|
Geoff, George, Robert, The current version of draft-ietf-sidr-res-certs contains a number of contradictions with respect to naming that need to be addressed. While the introduction says that "Resource Certificates are X.509 certificates that conform to the PKIX profile [RFC5280]", this is not the case. draft-ietf-sidr-res-certs-18 specifically states that names do not have to be globally unique, and via reference to draft-ietf-sidr-arch actually encourages the use of names that are not unique (draft-ietf-sidr-arch suggests the use of internal database keys or subscriber IDs as subject names). X.509 mandates that names be globally unique: NOTE 1 – Although the CAs are unambiguously defined by a distinguished name in the DIT, this does not imply that there is any relationship between the organization of the CAs and the DIT. The directory names used in X.509 are defined in X.501: 9.1.4 (directory) name: 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). X.509 uses names for many purposes, including determining the scope of a CRL. In X.509, the neither the key used to sign the CRL nor the location of a CRL in a directory nor the value of the CRLDP extension in a certificate affect the scope of the CRL. While some may believe this was a bad (and potentially dangerous) design decision, we need to acknowledge what is, rather than treating X.509 as if it were designed in the way we wish it had been. There are lots of X.509 path validation libraries, including OpenSSL, that are capable of working with certificates and CRLs that were signed using different keys, and that cannot be simply ignored. draft-ietf-sidr-res-certs-18 incorrectly states that names can't be globally unique within the RPKI since CAs can't coordinate unique subject names, this is not the case. As I have demonstrated (http://www.ietf.org/mail-archive/web/sidr/current/msg01739.html), if the profiles required the inclusion of some randomness in the names, this would effectively ensure name uniqueness without requiring any coordination. Even if there is a risk that there will be "malicious CAs" in the RPKI that won't following the naming rules, that isn't justification for not having them. After all, the SIDR WG is developing certificate profiles, certificate policies (CP), and certification practice statements (CPS), even though if there are any "malicious CAs" in the RPKI, they will not follow the requirements in these documents as well. While it would be unnecessarily risky to intentionally develop an RPKI in such a way that standard X.509 path validation software (e.g., OpenSSL) cannot be safely used to validate certification paths within the RPKI, that does not mean that the SIDR documents cannot encourage the use of path validation software that takes a more restrictive approach to path validation than is allowed by X.509. Adding a requirement in the path validation section of draft-ietf-sidr-res-certs to only use a CRL that was signed using the same key as the corresponding certificate would fall into this category. This would be a new requirement, and not an unreasonable one given that it is consistent with the way that CAs are required to issue CRLs. X.509 was not, in general, designed with the consideration that a PKI might include "malicious CAs". CAs are considered to be trusted entities. A relying party makes a decision to accept one or more CAs as trust anchors, and trusts that these CAs will not act in a malicious manner. In turn these CAs are expected to only issue CA certificates to CAs that can be trusted, and so on. If a CA suspects that a CA to which it has issued a cross-certificate is misbehaving, it would revoke the cross-certificate, effectively removing the misbehaving CA from the PKI. X.509 does define constraint extensions (name constraints, path length constraints, policy constraints, etc.) that can limit the degree to which a CA is trusted and thus mitigate the effects of any "misbehavior", but the RPKI does not take advantage of these extensions. If the SIDR WG believes that the RPKI may include "malicious CAs" that cannot be excluded from the PKI, then that is really something that needs to be covered in the Security Considerations section. If there is a serious risk that "malicious CAs" that cannot be excluded from the PKI will issue certificates to subordinate CAs under the same name as a "non-malicious CA", then the Security Considerations section needs to say that and explain the implications. In particular, it needs to point out that: 1) X.509 does not require the CRL used to determine the status of a certificate be signed using the same key as the corresponding certificate, and there are many path validation libraries available that will use a CRL signed to one key to determine the status of a certificate signed using a different key. 2) A "malicious CA" could create a subordinate CA with the same name as a "non-malicious CA" and then have that subordinate CA issue CRLs that either make it appear that revoked certificates have not been revoked or that valid certificates have been revoked. 3) Clients can protect against being tricked by such CA into using the wrong CRL by only using a CRL to determine the status of a certificate if the CRL and certificate were signed using the same key. Without warnings such as this being prominently placed within the SIDR documents, even someone who carefully reads through the SIDR documents may not understand that the RPKI is "different" from other X.509 PKIs, and that there may be security risks to using just any X.509 path validation library that implements the RFC 3779 certificate extensions. Of course, not everyone validating paths within the RPKI will carefully read these documents, which is why it is important for the profile to not encourage "non-malicious CAs" to assign names in a manner that would unintentionally create the same problems that some are worried that "malicious CA" will intentionally create. We have already heard from implementers that are using the hash of the subject public key as the subject name, and haven't heard from any who have argued that it would be unacceptable to ask them to satisfy the X.509 requirement to create names that are unambiguous across the RPKI, so it shouldn't be a problem for the profile to impose that as a requirement, while including a few examples of naming schemes that CAs could use that would satisfy the requirement. Dave On 07/22/2010 07:13 AM, Stephen Kent wrote: At 9:27 AM -0400 7/21/10, David A. Cooper wrote:Steve, |
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
