<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;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@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;
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.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri",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:70.85pt 85.05pt 70.85pt 85.05pt;}
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>Yes. Whether that’s the RIGHT proposal is debatable, but I think it’s a VALID proposal that should not be rejected as “non-compliant”.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If people think compliance requirements are important here, a good path would be an update to RFC 3647 that turns it into a normative document with requirements. I’m not a big fan of a constant stream of “clarifications” about what it means to “comply” with an informational document.<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> Inigo Barreira <Inigo.Barreira@sectigo.com> <br><b>Sent:</b> Monday, December 4, 2023 12:30 PM<br><b>To:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>; Tim Hollebeek <tim.hollebeek@digicert.com><br><b>Cc:</b> CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Subject:</b> RE: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=ES>Hi,<o:p></o:p></span></p><p class=MsoNormal><span lang=ES><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>I read also in this section 6, the following:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><pre><span lang=EN-GB>While use of an alternate outline is discouraged, it may be accepted if a proper justification is provided for the deviation and a mapping table is provided to readily discern where each of the items described in this outline is provided.<o:p></o:p></span></pre><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>I don´t know if it serves as “justification” the matching of the different numbers from section 11 to section 3.2 in a way of easing the checking by all interested third parties, considering that the adding of that section 3.2.1 with a “no stipulation” will add no value and will break all the numbering.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>I´m with Aaron in this case when he says “For whatever it's worth, I think that Section 11 of the current EVGs could be renumbered wholesale to become Section 3.2, retaining its subsections as-is, <b>with few or no issues</b>”, (emphasis mine).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Regards<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=ES>De:</span></b><span lang=ES> Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> <br><b>Enviado el:</b> sábado, 2 de diciembre de 2023 11:26<br><b>Para:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>>; Inigo Barreira <<a href="mailto:Inigo.Barreira@sectigo.com">Inigo.Barreira@sectigo.com</a>><br><b>CC:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Asunto:</b> Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES><o:p> </o:p></span></p><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span lang=ES 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.<o:p></o:p></span></p></div><p class=MsoNormal><span lang=ES><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES>We still have a disagreement so please allow me one more attempt to clarify my position because it seems you didn't check the links included in my previous post. I will copy some of that text here for convenience.<o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES>On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote:<o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>No.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>IETF has both Normative and Informative RFCs. While it is true that compliance with a Normative RFC is voluntary, if you do choose to comply, the RFC has requirements stated in RFC 2119 standards language that make it clear what the compliance rules are. Informative RFCs like 3647 do not have any normative requirements at all. They merely contain information.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>“all sections of the RFC 3647 framework” is fine, this covers the sections enumerated in RFC 3647 section 4, which includes the TOP TWO levels of an outline in numbered form, e.g. the requirements for section 3.2 are described in RFC 3647 section 4.3.2. There is no RFC 3647 section 4.3.2.1, which proves my point. RFC 3647 only has a two level outline structure.<o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>I think I might have a hint on our disconnect. RFC 3647 has an indicative Table of Contents in Chapter 6 (<a href="https://datatracker.ietf.org/doc/html/rfc3647#section-6">https://datatracker.ietf.org/doc/html/rfc3647#section-6</a>) outlining the proposed CP/CPS sections and subsections using 3 levels.<br><br>Here is the text of the opening paragraph of that section (emphasis added):<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><span lang=ES> This section contains a recommended outline for a set of provisions,<o:p></o:p></span></pre><pre><span lang=ES> intended to serve as a checklist or (with some further development) a<o:p></o:p></span></pre><pre><span lang=ES> standard template for use by CP or CPS writers. Such a common<o:p></o:p></span></pre><pre><span lang=ES> outline will facilitate:<o:p></o:p></span></pre><pre><span lang=ES><o:p> </o:p></span></pre><pre><span lang=ES> (a) Comparison of two certificate policies during cross-<o:p></o:p></span></pre><pre><span lang=ES> certification or other forms of interoperation (for the purpose<o:p></o:p></span></pre><pre><span lang=ES> of equivalency mapping).<o:p></o:p></span></pre><pre><span lang=ES><o:p> </o:p></span></pre><pre><span lang=ES> (b) Comparison of a CPS with a CP to ensure that the CPS faithfully<o:p></o:p></span></pre><pre><span lang=ES> implements the policy.<o:p></o:p></span></pre><pre><span lang=ES><o:p> </o:p></span></pre><pre><span lang=ES> (c) Comparison of two CPSs.<o:p></o:p></span></pre><pre><span lang=ES><o:p> </o:p></span></pre><pre><b><span lang=ES> In order to comply with the RFC, the drafters of a compliant CP or<o:p></o:p></span></b></pre><pre><b><span lang=ES> CPS are strongly advised to adhere to this outline.</span></b><span lang=ES> While use of an<o:p></o:p></span></pre><pre><span lang=ES> alternate outline is discouraged, it may be accepted if a proper<o:p></o:p></span></pre><pre><span lang=ES> justification is provided for the deviation and a mapping table is<o:p></o:p></span></pre><pre><span lang=ES> provided to readily discern where each of the items described in this<o:p></o:p></span></pre><pre><span lang=ES> outline is provided.<o:p></o:p></span></pre></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>The reason the CA/B Forum BRs were structured according to this outline was to assist with comparisons between CP/CPS documents of different CAs, making the review of these documents easier.<br><br>That's why you see sections like 1.5.4 "CPS approval procedures" in the BRs as an empty section with "No Stipulation". There are many such sections in the BRs, all coming from section 6 of RFC 3647.<br><br>I hope this is clearer now.<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>BR Section 2.2 needs to be re-written, as there are no materials required by RFC 3647 (because RFC 3647 contains no requirements). It needs to say something like “structured in accordance with RFC 3647 and MUST include all sections of the outline described in section 4” or something like that. What it says right now doesn’t capture the intent that you correctly summarized.<o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>During the last couple of years reviewing CP/CPS documents, I saw some uniformity at least in Publicly Trusted CAs, and they all seem to follow the BRs structure which comes from the outline of section 6 of RFC 3647. However, it's not a bad idea to further clarify BR section 2.2 to better meet the expectations.<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>The MSRP language is better, I think I may have made all of these same points when it was being drafted, which is why it says “section and subsection” (two levels) and uses “structured according to” and not “complies with the requirements of”.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>But anyway, this is all background that supports what I’ve been saying all along: BR 3.2 is a RFC 3647 section. BR 3.2.1 *<b>is not</b>* a RFC 3647 required section, nor is it even a section that is even mentioned in RFC 3647. If you don’t believe me, please go to RFC 3647, Section 4.3.2.1 and read what it says. OH, WAIT, IT DOESN’T EXIST! </span><span lang=ES style='font-family:"Segoe UI Emoji",sans-serif'>😊</span><span lang=ES><o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>To my point, BR 3.2.1 IS an RFC 3647 required section as it is explicitly mentioned in the outline of section 6 of RFC 3647:<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><span lang=ES>3.2.1 Method to prove possession of private key<o:p></o:p></span></pre></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>Details about the contents of that section can be found in the first bullet of <a href="https://datatracker.ietf.org/doc/html/rfc3647#section-4.3.2">section 4.3.2 of RFC 3647</a>. <br><br>Does that make more sense?<br><br>Dimitris.<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>-Tim<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <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 lang=ES>From:</span></b><span lang=ES> Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a> <br><b>Sent:</b> Friday, December 1, 2023 1:04 PM<br><b>To:</b> Tim Hollebeek <a href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a>; Inigo Barreira <a href="mailto:Inigo.Barreira@sectigo.com"><Inigo.Barreira@sectigo.com></a><br><b>Cc:</b> CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br><b>Subject:</b> Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES>Hi Tim,<br><br>None of the IETF standards set policy unless they are invited by some policy authority :) The BRs set such policy and "import" some documents, such as RFC 5280, 3647 and others.<br><br>The BRs in section 1.1 state:<br><br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted Certificates. In accordance with RFC 3647 and to facilitate a comparison of other certificate policies and CPSs (e.g. for policy mapping), this document includes all sections of the RFC 3647 framework. However, rather than beginning with a "no stipulation" comment in all empty sections, the CA/Browser Forum is leaving such sections initially blank until a decision of "no stipulation" is made<o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>In addition, section 2.2 states (emphasis added):<br><br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and <b>MUST include all material required by RFC 3647</b>.<o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>If you go back to the discussions when the CA/B Forum decide to align with the "RFC 3647 format", we agreed to include each and every section of the outline as a minimum set.<br><br>MRSP states in section 3.3 (5) (again, emphasis added):<br><br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>5. all CPs, CPSes, and combined CP/CPSes MUST be structured according to RFC 3647 and MUST:<br><br> - include <b>at least every section and subsection defined in RFC 3647</b>;<br> - only use the words "No Stipulation" to mean that the particular document imposes no requirements related to that section; and<br> - contain no sections that are blank and have no subsections;<o:p></o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES><br>So, with all that considered, when we visit <a href="https://datatracker.ietf.org/doc/html/rfc3647#section-6">section 6 of RFC 3647</a> ("the outline"), the expectation is to include each and every section and subsection of the outline (up to three levels).<br><br>CAs are free to add MORE sections and subsections as they desire, just like the BRs have done, but we can't escape or "hijack" an existing RFC 3647 section number. The outline contains a specific section labeled as "3.2.1 Method to prove possession of private key". That means we cannot re-use the number 3.2.1 for something else.<br><br>I hope this sounds reasonable to people.<br><br>Dimitris.<br><br><o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES>On 1/12/2023 6:51 μ.μ., Tim Hollebeek wrote:<o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>This is unfortunately wrong. There are lots of misconceptions about RFC 3647 “compliance”.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>The first point is that RFC 3647 is an INFORMATIONAL RFC. You can see this right at the top, where it says “Category: Informational”. This means that it contains no requirements and it’s impossible to be out of compliance with it. This is why I put quotes around “compliance”. Any requirements around it need to come from elsewhere, for example, a root program requirement that requires a particular document to be in RFC 3647 format. But that’s vague and informal, because 3647 doesn’t have requirements, it just has an outline and suggested contents. It’s not 100% precise what “MUST be in RFC 3647 format” means, and we need to just acknowledge that (specifying it precisely would be a colossal waste of time).<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>So what does “RFC 3647 format” mean? RFC 3647’s outline only covers the first two levels. So “Section 3.2: Initial Identity Validation” is a RFC 3647 section header, and most reasonable interpretations of “RFC 3647 format” would require it to exist with that or a substantially similar name and contents.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>Section 3.2.1, on the other hand, is not an RFC 3647 section. It’s common to have a third level of headers that mirror the “bullet points” in the suggested content for the section, but those are just unordered bullet lists in RFC 3647. Claiming that section 3.2.1 of a document in RFC 3647 must describe private key protection goes beyond what RFC 3647 says. Section 3.2 just “contains the following elements”, so private key protection is just one of several topics that one might discuss in section 3.2. It could be section 3.2.1, but it could be elsewhere in 3.2, and it’s perfectly fine for 3.2.1 to not exist, have different content, etc.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>Figuring out where section 11.1 goes is not trivial, but at first glance, section 3.2 is not an unreasonable choice, and I can understand why Inigo made it. And there isn’t a compliance reason why it can’t be section 3.2.1, if that’s what we want.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>Of course, we could convert the recommended bulleted sections to a numbered list of subsections (we often do elsewhere), in which case section 3.2.1 could be “Private Key Protection” with contents “No Stipulation”. If we do that, I suggest we follow the rest of the bullets as well.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>Either way works.<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=ES>-Tim<o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <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 lang=ES>From:</span></b><span lang=ES> Dimitris Zacharopoulos <a href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a> <br><b>Sent:</b> Friday, December 1, 2023 10:48 AM<br><b>To:</b> Inigo Barreira <a href="mailto:Inigo.Barreira@sectigo.com"><Inigo.Barreira@sectigo.com></a><br><b>Cc:</b> Tim Hollebeek <a href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a>; CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br><b>Subject:</b> Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES style='font-family:"Arial",sans-serif'>We MUST comply with RFC 3647 which means that we must include sections that are listed in the outline of 3647, and if we have nothing to say, we leave it empty. We can't "hijack" the numbering just because we have no requirements to describe. <br><br>That's my interpretation of the RFC 3647 compliance. Perhaps others can chime in and state their opinion. <br><br><br>Thanks, </span><span lang=ES><o:p></o:p></span></p></div><div><p><span lang=ES style='font-family:"Arial",sans-serif'>DZ.</span><span lang=ES><o:p></o:p></span></p></div><div><div><p><span lang=ES style='font-family:"Arial",sans-serif'>Dec 1, 2023 14:50:23 Inigo Barreira <<a href="mailto:Inigo.Barreira@sectigo.com">Inigo.Barreira@sectigo.com</a>>:</span><span lang=ES><o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 2.25pt;padding:0in 0in 0in 8.0pt;margin-left:0in;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>Thanks Dimitris.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>I think that strictly speaking, in RFC 3647 this section is the 4.3.2 Initial Identity Validation and the first bullet is about proving the possession of the private key, but there´s no specific section other than the general approach that we´ve implemented.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>That said, the current EVG does not include anything about the possession of the private key because that´s covered in the TLS BRs so that section does not exist in the EVGs and therefore I didn´t know how to avoid/implement it.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>I decided to continue with the normal numbering for an easy checking, so all 11 section is moved into section 3.2 and the rest of the sub-numbers do not change (so 11.1 would be 3.2.1, 11.1.1 would be 3.2.1.1, etc.)</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>I understand your point but I think we can´t create a section 3.2.1 for private key possession because there´s no such a text in the EVGs (and don´t think we should add anything new, even a NA for that) and don´t know which other sections we can create under 3.2 that can break the current equivalence, which again was done for an easy comparison. </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>So, what would you suggest to “comply” with that? I don´t have a clear idea.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Regards</span><span lang=ES><o:p></o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=ES style='mso-fareast-language:KO'>De:</span></b><span lang=ES style='mso-fareast-language:KO'> Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> <br><b>Enviado el:</b> jueves, 30 de noviembre de 2023 13:16<br><b>Para:</b> Inigo Barreira <<a href="mailto:Inigo.Barreira@sectigo.com">Inigo.Barreira@sectigo.com</a>>; Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Asunto:</b> Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot</span><span lang=ES><o:p></o:p></span></p></div></div><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span lang=ES style='font-size:10.0pt;color:black;mso-fareast-language:JA'>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><span lang=ES><o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES style='mso-fareast-language:JA'>Inigo,<br><br>As I am working to migrate the EV Guidelines into the EV Code Signing Baseline Requirements I took a look at the mapping you provided for the EV Guidelines and noticed that you are proposing migration of EVG section 11.1 into section 3.2.1. This particular section is labeled "Method to prove possession of private key" in RFC 3647 so I don't think it is appropriate. I think it's best to create new subsections under 3.2.<br><br>Thanks,<br>Dimitris.</span><span lang=ES><o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>On 8/9/2023 7:54 μ.μ., Inigo Barreira wrote:</span><span lang=ES><o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=ES>Hi all, <o:p></o:p></span></p><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Attached you´ll find the EVG v1.8.0 with comments in all sections indicating where those sections, and the content, have been moved into the new EVG RFC3647 format. So, with this document, plus the redlined version, I hope you can have now a clearer view of the changes done.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Let me know if you need anything else to clarify the new version.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Regards</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=ES style='mso-fareast-language:JA'>De:</span></b><span lang=ES style='mso-fareast-language:JA'> Inigo Barreira <a href="mailto:Inigo.Barreira@sectigo.com"><Inigo.Barreira@sectigo.com></a> <br><b>Enviado el:</b> martes, 29 de agosto de 2023 17:06<br><b>Para:</b> Tim Hollebeek <a href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a>; Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a>; CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br><b>Asunto:</b> RE: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot</span><span lang=ES><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Thanks Dimitris and Tim.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>I did something of that internally but didn´t reflect on the document, so will try to reproduce to have it clearer.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>OTOH, and as indicated in the PR, the whole section 11 has been placed in section 3.2 keeping the rest of the numbering. So, for example:</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>EVG EVG3647</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.1 3.2.1</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.1.1 3.2.1.1</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.1.2 3.2.1.2</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.1.3 3.2.1.3</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.2 3.2.2</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.2.1 3.2.2.1</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>….. …. </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.13 3.2.13</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.14 3.2.14</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.14.1 3.2.14.1</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.14.2 3.2.14.2</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>11.14.3 3.2.14.3</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Hope this can clarify the main difficult that I found in the document, where to place it and how.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Regards</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB> </span><span lang=ES><o:p></o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=EN-GB style='mso-fareast-language:JA'>De:</span></b><span lang=EN-GB style='mso-fareast-language:JA'> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>> <br><b>Enviado el:</b> martes, 29 de agosto de 2023 16:59<br><b>Para:</b> Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>>; Inigo Barreira <<a href="mailto:Inigo.Barreira@sectigo.com">Inigo.Barreira@sectigo.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Asunto:</b> RE: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot</span><span lang=ES><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span lang=ES style='font-size:10.0pt;color:black;mso-fareast-language:JA'>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><span lang=ES><o:p></o:p></span></p></div><p class=MsoNormal><span lang=ES style='font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Yes, exactly. I would like to see a list that shows that EVG-classic section 1.4 is now in EVG-3647 section 4.1. Then I can look at where the new text landed, see how the conversion was handled, we can all verify that nothing was lost or left out, etc.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Without that, anyone attempting to review the document is forced to recreate the mapping just to figure out where everything went and that nothing was missed or put in the wrong place. Redlines are not sufficient when large amounts of text are moving around to different places.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>I’m saying this because from my spot-checking, the conversion appears to be pretty good, and I’d like to be able to do a final verification that it’s mostly correct so I can endorse.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>-Tim</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><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 lang=ES style='mso-fareast-language:JA'>From:</span></b><span lang=ES style='mso-fareast-language:JA'> Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr"><span lang=EN-US>dzacharo@harica.gr</span></a>> <br><b>Sent:</b> Tuesday, August 29, 2023 7:58 AM<br><b>To:</b> Inigo Barreira <<a href="mailto:Inigo.Barreira@sectigo.com"><span lang=EN-US>Inigo.Barreira@sectigo.com</span></a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org"><span lang=EN-US>servercert-wg@cabforum.org</span></a>>; Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com"><span lang=EN-US>tim.hollebeek@digicert.com</span></a>><br><b>Subject:</b> Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot</span><span lang=ES><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES style='mso-fareast-language:JA'>Hi Inigo,<br><br>You can take some guidance from previous successful efforts to convert existing documents into RFC 3647 format. The latest attempt was in the Code Signing BRs conversion in May 2022. Check out the mapping document and the comments in the <a href="https://lists.cabforum.org/pipermail/cscwg-public/2022-May/000795.html"><span lang=EN-US>ballot discussion period</span></a>.<br><br>For each existing section/paragraph, it would be nice to have a comment describing where that existing language will land in the converted document (destination). This will allow all existing text to be accounted for.<br><br>During this process, you might encounter duplicate or redundant text which needs to be flagged accordingly. You might also get into some uncertainty as to which RFC3647 section is a best fit for existing text that might require additional discussion. <br><br>I hope this helps.<br><br><br>Dimitris.</span><span lang=ES><o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>On 29/8/2023 12:42 μ.μ., Inigo Barreira via Servercert-wg wrote:</span><span lang=ES><o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'>Hi Tim,</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'>See attached redlined and current versions. I just used what Martijn suggested yesterday but let me know if this is what you were looking for.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'>Regards</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=ES style='mso-fareast-language:JA'>De:</span></b><span lang=ES style='mso-fareast-language:JA'> Tim Hollebeek <a href="mailto:tim.hollebeek@digicert.com"><span lang=EN-US><tim.hollebeek@digicert.com></span></a> <br><b>Enviado el:</b> lunes, 28 de agosto de 2023 19:49<br><b>Para:</b> Inigo Barreira <a href="mailto:Inigo.Barreira@sectigo.com"><span lang=EN-US><Inigo.Barreira@sectigo.com></span></a>; CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org"><span lang=EN-US><servercert-wg@cabforum.org></span></a><br><b>Asunto:</b> RE: SC-065: Convert EVGs into RFC 3647 format pre-ballot</span><span lang=ES><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span lang=ES style='font-size:10.0pt;color:black;mso-fareast-language:JA'>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><span lang=ES><o:p></o:p></span></p></div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Thanks for doing this Inigo … I know re-organizations like this are a lot of work and fall very much in the category of “important but not fun”. So thanks for taking an initial stab at this.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Is there a mapping that shows where all the original text ended up? I think that’s going to be essential for people to be able to review this. I did some spot checking, and your conversion looks pretty good, but I wasn’t able to do a more detailed review without a mapping.</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>-Tim</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><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 lang=ES style='mso-fareast-language:JA'>From:</span></b><span lang=ES style='mso-fareast-language:JA'> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org"><span lang=EN-US>servercert-wg-bounces@cabforum.org</span></a>> <b>On Behalf Of </b>Inigo Barreira via Servercert-wg<br><b>Sent:</b> Monday, August 28, 2023 5:20 AM<br><b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org"><span lang=EN-US>servercert-wg@cabforum.org</span></a>><br><b>Subject:</b> [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot</span><span lang=ES><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Hello,</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>The current Extended Validation Guidelines (EVGs) are written in a non-standardized format. For many years it has been discussed to convert this document into the RFC 3647 format and follow the standardized model for this type of documents. </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Given that this has been known for several years, I have prepared the following ballot text, which converts the EVGs into the RFC 3647 format:</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'><a href="https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/440___.YXAzOmRpZ2ljZXJ0OmE6bzoyOGIxNWVhZGVmZDlkZTM0NjQzZTA3YTlmYTA2MzM5YTo2OmExZWM6NGZmMGEzM2U0ZWZjOTU4MTM1NWRkNjU3ZDE5YjU3Y2YxNzg1NWU0ZTVjYzkzY2NjM2M0MWU5MzEyYzJmZTQ0NzpoOkY" title="Protected by Avanan: https://github.com/cabforum/servercert/pull/440"><span lang=EN-GB>EVGs based on RFC3647 by barrini · Pull Request #440 · cabforum/servercert (github.com)</span></a></span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>I am currently seeking two endorsers as well as any feedback on the ballot content itself (wording, effective dates, etc.).</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'>Thanks,</span><span lang=ES><o:p></o:p></span></p><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p><pre><span lang=ES style='mso-fareast-language:JA'>_______________________________________________</span><span lang=ES><o:p></o:p></span></pre><pre><span lang=ES style='mso-fareast-language:JA'>Servercert-wg mailing list</span><span lang=ES><o:p></o:p></span></pre><pre><span lang=ES style='mso-fareast-language:JA'><a href="mailto:Servercert-wg@cabforum.org"><span lang=EN-US>Servercert-wg@cabforum.org</span></a></span><span lang=ES><o:p></o:p></span></pre><pre><span lang=ES style='mso-fareast-language:JA'><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"><span lang=EN-US>https://lists.cabforum.org/mailman/listinfo/servercert-wg</span></a></span><span lang=ES><o:p></o:p></span></pre></blockquote><p class=MsoNormal><span lang=ES style='mso-fareast-language:JA'> </span><span lang=ES><o:p></o:p></span></p></div></div></blockquote></div></blockquote></div></div></blockquote><p class=MsoNormal><span lang=ES> <o:p></o:p></span></p></div></blockquote><p class=MsoNormal><span lang=ES><o:p> </o:p></span></p></div></div></div></body></html>