<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)"><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;}
/* 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;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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>Hey Aaron,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thank you very much for this detailed analysis. As I mentioned on yesterday’s validation call, this is exactly the sort of risk I’m concerned about with this ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks for catching the leap second issue. I think it’s important that we resolve that and have a consistent way of converting days -> seconds throughout the document.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If you would like to take a whack at proposed text to fix it, I’m listening and interested.<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> Aaron Gable <aaron@letsencrypt.org> <br><b>Sent:</b> Thursday, November 18, 2021 3:52 PM<br><b>To:</b> Tim Hollebeek <tim.hollebeek@digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Subject:</b> Re: [Servercert-wg] Discussion Period Begins: SC-52: Specify CRL Validity Intervals in Seconds<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Throughout the BRs, there are many different kinds of time intervals:<br>- how long a cert is valid<br>- how long a CRL is valid<br>- how long an OCSP response is valid<br>- how long a validation document can be used<br>- how long a random value can be used<br>- how long a CA has to perform a revocation<br>- how quickly CAs must provide their first audit and disclose CPS changes in CCADB<br><br>Although the purpose of this ballot is focused on CRLs, I think there are two things we need to notice about it:<br><br>First, by moving the declaration of how differences are counted into Section 1.6.4 Conventions, this method of computing time differences *does* apply to validation documents, random values, and all other time intervals. CAs should be aware that these lifetimes will now be measured to the precision of seconds, and should take care to ensure that they are not (e.g.) reusing validation documents right up against the limit.<br><br>This does introduce a slight issue, in that some of these other intervals express some of their timetables in terms of days (now very precise) and some of their timetables in months (still imprecise). But that can be solved in a follow-up ballot.<br><br>Second, although this ballot does not *change* how OCSP validity intervals are calculated, I believe that it does increase the chances of confusion on how to do so. Calling out three lines from the ballot diff:<br><br>Section 1.6.1 Definitions:<br>> **Validity Interval**: For CRLs and OCSP responses, the difference in time between the thisUpdate and nextUpdate field, inclusive.<br><br>Section 1.6.4 Conventions:<br>> **Effective 2022-06-01:** For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional unit of measure, such as an additional hour or additional day.<br><br>Section 4.9.10 On-line revocation checking requirements<br>> For the purpose of computing an OCSP Validity Interval, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.<br><br>The first two quotes appear to combine to say that, for OCSP responses, the validity interval shall be the difference in time between the thisUpdate and the nextUpdate, and that any amount of time greater than that (such as leap seconds) shall represent an additional day of validity interval. However, this definition is then superseded by 4.9.10, which says that OCSP validity intervals ignore leap seconds.<br><br>I believe that the BRs should unify on either always including leap seconds (and that therefore CAs should be careful to not run right up against the limits, in case a leap second is inserted), or on always ignoring leap seconds. In particular, I propose the following text be included in section 4.9.10 in this ballot:<br>> **Effective prior to 2022-06-01:** For the purpose of computing an OCSP Validity Interval, a difference... <br><br>If folks believe that that change should not be included in this ballot, then I think that this ballot should not attempt to unify the calculation of the validity interval for OCSP and CRLs, as doing so leads to this confusion.<br><br>Aaron<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Nov 18, 2021 at 7:43 AM Tim Hollebeek via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ballot SC-52: Specify CRL Validity Intervals in Seconds<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Purpose of Ballot: Similar to Ballot SC-31 which modified the specification of<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>OCSP validity periods to be in seconds, this ballot modifies the specification<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>of CRL validity periods to be in seconds to avoid confusion about exactly which<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>periods are valid and which are not. The ballot also specifies that other time <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>periods should be handled the same way, which has broader impacts throughout <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>the document.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The following motion has been proposed by Tim Hollebeek of DigiCert and endorsed <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>by Trevoli Ponds-White of Amazon and Kati Davids of GoDaddy.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>---MOTION BEGINS---<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This ballot modifies the “Baseline Requirements for the Issuance and Management <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 1.8.0:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>MODIFY the Baseline Requirements as specified in the following Redline:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...0c265a673b10c460264a721214b902484c0d1c1f" target="_blank">https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...0c265a673b10c460264a721214b902484c0d1c1f</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>---MOTION ENDS---<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This ballot proposes a Final Maintenance Guideline. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The procedure for approval of this ballot is as follows: <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Discussion (7+ days)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Start Time: November 18, 2021 10:30am Eastern<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>End Time: No earlier than November 25, 2021 10:30 am Eastern<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Vote for approval (7 days)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Start Time: TBD<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>End Time: TBD<o:p></o:p></p></div></div><p class=MsoNormal>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p></blockquote></div></div></div></div></body></html>