<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:"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:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Bruce,<o:p></o:p></p><p class=MsoNormal>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.<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><p class=MsoNormal>[1] <a href="https://lists.cabforum.org/pipermail/cscwg-public/2021-September/000532.html">https://lists.cabforum.org/pipermail/cscwg-public/2021-September/000532.html</a><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 0in 0in 0in'><p class=MsoNormal><b>From:</b> Bruce Morton <Bruce.Morton@entrust.com> <br><b>Sent:</b> Monday, September 20, 2021 2:31 PM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com>; cscwg-public@cabforum.org<br><b>Subject:</b> RE: CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Corey,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Is there a reason that we cannot allow CAs to continue to use Revocation date and Invalidity date as per RFC 5280?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bruce.<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 0in 0in 0in'><p class=MsoNormal><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org">cscwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Corey Bonnell via Cscwg-public<br><b>Sent:</b> Monday, September 20, 2021 12:52 PM<br><b>To:</b> <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br><b>Subject:</b> [EXTERNAL] [Cscwg-public] CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>WARNING: This email originated outside of Entrust.<br>DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="100%" align=center></div><p class=MsoNormal>Hello,<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For reference, here are the two proposed paragraphs to be added to 13.2.1:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>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.</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<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><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></body></html>