<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=utf-8">
<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:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* 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:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle22
{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="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Corey,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think this wording is more clear. I would still like to drop the requirement on invalidityDate, since Windows does not use this date.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Perhaps we should discuss on Thursday.<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 <cscwg-public-bounces@cabforum.org>
<b>On Behalf Of </b>Corey Bonnell via Cscwg-public<br>
<b>Sent:</b> Tuesday, September 21, 2021 11:03 AM<br>
<b>To:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>; cscwg-public@cabforum.org<br>
<b>Subject:</b> [EXTERNAL] Re: [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">Hi Dimitris,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> If the CA already knows that the Subscriber Private Key was compromised and malicious code was signed at a certain date in the past, we should allow the CRL to contain that agreed revocation date without requiring a first CRL and then
a "subsequent" CRL entry.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agreed, that is the intent. In addition to the case you mentioned, I also am attempting to address the case where a certificate is revoked (and CRLs/OCSP responses have already been published denoting the revoked status) but later it is
discovered that the certificate should be considered to be invalid starting from a different time. In this case, the CA should be able to change the revocationDate in subsequently published CRLs/OCSP responses to convey the new date.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I tweaked the wording as follows (made some changes to the existing third paragraph of 13.2.1 as well the new fourth paragraph):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:11.0pt"><span style="font-family:"Cambria",serif;mso-fareast-language:EN-US">“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 the time at which the Certificate is first considered to be invalid in the revocationDate field of a CRL entry or the revocationTime
field of a 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></span></p>
<p class="MsoNormal" style="margin-bottom:11.0pt"><span style="font-family:"Cambria",serif;mso-fareast-language:EN-US">If a Code Signing Certificate previously has been 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" style="margin-bottom:11.0pt"><span style="font-family:"Cambria",serif;mso-fareast-language:EN-US">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.”<o:p></o:p></span></p>
<p class="MsoNormal">Does this revised wording help to clarify?<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 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>>
<br>
<b>Sent:</b> Tuesday, September 21, 2021 2:01 AM<br>
<b>To:</b> Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>>;
<a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a><br>
<b>Subject:</b> Re: [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" style="margin-bottom:12.0pt">Hi Corey,<br>
<br>
If the CA already knows that the Subscriber Private Key was compromised and malicious code was signed at a certain date in the past, we should allow the CRL to contain that agreed revocation date without requiring a first CRL and then a "subsequent" CRL entry.<br>
<br>
<br>
Thanks,<br>
Dimitris.<o:p></o:p></p>
<div>
<p class="MsoNormal">On 20/9/2021 7:52 μ.μ., Corey Bonnell via Cscwg-public wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </span><o:p></o:p></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" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Cscwg-public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<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>
</body>
</html>