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) 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. Nits/editorial comments: -- Section 8, last paragraph, last sentence: Duplicate "." (period) -- 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? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).