Subject: Re: [lamps] I-D Action: draft-ietf-lamps-samples-03.txt

From: "David A. Cooper" <[email-masked]>
Date: Mon, 17 May 2021 15:46:57 -0400

On 5/14/21 7:34pm, Daniel Kahn Gillmor wrote:
>  - Add organization and organizational unit to all certificates.

I ran the certificates in draft-ietf-lamps-samples-03 through 
https://github.com/dcooper16/cert_check, and it did not find any 
problems. However, I noticed that the attributes in the issuer and 
subject fields of the certificates are encoded in the reverse order of 
what one would expect. For example, the name of the RSA CA is encoded as:

     SEQUENCE {
       SET {
         SEQUENCE {
           OBJECT IDENTIFIER commonName (2 5 4 3)
           PrintableString 'Sample LAMPS RSA Certification Authority'
           }
         }
       SET {
         SEQUENCE {
           OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
           PrintableString 'LAMPS WG'
           }
         }
       SET {
         SEQUENCE {
           OBJECT IDENTIFIER organizationName (2 5 4 10)
           PrintableString 'IETF'
           }
         }
       }

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 May 2021 16:24:51 -0400

DKG,

Confusion in ordering may arise because LDAP display of DN is supposed to be
in the reverse order of bits on wire.

David's suggestion is correct.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Monday, May 17, 2021 3:47 PM
To: Daniel Kahn Gillmor <[email-masked]>
Cc: [email-masked]
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-samples-03.txt

I ran the certificates in draft-ietf-lamps-samples-03 through
https://github.com/dcooper16/cert_check, and it did not find any problems.
However, I noticed that the attributes in the issuer and subject fields of
the certificates are encoded in the reverse order of what one would expect.
For example, the name of the RSA CA is encoded as:

     SEQUENCE {
       SET {
         SEQUENCE {

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 17 May 2021 23:46:43 -0400

On Mon 2021-05-17 15:46:57 -0400, David A. Cooper wrote:

> what one would expect.

Thanks for identifying this concern.  Is there some documentation
someplace that indicates the expected ordering of the subject DN?

I'm a little surprised that none of the three certificate linters
identified in the discussion of the last few weeks have any such check
on DN component ordering.

     --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 00:13:21 -0400

> on DN component ordering.

Component ordering is being fixed in the CA/B Forum, although not
necessarily for ordering, but because CAs love introducing ambiguity and
security issues. So, assuming that work finishes, they will in time warn,
but that’ll be a property of referring to CA/B Forum’s profile, not 5280.

Ordering a relic of the X.500 model of hierarchical thinking, in which DNs
are ordered from least-specific to most-specific elements (e.g. RFC 1255)
and the directory was structured in such a global/universal ontology. That
model never manifested, and so it’s largely irrelevant, other than helping
legibility when stringified (RFC 4514). The main element of concern is the
processing client libraries apply. More often than not, they extract the
first or last value for a given attribute type, rather than all values, and
thus can lead to ambiguities, particularly when a profile is foolish enough
to use the DN to convey semantic information. That is, if you have multiple
CN fields, one system may consider the first, another the last, a third
system fail to parse entirely because of the multiple instances, or to
consider all of them.

Normally, this would be harmless, but if the implementation is ignoring
work such as RFC 6125 and doing foolish things like sticking domain names
in the CN fields, bad times ensue.

As it relates to this, the conventional practice of sorting the elements
based on their degree or least to most specific yields an unsurprising
string form, so is probably worth doing, mostly as a UX exercise.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 18 May 2021 06:12:20 -0400

On 5/17/21, 11:47 PM, "Spasm on behalf of Daniel Kahn Gillmor" <[email-masked] on behalf of [email-masked]> wrote:

[CW] Give a look at section 7.1 of RFC5280. This section defines comparison rules. Where these are used to enforce name constraints, asserting the common name first (or any more specific to less specific arrangement) would not work.

         --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 May 2021 13:21:28 +0000

*   Ordering a relic of the X.500 model of hierarchical thinking, in which DNs are ordered from least-specific to most-specific elements (e.g. RFC 1255) and the directory was structured in such a global/universal ontology. That model never manifested, and so it’s largely irrelevant

Doesn’t X.520 provide schema constraints on the most common RDN’s?

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 18 May 2021 09:52:10 -0400

Information about it can be found in Section 9 of X.501 
(https://www.itu.int/rec/T-REC-X.501-201610-S/en) and in Section 2.3 of 
RFC 4512.

As Ryan noted, the distinguished name (DN) is also a directory name. A 
DN consists of a sequence of relative distinguished names (RDNs), and 
each subsequence of a DN is itself a DN. Every DN needs to satisfy the 
requirement that  "A name shall be unambiguous, that is denotes just one 
object." So, the first value in the sequence needs to be unambiguous by 
itself (o=IETF), while the second one only needs to be unambiguous with 
respect to the first entry (i.e., there is only one "LAMPS WG" in the IETF).

> Doesn’t X.520 provide schema constraints on the most common RDN’s?
I found at least one example in 
https://www.itu.int/rec/T-REC-X.520-201610-S/en:

    "The  designated  organizational unit  is  understood  to  be  part 
    of  an  organization designated  by  an organizationName attribute.
    It follows that if an Organizational Unit Name attribute is used in
    a directory name, it shall be associated with an organizationName
    attribute."

So, it would be possible for a syntax checker to check for at least some 
things with respect to component ordering.

As Ryan noted, though, ordering may not be all that important if there 
is no directory associated with entities being identified in the 
certificates. What's most important is that issuer and subject names 
need to be unambiguous. The main exception to this rule, as Carl noted 
is that the RDNs in the DN need to be in a logical order in order to 
effectively be able to impose name constraints on the subject names in 
certificates. With the organization component coming first, a 
cross-certificate (or a relying party) could indicate that certificates 
will only be accepted from the IETF CA if subject name is with the 
"o=IETF" name space. With the ordering that currently appears in the 
certificates, that would not be possible, as the name constraint would 
first have to specify a common name (e.g., accept any certificates 
issued to "cn=Alice Lovelace" regardless of organization or 
organizational unit).

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 07:53:16 -0600

On Tue, May 18, 2021 at 7:21 AM Salz, Rich <[email-masked]> wrote:

>
>    - Ordering a relic of the X.500 model of hierarchical thinking, in
>    which DNs are ordered from least-specific to most-specific elements (e.g.
>    RFC 1255) and the directory was structured in such a global/universal
>    ontology. That model never manifested, and so it’s largely irrelevant
>
>
>
Not sure if I’m parsing the question correctly. RFC 5280 separately
provides the constraints for many of the AttributeTypeAndValues. These
constraints have diverged from X.5xx for some time, sometimes
unintentionally so (such as replicating the wrong size constraints), but
also intentionally so (the 3-4 discussions held on the list rejecting
synchronizing size constraints with X.5xx due to compatibility impact).

I’m not aware of X.500 setting forth a normative ontological scheme; that
was to be left up to the ITU and the directory naming authorities in
subsequent work, and even still, it largely wouldn’t matter here, for work
decoupled from The Directory. For example, I’m not aware of any
implementation that will get upset if CN occurs after O, or if the DN goes
“CN, O, CN, C, CN” except for my previous remarks about unpredictability
about how the application will expose CN and which single value it will
expose, if it only exposes one.

To Carl’s point, the only relevance to NameConstraints is simply that you
can tack on values at the end, hence the convention of less to more
specific. However, because we are and have been largely divorced from The
Directory for the past 2+ decades, the only functional impact is legibility
when stringified, as only AVAs are used.

Especially with work like
https://www.ietf.org/archive/id/draft-ietf-uta-use-san-00.html , the DN is
effectively just a “human-readable random number”; it’s only functional
purpose, when not considering The Directory, is to serve as a semi-unique
identifier for a logical CA. Even when coupled with LDAP, because the
naming ontology in LDAP is inherently local to the directory operator, it’s
no different than just being a database lookup key.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 18 May 2021 10:06:21 -0400

From: Spasm <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Date: Tuesday, May 18, 2021 at 9:53 AM
To: "Salz, Rich" <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>, "[email-masked]" <[email-masked]>, "David A. Cooper" <[email-masked]>, Daniel Kahn Gillmor <[email-masked]>
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-samples-03.txt

<snip>

To Carl’s point, the only relevance to NameConstraints is simply that you can tack on values at the end, hence the convention of less to more specific. However, because we are and have been largely divorced from The Directory for the past 2+ decades, the only functional impact is legibility when stringified, as only AVAs are used.

[CW] Regardless of how distasteful some may find them, there exist large PKIs where NameConstraints on DNs are used. That’s irrelevant, of course, to the question I was answering.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 08:20:41 -0600

On Tue, May 18, 2021 at 8:06 AM Carl Wallace <[email-masked]>
wrote:

>
>
> [CW] Regardless of how distasteful some may find them, there exist large
> PKIs where NameConstraints on DNs are used. That’s irrelevant, of course,
> to the question I was answering.
>
> Oh, for sure, I was not trying to say NameConstraints have no value, so
apologies if it read like that, that’s on me. Rather, that even when
nameConstraints are present, there are no new semantics imposed on the DN,
other than that the DNs beneath that CA contain the constrained values
first. Or, phrased differently, you simply append.

You could totally have a nameConstraint in the form “CN=Foo, OU=Bar, O=Baz”
- where the naming here goes from most to least specific, opposite of what
most might expect from convention. Nothing in the processing model would be
salty about that, and nothing would break if the final DN beneath that CA
(or a series of constrained CAs) was something like “CN=Foo, OU=Bar, O=Baz,
serialNumber=8675309, streetAddress=123 Anywhere St, postalCode=90210, C=US”

While that’s not the most legible _if_ someone is reading it is expecting
the DN to have semantic meaning or ontological clarity, it functionally
works with nameConstraints, looking up in local directories like LDAP, and
any other processing necessary.

This is why I mentioned the CABF context, earlier in the discussion of
linting; the interest here to specify rules is primarily one of legibility
if the DN is displayed to the end user, rather than being functional.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 May 2021 14:50:17 +0000

> the DN is effectively just a “human-readable random number”; it’s only functional purpose, when not considering The Directory, is to serve as a semi-unique identifier for a logical CA. Even when coupled with LDAP, because the naming ontology in LDAP is inherently local to the directory operator, it’s no different than just being a database lookup key.

That’s a very insightful way to put it, thanks!

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 18 May 2021 12:16:53 -0400

On 5/18/21 10:50 AM, Salz, Rich wrote:
>
> *>* the DN is effectively just a “human-readable random number”; it’s 
> only functional purpose, when not considering The Directory, is to 
> serve as a semi-unique identifier for a logical CA. Even when coupled 
> with LDAP, because the naming ontology in LDAP is inherently local to 
> the directory operator, it’s no different than just being a database 
> lookup key.
>
https://www.ietf.org/archive/id/draft-ietf-uta-use-san-00.html is 
"Update to Verifying TLS Server Identities with X.509 Certificates." 
While it may be the case that the subject DN doesn't have much of a 
functional purpose in TLS server certificates, the web PKI isn't the 
only use of X.509 certificates. I think it is a stretch to suggest that 
the DN is effectively just a "human-readable random number" for all uses 
of X.509 certificates.

I disagree with the suggestion that functionality works with 
nameConstraints even if the components of the DN are in the reverse 
order. Yes, the mechanics are well defined, constraints can't be 
specified in a useful way. In the example below, with name components 
appearing in the opposite of logical order, one can impose a constraint 
of the form "CN=Foo, OU=Bar, O=Baz", but one cannot impose a constraint 
of the form "OU=Bar, O=Baz" or "O=Baz". If the components were in a 
logical order (least to most specific), then a constraint could be 
applied at the appropriate level of specificity (e.g., "O=Baz" or 
"O=Baz, OU=Bar").

A nameConstraint can't just specify that "o=IETF" is permitted and have 
any certificate be accepted if "o=IETF" appears anywhere in the subject 
name. nameConstraints specify subtrees, so a constraint of "o=IETF" only 
applies to names in which the first component is "o=IETF".

The CABF doesn't apply to all uses of X.509 certificates. There are 
other use cases in which the DN does have a function purpose.

On 5/18/21 10:20 AM, Ryan Sleevi wrote:
>
>
> On Tue, May 18, 2021 at 8:06 AM Carl Wallace 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     [CW] Regardless of how distasteful some may find them, there exist
>     large PKIs where NameConstraints on DNs are used. That’s
>     irrelevant, of course, to the question I was answering.
>
> Oh, for sure, I was not trying to say NameConstraints have no value, 
> so apologies if it read like that, that’s on me. Rather, that even 
> when nameConstraints are present, there are no new semantics imposed 
> on the DN, other than that the DNs beneath that CA contain the 
> constrained values first. Or, phrased differently, you simply append.
>
> You could totally have a nameConstraint in the form “CN=Foo, OU=Bar, 
> O=Baz” - where the naming here goes from most to least specific, 
> opposite of what most might expect from convention. Nothing in the 
> processing model would be salty about that, and nothing would break if 
> the final DN beneath that CA (or a series of constrained CAs) was 
> something like “CN=Foo, OU=Bar, O=Baz, serialNumber=8675309, 
> streetAddress=123 Anywhere St, postalCode=90210, C=US”
>
> While that’s not the most legible _if_ someone is reading it is 
> expecting the DN to have semantic meaning or ontological clarity, it 
> functionally works with nameConstraints, looking up in local 
> directories like LDAP, and any other processing necessary.
>
> linting; the interest here to specify rules is primarily one of 
> legibility if the DN is displayed to the end user, rather than being 
> functional.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 13:16:49 -0400

On Tue, May 18, 2021 at 12:16 PM David A. Cooper <[email-masked]>
wrote:

> I think it is a stretch to suggest that the DN is effectively just a
> "human-readable random number" for all uses of X.509 certificates.
>

In the context of the IETF specifications, however, it's exactly that. RFC
5280 diverges from X.500 in that we don't use The Directory as the Source
of All Truth - we deliver certificates through plenty of other mechanisms,
whether they be TLS (RFC 8446), S/MIME (RFC 8551), or heck, TAMP (RFC 5934).

The sole purpose of the subject/issuer name in the X.500 model is to bind
the certificate to The Directory entry. However, nearly all uses of RFC
5280 are devoid of The Directory. Even when certificates are stored in
directories, such as LDAP, we (the IETF) don't have protocols that
normatively bind those entities such that the directory is the primary
method of lookup.

Because the ITU ontology was never adopted, that's all they function as
with respect to X.509/RFC 5280. You can even trace this through the
evolution of the RFC 5280 series itself, in which early drafts tried to
entirely omit Subject in favor of SAN, even for CAs, but ran into issues
with CRLs and the Issuer name, which is why only end-entity certificates
can omit Subject.

That's not to say that protocols may not attempt to use elements of the
Subject/Issuer name to convey relevant semantic information for
per-application purposes. For example, the work going on with ANIMA/BRSKI
is clearly borrowing from some of the TCG TPM work, such as IDevId, as does
the IETF RATS work. However, that work is not because RFC 5280 applies
special semantic meaning or ontological ordering requirements onto the DN -
it's just an easier (but far more dangerous to interoperability) way to
smuggle information about a given entity.

Put differently, for any value that can be expressed as "O=Bar", you could
equally express this as a subjectAlternativeName (via otherName) or even as
a separate extension (as a number of specifications do). The reason most
folks stick to putting it in Subject is because 1) it's easier to parse
with existing libraries and 2) it's believed nameConstraints are useful for
this, even though in practice for most specifications, they are not. The
reason I say the nameConstraints are not all that useful is because the
constraint applies to the tree, not to the AVAs, and thus you can do things
like "C=US, O=Bar" as a nameConstraint, then issue a certificate with a DN
of "C=US, O=Bar, C=CA, O=Foo". For many certificate processing libraries
and post-auth validation systems, they'll do the silly thing of saying
"C=CA, O=Foo", because they don't handle multiple AVAs being present of the
same AttributeType gracefully. This is especially true in the embedded
systems these DN-using profiles tend to target.

> nameConstraints even if the components of the DN are in the reverse order.
> Yes, the mechanics are well defined, constraints can't be specified in a
> useful way. In the example below, with name components appearing in the
> opposite of logical order, one can impose a constraint of the form "CN=Foo,
> OU=Bar, O=Baz", but one cannot impose a constraint of the form "OU=Bar,
> O=Baz" or "O=Baz". If the components were in a logical order (least to most
> specific), then a constraint could be applied at the appropriate level of
> specificity (e.g., "O=Baz" or "O=Baz, OU=Bar").
>

A nameConstraint can't just specify that "o=IETF" is permitted and have any
> certificate be accepted if "o=IETF" appears anywhere in the subject name.
> nameConstraints specify subtrees, so a constraint of "o=IETF" only applies
> to names in which the first component is "o=IETF".
>

Without wanting to misrepresent your words, it seems where we are
disagreeing is that you're attaching semantic importance to being able to
specify the ordering. That is, "O=Baz, OU=Baz" vs "OU=Baz, O=Baz" is only
relevant when those two names refer to different concrete objects - such as
nodes in The Directory. If you're not coupled to The Directory - and RFC
5280 is not - then while there is a distinction (in that these are two
uniquely different names), it's a distinction without semantic relevance.

Put differently, the importance of delegation, which is what you seem to be
highlighting by focusing on least-specific to most-specific, is only
relevant if you attach special meaning to the ordering of elements. As
certificates (devoid of The Directory) do not do that, then it's not a
general rule that you need to follow, and is instead relevant to individual
profiles that may be going above and beyond, or trying to recreate those
heady glory days of the mid-1990s.

The "need" to apply a constraint of "OU=Bar, O=Baz" only applies if you're
attaching semantic meaning to the order, which RFC 5280 doesn't, nor do
most commonly-used profiles. And even when they are used, it's largely for
the human-readable aspect "Oh, this CA belongs to Baz in the Bar division"
- rather than being functionally relevant to the underlying  protocol.

> The CABF doesn't apply to all uses of X.509 certificates. There are other
> use cases in which the DN does have a function purpose.
>
Sure, and I certainly was not trying to say CABF is somehow the gold
standard here. Indeed, my replies here have been trying to capture why we
should ignore what CABF does or doesn't do entirely, and instead focus on
what RFC 5280 itself does. RFC 5280 does not apply any meaning to the
ordering - it's the individual users and use cases.

While the DN is by convention sorted least-to-most specific, it's just
that: convention. And while for PKI enthusiasts it's a convention that is
as much subtle and enshrined as adjective order [1], and other sorting may
look weird and raise eyebrows, that's not because the words no longer make
sense in a different order, it's just that they look funny. And that's a
useful enough reason, but it's not functional, it's aesthetic.

[1] https://www.bbc.com/news/blogs-trending-37285796

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 18 May 2021 13:56:18 -0400

I have heard this mistaken belief before, that distinguished names are 
only meaningful if certificates are used in the context of a directory 
(or "The Directory"), but that simply isn't the case. I fully 
acknowledged that in many use cases, the subject name isn't really 
useful, but that doesn't apply to all uses of RFC 5280, and it has 
nothing to do with whether or not certificates are stored in a directory.

Note that Section 4.2.1.10 states that "Applications conforming to this 
profile MUST be able to process name constraints that are imposed on the 
directoryName name form," whereas you seem to imply that use of RFC 5280 
would never involve imposing name constraints on the directoryName name 
form.

It is a simple fact that the semantics of the DN name form imposes a 
meaning on the ordering of the elements. Perhaps in the use cases of 
which you are aware, that information is unnecessary, but it is wrong to 
suggest that RFC 5280 specifies that the naming of the ordering of the 
naming components has no meaning. It certainly has a meaning when it 
comes to name constraints, and directoryName is the one and only name 
form for which RFC 5280 mandates support for processing name constraints.

On 5/18/21 1:16 PM, Ryan Sleevi wrote:
>
>
> On Tue, May 18, 2021 at 12:16 PM David A. Cooper 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I think it is a stretch to suggest that the DN is effectively just
>     a "human-readable random number" for all uses of X.509 certificates.
>
>
> In the context of the IETF specifications, however, it's exactly that. 
> RFC 5280 diverges from X.500 in that we don't use The Directory as the 
> Source of All Truth - we deliver certificates through plenty of other 
> mechanisms, whether they be TLS (RFC 8446), S/MIME (RFC 8551), or 
> heck, TAMP (RFC 5934).
>
> The sole purpose of the subject/issuer name in the X.500 model is to 
> bind the certificate to The Directory entry. However, nearly all uses 
> of RFC 5280 are devoid of The Directory. Even when certificates are 
> stored in directories, such as LDAP, we (the IETF) don't have 
> protocols that normatively bind those entities such that the directory 
> is the primary method of lookup.
>
> Because the ITU ontology was never adopted, that's all they function 
> as with respect to X.509/RFC 5280. You can even trace this through the 
> evolution of the RFC 5280 series itself, in which early drafts tried 
> to entirely omit Subject in favor of SAN, even for CAs, but ran into 
> issues with CRLs and the Issuer name, which is why only end-entity 
> certificates can omit Subject.
>
> That's not to say that protocols may not attempt to use elements of 
> the Subject/Issuer name to convey relevant semantic information for 
> per-application purposes. For example, the work going on with 
> ANIMA/BRSKI is clearly borrowing from some of the TCG TPM work, such 
> as IDevId, as does the IETF RATS work. However, that work is not 
> because RFC 5280 applies special semantic meaning or ontological 
> ordering requirements onto the DN - it's just an easier (but far more 
> dangerous to interoperability) way to smuggle information about a 
> given entity.
>
> Put differently, for any value that can be expressed as "O=Bar", you 
> could equally express this as a subjectAlternativeName (via otherName) 
> or even as a separate extension (as a number of specifications do). 
> The reason most folks stick to putting it in Subject is because 1) 
> it's easier to parse with existing libraries and 2) it's believed 
> nameConstraints are useful for this, even though in practice for most 
> specifications, they are not. The reason I say the nameConstraints are 
> not all that useful is because the constraint applies to the tree, not 
> to the AVAs, and thus you can do things like "C=US, O=Bar" as a 
> nameConstraint, then issue a certificate with a DN of "C=US, O=Bar, 
> C=CA, O=Foo". For many certificate processing libraries and post-auth 
> validation systems, they'll do the silly thing of saying "C=CA, 
> O=Foo", because they don't handle multiple AVAs being present of the 
>     nameConstraints even if the components of the DN are in the
>     reverse order. Yes, the mechanics are well defined, constraints
>     can't be specified in a useful way. In the example below, with
>     name components appearing in the opposite of logical order, one
>     can impose a constraint of the form "CN=Foo, OU=Bar, O=Baz", but
>     one cannot impose a constraint of the form "OU=Bar, O=Baz" or
>     "O=Baz". If the components were in a logical order (least to most
>     specific), then a constraint could be applied at the appropriate
>     level of specificity (e.g., "O=Baz" or "O=Baz, OU=Bar").
>
>     A nameConstraint can't just specify that "o=IETF" is permitted and
>     have any certificate be accepted if "o=IETF" appears anywhere in
>     the subject name. nameConstraints specify subtrees, so a
>     constraint of "o=IETF" only applies to names in which the first
>     component is "o=IETF".
>
>
> disagreeing is that you're attaching semantic importance to being able 
> to specify the ordering. That is, "O=Baz, OU=Baz" vs "OU=Baz, O=Baz" 
> is only relevant when those two names refer to different concrete 
> objects - such as nodes in The Directory. If you're not coupled to The 
> Directory - and RFC 5280 is not - then while there is a distinction 
> (in that these are two uniquely different names), it's a distinction 
> without semantic relevance.
>
> Put differently, the importance of delegation, which is what you seem 
> to be highlighting by focusing on least-specific to most-specific, is 
> only relevant if you attach special meaning to the ordering of 
> elements. As certificates (devoid of The Directory) do not do that, 
> then it's not a general rule that you need to follow, and is instead 
> relevant to individual profiles that may be going above and beyond, or 
> trying to recreate those heady glory days of the mid-1990s.
>
> The "need" to apply a constraint of "OU=Bar, O=Baz" only applies if 
> you're attaching semantic meaning to the order, which RFC 5280 
> doesn't, nor do most commonly-used profiles. And even when they are 
> used, it's largely for the human-readable aspect "Oh, this CA belongs 
> to Baz in the Bar division" - rather than being functionally relevant 
> to the underlying  protocol.
>
>     The CABF doesn't apply to all uses of X.509 certificates. There
>     are other use cases in which the DN does have a function purpose.
>
> standard here. Indeed, my replies here have been trying to capture why 
> we should ignore what CABF does or doesn't do entirely, and instead 
> focus on what RFC 5280 itself does. RFC 5280 does not apply any 
> meaning to the ordering - it's the individual users and use cases.
>
> that: convention. And while for PKI enthusiasts it's a convention that 
> is as much subtle and enshrined as adjective order [1], and other 
> sorting may look weird and raise eyebrows, that's not because the 
> words no longer make sense in a different order, it's just that they 
> look funny. And that's a useful enough reason, but it's not 
> functional, it's aesthetic.
>
> <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bbc.com%2Fnews%2Fblogs-trending-37285796&data=04%7C01%7Cdavid.cooper%40nist.gov%7C9e8dea46a4cf4935c2d908d91a20c2dc%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637569550292986716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VxhI8CyuiDKbwnx6l2czjxP3DC5kdz58RTtzicDQgVY%3D&reserved=0>

---

From: Carl Wallace <[email-masked]>
Date: Tue, 18 May 2021 14:03:40 -0400

From: Spasm <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Date: Tuesday, May 18, 2021 at 1:16 PM
To: "David A. Cooper" <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>, "Salz, Rich" <[email-masked]>, "[email-masked]" <[email-masked]>, Daniel Kahn Gillmor <[email-masked]>
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-samples-03.txt

<snip>

 and instead focus on what RFC 5280 itself does. RFC 5280 does not apply any meaning to the ordering - it's the individual users and use cases.

[CW] In section 4.1.2.4, RFC5280 states the “Name describes a hierarchical name composed of attributes”.

<snip>

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 12:20:27 -0600

On Tue, May 18, 2021 at 12:03 PM Carl Wallace <[email-masked]>
wrote:

> <snip>
>
> and instead focus on what RFC 5280 itself does. RFC 5280 does not apply
> any meaning to the ordering - it's the individual users and use cases.
>
Sure, and that’s consistent with my previous replies, although it seems by
the snip you’ve done, that context is loss.

Yes, the directoryName is hierarchal in the abstract, but that doesn’t mean
an OU can’t contain an O, or that it must all be a child to the O.

A classic example of this can be seen in directory designs like Active
Directory, in which an OU may compromise a group for organization within
that directory, and then children within that node are Organizations that
the directory operator may do business with. That’s a perfectly fine and
valid case for something like “OU=Partners, O=Foo”.

I’m not suggesting, as your reply seems to imply, that all AVas are at the
same level even within separate RDNs, simply that there is no standard
requirement for a particular AVA to appear before or after another AVA,
except as the PKI operator wills it.

This particular thread started in the context of suggesting just that -
that fields like the CN must appear as children of other fields - but
there’s no such requirement.

While PKIs may decide to use the DN to convey semantic information, which
is the other through line of this thread, ample implementation experience,
and implementations themselves, show that this is fundamentally not
interoperable and dangerous. We might decry it as “if only folks understood
and implemented the standard”, but that’s been the case since X.500 was
first introduced, and it’s a reflection of the vast unnecessary complexity
for most use cases.

I’m not sure why it seems controversial to suggest the naming is whatever
you (the PKI designer) want it to be, simply because we don’t have a
globally assigned and managed naming scheme, or that saying such absence is
a feature, not a bug.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 18 May 2021 15:05:22 -0400

From: Ryan Sleevi <[email-masked]>
Date: Tuesday, May 18, 2021 at 2:20 PM
To: Carl Wallace <[email-masked]>
Cc: Daniel Kahn Gillmor <[email-masked]>, "David A. Cooper" <[email-masked]>, Ryan Sleevi <[email-masked]>, "Salz, Rich" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-samples-03.txt

On Tue, May 18, 2021 at 12:03 PM Carl Wallace <[email-masked]> wrote:

<snip>

<snip>

Sure, and that’s consistent with my previous replies, although it seems by the snip you’ve done, that context is loss.

[CW] The snip was to focus on the “does not apply any meaning to the ordering” assertion by noting that the spec states the Name is hierarchical. 

Yes, the directoryName is hierarchal in the abstract, but that doesn’t mean an OU can’t contain an O, or that it must all be a child to the O.

A classic example of this can be seen in directory designs like Active Directory, in which an OU may compromise a group for organization within that directory, and then children within that node are Organizations that the directory operator may do business with. That’s a perfectly fine and valid case for something like “OU=Partners, O=Foo”.

I’m not suggesting, as your reply seems to imply, that all AVas are at the same level even within separate RDNs, simply that there is no standard requirement for a particular AVA to appear before or after another AVA, except as the PKI operator wills it.

This particular thread started in the context of suggesting just that - that fields like the CN must appear as children of other fields - but there’s no such requirement.

While PKIs may decide to use the DN to convey semantic information, which is the other through line of this thread, ample implementation experience, and implementations themselves, show that this is fundamentally not interoperable and dangerous. We might decry it as “if only folks understood and implemented the standard”, but that’s been the case since X.500 was first introduced, and it’s a reflection of the vast unnecessary complexity for most use cases.

I’m not sure why it seems controversial to suggest the naming is whatever you (the PKI designer) want it to be, simply because we don’t have a globally assigned and managed naming scheme, or that saying such absence is a feature, not a bug.

[CW] I did not suggest or imply that attributes needed to be in any particular order or at the same level, feel no pain regarding the lack of “The Directory” or globally assigned and managed naming scheme, am not decrying folks who don’t understand the standard, etc. My entry into this thread was simply observing that if one elects to order attributes from most specific to least specific then name constraints may not work. That seems uncontroversial enough on its face, and possibly could even garner agreement because it references a knob that may constitute vast unnecessary complexity for most use cases.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 13:26:14 -0600

On Tue, May 18, 2021 at 1:05 PM Carl Wallace <[email-masked]>
wrote:

> [CW] <snip> My entry into this thread was simply observing that if one
> elects to order attributes from most specific to least specific then name
> constraints may not work. That seems uncontroversial enough on its face,
> and possibly could even garner agreement because it references a knob that
> may constitute vast unnecessary complexity for most use cases.
>
> But this is a chicken-and-egg statement. The order of the constraints
don’t matter unless the order of the DN matters, and the order of the DN
doesn’t matter unless the order of the constraints matter.

NameConstraints work just fine regardless of the order the PKI designer
chooses to use.

The issue is that if you choose to assign semantics to the order - such as
saying this OU in this Organization is an important distinction - then your
nameConstraints should reflect that.

If you don’t assign semantics to order, then the nameConstraints work
either way. You don’t have to assign any particular order to your AVAs for
nameConstraints to work.

To David’s point, if you want to use the DN to express a semantic
hierarchy, where names are constrained in a hierarchal scope, and the
namespace of that constraint matters (e.g. only names from/for your
organization), and you want to allow more than one level of constraints
(more than one subCA with NCs in a chain), sure, absolutely, order from
least-to-most-specific.

However, most (all?) IETF specs and protocols don’t need that, because they
use SAN, not DN, which is why I mentioned 6125 and the ongoing UTA work.
This is similar to the ports-vs-ALPN discussion happening in TLS; we’ve
since learned how to do things more securely, less ambiguously, than
originally designed. There’s no reason, for IETF specs or examples at
least, to assign any semantic meaning to the DN. That’s because we have and
use specific identifiers appropriate to the protocol, and that generally
flow from an IANA registry or relationship (domain names, IP addresses,
email addresses, URIs, SRVNames, etc)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 May 2021 17:28:57 -0400

> (more than one subCA with NCs in a chain), sure, absolutely, order from

Thanks to everyone for the close reading and nuanced arguments about
arcana on this thread.  I've gained perhaps more understanding than i
ever wanted about these tradeoffs, and am submitting patches to GnuTLS
to make the default DN ordering for the certificates and CSRs produced
by certtool to go from least-to-most-specific. [0] 

[0] https://datatracker.ietf.org/doc/draft-ietf-lamps-samples/

Summarizing this discussion as far as draft-ietf-lamps-samples goes: it
looks to me like everyone agrees that there would be no problem with any
certificate that orders the DN from least-to-most-specific.
Alternately, while a cert with other orderings in the DN *might* be
acceptable in some contexts, there are some situations where it would be
clearly counterindicated (e.g. name constraints).  So, for the purpose
of sample X.509 certificates, I'll make the DNs ordered from least to
most specific.

I'll release draft -04 shortly with that fix.

     --dkg