[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding revised identities to IKEv2



At 1:50 PM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>At 4:38 PM -0500 11/8/02, Stephen Kent wrote:
>>At 1:21 PM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>>At 3:27 PM -0500 11/8/02, Stephen Kent wrote:
>>>>At 8:42 AM -0800 11/8/02, Paul Hoffman / VPNC wrote:
>>>>>At 10:46 AM +0100 11/8/02, Francis Dupont wrote:
>>>>>>=> there is no agreement about what checks must be done:
>>>>>>  - common sense says the identity must be a subject of the certificate
>>>>>>    (but this is not clearly specified in IKEv1 and perhaps some
>>>>>>     implementations don't perform this check)
>>>>>
>>>>>That does not follow. There is no standard way for the Subject 
>>>>>to be an email address (the way folks do it now is a 
>>>>>non-standard hack), there is no standard way for the Subject to 
>>>>>be an IP address. I'm not sure, but I think the DC method of 
>>>>>doing domain names in the Subject is also a non-standard hack.
>>>>
>>>>I think the use of DC is a "standard hack," i.e., there is an RFC 
>>>>defining how to represent any DNS name in this fashion, and it 
>>>>may even state that this is the preferred way to do so if you use 
>>>>a DN rather than the SubAltname.
>>>
>>>The "standard" (you can barely call it that), RFC 1274, preceded 
>>>subjectAltName by many years. It is yet another example of being 
>>>able to say two equivalent things in a PKIX certificate in two 
>>>very different ways.
>>
>>Agreed.
>>
>>But if one had to have a DNS name in the Issuer field, e.g., 
>>because PKIX mandates use of the Issuer DN in a CA cert, that's the 
>>only standard game in town for a DNS representation, right?
>
>No, you could use CommonName (CN). Given that name constraints 
>checking software is unlikely to get the hierarchy in four DC 
>components correct, you are better off saying "CN=www.example.com" 
>than "DC=www, DC=example, DC=com" because every piece of PKIX 
>software knows CN.

CN is definitely not a PKIX-endorsed way to represent a DNS name in a 
DN, so I rule it out on that basis just to start. Yes, every piece of 
software knows CN, but that does not make it a good choice in a 
larger sense. I could use name constraints with the DC structure, but 
not effectively with the CN structure, for example.

Steve