My response to Steve Kent, sent to the SIDR WG > 24 hours ago, does not appear to be in the WG mailing list archive. It appears that using IPv6 to send mail to the sidr mailing list is not a good idea. The mail appears to to have been sent to the IETF mail servers according to the local mail log but never makes it to the mailing list on the IETF's systems. (So much for IPv6 robustness at the IETF, if thats indeed what has happaned!)
Let met try once more to send this to the sidr wg using a different mechanism.... Geoff Geoff -------------------------- On 14/06/2010, at 12:14 AM, Stephen Kent wrote: > At 9:09 AM +1000 6/12/10, Geoff Huston wrote: >> O... >> >> The requirement was introduced into the res-cert draft in response to a >> review comment from David Cooper: >> >> 3) Section 3.9.5 states: >> >> In this profile, the scope of the CRL is specified to be all >> certificates issued by this CA issuer using a given key pair. >> >> The scope of a CRL MUST be all certificates issued by the issuing CA >> unless the CRL includes an issuingDistributionPoint extension. So, if >> the scope of CRLs is to be limited to certificates signed with a given >> key pair, then the profile must either require inclusion of the >> issuingDistributionPoint extension in CRLs or forbid CAs from performing >> key rollover. The latter option may be implemented by having issuers >> change names whenever changing the key pair used to sign certificates. >> >> http://www.ietf.org/mail-archive/web/sidr/current/msg00476.html (and the >> ensuing brief thread). >> >> Geoff > > Geoff, > > Thanks for the explanation. David suggested two solutions to the problem, and > you chose to mandate changing the CA name rather than adding the IDP > extension into the CRL. This is true, although I have a recollection of consulting with some others at the time. > > The ensuring brief thread, that I just (quickly) reviewed, entailed message > exchanges between only you and David, and involved clarifying discussion > about how one could use the iDP extension to qualify the scope of a CRL when > rekeying. (It also included a confusing excursion into revocation reason > codes, and a discussion of appropriate key lengths to match hash algs. That > latter discussion may have been unduly biased by some NIST guidance that > focuses on long term sigs vs. certs, but ...) I have not dredged up all the emails from the time, but I recall (possibly not quite accurately) that at the time the general view was that the alternatives involved keeping the CA constant and allowing a CRL signed with the "new" key to revoke objects that were signed with "older" keys, or using a regime whereby the scope of the CRL which was limited to objects that were signed with the same private key that was used to sign the CRL was retained, which appeared to imply the concept of a key rollover implying a new CA. As I recall there was a marked preference for the latter course of action as representing the least impact on the evolving code base and an expectation that this limited CRL scope could be of benefit in this environment of a widely distributed PKI. Hence, the response to David's comments was to forbid CAs from performing a key rollover and implement key rollover via the use of change of CA. > > I'd just like to make sure that, that the WG still agrees that this is the > preferred solution. I agree that this is a prudent check. > If so, we can accommodate that in the key/alg rollover document, and note the > rationale. I do think the rationale also should appear in the repository > structure document as well, maybe the resource cert profile too. It would > take only a short paragraph to do so. I think it better not to succumb to the temptation to play hide and seek with a future consumer of these documents and embed critical design information and rationales in a whole set of documents. Its probably also unwise to copy this information and rationale and use it in multiple documents given the possibility of latter revision of one of the documents but not the others, resulting in the potential for contradiction. On that basis I would argue in favour of a position that placed constraints on a CA and the rationale for this constraint in a single document. It seems to me that the most logical place is the resource certificate profile document. I do not see a convincing case to duplicate this same rationale in the repository structure document, nor in an algorithm migration document, based on these considerations. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
