[Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot
Aaron Gable
aaron at letsencrypt.org
Fri Dec 1 17:27:35 UTC 2023
It's also worth noting that the Baseline Requirements also diverge from RFC
3647 in this way: for example, Section 1.5 of RFC 3647 is concerned with
the contact information of the group *administering the CP/CPS*, while
Section 1.5(.2) of the BRs is concerned with contact information of the
group *operating the CA*. So trying to cleave too closely to the bulleted
descriptions inside RFC 3647 is unhelpful, imo.
For whatever it's worth, I think that Section 11 of the current EVGs could
be renumbered wholesale to become Section 3.2, retaining its subsections
as-is, with few or no issues.
Aaron
On Fri, Dec 1, 2023 at 8:51 AM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> 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 <dzacharo at harica.gr>
> *Sent:* Friday, December 1, 2023 10:48 AM
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com>
> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *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 <Inigo.Barreira at sectigo.com>:
>
> 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) <dzacharo at harica.gr>
> *Enviado el:* jueves, 30 de noviembre de 2023 13:16
> *Para:* Inigo Barreira <Inigo.Barreira at sectigo.com>; Tim Hollebeek <
> tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public
> Discussion List <servercert-wg at cabforum.org>
> *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 <Inigo.Barreira at sectigo.com>
> <Inigo.Barreira at sectigo.com>
> *Enviado el:* martes, 29 de agosto de 2023 17:06
> *Para:* Tim Hollebeek <tim.hollebeek at digicert.com>
> <tim.hollebeek at digicert.com>; Dimitris Zacharopoulos (HARICA)
> <dzacharo at harica.gr> <dzacharo at harica.gr>; CA/B Forum Server Certificate
> WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>
> *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 <tim.hollebeek at digicert.com>
> *Enviado el:* martes, 29 de agosto de 2023 16:59
> *Para:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; Inigo
> Barreira <Inigo.Barreira at sectigo.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>
> *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) <dzacharo at harica.gr>
> *Sent:* Tuesday, August 29, 2023 7:58 AM
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Tim
> Hollebeek <tim.hollebeek at digicert.com>
> *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 <tim.hollebeek at digicert.com>
> <tim.hollebeek at digicert.com>
> *Enviado el:* lunes, 28 de agosto de 2023 19:49
> *Para:* Inigo Barreira <Inigo.Barreira at sectigo.com>
> <Inigo.Barreira at sectigo.com>; CA/B Forum Server Certificate WG Public
> Discussion List <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *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 <servercert-wg-bounces at cabforum.org> *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 <
> servercert-wg at cabforum.org>
> *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
>
> Servercert-wg at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20231201/8635696e/attachment-0001.html>
More information about the Servercert-wg
mailing list