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

From: =JeffH <[email-masked]>
Date: Tue, 08 Jun 2010 11:50:17 -0700

Martin Rex <[email-masked]> noted on
Wed, 12 May 2010 00:47:30 +0200 (MEST)...
 >
 > Further complicating the issue: While DER encoding leaves the ordering
 > of the contents of an ASN.1 SEQUENCE as is, the ordering of the contents
 > of an ASN.1 SET is "canonicalized" by DER encoding (based on the
 > numeric ordering of the final binary encoding of each element).
 > So the shorter elements will always end up first in RDNames
 > containing multiple attribute-value pairs in a SET.
 >
 > i.e.
 >
 >      CN=Foo+2.5.4.5=123ABC,O=bar,C=ZZ
 >      2.5.4.5=227DEF+CN=LongName,O=bar,C=ZZ

Nelson B Bolyard <[email-masked]> wrote on Fri, 04 Jun 2010 10:11:29 -0700
 >
 > On 2010-06-04 02:35 PDT, Peter Sylvester wrote:
 >>
 >> 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.
 >
 > 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.  :)

And Kaspar Brand <[email-masked]> had pointed out on
Thu, 13 May 2010 09:40:12 +0200
 >
 > Here's some data. It's from a sample of about 90,000 non self-issued
 > certs (from commercial CAs, most likely reflecting shares like those in
 > http://news.netcraft.com/SSL-survey). The data are from the beginning
 > of 2009, but I don't think the situation has considerably changed
 > in between.
 >
 > The second colum shows the RDNs in the order they have in the
 > ASN.1 subject SEQUENCE, while the first colum gives the number of
 > occurences of such a cert (only the "top 15" are shown).
 >
 >   19464 C, O, OU, OU, OU, CN
 >   15657 C, ST, L, O, OU, CN
 >    6859 O, OU, CN
 >    5603 C, ST, L, O, OU, OU, CN
 >    4983 C, ST, L, O, OU, OU, OU, OU, CN
 >    4813 C, ST, L, O, CN
<snip/>

I personally seem to recall observing certs in the wild whose string-formatted 
DNames included the "+" notation as Martin illustrates above, and which denotes 
an RDN SET, although I don't recall whether such certs were produced by "real 
CAs" as Nelson terms a certain subclass of CAs.

Kaspar -- would information wrt multi-valued RDNames be embodied in the sample 
you used to generate the above info you shared with the list?  If so, are there 
any occurances, and if so what's the frequency?

thanks,

=JeffH

---

From: Kaspar Brand <[email-masked]>
Date: Wed, 09 Jun 2010 09:11:56 +0200

> any occurances, and if so what's the frequency?

There are 38 occurrences (out of ~90,000), originating from three "real
CAs". The vast majority (34) are EV SSL certs from a CA which apparently
likes to stuff the CN (2.5.4.3) and the serialNumber (2.5.4.5)
attributes into a single RDN. [Not so surprisingly, the remaining 4
certs were issued by two CAs which apparently run their infrastructure
with software from that other "real CA" - which is the reason for seeing
the same peculiar encoding in their certs.]

In the context of this BCP, I consider the discussion about
"multi-valued RDNs" an academic thing, mostly. I would not mind,
however, to change the last sentence in section 2.2, item 6 to something
like "Furthermore, the certificate's subject Distinguished Name SHOULD
NOT contain more than one Common Name attribute, and MUST NOT contain
RDNs which consist of multiple Common Name attributes" (provided that
this wording pleases the ASN.1 terminology experts in the audience here).

The definition of "CN-ID" in section 1.3 should probably also be adapted
(i.e., it should explicitly forbid multi-CN RDNs).

Kaspar

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 20:18:48 -0600

> the same peculiar encoding in their certs.]

Thanks for the numbers.

> this wording pleases the ASN.1 terminology experts in the audience here).

Done in our working copy.

> (i.e., it should explicitly forbid multi-CN RDNs).

Is this a more accurate definition?

      *  CN-ID = a subject Distinguished Name (DN) whose constituent
         sequence of Relative Distinguished Names (RDNs) contains one
         and only one attribute value assertion (AVA) whose attribute
         type is Common Name (CN)

Peter

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

---

From: Kaspar Brand <[email-masked]>
Date: Thu, 10 Jun 2010 07:52:23 +0200

>          and only one attribute value assertion (AVA) whose attribute

I think it's better to refer to it at the RDN level (as is the case for
-05):

      *  CN-ID = a Relative Distinguished Name (RDN) in the certificate
         subject which contains one and only one attribute value
         assertion (AVA) whose attribute type is Common Name (CN)

When talking about CN-ID in the text, you would then say that only the
(DER-sequence-wise) last CN-ID is to be used for verification purposes.
Alternatively, the above definition could be changed to include this
"last" property as well, but this really depends on what text you
currently have in the working copy.

Kaspar

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Jun 2010 14:56:27 -0600

>          assertion (AVA) whose attribute type is Common Name (CN)

I think that's better, thanks.

Peter

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