Re: [certid] Comments on draft-saintandre-tls-server-id-check-04

[Peter Sylvester <[e-mail]>]

>
> 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).
DNs as a sequences of RDNs form a hierarchical name space similar to the 
DNS name space.
with the difference that the "labels" are not just a piece of texts but 
are structured , i.e.
SET OF of attribute/values assertions.

If one writes "a.b.c" then this is something that can be described as a 
string folling DNS name syntax,
and I could use it in whatever environment.

What is ambiguous in 2818 is that you may have a set of AVAs  with more 
than one
occurence of an AVA with common name. In theory...

Using the term 'field' is somewhat sloppy wording.


>
> 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.

Indeed. This is not surprising, if one looks at certification policies,
they are also pretty unprecise in that area.

But: what is deprecated in RFC 2818 is the fact not using
a subjectAltName:

    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. Although
    the use of the Common Name is existing practice, it is deprecated and
    Certification Authorities are encouraged to use the dNSName instead.

At least, if I understand the "otherwise" correctly and apply
Boolean an IETF logic.

As soon as one adds a subjectAltName, a verifier conformant
to 2818 doesn't even look for a common name.

As a "best practice", one may say that having
exactly one common name AVA in a single value RDN with
ensures that the cert is recognized as one belonging
to the intended host.

and to have an identical value in a subjectAltName

One may add that putting it as the last element in the
sequence covers the 0.000001% of very strange things,
I'd rather say that it is not necessary for this RDN
to be the last (i.e. explicitely tell verifiers so)

>
> (so we have some evangelizing to do with the CABForum folk...)

Well, my hourly fee is ... negotiable :-)

I (really don't) wonder how many of the CAs in that forum allow a
certificate request with two common names...

I think it is very important that the RFC use clear wording that
is also easy to understand by non native English.

    7.  The certificate SHOULD NOT represent the server's DNS domain name
        in a Relative Distinguished Name (RDN) of type Common Name (CN)
        (see [LDAP-SCHEMA]) within the subjectName field, even though it
        is recognized that many deployed clients still check for this
        legacy identifier configuration within certificate subjectName.

I do not see any reason for this unless one adds 'only' before the
within. see above.

        However, if this legacy identifer configuration is employed, then
        the server's DNS domain name MUST be placed in the last (most
        specific) RDN within the RDN sequence making up the certificate's
        subjectName, as the order of RDNs is determined by the DER-
        encoded Name within the server's PKIX certificate.

If one takes the text without saying that subjectAltName has precedece,
I think the message is wrong.


   The subject field of a PKIX Certificate is defined as a X.501 type
    Name [PKIX] and known as a Distinguished Name (DN).  See also [X.501]
    A DN is an ordered sequence of attribute type and attribute value
    pairs (termed "attribute value assertions (AVAs)"), where the
    attributes are to be those of the subject.  Each AVA is also termed a
    "Relative Distinguished Name (RDN)".  The RDNs are ordered in the DN
    sequence from most general to most specific.

this is simply wrong.

       DistinguishedName ::= RDNSequence

       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
           AttributeTypeAndValue

       AttributeTypeAndValue ::= SEQUENCE {
           type  AttributeType,
           value AttributeValue }



    Often such a
    DN string representation is ordered from left-to-right, most specific
    to most general.  See [LDAP-AUTH] for details.

I'd rather say that unfortunately both orderings occur and
it not always obvious to see which is used. I know about a
institude's CA that has country (C=DE) as last element
got that certified. :-)


    8.  The certificate MUST NOT represent the server's DNS domain name
        by means of a series of Domain Component (DC) attributes (because
        the order of Domain Components is not guaranteed, certain attacks
        are possible if DC attributes are included).

I think that this is also not nice wording. What is ment IMO is
that the server MUST NOT assume that whatever is put in DCs
is recognized as a domain name.

One should be careful about such words, sine it may be that
some extremely strict verifier misinterprets it. Talking about
'certain attacks' doesn't seem a useful information.

    2.  After the server provides its presented identifiers in the form
        of an PKIX certificate, the client checks each of its reference
        identifiers against the presented identifiers for the purpose of
        finding a match.

'presents its' instead of 'provides its presented'
and remove 'after'. It maybe present out of band

        The reference identifiers is matched with identifiers
        included/present/provided/electable in a PKIX certificate
        belonging to the server, i.e. by which the intended
        communication of data verification can be authenticated
        cryptograhically.

I don't really like PKIX here, one may have an X509 cert that is not
conformant to the PKIX profile.
       

   In addition to checking identifiers, a client MAY complete further
    checks to ensure that the server is authorized to provide the
    requested service.  However, methods for doing so (e.g., consulting
    local policy information) are out of scope for this document.

The chapter talks about Server identity verification. This paragraph
doesn't belong to this imo.


    o  The list SHOULD NOT include a CN-ID; however, the CN-ID (if
       included) MUST be constructed only from the source domain and
       never from a target domain.

       Note: A client MUST NOT construct a reference identifier
       corresponding to Relative Distinguished Names (RDNs) other than
       the Common Name and MUST NOT check for such RDNs in the presented
       identifiers.  In particular, this means that a client MUST NOT
       check a series of Domain Component (DC) attributes if included in
       the certificate (because the order of Domain Components is not
       guaranteed, certain attacks are possible if DC attributes are
       checked).

since a CN-ID is:

      CN-ID = a Relative Distinguished Name (RDN) of type Common Name
          (CN)

what is the purpose of the note?

3.4.4 seems to have a lot of redundant information and not the
same as already presented elsewhere. All text starting from
thesecond paragraph can be replaced by

    Therefore, if and only if the identity set does not include
    subjectAltName extensions of type dNSName, SRVName, or
    uniformResourceIdentifier (or any application-specific subjectAltName
    extensions), the client MAY as a fallback check cfor a CN-ID.

The examples may be put into the description of the certificate subject
structure.


3.6: There may also be the case where the server does not present a cert
at all. not the case of tls etc, but one may verify signatures of OCSP,
TSAs etc.

have fun
/PS