[Servercert-wg] Seeking endorsers: SC-065: Convert EVGs into RFC 3647 format pre-ballot
Ben Wilson
bwilson at mozilla.com
Thu Feb 8 18:27:29 UTC 2024
I'm willing to endorse.
On Thu, Feb 8, 2024 at 10:52 AM Inigo Barreira via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> Hi,
>
>
>
> As mentioned in the past SCWG call, I´m looking for 2 endorsers for this
> ballot.
>
>
>
> Regards
>
>
>
> *De:* Servercert-wg <servercert-wg-bounces at cabforum.org> *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* viernes, 19 de enero de 2024 13:28
> *Para:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>; Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr>; Bruce Morton <Bruce.Morton at entrust.com>; Tim
> Hollebeek <tim.hollebeek at digicert.com>
> *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.
>
>
>
> Hi all,
>
>
>
> As per yesterday´s SCWG call, I´ve also updated the BRs with the new
> section numbers of the EVG. Only 2 sections have been affected and
> therefore updated.
>
> Section 3.2.2.4.7
>
> EVG 11.14.3 à 3.2.2.14.3
>
>
>
> Section 7.1.2.7.5
>
> EVG 9.2 à 7.1.4.2
>
>
>
> You can find all the information in the PR 440, EVGs based on RFC3647 by
> barrini · Pull Request #440 · cabforum/servercert (github.com)
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F440%2Fcommits&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743467686%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HdTqG7oNDVDzJW8NzNbPoh5mrTVqdWcP08%2FGy7bmr30%3D&reserved=0>
>
> First, I had to update the current version of the BRs I was working with
> (2.0.0) to the current one (2.0.2) and then make the changes to the newest
> one.
>
>
>
> Regards
>
>
>
> *De:* Inigo Barreira <Inigo.Barreira at sectigo.com>
> *Enviado el:* viernes, 15 de diciembre de 2023 12:42
> *Para:* Inigo Barreira <Inigo.Barreira at sectigo.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>;
> Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; Bruce Morton <
> Bruce.Morton at entrust.com>; Tim Hollebeek <tim.hollebeek at digicert.com>
> *Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> Hi everyone
>
>
>
> As per last week discussion during the SCWG, we agreed to follow section 6
> of the RFC 3647 for the new EVG format.
>
> With that in mind, I´ve updated the correspondent PR (#440) to reflect it
> that way, so:
>
> - Changed section 1.1 name from scope to overview
> - Created a new section 3.2.1 for possession of the private key
> - Moved all the other stuff of the old section 11 to a “new” section
> 3.2.2 for organization identity.
> - Also created the remaining ones, 3.2.3, 3.2.4, etc.
> - Update section 8 removing section 8.1 and renumbering the others and
> putting the self audits under 8.1 and leaving section 8.7 for readiness
> audits because don´t know where it can fit better (this section does not
> exist in RFC 3647 section 6)
> - Checked all links
>
>
>
> In any case, see the comparison here: Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...238ff99fbe04f2aa24f2c58910d8133f2283f11e
> · cabforum/servercert (github.com)
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F90a98dc7c1131eaab01af411968aa7330d315b9b...238ff99fbe04f2aa24f2c58910d8133f2283f11e&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743477514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DfuivpL6hUVdFhvr3T8r%2FYdniz%2Bvdh5zkXiRTAXds00%3D&reserved=0>
>
>
>
> If you´re ok with this change, we can move forward a propose the ballot
> for which I´ll need 2 endorsers.
>
>
>
> Regards
>
>
>
> *De:* Servercert-wg <servercert-wg-bounces at cabforum.org> *En nombre de *Inigo
> Barreira via Servercert-wg
> *Enviado el:* jueves, 7 de diciembre de 2023 13:08
> *Para:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; Bruce
> Morton <Bruce.Morton at entrust.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>; Tim Hollebeek <
> tim.hollebeek at digicert.com>
> *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.
>
>
>
> Hi there,
>
>
>
> See the comparing one.
>
> Comparing
> 90a98dc7c1131eaab01af411968aa7330d315b9b...13b4f85a494fefa52510512a2fb3c4d7c77a7a36
> · cabforum/servercert (github.com)
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F90a98dc7c1131eaab01af411968aa7330d315b9b...13b4f85a494fefa52510512a2fb3c4d7c77a7a36&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743484475%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=15xO0GZKZBJbW3egMxmzA4aQLO%2FVD5pm4PXI5J6pEEc%3D&reserved=0>
>
>
>
> Regards
>
>
>
> *De:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Enviado el:* lunes, 4 de diciembre de 2023 22:18
> *Para:* Bruce Morton <Bruce.Morton at entrust.com>; 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>
> *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.
>
>
>
>
>
> On 4/12/2023 9:22 μ.μ., Bruce Morton wrote:
>
> I thought an intriguing promise of doing documents in Github and in the
> same format is that we would see the requirements in the same section,
> which would allow for better management. Also, the proposal Paul brought
> forward for the BR of BRs would work much better if we use the same
> sections. I guess I am encouraging the move of EV from a non-standard
> format to a sort of standard RFC 3647 format would be to help provide
> document alignment.
>
>
>
> +1 to Dimitris original suggestion.
>
>
>
> - https://github.com/cabforum/code-signing/compare/main...importEVG
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fcompare%2Fmain...importEVG&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743490220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jobRHX%2Fhq5%2Bnbg%2BtN3SB47BWx6%2FW9ie6G5sMdBI14X8%3D&reserved=0>
>
> This is currently WIP, maintaining the numbering of RFC 3647 section 6,
> and moving the EV Guidelines sections referenced by the CSBRs into new
> sections. We've done these conversions in the past and they worked pretty
> well, leading to consistently structured policy documents across the
> ecosystem.
>
> It's not perfect but it tries to move requirements to where RFC 3647 and
> the BRs expect them to be. For example, section 11.14 of the EV Guidelines
> talks about re-use of existing documentation which fits into section 4.2.1
> of the BRs.
>
>
> Thanks,
> Dimitris.
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
> <servercert-wg-bounces at cabforum.org> *On Behalf Of *Inigo Barreira via
> Servercert-wg
> *Sent:* Monday, December 4, 2023 2:15 PM
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>; Tim Hollebeek <tim.hollebeek at digicert.com>
> <tim.hollebeek at digicert.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL] Re: [Servercert-wg] SC-065: Convert EVGs into RFC
> 3647 format pre-ballot
>
>
>
> Dimitris, I think that we should focus on the EVG not on the CP/CPS. The
> CA´s CP/CPS will have that 3. 2. 1 section because it´s in the TLS BRs but
> that does not mean that the EVG must have also that section 3. 2. 1 (BTW,
> the section exist in the
>
> Dimitris,
>
>
>
> I think that we should focus on the EVG not on the CP/CPS. The CA´s CP/CPS
> will have that 3.2.1 section because it´s in the TLS BRs but that does not
> mean that the EVG must have also that section 3.2.1 (BTW, the section exist
> in the TLS BRs but with no content). At the end of the day, every CA
> issuing TLS certs will have to follow the TLS BRs and EVGs and then
> accommodate their CP/CPSes according to both documents.
>
> I understand your point to be stricter in the implementation of that
> specific point but for every CA to change/update their current CP/CPS with
> the new EVG in the RFC 3647 format, would find it easier to where to make
> those changes/adjustments in their own CP/CPS if we can convert easily the
> current section 11 into 3.2 and not to start looking into different numbers
> to make that change.
>
>
>
> Regards
>
>
>
> *De:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Enviado el:* lunes, 4 de diciembre de 2023 20:02
> *Para:* Tim Hollebeek <tim.hollebeek at digicert.com>; Inigo Barreira <
> Inigo.Barreira at sectigo.com>
> *CC:* 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.
>
>
>
> FWIW, there are informational RFCs that include SHOULD requirements (I
> didn't check for other informational RFCs that might contain SHALL
> requirements). Take a look at RFC 8894
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8894__%3B!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBI0YJAc7w%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743495910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mSFsB1K2scWMfovSBvYiWchCL7qq7rLc8eZPrCQPm1M%3D&reserved=0>
> .
>
> I agree that there seems to be some ambiguity in the REQUIRED CP/CPS
> structure but the entire reasoning behind using the "RFC 3647 format" was
> to align CP and CPS documents so that comparisons can be made across
> different CAs. If one CA reads that they must follow a 2-level structure
> based on section 4, and another CA reads that they must follow the
> structure of section 6 of the RFC, we're not meeting the goal for alignment
> and easy comparisons.
>
> Digicert's CPS seems to follow the structure of section 6 of RFC 3647. Has
> anyone spotted a CPS claiming compliance with the TLS BRs that is not
> following the section 6 structure of 3647?
>
> If all existing public CAs follow the structure of section 6 of 3647 in
> their CP/CPS documents, we can just clarify that the expectation is what
> Ben mentioned in
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2FBenWilson-Mozilla%2Fpkipolicy%2Fcommit%2F1a94642cb95017cf382e4e93811db16a2342a806__%3B!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBIIavReJg%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743502037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=prWDv%2Ffbsj1Hh53PTh46rU6R9bOLZx77HmNd2ePaZi0%3D&reserved=0>,
> so that we address this ambiguity. We probably don't even need an effective
> date if it causes no issue on existing CAs.
>
> My point is that if we leave this open to interpretation, we can't compare
> CP/CPS sections across multiple CAs efficiently, and this defeats the whole
> purpose of the requirement to structure CP/CPS documents according to RFC
> 3647. We might as well abandon the idea of converting the EV Guidelines
> into that format.
>
> I believe that the intent has always been to enforce a "stricter"
> alignment. But if indeed there are deviations, I'd support some stricter
> language to align CP/CPS documents according to section 6 of RFC 3647 even
> with a future effective date :)
>
>
> Dimitris.
>
> On 4/12/2023 7:27 μ.μ., Tim Hollebeek wrote:
>
> Yeah, the fact that the section 6 outline goes deeper than the actual
> described format in section 4 is annoying, and you’re right, it’s probably
> the source of these disagreements. I always look at section 4, because it
> has the actual guidance about what sort of information should be considered
> for inclusion.
>
>
>
> This is what happens when people try to turn informational documents into
> normative requirements. You have to try to interpret what phrases like
> “are strongly advised to adhere”, which isn’t even a RFC 2119 SHOULD. And
> it can’t even be a SHOULD, because as an informational RFC, it is
> prohibited from having requirements, even SHOULDs! That’s why it’s written
> that way. Also, informational RFCs are not examined as closely for
> inconsistencies (because there are no requirements!) which is how
> divergences like section 4 vs 6 happen. It wasn’t intended to be used as a
> compliance document.
>
>
>
> I still think what Inigo did is perfectly fine, although there are lots of
> other perfectly fine solutions, too. What we need to be discussing is
> what’s best for us, not RFC 3647 requires, because RFC 3647 has infinite
> leeway. As Aaron and I have been pointing out, you’ll find lots of
> divergences at level three, and there’s even lots of additional content in
> level two, just because a lot of newer content doesn’t really have a good
> fit in RFC 3647.
>
>
>
> Now, that said, we might want to be more strict in the future, and if we
> choose to do so, we can be. I just don’t want people overstating what the
> rules actually are, because a lot of people’s time has been wasted
> enforcing RFC 3647 in a way that is far stricter than was ever intended
> (one of the reasons I’m so vocal on this issue is because I got this point
> of view from one of the original authors).
>
>
>
> -Tim
>
>
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>
> *Sent:* Saturday, December 2, 2023 5:26 AM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
> <tim.hollebeek at digicert.com>; Inigo Barreira <Inigo.Barreira at sectigo.com>
> <Inigo.Barreira at sectigo.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> We still have a disagreement so please allow me one more attempt to
> clarify my position because it seems you didn't check the links included in
> my previous post. I will copy some of that text here for convenience.
>
> On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote:
>
> No.
>
>
>
> IETF has both Normative and Informative RFCs. While it is true that
> compliance with a Normative RFC is voluntary, if you do choose to comply,
> the RFC has requirements stated in RFC 2119 standards language that make it
> clear what the compliance rules are. Informative RFCs like 3647 do not
> have any normative requirements at all. They merely contain information.
>
>
>
> “all sections of the RFC 3647 framework” is fine, this covers the sections
> enumerated in RFC 3647 section 4, which includes the TOP TWO levels of an
> outline in numbered form, e.g. the requirements for section 3.2 are
> described in RFC 3647 section 4.3.2. There is no RFC 3647 section 4.3.2.1,
> which proves my point. RFC 3647 only has a two level outline structure.
>
>
> I think I might have a hint on our disconnect. RFC 3647 has an indicative
> Table of Contents in Chapter 6 (
> https://datatracker.ietf.org/doc/html/rfc3647#section-6
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3647*section-6__%3BIw!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBKp_QdGmg%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743508234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8rd8z6a28d9hEDfFSMfjNXw5I%2BtCcsO0xH%2Bj8GQ%2BPtQ%3D&reserved=0>)
> outlining the proposed CP/CPS sections and subsections using 3 levels.
>
> Here is the text of the opening paragraph of that section (emphasis added):
>
> This section contains a recommended outline for a set of provisions,
>
> intended to serve as a checklist or (with some further development) a
>
> standard template for use by CP or CPS writers. Such a common
>
> outline will facilitate:
>
>
>
> (a) Comparison of two certificate policies during cross-
>
> certification or other forms of interoperation (for the purpose
>
> of equivalency mapping).
>
>
>
> (b) Comparison of a CPS with a CP to ensure that the CPS faithfully
>
> implements the policy.
>
>
>
> (c) Comparison of two CPSs.
>
>
>
> * In order to comply with the RFC, the drafters of a compliant CP or*
>
> * CPS are strongly advised to adhere to this outline.* While use of an
>
> alternate outline is discouraged, it may be accepted if a proper
>
> justification is provided for the deviation and a mapping table is
>
> provided to readily discern where each of the items described in this
>
> outline is provided.
>
>
> The reason the CA/B Forum BRs were structured according to this outline
> was to assist with comparisons between CP/CPS documents of different CAs,
> making the review of these documents easier.
>
> That's why you see sections like 1.5.4 "CPS approval procedures" in the
> BRs as an empty section with "No Stipulation". There are many such sections
> in the BRs, all coming from section 6 of RFC 3647.
>
> I hope this is clearer now.
>
>
>
> BR Section 2.2 needs to be re-written, as there are no materials required
> by RFC 3647 (because RFC 3647 contains no requirements). It needs to say
> something like “structured in accordance with RFC 3647 and MUST include all
> sections of the outline described in section 4” or something like that.
> What it says right now doesn’t capture the intent that you correctly
> summarized.
>
>
> During the last couple of years reviewing CP/CPS documents, I saw some
> uniformity at least in Publicly Trusted CAs, and they all seem to follow
> the BRs structure which comes from the outline of section 6 of RFC 3647.
> However, it's not a bad idea to further clarify BR section 2.2 to better
> meet the expectations.
>
>
>
> The MSRP language is better, I think I may have made all of these same
> points when it was being drafted, which is why it says “section and
> subsection” (two levels) and uses “structured according to” and not
> “complies with the requirements of”.
>
>
>
> But anyway, this is all background that supports what I’ve been saying all
> along: BR 3.2 is a RFC 3647 section. BR 3.2.1 **is not** a RFC 3647
> required section, nor is it even a section that is even mentioned in RFC
> 3647. If you don’t believe me, please go to RFC 3647, Section 4.3.2.1 and
> read what it says. OH, WAIT, IT DOESN’T EXIST! 😊
>
>
> To my point, BR 3.2.1 IS an RFC 3647 required section as it is explicitly
> mentioned in the outline of section 6 of RFC 3647:
>
> 3.2.1 Method to prove possession of private key
>
>
> Details about the contents of that section can be found in the first
> bullet of section 4.3.2 of RFC 3647
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3647*section-4.3.2__%3BIw!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBIL19sP_w%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743514196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9d2e2bKWp0WgBz0fi0Q%2B7H37BraKcy9HDykgU2hg0NE%3D&reserved=0>.
>
>
> Does that make more sense?
>
> Dimitris.
>
>
>
> -Tim
>
>
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>
> *Sent:* Friday, December 1, 2023 1:04 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
> <tim.hollebeek at digicert.com>; Inigo Barreira <Inigo.Barreira at sectigo.com>
> <Inigo.Barreira at sectigo.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format
> pre-ballot
>
>
>
> Hi Tim,
>
> None of the IETF standards set policy unless they are invited by some
> policy authority :) The BRs set such policy and "import" some documents,
> such as RFC 5280, 3647 and others.
>
> The BRs in section 1.1 state:
>
> These Requirements do not address all of the issues relevant to the
> issuance and management of Publicly-Trusted Certificates. In accordance
> with RFC 3647 and to facilitate a comparison of other certificate policies
> and CPSs (e.g. for policy mapping), this document includes all sections of
> the RFC 3647 framework. However, rather than beginning with a "no
> stipulation" comment in all empty sections, the CA/Browser Forum is leaving
> such sections initially blank until a decision of "no stipulation" is made
>
>
> In addition, section 2.2 states (emphasis added):
>
> The Certificate Policy and/or Certification Practice Statement MUST be
> structured in accordance with RFC 3647 and *MUST include all material
> required by RFC 3647*.
>
>
> If you go back to the discussions when the CA/B Forum decide to align with
> the "RFC 3647 format", we agreed to include each and every section of the
> outline as a minimum set.
>
> MRSP states in section 3.3 (5) (again, emphasis added):
>
> 5. all CPs, CPSes, and combined CP/CPSes MUST be structured according to
> RFC 3647 and MUST:
>
> - include *at least every section and subsection defined in RFC 3647*;
> - only use the words "No Stipulation" to mean that the particular
> document imposes no requirements related to that section; and
> - contain no sections that are blank and have no subsections;
>
>
> So, with all that considered, when we visit section 6 of RFC 3647
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3647*section-6__%3BIw!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBKp_QdGmg%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743520165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=L9VbZRk1zuxMaDwZDNKCJDf36lHA7InzOJMYZAjD%2FPw%3D&reserved=0>
> ("the outline"), the expectation is to include each and every section and
> subsection of the outline (up to three levels).
>
> CAs are free to add MORE sections and subsections as they desire, just
> like the BRs have done, but we can't escape or "hijack" an existing RFC
> 3647 section number. The outline contains a specific section labeled as
> "3.2.1 Method to prove possession of private key". That means we cannot
> re-use the number 3.2.1 for something else.
>
> I hope this sounds reasonable to people.
>
> Dimitris.
>
> On 1/12/2023 6:51 μ.μ., Tim Hollebeek 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> <dzacharo at harica.gr>
> *Sent:* Friday, December 1, 2023 10:48 AM
> *To:* Inigo Barreira <Inigo.Barreira at sectigo.com>
> <Inigo.Barreira at sectigo.com>
> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>
> <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public
> Discussion List <servercert-wg at cabforum.org> <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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flists.cabforum.org%2Fpipermail%2Fcscwg-public%2F2022-May%2F000795.html__%3B!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBLzwUxa3A%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743526088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E%2BLAEuFHaNu26dqWFjor1uKzUv3aqQb%2F0WTae4u6vVU%3D&reserved=0>
> .
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Furl.avanan.click%2Fv2%2F___https%3A%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F440___.YXAzOmRpZ2ljZXJ0OmE6bzoyOGIxNWVhZGVmZDlkZTM0NjQzZTA3YTlmYTA2MzM5YTo2OmExZWM6NGZmMGEzM2U0ZWZjOTU4MTM1NWRkNjU3ZDE5YjU3Y2YxNzg1NWU0ZTVjYzkzY2NjM2M0MWU5MzEyYzJmZTQ0NzpoOkY__%3B!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBKpiKVP6w%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743532259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MPp0hhMFncU1F3DR2A20h8zmChrAX9HiOi4IUJvn1Sk%3D&reserved=0>
>
>
>
> 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 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg__%3B!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBI3Tfxaxw%24&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Ce95ecbc067c243eda3a008dc18ea0876%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638412640743539011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4iNv5o3e0pVrs0aBpI8HdC8NrweEBsMLmnePwnWj7tQ%3D&reserved=0>
>
>
>
>
>
>
>
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
>
>
> _______________________________________________
> 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/20240208/6db0edd1/attachment-0001.html>
More information about the Servercert-wg
mailing list