Thanks, Tobias. I'll take a look at your suggestions and see if I can work in a few revisions, and then we can restart the discussion period. Ben
On Thu, Oct 26, 2023 at 12:30 PM Tobias S. Josefowitz <to...@opera.com> wrote: > Hi Ben, > > On Mon, 23 Oct 2023, Ben Wilson wrote: > > > *Ballot FORUM-019: Amend Server Certificate Working Group Charter* > > > > *Purpose of the Ballot* > > > > This ballot proposes changes to the Server Certificate Working Group > (SCWG) > > Charter, based on existing version 1.2 of the Charter and on recent > updates > > to the Forum's Bylaws. > > > > During discussions at Face-to-Face Meeting 58, it was noted that the > > membership criteria for Certificate Consumers in the SCWG Charter lacked > > sufficient detail. Since then, through discussions on the mailing list of > > the SCWG, better criteria for membership of Certificate Consumers in the > > SCWG have been developed, and the ballot also adds a 6-month probationary > > period for all applicants to the SCWG before they become voting members. > > > > *Motion Begins* > > > > MODIFY the Charter of the Server Certificate Working Group as specified > in > > the following redline: > > > > > https://github.com/cabforum/forum/compare/59185f16917cc7f5b83564fe5fddff32cf84c8ce?f029c48cfd8a53ca563904835d6bd5d4b41fa4c8 > > > > *Motion Ends* > > My biggest concern with this Ballot is the language in 4. (d), which > introduces the limitation of "upon the request of any Member that > challenges the Applicant's adherence to all of the requirements of section > 3(a) or 3(b)" for requesting the membership to be decided by a vote. > > I recognize that we have members that interpret the current mechanism of > deciding membership by vote "upon the request of any Member" to only > result in a vote about the applicant meeting the formal membership > criteria. Understandably, from that perspective, adding pretty much any > sensible requirement to the list of formal membership criteria for > Certificate Consumer members is obviously beneficial and without any > downsides. > > As someone who does not share that perspective but maintains that the > current "upon the request of any Member" mechanism results in a vote in > which members can apply a level of discretion which allows at least e.g. > refusing membership to applicants who's membership (if granted) might > substantially erode trust into the WebPKI ecosystem or endanger the SCWG's > ability to maintain and produce documents that are incorporated into root > program policies in a mostly verbatim fashion, the new language is > extremely concerning. > > When taking into account that the new set of requirements for Certificate > Consumers can indeed still be trivially met by even a single individual > with a few hours of time on their hands (unless, maybe, "software product > intended for use by the general public for browsing the Web securely" > somehow will turn into a requirement that will not be considered to be > trivially fulfilled), the new language in my opinion becomes > disqualifying. I hope that this change to the mechanism can be reverted > until we have a set of formal membership criteria for Certificate > Consumers that makes such discretion obsolete. > > In addition, I have some minor concerns regarding the new formal > membership criteria for Certificate Consumers in 3.(b). In particular, for > the sake of the argument, I assume a browser that generally uses the OS > root store as a base mechanism (potentially with the ability to exclude > specific certificates that might be included in the OS root store). It is > my understanding that for example Google Chrome has worked like this until > somewhat recently, which to me kind of implies that it ought to be > considered an acceptable practice for SCWG Certificate Consumer Member > qualifying software products in good standing. From our discussion during > the F2F #60 (I am not sure if this was in the SCWG or Forum plenary) I > understand that you intend > > "its membership-qualifying software product uses a list of CA > certificates to validate the chain of trust from a TLS certificate to a > CA certificate in such list" > > to cover that case. However, such a software as described would indeed use > different lists on different platforms. We could consider the specific > version for one platform to be the "membership qualifying software", but > that does not seem elegant, and might come into conflict with "for the > general public" in a strict interpretation. > > In such a case, it would also be problematic to > > "publishes the list of CA certificates used to validate the chain of > trust from a TLS certificate to a CA certificate in such list" > > as any static copy of such a list would only give an indication of intent, > but misses to represent the actual mechanism at play. It would in this > case be much more reasonable to simply explain how the mmebership > qualifying software decides which certificates to trust. > > In the same way, when it comes to > > "it publishes how it adds or removes a CA certificate from such list" > > the published documentation might be something along the lines of "we do > not add certificates ourselves, but have mechanisms to override and thus > remove trust when we detect violations of the BRs or other security > concerns, please contact us if you would like to reoprt any such violation > or security concern". > > It seems to me that the Ballot language is not all that clear around such > scenarios and that members could easily form interpretations going any > which way without being to blame for it. > > I would propose to instead use the following language: > > * its membership qualifying software product validates the chain of trust > from a TLS certificate to a CA certificate included in a list or root > store or similar mechanism and being signified (by presence or flag or > similar mechanism) as either being in accordance with the SCWG's > Baseline Requirements or specifically requested to be trusted locally on > the device in question; > > * it provides documentation explaining which lists or root stores or > similar mechanism are used for determining whether a certificate chain > is valid and trusted; and > > * provides documentation allowing Certificate Issuers to determine what > steps they might need to take in order to have their Root Certificates > trusted or distrusted by the membership-qualifying software, as well as > documentation about how to contact the member regarding Baseline > Requirements violations or security or other issues and concerns related > to certificate validation in the membership qualifying software. > > Tobi >
_______________________________________________ Public mailing list Public@cabforum.org https://lists.cabforum.org/mailman/listinfo/public
