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.
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.
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.
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).
-Tim
*From:* Dimitris Zacharopoulos (HARICA) <[email protected]>
*Sent:* Saturday, December 2, 2023 5:26 AM
*To:* Tim Hollebeek <[email protected]>; Inigo Barreira
<[email protected]>
*Cc:* CA/B Forum Server Certificate WG Public Discussion List
<[email protected]>
*Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647
format pre-ballot
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.
On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote:
No.
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.
“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.
I think I might have a hint on our disconnect. RFC 3647 has an
indicative Table of Contents in Chapter 6
(https://datatracker.ietf.org/doc/html/rfc3647#section-6) outlining
the proposed CP/CPS sections and subsections using 3 levels.
Here is the text of the opening paragraph of that section (emphasis
added):
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.
* In order to comply with the RFC, the drafters of a compliant CP or*
* CPS are strongly advised to adhere to this outline.* 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.
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.
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.
I hope this is clearer now.
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.
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.
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”.
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 **is
not** 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! 😊
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:
3.2.1 Method to prove possession of private key
Details about the contents of that section can be found in the first
bullet of section 4.3.2 of RFC 3647
<https://datatracker.ietf.org/doc/html/rfc3647#section-4.3.2>.
Does that make more sense?
Dimitris.
-Tim
*From:* Dimitris Zacharopoulos (HARICA) <[email protected]>
<mailto:[email protected]>
*Sent:* Friday, December 1, 2023 1:04 PM
*To:* Tim Hollebeek <[email protected]>
<mailto:[email protected]>; Inigo Barreira
<[email protected]> <mailto:[email protected]>
*Cc:* CA/B Forum Server Certificate WG Public Discussion List
<[email protected]> <mailto:[email protected]>
*Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647
format pre-ballot
Hi Tim,
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.
The BRs in section 1.1 state:
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
In addition, section 2.2 states (emphasis added):
The Certificate Policy and/or Certification Practice Statement
MUST be structured in accordance with RFC 3647 and *MUST
include all material required by RFC 3647*.
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.
MRSP states in section 3.3 (5) (again, emphasis added):
5. all CPs, CPSes, and combined CP/CPSes MUST be structured
according to RFC 3647 and MUST:
- include *at least every section and subsection defined
in RFC 3647*;
- only use the words "No Stipulation" to mean that the
particular document imposes no requirements related to that
section; and
- contain no sections that are blank and have no subsections;
So, with all that considered, when we visit section 6 of RFC 3647
<https://datatracker.ietf.org/doc/html/rfc3647#section-6> ("the
outline"), the expectation is to include each and every section
and subsection of the outline (up to three levels).
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.
I hope this sounds reasonable to people.
Dimitris.
On 1/12/2023 6:51 μ.μ., Tim Hollebeek wrote:
This is unfortunately wrong. There are lots of misconceptions
about RFC 3647 “compliance”.
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).
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.
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.
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.
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.
Either way works.
-Tim
*From:* Dimitris Zacharopoulos <[email protected]>
<mailto:[email protected]>
*Sent:* Friday, December 1, 2023 10:48 AM
*To:* Inigo Barreira <[email protected]>
<mailto:[email protected]>
*Cc:* Tim Hollebeek <[email protected]>
<mailto:[email protected]>; CA/B Forum Server
Certificate WG Public Discussion List
<[email protected]> <mailto:[email protected]>
*Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC
3647 format pre-ballot
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.
That's my interpretation of the RFC 3647 compliance. Perhaps
others can chime in and state their opinion.
Thanks,
DZ.
Dec 1, 2023 14:50:23 Inigo Barreira <[email protected]>:
Thanks Dimitris.
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.
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.
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.)
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.
So, what would you suggest to “comply” with that? I don´t
have a clear idea.
Regards
*De:*Dimitris Zacharopoulos (HARICA) <[email protected]>
*Enviado el:* jueves, 30 de noviembre de 2023 13:16
*Para:* Inigo Barreira <[email protected]>; Tim
Hollebeek <[email protected]>; CA/B Forum Server
Certificate WG Public Discussion List
<[email protected]>
*Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into
RFC 3647 format pre-ballot
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.
Inigo,
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.
Thanks,
Dimitris.
On 8/9/2023 7:54 μ.μ., Inigo Barreira wrote:
Hi all,
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.
Let me know if you need anything else to clarify the
new version.
Regards
*De:*Inigo Barreira <[email protected]>
<mailto:[email protected]>
*Enviado el:* martes, 29 de agosto de 2023 17:06
*Para:* Tim Hollebeek <[email protected]>
<mailto:[email protected]>; Dimitris
Zacharopoulos (HARICA) <[email protected]>
<mailto:[email protected]>; CA/B Forum Server
Certificate WG Public Discussion List
<[email protected]>
<mailto:[email protected]>
*Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs
into RFC 3647 format pre-ballot
Thanks Dimitris and Tim.
I did something of that internally but didn´t reflect
on the document, so will try to reproduce to have it
clearer.
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:
EVG EVG3647
11.1 3.2.1
11.1.1 3.2.1.1
11.1.2 3.2.1.2
11.1.3 3.2.1.3
11.2 3.2.2
11.2.1 3.2.2.1
….. ….
11.13 3.2.13
11.14 3.2.14
11.14.1 3.2.14.1
11.14.2 3.2.14.2
11.14.3 3.2.14.3
Hope this can clarify the main difficult that I found
in the document, where to place it and how.
Regards
*De:*Tim Hollebeek <[email protected]>
*Enviado el:* martes, 29 de agosto de 2023 16:59
*Para:* Dimitris Zacharopoulos (HARICA)
<[email protected]>; Inigo Barreira
<[email protected]>; CA/B Forum Server
Certificate WG Public Discussion List
<[email protected]>
*Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs
into RFC 3647 format pre-ballot
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.
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.
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.
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.
-Tim
*From:*Dimitris Zacharopoulos (HARICA)
<[email protected] <mailto:[email protected]>>
*Sent:* Tuesday, August 29, 2023 7:58 AM
*To:* Inigo Barreira <[email protected]
<mailto:[email protected]>>; CA/B Forum
Server Certificate WG Public Discussion List
<[email protected]
<mailto:[email protected]>>; Tim Hollebeek
<[email protected]
<mailto:[email protected]>>
*Subject:* Re: [Servercert-wg] SC-065: Convert EVGs
into RFC 3647 format pre-ballot
Hi Inigo,
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 ballot discussion period
<https://lists.cabforum.org/pipermail/cscwg-public/2022-May/000795.html>.
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.
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.
I hope this helps.
Dimitris.
On 29/8/2023 12:42 μ.μ., Inigo Barreira via
Servercert-wg wrote:
Hi Tim,
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.
Regards
*De:*Tim Hollebeek <[email protected]>
<mailto:[email protected]>
*Enviado el:* lunes, 28 de agosto de 2023 19:49
*Para:* Inigo Barreira
<[email protected]>
<mailto:[email protected]>; CA/B Forum
Server Certificate WG Public Discussion List
<[email protected]>
<mailto:[email protected]>
*Asunto:* RE: SC-065: Convert EVGs into RFC 3647
format pre-ballot
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.
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.
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.
-Tim
*From:*Servercert-wg
<[email protected]
<mailto:[email protected]>> *On
Behalf Of *Inigo Barreira via Servercert-wg
*Sent:* Monday, August 28, 2023 5:20 AM
*To:* CA/B Forum Server Certificate WG Public
Discussion List <[email protected]
<mailto:[email protected]>>
*Subject:* [Servercert-wg] SC-065: Convert EVGs
into RFC 3647 format pre-ballot
Hello,
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.
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:
EVGs based on RFC3647 by barrini · Pull Request
#440 · cabforum/servercert (github.com)
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/440___.YXAzOmRpZ2ljZXJ0OmE6bzoyOGIxNWVhZGVmZDlkZTM0NjQzZTA3YTlmYTA2MzM5YTo2OmExZWM6NGZmMGEzM2U0ZWZjOTU4MTM1NWRkNjU3ZDE5YjU3Y2YxNzg1NWU0ZTVjYzkzY2NjM2M0MWU5MzEyYzJmZTQ0NzpoOkY>
I am currently seeking two endorsers as well as
any feedback on the ballot content itself
(wording, effective dates, etc.).
Thanks,
_______________________________________________
Servercert-wg mailing list
[email protected]
<mailto:[email protected]>
https://lists.cabforum.org/mailman/listinfo/servercert-wg
<https://lists.cabforum.org/mailman/listinfo/servercert-wg>
