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.