[cabfpub] For Discussion: S/MIME Working Group Charter

[Ryan Sleevi]

Hi Tim, thanks for circulating this (very rough) draft.

I think it sets a lot of ambitious work out, and I think as optimistic as
that is, that can also be problematic.

I've got several responses inline, and while this is a good starting point,
I think a lot more discussion is going to be needed to get this right.

On Thu, May 17, 2018 at 6:39 PM, Tim Hollebeek via Public <
public at cabforum.org> wrote:

>
>
>
>
> A rough first draft, based on text I blatantly stole from the Server
> Certificate Working Group Charter and draft Code Signing Working Group
> Charter:
>
>
>
> S/MIME Working Group Charter (should it be the Email Working Group, so it
> can cover web-based mail as well?)
>

Could you define what you believe "web-based mail" to cover as well -
specifically, what existing PKI would be in scope of such a definition? I
can see a lot of problematic interpretations, so unless there's a strong
and compelling demonstration of existing systems that rely on third-party
CAs and use cryptographic schemes other than S/MIME, then I should hope the
answer is "No" :)


>
>
> Upon approval of the CAB Forum by ballot, the S/MIME Working Group
> (“Working Group”) is created to perform the activities as specified in this
> Charter, subject to the terms and conditions of the CA/Browser Forum Bylaws
> and Intellectual Property Rights (IPR) Policy, as such documents may change
> from time to time. The definitions found in the Forum’s Bylaws shall apply
> to capitalized terms in this Charter.
>

>
> SCOPE: The authorized scope of the S/MIME Working Group shall be as
> follows:
>
>
>
> 1. To specify S/MIME Baseline Requirements, Extended Validation
> Guidelines,
>

For example, the proposal to begin an S/MIME EV Guidelines is, frankly, to
put the cart before the horse quite a bit. I think it's worth setting a
more reasonable, well, Baseline, and then actually working to demonstrate
whether or not that Baseline is insufficient and if there is any value
whatsoever in exploring bifurcating that.


> Network and Certificate System Security Requirements,
>

Similarly, this begins by presuming that the requirements will be
different, and sets it in scope of the charter. Does it seem far better to
start with simply focusing on the validation requirements as a product
deliverable, and then, on the basis of the success or failure of that
effort, look to explore rechartering, should it prove to be necessary and
the requirements meaningfully distinct?

My concern with such an ambitiously broad charter is that for such de novo
work, with a large list of existing players that have been independently
doing their own thing, it might be far better for the producitivity and
focus of a WG to narrowly define its efforts, produce a meaningful, viable,
and adopted deliverable, and then explore increasing the scope if
necessary. This is no different than the common refrain of most SDOs -
which is don't bite off more than you can chew :)


> and other acceptable practices for the issuance and management of code
> signing certificates
>

While we discussed that you'd been working on this for a while, after I
raised concerns about the risks of rushing this, it looks like avoidable
errors may have crept in, in that this still clearly says code signing
certificates.


> used to sign executables, libraries, and apps.
>

Rushed? :)


2. To update such requirements and guidelines from time to time, in order
> to address both existing and emerging threats, including responsibility for
> the maintenance of and future amendments to the current S/MIME Baseline
> Requirements, Extended Validation Requirements, and Network and Certificate
> System Security Requirements.
>
>
>
> 3. To perform such other activities that are ancillary to the primary
> activities listed above.
>
>
>
> OUT OF SCOPE: The S/MIME Working Group will not address certificates
> intended to be used primarily for client or server authentication, Code
> Signing, VoIP, IM, or Web services. The Code Signing Working Group will not
> address the issuance, or management of certificates by enterprises that
> operate their own Public Key Infrastructure for internal purposes only, and
> for which the Root Certificate is not distributed by any Application
> Software Supplier.
>
>
>
> Anticipated End Date: None.
>
>
>
> Initial chairs and contacts: TBD
>
>
>
> Members eligible to participate: The Working Group shall consist of two
> classes of voting members, the Certificate Issuers and the Certificate
> Consumers. The CA Class shall consist of eligible Certificate Issuers and
> Root Certificate Issuers meeting the following criteria:
>
>
>
> (1) Certificate Issuer: The member organization operates a certification
> authority that has a current and successful WebTrust for CAs audit, or ETSI
> TS 102042, ETSI 101456, or ETSI EN 319 411-1 audit report prepared by a
> properly-qualified auditor, and that actively issues email certificates,
> such certificates being treated as valid when verified by software from a
> Certificate Consumer Member. Applicants that are not actively issuing
> certificates but otherwise meet membership criteria 7 may be granted
> Associate Member status under Bylaw Sec. 3.1 for a period of time to be
> designated by the Forum.
>
>
>
> (2) Root Certificate Issuer: The member organization operates a
> certification authority that has a current and successful WebTrust for CAs,
> or ETSI TS 102042, ETSI TS 101456, ETSI EN 319 411-1 audit report prepared
> by a properly-qualified auditor, and that actively issues email
> certificates to subordinate CAs that, in turn, actively issue email
> certificates, such certificates being treated as valid when verified by
> software from a Certificate Consumer Member. Applicants that are not
> actively issuing certificates but otherwise meet membership criteria may be
> granted Associate Member status under Bylaw Sec. 3.1 for a period of time
> to be designated by the Forum.
>
>
>
> (3) A Certificate Consumer can participate in this Working Group if it
> produces a software product intended for use by the general public that can
> validate S/MIME signatures attached to email messages. The Working Group
> shall include Interested Parties and Associate Members as defined in the
> Bylaws. Voting structure: In order for a ballot to be adopted by the
> Working Group, two-thirds or more of the votes cast by the Certificate
> Issuers must be in favor of the ballot and more than 50% of the votes cast
> by the Certificate Consumers must be in favor of the ballot. At least one
> member of each class must vote in favor of a ballot for it to be adopted.
> Quorum is the average number of Member organizations (cumulative,
> regardless of Class) that have participated in the previous three S/MIME
> Working Group Meetings or Teleconferences (not counting subcommittee
> meetings thereof). If three meetings have not yet occurred, quorum is ten
> (10).
>

I can't recall, but what about updates, to both software and root stores -
how does that apply in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180517/63b66b27/attachment-0002.html>