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)
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.).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf