Subject: [pkix] errata request for RFC 5280

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Jun 2010 20:28:46 +0200

Hello,

as far as I have seen and read, the only way in RFC 5280 and its 
predecessors
to detect the order in which a DN hierarchy is encoded
i.e. highest = first element in sequence,
is to look into the non normative examples or
to go to the X.5xx base standards.

I think the direction of the encoding should be defined explicitely in the
description of DNs.

Similar, it may be worth to add that a subtree in name contraints is a
prefix of such  sequence.

regards
Peter Sylvester

---

From: Andrea Caccia <[email-masked]>
Date: Mon, 21 Jun 2010 21:55:31 +0200

I agree there is some confusion here. The source should be as the directory is built so a standard hierarchy should be used, but it is not required, it can just be a best practice that facilitate searching a certificate in a directory service. 
Some rule can also help interoperability.
And there is an additional issue: a DN is a sequence of RDN that is a set of attributes, in fact taking the syntax from RFC4514 clause 2:

      DistinguishedName ::= RDNSequence

      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
          AttributeTypeAndValue

      AttributeTypeAndValue ::= SEQUENCE {
          type  AttributeType,
          value AttributeValue }

In string format, RDN are separated by commas "," while attributes inside a RDN are separated by a plus sign "+" and, being a SET the order is not relevant.

Taking the DN from RFC5280 example, i.e.:
cn=End Entity,dc=example,dc=com;

if you need to add another attribute to the end entity, say an ID stored in a serialNumber attribute (quite common e.g. for qualified certificates), even without considering strange orderings you have 4 different ways to represent the same DN:

cn=End Entity+serialNumber=Some ID,dc=example,dc=com;

is the same of:
serialNumber=Some ID+cn=End Entity,dc=example,dc=com;

but is different from:
cn=End Entity,serialNumber=Some ID,dc=example,dc=com;

that is different from:
serialNumber=Some ID,cn=End Entity,dc=example,dc=com;

If you consider DER encoding, the first 2 are encoded exactly the same (and the most correct from an X.500 perspective, as "serialNumber" and "cn" belongs to the same directory entry) but you have 3 different way to express the same DN!

IMO, this is an additional aspect to consider.

Andrea Caccia

Il giorno 21/giu/2010, alle ore 20.28, Peter Sylvester ha scritto:

> Hello,
> 
> as far as I have seen and read, the only way in RFC 5280 and its predecessors
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Michael StJohns <[email-masked]>
Date: Mon, 21 Jun 2010 16:20:26 -0400

Hi Peter -

I think you mean instead - the way you translate to/from the DER encoding to a string representation and vice versa?

Traditionally, some X509 tools have represented names as "first string component is the first DER component", while LDAP (and X500 directory names) have been represented as "last string component is the first DER component".

So 

"c=US,o=Mikes Co,cn=Random User"  (X509)

would have the same DER encoding (assuming no typos) as

"cn=Random User,o=Mikes Co,c=US"  (ldap).

And this is specific to the tools.  For example, the java "keytool" uses the last DER first string model, while openssl uses first DER first string model when printing out names.  It's literally tool and library specific.

Not sure there's anything to be done in the RFC space. 

Mike

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 21 Jun 2010 16:28:28 -0400

Andrea,

Below you presented four examples:

    1) cn=End Entity+serialNumber=Some ID,dc=example,dc=com
    2) serialNumber=Some ID+cn=End Entity,dc=example,dc=com
    3) cn=End Entity,serialNumber=Some ID,dc=example,dc=com
    4) serialNumber=Some ID,cn=End Entity,dc=example,dc=com

As you noted, 1) and 2) are different string representations of the same 
DN, and so the DER encoding of 1) and 2) would be the same.  However, 3) 
and 4) are different DNs than the DN in 1) and 2).  So, these are not 4 
different ways to represent the same DN, these are 3 different DNs.  
They may all convey essentially the same information, but they are still 
different DNs.  Here is the text from Section 7.1 of RFC 5280 for 
determining whether two DNs match (i.e., are the same):

    Two naming attributes match if the attribute types are the same and
    the values of the attributes are an exact match after processing with
    the string preparation algorithm.  Two relative distinguished names
    RDN1 and RDN2 match if they have the same number of naming attributes
    and for each naming attribute in RDN1 there is a matching naming
    attribute in RDN2.  Two distinguished names DN1 and DN2 match if they
    have the same number of RDNs, for each RDN in DN1 there is a matching
    RDN in DN2, and the matching RDNs appear in the same order in both
    DNs.  A distinguished name DN1 is within the subtree defined by the
    distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
    and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.

Dave

On 06/21/2010 03:55 PM, Andrea Caccia wrote:
> .

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Jun 2010 22:42:35 +0200

> I think you mean instead - the way you translate to/from the DER encoding to a string representation and vice versa?
No, I am not talking about string representations.

Where in RFC 5280 and predecessors it is said that the 'highest'
element in an RDN hierarchy is the first in the encoding. In a normative 
part
of the text itself and not indirectly via examples or references to 
X.500 or LDAP.

Ok. Dave gave the answer:

    "A distinguished name DN1 is within the subtree defined by the
    distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
    and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored."

Given a natural interpretation of tree and subtree, one can deduce
that the "highest" RDN is the first.

Problem solved for me.

---

From: Andrea Caccia <[email-masked]>
Date: Mon, 21 Jun 2010 22:54:09 +0200

Yes, I fully agree. I'm pointing out that, without any guidance, different implementations can exist for the same semantic.

In RFC3739 at 3.1.2 you have:

3.1.2.  Subject

   The subject field of a certificate compliant with this profile SHALL
   contain a distinguished name of the subject (see 2.4 for definition
   of distinguished name).

   The subject field SHALL contain an appropriate subset of the
   following attributes:

      domainComponent;
      countryName;
      commonName;
      surname;
      givenName;
      pseudonym;
      serialNumber;
      title;
      organizationName;
      organizationalUnitName;
      stateOrProvinceName; and
      localityName.

So, all my DN's are valid as subject DN for a qualified certificate and you can have the same semantic expressed in different ways.
It is the case in my country there are common rules for building the subject DN, stating what to put in the various attributes, but no rules, as in RFC3739, about the ordering, so the software silently violate the rule in RFC5280 §7.1 in comparing subject DN's (this is what I guess that happens just looking at their behaviour). This is why I think that some guidance can help interoperability.

Andrea

Il giorno 21/giu/2010, alle ore 22.28, David A. Cooper ha scritto:

> As you noted, 1) and 2) are different string representations of the same DN, and so the DER encoding of 1) and 2) would be the same.  However, 3) and 4) are different DNs than the DN in 1) and 2).  So, these are not 4 different ways to represent the same DN, these are 3 different DNs.  They may all convey essentially the same information, but they are still different DNs.  Here is the text from Section 7.1 of RFC 5280 for determining whether two DNs match (i.e., are the same):
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 21 Jun 2010 17:28:58 -0400

There are multiple ways to marshal DNs into strings.  Directory order (top-down) or reverse (bottom-up)?  Comma-delimited or slash-delimited?  And then there's all those special character encoding syntaxes...

So the rule is:

"Thou shalt not compare DNs as strings."

Failure to obey this rule leaves latent bugs in your system to be discovered at a later inconvenient date.  E.g., a major federal agency web application relied on an unstated DN string representation when passing the authenticated subject DN from web front end to the middle tier server.  Then the front end changed, so did the string marshalling of the DN.  Whammo!  Instant and total denial of service.

While contractors may love emergency code changes (they get to charge a premium) the deploying program took a major hit.

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Michael StJohns
>Sent: Monday, June 21, 2010 3:20 PM
>To: Peter Sylvester; [email-masked]'
>Subject: Re: [pkix] errata request for RFC 5280
>
>Hi Peter -
>
>I think you mean instead - the way you translate to/from the DER
>encoding to a string representation and vice versa?
>
>Traditionally, some X509 tools have represented names as "first string
>component is the first DER component", while LDAP (and X500 directory
>names) have been represented as "last string component is the first DER
>component".
>
>
>So
>
>And this is specific to the tools.  For example, the java "keytool" uses
>the last DER first string model, while openssl uses first DER first
>string model when printing out names.  It's literally tool and library
>specific.
>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 21 Jun 2010 15:09:35 -0700

> "Thou shalt not compare DNs as strings."

IIUC all the discussion and angst relates to DER <--> string translation issues.  Shouldn't we therefore just define what's supposed to happen in terms of the DER, since that avoids all the questions and ambiguity?  

Provide appropriate dumps as examples and add a note that different implementations do the string translation differently, so you MUST do <what Tim said>.

I guess I'd add a second note that if string compares are done, then the implementor MUST verify that the translation behaves consistently AND properly handles the equivalence of A=V1+B=V2 multi-value RDN's.  You could talk me out of the second note, depending on how strongly worded the first prohibition is.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 22 Jun 2010 00:21:15 +0200

On 06/22/2010 12:09 AM, Henry B. Hotz wrote:
> IIUC all the discussion and angst relates to DER<-->  string translation issues.
Well,  yes and no.

>   Shouldn't we therefore just define what's supposed to happen in terms of the DER, since that avoids all the questions and ambiguity?
>    
Most (and intentionally all) of the text in 5280 is doing thissince it 
comes from X500
DN comparison rule for example.

> Provide appropriate dumps as examples and add a note that different implementations do the string translation differently, so you MUST do<what Tim said>.
>    
Which is also the case in 5280, just not in the normative part.
> I guess I'd add a second note that if string compares are done, then the implementor MUST verify that the translation behaves consistently AND properly handles the equivalence of A=V1+B=V2 multi-va…
Well, that's not what I am asking for.

Peter

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 22 Jun 2010 18:25:10 +0200

On 10-06-21 10:28 PM, "David A. Cooper" <[email-masked]> wrote:

> DN, and so the DER encoding of 1) and 2) would be the same.

I don't think this is correct.

Unless DER specifies which of commonName and serialNumber that must come
first in the set, the order of the bits on the wire will differ in the two
cases, and thus the hash of the tbs certificate.

Or what am I missing?

/Stefan

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 22 Jun 2010 09:56:45 -0700

> cases, and thus the hash of the tbs certificate.

Since this is DER, not BER we're discussing, I think that is specified, isn't it?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 22 Jun 2010 13:11:27 -0400

On 1 and 2 CN and SN are part of the same RDN and hence they get encoded
as a set and ordered and hence come out the same.

> Stefan Santesson
> Sent: Tuesday, June 22, 2010 12:25 PM
> To: David A. Cooper; Andrea Caccia
> Cc: [email-masked]'

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 22 Jun 2010 19:11:56 +0200

> Since this is DER, not BER we're discussing, I think that is specified, isn't it?

I think Stefan is right.  DER only specifies ASN.1 objects and does
not sort OIDs, Names, Integers etc.

Anders

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 22 Jun 2010 13:31:05 -0400

An RDN is of type:

    RelativeDistinguishedName ::=
      SET SIZE (1..MAX) OF AttributeTypeAndValue

The DER encoding of SET is covered by clause 11.6 of X.690, which 
specifies restrictions on BER employed by both CER and DER:

       The encodings of the component values of a set-of value
       shall appear in ascending order, the encodings being compared
       as octet strings with the shorter components being padded at
       their trailing end with 0-octets.

In BER the values may be encoded in any order.

Dave

On 06/22/2010 01:11 PM, Anders Rundgren wrote:
>>> On 10-06-21 10:28 PM, "David A. Cooper"<[email-masked]>  wrote:
>>>
>>>

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 22 Jun 2010 13:34:08 -0400

DER does specify sorting order, otherwise the name Distinguished would
be a misnomer.  The notation "cn=End Entity+serialNumber=Some ID" is a
relative distinguished name defined in X.501 as a SET OF:

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndDistinguishedValue

X.690 (BER,DER,and CER) says:
--------
11.6 Set-of components
The encodings of the component values of a set-of value shall appear in
ascending order, the encodings being compared as octet strings with the
shorter components being padded at their trailing end with 0-octets.
NOTE - The padding octets are for comparison purposes only and do not
appear in the encodings.
--------

So the DER encoding of that RDN is the same regardless of which LDAP
string representation is used, and the recipient of the DER encoding may
produce either string representation (since it is defined as a SET OF,
i.e., a list for which ordering is not significant).   If an
order-preserving String->DER->String transmission property were desired,
RDN would have had to have been defined as a SEQUENCE OF, not a SET OF.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Rundgren
Sent: Tuesday, June 22, 2010 1:12 PM
To: Henry B. Hotz
Cc: Stefan Santesson; [email-masked]'
Subject: Re: [pkix] errata request for RFC 5280

Anders

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 22 Jun 2010 10:51:56 -0700

> cases, and thus the hash of the tbs certificate.

A DER encoder has to sort the SET OF components, so the encoding
is always unique:

   From X.690 section 11 (Restrictions on BER employed by both
     CER and DER), part 11.6 (Set-of components):

     The encodings of the component values of a set-of value
     shall appear in ascending order, the encodings being
     compared as octet strings with the shorter components
     being padded at their trailing end with 0-octets.

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 22 Jun 2010 19:56:48 +0200

Interesting,

I just remember defining the DN comparison algorithm at Microsoft, assuming
that attributes in a set could appear in any order.

For clarity, what is meant by ascending order? Is that OID wise, length wise
or alphabetically (by attribute content) or what?

/Stefan

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Tue, 22 Jun 2010 14:12:32 -0400

>NOTE - The padding octets are for comparison purposes only and do not

     Does this mean the members of the SET are to be ordered according to 
their complete tag-length-value encoding or according to just their value 
encoding?  I read it as the former.

Charlie Gardiner

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 22 Jun 2010 20:14:40 +0200

Thanx David,
There is apparently always something new to learn when it comes to PKI :-)
Anders

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 22 Jun 2010 16:07:49 -0400

Charlie,

Although X.690 does not say so explicitly, "the encodings" in 11.6
appears (to me) to refer to the full tag-length-value encodings of the
component values.  This would be somewhat consistent with the encoding
for SET components, which explicitly are sorted by tag:

--------
10.3 Set components
The encodings of the component values of a set value shall appear in an
order determined by their tags as specified in 8.6 of ITU-T Rec. X.680 |
ISO/IEC 8824-1.
--------

This surprising rule led to my new piece of knowledge for today: a set
cannot have more than one component with the same tag, as mind-numbingly
described in X.680:

26 Notation for set types
26.1 The notation for defining a set type (see 3.6.64) from other types
shall be the "SetType":
SetType ::=
SET "{" "}"
| SET "{" ExtensionAndException OptionalExtensionMarker "}"
| SET "{" ComponentTypeLists "}"

26.3 The "ComponentType" types in a set type shall all have different
tags (see clause 30). The tag of each new "ComponentType" added to the
"ExtensionAdditions" shall be canonically greater (see 8.6) than those
of the other components in the "ExtensionAdditions".
NOTE - Where the "TagDefault" for the module in which this notation
appears is AUTOMATIC TAGS, this is achieved regardless of the actual
"ComponentType"s, as a result of the application of 24.7. (See also
48.7.)

Dave

-----Original Message-----
From: Charles W. Gardiner [mailto:[email-masked]] 

     Does this mean the members of the SET are to be ordered according
to 
their complete tag-length-value encoding or according to just their
value 
encoding?  I read it as the former.

Charlie Gardiner

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 22 Jun 2010 19:39:41 +0200

> not sort OIDs, Names, Integers etc.
No, SET OFs are sorted in ascending lexicographic order in order
to obtain *THE* DISTINGUISHED encoding.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 22 Jun 2010 19:26:36 +0200

> as a set and ordered and hence come out the same.
indeed.

DER specifies that the data in are ordered before encoded,
which comes first depends on the lexicographic order of the
sequence, which depends on the length of the sequence etc.

The order depends in most cases on the length of the two
component values.