[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 16:58:38 UTC 2024

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 <mailto: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/5a5dab49/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240315/5a5dab49/attachment-0001.p7s>