[Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Dec 1 18:11:32 UTC 2023
On 1/12/2023 7:27 μ.μ., Aaron Gable wrote:
> 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/.
The group /administrering /the CP/CPS can be included in section "1.5.2
Contact person" along with what the BRs need for the group /operating
/the CA. One does not prohibit the other.
> So trying to cleave too closely to the bulleted descriptions
> inside RFC 3647 is unhelpful, imo.
I believe CAs are obligated by policy to include all bulleted section of
section 6 of RFC 3647 (plus errata
<https://www.rfc-editor.org/errata/rfc3647>).
>
> 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.
IMO ... as long as it doesn't conflict with sections/subsections of the
outline of RFC 3647.
Dimitris.
>
> 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>
> <mailto:Inigo.Barreira at sectigo.com>
> *Enviado el:* martes, 29 de agosto de 2023 17:06
> *Para:* Tim Hollebeek <tim.hollebeek at digicert.com>
> <mailto:tim.hollebeek at digicert.com>; Dimitris
> Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <mailto:dzacharo at harica.gr>; CA/B Forum Server Certificate
> WG Public Discussion List <servercert-wg at cabforum.org>
> <mailto: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
> <mailto:dzacharo at harica.gr>>
> *Sent:* Tuesday, August 29, 2023 7:58 AM
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com
> <mailto:Inigo.Barreira at sectigo.com>>; CA/B Forum Server
> Certificate WG Public Discussion List
> <servercert-wg at cabforum.org
> <mailto:servercert-wg at cabforum.org>>; Tim Hollebeek
> <tim.hollebeek at digicert.com
> <mailto: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>
> <mailto:tim.hollebeek at digicert.com>
> *Enviado el:* lunes, 28 de agosto de 2023 19:49
> *Para:* Inigo Barreira <Inigo.Barreira at sectigo.com>
> <mailto:Inigo.Barreira at sectigo.com>; CA/B Forum Server
> Certificate WG Public Discussion List
> <servercert-wg at cabforum.org>
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto:Servercert-wg at cabforum.org>
>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <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/ba2573d9/attachment-0001.html>
More information about the Servercert-wg
mailing list