Subject: [certid] DC should be MUST NOT

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2010 17:12:51 -0700

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

This should be a MUST NOT. And the reason for the prohibition is not "DNS-ID can be used instead", but rather "this is insecure because you can interpret the series of RDNs incorrectly".

--Paul Hoffman, Director
--VPN Consortium

---

From: Bruno Harbulot <[email-masked]>
Date: Sat, 12 Jun 2010 12:01:41 +0100

On 12/06/2010 01:12, Paul Hoffman wrote:
>>        example)<dc=www,dc=example,dc=com>  could be used to represent

On this topic in 2.2.5 and 2.2.6, as Peter Sylvester and I said earlier 
in [1] and [2], I don't think using the word 'represent' is right here.

Currently, certificates that have been emitted with the aim that tools 
will verify them according to RFC 2818 and that have a subject 
alternative name, what's in the subject distinguished name (including 
CN) is more or less decorative (with respect to the validation of the 
identity of the server).

In this case, CN=host.name is still quite convenient to have, for humans 
to be able to sort their certificates. Maybe it's just me, but I keep my 
backups of my server certificates in tools such as OSX keychains, 
security stores in the browser or PKCS#12 files. The tools associated 
with them tend not to display anything about the subject alternative 
name in their listings (in terms of user interface) and I guess that's 
not going to change any time soon. (I guess larger systems could also 
use some sort of LDAP browser for example, in a similar way.)
CN=host.name there is convenient, and it doesn't really get in the way 
of checking the identity of the remote server by an actual client when 
there's a subject alt. name (so long as the rules specify to ignore CN 
when there is an alt. name).

For this reason, I'm not sure why you'd want to forbid CN=host.name 
(whatever its RDN position is) in such a certificate.

The problem with the way I understand 'represent' in this context, is 
that you don't really know whether the CA put the CN in the subject DN 
as an indication (after all, it's a "common name") or with the intent it 
would be used by clients for verification.

Which one of these would be OK?

1. Subject DN    :  C=UK,CN=the host name is host.name,E=[email-masked]
    SubjectAltName:  DNS:host.name

    Here, the certificate doesn't "represent" the host name in the CN 
(it's another string instead)

2. Subject DN    :  C=UK,CN=host.name,E=[email-masked]
    SubjectAltName:  DNS:host.name

    Here, the certificate "represents" the host name. Does it really, or 
is it just an indication as above?

The structure of the subject DNs tend to follow some nomenclature 
internal to the CA. I'm not sure this specification should interfere 
with that when the subject DN is made somehow irrelevant by the presence 
of a subject alternative name.

Best wishes,

Bruno.

[1] http://www.ietf.org/mail-archive/web/certid/current/msg00091.html
[2] http://www.ietf.org/mail-archive/web/certid/current/msg00052.html

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 16:14:58 -0600

On 6/11/10 6:12 PM, Paul Hoffman wrote:
>> 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.
> 
> This should be a MUST NOT. And the reason for the prohibition is not
> "DNS-ID can be used instead", but rather "this is insecure because
> you can interpret the series of RDNs incorrectly".

In version -05 we had the following text:

   Domain Components (DCs) are unordered.  Therefore the following two
   sets of DCs would be equivalent:

   dc=com, dc=example, dc=cn

   dc=cn, dc=example, dc=com

   Because com.example.cn is presumably different from cn.example.com,
   representing or verifying an application server's DNS domain name
   based on domain components would open a serious security hole.  As a
   result, certificate issuers and application clients MUST NOT use DCs.

Someone objected that in fact domain components are not unordered, only
that they can be misinterpreted (as everything else can, see ongoing
discussion of RDNs and AVAs). Therefore we pulled out the quoted text.

Corrections are welcome.

Peter

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

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 15:19:35 +0200 (MEST)

> discussion of RDNs and AVAs). Therefore we pulled out the quoted text.

I'm sorry, but this example is completely bogus.

* If you look at the examples of DC= usage in rfc-5280, they contain
  only >>domain<< names.  There is never a mentioning of a hostname,
  and therefore the server endpoint identification does not apply. 

* Some of the examples in rfc-5280 clearly combine DC= componentes
  with a CN= of a regular user !  It would be a terribly bad idea
  to newly introduce a concept of matching server endpoint identities
  that were supposed to be used for informational purposes in regular
  user certificates.

I would really appreciate a "MUST not use DC-ID for server endpoint
identification", which also happens to be the current practice and
what had previously been specified.  rfc-2818 doesn't mention DC= at all.

-Martin

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 30 Jun 2010 10:30:42 -0400

> what had previously been specified.  rfc-2818 doesn't mention DC= at all.

+1

The last thing we need is *another* way to do what existing methods already
address.

-- Scott

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Jun 2010 08:53:35 -0600

> The last thing we need is *another* way to do what existing methods already

That seems to be the consensus here, and I concur. IMHO we don't even
necessarily need to say anything about why we're prohibiting DC=, given
that we're working to document best current practices and there's not
even a current practice (let alone a best one) to use DC=.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Jun 2010 08:08:05 -0700

>The last thing we need is *another* way to do what existing methods already

Another +1

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 17:21:08 +0200 (MEST)

>    result, certificate issuers and application clients MUST NOT use DCs.

Slightly OT:
adding DC= AVAs to a DName would be fairly unreasonable if they did _not_
have a defined order.  I assume that the order is as much defined as it is
for the regular "hierarchical directory tree".

Although my PKIX & LDAP exposure is at the homeopathic level, I assume
the idea of the DC= components could be to establish something like
a hierarchical LDAP directory model based on DNS rather than assuming
a single global X.500 directory hierarchy and full-fledged DAP.

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jun 2010 17:58:25 +0200

>> The last thing we need is *another* way to do what existing methods already
+1,  RFC 5280 already "warns"  about that.

    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.