Steve, >but the CA cert used to verify a CRL signature does contain resources, >and that, I believe, was the issue Sriram was raising, >and that my message raised.
To be fair, Geoff did respond to my question: http://www.ietf.org/mail-archive/web/sidr/current/msg07453.html He said: “I would’ve thought that if you can establish a chain of Issuer / subject certs that connect a chosen Trust Anchor to the CA that issued the CRL then you have a sound reason to accept the CRL. Given that the CRL has no resources there does not seem to be any resource attribute test that can be applied here.” So, as I understand it now, when validating a ROA or a CRL, the first basic step (Step #1) is this: (Geoff/Tim: This is a description based on my understanding; please correct me if I got it wrong.) Step #1: Gather the relevant resource CA certs in the cert-path: C0, C1, C2, ..., Cn, where C0 is the TA’s cert and Cn is the final resource holder’s cert who created the ROA or issued the CRL. Before saying anything about the ROA or the CRL validity, first perform a basic check to see if *cert-path is Valid*. The given *cert-path is Valid* if the following holds: the signature on cert Ci is Valid when verified with the public key associated with cert C(i-1), for all i in 1 <= i <= n. In this basic validation process, no consideration is given to the resources contained in the certs. So at this step in the algorithm, it is not checked whether the resources contained in the certs are “encompassing” or not. This step only cares about verifying the chain of issuer/subject relationships (the successive issuers’ signatures on the certs). (Proceed to Step #2 if the *cert-path is Valid*.) Step #2 (in the case of a ROA): (Recall that the holder of Cn issued the ROA) The ROA is Valid if all of the following conditions hold: (a) The signature on the EE cert is Valid (verified with the public key associated with Cn). (b) The signature on the ROA is valid (verified with the public key associated with the EE cert). (c) The prefix resources in the ROA exactly match the resources listed in the EE cert. (d) All the prefix resources in the ROA are contained in the intersection of the resources listed in the set {C0, C1, ..., Cn}. Step #2 (in the case of a CRL): (Recall that the holder of Cn issued the CRL) The CRL is Valid if all the following conditions hold: (a) The certificate(s) being revoked in the CRL is (are) certificates that were issued earlier by the subject (holder) of Cn. (b) The signature on the CRL is Valid (verified with the public key associated with Cn). (Note: No need to look into the list of resources listed in Cn for CRL validation. Cn can issue a cert C(n+1) and later revoke it at will by issuing a CRL. When the CRL is received, for its validation purpose, we don’t need to look at what resources are listed in the revoked cert C(n+1) and their relation with the resources listed in cert Cn. Because the resource cert that is being CRL’ed is meant to be discarded.) Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
