[cabfpub] Ballot FORUM-019 - Amend Server Certificate Working Group Charter - Discussion Period

[Tobias S. Josefowitz]

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