> From: ArkanoiD <[email protected]>
>
> It does not really answer the question, we should analyse certificates seen
> "in the wild" ;-)
>
> On Wed, May 12, 2010 at 03:58:23PM -0700, Love H?rnquist ?strand wrote:
>>
>> 12 maj 2010 kl. 15:37 skrev Peter Saint-Andre:
>>
>> >> So I'm not sure right now what to say about that. I suspect we can still
>> >> stipulate that the only RDN having attr type of CN that we'll pay
>> >> attention to is the one at the far end of the RDN sequence comprising
>> >> the DN.
>> >
>> > We can stipulate that, but is it realistic?
>>
>> Yes, since that's what RFC 2818 said.
in essence I'm agreed with ArkanoiD.
In particular here's what RFC 2818 sez (in section 3.1 Server Identity)..
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. ...
..which is ambiguous because X.501 does not explicitly state which RDN in the
DN sequence is the most specific (it's implied) and there allegedly exist
non-trivial slices of current practice don't necessarily follow that
stipulation anyway (for whatever reasons).
Also, we should note that the current rev of "CA/Browser Forum: Guidelines For
The Issuance And Management Of Extended Validation Certificates (version 1.2)"
<http://cabforum.org/Guidelines_v1_2.pdf> specifies using CN (commonName)
containing the host domain name /or/ dNSName in subjectAlternativeName (see
section 8.1.1(2) therein), rather than deprecating use of subject:commonName
(in that doc's notation). that doc also doesn't specify where in the DN's RDN
sequence an RDN of type commonName should/must be placed.
(so we have some evangelizing to do with the CABForum folk...)
=JeffH
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
