On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote:
On 18.10.2016 07:34, Jan Cholasta wrote:
> On 17.10.2016 16:50, Rob Crittenden wrote:
> > Jan Cholasta wrote:
> > > Hi,
> > >
> > > On 13.10.2016 18:52, Sumit Bose wrote:
> > > > ===== Issuer specific matching =====
> > > > Although the MIT Kerberos rules allow to select the issuer of a
> > > > certificate there are use cases where a more specific selection is
> > > > needed. E.g. if there are some default matching rules for all
> > > > and some other issuer specific rules where the default rules should
> > > > not apply. To make this possible with the above scheme the default
> > > > rules must have an <ISSUER> clause which matches all but the
> > > > with the specific rules. Writing regular-expressions to not match a
> > > > specific string or a list of strings is at least error-prone if not
> > > > impossible.
> > > >
> > > > To make it easier to define issuer specific rules and default rules
> > > > the same time and optional issuer string can be added to the rule to
> > > > indicate that for the given issuer only those rules should be
> > > > considered. Given the use-case I think it is acceptable to require
> > > > that the full issuer must be specified here in LDAP order (see
> > > > and case-sensitive matching is used.
> > >
> > > This could also be solved by adding priority to rules - if two rules
> > > match, the one with higher priority (the issuer specific rule) is
> > > preferred over the one with lower priority (the default rule). IMO this
> > > is better than an optional issuer string as it offers greater
> > > flexibility.
> > The use cases I've seen haven't had to do with priority, though that
> > would be a nice enhancement, but with only allowing certificates issued
> > by a specific CA to be allowed (this is pretty common in web servers).
> > Being able to say "only do the matching on certificates issued by
> > is valuable.
> Sure, I'm not suggesting that matching by issuer should be removed, only
> that rule precedence should not be determined by the issuer field setting.
Bump. Sumit, what is your opinion on this?
I'm fine with an optional(?) priority as well. Since priorities are
already used in the pwpolicies this should be already known to the
experienced admin. I guess we just have stick with "A lower value
indicates a higher priority" to not confuse users. That's why I think
that the priority should be optional here and a missing value indicates
the lowest priority (default rules).
Are you thinking of using the CoS scheme here as well would a priority
attribute be sufficient because we do not want to reference internal
objects in the mapping rules?
> Jan Cholasta