<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:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@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:Aptos;}
@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:12.0pt;
        font-family:"Aptos",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.apple-converted-space
        {mso-style-name:apple-converted-space;}
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:"Aptos",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@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><span style='font-size:11.0pt'>That’s a fair point, and thank you for the additional discussion. There is in fact a large grey area between black and white, as there usually is.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>The reason this one crossed the line into a normative requirement for me was largely because it defined a Date of Formation, and then was talking about how that date should be formatted (which requires usage and context), which I personally think is clearly outside the boundaries of what a Date of Formation *<b>is</b>*.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>The  gray area is exactly where you describe, where there can be disagreements about what is an essential property of a thing, and what are requirements around a thing. For example, if you had written:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Date of Formation: A ten character string that specifies the date where a Legal Entity was first recognized by the jurisdiction in which it was created or formed, in the form of a </span><span style='font-size:11.0pt'>complete representation of an extended format calendar date (“YYYY-MM-DD”) in ISO 8601.</span><span style='font-size:11.0pt'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Then that clearly defines a thing. I don’t like defining it that way, but it works. We’re now defining a string, and characterizing its contents independently of any requirements of how it gets used. The definition is self-contained and the world is good again. Sort of.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Forward and up,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>-Tim<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></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><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Clint Wilson <clintw@apple.com> <br><b>Sent:</b> Wednesday, August 28, 2024 4:25 PM<br><b>To:</b> Tim Hollebeek <tim.hollebeek@digicert.com><br><b>Cc:</b> CABforum3 <validation@cabforum.org>; Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr><br><b>Subject:</b> Re: [cabf_validation] Proposed ballot on improving Registration Number language in EVGs<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This is helpful. <o:p></o:p></p><div><p class=MsoNormal>To be clear, I agree that normative requirements should be avoided in definitions, however based on your response to this proposed definition change, it’s also clear there’s some difference of opinion on what counts as (or doesn’t) a normative requirement. For example, what sections of the (T/S/CS)BRs constitute the body of the document? Is it just Section 1.6 that should be void of normative requirements? Should normative requirements be pulled out of Section 1 entirely? Since we don’t introduce RFC 2119 language until Section 1.6.4, does that mean all uses of those terms in prior sections are incorrect in some way? How would such a shift impact maintainability of the document, for example in a scenario where a defined term has its requirements pulled into a separate section, but then a later usage of that term doesn’t remember to include these “extra” properties of the term as used in a specific section?<o:p></o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>When I think of a definition, I assume two basic components: the term being defined and the exact meaning of a word, including the properties, attributes, or characteristics that term and meaning encompass. For example, I don’t see the definition of Random Value as containing normative requirements; rather, it’s describing that in order for a random value to <i>be</i> a random value, it needs to exhibit 112 bits of entropy. Is there a “MUST” implied in the requirement that the Reliable Method of Communication be verified by the CA? Should Wildcard Domain Name not specify the unicode character codes of the defined characters?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>When I think about pulling normative requirements out of definitions, I’m thinking more of terms like Request Token (because it does clearly espouse sets of interacting requirements and options) and Authorization Domain Name (because the concept is complex enough to warrant expansion in the context of its use rather than solely within the definition). <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>My suggestion of including the format in the definition for Date of Formation was intended to convey that this formatting is an intrinsic property of the thing being defined. Moving that down into the profile section is completely acceptable to me. The related suggestion that this property of the defined term is a requirement that <i>can't</i> be included in a definition has me confused about the actual expected outcome to <span style='color:black'>the content, organization, and accessibility of the BRs if that </span>statement is applied at face value.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal>-Clint<o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Aug 27, 2024, at 9:58<span style='font-family:"Arial",sans-serif'> </span>AM, Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt'>My opinion is that all requirements need to be stated in RFC 2119 language and be present in the body of the document in order to be treated as normative requirements. That should be an uncontroversial view. I suspect our auditor friends have a similar view. I don’t think it’s a particularly hard line or strict view, it’s just what’s necessary to prevent ambiguity as to what the requirements are.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'>I would be fine with once in the section. Something along the lines of “The Date of Formation MUST be formatted according to the complete representation of an extended format calendar date in ISO 8601 (i.e. YYYY-MM-DD; e.g. 0001-01-01).”</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'>-Tim</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;border-color:currentcolor currentcolor currentcolor blue;border-image: none'><div><div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentcolor currentcolor;border-image: none'><div><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span class=apple-converted-space><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span></span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Clint Wilson <<a href="mailto:clintw@apple.com">clintw@apple.com</a>><span class=apple-converted-space> </span><br><b>Sent:</b><span class=apple-converted-space> </span>Tuesday, August 27, 2024 9:06 AM<br><b>To:</b><span class=apple-converted-space> </span>Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>>; CABforum3 <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>><br><b>Cc:</b><span class=apple-converted-space> </span>Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>><br><b>Subject:</b><span class=apple-converted-space> </span>Re: [cabf_validation] Proposed ballot on improving Registration Number language in EVGs</span><o:p></o:p></p></div></div></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>Hi Tim,<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>I think including the format of this specific date type in the definition is totally reasonable, given that it’s not applicable to any other date types and so can very much exist intrinsically as part of the definition. That is, I don’t agree with the seemingly hard line you’re drawing in your statement — and, even moreso, I don’t believe such a statement is backed by consensus within the Forum so I also don’t want it construed as more than your opinion, as indeed is my above statement that it can be part of the definition.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>All that said, I do agree putting it in-line in the EVGs would work just fine too. Are you then imagining we would repeat this format requirement alongside each of the four times the term is used in 7.1.4.2.5 or just state it once somewhere in that section? Do you have some example text you can provide to show what you’re proposing as an alternative approach?<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Thank you,<o:p></o:p></p></div></div><div><div><p class=MsoNormal>-Clint<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><br><o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal>On Aug 26, 2024, at 10:32<span style='font-family:"Arial",sans-serif'> </span>AM, Tim Hollebeek via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<o:p></o:p></p></div></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>This is a requirement, and any requirements around how dates should be formatted need to be stated as such in the appropriate profile section. It MUST NOT be stated in the definition.</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>-Tim</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div></div><div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;border-color:currentcolor currentcolor currentcolor blue;border-image: none'><div><div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentcolor;border-image: none'><div><div><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span class=apple-converted-space><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span></span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Validation <<a href="mailto:validation-bounces@cabforum.org">validation-bounces@cabforum.org</a>><span class=apple-converted-space> </span><b>On Behalf Of<span class=apple-converted-space> </span></b>Dimitris Zacharopoulos (HARICA) via Validation<br><b>Sent:</b><span class=apple-converted-space> </span>Friday, August 23, 2024 2:26 AM<br><b>To:</b><span class=apple-converted-space> </span>CABforum3 <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>><br><b>Subject:</b><span class=apple-converted-space> </span>Re: [cabf_validation] Proposed ballot on improving Registration Number language in EVGs</span><o:p></o:p></p></div></div></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p><div><div><div><p class=MsoNormal>On 16/8/2024 2:53 π.μ., Clint Wilson via Validation wrote:<o:p></o:p></p></div></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal>Hi Corey,<span class=apple-converted-space> </span><o:p></o:p></p></div></div><div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal>Overall this seems like a good improvement to clarity of the current expectations related to these sections of the EVGs, reflecting the predominant approach to populating the subject:serialNumber field for EV TLS certificates. I do think it would be valuable to standardize on a date format (admittedly somewhat because it feels like a missed opportunity to not do so). What about something like modifying the newly added definition:<o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><blockquote style='margin-left:30.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>**Date of Formation**: The date on which a Legal Entity is first recognized by the jurisdiction in which it was created or formed. The date is formatted according to the complete representation of an extended format calendar date in ISO 8601 (i.e. YYYY-MM-DD; e.g. 0001-01-01).<o:p></o:p></p></div></div></div></blockquote></blockquote><div><div><p class=MsoNormal><br>Hi Clint,<br><br>I'm in favor of examples where they help avoid unintended mistakes, so I would support adding something like "e.g. 2000-12-31" to make it abundantly clear where the month and day is supposed to be represented.<br><br><br>Thanks,<br>Dimitris.<br><br><br><br><br><o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal>The parenthetical is probably too much, but you get the idea. And then the three instances of "in any one of the common date formats” could just be deleted.<o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal>-Clint<o:p></o:p></p></div></div><div><div><div><p class=MsoNormal><br><br><br><br><o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>On Aug 9, 2024, at 8:55<span style='font-family:"Arial",sans-serif'> </span>AM, Corey Bonnell via Validation<span class=apple-converted-space> </span><a href="mailto:validation@cabforum.org"><validation@cabforum.org></a>wrote:<o:p></o:p></p></div></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>Hello,</span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>Some time ago, I presented [1] a ballot proposal on improving the requirements for the Registration Number value in the EVGs. Here is the current proposal:<span class=apple-converted-space> </span><a href="https://github.com/cabforum/servercert/compare/main...CBonnell:servercert:govt-entity-serial-number"><span style='color:#467886'>https://github.com/cabforum/servercert/compare/main...CBonnell:servercert:govt-entity-serial-number</span></a>.</span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>On the call where the proposal was presented, there was a desire to explore standardizing date formats for the Date of Formation. Is this something that we would like to see added to the ballot? For the sake of minimizing scope of the ballot, I’m in favor of moving forward without such a requirement, but will certainly be happy to incorporate if there are strong feelings that such a requirement should be added in this ballot.</span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>Thanks,</span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>Corey</span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div></div></div><div><div><div><p class=MsoNormal><span style='font-size:11.0pt'>[1]<span class=apple-converted-space> </span><a href="https://lists.cabforum.org/pipermail/validation/2024-July/001997.html"><span style='color:#467886'>https://lists.cabforum.org/pipermail/validation/2024-July/001997.html</span></a></span><o:p></o:p></p></div></div></div><div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>_______________________________________________<br>Validation mailing list<br></span><a href="mailto:Validation@cabforum.org"><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#467886'>Validation@cabforum.org</span></a><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'><br></span><a href="https://lists.cabforum.org/mailman/listinfo/validation"><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#467886'>https://lists.cabforum.org/mailman/listinfo/validation</span></a><o:p></o:p></p></div></div></div></blockquote></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><div><div><p class=MsoNormal><br><br><br><br><o:p></o:p></p></div></div><pre>_______________________________________________<o:p></o:p></pre><pre>Validation mailing list<o:p></o:p></pre><pre><a href="mailto:Validation@cabforum.org">Validation@cabforum.org</a><o:p></o:p></pre><pre><a href="https://lists.cabforum.org/mailman/listinfo/validation">https://lists.cabforum.org/mailman/listinfo/validation</a><o:p></o:p></pre></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica",sans-serif'>_______________________________________________<br>Validation mailing list<br><a href="mailto:Validation@cabforum.org">Validation@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/validation">https://lists.cabforum.org/mailman/listinfo/validation</a></span><o:p></o:p></p></div></div></blockquote></div></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></div></body></html>