Re: Issue 282: cert validation, proposed text

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

>>        *  Certificate validation MUST include the 
>> verification rules as
>>           per [RFC5280].  If an SRV entry is present in the 
>> certificate
>>           and dynamic discovery based on DNS is used, the SRV entry
>>           SHOULD be validated. refence x.y.z here.
>>
>>     
> [Joe] Where is the SRV entry present in the certificate?  What does it look like? What is the value in the certificate validated against?  
>   

Right, sorry, I should have expanded on "reference x.y.z" :-) This is
about RFC4985: "Internet X.509 Public Key Infrastructure - Subject
Alternative Name for Expression of Service Name".

It defines a subjectAltName - otherName that's supposed to contain the
SRV record. I understood that so far, checking this is not in popular
TLS implementations yet, but it looks useful and deserves to be
mentioned IMHO. I'll update the reference in the draft.

> [Joe] I would suggest specifying a format for interop here.  You might want to take a look at 
> http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-14 which is somewhat similar and has some text on fingerprint matching.  
>   

Looks good, I'll add corresponding text to the next version of the draft.

>>        *  Peer validation always includes a check on whether the DNS
>>           name or the IP address of the server that is 
>> contacted matches
>>           its certificate.  DNS names and IP addresses can be 
>> contained
>>           in the Common Name (CN) or subjectAltName entries.  For
>>           verification, only one these entries is to be 
>> considered.  The
>>           following precedence applies: for DNS name validation,
>>           subjectAltName:DNS has precedence over CN; for IP address
>>           validation, subjectAltName:iPAddr has precedence over CN.
>>
>>     
> [Joe] In the syslog document referenced above we made it mandatory to support subjectAltName:DNSname matching.   Other places for the identity are allowed.  
>   

Ok, thanks for the pointer. That text looks good, and I might be tempted
to copy&paste from it :-). Just one question on it: if both a
subjectAltName:DNS and a CN are present, what if they differ? Which of
the entries gets precedence? Or is a match of any of the entries good
enough? My text emerged due to the impression that CN is regarded as
deprecated when subjectAltName:DNS is present, and consequently gives
subjectAltName:DNS precedence.

>>        *  Implementations SHOULD allow to configure a set of 
>> acceptable
>>           values for subjectAltName:URI.
>>     
> [Joe] What does the URI look like?  
>   

This is not constrained and defined by the users of the spec. As an
example, for the eduroam roaming consortium, we use a URL containing a
URN (due to subjectAltName:URI constraints, we can't use a URN directly):

The identity provider for the domain restena.lu has, for example:

URI:https://registry.edugain.org/resolver?urn=urn:geant:eduroam:component:idp:Europe:RESTENA:restena.lu

This enables checking on "urn:geant:eduroam:component:" as authorisation check. Plus, putting this URL into a browser will yield the registration data from the authoritative URN registry.

Other roaming consortia can define their own acceptable URI schemes.


Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>