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