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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
