<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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.<br>
<br>
<div class="moz-cite-prefix">On 1/12/2023 11:31 μ.μ., Tim Hollebeek
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SN7PR14MB6492F5F9CD33A778470BBC7A8381A@SN7PR14MB6492.namprd14.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}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.EmailStyle22
{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;}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]-->
<div class="WordSection1">
<p class="MsoNormal">No.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">“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.</p>
</div>
</blockquote>
<br>
I think I might have a hint on our disconnect. RFC 3647 has an
indicative Table of Contents in Chapter 6
(<a class="moz-txt-link-freetext" 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>
<blockquote type="cite">
<pre class="newpage"> This section contains a recommended outline for a set of provisions,
intended to serve as a checklist or (with some further development) a
standard template for use by CP or CPS writers. Such a common
outline will facilitate:
(a) Comparison of two certificate policies during cross-
certification or other forms of interoperation (for the purpose
of equivalency mapping).
(b) Comparison of a CPS with a CP to ensure that the CPS faithfully
implements the policy.
(c) Comparison of two CPSs.
<b> In order to comply with the RFC, the drafters of a compliant CP or
CPS are strongly advised to adhere to this outline.</b> 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.</pre>
</blockquote>
<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>
<blockquote type="cite"
cite="mid:SN7PR14MB6492F5F9CD33A778470BBC7A8381A@SN7PR14MB6492.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.</p>
</div>
</blockquote>
<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>
<blockquote type="cite"
cite="mid:SN7PR14MB6492F5F9CD33A778470BBC7A8381A@SN7PR14MB6492.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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
style="font-family:"Segoe UI Emoji",sans-serif">😊</span></p>
</div>
</blockquote>
<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>
<blockquote type="cite">
<pre class="newpage">3.2.1 Method to prove possession of private key</pre>
</blockquote>
<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>
<blockquote type="cite"
cite="mid:SN7PR14MB6492F5F9CD33A778470BBC7A8381A@SN7PR14MB6492.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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> Dimitris Zacharopoulos
(HARICA) <a class="moz-txt-link-rfc2396E" 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 class="moz-txt-link-rfc2396E" href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a>; Inigo Barreira
<a class="moz-txt-link-rfc2396E" 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 class="moz-txt-link-rfc2396E" 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></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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></p>
</blockquote>
<p class="MsoNormal"><br>
In addition, section 2.2 states (emphasis added):<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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></p>
</blockquote>
<p class="MsoNormal"><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></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
So, with all that considered, when we visit <a
href="https://datatracker.ietf.org/doc/html/rfc3647#section-6"
moz-do-not-send="true">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></p>
<div>
<p class="MsoNormal">On 1/12/2023 6:51 μ.μ., Tim Hollebeek
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">This is unfortunately wrong. There are
lots of misconceptions about RFC 3647 “compliance”.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Either way works.<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> Dimitris
Zacharopoulos <a href="mailto:dzacharo@harica.gr"
moz-do-not-send="true"><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"
moz-do-not-send="true"><Inigo.Barreira@sectigo.com></a><br>
<b>Cc:</b> Tim Hollebeek <a
href="mailto:tim.hollebeek@digicert.com"
moz-do-not-send="true"><tim.hollebeek@digicert.com></a>;
CA/B Forum Server Certificate WG Public Discussion
List <a href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"><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></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span
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><o:p></o:p></p>
</div>
<div>
<p><span
style="font-family:"Arial",sans-serif">DZ.</span><o:p></o:p></p>
</div>
<div>
<div>
<p><span
style="font-family:"Arial",sans-serif">Dec
1, 2023 14:50:23 Inigo Barreira <<a
href="mailto:Inigo.Barreira@sectigo.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">Inigo.Barreira@sectigo.com</a>>:</span><o:p></o:p></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.</span><o:p></o:p></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><o:p></o:p></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><o:p></o:p></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><o:p></o:p></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><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Regards</span><o:p></o:p></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="mso-fareast-language:KO" lang="ES">De:</span></b><span
style="mso-fareast-language:KO" lang="ES">
Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">Inigo.Barreira@sectigo.com</a>>;
Tim Hollebeek <<a
href="mailto:tim.hollebeek@digicert.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">tim.hollebeek@digicert.com</a>>;
CA/B Forum Server Certificate WG Public
Discussion List <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Asunto:</b> Re: [Servercert-wg] SC-065:
Convert EVGs into RFC 3647 format pre-ballot</span><o:p></o:p></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
style="font-size:10.0pt;color:black;mso-fareast-language:JA" lang="ES">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>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span
style="mso-fareast-language:JA" lang="ES">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><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA" lang="ES">On
8/9/2023 7:54 μ.μ., Inigo Barreira wrote:</span><o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="ES">Hi all, </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="ES"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Let me
know if you need anything else to clarify the
new version.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Regards</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="mso-fareast-language:JA"
lang="ES">De:</span></b><span
style="mso-fareast-language:JA" lang="ES">
Inigo Barreira <a
href="mailto:Inigo.Barreira@sectigo.com"
moz-do-not-send="true"><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"
moz-do-not-send="true"><tim.hollebeek@digicert.com></a>;
Dimitris Zacharopoulos (HARICA) <a
href="mailto:dzacharo@harica.gr"
moz-do-not-send="true"><dzacharo@harica.gr></a>;
CA/B Forum Server Certificate WG Public
Discussion List <a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"><servercert-wg@cabforum.org></a><br>
<b>Asunto:</b> RE: [Servercert-wg] SC-065:
Convert EVGs into RFC 3647 format
pre-ballot</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA" lang="ES"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Thanks
Dimitris and Tim.</span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">EVG
EVG3647</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.1
3.2.1</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.1.1
3.2.1.1</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.1.2
3.2.1.2</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.1.3
3.2.1.3</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.2
3.2.2</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.2.1
3.2.2.1</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">…..
…. </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.13
3.2.13</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.14
3.2.14</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.14.1
3.2.14.1</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.14.2
3.2.14.2</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">11.14.3
3.2.14.3</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Regards</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB"> </span><o:p></o:p></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="mso-fareast-language:JA"
lang="EN-GB">De:</span></b><span
style="mso-fareast-language:JA"
lang="EN-GB"> Tim Hollebeek <<a
href="mailto:tim.hollebeek@digicert.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">dzacharo@harica.gr</a>>;
Inigo Barreira <<a
href="mailto:Inigo.Barreira@sectigo.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">Inigo.Barreira@sectigo.com</a>>;
CA/B Forum Server Certificate WG Public
Discussion List <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Asunto:</b> RE: [Servercert-wg] SC-065:
Convert EVGs into RFC 3647 format
pre-ballot</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA" lang="EN-GB"> </span><o:p></o:p></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
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><o:p></o:p></p>
</div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:JA"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA">-Tim</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><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><span
style="mso-fareast-language:JA">From:</span></b><span
style="mso-fareast-language:JA">
Dimitris Zacharopoulos (HARICA) <</span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:dzacharo@harica.gr"
moz-do-not-send="true"><span
lang="EN-US">dzacharo@harica.gr</span></a></span><span
style="mso-fareast-language:JA">> <br>
<b>Sent:</b> Tuesday, August 29, 2023
7:58 AM<br>
<b>To:</b> Inigo Barreira <</span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:Inigo.Barreira@sectigo.com" moz-do-not-send="true"><span
lang="EN-US">Inigo.Barreira@sectigo.com</span></a></span><span
style="mso-fareast-language:JA">>;
CA/B Forum Server Certificate WG
Public Discussion List <</span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:servercert-wg@cabforum.org" moz-do-not-send="true"><span
lang="EN-US">servercert-wg@cabforum.org</span></a></span><span
style="mso-fareast-language:JA">>;
Tim Hollebeek <</span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:tim.hollebeek@digicert.com" moz-do-not-send="true"><span
lang="EN-US">tim.hollebeek@digicert.com</span></a></span><span
style="mso-fareast-language:JA">><br>
<b>Subject:</b> Re: [Servercert-wg]
SC-065: Convert EVGs into RFC 3647
format pre-ballot</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><span
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 </span><span
style="mso-fareast-language:JA" lang="ES"><a
href="https://lists.cabforum.org/pipermail/cscwg-public/2022-May/000795.html"
moz-do-not-send="true"><span
lang="EN-US">ballot discussion period</span></a></span><span
style="mso-fareast-language:JA">.<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><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA">On
29/8/2023 12:42 μ.μ., Inigo Barreira via
Servercert-wg wrote:</span><o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="EN-GB">Hi Tim,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="EN-GB">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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="EN-GB">Regards</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="EN-GB"> </span><o:p></o:p></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="mso-fareast-language:JA">De:</span></b><span
style="mso-fareast-language:JA"> Tim
Hollebeek </span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:tim.hollebeek@digicert.com" moz-do-not-send="true"><span
lang="EN-US"><tim.hollebeek@digicert.com></span></a></span><span
style="mso-fareast-language:JA"> <br>
<b>Enviado el:</b> lunes, 28 de
agosto de 2023 19:49<br>
<b>Para:</b> Inigo Barreira </span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:Inigo.Barreira@sectigo.com" moz-do-not-send="true"><span
lang="EN-US"><Inigo.Barreira@sectigo.com></span></a></span><span
style="mso-fareast-language:JA">;
CA/B Forum Server Certificate WG
Public Discussion List </span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:servercert-wg@cabforum.org" moz-do-not-send="true"><span
lang="EN-US"><servercert-wg@cabforum.org></span></a></span><span
style="mso-fareast-language:JA"><br>
<b>Asunto:</b> RE: SC-065: Convert
EVGs into RFC 3647 format pre-ballot</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></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
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><o:p></o:p></p>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA">-Tim</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><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><span
style="mso-fareast-language:JA">From:</span></b><span
style="mso-fareast-language:JA">
Servercert-wg <</span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:servercert-wg-bounces@cabforum.org" moz-do-not-send="true"><span
lang="EN-US">servercert-wg-bounces@cabforum.org</span></a></span><span
style="mso-fareast-language:JA">>
<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 <</span><span
style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:servercert-wg@cabforum.org" moz-do-not-send="true"><span
lang="EN-US">servercert-wg@cabforum.org</span></a></span><span
style="mso-fareast-language:JA">><br>
<b>Subject:</b> [Servercert-wg]
SC-065: Convert EVGs into RFC
3647 format pre-ballot</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA">Hello,</span><o:p></o:p></p>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"
lang="ES"><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"
moz-do-not-send="true"><span
lang="EN-GB">EVGs based on
RFC3647 by barrini · Pull
Request #440 ·
cabforum/servercert (github.com)</span></a></span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
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><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
<pre><span style="mso-fareast-language:JA">_______________________________________________</span><o:p></o:p></pre>
<pre><span style="mso-fareast-language:JA">Servercert-wg mailing list</span><o:p></o:p></pre>
<pre><span style="mso-fareast-language:JA"
lang="ES"><a
href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true"><span lang="EN-US">Servercert-wg@cabforum.org</span></a></span><o:p></o:p></pre>
<pre><span style="mso-fareast-language:JA"
lang="ES"><a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true"><span lang="EN-US">https://lists.cabforum.org/mailman/listinfo/servercert-wg</span></a></span><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span
style="mso-fareast-language:JA"> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>