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

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 1 Jun 2010 11:39:44 -0700

This looks to me like a case of "violent agreement".

On May 31, 2010, at 11:58 AM, ArkanoiD wrote:

> On Mon, May 31, 2010 at 05:18:17PM +0200, Martin Rex wrote:
>>> 
>>> 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.
> 
> Actually it should not, though i do not see any harm in behaving that
> way.

His observation was not w.r.t. what SHOULD happen, but a pragmatic observation of what WILL happen in the real world.

>> 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.
> 
> ..and multiple CNs are likely to be an error. I'd better reject this
> certificate as invalid.

He says there are "few" implementations that accept what you consider an error.  Possibly there are zero, but I hope it's few enough we can ignore them.  (Life's complex enough as it is.)

>> 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.
> 
> But we may safely ignore CN in this case, and that's what we probably intend
> to do.

Agreed.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 01 Jun 2010 15:38:43 -0400

On Tue, 2010-06-01 at 11:39 -0700, Henry B. Hotz wrote:
> He says there are "few" implementations that accept what you consider
> an error.  Possibly there are zero, but I hope it's few enough we can
> ignore them.  (Life's complex enough as it is.)

For some test results for implementation support for multiple CNs
(possibly outdated by now), see:

http://wiki.cacert.org/VhostTaskForce#Interoperability_Test

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Jun 2010 00:37:13 +0200 (MEST)

> http://wiki.cacert.org/VhostTaskForce#Interoperability_Test

Thanks for that link!

I'm puzzled why the list shows IE.  AFAIK, the hostname matching
is entirely performed inside of SChannel SSP
(Microsoft's TLS implementation), and that is a part of the operating
system since at least Windows 2000, and _not_ a part of the MSIE browser.

And even today, the installed base of Windows XP outnumbers the
installed base of Windows Vista and Windows 7 combined, so talking
about particular versions of MSIE instead of specific combinations
of the Windows Operating System plus a particular version of
the MSIE browser is confusing/misleading.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Jun 2010 00:50:49 +0200 (MEST)

> the MSIE browser is confusing/misleading.

Background info:
http://msdn.microsoft.com/en-us/library/aa375924%28VS.85%29.aspx

See description of function parameter pszTargetName in the
API description of the SSPI call InitializeSecurityContext(SChannel).

The pszTargetName input parameter is necessary to make client side
session caching work, so it is likely always asserted by all versions
of MSIE -- causing the SChannel SSP to perform the certificate
verification against this name -- if the documentation is correct.

However, MSIE could add additional checks on top of that,
which I am not aware of.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 15:12:21 -0600

On 5/29/10 11:46 AM, Peter Sylvester wrote:
> some more details.
> 
> In 1.1:
> 
> 
> There is the possibility to indicate several identities:
> 
> "Only a match between the client's reference identity and the server's
> presented identity enables the client to be sure that the certificate
> can legitimately be used to secure the connection."
> ==>
> "In general, a match between the client's reference identity and one of
> the server's
> presented identities is required to enable the client to be sure that
> the certificate
> can legitimately be used to authenticate the connection."

Ah, I see what you're getting at. Yes, the existing text is rather
informal, since later in the document we talk more precisely about
identifiers, not identity. I've reworded that paragraph as follows:

                                 When a client connects to an
   application server using Transport Layer Security [TLS] (or, less
   commonly, [DTLS]), it references some conception of the server's
   identity while attempting to establish a secure connection (e.g.,
   "the web site at example.com").  Likewise, during TLS negotiation the
   server presents its conception of the server's identity in the form
   of a public-key certificate that was issued by a certification
   authority in the context of the Internet Public Key Infrastructure
   using X.509 [PKIX].  Informally, we can think of these identities as
   the client's "reference identity" and the server's "presented
   identity" (these rough ideas are defined more precisely later in this
   document through the concept of particular identifiers).  In general,
   a client needs to verify that the server's presented identity matches
   its reference identity so that it can be sure that the certificate
   can legitimately be used to authenticate the connection.

> (see: "The application server is identified by a name or names carried in
>    the subject field and/or the subjectAltName extension of the
>    certificate.")
> 
> "The Internet Public Key Infrastructure" sounds ambiguous quite right to
> me.
> - The only thing of a PKI in question that is ever transmitted
>   and visible in the Internet might be the server's certificate.
> - There is no "Internet PKI"  (like the DNS).
> 

RFC 5280 has the title "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile". We're simply
inheriting from that, because it is a common baseline for this proposed
BCP and defines terms that are familiar to those who will use this
proposed BCP. If you have problems with RFC 5280, please take that up
with the authors of RFC 5280.

> "in the context of the Internet Public Key Infrastructure using X.509"
> ==>
> "in the context of a Public Key Infrastructure using X.509".

See above.

>    Likewise, during TLS negotiation the server presents
>    its conception of the server's identity
> 
>    Application protocols have traditionally specified their own rules
>    for representing and verifying server identities.
> 
> I suggest to replace "represent" by "present". (The word represent seems
> to be used interchangeable with present in the current text). I'd prefer
> even 'indicate' instead.

Your distinctions are quite subtle.

The server has a certificate. It presents (gives, hands over, shows,
offers) the certificate to the client during TLS negotiation. Thus
"present" seems appropriate in the first quoted sentence.

The server's certificate contains various information (e.g.,
subjectAltName extensions). That information is intended to represent
(depict, describe, symbolize, embody) the server's identity. Thus
"representing" seems appropriate in the second quoted sentence.

IMHO "indicate" is not a good substitute for "present" in the first
sentence or "represent" in the second sentence, because "indicate" is a
bit ambiguous -- it can mean either "point, show" (roughly equivalent to
"present") or "be a sign of" (roughly equivalent to "represent").

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 15:52:49 -0600

On 5/29/10 5:47 AM, Peter Sylvester wrote:
> 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.

OK. If you think that text in RFC 2818 is problematic, then feel free to
express the need for fixing RFC 2818. If the ambiguities in RFC 2818
have leaked into this proposed BCP, then that's something we can fix.

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

I don't think that the term "Common name field" is used in this proposed
BCP.

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

Agreed. But splitting hairs or coming up with new terminology might not
be a productive use of our time.

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

RFC 2818 didn't deprecate much.

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

Your point was too subtle for me to understand, so I didn't comment.

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

I fail to see the ambiguity. This says "You can include a CN, but you
should not make the content of that CN a DNS domain name".

> 'represent' is ambiguous
> here.

See my other message to the list (sent a few minutes ago).

> exampe, you a Common Name attribute containing the server's name

What is "the server's name"?

Let's take a concrete example, say the Google Talk service hosted at
talk.google.com. I would say that you have:

O=Google
CN=Google Talk
dNSName=talk.google.com

Here the name of the service is "Google Talk" and that's represented in
the Common Name (because it is a human-friendly name for the service).
We are recommending against putting "talk.google.com" in the CN.

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

I meant "doesn't", not "does".

> As I said, here you have room for clarification. You essentially
> rewrite 2818 

This proposed BCP is not limited to HTTP so it does not (only) rewrite
RFC 2818, but yes it is intended (in part) to provide more up-to-date
guidelines.

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

Because you are the first person to raise that issue.

What exactly is the problem with multiple CNs? What is the attack?

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

Something like that seems sensible. The significance of the last clause
is not clear to me.

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

Thanks for the text, I've added that sentence (but I changed "obtained"
to "enforced").

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

OK.

> The encoding party MUST be careful that the first element
> is encoding receives the intended attribute.

Right.

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

Or perhaps dc=cn.example, dc=com (or whatever)?

In any case it seems like a bad idea to allow DCs and I've added a
security consideration about this.

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

See the security considerations in -05 (will publish soon).

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

OK.

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

GTD. :)

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

Out of scope because we're trying to limit this proposed BCP to exactly
what is described in the Scope section. An OSCP responder is not an
application service as described in this proposed BCP. Feel free to
write your own BCP for such a scenario, but it's out of scope for this one.

Peter

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 03 Jun 2010 14:53:17 -0700

> than one needs to be checked.

That is precisely what it says NOT to do.  It says

>    field in the Subject field of the certificate MUST be used.

The phrease "the (most specific) Common Name field in the subject field"
is not plural.  There is at most one Common Name attribute in the name
that is *the* most specific one.  The words "most specific" refer to its
position in the list of RDNs, which are arranged (as encoded in the
certificate Name field) from most general (first) to most specific
(last).  So, the most specific Common Name is the last of the Common
Name attributes in the sequence of RDNs, as encoded in the certificate.

---

From: Sean Turner <[email-masked]>
Date: Thu, 03 Jun 2010 17:59:09 -0400

> RFC 2818, but yes it is intended (in part) to provide more up-to-date

Should we add a section that moves 2818 to historic? (sorry if this 
has been asked before)

spt

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 16:05:42 -0600

On 6/3/10 3:59 PM, Sean Turner wrote:
> Should we add a section that moves 2818 to historic? (sorry if this has
> been asked before)

I'm not that ambitious. :) Besides, I think this proposed BCP would
update one small aspect of RFC 2818, not obsolete it.

Peter

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

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 Jun 2010 11:35:40 +0200

> Name attributes in the sequence of RDNs, as encoded in the certificate.
You can have two AVAs of the same type in the on RDN, i.e.
two common names in the same RDN. There the interpretation
of most-significant is not clear.

There term of 2818 itself is wrong, there is no such thing
a 'Common Name field'.

If one puts no more than one AVA of type CN into an
RDN, and only one of such RDN, the result is ok.
The "(most specific)" is a kind of hint not to put more
than one unless you want to attack like a \0 :-)

/P

PS: I "like" the *.ietf.org cert use by the server  'ietf.org'  :-)

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 18:37:42 +0200 (MEST)

> Name attributes in the sequence of RDNs, as encoded in the certificate.

I am perfectly well aware of the wording in rfc-2818.

But security-wise an X.509 Cert containing

  CN=host1.example.com, CN=host2.example.com, CN=host3.example.com

is significantly less dangerous that an X.509 Cert containing

  CN=*.example.com

and therefore this wording in rfc-2818 is unreasonable in several
aspects and I chose to completely and deliberately ignore it in my
implementation.

Btw. I did not understand the meaning of "most specific" anyway,
so I considered it unlikely that this could be interoperably
implement by only matching a single CN= entry.  While the initial
definition of distinguished names might have had a hierarchical
directory structure in mind, one does find distinguished names
in "unusal" ordering out there, as well as distinguished names
entirely without country AVA, even ones with only CN=

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 04 Jun 2010 10:11:29 -0700

> of most-significant is not clear.

Agreed, in principle.  In practice, I've never seen a certificate produced
by a real CA with multiple AVAs in a single RDN.  I've seen them in certs
produced by test scripts, and by people playing with OpenSSL.  :)

> There term of 2818 itself is wrong, there is no such thing

Agreed, whole heartedly.  Still, we know what they meant.  But I'm glad this
mistake is not repeated in your draft.

> RDN, and only one of such RDN, the result is ok.

I agree with the first part of that.  Don't see why the second restriction
is necessary for the result to be OK.

> than one unless you want to attack like a \0 :-)

Yes, an attach to which software that ignores the "most specific"
requirement will be vulnerable.

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 20:38:36 +0200 (MEST)

> produced by test scripts, and by people playing with OpenSSL.  :)

A few years ago I received a certificate of a productive PKI
from a big account customer, and it had RDNames with two AVAs
(CN= and SERIALNUMBER= in one RDName SET).

The concept of "most significant" only applies to RDName, and not to
members of the RDName set (because a SET is specified to be an unordered
list, and ASN.1 DER encoding actually enforces a specific canonical
ordering for ASN.1 SETs that unconditionally overrules whatever the
creator of the distinguished name may have desired).

So technically an RDName set with two different CN= are possible.
In the sense of the directory hierarchy, both of them are
"most significant".

So that part of rfc-2818 doesn't make any sense.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 07 Jun 2010 11:23:30 -0700

(Resending: first copy seems to have bounced off the server.)
On 2010-06-04 09:37 PDT, Martin Rex wrote:

> and therefore this wording in rfc-2818 is unreasonable in several aspects
> and I chose to completely and deliberately ignore it in my 
> implementation.

I'm not surprised that you say that.  It's not the first time you've
told us that you've deliberately ignored something in an RFC that you
considered unreasonable.

But consider that, because of the wording that you ignore, some (many) CAs
will only check the DNS name in ONE of the CNs in the cert subject name.
Other CNs may contain strings whose contents are unchecked.
If you rely on their contents, you're relying on unchecked DNS names.
I wouldn't call that "significantly less dangerous" than a wildcard cert
whose domain (not host) name part has been checked.

Now, as an aside, I think the practice of CAs to put unchecked and
unvetted data ("certified nonsense") into the subject names of their
certs is reprehensible, and IMO, the RFCs should all explicitly
disallow it.  Maybe this draft is the place to start.  But until then,
sadly, it will remain the case that some CAs check only certain specific
attributes (and then only the last one) in the names of the certs they
issue, and software that chooses to honor other fields will be vulnerable.

> Btw. I did not understand the meaning of "most specific" anyway, so I
> considered it unlikely that this could be interoperably implement by only
> matching a single CN= entry.  While the initial definition of
> distinguished names might have had a hierarchical directory structure in
> mind,

The initial, *AND CURRENT*, definitions of DNs still have a hierarchical
organization.  X.501 is worth a read.

> one does find distinguished names in "unusal" ordering out there, as well
> as distinguished names entirely without country AVA, even ones with only
> CN=

True.  There's no requirement that any particular attribute types appear
in any hierarchy.  X.501 talks about this at length.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Jun 2010 16:27:31 +0100

Hi Sean,

> Should we add a section that moves 2818 to historic? (sorry if this 

RFC 2818 contains more information than just the TLS server identity 
verification procedure for https. Besides RFC 2818 is widely used and I 
think moving it to historic would be a disservice to the community. 
Maybe you meant to suggest "obsoleting" it?

One year ago I was trying to convince Ekr to update RFC 2818, but he 
wasn't interested. I still think this would be a good idea. I also think 
that HTTPBIS is a better place for this activity.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Jun 2010 09:36:03 -0600

> that HTTPBIS is a better place for this activity.

Agreed. After HTTPBIS completes its current work items, naturally. :)

/psa

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Jun 2010 11:44:37 -0400

> Maybe you meant to suggest "obsoleting" it?

Maybe we should be updating the pertinent sections?  That would mean 
adding "Updates: 2818 (once approved) to the header of this document? 
  Also clearly state it doesn't just apply to HTTP.

> that HTTPBIS is a better place for this activity.

What Peter said ;)

spt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Jun 2010 16:45:18 +0100

Sean Turner wrote:

>> verification procedure for https. Besides RFC 2818 is widely used and 
>> I think moving it to historic would be a disservice to the community. 

Yes, we could do that.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 10 Jun 2010 10:22:59 -0700

My NASA PIV card has one.  The ambiguity of ordering in the string representation does in fact cause problems.