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 < [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]> > <[email protected]> > *Enviado el:* martes, 29 de agosto de 2023 17:06 > *Para:* Tim Hollebeek <[email protected]> > <[email protected]>; Dimitris Zacharopoulos (HARICA) > <[email protected]> <[email protected]>; CA/B Forum Server Certificate > WG Public Discussion List <[email protected]> > <[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]> > *Sent:* Tuesday, August 29, 2023 7:58 AM > *To:* Inigo Barreira <[email protected]>; CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>; Tim > Hollebeek <[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]> > <[email protected]> > *Enviado el:* lunes, 28 de agosto de 2023 19:49 > *Para:* Inigo Barreira <[email protected]> > <[email protected]>; CA/B Forum Server Certificate WG Public > Discussion List <[email protected]> <[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]> *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]> > *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] > > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > > > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
