On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote:
On 5.1.2017 10:39, Sumit Bose wrote:
> 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 issuers
> > > > > > 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 issuer
> > > > > > 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 at
> > > > > > 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 below)
> > > > > > 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 foo"
> > > > 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).
In pwpolicy and sudorule, the priority is required and has to be unique.
Maybe we should do this for certificate mapping rules as well?
I think there is no requirement that only a single rule should match
hence I think the priority here must not be unique.
>
> 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?
I'm not sure how CoS would be helpful here, I think a simple interger
attribute would be perfectly sufficient.
I agree.
bye,
Sumit
>
> >
> > bye,
> > Sumit
> >
> > >
> > > --
> > > Jan Cholasta
>
>
> --
> Jan Cholasta