Tim, For conflicting sections in multiple simultaneous ballots, this is what we've done historically and consistently.
You are correct that the Bylaws use a "may" but I strongly recommended using the existing practice, otherwise the outcome is uncertain and risky. In fact, I would suggest we make this mandatory at the next Bylaws update. I will bring it up for discussion separately from this thread. Thanks, DZ. Jan 19, 2024 23:57:14 Tim Hollebeek <[email protected]>: > Note that the language says “may”. Summarizing that as “needs to” is > incorrect. It is intentionally weak, to avoid putting a burden on ballot > proposers to completely and exhaustively specify their ballot’s interaction > with another ballot they don’t control. The only requirement is to name and > link to ballots that amends the same section (to help avoid merge errors). > > All of the stuff around holding and sequencing ballots, and describing > possible deconfliction strategies, is useful and important stuff we do to > keep the Forum working smoothly, and I would highly encourage people to pay > close attention to those sorts of things, but we need to be clear on what > actually are minimum requirements and what aren’t, because I don’t want to > interfere with or unduly burden the rights of members to call for a proposed > ballot at any time. > > -Tim > > *From:* Dimitris Zacharopoulos (HARICA) <[email protected]> > *Sent:* Friday, January 19, 2024 2:00 PM > *To:* Pedro FUENTES <[email protected]>; Inigo Barreira > <[email protected]>; CA/B Forum Server Certificate WG Public > Discussion List <[email protected]> > *Cc:* Bruce Morton <[email protected]>; Tim Hollebeek > <[email protected]> > *Subject:* Re: [EXTERNAL]-Re: [Servercert-wg] SC-065: Convert EVGs into RFC > 3647 format pre-ballot > > Hi Pedro, > > If the proposed ballot interacts with sections that are modified by an > existing ballot, the second ballot proposer needs to describe what will the > possible results of that section look like, basically by writing down the > expected language if the first ballot passes or fails. > > Bylaws section 2.4 (10): > / > If a ballot is proposed to amend the same section of the Final Guidelines or > the Final Maintenance Guidelines as one or more previous ballot(s) that > has/have not yet been finally approved, the newly proposed ballot must > include information about, and a link to, any such previous ballot(s), and > may include provisions to avoid any conflicts relating to such previous > ballots./ > > > I hope this helps. > > Dimitris. > > On 19/1/2024 2:34 μ.μ., Pedro FUENTES wrote: > Hello, > I’d like to know how this would interact with the change proposed by Dimitris > for the VATEL thing. > In my case I did put on hold my own proposed change (regulation of use of > QGIS for organization validation) until the doc was in RFC format, and I > wonder if we should do the same for other proposed changes, as I guess the > order of the ballots is important here. > Best, > Pedro > > > On 19 Jan 2024, at 13:27, Inigo Barreira via Servercert-wg > <[email protected]> wrote: > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_servercert_pull_440_commits&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=4yDjCByZihcF66OPg0-LImW7hEJ3BRBPpguv_Dh5h0I&e=] > 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 <[email protected]> > *Enviado el:* viernes, 15 de diciembre de 2023 12:42 > *Para:* Inigo Barreira <[email protected]>; CA/B Forum Server > Certificate WG Public Discussion List <[email protected]>; Dimitris > Zacharopoulos (HARICA) <[email protected]>; Bruce Morton > <[email protected]>; Tim Hollebeek <[email protected]> > *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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_servercert_compare_90a98dc7c1131eaab01af411968aa7330d315b9b...238ff99fbe04f2aa24f2c58910d8133f2283f11e&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=Fkxi2puIea-XluHGWRpA2fMQdGTdESWl6jTcxt-Mh2I&e=] > > > 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 <[email protected]> *En nombre de *Inigo > Barreira via Servercert-wg > *Enviado el:* jueves, 7 de diciembre de 2023 13:08 > *Para:* Dimitris Zacharopoulos (HARICA) <[email protected]>; Bruce Morton > <[email protected]>; CA/B Forum Server Certificate WG Public > Discussion List <[email protected]>; Tim Hollebeek > <[email protected]> > *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format > pre-ballot > > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > Hi there, > > > See the comparing one. > Comparing > 90a98dc7c1131eaab01af411968aa7330d315b9b...13b4f85a494fefa52510512a2fb3c4d7c77a7a36 > · cabforum/servercert > (github.com)[https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_servercert_compare_90a98dc7c1131eaab01af411968aa7330d315b9b...13b4f85a494fefa52510512a2fb3c4d7c77a7a36&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=SAlnT_XxVC5MVdb-AWK-2-2ft5iK_-91Uh8zev3Au44&e=] > > > Regards > > > *De:* Dimitris Zacharopoulos (HARICA) <[email protected]> > *Enviado el:* lunes, 4 de diciembre de 2023 22:18 > *Para:* Bruce Morton <[email protected]>; Inigo Barreira > <[email protected]>; CA/B Forum Server Certificate WG Public > Discussion List <[email protected]>; Tim Hollebeek > <[email protected]> > *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format > pre-ballot > > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_code-2Dsigning_compare_main...importEVG&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=IH-hz12ss4KJRRKpXUPs_ykN-ftU1yP8_QWnqFumUpE&e=] > 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 <[email protected]> *On Behalf Of > *Inigo Barreira via Servercert-wg > *Sent:* Monday, December 4, 2023 2:15 PM > *To:* Dimitris Zacharopoulos (HARICA) <[email protected]>; Tim Hollebeek > <[email protected]> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List > <[email protected]> > *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) <[email protected]> > *Enviado el:* lunes, 4 de diciembre de 2023 20:02 > *Para:* Tim Hollebeek <[email protected]>; Inigo Barreira > <[email protected]> > *CC:* CA/B Forum Server Certificate WG Public Discussion List > <[email protected]> > *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format > pre-ballot > > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_datatracker.ietf.org_doc_html_rfc8894-5F-5F-3B-21-21FJ-2DY8qCqXTj2-21cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz-5Foc-2DH9s1zZDBI0YJAc7w-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=eZUOnibdXAEm7TArY-4NlpNDvdpq2qrcI6Os5GzWvtY&e=]. > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_github.com_BenWilson-2DMozilla_pkipolicy_commit_1a94642cb95017cf382e4e93811db16a2342a806-5F-5F-3B-21-21FJ-2DY8qCqXTj2-21cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz-5Foc-2DH9s1zZDBIIavReJg-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=7yKm78aVhCw6xlE85YVTEd_kGz4SHJhZ83xtcshx1Ag&e=], > 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) <[email protected]> > *Sent:* Saturday, December 2, 2023 5:26 AM > *To:* Tim Hollebeek <[email protected]>; Inigo Barreira > <[email protected]> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List > <[email protected]> > *Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format > pre-ballot > > > We 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: > … > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_datatracker.ietf.org_doc_html_rfc3647-2Asection-2D6-5F-5F-3BIw-21-21FJ-2DY8qCqXTj2-21cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz-5Foc-2DH9s1zZDBKp-5FQdGmg-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=cp3VExDM2DhLCKZSB-C46rsVM45LgWuB6qsMlwtjSHY&e=]) > outlining the proposed CP/CPS sections and subsections using 3 levels. > > Here is the text of the opening paragraph of that section (emphasis added): > > > … > > 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. > > > … > > 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. > > > … > > 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: > > > … > > Details about the contents of that section can be found in the first bullet > of section 4.3.2 of RFC > 3647[https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A_datatracker.ietf.org_doc_html_rfc3647-2Asection-2D4.3.2-5F-5F-3BIw-21-21FJ-2DY8qCqXTj2-21cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz-5Foc-2DH9s1zZDBIL19sP-5Fw-24&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=VVgYrcQHYItvxshaRW05i_oEkdLisu_m-OdTzlBeXn8&e=]. > > > Does that make more sense? > > Dimitris. > > > … > > > > > /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 > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=wsg-TdwvnM_b-Pg3U1XTwuszyojufD0lb45hNqvXdBXdCbT5NwVJ3w_4u0QY-JUd&s=NI2v6X_p5sLdAuQxYnL49SedZwqRk1slWN8V5zVZkQs&e= > > * > WISeKey SA* > *Pedro Fuentes > *CSO - Trust Services Manager > Office: + 41 (0) 22 594 30 00 > Mobile: + 41 (0) 791 274 790 > Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland > *Stay connected with WISeKey[http://www.wisekey.com] > * > > *THIS IS A TRUSTED MAIL*: This message is digitally signed with a WISeKey > identity. If you get a mail from WISeKey please check the signature to avoid > security risks > > > > *CONFIDENTIALITY: *This email and any files transmitted with it can be > confidential and it’s intended solely for the use of the individual or entity > to which they are addressed. If you are not the named addressee you should > not disseminate, distribute or copy this e-mail. If you have received this > email in error please notify the sender > > *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of this > message and does not accept any liability for any errors or omissions herein > as this message has been transmitted over a public network. Internet > communications cannot be guaranteed to be secure or error-free as information > may be intercepted, corrupted, or contain viruses. Attachments to this e-mail > are checked for viruses; however, we do not accept any liability for any > damage sustained by viruses and therefore you are kindly requested to check > for viruses upon receipt. > >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
