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

[Peter Sylvester <[e-mail]>]

On 05/29/2010 12:00 AM, Peter Saint-Andre wrote:
> 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...
>>      
The sentence starting with 'What" was the comment.


>> Using the term 'field' is somewhat sloppy wording.
>>      
>    
There are two usages of field. There is no 'Common namefield".
> 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?
>    
There is a subsject field, but such thing as a 'Common name field'.

Using vocabulary which is undefined is not the best way to explain
best practices, i.e. to clarify usages, IMO.

>    
>>> 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)
>>
>>      
No comment here??

>>> (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"?
>    
The point is not (since already said) that there is no such thing
as 'an RDN of type Common Name', there are only AVAs but:

The SHOULD NOT may be misleading for a non-native English.
It may be understood as "It is not a good idea at all to put
an attribute of type Common Name in any RDN since it can be
misunderstood as the server's name independantly of what
is put in the subjectAltname extension."   'represent' is ambiguous
here.

exampe, you a Common Name attribute containing the server's name
and if the cert has a subjectAltName, have I 'represented' the
server's name in the Common Name or not? I have put it in,
I don't expect that someone verifies it there, but still, I have
can think I have represented it in two places.


>    
>>         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.
>    
As I said, here you have room for clarification. You essentially
rewrite 2818 (the most specific) without clarifying the
amiguity of multiple AVAs and without mentioning that
is is a BAD idea to have several attributs with type Common
Name.

"However, if this legacy identifier configuration is employed,
   in order to be surely recognizable, there SHOULD only
   be one attribute of type Common Name, and that ava
   SHOULD occur in a single element RDN."

>    
>>    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.
>    
Ok.
>    
>>     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)?
>    
The RDN order is the only thing clearly defined. What one should say
is that unfortunately there are the two orders in textual representations
multiplied by the two ways of reading them and that when tools
are displaying rdns in windows, things may be worse.

"When creating DNs, care must be taken in order to be sure that
the desired order of the RDN sequence is obtained."

>    
>> 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?
>    
In the DN encoding, the first element is the most significant
(for the decoding party).

The encoding party MUST be careful that the first element
is encoding receives the intended attribute.
>    
>>     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).
>    
"Certain attacks", IMO, that's not something to be used to justify
a MUST NOT.

The point is the word "represent". As above.
>    
>> 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.
>    
And you can have dc=cn.example.com
> 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.
>    
Ok
>    
>>         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.
>    
fair.

>    
>>    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.
>    
will see.
>    
>>     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.
>    
Hm, need to think more.
>    
>> 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.
>    
You seem to consider this as a matter of style, I don't.
We may be in violant disagreement,  I don't fight. :-)
>    
>> 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.
>
>    
Hm, if you  succeed to get more time, tell me the recipe. :-)
>> 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.
>    
Why out of scope? what has the interpretation of a cert to do with
the way it is detected/communicated?


regards
Peter