<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
{mso-style-name:x_msonormal;
margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.xmarkevaru7uc9
{mso-style-name:x_markevaru7uc9;}
p.xxmsonormal, li.xxmsonormal, div.xxmsonormal
{mso-style-name:x_xmsonormal;
margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xxmsolistparagraph, li.xxmsolistparagraph, div.xxmsolistparagraph
{mso-style-name:x_xmsolistparagraph;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:442964279;
mso-list-type:hybrid;
mso-list-template-ids:1938950374 432718566 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-fareast-font-family:"Yu Gothic";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:677971935;
mso-list-template-ids:1277459088;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1028801658;
mso-list-template-ids:1570695878;}
@list l3
{mso-list-id:1510369834;
mso-list-type:hybrid;
mso-list-template-ids:998309844 1067765134 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-fareast-font-family:"Yu Gothic";
mso-bidi-font-family:"Times New Roman";}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Rob,<o:p></o:p></p><p class=MsoNormal>Comments inline.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> 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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> 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?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ll draft a ballot proposal and circulate on the list before the next meeting.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b>From:</b> Rob Stradling <rob@sectigo.com> <br><b>Sent:</b> Wednesday, September 15, 2021 5:47 PM<br><b>To:</b> Ian McMillan <ianmcm@microsoft.com>; cscwg-public@cabforum.org; Bruce Morton <bruce.morton@entrust.com>; Corey Bonnell <Corey.Bonnell@digicert.com><br><b>Subject:</b> Re: Invalidity Date<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'>Hi Ian.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'>I believe that, today, CAs fall into 2 camps:<o:p></o:p></span></p></div><div><ol start=1 type=1><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'><span style='font-size:12.0pt'>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.<o:p></o:p></span></li><li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1'><span style='font-size:12.0pt'>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.<o:p></o:p></span></li></ol><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'>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?<o:p></o:p></span></p></div></div><div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p></div><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="98%" align=center></div><div id=divRplyFwdMsg><p class=MsoNormal><b><span style='color:black'>From:</span></b><span style='color:black'> Ian McMillan <<a href="mailto:ianmcm@microsoft.com">ianmcm@microsoft.com</a>><br><b>Sent:</b> 08 September 2021 20:52<br><b>To:</b> Ian McMillan <<a href="mailto:ianmcm@microsoft.com">ianmcm@microsoft.com</a>>; <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a> <<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>>; Rob Stradling <<a href="mailto:rob@sectigo.com">rob@sectigo.com</a>>; <a href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a> <<a href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a>>; <a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a> <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>><br><b>Subject:</b> RE: Invalidity Date</span> <o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span style='font-size:10.0pt;color:black'>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.<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=xmsonormal>Hi Folks, <o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>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. <o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>Thanks,<o:p></o:p></p><p class=xmsonormal>Ian <o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=xmsonormal><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Ian McMillan via Cscwg-public<br><b>Sent:</b> Friday, September 3, 2021 3:21 PM<br><b>To:</b> <a href="mailto:rob@sectigo.com">rob@sectigo.com</a>; <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>; <a href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a>; <a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a><br><b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] Invalidity Date<o:p></o:p></p></div></div><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>Hi Folks,<o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>I am looking into the current, past, and future behaviors of Windows now to get a definitive answer.<o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>Thanks,<o:p></o:p></p><p class=xmsonormal>Ian <o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=xmsonormal><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Rob Stradling via Cscwg-public<br><b>Sent:</b> Thursday, September 2, 2021 6:14 AM<br><b>To:</b> Bruce Morton <<a href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a>>; <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>; Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>><br><b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] Invalidity Date<o:p></o:p></p></div></div><p class=xmsonormal> <o:p></o:p></p><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>[Resending; hopefully this message won't get lost in a moderation queue/blackhole this time]</span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>> 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 <span class=xmarkevaru7uc9>invalidity</span>Date is seemingly not used. </span><o:p></o:p></p><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>That matches our experience.</span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>On 2010-11-12, I received the following email from Tom Albertson, who at that time was in charge of the Microsoft Root Program:</span><o:p></o:p></p></div><div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'>'Hi Rob,</span></i><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'>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:</span></i><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'>In parsing CRLS, we populate the “Revocation Date” with the effective revocation date, but UserTrust is using the <span class=xmarkevaru7uc9>Invalidity</span> Date extension in its CRLs. RFC 5280 defines the <span class=xmarkevaru7uc9>Invalidity</span> 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 <span class=xmarkevaru7uc9>Invalidity</span> Date extension by other CAs so far.</span></i><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'>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.</span></i><o:p></o:p></p></div><div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'> </span></i><o:p></o:p></p></div><div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'>Thanks and best regards,</span></i><o:p></o:p></p></div><p class=xmsonormal><i><span style='font-size:12.0pt;color:black'>Tom Albertson'</span></i><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>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 "<span class=xmarkevaru7uc9>Invalidity</span> 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).</span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>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.</span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>> Could Ian or Mike confirm Windows’s behavior in this regard?</span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>An official, public update on Microsoft's policy requirements for encoding the effective revocation date in CRLs would also be much appreciated!</span><o:p></o:p></p></div></div><div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="98%" align=center></div><div id="x_divRplyFwdMsg"><p class=xmsonormal><b><span style='color:black'>From:</span></b><span style='color:black'> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>> on behalf of Corey Bonnell via Cscwg-public <<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>><br><b>Sent:</b> 25 August 2021 22:50<br><b>To:</b> Bruce Morton <<a href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a>>; <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a> <<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>><br><b>Subject:</b> Re: [Cscwg-public] Invalidity Date</span> <o:p></o:p></p><div><p class=xmsonormal> <o:p></o:p></p></div></div><div><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=xmsonormal style='line-height:12.0pt;background:#FAFA03'><span style='font-size:10.0pt;color:black'>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.</span><o:p></o:p></p></div><p class=xmsonormal> <o:p></o:p></p><div><div><p class=xxmsonormal>Hi Bruce,<o:p></o:p></p><p class=xxmsonormal>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). <o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>Could Ian or Mike confirm Windows’s behavior in this regard?<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>Thanks,<o:p></o:p></p><p class=xxmsonormal>Corey<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=xxmsonormal><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Bruce Morton via Cscwg-public<br><b>Sent:</b> Wednesday, August 25, 2021 1:59 PM<br><b>To:</b> <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br><b>Subject:</b> [Cscwg-public] Invalidity Date<o:p></o:p></p></div></div><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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, <span style='color:black;background:yellow'>the CA MAY specify a revocation date in a CRL</span> 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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>The CSBRs are referring to “revocation date’, which I believe should be referring to “invalidity date” as specified in RFC 5280, <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.3.2&data=04%7C01%7Crob%40sectigo.com%7C987689e6256d4d6b0f3508d97302289b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637667275428154902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gTQRWY7rKTwIxc3s53rREY%2BI4rOZtxpkllSZ2GPZbac%3D&reserved=0">https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.2</a>.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>Note that we need to think of the following dates:<o:p></o:p></p><ul style='margin-top:0cm' type=disc><li class=xxmsolistparagraph style='margin-top:0cm;margin-bottom:0cm;mso-list:l1 level1 lfo2'>Valid from<o:p></o:p></li><li class=xxmsolistparagraph style='margin-top:0cm;margin-bottom:0cm;mso-list:l1 level1 lfo2'>Invalidity date<o:p></o:p></li><li class=xxmsolistparagraph style='margin-top:0cm;margin-bottom:0cm;mso-list:l1 level1 lfo2'>Revocation date<o:p></o:p></li><li class=xxmsolistparagraph style='margin-top:0cm;margin-bottom:0cm;mso-list:l1 level1 lfo2'>Valid to<o:p></o:p></li></ul><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>Would there be any objections in changing “revocation date” to “invalidity date” in a future ballot? <o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>Thanks, Bruce<o:p></o:p></p><p class=xxmsonormal><i>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. <u>Please notify Entrust immediately</u> and delete the message from your system.</i> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></body></html>