Well, yes, um, that was me đ
There wasnât an obvious place for contact information for CAs to fit, so I suggested section 1.5 when it was discussed on MDSP. That suggestion migrated into the BRs as part of the root program requirement consolidation effort. Youâre right that itâs outside of the âsuggestionsâ for the official content of that section. A similar example is section 1.2, which says: âThis subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, *for the document*. An example of such a document name would be the US Federal Government Policy for Secure E-mail.â BR Section 1.2 does not contain the name of the document (âBaseline Requirements for the Issuance and Management of PubliclyâTrusted Certificatesâ) and it does not contain any other OIDs or identifiers *for the document*. The expected content would have been something like: ---- This document is the CA/Browser Forum TLS requirements, known as âBaseline Requirements for the Issuance and Management of PubliclyâTrusted Certificatesâ, version blah.blah. This version of the document can be referenced by name and version, by the URI x://y.z.z/y, or by the OID cabf.requirements.baseline.tls.blah.bah. ---- That sort of title and version information is what was intended for that section. We, instead, have a bunch of OIDs that are intended for indicating compliance with the document (which is related, but not the same thing as OIDs identifying the document itself). And then we have the version history and relevant dates in that section, which again, is fine, because weâre following an outline, and not a normative list of requirements about what MAY / MUST / SHALL NOT / ONLY IF YOU ASK NICELY / OVER MY DEAD BODY appear in each section. And Iâve even heard of auditors who have insisted that every single OID the CA uses in its operations must be documented in section 1.2. This is a very perverse and difficult to understand misreading of the non-normative text that appears in the informative RFC 3647, but Iâve heard of auditors threatening audit findings over it (ÂŻ\_(ă)_/ÂŻ). There are other, better places for documenting OIDs that are used in certificates. For example, almost anywhere in section 7. -Tim From: Aaron Gable <[email protected]> Sent: Friday, December 1, 2023 12:28 PM To: Tim Hollebeek <[email protected]>; CA/B Forum Server Certificate WG Public Discussion List <[email protected]> Cc: Dimitris Zacharopoulos <[email protected]>; Inigo Barreira <[email protected]> Subject: Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot 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] <mailto:[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] <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] <mailto:[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] <mailto:[email protected]> > Enviado el: jueves, 30 de noviembre de 2023 13:16 Para: Inigo Barreira <[email protected] <mailto:[email protected]> >; Tim Hollebeek <[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 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 <mailto:[email protected]> <[email protected]> Enviado el: martes, 29 de agosto de 2023 17:06 Para: Tim Hollebeek <mailto:[email protected]> <[email protected]>; Dimitris Zacharopoulos (HARICA) <mailto:[email protected]> <[email protected]>; CA/B Forum Server Certificate WG Public Discussion List <mailto:[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] <mailto:[email protected]> > Enviado el: martes, 29 de agosto de 2023 16:59 Para: Dimitris Zacharopoulos (HARICA) <[email protected] <mailto:[email protected]> >; Inigo Barreira <[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 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) < <mailto:[email protected]> [email protected]> Sent: Tuesday, August 29, 2023 7:58 AM To: Inigo Barreira < <mailto:[email protected]> [email protected]>; CA/B Forum Server Certificate WG Public Discussion List < <mailto:[email protected]> [email protected]>; Tim Hollebeek < <mailto:[email protected]> [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 <https://lists.cabforum.org/pipermail/cscwg-public/2022-May/000795.html> ballot discussion period. 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 <mailto:[email protected]> <[email protected]> Enviado el: lunes, 28 de agosto de 2023 19:49 Para: Inigo Barreira <mailto:[email protected]> <[email protected]>; CA/B Forum Server Certificate WG Public Discussion List <mailto:[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 < <mailto:[email protected]> [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 < <mailto:[email protected]> [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: <https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/440___.YXAzOmRpZ2ljZXJ0OmE6bzoyOGIxNWVhZGVmZDlkZTM0NjQzZTA3YTlmYTA2MzM5YTo2OmExZWM6NGZmMGEzM2U0ZWZjOTU4MTM1NWRkNjU3ZDE5YjU3Y2YxNzg1NWU0ZTVjYzkzY2NjM2M0MWU5MzEyYzJmZTQ0NzpoOkY> EVGs based on RFC3647 by barrini ¡ Pull Request #440 ¡ cabforum/servercert (github.com) 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 <mailto:[email protected]> [email protected] <https://lists.cabforum.org/mailman/listinfo/servercert-wg> https://lists.cabforum.org/mailman/listinfo/servercert-wg _______________________________________________ Servercert-wg mailing list [email protected] <mailto:[email protected]> https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
