|
On 03/31/2016 11:30 AM, Ben Laurie
wrote:
The id-ad-ocsp access method in AIA just contains an HTTP URI that provides information about where an OCSP responder can be found. It does nothing to help ensure that the response it authoritative for the certificate. That is addressed by other means. Perhaps if PKIX were changed to only allow the use of OCSP to distribute status information and it imposed (as SHALLs) certain restrictions on the validation of OCSP responses, this would avoid the problems that name collisions might cause with respect to determining the revocation status of a certificate. But, there's a lot more to a PKI than just determining whether certificates are revoked.
I can again only guess what you mean. As with OCSP, including a URL in the cRLDistributionPoints extension just provides an (insecure) pointer to where a CRL can be found. It doesn't provide any security. In order for the URL to provide any additional assurance, that same URL would need to appear in a critical issuingDistributionPoint extension in the CRL. If it appeared in the CRL's IDP extension, then the CRL could only be used if the same name (e.g., HTTP URI) appeared in both the CRL's IDP and the certificate's CRLDP. But this again relies on names being unambiguous, because it wouldn't solve the problem if unrelated issuers could use the same names for distribution points.
There needs to be a reliable revocation mechanism for all certificates, not just EE certificates, and the mechanisms that PKIX describes (CRLs and OCSP) are the same for both. So, if something needs to be done in EE certificates to make revocation reliable, then something needs to be done in CA certificates as well.
Yes. The problem with attribute certificates has nothing to do with revocation. RFC 5755 allows attribute certificates to be issued to entities (humans, devices, etc.). How does a relying party know to whom (or what) the attribute certificate was issued? The entity to which the attribute certificate was issued is identified by providing the issuer name and serial number of the entity's public key certificate. So, if issuer names are ambiguous, then relying parties cannot reliably determine to whom (or to what) an attribute certificate has been issued.
In practice, this just isn't a problem. CAs aren't just arbitrary system components. They are trusted entities that operate under well-defined policies and practices, and they don't just assign simple names for their CAs like "cn=Joe's CA". Just look, for example, at the name of the CA that issued the certificate for the IETF web site: CN = Starfield Secure Certificate Authority - G2, OU = http://certs.starfieldtech.com/repository/, O = "Starfield Technologies, Inc.", L = Scottsdale, ST = Arizona, C = USIs some unrelated entity going to issue certificates under that same name by accident? Given the way names are formed, if two entities were found to be using the same name, it is far more likely that is was a result of one of these entities deliberately trying to impersonate the other. That's not a case of names being ambiguous, that's an attack. The solution to that (if name constraints don't prevent the impersonator's certificate from being validated) is revocation. PKIX doesn't deal with the issue of how to detect that there is a certificate that should be revoked. But this has nothing to do with names. If you have an undetected attacker in your PKI that is trusted as a CA, then you have problems regardless of whether the PKI standard was developed to mitigate problems associated with ambiguous CA names. |
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
