Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

From: Russ Housley <[email-masked]>
Date: Fri, 05 Oct 2007 10:10:31 -0400

It seems to me that this is a trust anchor configuration concern.  If 
two CAs adopt the same name and a user accepts both of these CAs as 
trust anchors, then there could be a problem.  Just don't do it.

RFC 3280bis says:

    While X.509 mandates that names be unambiguous, there is a risk that
    two unrelated authorities will issue certificates and/or CRLs under
    the same issuer name.  As a means of reducing problems and security
    issues related to issuer name collisions, CA and CRL issuer names
    SHOULD be formed in a way that reduces the likelihood of name
    collisions.  Implementers should take into account the possible
    existence of multiple unrelated CAs and CRL issuers with the same
    name.  At a minimum, implementations validating CRLs MUST ensure that
    the certification path of a certificate and the CRL issuer
    certification path used to validate the certificate terminate at the
    same trust anchor.

Russ

At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:

>Title: Liaison to IETF on the resolution of DR320
>Submission Date: 2007-10-05
>URL of the IETF Web page: 
>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>Please reply by 2008-03-01
>
>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
><[email-masked]>)
>Cc: Herbert Bertine <[email-masked]>
><[email-masked]>
><[email-masked]>
><[email-masked]>
>Reponse Contact: Xiaoya YANG <[email-masked]>
><[email-masked]>
>Technical Contact: <[email-masked]>
><[email-masked]>
>Purpose: For action
>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>rejected Defect Report 320 
>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>AFNOR.  This DR advanced an argument that Distinguished Names may 
>not be unique and as such, the DN of the Certificate User may not be unique.
>The directory group believes that Distinguished Name values must be 
>unique and unambiguously identify a single entity, hence the use of 
>the term Distinguished.
>The DR states “the DN of the issuer name cannot be guaranteed to 
>be unique”.  X.509 takes its definition of DN from X.501.  Clause 
>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>clause states A name shall be unambiguous, that is, denotes just one object.
>Clause 9 goes on to state: It is the responsibility of the relevant 
>naming authority for an entry to ensure that this is so by 
>appropriately assigning distinguished attribute values.  Allocation 
>of RDNs is considered an administrative undertaking that may or may 
>not require some negotiation between involved organizations or 
>administrations.  This Directory Specification does not provide such 
>a negotiation mechanism, and makes no assumption as to how it is performed.
>The standard takes an axiomatic view of the concept that a 
>distinguished name unambiguously identifies a single entity.  Things 
>break if two entities identify themselves using the same name.  We 
>don't let two entities have the same domain name or the same email 
>address.  Why? - because things wouldn't work.
>The directory group does not accept the DR’s basic argument.  We 
>believe that if two entities present the same name and a CA issues a 
>certificate to each, that CA made a mistake - not a naming authority 
>mistake, since a CA is not an naming authority (although one entity 
>can be both), but an entity to key binding mistake that leads to 
>confusion and even worse, a security risk.
>We believe that if two entities claim the same name as top level 
>CAs, there is a political/procedural breakdown much like the domain 
>ownership arguments we have seen.  No one argues that the Internet 
>protocols should be modified to solve that problem.  The conflict is 
>resolved and one entity is assigned the name.  The group believes 
>that this is the only reasonable solution for Distinguished 
>Naming.  One votes for the CA of choice by configuring it as an anchor.
>One of the participants in the directory meeting stated that 
>Certification Authorities are being deployed with names not acquired 
>from naming authorities but with names arbitrarily chosen assuming 
>that no other CA is or will be operating under that name.  That 
>participant further stated that the IETF provides no guidelines on 
>ensuring that the names of CAs are unambiguous.
>The directory group requests the IETF PKIX group to comment on this 
>statement.  If the statement is correct, we ask the IETF to consider 
>putting a mechanism in place to prevent conflict, e.g. a list of 
>existing CA names that deployers of new CAs could check for naming conflicts.
>Attachment(s):
>No document has been attached

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Oct 2007 18:25:02 -0400

The ITU statement says the following:

>>Certification Authorities are being deployed with names not 
>>acquired from naming authorities but with names arbitrarily chosen 
>>assuming that no other CA is or will be operating under that name.

That is, of course, true. There is no central repository for CA names 
because there is no central authority for CAs.

>>That participant further stated that the IETF provides no 
>>guidelines on ensuring that the names of CAs are unambiguous.

That is true.

>>statement.

Should we make a consensus call on "that is true"?

>>If the statement is correct, we ask the IETF to consider putting a 
>>mechanism in place to prevent conflict, e.g. a list of existing CA 
>>names that deployers of new CAs could check for naming conflicts.

Words fail me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 9 Oct 2007 17:47:04 -0700

All of these statements are true.

Words fail me is as fine a response to that as any...

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Hoffman [[email-masked]]
Sent: Tuesday, October 09, 2007 3:25 PM
To: Russ Housley; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"

That is true.

Words fail me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tom Gindin <[email-masked]>
Date: Fri, 19 Oct 2007 12:37:41 -0400

I know this response is a little late, but the main reason that 
there is no central repository for CA names is that there is no world-wide 
directory using X.500 names.  For reasons which have been discussed many 
times on this list, there probably never will be.  Of course,  the IETF 
knows of an existing registry which could be used to avoid conflicts 
between CA names.
        How about the following wording: "Certificate Authorities SHOULD 
NOT use a value in the Organization or Common Name attribute of their 
Distinguished Name which is syntactically legal as a dNSName (i.e. an IA5 
string containing one or more periods but no spaces) unless they are 
operated by an organization which has registered the domain name 
controlling that dNSName.  Certificate Authorities wishing to ensure a 
globally unique issuer name MAY use an IA5 FQDN controlled by their 
organization in either the Organization or the Common Name attribute." 
Does anybody want to add Organizational Unit into the mix, and possibly 
even make it a SHOULD for newly allocated CA's?
        Given my unfamiliarity with non-alphabetic scripts, I hesitate to 
discuss internationalized DNS names in this connection unless Punycode is 
relevant.  However, even without considering DR 320, using somebody else's 
domain name as your CN or O attribute is misleading.

                Tom Gindin

P.S. -  The opinions above are mine, and not necessarily those of my 
employer

Ryan Hurst <[email-masked]> 
Sent by: [email-masked]
10/09/2007 08:47 PM

To
Paul Hoffman <[email-masked]>, Russ Housley <[email-masked]>, 
"[email-masked]" <[email-masked]>
cc

Subject
RE: New Liaison Statement, "Liaison to IETF on the resolution   of  DR320"

________________________________________
From: [email-masked] [[email-masked]] On 
Behalf Of Paul Hoffman [[email-masked]]
Sent: Tuesday, October 09, 2007 3:25 PM
To: Russ Housley; [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of 
DR320"

That is true.

Words fail me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Oct 2007 10:21:22 -0700

At 12:37 PM -0400 10/19/07, Tom Gindin wrote:
>directory using X.500 names.

While the latter is obviously true, it is not the "main reason". The 
"main reason" is that many (most?) CAs could get no real value out of 
a "world-wide directory using X.500 names". For example, when an 
organization becomes a CA by making its own trust anchor for internal 
use, having to register in a "world-wide directory" is  a hindrance, 
not a feature.

>For reasons which have been discussed many
>times on this list, there probably never will be.

"Probably" may be understating the likelihood.

>Of course,  the IETF

We do?

>organization in either the Organization or the Common Name attribute."

This might be appropriate in an ITU document, but is it really 
appropriate for a standards-track IETF document? In specific, the 
latter makes it sound like using your domain name is safe. Might be, 
might not be.

>even make it a SHOULD for newly allocated CA's?

I don't see how this would help. If you look at the OUs in 
IssuerNames of certificates flying around the net, you can see that 
few people understand OUs,

>domain name as your CN or O attribute is misleading.

True, but I do not think that it is the place of IETF documents to 
say what is or is not "misleading".

--Paul Hoffman, Director
--VPN Consortium

---

From: Steven Legg <[email-masked]>
Date: Mon, 22 Oct 2007 11:51:27 +1000

> organization in either the Organization or the Common Name attribute."

... or use the dc naming attribute defined in RFC 4519.

Regards,
Steven