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

Ben Wilson bwilson at mozilla.com
Mon Oct 30 19:37:38 UTC 2023

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.

On Thu, Oct 26, 2023 at 12:30 PM Tobias S. Josefowitz <tobij at opera.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20231030/0a338019/attachment.html>

More information about the Public mailing list