Subject: Re: [Isms] Responses to Michael Peck's comments for last call

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Apr 2010 13:32:36 -0400

--On Tuesday, April 06, 2010 04:59:36 PM -0700 Wes Hardaker 
<[email-masked]> wrote:

> 6 DISCUSS 5.3.2 Paragraph 1:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         "authenticating... through a path validation process.. or
>         through a certificate fingerprint verification"
>
>         Just to clarify, does this mean that if a certificate directly
>         matches the fingerprint in the MIB, then RFC5280 path
>         validation is not performed and nothing else about the
>         certificate is checked?  I think that may be okay.  For
>         example, it would provide an override mechanism to be able to
>         manage the device even if the certificate (or the certificates
>         above it in the chain) has expired, rather than potentially
>         being locked out of the device completely.
>
>         + WH: That's correct: a matching fingerprint can be used to not
>           require chaining to a trust anchor.  The current text
>           actually comes from Pasi and the interesting side-effect is
>           that we don't discuss date ranges and I'm not sure we should
>           do this.  I'm more tempted to say we need to add in text
>           describing that the date validity should be checked.  I
>           don't think anyone intended for this to be a way to trump
>           other issues with it other than trust anchor chaining.

On the contrary, a certificate is an assertion from the issuer.  If you're 
not going to use the fact that some issuer has made an assertion in 
deciding whether the key is any good, then the certificate becomes just a 
convenient way to represent a key.  In that case, everything but the key 
becomes irrelevant, because it's all just signed assertions that you're not 
relying on.

The validity times in a certificate indicate when the certificate itself is 
valid; particularly, the expiration time describes the expiration of the 
issuer's assertion that the signed key belongs to a particular subject.  It 
does _not_ describe the expiration of the subject's key, and it is common 
to obtain new certificates with the same key pair.

-- Jeff