[Cscwg-public] CRL Revocation Date Clarification Pre-Ballot
Tim Hollebeek
tim.hollebeek at digicert.com
Wed Sep 22 16:27:22 UTC 2021
My understanding is that the RFC 5280 language about them being different is
because the revocationDate is the date of revocation and the invalidityDate
is the (probably retroactive) date of invalidity. These can be and often
are different.
Our intent with the Code Signing BRs is to align the CSBRs with existing
Microsoft practice and implementation, where the revocationDate is intended
to be the (probably retroactive) date of invalidity, and the invalidity date
is ignored.
Once you make an allowance for the revocationDate to be the date of
invalidity, there is no longer a reason for the two dates to be different,
as they are both the date of invalidity. It appears reasonable to me to
require that if they both appear, they agree.
What I think I’m hearing you say is that there should be an allowance for
RFC 5280 compliant behavior as well, where the invalidityDate is present,
but the revocationDate is the date of revocation. This won’t necessarily
do what you want for Microsoft, but may make sense in other ecosystems. Is
that what you are saying?
If so, I do think it might make sense to say and allow that if the
revocationDate and invalidityDate are different, then the revocationDate
must be the actual date of revocation. I don’t think there’s a good
reason to ban RFC 5280-compliant behavior here.
We’d end up with two allowed behaviors:
1. if the revocationDate is the invalidity date (for compatibility with
the Microsoft implementation) then the invalidityDate, if it appears, must
agree, or
2. if the revocationDate is the actual revocation date (for strict 5280
compliance), then the invalidityDate MAY be present and MAY be different.
This does make it ambiguous if just the revocationDate appears, whether it
is the invalidity date or revocation date. This could be fixed by requiring
the invalidityDate to be present for those who deviate from Microsoft
expectations and adopt option (2). I.e. if the only date that appears is
revocationDate, it must be interpreted as an invalidity date.
-Tim
From: Bruce Morton <Bruce.Morton at entrust.com>
Sent: Wednesday, September 22, 2021 11:51 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; Rob Stradling
<rob at sectigo.com>; cscwg-public at cabforum.org; Corey Bonnell
<Corey.Bonnell at digicert.com>
Subject: RE: CRL Revocation Date Clarification Pre-Ballot
The issue with invaldityDate is that if you are currently using both
invalidityDate and revocationDate per RFC 5280, we are saying that we would
require that invalidityDate be used incorrectly. Why?
I think this ballot should be about providing an RFC exception for
revocationDate.
Bruce.
From: Tim Hollebeek <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >
Sent: Wednesday, September 22, 2021 11:39 AM
To: Rob Stradling <rob at sectigo.com <mailto:rob at sectigo.com> >;
cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> ; Corey Bonnell
<Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> >; Bruce
Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com> >
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.
_____
I prefer the former, since it doesn’t appear that any Certificate Consumer
has any plans to consume the Invalidity Date, even in the future. And
“substantial portion” is just going to cause arguments … it’s better to
remain silent the issue until there’s a concrete consumer with actual plans
to implement.
Bruce, what’s the concern with having the requirement that the invalidity
date, if present, must be the same date? Certificates with two different
dates are going to confuse a lot of people, and it seems completely
unnecessary to allow them, unless I’m missing a use case, which I very well
could be.
-Tim
From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Rob Stradling via
Cscwg-public
Sent: Tuesday, September 21, 2021 11:49 AM
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> ; Bruce Morton <bruce.morton at entrust.com
<mailto:bruce.morton at entrust.com> >
Subject: Re: [Cscwg-public] CRL Revocation Date Clarification Pre-Ballot
I think it's valuable for CABForum documents to explicitly call out
deviations from RFC5280, but I'd take a different approach to Bruce's
suggestion...
In the Server Certificate BRs, "Application of RFC 5280" describes a
scenario (Precertificates) where RFC5280 does not apply at all; whereas what
I think we're trying to do here is specify that RFC5280 does apply (to CRLs)
except for one required deviation (i.e., "revocationDate" MUST match the
RFC5280 semantics for Invalidity Date, rather than necessarily be "The date
on which the revocation occurred"). Deviation is not "Application", in my
view.
I think the most similar concept in the Server Certificate BRs is the
language about non-critical Name Constraints:
"Non‐critical Name Constraints are an exception to RFC 5280 (4.2.1.10),
however, they MAY be used until
the Name Constraints extension is supported by Application Software
Suppliers whose software is used by
a substantial portion of Relying Parties worldwide."
The effect of this text is that RFC5280 does apply (to the Name Constraints
extension) except for one required deviation (i.e., we permit the extension
to be non-critical, at least for now).
How about adding this language to the ballot...
'Permitting the "revocationDate" to be set earlier than the date on which
the revocation occurred is an exception to RFC 5280 (5.1.2.6)."
Or, if we're hoping that this RFC5280 deviation will be temporary, how
about...
'Permitting the "revocationDate" to be set earlier than the date on which
the revocation occurred is an exception to RFC 5280 (5.1.2.6); however, this
MAY be done until the Invalidity Date extension is supported by Application
Software Suppliers whose software is used by a substantial portion of
Relying Parties worldwide."
WDYT?
_____
From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > on behalf of Bruce Morton via
Cscwg-public <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >
Sent: 21 September 2021 16:04
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> <cscwg-public at cabforum.org
<mailto:cscwg-public at cabforum.org> >
Subject: Re: [Cscwg-public] CRL Revocation Date Clarification Pre-Ballot
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.
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
<mailto:Corey.Bonnell at digicert.com> >
Sent: Tuesday, September 21, 2021 8:45 AM
To: Bruce Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com>
>; cscwg-public at cabforum.org <mailto: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
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cab
forum.org%2Fpipermail%2Fcscwg-public%2F2021-September%2F000532.html&data=04%
7C01%7Crob%40sectigo.com%7C0d12b84938cc4d7ed05208d97d1118a7%7C0e9c48946caa46
5d96604b6968b49fb7%7C0%7C0%7C637678334657724301%7CUnknown%7CTWFpbGZsb3d8eyJW
IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
0y8EPWbaEx8JjusdPkaCY%2F6AZTmk3mzEJxeQuPv5yhk%3D&reserved=0>
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/20210922/15a0e992/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210922/15a0e992/attachment-0001.p7s>
More information about the Cscwg-public
mailing list