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

Peter Sylvester wrote:
> 
> >> 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.
> 
> example, 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.

There is going to be software that will check the CN= RDName of the
certificate subject name for a match, even when subjectAltName of
type dNSName are present.  Either because they're fully backwards
compatible or because they do not check subjectAltNames at all.

While there have been few implementations checking for multiple
CN= parts, the guideline in rfc-2818 for subjectAltNames seems
to be much clearer, that there can be more than one, and more
than one needs to be checked.

The original approach to use a single certificate for several
hosts was to use a wildcard (*).  Personally, I prefer the multiple
individual hostnames to the wildcard.

Example: https://www.entrust.com  

It contains a CN=www.entrust.com and two subjectAltNames
type dNSName with the values "www.entrust.com" and "secure.entrust.com"

And a reasonable, fully backwards compatible approach to server endpoint
identification would be to check all names for a match sequentially,
and succeed when any one matches.

-Martin

> 
> 
> >    
> >>         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
> 
> 
> _______________________________________________
> certid mailing list
> certid@ietf.org
> https://www.ietf.org/mailman/listinfo/certid
> 