[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on <draft-ietf-pkix-crlaia-00.txt>




Denis:

Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated.
You say that it is not clear what validation policy needs to be used, but this is completely irrelevant to the discussion of the CRL AIA extension. This extension aid in certification path construction, not the validation of the path once it is constructed.

Not exactly, it could "help" finding a wrong path !

Not likely. The signer of the CRL is providing a pointer to their own certificate. Path construction to locate a parent of that certificate through a complex PKI might include paths that are acceptable and paths that are unacceptable, but the certificate that contains the public key needed to validate the signature on the CRL is clearly needed.

There are many factors which need to be considered in the validation of the CRL issue certificate. The values of the key usage extension and the certificate policies extension are two that jump to mind. There are probably more if I spend the time to consider each possible scenario.

One simple rule would allow no security problem at all and I wonder why you have so much resistance to mention it.

We have that rule: The CA certificate and the CRL Issuer certificate must validate back to the same trust anchor.

In my opinion, this document is ready for WG Last Call.

As an editor of the draft, I may understand your position; but it is up the the PKIX chairs to decide whether or not the document is ready for WG last call.

Correct. I included this sentence for the WG chairs. I hope they will agree with me, and that they will issue WG Last Call for this document.

Once again the current Security Considerations section is not acceptable.

To you... No one else is advocating this change. I continue to believe that requiring the CA certificate and the CRL Issuer certificate to validate back to the same trust anchor resolves your concern. I am willing to add a few words to the security considerations about name collisions (my co-author may disagree), but I am not willing to use "MUST" or "SHOULD" in those words. There is absolutely nothing that a client can do to determine deal with name collisions that are subordinate to the same trust anchor.

Russ