Subject: [certid] Domain Components

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

Version -05 of draft-saintandre-tls-server-id-check has some warning
text about Domain Components (DCs). However, the more I delve the matter
the less I think that we need to warn people away from using DCs from a
security perspective. The problem with them would arise from confusion
about the order of DCs based on the string representation, however that
kind of confusion is possible for any RDNs and is not limited to DCs (so
follow the DER order, not the string order). There might be other
reasons to discourage DCs, but so far I have not heard them, so I'm
inclined to remove the warnings from -06.

Do speak up if you're concerned about this proposal.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2010 15:53:48 -0700

At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote:
>Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020609010501090708040406"
>

Finally decloaking after being off this topic for a while.

I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. For example, think about  a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Jun 2010 07:47:20 -0700

At 6:56 PM -0700 6/11/10, Henry B. Hotz wrote:
>On Jun 11, 2010, at 3:53 PM, Paul Hoffman wrote:
>
>But is the problem unique to DC's?

To the best of my knowledge, yes. It is the "component" part of DC that makes them susceptible to "guess the ordering". All other relevant PKIX identifier fields are the full identifier.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 19 Jun 2010 11:58:00 +0100

Hi Paul,

Paul Hoffman wrote:

>I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions.
>
>For example, think about  a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains.
>  
>
I personally I don't care if DCs are allowed or not by this document. 
But if DCs are to be prohibited in this document, I want to make sure 
that the document gives the right reason for that.

The order of RDNs in a DN is fixed. So you are saying that there are 
buggy implementations (and maybe most of them are buggy) which don't 
read RDNs in the correct order, that is why we need to prohibit use of 
DCs in subjectName?

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jun 2010 07:01:26 -0700

At 11:58 AM +0100 6/19/10, Alexey Melnikov wrote:
>I personally I don't care if DCs are allowed or not by this document. But if DCs are to be prohibited in this document, I want to make sure that the document gives the right reason for that.
>
>The order of RDNs in a DN is fixed. So you are saying that there are buggy implementations (and maybe most of them are buggy) which don't read RDNs in the correct order, that is why we need to prohibit use of DCs in subjectName?

No, I'm saying that the order in which you are supposed to take the DCs has historically been unclear. "Most significant" means different things to different people.

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 19 Jun 2010 13:06:28 +0200

> read RDNs in the correct order, that is why we need to prohibit use of 
In addition, RFC 5280 says:

    In addition, implementations of this specification MUST be prepared
    to receive the domainComponent attribute, as defined in [RFC4519].
    The Domain Name System (DNS) provides a hierarchical resource
    labeling system.  This attribute provides a convenient mechanism for
    organizations that wish to use DNs that parallel their DNS names.
    This is not a replacement for the dNSName component of the
    alternative name extensions.  Implementations are not required to
    convert such names into DNS names.  The syntax and associated OID for
    this attribute type are provided in the ASN.1 modules in Appendix A.
    Rules for encoding internationalized domain names for use with the
    domainComponent attribute type are specified in Section 7.3.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 19 Jun 2010 15:24:11 +0100

>No, I'm saying that the order in which you are supposed to take the DCs has historically been unclear. "Most significant" means different things to different people.
I probably sound like a broken record, but the order is very clear for 
LDAP. I don't see why is this going to be different for X.509 certificates.

---

From: Michael Ströder <[email-masked]>
Date: Sat, 19 Jun 2010 16:42:03 +0200

Alexey Melnikov wrote:
> Paul Hoffman wrote:
>> No, I'm saying that the order in which you are supposed to take the
>> DCs has historically been unclear. "Most significant" means different
>> things to different people.
>>

Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500
names as well.

Ciao, Michael.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jun 2010 07:42:25 -0700

At 3:24 PM +0100 6/19/10, Alexey Melnikov wrote:
>I probably sound like a broken record, but the order is very clear for LDAP. I don't see why is this going to be different for X.509 certificates.

If you feel that way, fine. We have historically seen deployed PKIX implementations that got the order wrong because they had no certs to test with. I do not hold it against someone to get the order wrong, particularly because all of the text examples in RFC 5280 say "dc=example,dc=com".

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Jun 2010 07:56:06 -0700

>Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500

...and you think that all (or even typical) PKIX implementers read either of those documents?

---

From: Peter Sylvester <[email-masked]>
Date: Sat, 19 Jun 2010 20:34:59 +0200

> ...and you think that all (or even typical) PKIX implementers read either of those documents?
And there might be a chance that this gets worse with RFCs
full of unclear justifications. The order in domain components
is as unclear as the order in DNs, i.e. the same confusion can
occur IMO due to the two different string representions.
(openssl vs ldap)
There are two ways, I have seen a real CA having it DN
starting wit CN and ending with C, the whole in a certificate
issued from a Research Network PKI. Was rather simple to explain
and corrected.

Examples in various RFCs mentionned also contain CN. If (and
that might not be clear)  CN is regarded as more significant,
then the order of DCs is sufficiently clear IMO. I also wonder if
someone who understands the hierarchy of RDNs would
consider that the hierarchy in the DC sequence is the other
way around.  It is more likely that one doesn't think about
any order at all in name components (and implement
names with hash tables) which may be a reasonable
concept with named components.

With the text concerning DCs in RFC 5280 that a CA cannot
assume that a relying party is able to reconstruct a DNS name
from DC components, but the text does not exclude this, thus
one can assume that it is constructed correctly if present.

having said this, I agree with Alexey when he says (in particular
I like the many reasons for the first sentence).

Peter

---

From: Michael Ströder <[email-masked]>
Date: Mon, 21 Jun 2010 10:27:27 +0200

Paul Hoffman wrote:
> particularly because all of the text examples in RFC 5280 say
> "dc=example,dc=com".

And what's wrong with that example?
RFC 5280 lists RFC 4514 as informative reference which I read as DNs are in
examples are .

Ciao, Michael.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Jun 2010 10:56:39 +0200

> RFC 5280 lists RFC 4514 as informative reference which I read as DNs are in
The citation is taken out of context, all examples also include cn like in:

Appendix C.1 contains an annotated hex dump of a "self-signed"
    certificate issued by a CA whose distinguished name is
    cn=Example CA,dc=example,dc=com

and they reference ldap in all parts except appendix C.1
In C.1 one can read the encoding of that textual representation.

   31   67:     SEQUENCE {
   33   19:       SET {
   35   17:         SEQUENCE {
   37   10:           OBJECT IDENTIFIER
          :             domainComponent (0 9 2342 19200300 100 1 25)
   49    3:           IA5String 'com'
          :           }
          :         }
   54   23:       SET {
   56   21:         SEQUENCE {
   58   10:           OBJECT IDENTIFIER
          :             domainComponent (0 9 2342 19200300 100 1 25)
   70    7:           IA5String 'example'
          :           }
          :         }
   79   19:       SET {
   81   17:         SEQUENCE {
   83    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
   88   10:           PrintableString 'Example CA'
          :           }
          :         }
          :       }

/PS

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Jun 2010 11:39:30 +0200

2.2 says

   5.  The certificate SHOULD NOT represent the server's fully-qualified
        DNS domain name in a Relative Distinguished Name (RDN) of type
        Common Name (CN) (see [LDAP-SCHEMA]), even though we recognize
        that many deployed clients still check for this legacy identifier
        configuration within certificate subjectName.  However, if this
        legacy identifer configuration is employed, then the server's
        fully-qualified 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.  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.

The second half is aprt of a redefintion of CN-ID

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

I think one should say exactly the opposite:

5. The certificate SHOULD represent the server's fully-qualified
     DNS domain name in exactly one CN-ID as the last RDN in the
     subject DN.
     The subject DN SHOULD NOT have more than one CN ava.

And in the following

   6.  The certificate SHOULD NOT represent the server's fully-qualified
        DNS domain name by means of a DC-ID, i.e., a series of Domain
        Component (DC) attributes in the certificate subject, with one
        RDN per domain label and one DC in each RDN.  Although (for
        example)<dc=www,dc=example,dc=com>  could be used to represent
        the DNS domain name "www.example.com", given the fact that the
        DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED.

There is no reason to reference DNS-ID here.

6. If present in a DN, a sequence of DCs SHOULD be a DC-ID.

Peter

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Jun 2010 08:15:04 -0700

>  88   10:           PrintableString 'Example CA'

Exactly. Someone reading the *text* of RFC 5280 would see the components in left-to-right order; only those who read the non-normative dumps would see that they actually appear in the certificate in the correct right-to-left order.

No one would ever make the mistake of only reading the normative text, of course...

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Jun 2010 19:12:52 +0200

> Exactly. Someone reading the *text* of RFC 5280 would see the components in left-to-right order; only those who read the non-normative dumps would see that they actually appear in the certificate i…
Yes.
> No one would ever make the mistake of only reading the normative text, of course...
Or write RFCs with ambiguous normative part which cannot be understood
with the non-normative part. :-)
> --VPN Consortium
As I said in a previous message,  the pb also occurs in a string form
like   cn=Paul, O=VPN Consortium

I think one might want enhance the normative part of RFC 5280:

    The Name describes a hierarchical name composed of attributes, such
    as country name, and corresponding values, such as US.  The type of
    the component AttributeValue is determined by the AttributeType; in
    general it will be a DirectoryString.

without other texts of X5xx this is also ambiguous. It doesn't say
how the hierarchy is encoded, etc for name constraints, what
is a subtree (prefix or suffix)?  I may have overlooked something?

have fun

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Jun 2010 10:25:16 -0700

>like   cn=Paul, O=VPN Consortium

Quite true.

>is a subtree (prefix or suffix)?  I may have overlooked something?

You have overlooked the fact that this effort is to create a new document, not to update RFC 5280, which the PKIX group insists is readable enough. I am well-known for disagreeing, and that is why I think that this new document allowing constructs that are known security problems is a bad idea.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Ströder <[email-masked]>
Date: Mon, 21 Jun 2010 19:52:48 +0200

> ...and you think that all (or even typical) PKIX implementers read either

Some of them do.

If you dig in mailing list archives you will find that I know enough about
deficiencies of real-world software. And I tracked down quite a few bugs in
software of "major" PKI vendors some of them related to DN (string) handling.

But what does that tell us? To give up writing or referencing RFCs?

Ciao, Michael.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Jun 2010 11:10:47 -0700

>But what does that tell us? To give up writing or referencing RFCs?

It tells us that, when there are multiple ways to do things, and some of those ways are known to be insecure due to repeated poor implementations, we can say "don't do that" for the bad ways.

---

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

> You have overlooked the fact that this effort is to create a new document, not to update RFC 5280, which the PKIX group insists is readable enough. I am well-known for disagreeing, and that is why…
I didn't not overlook that this effort is to create a new doc. With what 
authority do
you say that what the PKIX group "insists"?

Indeed, it might be that you have a server  "net.com" and another "com.net"
ah well, the real problem is between Serbia and the UK computer science
departments. Fortunately we have no top level domain www.

I am not saying at all that one should allow an http client to accept DCs
if neither DNS-ID is not present (and no CN-ID). Rather the contrary.

The new document is destined to CAs that fill DNs, and for RPs that 
think about it.
If both are reminded about the order defined by the X.500 base 
standards, this
is an enhancement. Talking about DCs does not allow anything new that isn't
allowed today. If this text "prohibits" the use of DCs in DNs, then RFC 
5280 becomes
somewhat funny because it uses them as examples.

Would an answer to Alexey be:  DCs MUST not be used since RFC 5280 does 
not define the
order of the encoding of the hierarchy in the normative part of the 
text. ???

BTW: Should one speak about jurisdiction and country of jurisdiction 
attributes?

---

From: Michael Ströder <[email-masked]>
Date: Mon, 21 Jun 2010 23:02:07 +0200

Paul Hoffman wrote:
> It tells us that, when there are multiple ways to do things, and some of
> those ways are known to be insecure due to repeated poor implementations,
> we can say "don't do that" for the bad ways.

That's fine for me too.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 21 Jun 2010 23:04:13 +0200

>> we can say "don't do that" for the bad ways.

But to make that more clear in this context: The draft should not discourage
completely using DCs in the subject-DN. It should only recommend not to encode
the server's hostname in the DCs.

Ciao, Michael.

---

From: Bruno Harbulot <[email-masked]>
Date: Mon, 21 Jun 2010 23:19:37 +0100

> the server's hostname in the DCs.

I think the problem with that approach is the same as the use of the 
word "represent" in a couple of paragraphs (as mentioned earlier on this 
list): if you get some DCs (or CN for that matter), how do you know 
whether or not they were meant to "represent" the hostname or something 
else?
If DCs are to be used in some but not all cases to convey the hostname 
to check against, then there either needs a way to disambiguate which 
case is which.

In my opinion, I would split this in two cases:
- If there is a subject alt. name.: the Subject DN can be more or less 
ignored (it would just be a convenience).
- If there isn't: the expectations on the DCs (or CN) in the Subject DN 
have to be strict (i.e. a MUST). If we get something like "SHOULD NOT 
encode the server hostname in the DCs", then the door is open to 
ambiguity, and I think that's where the problems will come for 
determining whether or not the certificate matches the server.

(I think that would also be compatible with the existing implementations 
of RFC 2818.)

Best wishes,

Bruno.

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Jun 2010 23:31:35 +0200 (MEST)

> But what does that tell us? To give up writing or referencing RFCs?

Since the document under discussion is supposed to become a
"Best current practice" document, I'm really wondering which of the
existing implementations actually implement server endpoint matching
based on DC components of a certificate subject name?

I would assume that matching to more than one CN= might be
more common than DC matching.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Jun 2010 03:02:43 +0200 (MEST)

> the server's hostname in the DCs.

Nope.  It is important to strongly recommend to clients to _NOT_
check the server endpoint identity based on DC components, that is
the important issue.  There is no known sensible, consistent
and reasonably safe interpretation of DC name components
as the hostname for a server endpoint.

No implementation that doesn't have such code should add it,
and existing implementations with such code should think about
removing it or disabling it by default.

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 23 Jun 2010 06:52:19 +0200

> as the hostname for a server endpoint.

encoding and checking are two different things. There are two
subchapters. It is not incoherent IMO to recommend
encode a domain if and only if DCs are used at all,
and "discourage" checking in all cases.

> No implementation that doesn't have such code should add it,
At least 'No one is required neither must be forced to add.'
is there any application that requires checking?
> removing it or disabling it by default.
Implementations don't think, well, hm, for implementors
the situation might be less clear. Implementation details
are out of scope anyway

---

From: Martin Rex <[email-masked]>
Date: Thu, 24 Jun 2010 23:03:25 +0200 (MEST)

Paul Hoffman wrote:
> 
> If you feel that way, fine. We have historically seen deployed PKIX
> implementations that got the order wrong because they had no certs
> to test with. I do not hold it against someone to get the order wrong,

You're right on the spot -- all of the DC= examples in rfc-5280 are
purely about >>domain name<<.  There is also a server mentioned
"ldap.example.com", but there is not a single example in rfc-5280
that puts a >>hostname<< into a DC component.

So why does draft-saintandre-tls-server-id-check-06
come up with the idea of performing a server endpoint identification
against a DC that includes a hostname?
Rfc-2818 never suggested this!

-Martin