Thanks for the review Ben. Couple of comments below. Ben Campbell wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-pkix-other-certs-05 > Reviewer: Ben Campbell > Review Date: 22 Sep 2009 > IESG Telechat date: 24 Sept 2009 > > Summary: This draft is basically ready for publication as an > experimental RFC. I have one concern that might be problematic if this > was standards track, but I suspect would not impact an experimental. > > Issues: > > -- Section 3: > > (I am not an expert on how end-entities are expected to treat expired > certs, so I could easily be confused here) I guess in general that's application specific, e.g. one might want an email UA to use an expired cert to verify a signature on an old, stored message. For HTTP/TLS, I guess one shouldn't see expired certs, though of course one does in fact see that quite a lot;-) However, for the main HTTP/TLS use-case, if all was well when the old cert was seen, then it won't really matter what has happened to the old-cert private key in the meantime since the RP will (usually) only see the new-cert public key and (if all is well with the new-cert private key), the linkage remains safe. If a bad-guy wanted to make use of the leaked old-cert private key, then that's independent of the new extension - the bad guy would just use the leaked old-cert private key and hope that the RP lets the user click on the "accept anyway" button as is currently, unfortunately, the case. Arguably, if RPs supported the new extension, we'd all be better off, since such RPs could maybe enforce old-cert expiry more strictly, but that's something to learn-as-we-go - one of the reasons to do this as experimental I guess. > The draft states that two linked certs do not have to be simultaneously > valid, if an application somehow cached the validity of a currently > expired certificate. The extension asserts that the same end-entity > has the private keys for both linked certs. My concern is the idea that > you can assume that the end-entity that held the private keys for a cert > in the past _still_ holds them after that cert expires. > > The draft goes further to explicitly disallow that assumption in the > case where one of the certs has been revoked. In the case of revocation, > it's reasonable to assume the end-entity no longer has sole possession > of the private key. But can you assume that an end-entity will continue > to securely protect the private-key associated with an expired cert, or > revoke that cert if the key is compromised? This assumption appears to > be fundamental to the primary use case described in the draft. > > I'm not sure if this is a problem, as the operating assumption is > probably along the lines of "the end-entity for this new cert had the > private keys for the expired cert back before it expired". If this were > standards track, it would probably be worth some elaboration in the > security considerations section. I guess I don't really see a problem here either, since the putative problem (leaking private key) would also affect a PKI without this new extension as mentioned above. In fact, even if the cert was revoked, that revocation entry may eventually be dropped from the latest CRL (if the RP depends on CRLs). But just in case this does get promoted later, I'd have no problem adding something like the following at the end of the current security considerations section: "In some application contexts, if the old certificate has expired, (and perhaps any associated CRL entries are no longer on the latest CRL), it may be unsafe to link the new and old certificates. Application developers SHOULD carefully consider whether to make use of the other certificates extension in such contexts." I'll leave it to the AD/IESG to say whether its worthwhile adding text like that or not. > > > Nits/editorial comments: > > -- Section 8, last paragraph, last sentence: > > Duplicate "." (period) Ta. > > -- idnits reports the following: > > The document seems to lack a disclaimer for pre-RFC5378 work, but was > first submitted before 10 November 2008. Should you add the > disclaimer? Nope. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.). > Regards, Stephen. > > > > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf