Subject: Re: [sidr] WG LC for draft-ietf-sidr-cp-10.txt

From: Sean Turner <[email-masked]>
Date: Tue, 07 Sep 2010 10:51:52 -0400

Sandy,

I review this document and sent my, mostly minor, comments to the 
authors.  I believe after they fix it up, it'll be ready to go.

spt

Sandra Murphy wrote:
> The authors of "Certificate Policy (CP) for the Resource PKI (RPKI)" 
> have requested a working group last call on this draft.  The draft is 
> available at http://tools.ietf.org/html/draft-ietf-sidr-cp-10.
> 
> The authors indicate that the following changes have been made:
> 
>      1. Added 147 RFC 2119 words
> 
>      2. Changed "2.1. Repositories" to require conformance to
>         the spec "A Profile for Resource Certificate Repository Structure"
> 
>      3. Changed "3.2.4. Non-verified subscriber information"
> 
>         From: No non-verified subscriber data is included in certificates
>               issued under this certificate policy except for SIA/AIA
>               extensions.
>         To: No non-verified subscriber data is included in certificates
>             issued under this certificate policy except for SIA
>             extensions.
> 
>      4. Changed Section "4.7. Certificate re-key" to require conformance
>         to the spec for "CA Key Rollover in the RPKI"
> 
> This document has been through last call once before, which ordinarily 
> would mean that this review would verify that previous last call 
> comments had been adequately dealt with.  However, the number of changes 
> made since the last wglc indicate a full review would be wise, 
> particularly the 2119 language.
> 
> Please review the document and send comments to the list, and indicate 
> whether you believe that this document is ready to leave the wg.
> 
> The wglc will end on 10 Sept.
> 
> --Sandy, speaking as wg chair
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 09 Sep 2010 15:15:16 -0400

There is still a problem in this document that needs to be fixed.  
Section 3.1 of the document explicitly states that there is no 
requirement for subject names to be globally unique in the RPKI.  As I 
have pointed out several times before, this is a violation of X.509, 
which says that "CAs are unambiguously defined by a distinguished name" 
and that a directory name is "A construct that singles out a particular 
object from all other objects. A name shall be unambiguous (that is, 
denote just one object); however, it need not be unique (that is, be the 
only name which unambiguously denotes the object)."

While some people have expressed a concern that a few issuers may create 
name collisions even if there is a requirement that names be 
unambiguous, no one has provided an argument as to why such a 
requirement cannot be specified in the SIDR documents.  Name collisions 
are a security risk, and so should be avoided to whatever degree is 
possible.  While one may not be able to prevent malicious (or 
incorrectly designed) issuers from creating collisions, one can easily 
instruct those who are following the specifications to not create them.

The problem of name collisions is further compounded by the fact that 
draft-ietf-sidr-cp-10.txt (and other SIDR WC documents) explicitly 
permits name collisions, but provides no warnings about the 
risks/problems that name collisions create.  If two CAs issue 
certificates and CRLs under the same name then an X.509 compliant path 
validation library may accept certificates even though they have been 
revoked or may reject (as revoked) certificates that are valid.  Yet, 
there are no warnings in any of the SIDR WG documents about the security 
risks created by name collisions.  In fact, the documents do just the 
opposite: they provide (incorrect) rationalizations for why there is no 
need to avoid name collisions in the RPKI.

draft-ietf-sidr-cp needs to require subject names to unambiguously 
identify a single entity in the RPKI.  There is no reason that such a 
requirement cannot be imposed.  As I demonstrated in a previous email 
(http://www.ietf.org/mail-archive/web/sidr/current/msg01739.html), this 
is a requirement that is very easy to implement and does not require 
"Certification authorities to coordinate PKI-wide unique Subject 
names."  So, a name uniqueness requirement can be imposed just as easily 
as these requirements:

* The distinguished name for every CA and end entity consists of a 
single Common Name (CN) attribute with a value generated by the issuer 
of the certificate. Optionally, the serialNumber attribute MAY be 
included along with the common name (to form a terminal relative 
distinguished name set), to distinguish among successive instances of 
certificates associated with the same entity.

* The Subject name in each certificate MUST be unique relative to all 
Subject names certified by the same Issuer.

* Each CA operating within the context of this PKI MUST require each 
Subject to demonstrate proof-of-possession (PoP) of the private key 
corresponding to the public key in the certificate, prior to issuing the 
certificate.

As I have stated before, just because the SIDR WG documents require 
names to be unambiguous (as is required by X.509), that does not 
preclude draft-ietf-sidr-res-certs from indicating that there is a risk 
that name collisions will occur.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Sep 2010 16:43:31 -0400

At 3:15 PM -0400 9/9/10, David A. Cooper wrote:
>requirement for subject names to be globally unique in the RPKI.  As 
>I have pointed out several times before, this is a violation of 
>X.509, which says that "CAs are unambiguously defined by a 
>distinguished name" and that a directory name is "A construct that 
>singles out a particular object from all other objects. A name shall 
>be unambiguous (that is, denote just one object); however, it need 
>not be unique (that is, be the only name which unambiguously denotes 
>the object)."

David,

As I have noted previously, in the RPKI it would be silly (at best) 
to assume name uniqueness on a global basis. This is because of the 
very large number of entities that will act as CAs, and the reality 
that not all of them ought be trusted. The RPKI, unlike most PKIs, 
does not bind a key to a name as its principle secruity function. It 
binds a key to a resource set. The RPKI is more secure than typical 
PKIs, with regard to its principle function. This is because the 3779 
extension imposes a subset relationship on cert paths analogous to 
what the name constraints extension does. But, as we both know, the 
name constraints extension is very rarely used in PKIs.

You ask what not put the requirement for name uniqueness into the 
SIDR specs, even if we know that it would be dangerous to rely on it. 
If one puts a requirement of this sort into a spec, one is 
encouraging developers to rely on  the requirement, and we don not 
want to do that, for the reasons noted above.

I note that all of the developers of RPKI CA software are employing 
techniques to generate names that should minimize the likelihood of 
name collisions. I'm in favor of including some of the text you 
generated on how to do this in the cert/CRL profile, as 
recommendations in the design note section.

I also omise that, before the cert/CRL profile is finalized, it will 
include text to ensure that the concern you cite will be addressed, 
i.e., to prevent an RP from (naively) assuming that a name match (vs. 
key match) is sufficient when checking CRLs. because of the 
constraints already imposed in the RPKI (re CRL issuance) this is a 
valid check to perform, and it will be called out.

I do not propose to change the CP as you suggest, for the reasons cited above.

I'd like to hear the Security ADs opinions on this matter.

Steve