On 13.07.2010 18:32, Paul Hoffman wrote:
> At 7:09 AM +0200 7/13/10, Kaspar Brand wrote:
>> -08 looks good to me, generally speaking, but in addition to the
>> implementation note at the end of 2.2 I would add some wording to
>> 4.4.4 which states that a) if multiple CN-IDs are found in the
>> subject, all of them should be checked
>
> Wait, wait. The spec says in a few places that there must only be a
> single CN. If you add that (which was taken out of -08), you have to
> change all of them.
I'm not sure I'm following you. Add what "which was taken out of -08"?
Section 3 currently says:
If a CN-ID is included, the
certificate's subject field SHOULD NOT contain more than one
CN-ID, and MUST NOT contain RDNs which consist of multiple Common
Name attributes.
and CN-ID is defined as
* CN-ID = a Relative Distinguished Name (RDN) in the certificate
subject that contains one and only one attribute-type-and-value
pair of type Common Name (CN); see [PKIX] and also
[LDAP-SCHEMA]
What's underspecified in 4.4.4 is how CN checking should be done if
multiple CN-IDs are present, but that's the only place where it needs to
be covered, I think.
> I propose that we stay with the current MUST for a single CN.
But this wouldn't really address the issue of how to handle a
certificate with multiple CNs in the subject... and they do occur in the
wild, so they shouldn't simply be ignored in this document - let's use
the opportunity to specify this explicitly.
>> (Finally, let me add that browsers such as MSIE, Opera or Safari
>> already implement this kind of multi-CN checking - if there is no
>> subjectAltName extension, they will go through all CNs and look for
>> a match [1]).
>
> That doesn't make it a best current practice.
Not in the literal sense, because currently there's no real consensus on
the meaning of the "(most specific) Common Name field" statement from
RFC 2818, so implementations differ in their behavior right now. I would
at least consider it "best future practice", however, given that you
would no longer have to argue about most specific vs. least specific etc.
Kaspar
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
