<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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:"MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
{font-family:"\@MS PGothic";}
/* 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;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
{mso-style-name:x_msonormal;
margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xxmsonormal, li.xxmsonormal, div.xxmsonormal
{mso-style-name:x_xmsonormal;
margin:0in;
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:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.xxxmsonormal, li.xxxmsonormal, div.xxxmsonormal
{mso-style-name:x_xxmsonormal;
margin:0in;
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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2005426167;
mso-list-template-ids:-2006794170;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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>Totally agree, Rob. If CAs are expected to do something, then clear requirements need to find their way into the BRs or one or more root programs (preferably the BRs, for the reasons outlined in the preamble to Ballot SC31). It’s fine if there are private communications, negotiations, and agreements in the meantime (e.g. in response to incidents), but the expectations need to find their way to requirements eventually.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There have been some experiments in the past few years with approaches like “in order to understand our expectations, please read and comply with all the emails we have ever sent.” Having actually done that a few times in an attempt to distill the relevant requirements, I can confidently say that, in my view, those experiments have ended badly, and we should return to clear requirements in standards documents that impose uniform expectations on all participants. If there are expectations that are important enough to be enforced, we should write them up and ballot them so that they are audited, and everyone is 100% clear on exactly what they are.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Rob Stradling <rob@sectigo.com> <br><b>Sent:</b> Thursday, September 23, 2021 9:46 AM<br><b>To:</b> Bruce Morton <bruce.morton@entrust.com>; Tim Hollebeek <tim.hollebeek@digicert.com>; cscwg-public@cabforum.org; Corey Bonnell <Corey.Bonnell@digicert.com><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><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'>I agree that there's no rush. And yes, CAs have done everything right if they've implemented the traditional RFC5280 behaviour and weren't asked by Microsoft to do otherwise.<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'>My primary concern is that I'm super keen for Sectigo's compliance status to stop being reliant on a decade-old private communication from Tom Albertson! In my view, if Microsoft wants CAs to do something that's contrary to RFC5280, then Microsoft really needs to state this in their public root program policy requirements (either directly by including explicit language, or indirectly by incorporating a CABForum specification that states this). The public requirements are what our auditors are going to look at and judge us on.<o:p></o:p></span></p></div><div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p><div class=MsoNormal align=center style='text-align:center'><span style='font-size:12.0pt;color:black'><hr size=2 width="98%" align=center></span></div><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From:</span></b><span style='font-size:12.0pt;color:black'> Bruce Morton<br><b>Sent:</b> Wednesday, September 22, 2021 20:35<br><b>To:</b> Tim Hollebeek; Rob Stradling; <a href="mailto:cscwg-public@cabforum.org">cscwg-public@cabforum.org</a>; Corey Bonnell<br><b>Subject:</b> RE: CRL Revocation Date Clarification Pre-Ballot <o:p></o:p></span></p><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p></div></div><div><div><div><p class=xmsonormal>I’m in agreement with the direction. I think we need to confirm the SHALL(s) and/or the SHOULD(s) and allow some time for the CAs to get implemented.<o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>Thanks, Bruce.<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 0in 0in 0in'><p class=xmsonormal><b>From:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>> <br><b>Sent:</b> Wednesday, September 22, 2021 3:33 PM<br><b>To:</b> Rob Stradling <<a href="mailto:rob@sectigo.com">rob@sectigo.com</a>>; 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: CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>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=1 width="100%" align=center></div><p class=xmsonormal>Yeah, if there isn’t a good reason to allow what I called (2), I’m also fine with banning invalidityDate, with a reasonable implementation timeline for CAs that have historically had a different interpretation, since at least one seems to exist. I don’t really see any reason to force people to rush this, since it’s really just a minor ecosystem cleanup. And I do have a lot of sympathy for people who implemented traditional RFC 5280 behavior instead of the Microsoft-specific behavior.<o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><p class=xmsonormal>-Tim<o:p></o:p></p><p class=xmsonormal> <o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=xmsonormal><b>From:</b> Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>> <br><b>Sent:</b> Wednesday, September 22, 2021 12:47 PM<br><b>To:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; Bruce Morton <<a href="mailto:bruce.morton@entrust.com" target="_blank">bruce.morton@entrust.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>; Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>><br><b>Subject:</b> Re: CRL Revocation Date Clarification Pre-Ballot<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'>> 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.</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'>+1</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'>> This won’t necessarily do what you want for Microsoft, but may make sense in other ecosystems.</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'>Which other ecosystems do we expect to consume the Code Signing BRs? Do any of these ecosystems support the Invalidity Date extension? (I don't think it makes sense to make guesses about what may make sense </span><span style='font-size:12.0pt;font-family:"Segoe UI Emoji",sans-serif;color:black'>😉</span><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'> </span><o:p></o:p></p></div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'>> I don’t think there’s a good reason to ban RFC 5280-compliant behavior here.</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'>As I mentioned in the previous list thread on this topic: Sectigo is already banned (we believe) from using the RFC5280-compliant behaviour in Microsoft's ecosystem, because Tom Albertson sent us a private email on behalf of the Microsoft Root Program asking us to always put the invalidity date in the revocationDate field, and because Ian said recently "we expect CAs to continue to use the RevocationDate field as they do today".</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'>Unless there are other code signing ecosystems that support the Invalidity Date extension, I propose that we require the revocationDate field to hold the invalidity date and say "The Invalidate Date extension MUST NOT be present", since there's no point bloating CRLs with two copies of each invalidity date and because this approach would sidestep the question of what to do if the revocationDate field and the Invalidity Date extension differ.</span><o:p></o:p></p></div><div><div><p class=xmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><span style='font-size:12.0pt;color:black'><hr size=1 width="98%" align=center></span></div><p class=xmsonormal><b><span style='font-size:12.0pt;color:black'>From:</span></b><span style='font-size:12.0pt;color:black'> Tim Hollebeek<br><b>Sent:</b> Wednesday, September 22, 2021 17:27<br><b>To:</b> Bruce Morton; Rob Stradling; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>; Corey Bonnell<br><b>Subject:</b> RE: CRL Revocation Date Clarification Pre-Ballot </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><div><div><div><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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?<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>We’d end up with two allowed behaviors:<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><ol style='margin-top:0in' start=1 type=1><li class=xxmsolistparagraph style='margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo1'>if the revocationDate is the invalidity date (for compatibility with the Microsoft implementation) then the invalidityDate, if it appears, must agree, or<o:p></o:p></li><li class=xxmsolistparagraph style='margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo1'>if the revocationDate is the actual revocation date (for strict 5280 compliance), then the invalidityDate MAY be present and MAY be different.<o:p></o:p></li></ol><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>-Tim<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=xxmsonormal><b>From:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com" target="_blank">Bruce.Morton@entrust.com</a>> <br><b>Sent:</b> Wednesday, September 22, 2021 11:51 AM<br><b>To:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>; Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>><br><b>Subject:</b> RE: CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=xxmsonormal><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'> </span><o:p></o:p></p><p class=xxmsonormal>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? <o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>I think this ballot should be about providing an RFC exception for revocationDate.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>Bruce.<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 0in 0in 0in'><p class=xxmsonormal><b>From:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>> <br><b>Sent:</b> Wednesday, September 22, 2021 11:39 AM<br><b>To:</b> Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>; Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>>; Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com" target="_blank">Bruce.Morton@entrust.com</a>><br><b>Subject:</b> [EXTERNAL] RE: CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=xxmsonormal><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'> </span><o:p></o:p></p><p class=xxmsonormal><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'>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.</span><o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'><hr size=0 width="100%" align=center></span></div><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>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.<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><p class=xxmsonormal>-Tim<o:p></o:p></p><p class=xxmsonormal> <o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=xxmsonormal><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org" target="_blank">cscwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Rob Stradling via Cscwg-public<br><b>Sent:</b> Tuesday, September 21, 2021 11:49 AM<br><b>To:</b> Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>; Bruce Morton <<a href="mailto:bruce.morton@entrust.com" target="_blank">bruce.morton@entrust.com</a>><br><b>Subject:</b> Re: [Cscwg-public] CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=xxmsonormal><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'> </span><o:p></o:p></p><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black;background:white'>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...</span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'>In the Server Certificate BRs, "Application of RFC 5280" describes a scenario (Precertificates) where RFC5280 does <u>not</u> apply at all; whereas what I think we're trying to do here is specify that RFC5280 <u>does</u> 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.</span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'>I think the most similar concept in the Server Certificate BRs is the language about non-critical Name Constraints:</span><o:p></o:p></p></div><div><div><p class=xxmsonormal><i><span style='font-size:12.0pt;color:black'>"Non‐critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until</span></i><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p><div><p class=xxmsonormal><i><span style='font-size:12.0pt;color:black'>the Name Constraints extension is supported by Application Software Suppliers whose software is used by</span></i><o:p></o:p></p></div><p class=xxmsonormal><i><span style='font-size:12.0pt;color:black'>a substantial portion of Relying Parties worldwide."</span></i><o:p></o:p></p></div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'>The effect of this text is that RFC5280 <u>does</u> 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).</span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'>How about adding this language to the ballot...</span><o:p></o:p></p></div><div><p class=xxmsonormal><i><span style='font-size:12.0pt;color:black'>'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)."</span></i><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'>Or, if we're hoping that this RFC5280 deviation will be temporary, how about...</span><o:p></o:p></p></div><div><p class=xxmsonormal><i><span style='font-size:12.0pt;color:black;background:white'>'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."</span></i><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black;background:white'>WDYT?</span><o:p></o:p></p></div><div><div><p class=xxmsonormal><span style='font-size:12.0pt;color:black'> </span><o:p></o:p></p></div><div class=MsoNormal align=center style='text-align:center'><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'><hr size=0 width="98%" align=center></span></div><div id="x_x_divRplyFwdMsg"><p class=xxmsonormal><b><span style='color:black'>From:</span></b><span style='color:black'> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org" target="_blank">cscwg-public-bounces@cabforum.org</a>> on behalf of Bruce Morton via Cscwg-public <<a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>><br><b>Sent:</b> 21 September 2021 16:04<br><b>To:</b> Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a> <<a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a>><br><b>Subject:</b> Re: [Cscwg-public] CRL Revocation Date Clarification Pre-Ballot</span><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'> </span><o:p></o:p></p><div><p class=xxmsonormal><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'> </span><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=xxmsonormal 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=xxmsonormal><span style='font-size:12.0pt;font-family:"MS PGothic",sans-serif'> </span><o:p></o:p></p><div><div><p class=xxxmsonormal>Hi Corey,<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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.”<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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.<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>Bruce.<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=xxxmsonormal><b>From:</b> Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>> <br><b>Sent:</b> Tuesday, September 21, 2021 8:45 AM<br><b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com" target="_blank">Bruce.Morton@entrust.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a><br><b>Subject:</b> [EXTERNAL] RE: CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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=0 width="100%" align=center></div><p class=xxxmsonormal>Hi Bruce,<o:p></o:p></p><p class=xxxmsonormal>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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>Thanks,<o:p></o:p></p><p class=xxxmsonormal>Corey<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>[1] <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fcscwg-public%2F2021-September%2F000532.html&data=04%7C01%7Crob%40sectigo.com%7C0d12b84938cc4d7ed05208d97d1118a7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637678334657724301%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0y8EPWbaEx8JjusdPkaCY%2F6AZTmk3mzEJxeQuPv5yhk%3D&reserved=0" target="_blank">https://lists.cabforum.org/pipermail/cscwg-public/2021-September/000532.html</a><o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=xxxmsonormal><b>From:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com" target="_blank">Bruce.Morton@entrust.com</a>> <br><b>Sent:</b> Monday, September 20, 2021 2:31 PM<br><b>To:</b> Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>>; <a href="mailto:cscwg-public@cabforum.org" target="_blank">cscwg-public@cabforum.org</a><br><b>Subject:</b> RE: CRL Revocation Date Clarification Pre-Ballot<o:p></o:p></p></div></div><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>Hi Corey,<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>Bruce.<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=xxxmsonormal><b>From:</b> Cscwg-public <<a href="mailto:cscwg-public-bounces@cabforum.org" target="_blank">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" target="_blank">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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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=0 width="100%" align=center></div><p class=xxxmsonormal>Hello,<o:p></o:p></p><p class=xxxmsonormal>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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>For reference, here are the two proposed paragraphs to be added to 13.2.1:<o:p></o:p></p><p class=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal><span style='font-size:10.0pt;font-family:"Courier New",serif'>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=xxxmsonormal><span style='font-size:10.0pt;font-family:"Courier New",serif'> </span><o:p></o:p></p><p class=xxxmsonormal><span style='font-size:10.0pt;font-family:"Courier New",serif'>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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>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=xxxmsonormal> <o:p></o:p></p><p class=xxxmsonormal>Thanks,<o:p></o:p></p><p class=xxxmsonormal>Corey<o:p></o:p></p><p class=xxxmsonormal><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></div></div></div></div></div></div></div></div></body></html>