Aaron
On Fri, Dec 1, 2023 at 8:51 AM Tim Hollebeek via Servercert-wg
<[email protected]> 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]>
*Sent:* Friday, December 1, 2023 10:48 AM
*To:* Inigo Barreira <[email protected]>
*Cc:* Tim Hollebeek <[email protected]>; 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 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>
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
