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

Fri Mar 15 20:13:10 UTC 2024

I concur that it is a misrepresentation to say that a "NOT RECOMMENDED" in
the BRs and a "MUST" in the EVGs is a conflict. It is no more of a conflict
than we saw recently
<https://bugzilla.mozilla.org/show_bug.cgi?id=1872374> where
European law allowed two identifiers to be used while the EVGs required a
specific one of them. In both cases, the correct course of action is clear:
abide by the stricter set of requirements.

As Clint said, being required to include the field by the EVGs certainly
qualifies as a "good reason" to go against the BRs' mere recommendation.

To be clear, I support making this change to the EVGs. I think that
including the CPS URI increases the size of the certificate while providing
little to no benefit to end users or ecosystem auditors. But rushing
through a ballot like this is no substitute for proper incident response
and remediation, and the fact that Entrust seems to believe it is easier to
fix the requirements than it is to abide by them makes me question the
motivations behind this ballot and the precedent it may set.

Aaron

On Fri, Mar 15, 2024 at 11:25 AM Wayne Thayer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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
>>
> _______________________________________________
> 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/fba2f459/attachment-0001.html>