Re: [netconf] x509c2n:cert-to-name problem

[Kent Watsen <[e-mail]>]

Hi Martin,


>>>> The "tls-server-parameters" container defines the certificates used to
>>>> authenticate the client's cert.  In many deployments, regardless how
>>>> the client cert is authenticated, the "client-identification" section only
>>>> needs to explain how to extract the "name" from the cert, a fingerprint
>>>> isn't needed to identify either the client's end-entity or some
>>>> intermediate cert.
>>> 
>>> Ok.  To me this sounds like you need a more complex^wsophisticated
>>> client identification mechansim than what a plain cert-to-name gives
>>> you.  I don't think there is anything wrong with the current
>>> cert-to-name grouping.  So let's continue this discussion in the
>>> netconf ML, where this model is being developed.
>> 
>> In an attempt to resolve this issue, I modified both ietf-netconf-server
>> and ietf-restconf-server as follows:
>> 
>> OLD:
>>        uses x509c2n:cert-to-name;
>> 
>> NEW:
>>        uses x509c2n:cert-to-name {
>>          refine "cert-to-name/fingerprint" {
>>            mandatory false;
>>            description
>>              "A 'fingerprint' value does not need to be specified
>>               when the 'cert-to-name' mapping is independent of
>>               fingerprint matching.  A 'cert-to-name' having no
>>               fingerprint value will match any client certificate
>>               and therefore should only be present at the end of
>>               the user-ordered 'cert-to-name' list.";
>>          }
>>        }
> 
> Did you see my email "client identification in ietf-netconf-server"?
> I don't think this refinement is the correct solution.

Having replied to your other message, I still don't understand this statement.  I understand the fingerprint being useful in some scenarios and unnecessary in others.  When unnecessary, as a user, I'd rather not have to configure it.


Kent // contributor