[Cscwg-public] Invalidity Date

[Bruce Morton]

Independent of client behavior, putting the revocation date in the
invalidityDate field would provide no value. I think it is best to implement
in accordance with RFC 5280. Perhaps the clients will catchup in the future.

 

Bruce.

 

From: Corey Bonnell <Corey.Bonnell at digicert.com> 
Sent: Wednesday, August 25, 2021 5:51 PM
To: Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org
Subject: [EXTERNAL] RE: Invalidity Date

 

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.

  _____  

Hi Bruce,

I agree that using the invalidityDate CRL entry extension to express when
the key corresponding to a revoked code signing certificate can no longer be
trusted as opposed to the revocation date is conceptually cleaner and more
in line with 5280 (which states that the revocation date SHOULD NOT be
backdated such that it is before the issue date of the latest CRL). 

 

However, in all the documentation I've seen regarding Authenticode, it
appears that the revocation date is the value that is checked by Windows and
invalidityDate is seemingly not used.

 

Could Ian or Mike confirm Windows's behavior in this regard?

 

Thanks,

Corey

 

 

From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Bruce Morton via
Cscwg-public
Sent: Wednesday, August 25, 2021 1:59 PM
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> 
Subject: [Cscwg-public] Invalidity Date

 

CSBR 13.2.1 states: A Certificate MAY have a one-to-one relationship or
one-to-many relationship with the signed Code. Regardless, revocation of a
Certificate may invalidate the Code Signatures on all signed Code, some of
which could be perfectly sound. Because of this, the CA MAY specify a
revocation date in a CRL or OCSP response to time-bind the set of software
affected by the revocation, and software should continue to treat objects
containing a timestamp dated before the revocation date as valid.

 

The CSBRs are referring to "revocation date', which I believe should be
referring to "invalidity date" as specified in RFC 5280,
https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.2.

 

Note that we need to think of the following dates:

*	Valid from
*	Invalidity date
*	Revocation date
*	Valid to

 

The purpose of the Invalidity date is to provide a date in the past, when
the key was compromised. The revocation date would be on the date that the
certificate was revoked and cannot be a past date.

 

Would there be any objections in changing "revocation date" to "invalidity
date" in a future ballot? 

 

 

Thanks, Bruce

Any email and files/attachments transmitted with it are confidential and are
intended solely for the use of the individual or entity to whom they are
addressed. If this message has been sent to you in error, you must not copy,
distribute or disclose of the information it contains. Please notify Entrust
immediately and delete the message from your system. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210826/e944f453/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4929 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210826/e944f453/attachment-0001.p7s>