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
