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

Re: Adding revised identities to IKEv2



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.

--Paul Hoffman, Director
--VPN Consortium