At 10:43 PM +0200 7/20/10, Roque Gagliano wrote:
Content-Type: multipart/signed; boundary=Apple-Mail-229-703677170;
protocol="application/pkcs7-signature"; micalg=sha1
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,
i think other text in the resource cert profile also addresses this.
Specifically, 4.9.6 says that:
In this profile the certificate Issuer is also the CRL Issuer,
implying that the CRLIssuer field MUST be omitted, and the
distributionPoint field MUST be present. The Reasons field MUST be
omitted.
The profile makes no provision for a separate cert issued by the CA
to be used for CRL validation (unlike the general case of 5280). Thus
RPs ought to require that the key used to verify a cert is the same
key used to verify the CRL. It will be easy to add that requirement
to this document.
I agree that the AKI extension, if checked during validation,
provides an additional binding to the CA's key. However, David would
note that 5280 does not call for checking the AKI during path
validation, so the check that one might envision here need not be
performed. I would observe that if one used the AKI for path
construction, especially during key rollover, then an RP would be
lead to the right cert.
I also note that the profile calls for inclusion of a URI in the
CRLDP and in the IDP of the CRL. Since these URIs are globally
unique publication points, no "accidental" name collisions in CAs
will cause confusion re picking the right CRL to use. To avoid
secruity problems in the face of a malicious CA name reuse, the only
safe solution appears to be mandating a check that the key used to
verify the cert is the same key used to verify the CRL.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
