Re: [certid] Need to define "most specific RDN"

[Peter Sylvester <[e-mail]>]

On 07/06/2010 02:35 PM, Ludwig Nussel wrote:
> Kaspar Brand wrote:
>    
>> [1] Re-reading section 3.1 in RFC 2818 can actually confirm this
>> hypothesis, under the following interpretation: "the (most specific)
>> Common Name field in the Subject field of the certificate MUST be used"
>> can be understood to mean the domain name which has the highest number
>> of DNS labels: if the subject has CN=foo.example.net and CN=example.net,
>> then the first one must be used for the identity check (it's more
>> specific than CN=example.net), irrespective of its position in the DER
>> encoded subject, actually.
>>      
> That interpretation at least doesn't require knowledge about
> certificate encoding subtleties. It's ambiguous though. You could
> have several CN with an equal number of dots after all. Just think
> of this one:
> http://www.mail-archive.com/[e-mail]/msg61198.html
>
> cu
> Ludwig
>
>    
X.500 defines a tree structure, the nodes are relative names put
into a hierarchie represented by a DN. a prefix of the elements in
the sequence defines thus a "subtree", and the relative name of a leaf
is the rightmost element, In a tree the most specific element a leaf
and moving backwards defined less specific.

There is no need at all to talk about binary encoding, or DER or
whatever. A DN is a sequence of relative names forming a tree
structure when interpreted in the X.500 context. This is thus
one clear interpretation of 'most specific'  (for a RDN).

But: Since RDN can have multiple occurences of AVAs with the
same type, (and one my even construct interpretations as above)
it is not clear whether anything else than putting exactly one AVA
with type Common Name into the very last component and not
having any AVA with type Common name may lead to unexpected
results, making 2818 unclear.

At least I think one can agree that Common name in the last RDN
as the only AVA is "safe". What can one do else:

- some other RDNs without after it? probably ok, but not sure.
- other RDNs with Common Name before? oh oh, like th \0 attack
- multiple AVAs in the same RDN. maybe.
...

Anyway, since there is no good reason not to put a subjectAltName,
I do not think that one shouls say anything more than
"If you use a Common Name other than in the most simple case one
  may run a risk not to be interpreted correctly."

replace:

    The subject field of a PKIX certificate is defined as an X.501 type
    Name and known as a Distinguished Name (DN) -- see [X.501] and
    [PKIX].....  and so on

by

    In essence, Subject (and Issuer) are essentially are defined in PKIX and
    X.50x/ISOnnnn  as ASN.1 type DistinguishedName which is (in ASN.1 terms)
    a a row of elements (SEQUENCE OF in ASN.1 terms)
    of type RelativeDistinguishedName (RDN).

    In the directory context and in the PKIX context
    this defines a hierarchical tree structure
    from left to right and least to most specific, i.e. a prefix defines
    a subtree and the relative name of a leaf is the rightmost one
    in the sequence.
    An RDN is a collection (SET OF in ASN.1 terms) of elements of
    the ASN.1 type  AttributeValueAssertion (AVA).  ... leaving as
    exercise a definition of AVA.

    Thus, regarding this, the usage of "most specific RDN of type Common
    Name" in HTTPS is not precise enough.
    Furthermore,  string representations (as well as graphical ones)
    may confuse
    users because of two possible interpretations of an implied order of 
RDNs.
    e.g. LDAP define the order ....
    and, historically, Openssl uses the other direction.

By the way: Certificates are not binary objects. At best:

Certificates are structures defined as ASN.1 types, and (almost always) 
transmitted in
an encoding called DER... which may be encapsulated in base64, i.e.
becoming textual ... etc. Anyway, does this matter here?

Compare: The last paragraph of 2.2 doesn't use DER.

SubjectAltname is not a 'field', it is an occurence of type
Extension identified (... let's say ... ) as SunjectAltName.

Certificate subjects may have alternate names represented as Extension
identified as SubjectAltName.

Thus: 2.2 can be greatly simplified IMO.

ave fun.