I'm willing to endorse. On Thu, Feb 8, 2024 at 10:52 AM Inigo Barreira via Servercert-wg < servercert-wg@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-boun...@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@cabforum.org>; Dimitris Zacharopoulos (HARICA) < > dzach...@harica.gr>; Bruce Morton <bruce.mor...@entrust.com>; Tim > Hollebeek <tim.holleb...@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.barre...@sectigo.com> > *Enviado el:* viernes, 15 de diciembre de 2023 12:42 > *Para:* Inigo Barreira <inigo.barre...@sectigo.com>; CA/B Forum Server > Certificate WG Public Discussion List <servercert-wg@cabforum.org>; > Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr>; Bruce Morton < > bruce.mor...@entrust.com>; Tim Hollebeek <tim.holleb...@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-boun...@cabforum.org> *En nombre de *Inigo > Barreira via Servercert-wg > *Enviado el:* jueves, 7 de diciembre de 2023 13:08 > *Para:* Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr>; Bruce > Morton <bruce.mor...@entrust.com>; CA/B Forum Server Certificate WG > Public Discussion List <servercert-wg@cabforum.org>; Tim Hollebeek < > tim.holleb...@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) <dzach...@harica.gr> > *Enviado el:* lunes, 4 de diciembre de 2023 22:18 > *Para:* Bruce Morton <bruce.mor...@entrust.com>; Inigo Barreira < > inigo.barre...@sectigo.com>; CA/B Forum Server Certificate WG Public > Discussion List <servercert-wg@cabforum.org>; Tim Hollebeek < > tim.holleb...@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-boun...@cabforum.org> > <servercert-wg-boun...@cabforum.org> *On Behalf Of *Inigo Barreira via > Servercert-wg > *Sent:* Monday, December 4, 2023 2:15 PM > *To:* Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr> > <dzach...@harica.gr>; Tim Hollebeek <tim.holleb...@digicert.com> > <tim.holleb...@digicert.com> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List > <servercert-wg@cabforum.org> <servercert-wg@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) <dzach...@harica.gr> > *Enviado el:* lunes, 4 de diciembre de 2023 20:02 > *Para:* Tim Hollebeek <tim.holleb...@digicert.com>; Inigo Barreira < > inigo.barre...@sectigo.com> > *CC:* CA/B Forum Server Certificate WG Public Discussion List < > servercert-wg@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) <dzach...@harica.gr> > <dzach...@harica.gr> > *Sent:* Saturday, December 2, 2023 5:26 AM > *To:* Tim Hollebeek <tim.holleb...@digicert.com> > <tim.holleb...@digicert.com>; Inigo Barreira <inigo.barre...@sectigo.com> > <inigo.barre...@sectigo.com> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List > <servercert-wg@cabforum.org> <servercert-wg@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) <dzach...@harica.gr> > <dzach...@harica.gr> > *Sent:* Friday, December 1, 2023 1:04 PM > *To:* Tim Hollebeek <tim.holleb...@digicert.com> > <tim.holleb...@digicert.com>; Inigo Barreira <inigo.barre...@sectigo.com> > <inigo.barre...@sectigo.com> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List > <servercert-wg@cabforum.org> <servercert-wg@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 <dzach...@harica.gr> <dzach...@harica.gr> > *Sent:* Friday, December 1, 2023 10:48 AM > *To:* Inigo Barreira <inigo.barre...@sectigo.com> > <inigo.barre...@sectigo.com> > *Cc:* Tim Hollebeek <tim.holleb...@digicert.com> > <tim.holleb...@digicert.com>; CA/B Forum Server Certificate WG Public > Discussion List <servercert-wg@cabforum.org> <servercert-wg@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.barre...@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) <dzach...@harica.gr> > *Enviado el:* jueves, 30 de noviembre de 2023 13:16 > *Para:* Inigo Barreira <inigo.barre...@sectigo.com>; Tim Hollebeek < > tim.holleb...@digicert.com>; CA/B Forum Server Certificate WG Public > Discussion List <servercert-wg@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.barre...@sectigo.com> > <inigo.barre...@sectigo.com> > *Enviado el:* martes, 29 de agosto de 2023 17:06 > *Para:* Tim Hollebeek <tim.holleb...@digicert.com> > <tim.holleb...@digicert.com>; Dimitris Zacharopoulos (HARICA) > <dzach...@harica.gr> <dzach...@harica.gr>; CA/B Forum Server Certificate > WG Public Discussion List <servercert-wg@cabforum.org> > <servercert-wg@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.holleb...@digicert.com> > *Enviado el:* martes, 29 de agosto de 2023 16:59 > *Para:* Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr>; Inigo > Barreira <inigo.barre...@sectigo.com>; CA/B Forum Server Certificate WG > Public Discussion List <servercert-wg@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) <dzach...@harica.gr> > *Sent:* Tuesday, August 29, 2023 7:58 AM > *To:* Inigo Barreira <inigo.barre...@sectigo.com>; CA/B Forum Server > Certificate WG Public Discussion List <servercert-wg@cabforum.org>; Tim > Hollebeek <tim.holleb...@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.holleb...@digicert.com> > <tim.holleb...@digicert.com> > *Enviado el:* lunes, 28 de agosto de 2023 19:49 > *Para:* Inigo Barreira <inigo.barre...@sectigo.com> > <inigo.barre...@sectigo.com>; CA/B Forum Server Certificate WG Public > Discussion List <servercert-wg@cabforum.org> <servercert-wg@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-boun...@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@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@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@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
