On 6.1.2017 10:30, Sumit Bose wrote:
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.
Is there a requirement that it must be possible for multiple rules to
match? If not, we could begin with a simpler (for admin) solution with
unique priorities and lift the restriction later when/if it becomes
necessary. But I don't have a strong opinion on this.
>
>>
>> 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
--
Jan Cholasta