[Cscwg-public] CRL Revocation Date Clarification Pre-Ballot

Tue Sep 21 15:04:07 UTC 2021

Hi Corey,

I was thinking that we would create a section similar to the BRs called
"Application of RFC 5280." We could have text that says, "For the purposes
of clarification, the revocationDate MAY be set the same as the
invalidityDate, which would mean that the revocationDate may precede the
date of issue of earlier CRLs."

I don't think that we need to address or change the requirements for
invalidityDate as this date is not used by Windows; however, it may be used
by other applications per RFC 5280.

Bruce.

From: Corey Bonnell <Corey.Bonnell at digicert.com> 
Sent: Tuesday, September 21, 2021 8:45 AM
To: Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org
Subject: [EXTERNAL] RE: CRL Revocation Date Clarification Pre-Ballot

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 interpreted Ian's message from last week [1] as guidance that all CAs
should be using the revocationDate to denote when the Code Signing
Certificate is first invalid. Since Windows (Authenticode) does not consume
the invalidityDate extension value when making trust decisions, there is a
negative security impact when CAs set the invalidityDate and revocationDate
in the manner described in RFC 5280. This ballot codifies the guidance Ian
shared so that the revocationDate is set uniformly across all CAs.

Thanks,

Corey

[1]
https://lists.cabforum.org/pipermail/cscwg-public/2021-September/000532.html

From: Bruce Morton <Bruce.Morton at entrust.com
<mailto:Bruce.Morton at entrust.com> > 
Sent: Monday, September 20, 2021 2:31 PM
To: Corey Bonnell <Corey.Bonnell at digicert.com
<mailto:Corey.Bonnell at digicert.com> >; cscwg-public at cabforum.org
<mailto:cscwg-public at cabforum.org> 
Subject: RE: CRL Revocation Date Clarification Pre-Ballot

Hi Corey,

Is there a reason that we cannot allow CAs to continue to use Revocation
date and Invalidity date as per RFC 5280?

My assumption is that we were going to allow the Revocation date to be a
date earlier than the time the certificate was revoked. I am not seeing how
this change would impact the Invalidity date.

Bruce.

From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Corey Bonnell via
Cscwg-public
Sent: Monday, September 20, 2021 12:52 PM
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> 
Subject: [EXTERNAL] [Cscwg-public] CRL Revocation Date Clarification
Pre-Ballot

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

  _____  

Hello,

As discussed last week, it would be valuable to ensure that there is clarity
regarding how revocation/invalidity dates are encoded in CRLs so that
relying party software can make the correct trust decisions regarding
compromised code. Attached is a small change to 13.2.1 to reflect that the
revocationDate CRL entry field shall be used to denote when a certificate is
invalid. The proposed language allows for the Invalidity Date CRL entry
extension to continue to appear, but the time encoded in it must be the same
as the revocationDate for the entry. I don't believe this causes issues with
Windows CRL processing, please let me know if it does and I'll remove the
provision.

For reference, here are the two proposed paragraphs to be added to 13.2.1:

If a Code Signing Certificate is revoked, and the CA later becomes aware of
a more appropriate revocation date, then the CA MAY use that revocation date
in subsequent CRL entries and OCSP responses for that Code Signing
Certificate.

Effective 2022-02-01, if the CA includes the Invalidity Date CRL entry
extension in a CRL entry for a Code Signing Certificate, then the time
encoded in the Invalidity Date CRL extension SHALL be equal to the time
encoded in the revocationDate field of the CRL entry.

Given that the revocation date is potentially security sensitive, I think
it's worthwhile to get this clarified prior to the RFC 3647/Pandoc effort.
In addition to comments/questions on the proposed language, we're looking
for two endorsers.

Thanks,

Corey

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/20210921/ea4916e3/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/20210921/ea4916e3/attachment-0001.p7s>