<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
FWIW, there are informational RFCs that include SHOULD requirements
(I didn't check for other informational RFCs that might contain
SHALL requirements). Take a look at <a
href="https://datatracker.ietf.org/doc/html/rfc8894">RFC 8894</a>.<br>
<br>
I agree that there seems to be some ambiguity in the REQUIRED CP/CPS
structure but the entire reasoning behind using the "RFC 3647
format" was to align CP and CPS documents so that comparisons can be
made across different CAs. If one CA reads that they must follow a
2-level structure based on section 4, and another CA reads that they
must follow the structure of section 6 of the RFC, we're not meeting
the goal for alignment and easy comparisons.<br>
<br>
Digicert's CPS seems to follow the structure of section 6 of RFC
3647. Has anyone spotted a CPS claiming compliance with the TLS BRs
that is not following the section 6 structure of 3647?<br>
<br>
If all existing public CAs follow the structure of section 6 of 3647
in their CP/CPS documents, we can just clarify that the expectation
is what Ben mentioned in
<a class="moz-txt-link-freetext" href="https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806">https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806</a>,
so that we address this ambiguity. We probably don't even need an
effective date if it causes no issue on existing CAs.<br>
<br>
My point is that if we leave this open to interpretation, we can't
compare CP/CPS sections across multiple CAs efficiently, and this
defeats the whole purpose of the requirement to structure CP/CPS
documents according to RFC 3647. We might as well abandon the idea
of converting the EV Guidelines into that format.<br>
<br>
I believe that the intent has always been to enforce a "stricter"
alignment. But if indeed there are deviations, I'd support some
stricter language to align CP/CPS documents according to section 6
of RFC 3647 even with a future effective date :)<br>
<br>
<br>
Dimitris.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 4/12/2023 7:27 μ.μ., Tim Hollebeek
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SN7PR14MB64928E9652B6FEA0C3826CF88386A@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:"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;}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">Yeah, the fact that the section 6 outline
goes deeper than the actual described format in section 4 is
annoying, and you’re right, it’s probably the source of these
disagreements. I always look at section 4, because it has the
actual guidance about what sort of information should be
considered for inclusion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is what happens when people try to
turn informational documents into normative requirements. You
have to try to interpret what phrases like “are strongly
advised to adhere”, which isn’t even a RFC 2119 SHOULD. And
it can’t even be a SHOULD, because as an informational RFC, it
is prohibited from having requirements, even SHOULDs! That’s
why it’s written that way. Also, informational RFCs are not
examined as closely for inconsistencies (because there are no
requirements!) which is how divergences like section 4 vs 6
happen. It wasn’t intended to be used as a compliance
document.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I still think what Inigo did is perfectly
fine, although there are lots of other perfectly fine
solutions, too. What we need to be discussing is what’s best
for us, not RFC 3647 requires, because RFC 3647 has infinite
leeway. As Aaron and I have been pointing out, you’ll find
lots of divergences at level three, and there’s even lots of
additional content in level two, just because a lot of newer
content doesn’t really have a good fit in RFC 3647.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now, that said, we might want to be more
strict in the future, and if we choose to do so, we can be. I
just don’t want people overstating what the rules actually
are, because a lot of people’s time has been wasted enforcing
RFC 3647 in a way that is far stricter than was ever intended
(one of the reasons I’m so vocal on this issue is because I
got this point of view from one of the original authors).<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> Saturday, December 2, 2023 5:26 AM<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" style="margin-bottom:12.0pt">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></p>
<div>
<p class="MsoNormal">On 1/12/2023 11:31 μ.μ., Tim Hollebeek
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><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"
moz-do-not-send="true" class="moz-txt-link-freetext">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>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre> This section contains a recommended outline for a set of provisions,<o:p></o:p></pre>
<pre> intended to serve as a checklist or (with some further development) a<o:p></o:p></pre>
<pre> standard template for use by CP or CPS writers. Such a common<o:p></o:p></pre>
<pre> outline will facilitate:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> (a) Comparison of two certificate policies during cross-<o:p></o:p></pre>
<pre> certification or other forms of interoperation (for the purpose<o:p></o:p></pre>
<pre> of equivalency mapping).<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> (b) Comparison of a CPS with a CP to ensure that the CPS faithfully<o:p></o:p></pre>
<pre> implements the policy.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> (c) Comparison of two CPSs.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><b> In order to comply with the RFC, the drafters of a compliant CP or<o:p></o:p></b></pre>
<pre><b> CPS are strongly advised to adhere to this outline.</b> While use of an<o:p></o:p></pre>
<pre> alternate outline is discouraged, it may be accepted if a proper<o:p></o:p></pre>
<pre> justification is provided for the deviation and a mapping table is<o:p></o:p></pre>
<pre> provided to readily discern where each of the items described in this<o:p></o:p></pre>
<pre> outline is provided.<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><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>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><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>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><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>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>3.2.1 Method to prove possession of private key<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><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"
moz-do-not-send="true">section 4.3.2 of RFC 3647</a>. <br>
<br>
Does that make more sense?<br>
<br>
Dimitris.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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
href="mailto:dzacharo@harica.gr"
moz-do-not-send="true"><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"
moz-do-not-send="true"><tim.hollebeek@digicert.com></a>;
Inigo Barreira <a
href="mailto:Inigo.Barreira@sectigo.com"
moz-do-not-send="true"><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"
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>
<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>
<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>
<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>
<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>
<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>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
<br>
</body>
</html>