All,

The current RPKI documents (draft-ietf-sidr-res-certs, 
draft-ietf-sidr-cp, draft-ietf-sidr-cps-irs, draft-ietf-sidr-cps-isp, 
draft-ietf-sidr-arch) require that subject names in certificates be 
unique relative to all certificates issued by a given CA, but does not 
require that subject names be issued in a manner that would make it 
likely that subject names are globally unique (i.e., unique across the 
entire RPKI).

While it is true that there is less of a need for names to be unique 
across the RPKI than there is other other PKIs (since the RPKI does not 
use such things as name constraints, indirect CRLs, or attribute 
certificates), the existence of name collisions within the RPKI would 
not be without risk.  In particular, there is no requirement in X.509 
that the CRL used to determine the revocation status of a certificate be 
signed using the same key as the certificate.  Using the X.509 (and RFC 
5280) path validation rules, a CRL may be validated using an entirely 
different certification path than the certificate whose status is being 
checked.  If a path validation implementation does this, and there are 
two different CAs within the PKI that operate under the same name, then 
the library may use the CRL issued by one of the CAs to determine the 
status of certificates issued by the other CA.  This could lead to a 
revoked certificate being accepted as valid or a valid certificate being 
rejected as revoked.

It is my understanding that some current path validation implementations 
that are being developed for use with the RPKI make use of the OpenSSL 
path validation libraries.  At the moment, OpenSSL will not by default 
will not use a separate certification path to validate a CRL than was 
used to validate the certificate whose status is being checked, but the 
latest version of OpenSSL (1.0.0) does have that capability.  One of the 
changes that is mentioned for OpenSSL 1.0.0 is:

   *) Add support for distinct certificate and CRL paths. The CRL issuer
      certificate is validated separately in this case. Only enabled if
      an extended CRL support flag is set: this flag will enable additional
      CRL functionality in future.

If a future version of OpenSSL enables this feature by default, and that 
version of OpenSSL is used to validate certificates in the RPKI, and 
there are name collisions in the RPKI, then relying parties will be at 
risk of incorrectly accepting or rejecting certificates.

I understand that there is a desire to keep subject names within the 
RPKI simple and that the RPKI cannot impose a centralized or 
hierarchical naming structure to ensure that there are no name 
collisions.  However, with a very small change to the RPKI 
specifications, one could maintain a simple naming scheme while making 
the risk of name collisions negligible.

The current RPKI specification states that a subject name consists of a 
commonName attribute and optionally a serialNumber attribute.  However, 
there was some discussion recently about whether the specification could 
be changed to require that the subject name contain only a commonName 
attribute.  So, I will present examples of ways in which unambiguous 
names could be constructed that only include a commonName attribute.  
The idea is to include enough randomness in the name so that name 
collisions are unlikely.  According to the Birthday Paradox, if there 
are about one million (2^20) CAs in the RPKI, then collisions will be 
unlikely if there is significantly more than 40 bits of entropy in the 
name.  Some ways to achieve this would be:

1) Hash of the subject public key (encoded as ASCII HEX).
     example: cn="999d99d564de366a29cd8468c45ede1848e2cc14"

2) A Universally Unique IDentifier (UUID) - RFC 4122
     example: cn="6437d442-6fb5-49ba-bbdb-19c260652098"

3) A randomly generated ASCII HEX encoded string:
    example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"
    (A string of 20 ASCII HEX digits would have 80-bits of entropy)

4) An internal database key or subscriber ID combined with one of the above
     example:  cn="<DBkey1> (6437d442-6fb5-49ba-bbdb-19c2606520980)"
    (The issuing CA may wish to be able to extract the database key or 
subscriber
    ID from the commonName.  Since only the issuing CA would need to be 
able to
    parse the commonName, the database key and the source of entropy
    (e.g., a UUID) could be separated in any way that the CA wanted, as 
long as
    it conformed to the rules for PrintableString.  The separator could 
be a space
    character, parenthesis, hyphen, slash, question mark, etc.  Of 
course, the
    source of entropy could also be placed in a separate attribute, if 
the profile
    permitted that.)

   If the internal database key or subscriber ID contained enough entropy by
   itself, then it may not be necessary to include anything else in the 
commonName
   attribute.


Of course, even if the RPKI documents required CAs to create subject 
names as described above, there is a risk that some CAs in the RPKI 
would not follow these rules and would accidentally (or deliberately) 
create name collisions.  This problem could be mitigated, however, given 
the way that certificates and CRLs are issued in the RPKI.  Unlike X.509 
in general, the RPKI requires that the CRL that provides the revocation 
status of a certificate be signed using the same key as the 
corresponding certificate.  The RPKI could take advantage of that by 
adding a step to the path validation algorithm (Step 5 in Section 7.2 of 
draft-ietf-sidr-res-certs) requiring the relying party to verify the 
signature on the CRL used to determine whether the certificate was 
revoked using the same public key as was used to verify the signature on 
the certificate itself.  At the moment, the RPKI path validation 
algorithm does not impose such a requirement.

It may also be a good idea to add a paragraph to the Security 
Considerations section noting that there may be a risk in using a path 
validation implementation that is capable of using separate 
certification paths for a certificate and the corresponding CRL if there 
are name collisions in the RPKI as a result of CAs not following the 
profiles requirements for constructing subject names.

This would result in a belts-and-suspenders approach.  Specifying naming 
rules that will make name collisions unlikely will increase the 
likelihood that relying parties can safely use any X.509 path validation 
implementation that has added support for the RFC 3779 extensions.  
Imposing a path validation requirement to only use CRLs that were signed 
using the same key as the certificate will encourage relying parties to 
use path validation software that will be at less risk of getting 
incorrect certificate validation results even if there are name 
collisions in the RPKI as as result of some CAs not complying with the 
naming rules.

Dave