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.vanbrouwersha...@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@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@cabforum.org <mailto:Servercert-wg@cabforum.org> > https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
