cert considered invalid when intermediate is expired

[Daniel Kahn Gillmor]

On 10/28/2012 10:23 AM, Nikos Mavrogiannopoulos wrote:
> On 10/28/2012 01:57 PM, James Cloos wrote:
> 
>>>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>>
>> NM> If the intermediate certificate is expired why would you consider it
>> NM> valid? You may ignore expiration failures if your application doesn't
>> NM> care, but gnutls cannot ignore them.
>>
>> The presumption people normally make is that the validity period of a
>> cert specifies when it can sign, not when it can verify.
>>
>> If the cert was valid when the signature was made, validation is expected
>> to continue to work for the lifetime of the signed cert.
>
> This is a totally different use case than a TLS certificate chain
> verification. You can do that by considering the expired certificates as
> trusted while you verify the documents. That verification is application
> specific.

Just to clarify, there is a specific attack that web browsers (and other
TLS-using X.509 relying parties) cannot properly defend against:

the holder of the secret key belonging to an expired certificate can
make arbitrary certificates with arbitrary start times (since they
control the clock on the signing system).  So, if your certificate
expired in December 2010, you can still use the secret key today to make
a cert that was "created" in November 2010, which happens to be good for
3 years.

If the relying parties were willing to accept an expired intermediate
(or root) cert that appears to be "valid at time of issuance", then
there is nothing to stop a malicious intermediate (or root!) CA from
continuing to sign any certificate they'd like at any time.

It's tempting to let this particular validation error slide for the
reason James Cloos describes; but it would be a bad idea to do so.

GnuTLS is doing the right thing.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20121028/c576d61d/attachment.pgp>