[Servercert-wg] [EXTERNAL] [Discussion Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

Wayne Thayer wthayer at gmail.com
Fri Mar 15 18:24:42 UTC 2024


>
> I don’t have any particular concern with the change itself, to be clear,
> but the motivation behind this — and the abruptness of the introduction of
> the topic — remain opaque to me.


It appears to me that this bug is the motivation for this ballot:
https://bugzilla.mozilla.org/show_bug.cgi?id=1883843

On Fri, Mar 15, 2024 at 9:58 AM Clint Wilson via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Paul,
>
> There are a lot of ways that the EVGs differ from the TBRs; that’s
> basically the point of them, as I understand it. Specifically it’s within
> the profiles that most non-process-oriented differences can be found
> between EV, OV, IV, and DV TLS certificates. Are all of these differences
> issues which should be addressed by the WG to bring EV TLS certificates
> more in line with the leaner profiles found in the TBRs?
>
> I don’t see how this is a genuine misalignment between the TBRs and the
> EVGs. I could possibly see a misalignment between RFC 5280 and the EVGs,
> but even there it’s very intentional that allowance is given such that
> individual use-cases can successfully be addressed without violating the
> RFC.
>
> From https://datatracker.ietf.org/doc/html/rfc2119#section-4: (emphasis
> mine)
> "SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>    *there may exist valid reasons* in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.”
>
> From https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4:
> "To promote interoperability, this profile RECOMMENDS that policy
>    information terms consist of only an OID.  Where an OID alone is
>    insufficient, this profile strongly recommends that the use of
>    qualifiers be limited to those identified in this section.”
>
> In both cases, it’s clear to me, when encountering a SHOULD, SHOULD NOT,
> RECOMMENDS, or NOT RECOMMENDED that the expectation is for CAs to
> individually assess what is the most appropriate action to take. That
> doesn’t sound like a misalignment, so much as an acknowledgement of
> potential nuance and the need for additional consideration. As you say,
> they shouldn’t "unless they have a good reason to" — such as the EV
> Guidelines explicitly requiring policyQualifiers.
>
> I don’t have any particular concern with the change itself, to be clear,
> but the motivation behind this — and the abruptness of the introduction of
> the topic — remain opaque to me.
>
> Thank you,
> -Clint
>
> On Mar 15, 2024, at 9:09 AM, Paul van Brouwershaven <
> Paul.vanBrouwershaven at entrust.com> wrote:
>
> Hi Clint,
>
> If the BRs specified MAY and the EVGs MUST you can put it in both and thus
> have profile alignment. After this changed from MAY to NOT RECOMMENDED we
> end up with a conflicting requirement, while allowed, its expected that CAs
> adhere to a NOT RECOMMENDED unless they have a good reason to do so.
>
> While it's possible to implement two different policies this does creates
> a clear misalignment.
>
> Paul
>
> ------------------------------
> *From:* Clint Wilson
> *Sent:* Friday, March 15, 2024 17:00
> *To:* Paul van Brouwershaven; ServerCert CA/BF
> *Subject:* [EXTERNAL] Re: [Servercert-wg] [Discussion Period Begins]:
> SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making
> them NOT RECOMMENDED
>
> Hi,
>
> Could the ballot author and endorsers please provide some additional
> explanation and context surrounding this ballot? As far as I can recall,
> this topic hasn’t been discussed since SC-062, so it’s rather coming out of
> nowhere as a ballot proposal (which is, of course, totally fine, but also
> still abrupt/confusing). Why is this difference between the TBRs and the
> EVGs necessary/valuable for the WG to address at the moment?
>
> You indicate that this is a discrepancy introduced by Ballot SC-062, but I
> don’t see how that’s the case. Before SC-062, the TBRs specified
> policyQualifiers as Optional and after as NOT RECOMMENDED. Neither of these
> match the MUST present in the EVGs and both of these are
> compatible/non-conflicting with the MUST present in the EVGs.
>
> Thanks,
> -Clint
>
>
>
> On Mar 15, 2024, at 3:01 AM, Paul van Brouwershaven via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> This ballot updates the TLS Extended Validation Guidelines (EVGs) by
> removing the exceptions topolicyQualifiers​ in section 9.7, to align them
> with the Baseline Requirements (BRs).As result, this ballot changes
> policyQualifiers​ from MUST​ to NOT RECOMMENDED​ as stated in the TLS
> Baseline Requirements, resolving a discrepancy introduced byBallot SC-62v2
> <https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/> between
> section 7.1.2.7.9 Subscriber Certificate Policies
> <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#71279-subscriber-certificate-certificate-policies> of
> the BRs and the Additional Technical Requirements for EV Certificates
> <https://cabforum.org/working-groups/server/extended-validation/guidelines/#97-additional-technical-requirements-for-ev-certificates> in
> the EVGs.
>
> The following motion has been proposed by Paul van Brouwershaven (Entrust)
> and endorsed by Dimitris Zacharopoulos (HARICA) and Iñigo Barreira
> (Sectigo).
>
> You can view and comment on the GitHub pull request representing this
> ballot here:https://github.com/cabforum/servercert/pull/490
>
> --- Motion Begins ---
>
> This ballot modifies the “Guidelines for the Issuance and Management of
> Extended Validation Certificates” (“EV Guidelines”) as follows, based on
> version 1.8.1:
>
> MODIFY the Extended Validation Guidelines as specified in the following
> redline:
> https://github.com/cabforum/servercert/compare/8e7fc7d5cac0cc27c44fe2aa88cf45f5606f4b94...7b9bb1dbfd41b1d0459b8a985ed629ad841ce122
>
>
> --- Motion Ends ---
>
> Discussion (at least 7 days):
> - Start: 2024-03-15 10:00 UTC
> - End no earlier than 2024-03-22 10:00 UTC
>
> Vote for approval (7 days):
> - Start: TBD
> - End: TBD
>
> *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
>
>
> _______________________________________________
> 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/20240315/5f6b66a6/attachment-0001.html>


More information about the Servercert-wg mailing list