> > 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 < [email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
