Hi David, Isn't this problem prevented by the requirement of including the AKI extension in all CRLs as expressed in section 5.7.1 of draft-ietf-sidr-res-certs-18?
Regards,
Roque.
----------------------------------------------------------------------------------------------------------------------------------------------
Roque Gagliano
Cisco Systems International Sàrl
Software Engineer
Mailstop ROL01/2/
Corporate Development Technology Group Avenue
des Uttins 5
1180 Rolle
[email protected]
Switzerland
Phone: +41 21 823 2805
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
On Jul 14, 2010, at 11:03 PM, David A. Cooper wrote:
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
