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

[Peter Saint-Andre <[e-mail]>]

On 5/14/10 2:48 AM, Peter Sylvester wrote:
> 
> 
>>
>> 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.

We borrowed that wording from RFC 5280. Do you have a suggestion for
improvement? And, from the perspective of this proposed BCP, does it
make a material difference?

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

How about removing the words "within the subjectName field"?

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

Does this proposed BCP say that the subjectAltName has precedence? If
that is not clear, then we need to clarify it.

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

Our working copy of version -05 currently says:

   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].  A DN is an ordered sequence of Relative Distinguished Name
   (RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
   value pairs [LDAP-DN], each of which asserts some attribute about the
   subject of the certificate.  The RDNs are ordered in the DN sequence
   from most general to most specific.

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

OK. In fact do we need to say anything about the order (specific to
general or general to specific)?

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

So:

   ... In practice, the RDNs can be ordered in
   the DN sequence from most general to most specific or most specific
   to general, and the order cannot be relied upon.

Better?

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

This section is about certificate issuance, not client processing (or
server interpretation of the certificate, which so far is utterly out of
scope for this proposed BCP).

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

Consider:

1. DC=com, DC=example, DC=cn

vs.

2. DC=cn, DC=example, DC=com

Clearly com.example.cn != cn.example.com, but if one interpreted DCs
then both of those DNS domain names would match #1 and #2.

We can add more text about this to the spec.

>    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

Sure. Changed.

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

One may, but we're not trying to cover every possible profile of X.509v3
here, only those 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.

It's just an implementation note. I've added some clarifying text.

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

The purpose of the note is to warn client developers against using DCs.

> 3.4.4 seems to have a lot of redundant information and not the
> same as already presented elsewhere. 

Repetition is not necessarily a bad thing. We assume that client
developers will read only section 3, not section 4.

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

Maybe, but I think the repetition is useful. I'll double-check this when
I have more time.

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

Out of scope. We might write another spec about such use cases, but in
this case we think we're covering at least 80% of the usage.

> have fun

Always. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/