[Freeipa-devel] [RFC] Matching and Mapping Certificates

[Jan Cholasta]

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