Subject: [Gen-art] GenArt Telechat Review of draft-ietf-pkix-other-certs-05

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Sep 2009 14:35:44 -0500

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.).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Sep 2009 11:52:33 +0100

Thanks for the review Ben. Couple of comments below.

> 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.
> 
> 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.
> 
> 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.

> -- Section 8, last paragraph, last sentence:

Ta.

>      first submitted before 10 November 2008.  Should you add the

Nope.

>      http://trustee.ietf.org/license-info for more information.).

Regards,
Stephen.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 23 Sep 2009 08:24:26 -0500

Thanks for the quick response. Your responses address all of my  
comments.

Thanks!

Ben.

On Sep 23, 2009, at 5:52 AM, Stephen Farrell wrote:

>> simultaneously
>> revocation,
>> were