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
[email protected]
https://lists.cabforum.org/mailman/listinfo/public
