[Cscwg-public] Invalidity Date

Thu Sep 16 14:36:58 UTC 2021

Hi Rob,

Comments inline.

> CAs, such as Sectigo (and, AFAIK, perhaps only Sectigo), that backdate the
RevocationDate field instead of using the InvalidityDate extension, due to
requirements communicated in private emails by Tom Albertson many years ago.

I can confirm that DigiCert backdates revocations of code signing
certificates using the revocationDate field. Additionally, I briefly scanned
through some CRLs issued by code signing CAs and it appears that the
majority do not include the invalidityDate CRL entry extension, but there
are a few that do. So, to your point, there are CAs in both camps.

> I'm unclear how expecting both camps of "CAs to continue to use the
RevocationDate field as they do today" achieves the consistency you're
looking for.  Surely all CAs need to be in the same camp?

I agree that there needs to be better clarity in the CSBRs regarding the use
of the revocationDate field for backdating, especially since it goes against
best practice as defined in 5280. Not backdating revocations using the
revocationDate field may have security consequences, I am thinking it would
be best to draft a ballot to clarify this to ensure consistency across the
ecosystem. Given the security ramifications, I think addressing this issue
sooner rather than after the RFC 3647 migration/Pandocification is the right
course of action.

I'll draft a ballot proposal and circulate on the list before the next
meeting.

Thanks,

Corey

From: Rob Stradling <rob at sectigo.com> 
Sent: Wednesday, September 15, 2021 5:47 PM
To: Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org; Bruce
Morton <bruce.morton at entrust.com>; Corey Bonnell
<Corey.Bonnell at digicert.com>
Subject: Re: Invalidity Date

Hi Ian.

I believe that, today, CAs fall into 2 camps:

1.	CAs, such as Sectigo (and, AFAIK, perhaps only Sectigo), that
backdate the RevocationDate field instead of using the InvalidityDate
extension, due to requirements communicated in private emails by Tom
Albertson many years ago.
2.	CAs that don't backdate the RevocationDate field but that
potentially do use the InvalidityDate extension, because this is consistent
with RFC5280 (and the CS BRs and the published Microsoft Trusted Root
Program Requirements) and Tom didn't privately ask them to do otherwise.

I'm unclear how expecting both camps of "CAs to continue to use the
RevocationDate field as they do today" achieves the consistency you're
looking for.  Surely all CAs need to be in the same camp?

  _____  

From: Ian McMillan <ianmcm at microsoft.com <mailto:ianmcm at microsoft.com> >
Sent: 08 September 2021 20:52
To: Ian McMillan <ianmcm at microsoft.com <mailto:ianmcm at microsoft.com> >;
cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
<cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >; Rob
Stradling <rob at sectigo.com <mailto:rob at sectigo.com> >;
bruce.morton at entrust.com <mailto:bruce.morton at entrust.com>
<bruce.morton at entrust.com <mailto:bruce.morton at entrust.com> >;
Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com>
<Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> >
Subject: RE: Invalidity Date 

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 Folks, 

Considering we would want the behaviors to consistent across the wide
variety of OS versions in the market, we can say confidently that we expect
CAs to continue to use the RevocationDate field as they do today. Any use of
the Invalidity Date extension is not planned to be consumed. 

Thanks,

Ian 

From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Ian McMillan via
Cscwg-public
Sent: Friday, September 3, 2021 3:21 PM
To: rob at sectigo.com <mailto:rob at sectigo.com> ; cscwg-public at cabforum.org
<mailto:cscwg-public at cabforum.org> ; bruce.morton at entrust.com
<mailto:bruce.morton at entrust.com> ; Corey.Bonnell at digicert.com
<mailto:Corey.Bonnell at digicert.com> 
Subject: [EXTERNAL] Re: [Cscwg-public] Invalidity Date

Hi Folks,

I am looking into the current, past, and future behaviors of Windows now to
get a definitive answer.

Thanks,

Ian 

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: Thursday, September 2, 2021 6:14 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> ; Corey
Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> >
Subject: [EXTERNAL] Re: [Cscwg-public] Invalidity Date

[Resending; hopefully this message won't get lost in a moderation
queue/blackhole this time]

> 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. 

That matches our experience.

On 2010-11-12, I received the following email from Tom Albertson, who at
that time was in charge of the Microsoft Root Program:

'Hi Rob, 

I'm in over my technical head on this one, so treat it as more of a relay
than anything else.  When folks over here were looking at recent UserTrust
CRLs, they noticed errors in Windows parsing the revocation date used.  I'm
not sure if it is a recent change or something you have been doing for a
reason, but in any event:

In parsing CRLS, we populate the "Revocation Date" with the effective
revocation date, but UserTrust is using the Invalidity Date extension in its
CRLs.  RFC 5280 defines the Invalidity Date extension as "a non-critical CRL
entry extension that provides the date on which it is known or suspected
that the private key was compromised or that the certificate otherwise
became invalid."  This extension has been around in the standards since 1999
at least as a recommended (SHOULD) extension.  However, Windows has never
supported it.  Windows sets the effective revocation date in the
RevocationDate field, which is supported by other code signing CAs.  Or at
least we haven't noted this use of the Invalidity Date extension by other
CAs so far.

Can you look into this practice on your end, and try to find out the reason
for it?  Would there be any problem going forward indicating the effective
revocation date in the RevocationDate field?  This would appear to require
re-issuing the CRLS, but not require rolling over any of your certificates.

Thanks and best regards,

Tom Albertson'

The end result of that conversation was that we felt we had to treat Tom's
request as a requirement from a root store operator that overrode RFC5280,
which meant that we had to change our (previously RFC5280-compliant)
implementation to start putting the effective revocation date into the
"Revocation Date" field instead of the "Invalidity Date" extension.  Since
we haven't heard anything new from Microsoft on this topic since then, our
implementation still behaves this way today.  (I commented rather than
deleted our original code, in the hope that we would one day be permitted to
return to being RFC5280-compliant).

I don't like it when any aspect of policy is defined by a private
communication that a root store operator sent only to a subset of CAs, but
that seems to be what happened in this case.

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

An official, public update on Microsoft's policy requirements for encoding
the effective revocation date in CRLs would also be much appreciated!

  _____  

From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > on behalf of Corey Bonnell via
Cscwg-public <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >
Sent: 25 August 2021 22:50
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>
<cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> >
Subject: Re: [Cscwg-public] Invalidity Date 

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 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
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.3.2&data=04%7C01%7Crob%40sect
igo.com%7C987689e6256d4d6b0f3508d97302289b%7C0e9c48946caa465d96604b6968b49fb
7%7C0%7C0%7C637667275428154902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gTQRWY7rKTwIxc3s5
3rREY%2BI4rOZtxpkllSZ2GPZbac%3D&reserved=0> .

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/20210916/f9d92c50/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210916/f9d92c50/attachment-0001.p7s>