[Servercert-wg] [EXTERNAL]-Re: SC-065: Convert EVGs into RFC 3647 format pre-ballot
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Tue Jan 23 08:14:00 UTC 2024
Hi Pedro, there is no controversy, it's ok to share different opinions
and different perspectives. As I said, the particular issue with ballots
that update the same section(s) will be discussed separately. To me,
it's a matter of consistency and all "code management systems" must have
a firm process to handle "conflicts".
With that said, nothing prevents us from discussing the essence of your
ballot. Irrespective of what we do with the conflicting sections, the
language from the EV Guidelines will be moved altogether. So, for
example, if you update the current section 11.1.3, this will move to a
new location in its entirety so you don't need to worry about it during
the discussion of the ballot.
Thank you for using GH to show the proposed changes, it is very helpful
to most Members. To echo Tim's point, and in order to assist ballot
proposers as much as possible, if someone is not familiar or doesn't
want to get involved with GH, it is not mandatory to use GH to propose
changes. Anything, from writing a text in the body of an email, to
submitting a word redline, they are all acceptable according to our
Bylaws (section 2.4).
Thanks,
Dimitris.
On 23/1/2024 7:47 π.μ., Pedro FUENTES wrote:
> Hi guys,
>
> I didn’t want to trigger any controversy. My question was more related
> to understand how a so impacting Pull Request like the one to convert
> to RFC format could be managed in GitHub with other PR related to the
> non-RFC version.
>
> On my side, I prepared the PR#439
> (https://github.com/cabforum/servercert/pull/439) but I didn’t promote
> it as I guessed I’d have to redo it at some point based on the RFC
> version… but again maybe I’m not understanding how GH works…
>
> Cheers!
> Pedro
>
>> On 22 Jan 2024, at 19:49, Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>> Feel free to bring it up, but I still oppose it for all the reasons
>> we discussed when we had this discussion the last time. Adding more
>> mandatory details to the ballot process is not progress. We need to
>> get back to improving the requirements, and not spending so much time
>> on bylaws and administrivia. It’s already too hard for people not
>> intimately familiar with the forum and ballot process to write
>> ballots. Adding this would just make it even worse.
>> Instead of that, let’s discuss Pedro’s ballot, whether it’s a good
>> idea, and how we get it or something else across the finish line, if
>> it is.
>> -Tim
>> *From:*Dimitris Zacharopoulos <dzacharo at harica.gr>
>> *Sent:*Saturday, January 20, 2024 12:21 AM
>> *To:*Tim Hollebeek <tim.hollebeek at digicert.com>
>> *Cc:*Pedro FUENTES <pfuentes at wisekey.com>; Inigo Barreira
>> <Inigo.Barreira at sectigo.com>; CA/B Forum Server Certificate WG Public
>> Discussion List <servercert-wg at cabforum.org>; Bruce Morton
>> <bruce.morton at entrust.com>
>> *Subject:*Re: [EXTERNAL]-Re: [Servercert-wg] SC-065: Convert EVGs
>> into RFC 3647 format pre-ballot
>> 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 <tim.hollebeek at digicert.com>:
>>
>> 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) <dzacharo at harica.gr>
>> *Sent:*Friday, January 19, 2024 2:00 PM
>> *To:*Pedro FUENTES <pfuentes at wisekey.com>; Inigo Barreira
>> <Inigo.Barreira at sectigo.com>; CA/B Forum Server Certificate WG
>> Public Discussion List <servercert-wg at cabforum.org>
>> *Cc:*Bruce Morton <bruce.morton at entrust.com>; Tim Hollebeek
>> <tim.hollebeek at digicert.com>
>> *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<servercert-wg at cabforum.org>
>> <mailto:servercert-wg at cabforum.org>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 <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://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
>> <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://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) <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://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<servercert-wg-bounces at cabforum.org>
>> <mailto: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>
>> <mailto:dzacharo at harica.gr>; Tim
>> Hollebeek<tim.hollebeek at digicert.com>
>> <mailto:tim.hollebeek at digicert.com>
>> *Cc:*CA/B Forum Server Certificate WG Public
>> Discussion List<servercert-wg at cabforum.org>
>> <mailto: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 atRFC 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
>> inhttps://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)<dzacharo at harica.gr>
>> <mailto:dzacharo at harica.gr>
>> *Sent:*Saturday, December 2, 2023 5:26 AM
>> *To:*Tim Hollebeek<tim.hollebeek at digicert.com>
>> <mailto:tim.hollebeek at digicert.com>; Inigo
>> Barreira<Inigo.Barreira at sectigo.com>
>> <mailto:Inigo.Barreira at sectigo.com>
>> *Cc:*CA/B Forum Server Certificate WG Public
>> Discussion List<servercert-wg at cabforum.org>
>> <mailto: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:
>>
>> …
>>
>>
>> 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 ofsection 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
>> Servercert-wg at cabforum.org
>> <mailto:Servercert-wg at cabforum.org>
>> 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=
>> <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.
>>
>
> *
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240123/f837a863/attachment-0001.html>
More information about the Servercert-wg
mailing list