[cabfpub] Bylaws: Update Membership Criteria (section 2.1)

[Ryan Sleevi]

On Wed, Jan 30, 2019 at 2:21 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> I disagree that for S/MIME there is no set of existing rules. ETSI EN 319
> 411-1 (scope LCP, NCP) and AFAIK WebTrust for CAs have been used as
> attestations of adequate level of organizational/technical controls for
> S/MIME, clientAuthentication and Code Signing Certificates.
>

They are not tailored towards S/MIME, while there exist a number of schemes
that are, which you seem to wish to exclude from consideration or
participation. I disagree that it's been seen as an "adequate" level -
otherwise, we wouldn't have been talking about the need for guidelines for
both S/MIME and codeSigning for a number of years.


> The main reason I prefer using an international scheme is because it is
> more carefully drafted, usually by experts in that area, and have a good
> and internationally acceptable quality assurance. The auditors themselves
> are assessed by peer reviews (WebTrust) or by NABs (ETSI). Local laws and
> National regulations may not have similar quality level but lower.
>

Or, as it happens, they may be higher.


> Auditors are usually a government agency.
>

A regulated entity, as opposed to self-regulation with demonstrable lack of
oversight. I would point to the sizable number of issues with ETSI audits,
both in reporting and performance, that might suggest otherwise.


> I consider the level of audit schemes in the Baseline Requirements to be a
> good set of standards to start with because it sets the bar pretty high
> from the very beginning.
>

You're ignoring, however, that these schemes are recognized as such for
SSL/TLS. I see no reason to support the conclusion that they're good
schemes for these other cases, and ample evidence (both from the SSL/TLS
discussions and the need to form these WGs) that they are substantially
lacking.

However, in all of this response, you haven't really articulated why a CA
that lacks a WebTrust or ETSI audit should be able to participate and/or
vote in the Forum. You've articulated that you think these schemes are
great starting grounds, and while there's ample evidence to disagree with
that, it doesn't actually help describe why it should be a Forum-level
requirement as opposed to a servercert-wg requirement.

I'm fundamentally uncomfortable with CAs "on the inside" attempting to keep
other CAs out, and it seems like a definition that recognizes that CA trust
is fundamentally imparted by the Certificate Consumers seems... useful. If
a WG goes off the rails because, say, a certificate consumer decided to let
everyone under the sun in - or if it gets stacked with certificate
consumers with interests not aligned with major platforms - then the
natural consequence is that that WG and its work product will be ignored
and not required by Certificate Consumers.

The goal of a WG - S/MIME or Code Signing - is not to produce something
that CAs like or even agree with. It's to produce a set of criteria that
reflect the participating Certificate Consumers needs, so that they can
then require it for participation in their Root Programs. If the
requirements do not meet their needs, such Consumers can choose not to
require them. Similarly, such Consumers can impose their own requirements
above and beyond. In both situations, it seems extremely valuable to
support as diverse and varied as possible a set of participants, to provide
feedback for Certificate Consumers in developing and imposing requirements
for their programs. I don't see how the possession of a WebTrust for CAs
audit, over, say, participation in the US Federal PKI, fundamentally
improves the quality of discourse or feedback. This is especially true if
the consequence of developing and imposing such standards may result in
presently-accepted Certificate Consumers from being excluded from
participation in the future - that's all the more reason to want to ensure
their views and voices are consistently and equally represented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20190130/6dbdbe80/attachment-0003.html>