Re: [cabfpub] Final Minutes of the CA/B Forum meeting August 5, 2021

[Ryan Sleevi via Public]

On Thu, Aug 19, 2021 at 12:12 PM Dean Coclin via Public 
wrote:

> 9. Any Other Business
>
> Yoshiro Yoneya asked if anyone had attended the IETF meetings last week.
> Any updates?
>
> Ryan stated that Google, DigiCert (Tim Hollebeek) were involved in the
> LAMPS
> discussion. ACME was covered.  DigiCert is working in the LAMPS group.
> Document signing EKU creation was discussed.  Google is not supportive for
> many reasons.  Long discussions on this topic in the IETF meeting and best
> to review the minutes: (https://datatracker.ietf.org/doc/minutes-111-acme/
> )
>

I received a question off-list about this, and so for clarification for the
minutes:

Relevant to CA/B Forum were meetings for ACME and LAMPS, both of which met.
The minutes for ACME are at the link provided above, the minutes for LAMPS
are https://datatracker.ietf.org/doc/minutes-111-lamps/

The document signing EKU was discussed within LAMPS, but the primary
discussion was and is on the list, at
https://mailarchive.ietf.org/arch/msg/spasm/Ix2QfVLyWDBLtph4XLXVRuC-Mes/
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping

[Ryan Sleevi via Public]

On Thu, Apr 29, 2021 at 10:36 AM Rob Stradling via Public <
public@cabforum.org> wrote:

> > I don’t think the creation of another WG would be justified or useful
>
> Practically, that may well be the case, but I think it's right to arrive
> at that conclusion by going through this thought process rather than
> circumventing it.
>
> > I don’t see an issue with the CS WG defining requirements for
> timestamping as long as it’s very clear that this is ONLY for timestamping
> used with CodeSigning certificates so that is no violation of the scope of
> the WG.
>
> Policing "ONLY for timestamping used with CodeSigning certificates" seems
> like it would be hard.  A timestamping server has no idea whether it's
> being asked to timestamp signed code or some other "datum" (to quote
> RFC3161).
>
> Sectigo's publicly-trusted RFC3161 timestamping service (and the
> timestamping certificates that it uses) is expected to be used in
> conjunction with both Code Signing and Document Signing.
>

Indeed Rob, I think this gets to the heart of the concern.

If the CSC WG is expecting that CAs will stand up separate EVCS
Timestamping services, exclusively to be used for code signing (which
cannot be enforced by the TSA), from a separate hierarchy, then at least we
should be clear about that.

The fundamental issue here is that the references to timestamping appear to
be implementation/policy-specific to a particular implementor, rather than
generalized regarding code signing. I appreciate the challenge here (code
outliving the code signing certificate), and I can understand the rationale
for wanting to address it, but it fundamentally feels like an attempt to
scope an entirely unrelated service, which has no **defined** interaction,
and which fundamentally is a matter of Relying Party policy.

It seems the CSC WG should define how the CS *certificates* work, and the
broader question about how code signing is conveyed (e.g. PKCS#7/CMS, ZIP
files, bespoke vendor format - all of which are practically deployed
today), or how those *certificates* are authenticated after their useful
lifetime, is really a question for root program policies, in the absence of
industry norms. And there could be opportunity here for something. However,
if the CSC WG is determined to have this scoped within its charter, which
is still something highlighted previously as problematic, then it really is
and must simply be scoped to CS, and that's fundamentally saying a new,
separate trust hierarchy "should" be established.

We previously discussed, during the chartering of the S/MIME WG, exactly
this issue (the need for a separate WG), due to the attempts to conflate
S/MIME WG with document signing, since they both may choose to use legal
identities in addition to or in lieu of technical identities (like an email
address). This was the major blocker to getting the S/MIME charter
approved, but we managed to eventually do so by making it clear document
signing (and the related support services, including timestamping) are out
of scope of S/MIME.
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Re: [Cscwg-public] Code signing and Time stamping

[Ryan Sleevi via Public]

To make sure I follow the logic here:

EVCS states:

> "These Guidelines describe the minimum requirements that apply to the
> issuance of Extended Validation Code Signing Certificates and EV
> signatures. Certification Authority, Timestamp Authority and Signing
> Authority are all governed by these Guidelines. The Timestamp Authority and
> the Signing Authority are optional components of the environment."


The EVCS then further states, within Section 9.4:

"Timestamp Authorities and Signing Authorities may obtain an EV Timestamp
> Certificate or EV Code Signing Certificate (respectively) with a validity
> period not exceeding one hundred and thirty five months. The validity
> period for an EV Code Signing Certificate issued to a Subscriber MUST NOT
> exceed thirty-nine months.
> The validity period for an EV Code Signing Certificate issued to a Signing
> Authority that fully complies with these Guidelines MUST NOT exceed one
> hundred and thirty five months. The validity period for an EV Timestamp
> Certificate issued to a Timestamp Authority that fully complies with these
> Guidelines MUST NOT exceed one hundred and thirty five months."


And then finally, in Section 16:

> (1) An EV Timestamp Authority MUST protect its Private Key in a crypto
> module validated in accordance with FIPS 140-2 Level 2.
> (2) An EV Timestamp Authority MUST be synchronized with a UTC(k) time
> source recognized by the International Bureau of Weights and Measures
> (BIPM).


Separately, in the CS 1.0 draft (
https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf
), it's scope is defined as:

> "The scope of these Requirements includes all “Code Signing Certificates”,
> as defined below, and associated Timestamp Authorities, and all
> Certification Authorities technically capable of issuing Code Signing
> Certificates, including any Root CA that is publicly trusted for code
> signing and all other CAs that might serve to complete the validation path
> to such Root CA"


Section 9.4, similar to EVCS, places a requirement on validity, but also on
the private key usage period and strength (by reference to Appendix A).

Section 13.2.1 places requirements that the CA needs to maintain revocation
information for the Timestamp Certificate for 10 years past expiration, and
must provide notice to Application Software Suppliers of at least 90 days
if they intend to YOLO it and start ignoring requirements.


Within the charter of the WG (***emphasis added***)
"The authorized scope of the CSCWG SHALL be to discuss, adopt, and maintain
policies, frameworks, and sets of standards ***related to the issuance and
management of code signing certificates*** by third-party Certificate
Issuers under a publicly trusted root (and not code signing certificates
issued under a private root CA), limited as follows"

My question to the proponents is thus this:
Do you believe the existing language (both charter and documents) allows
the arbitrary addressing of Timestamping Authorities, or does it
specifically pertain to Timestamping Authorities used to provide timestamps
for codesigning (which neither of the documents actually details how such
timestamp tokens or certificates are included, presumably to be left up to
code signing implementers)?

It would seem that those arguing that TSAs are in-scope are suggesting that
Timestamping is part of "the policies, frameworks, and set of standards"
related to code signing certificates, even though no part of either draft
actually details how such certificates are consumed. My minimal hope is
that there's agreement that the CSWG is not chartered to tackle
Timestamping in general - i.e. a Timestamp Baseline Requirements - and is
only narrowly chartered to the extent such information pertains to code
signing certificates (if the argument that it's related is accepted). Yet
it also seems to ignore the limits further placed within the charter (i.e.
points c - j of the charter), suggesting those are not restrictions on
those documents but rather additions to the scope.

Part of the reason of the concern is simple: If we accept and acknowledge
this interpretation as valid, what would prevent the CSCWG from saying "Oh,
hey, submissions to the Signing Authority need to be secured via TLS", and
then arguing that because TLS is used as part of generating code
signatures, TLS profiles are in scope for the CSC WG. You might say that
sounds extreme, but I hope you can see why it's concerning that a dependent
service is being seen as in-scope of a charter limited to a particular type
of certificate.

It's the same reason to feel uncomfortable about trying to, say, redefine a
"code signing certificate" to include a TSA by saying "Well, when you think
about it, a TSA is really signing a hash of code that already has a
signature, so a TSA is in a way a code signing certificate as well, so it's
in scope", because that logic could also say "Well, code is delivered via
TLS, and the certificate is used to 

[cabfpub] Election of S/MIME Vice Chair

[Ryan Sleevi via Public]

Hey Stephen,

As I was trying to finish setting up the permissions for repositories
following the separation of repositories [1], I realized I needed to set
the S/MIME Chair and Vice Chair up.

It took me a while to dig through the minutes to find out how that went.
Recall that the S/MIME Charter [2][3] established you as temporary chair,
with the requirement that the SMCWG, in its first Working Group
Teleconference, establish a chair and vice-chair.

It would appear that, on the first call [4] on July 22, you were elected as
Chair. However, it looks like the WG diverged from its charter in that
first call, in that it didn't establish a vice chair (as required by 3.1).
It looks like the SMCWG also didn't hold a public vote for members (as
required by 3.2.2), as abstensions were noted but not recorded in the
minutes.

Looking at the minutes further, it looks like a Vice Chair was not elected
until September 2 [5], and this was done by just a voice vote on the call.

The Forum Bylaws are a bit more restrictive here, as captured in 5.3.1(3),
which states:
"After the charter is approved, the CWG MAY elect a new Chair and Vice Chair
elected by CWG members following the procedures of Bylaws Section 4.1 as
closely as possible. The initial term for CWG officers shall expire on
November
30 of the next even-numbered year after the CWG is established in order to
be
synchronized with the terms of Forum officers."

The Forum Bylaws Section 4.1 describes the Ballot process for selecting
Chairs and Vice-Chairs. I don't see any record of a Ballot being followed,
as we recently did for the Forum and SCWG Chair/Vice-Chairship.

I admit, I haven't seen how the CSC CWG handled this bootstrapping issue,
so this is only my first time looking at a de novo CWG, but this feels like
it might have missed some steps required in our Bylaws? Or does this
highlight an area where the SMCWG charter was ambiguous, and something to
think about for future charters?

Separate from those concerns, can you at least help me confirm that:
* You're the Chair
* Mads is the Vice-Chair

Thanks!

[1] https://archive.cabforum.org/pipermail/public/2020-October/015176.html
[2]
https://cabforum.org/2020/02/12/ballot-forum-11-creation-of-s-mime-certificates-working-group/
[3]
https://github.com/cabforum/forum/blob/5f2183ec1542bfc9b2b7888b94b4b8fffed3ccb9/SMCWG-charter.md
[4]
https://lists.cabforum.org/pipermail/smcwg-public/2020-August/14.html
[5]
https://lists.cabforum.org/pipermail/smcwg-public/2020-September/31.html
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting begins on Special Ballot Forum-16: Election of CA/Browser Forum Vice Chair

[Ryan Sleevi via Public]

Google votes YES on Special Ballot FORUM-16

On Wed, Oct 21, 2020 at 10:15 PM Dean Coclin via Public 
wrote:

> Voting begins on this ballot below:
>
>
>
>
> The following motion has been proposed by the CA/Browser Forum Chair
> Dimitris Zacharopoulos of HARICA.
>
> Purpose of Ballot
>
> This special ballot is to confirm the new Vice Chair of the CA/Browser
> Forum.
>
>
>
> --- MOTION BEGINS ---
>
>
> In accordance with Bylaw 4.1(c), *Karina Sirota* representing Microsoft
> is hereby elected Vice Chair of the CA/Browser Forum for a term commencing
> on November 1, 2020 and continuing through October 31, 2022.
>
> --- MOTION ENDS ---
>
>
>
> The procedure for approval of this ballot is as follows:
>
> *Special Ballot Forum-16 - Election of CA/Browser Forum Vice Chair*
>
> *Start time*
>
> *End time*
>
> Discussion (7 days)
>
> October 14, 2020 at 11:00 am Eastern Time
>
> October 21, 2020 at 11:00 am Eastern Time
>
> Vote for approval (7 days)
>
> October 21, 2020 at 11:00 am Eastern Time
>
> October 28, 2020 at 11:00 am Eastern Time
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Separate GitHub Repositories for Each Working Group

[Ryan Sleevi via Public]

On Wed, Oct 7, 2020 at 8:27 PM Aaron Gable via Public 
wrote:

> I have just a couple questions, none of which I think are important enough
> to
> count as objections or block this proposal from moving forward:
>
> 1) Has the Infrastructure Subcommittee considered the option of using
> `git filter-branch` (or its easier-to-use unofficial cousin,
> git-filter-repo:
> https://github.com/newren/git-filter-repo/) instead of forking +
> deleting? I
> believe that this solution would not work well for the new "servercert"
> repo,
> as the history rewrite would break redirects from old "documents" urls
> which
> contain specific commit or blob hashes, but it might be a good option to
> preserve full history (including of tools) for the other repositories if
> that
> is desired.
>

Yeah, this was effectively the approach desired for:
> The few commits that need to be preserved in these repos will be manually
re-created.

Namely, the non-"servercert" repos would only have the commits relevant for
the appropriate documents preserved (i.e. there's no need for the
codesigning repo to preserve edits to the BRs)


> 2) Given that the plan is for the "smime" and "code-signing" repositories
> to
> retain the tooling necessary for building and deploying their documents (at
> least until the "tools" repo is finalized), why are they being created
> fresh
> instead of forked + deleted like the other, larger repositories? Having the
> same creation process for all new repos, regardless of their size or the
> importance of their documents' edit history, seems like a good idea.
>

The number of commits outside of the servercert WG, affecting the other
documents, was something like less than two dozen, and most of that was
largely the Bylaws.

I'm not sure the benefit of the same creation process? The benefit here is
you wouldn't need to download 8+ MB of unrelated diff-history when cloning
the repro. Mostly, the discussion was how "Everything other than
servercert-wg can be done by hand in a few minutes, so no need to have a
massive process here".


> 3) Does the Infrastructure Subcommittee have a plan for preventing the
> creation of orphan branches in the future, like those that will be deleted
> from the "servercert" and "forum" repos? My understanding is that these
> branches come into being representing proposed ballots which then fail to
> be
> ratified.
>

The Ballot Instructions specifically provide guidance to avoid this. The
affected branches are largely those affected prior to the adoption of those
requirements. It also related to fact that previously, almost every member
of the /documents repo had the ability to directly commit to "main" and had
the ability to create branches.

The model captured in the Wiki tries to encourage the fork+(do work in your
fork), rather than the unfortunate situation in the past where some commits
were directly on "main" and some were in branches off the main /documents


> Are there proposals to clean up such branches on a regular ongoing
> basis, or to prevent their creation in the first place (e.g. by having the
> ballot pull request come from its sponsors' fork of the repo, rather than
> from a branch within the repo itself)?
>

Exactly this. We've already turned off the direct write access to "main",
and even admins are required to go through a PR-review process to land
commits there. The workflow documented on the Wiki also provides
instructions for how to provide stable links. We've also been working to
update the continuous integration so that artifacts are produced on PRs,
specifically PRs from sponsors' forks, by looking at switching from Travis
to GitHub Actions and streamlining the process. Under the current Travis
integration, there was a bias to using cabforum/documents branches because
that allowed the CI to run with the AWS secrets, so that's why that
sometimes happened from infrastructure WG members, to ensure that document
previews (for review and for IPR) would be generated.
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting begins on Special Ballot Forum-15: Election of CA/Browser Forum Chair

[Ryan Sleevi via Public]

Google votes YES to Ballot FORUM-15

On Mon, Sep 14, 2020 at 11:11 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

>
> Voting begins for Special Ballot Forum-15.
>
> Dimitris.
>
>
> On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:
>
>
> The following motion has been proposed by the CA/Browser Forum Chair
> Dimitris Zacharopoulos of HARICA.
> Purpose of Ballot
>
> This special ballot is to confirm the new Chair of the CA/Browser Forum.
>
> --- MOTION BEGINS ---
>
> In accordance with Bylaw 4.1(c), *Dean Coclin* representing Digicert is
> hereby elected Chair of the CA/Browser Forum for a term commencing on
> November 1, 2020 and continuing through October 31, 2022.
>
> --- MOTION ENDS ---
>
>
> The procedure for approval of this ballot is as follows:
>
> *Special Ballot Forum-15 - Election of CA/Browser Forum Chair*
>
> *Start time*
>
> *End time*
> Discussion (7 days)
> September 7, 2020 at 11:00 am Eastern Time
>
> September 14, 2020 at 11:00 am Eastern Time
> Vote for approval (7 days)
>
> September 14, 2020 at 11:00 am Eastern Time
>
> September 21, 2020 at 11:00 am Eastern Time
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

On Wed, Sep 16, 2020 at 2:17 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
>
> On 2020-09-16 8:52 μ.μ., Ryan Sleevi wrote:
> > I realize you've provided further context, but my hope is that by
> > laying out the fundamentally wrong assumptions above, which your
> > further replies build on, we can make progress here in understanding
> > why "Everyone already reviewed the Ballot, what's the harm" is a
> > deeply flawed assumption that permeates the subsequent decision making.
>
> Early in this thread, when you presented the example ballot A and B
> should not produce an IPR review of A + B because failure of either A or
> B would block the other, I agreed that the IPR reviews should be
> distinct. This solves the possible legal issue you described.
>
> The second issue is the creation of an aggregated or separate final
> guidelines which exploded the thread.
>

The two are coupled. You cannot separate these; the IP review is what
produces a Final Guideline. If you separate out for IP review, by
necessity, it separates out the publication of a Final Guideline.


> The logical assumption I make is that CAs, especially the ones outside
> the Forum, assuming they don't check the ballots, IPR Review and such,
> they should at least directly check and monitor when a new Final
> Maintenance Guideline is published. These CAs will either see three
> distinct Final Guidelines becoming effective on the same day [versions
> 1.2.1, 1.2.2 (including changes from 1.2.1) and 1.2.3 (including changes
> from 1.2.1 and 1.2.2)], or one aggregated version 1.2.1 that will
> include changes from all ballots that cleared IPR review.
>
> In my understanding these CAs are better served by bringing the
> aggregated final Guideline to their compliance/engineering department,
> rather than versions 1.2.1, 1.2.2 and 1.2.3. It doesn't make sense for
> me to create 1.2.1 and 1.2.2 since all the introduced changes will be in
> 1.2.3.
>

Put differently, it appears that you're stating the "expected" process if
CAs (whether member or not), should be individually checking each Ballot
and IP review, rather than the Final Guideline, in order to understand what
changes.

I'm saying that's an unreasonable (as practiced) and unfair (in what it
expects) assumption. If you recognize the benefit of understanding what was
in SC30 vs SC31, then it's not clear to me how you cannot recognize the
benefit of seeing that reflected in the Final Guideline.

The very point of creating 1.2.1 is to show what changed from 1.2.0, to
then create a 1.2.2 that showed what changed from 1.2.1. Your approach, of
creating an aggregate 1.2.3, does indeed show *everything* that changed
from 1.2.0, but that's the very problem in the first place! By showing a
series of aggregate Ballots, it destroys the very context that separate
Ballots are trying to preserve, of logically grouping related changes, to
make them easier to process and understand the systemic set of changes.

It appears you recognize that value, but you think it should only exist at
the Ballot level. Yet I'm trying to tell you that we have clear evidence
that it's not working.
It appears you recognize the value of distinction, from the IP review
process, so continuing that to the Final Guideline level produces no new
work; you reuse the exact same document you used for the IP review (by
design, of the IP review process)


> I realize that we are spending a disproportional amount of time debating
> on this, but I honestly can't see -yet- the "disastrous consequences"
> that this can create, and I am very curious to see why I can't see that.
>

Because you've specifically asked me to stop providing references to CA
compliance incidents. In particular, I've got a pattern of CAs, both
Members and non-Members of the Forum, having trouble adapting to changes,
for a variety of reasons. I am fundamentally opposed to anything that makes
it harder to understand the context and relevance of the changes.

You seemingly acknowledge the issue with the IP review, and I would say the
necessity of formation of a PAG would absolutely be disastrous for any
productivity, especially under aggregated changes.

I totally get that the crux of your argument is "Isn't it better for CAs to
be able to see everything that changed at once?", as if it makes it easier
to carefully review and implement changes. However, what we're consistently
seeing is CAs say "Oh, a bunch of stuff changed at once, so we overlooked
things" - and making it clearer, more digestible, to work through each
logical change is one of things to address that. I understand that there's
a "If you have to review each change, it makes it harder to see the big
picture", but that's not the ostensible argument for why you started this
(as I understand it), it was time-savings. And I understand you're saying
"CAs can (and implicitly, should) look at individual Ballots to understand
each of those contextual changes", and in an ideal world, that would be

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

On Wed, Sep 16, 2020 at 1:30 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> You seem to be conflating my role, as Chair, with HARICA and how HARICA
> evaluates changes in ballots.
>

No, I'm trying to call out that you may be assuming that how HARICA
evaluates Ballots is how everyone evaluates Ballots. This is most obvious
in your follow-up, which is why I'm calling out the concern. How HARICA
does things should not necessarily influence how the Chair does things, and
that's the disconnect I'm trying to call out, because we have evidence that
it's not happening as described.


> I'd like to start off by clarifying that each Member (HARICA as one of the
> voting Members), reviews each ballot independently and votes after
> evaluating the changes of each individual ballots. When a ballot passes,
> this means that each Member must prepare for the changes to be effective as
> soon as the IPR period is over. This has nothing to do with having 2-3
> ballots being added in a single new version of the new Guideline, because
> the Member has already been aware of the upcoming changes because of the
> already voted ballot. This is my personal understanding of the situation,
> and I would even say that it's common sense.
>

There's several important flaws here in this assumption.

One, not every CA that makes use of the Baseline Requirements is a Member
of the Forum. So, at the outset, the process you describe doesn't apply to
them; they logically only see the final result.
Two, not every CA that participates as a Member of the Forum votes on the
Ballots, or even necessarily reviews. We've seen several CAs specifically
call out that the volume of activity in the Forum, versus their current
staffing availability, is often inadequate. As such, they only review the
final product, and otherwise abstain or don't participate in Ballots.
Three, everything you describe, in terms of individual Ballot review, is
precisely the property we're trying to make sure is preserved through the
IP review. The IP review, by aggregating, forces CAs that want to follow
the process you described to then go through the individual Ballots to
achieve the same end result.

At the core, the assumption here is that everyone is following at the time
of Balloting, and everyone knows how to obtain and review the individual
Ballots in isolation, from engineering, to compliance, to legal, but that's
not a fair assumption, and that's not how it's working out in practice.


> As the Chair, to the best of my ability I interpret the Bylaws, and with
> the help of the Vice Chairs (who have worked with me as officers for almost
> two years) I am ultimately responsible for producing the necessary
> documents and all other activities according to the Bylaws. Aggregating
> ballots to a single version of a Guideline is not prohibited, it has been
> used several times already, yet you found an opportunity to attack me
> personally and imply things for HARICA that are totally irrelevant with
> this issue.
>

I didn't imply things for HARICA. I pointed out how you're generalizing
HARICA's approach here and assuming it's the general workmode of everyone
affected by the Forum, while we have repeated evidence that this is not the
case. The most recent aggregation has lead to a compliance incident, for a
Member of the Forum, who voted on a Ballot. While that is just one example,
and we're still gathering details, an obvious systemic issue here is the
recent trend to aggregation makes it more difficult, and more work, for CAs
to ensure compliance, rather than less. The incredibly relevant context of
Ballots is lost through the aggregation.

As it applies to the legal risks that we spent two years trying to address,
it reintroduces the problems we've tried to address multiple times in the
Forum, from the introduction of the requirement to produce Final Guidelines
with Ballots, the shift to version-managed documents, and the adoption of
our updated Bylaws and IP policy. I wholly understand this was made in
good-faith as an attempt to reduce the time involved from being a Chair,
but it's had disastrous consequences, and leaves the door open for even
greater risks. It bears calling out precisely because we're seeing already
that the approach does not work. I started off by trying to understand the
problems you're trying to solve, so we can work and prioritize reasonable
alternative solutions for them, but the fact that there's a fundamental
misunderstanding about the problems being caused has taken the conversation
in a very different direction.

I realize you've provided further context, but my hope is that by laying
out the fundamentally wrong assumptions above, which your further replies
build on, we can make progress here in understanding why "Everyone already
reviewed the Ballot, what's the harm" is a deeply flawed assumption that
permeates the subsequent decision making.
___
Public mailing list

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

On Wed, Sep 16, 2020 at 2:12 AM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
>
> On 2020-09-16 2:43 π.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr> wrote:
>
>>
>>
>> On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
>>
>>
>>
>> Sure, I can do that but in any case I forwarded it the argument on the
>> list. I also support this argument that aggregating new versions of the
>> documents saves time.
>>
>
> While you're the only one qualified to measure whether it saves time, as a
> browser, this raises a host of questions for understanding how CAs are
> staying abreast of changes and reviewing them. This is actually critical,
> given that I've seen multiple CA incidents where CAs have reported that
> they have trouble staying abreast of changes, even for ballots they voted
> for! So it suggests to me that some of the current ways that CAs are
> keeping up to date are flawed, or lend themselves to easy mistakes.
>
>
> I hope you realize that this is not related with Forum's activities. The
> Forum produces standards/Guidelines. Whether CAs, Relying Parties adhere to
> those standards/Guidelines and update their processes/products is a
> different issue.
>

I hope you realize that questions about the working mode of the Forum
impacting the ability to make reliable use of the Forum's work product is,
of course, essential to the continued value and participation in the Forum.

If the view of the Chair of the Forum is that the Forum should not consider
how usable its work product is, which is voluntary standards that can be
used by Browsers, then I think it raises deep concerns about the value of
the Forum.



> Naturally, if we had the specific member, we could ask them to describe
> their process for staying aware of changes, and why one document makes that
> easier. For example, I'd be deeply concerned if a CA was looking at an
> aggregated SC28+SC35, since they might mistake a meaningful normative
> change as a cleanup or clarification, or similarly, mistake or overlook an
> important clarification because they're distracted by logging changes.
>
>
> I don't think that's necessary. It seems very reasonable to me that
> reviewing one redline document that introduces changes from two or three
> ballots, is more convenient and simpler than having to review two or three
> redline documents to reach the same result.
>
> If there are questions about a new requirement or an introduced change,
> the discussion of the specific ballot that introduced the change is there
> for anyone to review and get a better understanding on the rationale and
> get clarifications. In some cases, even that is not enough, and we
> encourage people to submit questions to the questi...@cabforum.org, or if
> these questions come from Members, they can post questions directly to the
> WG public mailing list.
>

I am concerned that you're allowing your personal judgement, which
unfortunately is seemingly clouded by confusion of the issues, to impair
your ability to effectively and respectfully Chair, by selectively picking
and choosing which viewpoints are respected.

I realize you believe it's very reasonable, but that appears to be a lack
of familiarity with the issues we, as browsers, are seeing. As a Forum CA
Member, that's concerning for HARICA, but as a Chair, that's even more
inexcusable. Ballots are specifically produced to group their logical
related changes within a single ballot, to make it clear the many related
things that need to change in order to accomplish a particular goal, as
stated in the Ballot. The aggregation approach destroys that contextually
relevant information.

Your further suggestion that it's confusion that a CA is actively aware of,
and thus can and should avail themselves of questions, when that cannot be
further from what I stated. It is the lack of awareness that causes the
issue, and this lack of awareness is heightened by the increasing number of
changes that come in aggregation.

As a member, HARICA represented that it was overloaded with reviewing
changes, and concerned about the quality of results at the continued
cadence in light of COVID. I would expect that you (HARICA), of all
organizations, should thus be familiar with the risk of many changes
causing important changes to be *overlooked*, rather than misunderstood.

Ultimately, I understand that you, individually, have a workmode that works
for you. However, that workmode is demonstrably not working in industry. As
Chair, I'm requesting you do not impose your preferences on the Forum,
particularly when doing so impairs and impacts the ability for CAs to
adhere to these Guidelines, and thus greatly diminishes the value of the
Forum as a producer of such documents. Again, the relevance of the Forum is
how well it serves industry, and that has to be acknowledged as being how
well its voluntary Guidelines, such as the Baseline Requirements, provide
value to browser 

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
>
> On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 12:25 PM Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr> wrote:
>
>> I think you have a point about A + B, so we should have independent
>> review periods for each ballot as we did with version 1.6.4 (we had
>> independent ballots to be reviewed and then a combined/aggregated new
>> version of the BRs).
>>
>> I also received some personal messages supporting the "aggregated"
>> practice as it seems to be much more efficient for a CA's compliance review
>> to check against one new BR rather than 2 or 3 separate ones within a very
>> short timeframe.
>>
>
> As Chair, could I ask you to encourage these to be shared on the list? I
> think it's troubling the increased amount of off-list messages used to
> justify Forum behaviour. This feels very much like the mode which the Forum
> explicitly tried to move past with our move to open lists and minuted
> calls, so that we can more accurately understand perspectives and ask
> questions. Certainly, I hope it should be uncontroversial that the Forum
> helps us understand the many different perspectives and constraints, and
> this sort of "appeal to private communication, anonymized, without data"
> actively harms the ability of the Forum to function and improve. This is
> part of why we have public discussion
>
>
> Sure, I can do that but in any case I forwarded it the argument on the
> list. I also support this argument that aggregating new versions of the
> documents saves time.
>

While you're the only one qualified to measure whether it saves time, as a
browser, this raises a host of questions for understanding how CAs are
staying abreast of changes and reviewing them. This is actually critical,
given that I've seen multiple CA incidents where CAs have reported that
they have trouble staying abreast of changes, even for ballots they voted
for! So it suggests to me that some of the current ways that CAs are
keeping up to date are flawed, or lend themselves to easy mistakes.

Naturally, if we had the specific member, we could ask them to describe
their process for staying aware of changes, and why one document makes that
easier. For example, I'd be deeply concerned if a CA was looking at an
aggregated SC28+SC35, since they might mistake a meaningful normative
change as a cleanup or clarification, or similarly, mistake or overlook an
important clarification because they're distracted by logging changes.

Indeed, I'd be quite worried if someone was specifically using the Redline
PDF for reviewing changes (in the full document), without also looking at
any supporting discussion and included redlines, to also make sure they
have an at-a-glance understanding of what's changing. Of course, I'm not a
CA, so it's much better to hear, in a CAs own words, the processes they
employee, so they can describe why one document saves more time.

Selfishly, my priority is not in saving time for CAs, if saving time risks
correctness. I'd much rather ensure CAs do the right thing, and
consistently implement it, even if it means they have to take more time to
be careful and thorough. This is no different from me wanting to make sure
my surgeon was certain my spleen needed to be removed, before scheduling
the surgery, rather than just have them open me up and see what looks
interesting or relevant.


> Once I have the review period redline ready, it usually takes between 30
>> minutes to 1 hour to create the final documents, upload them to the wiki
>> (the word versions), produce the final PDF versions and upload them to the
>> public web site.
>>
>
> Wow! I wouldn't have expected this to be more than 5 minutes, so that's a
> really surprising amount of time!  Do you know where the bulk of the time
> is, so we can prioritize? That said, it sounds like your response here
> aggregated 2-5 - is that roughly right?
>
>
> Yes, because to produce a Final Guideline and a redlined version in a
> non-GitHub version is quite painful. In the GitHub version, things are
> faster but again I need to create the redline manually, compare the two
> .docx versions produced by GitHub (before and after the merge to Main),
> check everything like track changes mode, make sure the ToC is not tracked
> and other minor details.
>

I'm not really sure I understand this process. It might be useful to have a
demonstration on an Infrastructure WG call, to best see the challenge.
Beyond helping the (presumptive, given single candidate) future chair, it
might also help figure out opportunities for improvement here :)


> Then, create a PDF without the formatting comments (otherwise the PDF
> contains formatting changes in the redline which doesn't look good). Then
> make the changes to the web sites, wiki, etc. I wish I could make that in 5
> minutes :-)
>
> This would probably require having our entire public website on GitHub and
> 

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

On Tue, Sep 15, 2020 at 12:25 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> I think you have a point about A + B, so we should have independent review
> periods for each ballot as we did with version 1.6.4 (we had independent
> ballots to be reviewed and then a combined/aggregated new version of the
> BRs).
>
> I also received some personal messages supporting the "aggregated"
> practice as it seems to be much more efficient for a CA's compliance review
> to check against one new BR rather than 2 or 3 separate ones within a very
> short timeframe.
>

As Chair, could I ask you to encourage these to be shared on the list? I
think it's troubling the increased amount of off-list messages used to
justify Forum behaviour. This feels very much like the mode which the Forum
explicitly tried to move past with our move to open lists and minuted
calls, so that we can more accurately understand perspectives and ask
questions. Certainly, I hope it should be uncontroversial that the Forum
helps us understand the many different perspectives and constraints, and
this sort of "appeal to private communication, anonymized, without data"
actively harms the ability of the Forum to function and improve. This is
part of why we have public discussion



> More answers inline.
>
> On 2020-09-15 5:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr> wrote:
>
>> On 14/9/2020 8:08 μ.μ., Ryan Sleevi wrote:
>>
>> Yes, I'm aware of the "what", but it's not clear the "why".
>>
>> The act of combining ballots is relatively new, as you can see from
>> https://cabforum.org/baseline-requirements-documents/ . Producing
>> multiple versions of the Guidelines, linear based on when the Ballot
>> concluded, was something our GitHub flow intentionally was to make easy.
>> While that page stopped listing dates of adoption around Ballot 189, you
>> can see previous ballot pairs (e.g. 171+164, 125+118+134+135) that did that.
>>
>> It seems worth figuring out the challenges you're facing, since it was
>> meant to be very easy to create a new version of the document for each
>> ballot, even ballots that conclude closely, and to have IP reviews as such.
>>
>>
>> The administrative overhead of updating public web sites, sending
>> additional emails, and the fact that we would have versions of the
>> Guidelines that would be valid for a few seconds (which seems unreasonable
>> for a public standards document), are some of the reasons behind aggregated
>> final guidelines. Version 1.6.4 aggregated 3 ballots, 1.6.7 and 1.7.1. had
>> 2 and now 1.7.2.
>>
>
>> This process was discussed with Dean and Wayne back in February 2019, and
>> we all considered it compliant with our Bylaws. The results of each IPR
>> review period were sent to the public lists without receiving any
>> objections or concerns.
>>
>> Although we have documented a GitHub workflow that supports the most
>> common case (one ballot, one IPR review, one Final Maintenance Guideline),
>> it should not prohibit aggregated ballots to minimize administrative
>> overhead or the production of Guidelines that have some reasonable validity
>> time.
>>
>> If there are strong objections to this process, we can revise it going
>> forward.
>>
>
> I think we should understand the concerns, so we can make sure we have
> solutions that work.
>
> The concerns for aggregated ballots is that, from an IP perspective, it
> makes multiple ballots share the same fate and can easily delay adoption.
> For example, imagine there are Ballots A and B. A makes a change to one
> section, B makes a change to another, and only through their combined
> implementation does a Member raise an IP concern.
>
> In the serialized approach, A then B, A can be introduced to the IP review
> and not introduce any IP obligations. It can become effective. When B is
> introduced and undergoes IP review, and an exclusion is filed (on the B+A),
> then B is basically sent to the PAG to work through what to do, while A
> remains effective.
>
> In the combined approach, A and B, when A+B trigger the IP review and
> result in the IP obligation. An exclusion is filed, and now A+B are sent to
> a PAG. The act of understanding whether it is A introducing the IP
> obligation or B introducing the IP obligation is left for the PAG to sort,
> with neither A nor B being effective until the PAG reaches recommendations.
>
> This was a concern debated at length throughout our governance process,
> and was indeed one of the core motivations for our IPR policy update
> (which, you may recall, was motivated by the removal of the "any other
> method" introducing obligations on the other enumerated methods). Our IP
> policy was revised to try to make it easier to distinguish whether A or B
> was introducing the obligation, and allow modifications like A (and
> subsequent modifications) to continue, even while B was addressed within
> the PAG.
>
> Beyond that explicit 

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> On 14/9/2020 8:08 μ.μ., Ryan Sleevi wrote:
>
> Yes, I'm aware of the "what", but it's not clear the "why".
>
> The act of combining ballots is relatively new, as you can see from
> https://cabforum.org/baseline-requirements-documents/ . Producing
> multiple versions of the Guidelines, linear based on when the Ballot
> concluded, was something our GitHub flow intentionally was to make easy.
> While that page stopped listing dates of adoption around Ballot 189, you
> can see previous ballot pairs (e.g. 171+164, 125+118+134+135) that did that.
>
> It seems worth figuring out the challenges you're facing, since it was
> meant to be very easy to create a new version of the document for each
> ballot, even ballots that conclude closely, and to have IP reviews as such.
>
>
> The administrative overhead of updating public web sites, sending
> additional emails, and the fact that we would have versions of the
> Guidelines that would be valid for a few seconds (which seems unreasonable
> for a public standards document), are some of the reasons behind aggregated
> final guidelines. Version 1.6.4 aggregated 3 ballots, 1.6.7 and 1.7.1. had
> 2 and now 1.7.2.
>

> This process was discussed with Dean and Wayne back in February 2019, and
> we all considered it compliant with our Bylaws. The results of each IPR
> review period were sent to the public lists without receiving any
> objections or concerns.
>
> Although we have documented a GitHub workflow that supports the most
> common case (one ballot, one IPR review, one Final Maintenance Guideline),
> it should not prohibit aggregated ballots to minimize administrative
> overhead or the production of Guidelines that have some reasonable validity
> time.
>
> If there are strong objections to this process, we can revise it going
> forward.
>

I think we should understand the concerns, so we can make sure we have
solutions that work.

The concerns for aggregated ballots is that, from an IP perspective, it
makes multiple ballots share the same fate and can easily delay adoption.
For example, imagine there are Ballots A and B. A makes a change to one
section, B makes a change to another, and only through their combined
implementation does a Member raise an IP concern.

In the serialized approach, A then B, A can be introduced to the IP review
and not introduce any IP obligations. It can become effective. When B is
introduced and undergoes IP review, and an exclusion is filed (on the B+A),
then B is basically sent to the PAG to work through what to do, while A
remains effective.

In the combined approach, A and B, when A+B trigger the IP review and
result in the IP obligation. An exclusion is filed, and now A+B are sent to
a PAG. The act of understanding whether it is A introducing the IP
obligation or B introducing the IP obligation is left for the PAG to sort,
with neither A nor B being effective until the PAG reaches recommendations.

This was a concern debated at length throughout our governance process, and
was indeed one of the core motivations for our IPR policy update (which,
you may recall, was motivated by the removal of the "any other method"
introducing obligations on the other enumerated methods). Our IP policy was
revised to try to make it easier to distinguish whether A or B was
introducing the obligation, and allow modifications like A (and subsequent
modifications) to continue, even while B was addressed within the PAG.

Beyond that explicit reason, the distinct versioning also helps better
review changes and tie back to ballots. It treats Ballots as they are -
logical units of change - rather than aggregations of change. The Forum
first started with an aggregation-of-change approach (through submitting
amendments and errata) and quickly confounded the ability to understand the
reconciled state. The same issue applies to unified ballots. Given that we
have CAs asserting that it's difficult to find changes in Ballots they
explicitly voted for, after lengthy reviews, and with policies incorporated
in at least two root programs, I'm incredibly sensitive to wanting to make
sure CAs are set up to succeed in following the Requirements, by making
changes discrete and digestible.

So that's the context about "why" serialized was intended. I'm also totally
sympathetic to the difficulty involved in producing ballots, especially as
we haven't quite got automation up to speed, and so I can understand why
wanting to avoid that work is undesirable. What I take from your reply is
that there are several tasks that, as a consequence of our current tooling,
represent undesirable time commitments. It's unclear if that's "5 minutes
more" or "5 hours more", and so your help in breaking down how much time it
takes for the following would be greatly useful, as it will help prioritize
what is most important to resolve. I suspect these can become priorities
for the Infrastructure WG.

1) 

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

Yes, I'm aware of the "what", but it's not clear the "why".

The act of combining ballots is relatively new, as you can see from
https://cabforum.org/baseline-requirements-documents/ . Producing multiple
versions of the Guidelines, linear based on when the Ballot concluded, was
something our GitHub flow intentionally was to make easy. While that page
stopped listing dates of adoption around Ballot 189, you can see previous
ballot pairs (e.g. 171+164, 125+118+134+135) that did that.

It seems worth figuring out the challenges you're facing, since it was
meant to be very easy to create a new version of the document for each
ballot, even ballots that conclude closely, and to have IP reviews as such.

On Mon, Sep 14, 2020 at 11:46 AM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
>
> On 2020-09-14 5:45 μ.μ., Ryan Sleevi wrote:
>
> Dimitris: Could you explain why it's necessary to integrate?
>
> It seems much better to have Ballot -> Distinct BR version, and there's
> nothing in our IP policy I'm aware of that requires you to send them as a
> combined review.
>
>
> The result of the IPR review will produce a new version of the Guidelines.
> Having two ballots with two IPR review periods would probably require
> creating two versions of the Guidelines, which is why we've been trying to
> combine reviews in the past, so we can bump up one version of the Guideline.
>
> Hope this helps.
>
> On Mon, Sep 14, 2020 at 4:38 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
>>
>> I just realized that ballot SC28 also contains changes to the BRs so I
>> will create a combined IPR review for ballots SC35 and SC28 later today.
>>
>> Thank you,
>> Dimitris.
>>
>>
>> On 2020-09-14 11:02 π.μ., Dimitris Zacharopoulos (HARICA) wrote:
>>
>> *NOTICE OF REVIEW PERIOD*
>>
>>
>>
>> This Review Notice is sent pursuant to Section 4.1 of the CA/Browser
>> Forum’s Intellectual Property Rights Policy (v1.3). This Review Period
>> is for two Final Maintenance Guidelines (30 day Review Period). Attached
>> are the complete Draft Guidelines subject of this Review Notice.
>>
>>
>> Ballots for Review: Ballot SC35
>> 
>> Start of Review Period: September 14, 2020 at 11:00 Eastern Time
>> End of Review Period: October 14, 2020 at 11:00 Eastern Time
>>
>>
>>
>>
>> Please forward a written notice to exclude Essential Claims to the Forum
>> and Working Group Chair by email to dzach...@harica.gr and a copy to the
>> CA/B Forum public mailing list public@cabforum.org before the end of the
>> Review Period.
>>
>>
>> See current version of CA/Browser Forum Intellectual Property Rights
>> Policy for details.
>>
>>
>>
>> *(Optional form of Exclusion Notice is available at
>> https://cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf
>> )*
>>
>>
>>
>>
>> ___
>> Servercert-wg mailing list
>> servercert...@cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi via Public]

Dimitris: Could you explain why it's necessary to integrate?

It seems much better to have Ballot -> Distinct BR version, and there's
nothing in our IP policy I'm aware of that requires you to send them as a
combined review.

On Mon, Sep 14, 2020 at 4:38 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

>
> I just realized that ballot SC28 also contains changes to the BRs so I
> will create a combined IPR review for ballots SC35 and SC28 later today.
>
> Thank you,
> Dimitris.
>
>
> On 2020-09-14 11:02 π.μ., Dimitris Zacharopoulos (HARICA) wrote:
>
> *NOTICE OF REVIEW PERIOD*
>
>
>
> This Review Notice is sent pursuant to Section 4.1 of the CA/Browser
> Forum’s Intellectual Property Rights Policy (v1.3). This Review Period is
> for two Final Maintenance Guidelines (30 day Review Period). Attached are
> the complete Draft Guidelines subject of this Review Notice.
>
>
> Ballots for Review: Ballot SC35
> 
> Start of Review Period: September 14, 2020 at 11:00 Eastern Time
> End of Review Period: October 14, 2020 at 11:00 Eastern Time
>
>
>
>
> Please forward a written notice to exclude Essential Claims to the Forum
> and Working Group Chair by email to dzach...@harica.gr and a copy to the
> CA/B Forum public mailing list public@cabforum.org before the end of the
> Review Period.
>
>
> See current version of CA/Browser Forum Intellectual Property Rights
> Policy for details.
>
>
>
> *(Optional form of Exclusion Notice is available at
> https://cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf
> )*
>
>
>
>
> ___
> Servercert-wg mailing list
> servercert...@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Requirements language cleanup

[Ryan Sleevi via Public]

On Fri, Aug 7, 2020 at 3:05 PM Dean Coclin via Public 
wrote:

> As mentioned on today’s call, our team went through the CA/B Forum
> Baseline Requirements, EV Guidelines and Code Signing Guidelines to review
> for names which are being deprecated by the industry. The number found were
> very minor:
>
>
>
> In the EV Guidelines, the following text was found: “Denied Lists and
> Other Legal Black Lists” in Pg. iii Table of Contents 11.12.2 Black Lists;
> Pg. 30 11.12.2. Suggest changing to “Block Lists”.
>
>
>
> In the EV Code Signing Guidelines, the following text was found: “In
> addition to checking revocation status, where practical, platforms should
> consult blacklists of suspect software”. Suggest changing to “blocklist”.
> This can be taken up by the code signing WG.
>

I can add both of these to the cleanups & clarifications ballot, now that I
have endorsers, assuming they're OK with a last minute addition.


>
>
> In the TLS Baseline Requirements, there is reference to standard email
> addresses (page 19) used to contact parties for domain validation (i.e.
> webmaster, hostmaster, postmaster). However, I’m assuming these cannot be
> changed.
>

Yes, these are from RFC 2142


>
>
> I know there are some cleanup ballots either planned or underway and
> perhaps these can be included there.
>
>
>
> Dean Coclin
>
> DigiCert
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] VOTING BEGINS: Ballot Forum-14 version 2: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

On Mon, Jun 8, 2020 at 4:52 PM Tim Hollebeek via Public 
wrote:

> The following ballot is proposed by Tim Hollebeek of DigiCert and endorsed
> by Wayne Thayer of Mozilla and Clint Wilson of Apple.
>
>
>
> Ballot Forum-14: Creation of S/MIME Certificates Working Group
>
>
>
> Purpose of the Ballot
>
>
>
> The CA/Browser Forum underwent a two-year long governance reform exercise,
> modifying the Bylaws to allow the creation of working groups that covered
> topics other than server certificates.  While originally motivated by the
> inability to maintain requirements for code signing certificates, it was
> anticipated from the start that this would also provide an opportunity to
> create other working groups that could develop and maintain certificate
> profiles and requirements for other kinds of certificates.  While a number
> of regional and technical standards exist regarding the creation and
> issuance of S/MIME certificates, there is no current global forum for
> certificate authorities and those who consume or use S/MIME certificates to
> come together and develop and maintain policies and standards for those
> certificates.  This lack of standards has impeded the adoption and
> interoperability of S/MIME certificate worldwide.  This ballot would
> establish a working group chartered to develop and maintain such standards
> for S/MIME certificates, including but not limited to two important
> priorities: a uniform certificate profile for the issuance of
> publicly-trusted S/MIME certificates, and validation requirements for such
> certificates.
>
>
>
> -- MOTION BEGINS –
>
>
>
> Establish S/MIME Certificates Working Group
>
>
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.3 of
> the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to
> perform the activities as specified in the Charter, with the Charter as
> described here (
> https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...e6ad111f4477010cbff409cd939c5ac1c7c85ccc
> ).
>
>
>
>
>
> — MOTION ENDS—
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion (7+ days)
>
>
>
> Start Time: 2020-06-01 16:40:00 EDT
>
>
>
> End Time: after 2020-06-08 16:40:00 EDT
>
>
>
> Vote for approval (7 days)
>
>
>
> Start Time: 2020-06-08 16:50:00 EDT
>
>
>
> End Time: 2020-06-15 16:50:00 EDT
>

Google votes YES on FORUM 14 v2
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot Forum-14: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Note: This is missing the feedback from Apple, which landed in
https://github.com/cabforum/documents/pull/167/commits/e6ad111f4477010cbff409cd939c5ac1c7c85ccc

You could probably restart discussion with things as

https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...e6ad111f4477010cbff409cd939c5ac1c7c85ccc

and shifted to 15:30 EDT (or 16:00 EDT), depending on when you get this :)

On Mon, Jun 1, 2020 at 3:04 PM Tim Hollebeek via Public 
wrote:

> I believe the most recent attempt to post this was swallowed by CABForum
> mailer issues that were fixed today.  Reposting:
>
>
>
> The following ballot is proposed by Tim Hollebeek of DigiCert and endorsed
> by Wayne Thayer of Mozilla and Clint Wilson of Apple.
>
>
>
> Ballot Forum-14: Creation of S/MIME Certificates Working Group
>
>
>
> Purpose of the Ballot
>
>
>
> The CA/Browser Forum underwent a two-year long governance reform exercise,
> modifying the Bylaws to allow the creation of working groups that covered
> topics other than server certificates.  While originally motivated by the
> inability to maintain requirements for code signing certificates, it was
> anticipated from the start that this would also provide an opportunity to
> create other working groups that could develop and maintain certificate
> profiles and requirements for other kinds of certificates.  While a number
> of regional and technical standards exist regarding the creation and
> issuance of S/MIME certificates, there is no current global forum for
> certificate authorities and those who consume or use S/MIME certificates to
> come together and develop and maintain policies and standards for those
> certificates.  This lack of standards has impeded the adoption and
> interoperability of S/MIME certificate worldwide.  This ballot would
> establish a working group chartered to develop and maintain such standards
> for S/MIME certificates, including but not limited to two important
> priorities: a uniform certificate profile for the issuance of
> publicly-trusted S/MIME certificates, and validation requirements for such
> certificates.
>
>
>
> -- MOTION BEGINS –
>
>
>
> Establish S/MIME Certificates Working Group
>
>
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.3 of
> the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to
> perform the activities as specified in the Charter, with the Charter as
> described here (
> https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...c274e89f79442c12f3c75c778ae4eadaa6403dda
> ).
>
>
>
> — MOTION ENDS—
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion (7+ days)
>
>
>
> Start Time: 2020-06-01  15:00:00 EDT
>
>
>
> End Time: after 2020-06-08 15:00:00 EDT
>
>
>
> Vote for approval (7 days)
>
>
>
> Start Time: TBD
>
>
>
> End Time: TBD
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Oh, and the ballot number will need to be updated - I'm not sure how both
collided on 'FORUM-12' (Dimitris' Bylaws ballot and this)

On Wed, May 20, 2020 at 6:18 PM Ryan Sleevi  wrote:

>
>
> On Fri, May 15, 2020 at 2:20 PM Tim Hollebeek 
> wrote:
>
>> I’m willing to drop the scope statement based on Thursday’s discussion
>> and the addition of the paragraph I suggested to the introduction, which
>> describes much of the same thing in a form that seems more acceptable to
>> most.  Clint and Wayne, are you ok with that?
>>
>>
>>
>> On the subject of redlines, //github_redline_guide is not normative, so I
>> disagree that it is not a valid Ballot.  But that’s not really important,
>> because I’m more than happy to improve the ballot by fixing the link.
>>
>
> While I realize we end up frequently discussing this, I think you may have
> missed that this was a different scenario than you may have realized.
>
> If your ballot had included the full text, then I agree, the redline link
> was not normative. However, your ballot just pointed to a link, and so that
> made the link itself normative. The contents of the link were not actually
> a charter, they were just a few edits. That's why it wasn't really a
> "Ballot".
>
> This is easily fixed in the next run. You can paste the full text, as I
> think you're one of the folks who still prefers to do so, despite the
> risks, or you could provide the full link to all the edits, which will at
> least include a "full charter". Just a single commit on its own, or "as of
> this revision", can end up being ambiguous :) In the future, the
> infrastructure WG efforts will certainly make this easier, and it's not
> difficult to imagine an easy "create a ballot for me" that provides the
> PDF, docx, and patch file and stable link, so appreciate your patience :)
>
>
>> Assuming Clint and Wayne sign off, please merge the change, and I’ll
>> update the ballot.
>>
>
> One more set of issues, now that scope has been finalized, that came up on
> another review cycle:
> https://github.com/sleevi/cabforum-docs/pull/22/files
>
>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Ryan Sleevi 
>> *Sent:* Wednesday, May 13, 2020 5:44 PM
>> *To:* Tim Hollebeek ; CABforum1 <
>> public@cabforum.org>
>> *Subject:* Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME
>> Certificates Working Group
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 13, 2020 at 5:18 PM Tim Hollebeek via Public <
>> public@cabforum.org> wrote:
>>
>> Upon approval of the CAB Forum by ballot in accordance with section 5.3
>> of the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to
>> perform the activities as specified in the Charter, with the Charter as
>> described here (
>> https://github.com/cabforum/documents/pull/167/commits/2aa376c06b45146249d0cc6b8cc5d42d08ccb177
>> ).
>>
>>
>>
>> Just to be clear: This link doesn't match the link for a valid proposal,
>> so I don't think this is a valid Ballot yet.
>> https://wiki.cabforum.org/github_redline_guide is helpful, but any
>> suggestions for improvements are welcome.
>>
>>
>>
>> The immutable link is
>> https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...2aa376c06b45146249d0cc6b8cc5d42d08ccb177
>>
>>
>>
>> The pull request is still https://github.com/cabforum/documents/pull/167
>>
>>
>>
>> Again, our concern is that the statement that "non-publicly trusted
>> S/MIME certificates are out of scope" accomplishes nothing valuable, and
>> causes real harm. That is, either it fails to keep anything out of scope
>> due to its definition, OR limits the discussion to being impossible to
>> introduce any new requirements due to, by definition, anything not in the
>> existing documents is out of scope. Neither of these scenarios are good,
>> and the risk of harm outweighs any benefits. We remain committed to trying
>> to work with you and understand your goals, to find language that better
>> captures those goals without the problematic ambiguity and harm of what's
>> being proposed.
>>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

On Fri, May 15, 2020 at 2:20 PM Tim Hollebeek 
wrote:

> I’m willing to drop the scope statement based on Thursday’s discussion and
> the addition of the paragraph I suggested to the introduction, which
> describes much of the same thing in a form that seems more acceptable to
> most.  Clint and Wayne, are you ok with that?
>
>
>
> On the subject of redlines, //github_redline_guide is not normative, so I
> disagree that it is not a valid Ballot.  But that’s not really important,
> because I’m more than happy to improve the ballot by fixing the link.
>

While I realize we end up frequently discussing this, I think you may have
missed that this was a different scenario than you may have realized.

If your ballot had included the full text, then I agree, the redline link
was not normative. However, your ballot just pointed to a link, and so that
made the link itself normative. The contents of the link were not actually
a charter, they were just a few edits. That's why it wasn't really a
"Ballot".

This is easily fixed in the next run. You can paste the full text, as I
think you're one of the folks who still prefers to do so, despite the
risks, or you could provide the full link to all the edits, which will at
least include a "full charter". Just a single commit on its own, or "as of
this revision", can end up being ambiguous :) In the future, the
infrastructure WG efforts will certainly make this easier, and it's not
difficult to imagine an easy "create a ballot for me" that provides the
PDF, docx, and patch file and stable link, so appreciate your patience :)


> Assuming Clint and Wayne sign off, please merge the change, and I’ll
> update the ballot.
>

One more set of issues, now that scope has been finalized, that came up on
another review cycle: https://github.com/sleevi/cabforum-docs/pull/22/files


>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Wednesday, May 13, 2020 5:44 PM
> *To:* Tim Hollebeek ; CABforum1 <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME Certificates
> Working Group
>
>
>
>
>
>
>
> On Wed, May 13, 2020 at 5:18 PM Tim Hollebeek via Public <
> public@cabforum.org> wrote:
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.3 of
> the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to
> perform the activities as specified in the Charter, with the Charter as
> described here (
> https://github.com/cabforum/documents/pull/167/commits/2aa376c06b45146249d0cc6b8cc5d42d08ccb177
> ).
>
>
>
> Just to be clear: This link doesn't match the link for a valid proposal,
> so I don't think this is a valid Ballot yet.
> https://wiki.cabforum.org/github_redline_guide is helpful, but any
> suggestions for improvements are welcome.
>
>
>
> The immutable link is
> https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...2aa376c06b45146249d0cc6b8cc5d42d08ccb177
>
>
>
> The pull request is still https://github.com/cabforum/documents/pull/167
>
>
>
> Again, our concern is that the statement that "non-publicly trusted S/MIME
> certificates are out of scope" accomplishes nothing valuable, and causes
> real harm. That is, either it fails to keep anything out of scope due to
> its definition, OR limits the discussion to being impossible to introduce
> any new requirements due to, by definition, anything not in the existing
> documents is out of scope. Neither of these scenarios are good, and the
> risk of harm outweighs any benefits. We remain committed to trying to work
> with you and understand your goals, to find language that better captures
> those goals without the problematic ambiguity and harm of what's being
> proposed.
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

On Wed, May 13, 2020 at 5:18 PM Tim Hollebeek via Public <
public@cabforum.org> wrote:

> Upon approval of the CAB Forum by ballot in accordance with section 5.3 of
> the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to
> perform the activities as specified in the Charter, with the Charter as
> described here (
> https://github.com/cabforum/documents/pull/167/commits/2aa376c06b45146249d0cc6b8cc5d42d08ccb177
> ).
>

Just to be clear: This link doesn't match the link for a valid proposal, so
I don't think this is a valid Ballot yet.
https://wiki.cabforum.org/github_redline_guide is helpful, but any
suggestions for improvements are welcome.

The immutable link is
https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...2aa376c06b45146249d0cc6b8cc5d42d08ccb177

The pull request is still https://github.com/cabforum/documents/pull/167

Again, our concern is that the statement that "non-publicly trusted S/MIME
certificates are out of scope" accomplishes nothing valuable, and causes
real harm. That is, either it fails to keep anything out of scope due to
its definition, OR limits the discussion to being impossible to introduce
any new requirements due to, by definition, anything not in the existing
documents is out of scope. Neither of these scenarios are good, and the
risk of harm outweighs any benefits. We remain committed to trying to work
with you and understand your goals, to find language that better captures
those goals without the problematic ambiguity and harm of what's being
proposed.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Update about S/MIME Charter

[Ryan Sleevi via Public]

Thanks for checking, Tim. The changes y'all approved are integrated, and so
I think https://github.com/cabforum/documents/pull/167 reflects all
feedback to date.

On Fri, Apr 24, 2020 at 4:43 PM Tim Hollebeek 
wrote:

> Ryan: Any other issues, or shall we get a ballot out for discussion?
>
>
>
> (of course, discussion can continue during the ballot discussion period as
> well)
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Tim Hollebeek
> via Public
> *Sent:* Wednesday, April 22, 2020 4:24 PM
> *To:* Ryan Sleevi 
> *Cc:* CABforum1 
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> I’m fine with this.  Looks like Clint and Wayne are too (just repeating
> this here for those who don’t follow the link).
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Wednesday, April 22, 2020 3:42 PM
> *To:* Tim Hollebeek 
> *Cc:* CABforum1 
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> https://github.com/sleevi/cabforum-docs/pull/17 so that you can comment
> and make additional modifications/edits.
>
>
>
> In prepping this, I also spotted an issue with the CABF Bylaws that I'll
> feed back to Dimitris' ballot
>
>
>
> On Wed, Apr 22, 2020 at 3:27 PM Tim Hollebeek 
> wrote:
>
> I think some people might have objections to “includes, but not limited
> to…” language, but I don’t.  I think it’s sometimes helpful when drafting
> intentionally broad criteria like this to make it explicitly clear that
> common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the
> issuance of S/MIME certificates”.  That could really cut down on the amount
> of confusion about who does or does not qualify for membership, and give
> members clarity when voting for the charter about who is and isn’t allowed
> to participate, while also potentially allowing participation by others
> with less common audit schemes.
>
>
>
> That’s just a more verbose than usual way of me saying that yes, I would
> appreciate draft text along the lines you suggest.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Wednesday, April 22, 2020 3:15 PM
> *To:* Tim Hollebeek 
> *Cc:* CABforum1 
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> See my earliest comments on the first draft about this -
> https://cabforum.org/pipermail/public/2019-January/014517.html shows the
> suggested edit and points to
> https://cabforum.org/pipermail/public/2019-January/014521.html
>
>
>
> Finally, regarding membership criteria, I'm curious whether it's necessary
> to consider WebTrust for CAs / ETSI at all. For work like this, would it
> make sense to merely specify the requirements for a CA as one that is
> trusted for and actively issues S/MIME certificates that are accepted by a
> Certificate Consumer. This seems to be widely inclusive and can be iterated
> upon if/when improved criteria are developed, if appropriate.
> There's also a bootstrapping issue for membership, in that until we know
> who the accepted Certificate Consumers are, no CA can join as a Certificate
> Issuer. I'm curious whether it makes sense to explicitly bootstrap this in
> the charter or how we'd like to tackle this.
>
>
>
> In the current incarnation, it's to simply remove the scheme requirement,
> as follows:
>
>
>
> A Certificate Issuer eligible for voting membership in the SMCWG MUST have
> a publicly-available audit report or attestation statement in accordance
> with a publicly-available audit or assessment scheme relevant to the
> issuance of S/MIME certificates. This includes, but is not limited to, ...:
>
>
>
> Happy to propose draft text to this effect, if this is something that
> you're open to addressing.
>
>
>
> On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek 
> wrote:
>
> Unintentional, and thanks for calling it out.  I don’t have strong
> feelings on the issue and agree broader participation is a useful goal,
> especially before requirements exist.  Certificate Consumers can, and I
> expect will, have their own opinions on what audits are appropriate and
> necessary once they adopt the requirements.  Do you have a proposed fix?
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Sunday, April 19, 2020 4:41 PM
> *To:* Tim Hollebeek ; CABforum1 <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> Looking through the resolved and unresolved aspects, the lack of feedback
> from you meant we still have one unaddressed matter in the draft:
>
>
>
> https://github.com/cabforum/documents/pull/167/files#r392389077
>
> - The proposed draft charter forbids any CA from participating unless they
> already have particular audit schemes, despite this document not yet
> existing nor being incorporated into audit frameworks. This has been
> repeatedly raised as an issue for the past year, and it would be useful to
> know whether or not this is intentionally not being addressed. It does seem
> that there doesn't need to be restrictions on CA membership until such a
> document is produced (see also
> 

Re: [cabfpub] Update about S/MIME Charter

[Ryan Sleevi via Public]

https://github.com/sleevi/cabforum-docs/pull/17 so that you can comment and
make additional modifications/edits.

In prepping this, I also spotted an issue with the CABF Bylaws that I'll
feed back to Dimitris' ballot

On Wed, Apr 22, 2020 at 3:27 PM Tim Hollebeek 
wrote:

> I think some people might have objections to “includes, but not limited
> to…” language, but I don’t.  I think it’s sometimes helpful when drafting
> intentionally broad criteria like this to make it explicitly clear that
> common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the
> issuance of S/MIME certificates”.  That could really cut down on the amount
> of confusion about who does or does not qualify for membership, and give
> members clarity when voting for the charter about who is and isn’t allowed
> to participate, while also potentially allowing participation by others
> with less common audit schemes.
>
>
>
> That’s just a more verbose than usual way of me saying that yes, I would
> appreciate draft text along the lines you suggest.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Wednesday, April 22, 2020 3:15 PM
> *To:* Tim Hollebeek 
> *Cc:* CABforum1 
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> See my earliest comments on the first draft about this -
> https://cabforum.org/pipermail/public/2019-January/014517.html shows the
> suggested edit and points to
> https://cabforum.org/pipermail/public/2019-January/014521.html
>
>
>
> Finally, regarding membership criteria, I'm curious whether it's necessary
> to consider WebTrust for CAs / ETSI at all. For work like this, would it
> make sense to merely specify the requirements for a CA as one that is
> trusted for and actively issues S/MIME certificates that are accepted by a
> Certificate Consumer. This seems to be widely inclusive and can be iterated
> upon if/when improved criteria are developed, if appropriate.
> There's also a bootstrapping issue for membership, in that until we know
> who the accepted Certificate Consumers are, no CA can join as a Certificate
> Issuer. I'm curious whether it makes sense to explicitly bootstrap this in
> the charter or how we'd like to tackle this.
>
>
>
> In the current incarnation, it's to simply remove the scheme requirement,
> as follows:
>
>
>
> A Certificate Issuer eligible for voting membership in the SMCWG MUST have
> a publicly-available audit report or attestation statement in accordance
> with a publicly-available audit or assessment scheme relevant to the
> issuance of S/MIME certificates. This includes, but is not limited to, ...:
>
>
>
> Happy to propose draft text to this effect, if this is something that
> you're open to addressing.
>
>
>
> On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek 
> wrote:
>
> Unintentional, and thanks for calling it out.  I don’t have strong
> feelings on the issue and agree broader participation is a useful goal,
> especially before requirements exist.  Certificate Consumers can, and I
> expect will, have their own opinions on what audits are appropriate and
> necessary once they adopt the requirements.  Do you have a proposed fix?
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Sunday, April 19, 2020 4:41 PM
> *To:* Tim Hollebeek ; CABforum1 <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> Looking through the resolved and unresolved aspects, the lack of feedback
> from you meant we still have one unaddressed matter in the draft:
>
>
>
> https://github.com/cabforum/documents/pull/167/files#r392389077
>
> - The proposed draft charter forbids any CA from participating unless they
> already have particular audit schemes, despite this document not yet
> existing nor being incorporated into audit frameworks. This has been
> repeatedly raised as an issue for the past year, and it would be useful to
> know whether or not this is intentionally not being addressed. It does seem
> that there doesn't need to be restrictions on CA membership until such a
> document is produced (see also
> https://cabforum.org/pipermail/public/2020-March/014917.html )
>
>
>
>
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Update about S/MIME Charter

[Ryan Sleevi via Public]

See my earliest comments on the first draft about this -
https://cabforum.org/pipermail/public/2019-January/014517.html shows the
suggested edit and points to
https://cabforum.org/pipermail/public/2019-January/014521.html

Finally, regarding membership criteria, I'm curious whether it's necessary
> to consider WebTrust for CAs / ETSI at all. For work like this, would it
> make sense to merely specify the requirements for a CA as one that is
> trusted for and actively issues S/MIME certificates that are accepted by a
> Certificate Consumer. This seems to be widely inclusive and can be iterated
> upon if/when improved criteria are developed, if appropriate.
> There's also a bootstrapping issue for membership, in that until we know
> who the accepted Certificate Consumers are, no CA can join as a Certificate
> Issuer. I'm curious whether it makes sense to explicitly bootstrap this in
> the charter or how we'd like to tackle this.


In the current incarnation, it's to simply remove the scheme requirement,
as follows:

A Certificate Issuer eligible for voting membership in the SMCWG MUST have
a publicly-available audit report or attestation statement in accordance
with a publicly-available audit or assessment scheme relevant to the
issuance of S/MIME certificates. This includes, but is not limited to, ...:

Happy to propose draft text to this effect, if this is something that
you're open to addressing.

On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek 
wrote:

> Unintentional, and thanks for calling it out.  I don’t have strong
> feelings on the issue and agree broader participation is a useful goal,
> especially before requirements exist.  Certificate Consumers can, and I
> expect will, have their own opinions on what audits are appropriate and
> necessary once they adopt the requirements.  Do you have a proposed fix?
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Sunday, April 19, 2020 4:41 PM
> *To:* Tim Hollebeek ; CABforum1 <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] Update about S/MIME Charter
>
>
>
> Looking through the resolved and unresolved aspects, the lack of feedback
> from you meant we still have one unaddressed matter in the draft:
>
>
>
> https://github.com/cabforum/documents/pull/167/files#r392389077
>
> - The proposed draft charter forbids any CA from participating unless they
> already have particular audit schemes, despite this document not yet
> existing nor being incorporated into audit frameworks. This has been
> repeatedly raised as an issue for the past year, and it would be useful to
> know whether or not this is intentionally not being addressed. It does seem
> that there doesn't need to be restrictions on CA membership until such a
> document is produced (see also
> https://cabforum.org/pipermail/public/2020-March/014917.html )
>
>
>
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Update about S/MIME Charter

[Ryan Sleevi via Public]

Looking through the resolved and unresolved aspects, the lack of feedback
from you meant we still have one unaddressed matter in the draft:

https://github.com/cabforum/documents/pull/167/files#r392389077
- The proposed draft charter forbids any CA from participating unless they
already have particular audit schemes, despite this document not yet
existing nor being incorporated into audit frameworks. This has been
repeatedly raised as an issue for the past year, and it would be useful to
know whether or not this is intentionally not being addressed. It does seem
that there doesn't need to be restrictions on CA membership until such a
document is produced (see also
https://cabforum.org/pipermail/public/2020-March/014917.html )
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Update about S/MIME Charter

[Ryan Sleevi via Public]

On Fri, Apr 17, 2020 at 7:57 PM Tim Hollebeek via Public <
public@cabforum.org> wrote:

>
>
> As I mentioned on the last call, I promised to give an update on the
> S/MIME Charter today.  There was a previous draft incorporating Apple’s
> comments, but as that draft was being finalized, a number of useful
> improvements were contributed by Google.  After some discussion, most of
> those improvements were adopted, resulting in a proposal from Apple which
> can be found here:
>

Hi Tim,

The correct link is https://github.com/cabforum/documents/pull/167 . The
e-mails I sent (as well as the GitHub notifications) were trying to address
this by avoiding a bunch of fragmented URLs. Hopefully that makes it easier
to see the edits, as well as make sure that the comments are actually
addressed by allowing them to be resolved :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

This doesn't incorporate Pedro's feedback, but this hopefully accurately
reflects Clint's proposal, with all of the proposed additions/deletions
provided by Apple, incorporated:
https://github.com/sleevi/cabforum-docs/blob/2020-03-13-SMCWG_Charter/docs/SMCWG-charter.md

To facilitate discussion, I've opened it up as a PR -
https://github.com/cabforum/documents/pull/167

Under the files tab, this allows you to suggest in-place edits, and helps
track the evolution of the document

On Fri, Mar 13, 2020 at 12:35 PM Pedro FUENTES  wrote:

> Hello,
> I was about to send a new version of the doc with a couple of comments… I
> send it anyway, just in case.
>
> On my side, as main point I’m not in full agreement with the definition of
> the “Certificate Consumer” role.
>
> Considering the current formulation…
>
> *(2) A Certificate Consumer eligible for voting membership in the SMCWG
> must produce and maintain [1] a mail user agent (web-based or application
> based) or email service provider that processes S/MIME certificates[2] *
>
>
> I added this comment:
>
> This doesn’t seem fully clear. What are exactly the requirements for those
> that provide a mail user agent? Does “that processes S/MIME
> certificates” applies only to the email service provider or to both types
> of certificate consumers? What implies to “process S/MIME”… It should be
> maybe agreed that the certificate consumers must actively use S/MIME to
> sign/encrypt email, as a passive processing of the S/MIME parts not
> performing any action is not enough
>
>
> Best,
> Pedro
>
>
>
> On 13 Mar 2020, at 17:21, Ryan Sleevi via Public 
> wrote:
>
> Thanks Clint.
>
> We still have a number of concerns, many of which have been captured in
> the minutes and, in past meetings, received commitment from DigiCert that
> these would be addressed.
>
> To avoid circulating a bunch of Word docs around, it seems like a
> reasonable next step would the conversion to Markdown and having inline
> discussion.
>
> Thematically, these elements include:
> 1) If natural or legal identity is included in scope, it's clearly
> indicated that work on such efforts will not begin until the successful
> adoption of standard controls on domain / email validation. For example,
> this was discussed at Thessaloniki and proposed by DigiCert -
> https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/
>  as
> an alternative to the previous path that DigiCert had agreed to in
> Cupertino .
>   - The solution for this needs to be a clear articulation of the priority
> of activities, and a commitment in charter that the identity work does not
> begin unless and until a common baseline has been delivered for
> email/domain validation
> 2) The removal of the government equivalent audit was something discussed
> in Cupertino -
> https://cabforum.org/2019/05/03/minutes-for-ca-browser-forum-f2f-meeting-46-cupertino-12-14-march-2019/
>  -
> as being intentional to prevent unnecessary exclusion. For example, see the
> discussion regarding the US Federal PKI's approach
>   - It looks like there was some concern about why this bullet existed,
> and its removal might have just been due to lack of context with the past
> discussions
> 3) The transition from "updates" to "support" misses much of the intent
> with Ballot 205 -
> https://cabforum.org/2017/07/06/ballot-205-membership-related-clarifications/
>
>   - It introduces a new issue, regarding "end of life", which potentially
> allows one to declare an "end of life" in 2038, and then ceases all
> maintenance, while qualifying "support" as providing online documentation
>   - Given that this document strives to be a living document of best
> practices, the intent in Ballot 205 and with the original (now stricken)
> language was to ensure that participants were invested in the success of
> the ecosystem. I'm not sure this proposed change adequately encourages this?
>   - To be fair, this is somewhat mooted by the fact that if the Forum
> fails to be a useful venue for discussion, Root Programs can and will make
> and discuss changes through their existing Root Program policies, so it may
> be that this is perfectly fine, but just sets up that probability even
> greater
> 4) The use of "publicly trusted root" and "publicly trusted" certificate
> are ill-defined
>   - We know and have seen repeatedly the concerns and confusion this
> causes in the SCWG
>   - Any attempt to tie this back to Certificate Consumer is just going to
> create a circular dependency
>   - The SMCWG's scope is to create a common set of minimum guidelines
> which can be used by Certifi

Re: [cabfpub] Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Thanks Clint.

We still have a number of concerns, many of which have been captured in the
minutes and, in past meetings, received commitment from DigiCert that these
would be addressed.

To avoid circulating a bunch of Word docs around, it seems like a
reasonable next step would the conversion to Markdown and having inline
discussion.

Thematically, these elements include:
1) If natural or legal identity is included in scope, it's clearly
indicated that work on such efforts will not begin until the successful
adoption of standard controls on domain / email validation. For example,
this was discussed at Thessaloniki and proposed by DigiCert -
https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/
as
an alternative to the previous path that DigiCert had agreed to in
Cupertino .
  - The solution for this needs to be a clear articulation of the priority
of activities, and a commitment in charter that the identity work does not
begin unless and until a common baseline has been delivered for
email/domain validation
2) The removal of the government equivalent audit was something discussed
in Cupertino -
https://cabforum.org/2019/05/03/minutes-for-ca-browser-forum-f2f-meeting-46-cupertino-12-14-march-2019/
-
as being intentional to prevent unnecessary exclusion. For example, see the
discussion regarding the US Federal PKI's approach
  - It looks like there was some concern about why this bullet existed, and
its removal might have just been due to lack of context with the past
discussions
3) The transition from "updates" to "support" misses much of the intent
with Ballot 205 -
https://cabforum.org/2017/07/06/ballot-205-membership-related-clarifications/

  - It introduces a new issue, regarding "end of life", which potentially
allows one to declare an "end of life" in 2038, and then ceases all
maintenance, while qualifying "support" as providing online documentation
  - Given that this document strives to be a living document of best
practices, the intent in Ballot 205 and with the original (now stricken)
language was to ensure that participants were invested in the success of
the ecosystem. I'm not sure this proposed change adequately encourages this?
  - To be fair, this is somewhat mooted by the fact that if the Forum fails
to be a useful venue for discussion, Root Programs can and will make and
discuss changes through their existing Root Program policies, so it may be
that this is perfectly fine, but just sets up that probability even greater
4) The use of "publicly trusted root" and "publicly trusted" certificate
are ill-defined
  - We know and have seen repeatedly the concerns and confusion this causes
in the SCWG
  - Any attempt to tie this back to Certificate Consumer is just going to
create a circular dependency
  - The SMCWG's scope is to create a common set of minimum guidelines which
can be used by Certificate Consumers in evaluating Certificate Issuers,
such as by Certificate Issuers incorporating these guidelines into their
CP/CPS and through the use of audits which derive auditable criteria that
evaluate against such guidelines

These are just a small sampling of some of the issues we've discussed in
the past. I appreciate the energy towards getting this out, and I'm glad to
see that progress is being made in actually updating these to reflect
discussions, but despite the amount of time that's passed since we first
began discussing, there are still many core, systemic issues to work
through, and still ample feedback that has been provided in good faith that
has been committed to be integrated, but not yet integrated. I don't mean
that as a criticism for Apple's many welcome improvements, merely that we
should continue with this enthusiasm to update, while making sure we're not
overlooking things.


On Thu, Mar 12, 2020 at 11:07 AM Clint Wilson  wrote:

> Sure thing, here’s a Word formatted version :)
>
>
>
> On Mar 12, 2020, at 8:05 AM, Ryan Sleevi  wrote:
>
> Hey Clint,
>
> Is it possible to convert that file to a standard format? I'm having
> trouble opening it
>
> On Wed, Mar 11, 2020 at 10:30 PM Clint Wilson  wrote:
>
>> Hello all,
>>
>> I’ve attached below an updated draft charter which addresses the concerns
>> I raised previously, especially with regards to section 4.2.3. There are
>> additionally changes seeking to address Tim and Ryan’s comments/responses
>> below and a few minor updates that seemed warranted as I went through
>> another comprehensive review of the document. For each area changed, there
>> is a corresponding comment; if anything is unclear, please let me know and
>> I’d be happy to address.
>>
>> Thank you for your patience and understanding in getting this back to the
>> group. Have a great evening!
>> -Clint
>>
>>
>>

Re: [cabfpub] Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Hey Clint,

Is it possible to convert that file to a standard format? I'm having
trouble opening it

On Wed, Mar 11, 2020 at 10:30 PM Clint Wilson  wrote:

> Hello all,
>
> I’ve attached below an updated draft charter which addresses the concerns
> I raised previously, especially with regards to section 4.2.3. There are
> additionally changes seeking to address Tim and Ryan’s comments/responses
> below and a few minor updates that seemed warranted as I went through
> another comprehensive review of the document. For each area changed, there
> is a corresponding comment; if anything is unclear, please let me know and
> I’d be happy to address.
>
> Thank you for your patience and understanding in getting this back to the
> group. Have a great evening!
> -Clint
>
>
>
> On Feb 18, 2020, at 1:57 PM, Ryan Sleevi via Public 
> wrote:
>
>
>
> On Tue, Feb 18, 2020 at 1:57 PM Tim Hollebeek via Public <
> public@cabforum.org> wrote:
>
>>
>>- Automatic cessation of membership
>>
>>
>>- The balloted wording around software update cadences introduces
>>   some precision/definition issues that would likely prove troublesome 
>> in and
>>   of themselves.
>>   - While some of those issues could be addressed through
>>   wordsmithing, the entire precept that membership may be automatically
>>   removed based on various conditions (both for Certificate Consumers
>>   *and* Issuers) is itself problematic and I think an area rife for
>>   improvement (both here and in other charters).
>>
>> REJECT: The language is consistent with the language in the other working
>> group charters.  Introducing new inconsistencies in this charter would be
>> confusing for all involved.  If Apple believes these provisions are
>> problematic, potential improvements should be discussed an applied across
>> all chartered working groups.
>>
>
> I'm not quite sure I understand this rationale, could you explain more.
>
> Why does this charter need to follow the SCWG/CSWG charter? Who is "all
> involved" that would be confused?
>
> It seems very valuable to learn from mistakes and concerns and address
> them, but perhaps I'm overlooking something?
>
>
>>
>>- Invalid membership requirements/processes
>>
>>
>>- I think Ryan Sleevi has explained most of this better than I could,
>>   so I’ll refer to his message instead:
>>   https://cabforum.org/pipermail/public/2020-February/014874.html.
>>   - I looked, but failed to find information as to how mail transfer
>>   agents consume S/MIME certificates. However, since it’s included in the
>>   ballot I can only conclude that the proposer has relevant and detailed
>>   insight into how and why this is a valid categorization for Certificate
>>   Consumers and had hoped to be pointed to that information so as to 
>> better
>>   understand the scope of this proposed CWG.
>>
>> REJECT: This was discussed extensively during the governance reform
>> process, and the current procedures were deemed to be sufficient.  This
>> charter simply follows those precedents.  Indeed, two other chartered
>> working groups were successfully bootstrapped already.
>>
>
> I understand one group was the Code Signing Working Group, which perhaps
> did not have careful or close review from all Forum members due to the
> explicit lack of intent to participate in the venue or fundamental
> disagreements about the working group objectives.
>
> However, I'm not sure, what's the other Chartered Working Group you're
> thinking of? The SCWG explicitly did not follow this process, as part of
> the Legacy Working Group transition, and so I'm not sure what the other CWG
> is that avoided this?
>
> Also, while I agree that this was discussed extensively, I must
> respectfully disagree that the "current procedures were deemed to be
> sufficient". The current (proposed) procedures were known to be problematic
> in bootstrapping, something we discussed, and something we knew we could
> avoid by defining an open and welcoming charter. This WG does not seem to
> set out to do this.
>
> In all fairness, this seems a repeat of the same issues the bedeviled, and
> nearly derailed, the Forum in it's first start. The attempt to exclude some
> CAs, via narrowly and restrictively scoped membership, nearly resulted in
> the implosion of the Forum, as the management@ archives from 2009 show.
> Ultimately, it was the Forum's rejection of such exclusionary attempts that
> helped grow the membership.

Re: [cabfpub] Ballot Forum-XX: Update CA/B Forum Bylaws to version 2.3

[Ryan Sleevi via Public]

Hi Dimitris,

There's a lot of changes here, and this will take us quite a bit of time to
digest.

I don't know that we're necessarily supportive of the "Full Member"
definition, and the implications that has. The implicit consequences of
treating Interested Parties as Members of the Forum is not what was
intended with the current Bylaws, as I understand it, and so it has
ramifications throughout. That is, our definitions have historically been
"Member, Associate Member, Interested Party" - with zero overlap. This
seems to redefine things to be "Full Member, Associate Member, Interested
Party", with using "Member" as the aggregate term for all three, and it's
unclear why that was necessary.

However, the biggest concern remains with the approach to the Chair / Vice
Chair making changes to "Informative" sections. We're tremendously
appreciative of your efforts here in finding a solution, and we're trying
to work through how best to propose changes that capture the intent. We're
very appreciative of the explicit attempt to limit the scope in sucha
manner.

On Fri, Feb 28, 2020 at 6:15 AM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> wrote:

>
>
> I just received a comment that Section 2.3 point 7 also needs to precede
> all occurrences of "Member" with "Full", as Interested Parties are
> sometimes able to participate in Forum Teleconferences, etc, and so may
> affect the quorum without a corresponding ability to vote.
>
> So, I updated this paragraph to:
>
> "7.A ballot result will be considered valid only when more than half
> of the number of currently active Full Members has participated. The
> number of currently active Full Members is the average number of Full Member
> organizations that have participated in the previous three (3) Forum
> Meetings and Forum Teleconferences."
>
> There is no need to circulate a new version yet. I'll wait for more
> feedback.
>
>
> Thanks,
> Dimitris.
>
> On 2020-02-27 8:51 μ.μ., Dimitris Zacharopoulos (HARICA) via Public wrote:
>
> Following up from the latest F2F meeting, I have prepared a ballot for a
> Bylaws update.
>
> I am looking for two endorsers.
>
> Thanks,
> Dimitris.
>
>
> *Purpose of Ballot:* The Forum has identified and discussed a number of
> improvements to be made to the current version of the Bylaws to improve
> clarity and allow the Forum to function more effectively. Most of these
> changes are described in the “Issues with Bylaws to be addressed
> ”
> document.
>
> Here is a list of major changes:
>
>1. Clarification of the use of the term “Member” so it is clear when
>we discuss about all Forum Members (which includes Associate Members and
>Interested Parties), and when we discuss about the “Full Members”.
>2. Adding the term “Voting Representative” which is designated by each
>Member. Only votes submitted by Voting Representatives will be considered
>3. Replacing of the term “Forum wiki” with the properly defined term
>“Member Web Site”
>4. Removing references for Webmaster in the definition of “Public Web
>Site” since it is repeated in section 5.2
>5. New Photography Policy in Exhibit D
>6. Clarification of 4.1 (2) that Forum Members nominate representatives
>7. Allowing informative changes to Guidelines by the Chair or Vice
>Chair
>8. In 5.3.1 require that a Certificate Issuer is trusted in the
>“latest” software produced by a Certificate Consumer
>
> *— MOTION BEGINS –*
>
> *Amendment to the Bylaws:* Replace the entire text of the Bylaws of the
> CA/Browser Forum with the attached version (CA-Browser Forum Bylaws draft
> v2.3.pdf).
>
>
> *— MOTION ENDS –*
>
> A red-line is also attached (CA-Browser Forum Bylaws draft v2.3
> redline.pdf).
>
> The procedure for approval of this ballot is as follows:
>
> Formal discussion period:  (14+ days)
>
> Ballot Discussion Begins: March XX, 2020 19:00 UTC
>
> Ballot Discussion Ends: March XX, 2020 19:00 UTC
>
> Vote for approval (7 days)
>
> Ballot Vote Begins: TBD
>
> Ballot Vote Ends: TBD
>
> ___
> Public mailing 
> listPublic@cabforum.orghttps://cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

On Tue, Feb 18, 2020 at 1:57 PM Tim Hollebeek via Public <
public@cabforum.org> wrote:

>
>- Automatic cessation of membership
>
>
>- The balloted wording around software update cadences introduces some
>   precision/definition issues that would likely prove troublesome in and 
> of
>   themselves.
>   - While some of those issues could be addressed through
>   wordsmithing, the entire precept that membership may be automatically
>   removed based on various conditions (both for Certificate Consumers
>   *and* Issuers) is itself problematic and I think an area rife for
>   improvement (both here and in other charters).
>
> REJECT: The language is consistent with the language in the other working
> group charters.  Introducing new inconsistencies in this charter would be
> confusing for all involved.  If Apple believes these provisions are
> problematic, potential improvements should be discussed an applied across
> all chartered working groups.
>

I'm not quite sure I understand this rationale, could you explain more.

Why does this charter need to follow the SCWG/CSWG charter? Who is "all
involved" that would be confused?

It seems very valuable to learn from mistakes and concerns and address
them, but perhaps I'm overlooking something?


>
>- Invalid membership requirements/processes
>
>
>- I think Ryan Sleevi has explained most of this better than I could,
>   so I’ll refer to his message instead:
>   https://cabforum.org/pipermail/public/2020-February/014874.html.
>   - I looked, but failed to find information as to how mail transfer
>   agents consume S/MIME certificates. However, since it’s included in the
>   ballot I can only conclude that the proposer has relevant and detailed
>   insight into how and why this is a valid categorization for Certificate
>   Consumers and had hoped to be pointed to that information so as to 
> better
>   understand the scope of this proposed CWG.
>
> REJECT: This was discussed extensively during the governance reform
> process, and the current procedures were deemed to be sufficient.  This
> charter simply follows those precedents.  Indeed, two other chartered
> working groups were successfully bootstrapped already.
>

I understand one group was the Code Signing Working Group, which perhaps
did not have careful or close review from all Forum members due to the
explicit lack of intent to participate in the venue or fundamental
disagreements about the working group objectives.

However, I'm not sure, what's the other Chartered Working Group you're
thinking of? The SCWG explicitly did not follow this process, as part of
the Legacy Working Group transition, and so I'm not sure what the other CWG
is that avoided this?

Also, while I agree that this was discussed extensively, I must
respectfully disagree that the "current procedures were deemed to be
sufficient". The current (proposed) procedures were known to be problematic
in bootstrapping, something we discussed, and something we knew we could
avoid by defining an open and welcoming charter. This WG does not seem to
set out to do this.

In all fairness, this seems a repeat of the same issues the bedeviled, and
nearly derailed, the Forum in it's first start. The attempt to exclude some
CAs, via narrowly and restrictively scoped membership, nearly resulted in
the implosion of the Forum, as the management@ archives from 2009 show.
Ultimately, it was the Forum's rejection of such exclusionary attempts that
helped grow the membership. In particular, it was DigiCert who some were
trying to prevent from joining the Forum, so it would be unfortunate to
have DigiCert repeat that same process.

I'm hoping you're open to addressing these issues, but I don't think we can
support the charter without this issue being addressed.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

The intent, stated in London, Cupertino, and Shanghai, is that much like
other Subject information in leaf certificates does not have explicit
guidelines (other than the CA validates), that the same approach would be
valid for S/MIME

On Fri, Feb 7, 2020 at 2:46 AM Adriano Santoni via Public <
public@cabforum.org> wrote:

> I would still prefer identity information (natural person or legal entity,
> or both: natural person affiliated to a legal entity) to be expressly
> included in the WG scope since the beginning. Of course this makes the WG
> task (that of producing "S/MIME baseline requirements") harder and longer,
> but it would reflect current practice. On the other hand, its not clear to
> me what the implications would be if S/MIME baseline requirements were
> approved and published, should they not cover the inclusion of identity
> information in S/MIME certificates. Would that imply, once Root Programs
> adopted such S/MIME BRs, that those CAs issuing S/MIME certs with identity
> information in them are mis-issuing?
> Adriano
>
>
> Il 06/02/2020 19:31, Wayne Thayer via Public ha scritto:
>
> Thanks Dimitris.
>
> On Wed, Feb 5, 2020 at 11:09 PM Dimitris Zacharopoulos (HARICA) via Public
>  wrote:
>
>> Tim, Wayne, Adriano,
>>
>> Apple made a contribution and although HARICA disagrees with most of the
>> recommended changes I believe there should be some discussion around that.
>>
>
> Agree. It's not in anyone's interests, nor do I believe that the intent
> was to ignore input unrelated to the identity issue. We should discuss it
> now to allow members to decide for themselves if the suggestions are
> important enough to warrant voting against this ballot, or if the ballot is
> good enough to ratify as-is.
>
> Unfortunately, although I had started working on a response, I didn't have
>> time to complete it on time. I was hoping to see some comments/responses
>> from the proposer and endorsers before the voting period began.
>>
>> For what it's worth, here is a list of my comments (attached). My biggest
>> concern is the Certificate Consumer members that qualify based on "mail
>> transfer agent". I would certainly like some more information about that
>> before HARICA votes. Other than that, the charter looks good to me.
>>
>>
> The section in question is:
>
> (2) A Certificate Consumer eligible for voting membership in the SMCWG
> must produce a develop and maintain a mail user agent (web-based or
> application based), mail transfer agent, or email service provider that
> processes S/MIME certificates issued by third-party Certificate Issuers who
> meet criteria set by such Certificate Consumer.
> The inclusion of "mail transfer agents" as eligible participants doesn't
> appear harmful to me, but I also agree with Clint's comment that "The role
> of a mail transfer agent in consuming S/MIME certificates is unclear."
> Tim or Ben: this was part of the draft Ben proposed over a year ago. Do
> you have any information on why this was included?
>
>
>> Best regards,
>> Dimitris.
>>
>>
>>
>> On 2020-02-06 12:45 π.μ., Wayne Thayer via Public wrote:
>>
>> Based on my recollection of the Guangzhou discussion, and supported by
>> the minutes, the "path forward agreed to in Guangzhou" was that we would
>> take this charter to a ballot without further attempts to resolve the issue
>> of including identity in the charter's scope. There does not appear to be a
>> path to consensus on this issue, despite the considerable amount of time
>> spent discussing it. I'm unhappy with this approach, but as one of the
>> endorsers, I don't see an alternative other than "take it to a vote" that
>> gets this much-needed WG formed any time soon.
>>
>> - Wayne
>>
>> On Wed, Feb 5, 2020 at 3:22 PM Ryan Sleevi via Public <
>> public@cabforum.org> wrote:
>>
>>> Hi Tim,
>>>
>>> Could you point to where that's reflected in the minutes? Our
>>> understanding here at Google is that Apple's proposed changes, which we
>>> support and would be unable to participate without incorporating, is that
>>> it accurately and correctly reflects the discussions in London [1],
>>> reiterated in Cupertino [2], and agreed upon in Thessaloniki [3]. It
>>> appears that, following that, the proposers of that ballot ignored that
>>> consensus and conclusion, and yet the discussion of Guangzhou [4] does not
>>> indicate there was consensus to do so.
>>>
>>> I'm hoping we've just overlooked something in the minutes, but Apple's
>>> proposed 

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

On Thu, Feb 6, 2020 at 2:37 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
> This was not raised as an issue when the code signing WG was created.
>

That doesn't mean it's not an issue? It just means y'all may not have had
folks review it closely?


> During the kick-off meeting, there was a Certificate Consumer present and
> Certificate Issuers that were trusted by this Certificate Consumer. So the
> WG was forged at that meeting without problems or concerns raised. I can
> only assume we will do the same thing at the kick-off meeting of the SMCWG.
>

That's problematic, yes.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

On Thu, Feb 6, 2020 at 2:05 PM Wayne Thayer  wrote:

> Ryan - Thank you for pointing out the past discussions. it's unfortunate
> that this ballot has lingered for so long and as a result it's possible
> that some of your feedback from a year ago was (unintentionally, I believe)
> "ignored". In reviewing [12], I observe the following:
>  * As noted, most, but not all of your comments relate to identity, an
> issue that is intended to be decided via ballot.
>  * You state "I'll also duplicate them as suggested edits on the doc after
> sending this, to provide more concrete and hopefully productive guidance."
> Did you share a redline with suggested changes?
>

I did, and they're available in the links provided.


>  * Your comment "Finally, regarding membership criteria, I'm curious
> whether it's necessary to consider WebTrust for CAs / ETSI at all." was
> discussed in the thread without reaching agreement.
>

And suggested edits were given to Ben twice on how to address that.

This is actually rather significant, because it's artificially
exclusionary, and does not match how we've bootstrapped other efforts, such
as the Forum itself.


>  * Regarding membership, you also commented "There's also a bootstrapping
> issue for membership, in that until we know who the accepted Certificate
> Consumers are, no CA can join as a Certificate Issuer. I'm curious whether
> it makes sense to explicitly bootstrap this in the charter or how we'd like
> to tackle this." I agree with this concern but is it something that can be
> easily worked around by having Certificate Consumers such as Microsoft and
> Mozilla become the first members of the WG?
>

Define "easily"? The membership definition is circular and intended to
protect CAs' interests, and that's a real problem. A Certificate Consumer
is one who accepts Certificate Issuers in the WG, meaning that if a given
Consumer moves to distrust a given issuer, such action may result in their
removal from the SMCWG, which would happen automatically, while for CAs,
they would merely be suspended.

Beyond that, as suggested, Microsoft and Mozilla cannot qualify as
Certificate Consumers without Certificate Issuers, and CAs cannot qualify
as Certificate Issuers without the existence of Certificate Consumers.
There's no way, valid to the Bylaws, for members to declare their interest,
because they can't meet the qualification, so it's incorrect to suggest
that this is a first-mover problem. This is a bootstrap problem, similar to
the audit, that was flagged in the past.

Of course, the definition of Certificate Issuer also seeks to exclude those
it claims to consider, by imposing a set of audit criteria that's more
restrictive than the proposed scope of the charter. That is, existing
issuers may be considered, but may not participate, if they haven't adopted
one of the specific audit schemes.

These are just the *existing* issues that were discussed. As mentioned,
there was significantly more feedback around other areas of structure and
approach, but we didn't submit those in the hope of a good-faith engagement
with Apple's suggestions. For example, the draft charter introduces a
normative dependency on the Baseline Requirements through its definition of
Qualified Auditor, which is necessary for membership, which means that
participation in the SMCWG is entirely dependent on participation in the
SCWG, such that actions in the SCWG can cause members to be excluded from
the SMCWG.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Just to make sure the timing is accurate:

2018-05 - Tim Hollebeek circulates a draft charter, largely modeled after
the code signing charter [1].
2018-06 - F2F 44 provides significant discussion on this issue and the
potential concerns. [2]
2018-07 - Ballot 208 [3] is finalized, which sets forth the requirements
for creating new CWG charters.
2018-10 - F2F 45 reiterates the concerns previously raised [4], with the
conclusion being


>- Ben – It sounds like the initial charter should focus on three
>aspects: profile, identity validation of email and identity (host and local
>part), and private key protection.
>- Kirk Hall, Entrust – Is that enough to start drafting a charter?
>- Ben – Yes, I can start a charter based on those three principles.
>
> 2019-01 - Ben Wilson circulates an updated draft for feedback [5]. This
draft is substantially more expansive, due to the changes in Ballot 206.
2019-03 - F2F 46 is held in Cupertino. While the minutes show [6] there is
still scope issue, a clear and viable path forward, previously raised, is
reiterated.

Dean – We have a blank slate here and it seems the reluctance was to make
> it a narrow scope and then focus on either one aspect of SMIME. First task
> might be how to validate an email, and then focus on identity validation.
> Some comments were to make the chart narrow to focus on one task while
> others say to include all proposed tasks to not have to recharter which has
> caused issues in the past.
>

2019-06 - F2F 47 is held in Thessaloniki [7], where again we discuss the
same topic.
2019-12 - Tim circulates the first draft version [8], the week before
Christmas. This is the first version that has been circulated since Ben
Wilson's 2019-01 version. Feedback is provided by Wayne [9] to be addressed.
2019-01 - Tim starts the discussion period for this ballot [10]

I highlight this timeline, because it does seem somewhat concerning that
after significant good faith effort to discuss the issues, these are
seemingly intentionally ignored in forcing a vote that intentionally
ignores feedback during the discussion period [11]. For example, [10]
represents the first time of seeing any draft on how the concerns were
raised. Given the significant beneficial edits proposed by Apple, for
example, Google did not submit its many procedural and practical concerns
with the draft language, on the hope that there would be a good faith
effort to engage with and discuss these issues.

It's equally concerning that the effort and time spent in communicating on
the previous draft, in [5], was entirely ignored in [8], which entirely
precipitated the issues in [9]. Substantive issues, such as those raised in
[12], were entirely ignored, and are largely orthogonal to the debate about
identity but to the very core of the charter.

I can understand that, if the view is we are at an impasse, then rough
consensus is a path forward. However, it remains deeply disappointing that
it seems that virtually all feedback, from a variety of participants, has
been ignored, as shown through the minutes and the past proposed changes.
That does not seem to be in the spirit of what you've suggested the intent
is.

[1] https://cabforum.org/pipermail/public/2018-May/013400.html
[2]
https://cabforum.org/2018/06/06/minutes-for-ca-browser-forum-f2f-meeting-44-london-6-7-june-2018/
[3]
https://cabforum.org/2018/04/03/ballot-206-amendment-to-ipr-policy-bylaws-re-working-group-formation/

[4]
https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/#6-Creation-of-additional-Working-Groups---Secure-Mail-Other
[5] https://cabforum.org/pipermail/public/2019-January/014517.html
[6]
https://cabforum.org/2019/05/03/minutes-for-ca-browser-forum-f2f-meeting-46-cupertino-12-14-march-2019/#Creation-of-additional-Working-Groups---Secure-Mail
[7]
https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/#Creation-of-Additional-Groups---Secure-Mail
[8] https://cabforum.org/pipermail/public/2019-December/014838.html
[9] https://cabforum.org/pipermail/public/2019-December/014839.html
[10] https://cabforum.org/pipermail/public/2020-January/014852.html
[11] https://cabforum.org/pipermail/public/2020-February/014865.html
[12] https://cabforum.org/pipermail/public/2019-January/014521.html

On Wed, Feb 5, 2020 at 5:45 PM Wayne Thayer  wrote:

> Based on my recollection of the Guangzhou discussion, and supported by the
> minutes, the "path forward agreed to in Guangzhou" was that we would take
> this charter to a ballot without further attempts to resolve the issue of
> including identity in the charter's scope. There does not appear to be a
> path to consensus on this issue, despite the considerable amount of time
> spent discussing it. I'm unhappy with this approach, but as one of the
> endorsers, I don't see an alternative other than "take it to a vote" that
> gets this much-needed WG formed any time soon.
>

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Hi Tim,

Could you point to where that's reflected in the minutes? Our understanding
here at Google is that Apple's proposed changes, which we support and would
be unable to participate without incorporating, is that it accurately and
correctly reflects the discussions in London [1], reiterated in Cupertino
[2], and agreed upon in Thessaloniki [3]. It appears that, following that,
the proposers of that ballot ignored that consensus and conclusion, and yet
the discussion of Guangzhou [4] does not indicate there was consensus to do
so.

I'm hoping we've just overlooked something in the minutes, but Apple's
proposed changes seem imminently reasonable, and a worthwhile path to
drafting requirements that consuming software, such as mail clients (both
native and Web), can use and consume as part of their root programs, as an
alternative to their root-program-specific requirements.

[1]
https://cabforum.org/2018/06/06/minutes-for-ca-browser-forum-f2f-meeting-44-london-6-7-june-2018/#New-SMIME-Working-Group-Charter
[2]
https://cabforum.org/2019/05/03/minutes-for-ca-browser-forum-f2f-meeting-46-cupertino-12-14-march-2019/#Creation-of-additional-Working-Groups---Secure-Mail
"Dean – We have a blank slate here and it seems the reluctance was to make
it a narrow scope and then focus on either one aspect of SMIME. First task
might be how to validate an email, and then focus on identity validation.
Some comments were to make the chart narrow to focus on one task while
others say to include all proposed tasks to not have to recharter which has
caused issues in the past."
[3]
https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/#Creation-of-Additional-Groups---Secure-Mail
"Eventually, all parties in the conversation came to the conclusion that it
would behoove the Forum to scope the working group charter to domain
validation, first, before adding other functionality once that portion was
locked-down."
[4]
https://cabforum.org/2019/12/12/minutes-for-ca-browser-forum-f2f-meeting-48-guangzhou-5-7-november-2019/#Creation-of-Additional-Groups---Secure-Mail
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot Forum-11: Creation of S/MIME Certificates Working Group

[Ryan Sleevi via Public]

Hi Tim,

Is there a reason this doesn't follow the template in Exhibit C of our
Bylaws? The differences seem rather significant.

On Fri, Jan 24, 2020 at 2:39 PM Tim Hollebeek via Public <
public@cabforum.org> wrote:

>
>
> The following ballot is proposed by Tim Hollebeek of DigiCert and endorsed
> by Wayne Thayer of Mozilla and Adriano Santoni of Actalis.
>
>
>
> Ballot Forum-11: Creation of S/MIME Certificates Working Group
>
>
>
> Purpose of the Ballot
>
>
>
> The CA/Browser Forum recently underwent a two-year long governance reform
> exercise, modifying the Bylaws to allow the creation of working groups that
> covered topics other than server certificates.  While originally motivated
> by the inability to maintain requirements for code signing certificates, it
> was anticipated from the start that this would also provide an opportunity
> to create other working groups that could develop and maintain certificate
> profiles and requirements for other kinds of certificates.  While a number
> of regional and technical standards exist regarding the creation and
> issuance of S/MIME certificates, there is no current global forum for
> certificate authorities and those who consume or use S/MIME certificates to
> come together and develop and maintain policies and standards for those
> certificates.  This lack of standards has impeded the adoption and
> interoperability of S/MIME certificate worldwide.  This ballot would
> establish a working group chartered to develop and maintain such standards
> for S/MIME certificates, including but not limited to two important
> priorities: a uniform certificate profile for the issuance of
> publicly-trusted S/MIME certificates, and validation requirements for such
> certificates.
>
>
>
> -- MOTION BEGINS –
>
>
>
> Establish S/MIME Certificates Working Group
>
>
>
> Upon approval of the CAB Forum by ballot in accordance with section 5.3 of
> the Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to
> perform the activities as specified in the attached Charter.
>
>
>
> — MOTION ENDS—
>
>
>
> The procedure for approval of this ballot is as follows:
>
>
>
> Discussion (7+ days)
>
>
>
> Start Time: 2020-01-24  14:40:00 EDT
>
>
>
> End Time: after 2020-01-31 14:40:00 EDT
>
>
>
> Vote for approval (7 days)
>
>
>
> Start Time: TBD
>
>
>
> End Time: TBD
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Notice of Review Period – Ballots SC23 and SC24

[Ryan Sleevi via Public]

Capturing notes that were shared off-list by various folks, and reposting
for visibility. Thanks for doing this, Dimitris, as this definitely
highlights the ease to be had of having GitHub, PRs, and automagically
generated PDFs :)

*Requiring Correction*:
Section 1.6.1: This fails to remove the definition for "Effective Date" (as
shown in https://github.com/cabforum/documents/pull/145/files , based on
what the Ballot was)
Section 3.2.2.7: This appears to renumber the entries, leading #4 to have
two entries and #5 to have no entry. This was not touched by either ballot,
AFAICT. This may be a PDF diff bug?
Section 3.2.2.8: The first paragraph, regarding Effective Date, was not
removed.
Section 4.1.2 was not updated to refer to Section 4.2.1, and continues to
incorrectly refer to Section 3.3.1; this was captured in
https://github.com/cabforum/documents/pull/145/files
Section 6.1.5.1 appears to place an asterisk (for the footnote) as a footer
for 6.1.5, rather than indented to 6.1.5.1
  - Same for 6.1.5.2 and 6.1.5.3

*Uncertain*:
The diff for 7.1.4+ appears to be mangled. Currently, version 1.6.6 shows
that "Name Forms" is in Section 7.1.4, which is the same as the Markdown.
The diff appears to show it was 7.1.5, and is now being corrected to 7.1.4
- but that's not correct.

*Not Requiring Correction in the PDF, but otherwise noted:*
Section 7.1.4.1 is listed in the PDF as "Issuer Information", matching the
1.6.6 PDF, while in the Markdown, it's listed as "Issuing CA Certificate
Subject". As best I can tell, this was a typo introduce in the Markdown 4
years ago, in
https://github.com/cabforum/documents/commit/661505addb9c5a0e9f35bcbc98f0629e26c3842d#diff-84a0a987677aabc0ae38abb27f95fb6d
,
related to Ballot 146 -
https://cabforum.org/2015/04/16/ballot-146-convert-baseline-requirements-to-rfc-3647-framework/
 .
  - Note: The above appears to only be an issue with the GitHub/Markdown,
and not with the PDF or what was balloted in this or previous ballots
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [FEEDBACK NEEDED] Pull Request: Pandoc-Friendly Formatting

[Ryan Sleevi via Public]

Hi Jos!

I know things have been quiet here, but I commented a little on the
conversion of the BRs.

I know this was sent to Public, but was it meant to go to servercert-wg@,
since it's for the Server Cert WG? I don't see any of the other documents
being touched/changed.

On Thu, Oct 3, 2019 at 11:42 AM Jos Purvis (jopurvis) via Public <
public@cabforum.org> wrote:

> All,
>
>
>
> I’ve created a pull request containing the formatting changes necessary to
> permit using pandoc to automatically convert the BRs from Markdown to PDF,
> HTML, and Word/DOCX. I *think* the changes are whitespace and markup
> modifications that do not change the content or meaning of the BRs, but
> since it’s a significant number of changes, I’m happy to bring it to ballot
> (or incorporate it into the next ‘Cleanup Ballot’) if people would prefer.
>
>
>
> The link to the pull request is below; I’d welcome feedback on whether and
> how people would like this brought to ballot.
>
>
>
> https://github.com/cabforum/documents/pull/142
>
>
>
> Cheers,
>
>
>
> Jos
>
>
>
> --
> Jos Purvis (jopur...@cisco.com)
> .:|:.:|:. cisco systems  | Cryptographic Services
> PGP: 0xFD802FEE07D19105  | +1 919.991.9114 <(919)%20991-9114> (desk)
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] The purpose of the CA/B Forum

[Ryan Sleevi via Public]

On Tue, Oct 22, 2019 at 2:17 PM Robin Alden  wrote:

> Ryan,
>
> Referring back to Dimitris’s reference [1], i.e. your response to Stephan
> Wolf, I think he (Stephan Wolf) probably overstated the forum’s purpose
> somewhat, but your response goes too far in the opposite direction to be
> considered accurate
>
>
>
> Stephan Wolf said:
>
> > > My understanding of the formation of the Forum was always about
> adopting
>
> > > “best practices” by strong consensus of the CA and browser community,
>
> > > acting cooperatively and by consensus.
>
>
>
> Ryan Sleevi said:
>
> > "The Forum provides a venue to ensure Browsers do not place conflicting
> requirements on CAs that voluntarily participate within the browsers root
> programs, by facilitating discussion and feedback.
>
> > 
>
> > That is the sole and only purpose of the Forum. Any other suggestion is
> ahistorical and not reflected in the past or present activities."
>
> I think Stephan’s statement could have said ‘developing’ instead of
> ‘adopting’, ‘better practices’ instead of ‘best practices’, and he would
> have been pretty close to the mark.
>
>
>
> I had to look up ‘ahistoric’ in a dictionary, since it is not a word in my
> vocabulary, and one of the two definitions Merriam-Webster says it is
> “historically inaccurate or ignorant”.
>
>
>
> I accept that it could be the view of a representative from a browser that
> the only point of the forum is as “a venue to ensure Browsers do not
> place conflicting requirements on CAs”.
>
> However, if the other members of the forum are of the opinion that there
> is value in the activity of developing, not just receiving, even minimum
> requirements that may be used to raise the bar in the Web PKI, and
> especially if there are other parties within or without the forum that
> consider those minimum requirements as being worthy of adoption or
> formalization within their use of PKI, for the web or elsewhere, then that
> gives the forum purpose beyond the resolution of conflicting requirements
> and therefore your view of the forum is not accurate from the wider
> perspective.
>

I think we're in quite a bit more agreement than disagreement.

That is, the value of the Baseline Requirements is the same as any SDO work
product - it's only useful if it's adopted and used. The existence of
standards for standards sake is not useful, nor are standards themselves
imbued with some special power that make them worthwhile independently
(i.e. with no implementations).

This is why, for example, SDOs like the IETF say "Rough consensus and
running code" - equal in measure. Or, for that matter, the WHATWG take a
more direct approach - many of the documents (e.g. the URL standard, the
Fetch standard, CSS, or even HTML) are "Living Standards", in that they
reflect "What implementations do", not necessarily "What they ought to do"
(this was a somewhat significant divergence from the prescriptive model of
the W3C).

So now let's circle back:
1) Why is the CA/B Forum relevant?
  - The CA/B Forum is relevant because it develops documents like the
Baseline Requirements
2) Why are the Baseline Requirements relevant?
  - The Baseline Requirements are relevant because they are useful to
inform audit criteria like WebTrust for CAs or ETSI EN 319 411-2
3) Why are audit criteria like those relevant?
  - Those audit criteria are relevant because they're used by Browser Root
Programs
4) Why do Browser/Root Programs use those Audit Criteria?
  - They use them because it's a convenient short-hand for a common base
set of requirements that can be independently assessed and that are
nominally aligned with the critical aspects of their Browser/Root Program
Requirements
5) Why do Browser/Root Programs define requirements?
  - Because the use of certificates, particularly from third-party CAs, is
inherently a product security decision, and tied closely with the
reputation, needs, and desires of that Browser/Root Program and their
product(s).

The 'value' of the Baseline Requirements, as they stand today, flows down
from their use and adoption by Browser/Root Programs. And Browser/Root
Programs adopt them not because there is an intrinsic or inherent value to
them, but because they are useful if, and only if, they're aligned with the
Browser/Root Programs inherent requirements. If the Baseline Requirements
are not aligned with industry needs (read: Browser/Root Programs), then
Browser/Root Programs won't and shouldn't continue to use them, nor audit
criteria that are based on them. And if Browser/Root Programs don't use
these requirements, then there's limited value in them, and in the Forum
itself as the developer of them.

Browser/Root Programs don't use the Baseline Requirements inherently - they
use their Root Program Requirements, and accept the BRs only to the extent
they are aligned with those Root Program requirements.

For example, Browsers could fully decide that the WebTrust and the ETSI
approach to auditing don't actually meet the 

Re: [cabfpub] The purpose of the CA/B Forum

[Ryan Sleevi via Public]

On Mon, Oct 21, 2019 at 1:48 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> I see a conflict because the statement considers a different purpose than
> what is described in section 1.1 of the Bylaws. I was also surprised
> ("shocked" might better describe it) to read that any other purposes are
> "ahistorical", and see this statement being directed to a new Interested
> Party who just recently joined the Server Certificate Working Group.
>

Again, I want to emphasize, you're conflating an informative statement of
fact - what the Forum has done in the past - with a statement of purpose,
what the Forum does or will do. I can understand that this confusion
exists, but it's not a conflict. It's further ahistorical is that while the
Forum may have done X in the past, it no longer does those things in the
section you cited! You'll recall that the Processing of EV SSL Certificates
was not adopted as a continued Forum work item, precisely because it was
seen as inappropriate for the Forum.


> I agree with all three. I have also been pointing out these three elements
> in every presentation related to the Forum :-) However, the fact that the
> Forum:
>
>- is voluntary
>- does not define "Root Program Policy" and
>- does not "enforce" nor "supervise" the CAs,
>
> are not related to the purpose of the Forum. You can say the same thing
> about IETF or other STOs. The CA/B Forum is a consensus driven STO that
> produces guidelines. How these guidelines are used is a different topic. We
> know for a fact that they are used as input for two International
> Standards, ETSI and WebTrust. Who knows how many other government or
> private sector areas are using the CA/B Forum's work product to define
> their policies.
>

Did you mean Standards Defining Organization (SDO)? It's unclear what you
mean by STO.

You're correct that we could certainly look to make the CA/Browser Forum as
ineffective as, say, the CA Security Council, and just as captured.
However, it would simply mean that the CA/Browser Forum requirements no
longer reflect or align with Root Program requirements, Root Programs would
abandon the WebTrust and ETSI documents (as has been discussed in the past
and is a /very real/ possibility), and develop their own auditing
standards, to directly oversee. This is important to understand that the
only value - and legitimacy - that the Forum has is not in producing the
Guidelines, but in providing a venue for discussion. The Guidelines utility
is certainly in providing input to audit criteria that can be developed,
but it's important to recognize that the only utility in the development in
that audit criteria is when they're accepted - i.e. by browsers.

Many other organizations /reject/ the CA/B Forum's work precisely because
it's not aligned with their security or disclosure requirements. For good
reason - the BRs are incomplete!


> I will let others state their opinion and comment about this. I, for one,
> disagree.
>
> Although the CA/B Forum takes input from its Members (Issuers and
> Consumers), it has a consensus-driven process. This means that if a CA or a
> Browser proposes an unreasonable or insecure change to the Forum's
> Guidelines, it will need 2/3 of CAs and majority of Browsers to enter the
> Guidelines.
>
> If a new Certificate Consumer with completely ridiculous "My Program
> Requirements" joins the Forum, the Forum is not forced by anyone to adopt
> changes that would jeopardize the quality of the Guidelines.
>
> I understand where you're coming from and respect the fact that you are
> trying to make Root Programs align, but the way you frame it, doesn't align
> with the Forum's purpose nor its processes. For better or worse, each
> recommendation will have to go through the ballot process and get consensus
> to be voted. No Certificate Consumer can enforce changes to the Guidelines,
> at least with the current Bylaws.
>

I think we're in more agreement than you realize. It's certainly true that
the Forum adoption to the Baseline Requirements is a consensus-driven
process. However, to the extent those documents diverge from real use, they
simply cease to be valuable as input - for the audit criteria or for the
Root Program.

And I think that's an essential point that your message both fails to
capture and arguably denies - it suggests the Forum has value outside of
the Root Programs that consume its inputs. If it no longer has value, Root
Programs won't consume it. If Ballots are rejected, Root Programs can and
should go above it.

The BRs, as they stand, have no value outside of Root Programs' requiring
them (or more aptly, accepting the audits derived from them).
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] The purpose of the CA/B Forum

[Ryan Sleevi via Public]

On Mon, Oct 21, 2019 at 1:09 PM Kirk Hall via Public 
wrote:

> +1 Dimitris.  As the immediate past Chair of the Forum and someone
> involved in creating the Forum in 2005, your analysis below is correct.
>

As I mentioned, this is somewhat ahistorical. For example, this viewpoint
you're sharing now does not seem consistent with your message in December
2005, proposing DigiCert (and all Sub-CAs) be excluded from participating
in the Forum, and a discussion about the purpose of the Forum being about
direct relationships with browsers.

You can see this at
https://cabforum.org/mailman/private/management/2005-December/07.html ,
in the event you don't recall that discussion.

It sparked a lot of lively discussion, such as the antitrust implications
for the Forum (
https://cabforum.org/mailman/private/management/2006-March/54.html )
and lengthy discussion about the membership criteria (
https://cabforum.org/mailman/private/management/2006-March/40.html ).
The minutes for that London meeting (
https://cabforum.org/mailman/private/management/2006-March/78.html )
have further discussion about the participation model, as captured in
https://cabforum.org/mailman/private/management/2006-April/82.html
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] The purpose of the CA/B Forum

[Ryan Sleevi via Public]

On Mon, Oct 21, 2019 at 11:54 AM Dimitris Zacharopoulos via Public <
public@cabforum.org> wrote:

>
> Dear CA/B Forum Members,
>
> Recent posts [1], [2] were brought to my attention with a statement from a
> representative of a Certificate Consumer Member who believes that the role
> of the Forum is the following:
>
> "The Forum provides a venue to ensure Browsers do not place conflicting
> requirements on CAs that voluntarily participate within the browsers root
> programs, by facilitating discussion and feedback. This allows
> interoperability among the Web PKI space, which refers to the set of CAs
> within browsers, and thus allows easier interoperability within browsers.
> Prior to the Forum, it was much easier to see this reflected in the private
> arrangements between CAs and browsers. If different browsers had different
> requirements, CAs would have to act as the intermediary to identify and
> communicate those conflicts. Similarly, browsers had to spend significant
> effort working to communicate with all of the CAs in their programs, often
> repeatedly answering similar questions. By arranging a common mailing list,
> and periodic meetings, those barriers to communication can be reduced.
>
>
> That is the sole and only purpose of the Forum. Any other suggestion is
> ahistorical and not reflected in the past or present activities."
> 
> It is fortunate that we are given the opportunity to take a step back and
> re-check why we are all here. I can only quote from the Bylaws (emphasis
> mine):
>
> "1.1 Purpose of the Forum
>
> The Certification Authority Browser Forum (CA/Browser Forum) is a
> voluntary gathering of leading Certificate Issuers and vendors of Internet
> browser software and other applications that use certificates (Certificate
> Consumers).
>
> Members of the CA/Browser Forum have worked closely together in defining
> the guidelines and means of *implementation for best practices **as a way
> of providing a heightened security for Internet transactions and creating a
> more intuitive method of displaying secure sites to Internet users*."
>

Dimitris,

I don't believe there is the conflict you suggest between the statement and
the bylaws.

I think we're in agreement the the CA/Browser Forum is voluntary.
I think we're in agreement that the CA/Browser Forum does not, nor has it
ever, defined Root Program Policy.
I think we're in agreement that the CA/Browser Forum does not, nor has it
ever, "enforced" any action upon CAs.

I think this is much clearer if you continue quoting from the Bylaws.
Indeed, the two sentences that immediately follow, emphasis mine, highlight
this:

1.2 Status of the Forum and the Forum Activities
The Forum has no corporate or association status, but is


*simply a group ofCertificate Issuers and Certificate Consumers that
communicates or meets from timeto time to discuss matters of common
interest relevant to the Forum’s purpose. TheForum has no regulatory or
industry powers over its members or others.*

I read this purpose as an "unofficial" agreement between Certificate
> Issuers and Certificate Consumers to improve security for internet
> transactions AND to create a more intuitive method of displaying secure
> sites to internet users.
>

No. It's a statement about what the Forum has done in the past. If you
continue reading, you will find out what the Forum does. It merely
discusses.


> I'm afraid this cannot be achieved if Certificate Consumer Members
> continuously bring their "guns" (i.e. Root Program Requirements) in CA/B
> Forum discussions. I would expect these "guns" to be displayed and used in
> the independent Root Program venues and not the CA/B Forum.
>

While I can understand if you're unhappy to discuss Root Program
Requirements, I think it belies a fundamental misunderstanding of the Forum
and the Baseline Requirements.

Recall: PKI was designed to allow different communities - i.e. different
browsers - to define different policies, profiles, and practices for the
CAs that participate in their different PKIs. The Microsoft PKI is distinct
from the Google PKI is distinct from the Mozilla PKI, each of which has
those vendors as the Root of Trust, signing a Trust List for use within
their products, based on their product security requirements.

Conceptually, each of these PKIs define their own profiles and practices
(the Root Program Requirements) and define their own means of assessing
(e.g. Mozilla distrusting certain auditors, Microsoft allowing certain
auditors). The Forum exists to allow for interoperability between these
distinct PKIs. The Baseline Requirements serve as a means of expressing a
common set of requirements, in order to reduce the need of obtaining a
distinct Microsoft audit or a distinct Mozilla audit, which are entirely
plausible scenarios.

Thus, it's inherent that the /only/ value of useful discussion to be had is
with respect to Root Program Requirements. It's also the opportunity for
CAs to provide input and insight 

Re: [cabfpub] FW: Ballot FORUM-10: Re-charter Forum Infrastructure Working Group

[Ryan Sleevi via Public]

Google votes Yes to ballot FORUM-10

On Mon, Sep 30, 2019 at 11:27 AM Jos Purvis (jopurvis) via Public <
public@cabforum.org> wrote:

> The following ballot is proposed by Jos Purvis of Cisco, endorsed by Wayne
> Thayer of Mozilla and Ben Wilson of DigiCert. Voting begins at *2100 UTC
> 30 September 2019* and runs through *2100 UTC 7 October 2019*.
>
>
>
> *Ballot Forum-10: Re-charter Forum Infrastructure Work*
>
> *Overview*
>
> The Forum Infrastructure Working Group (FIWG) was chartered during a
> period when the CABF Bylaws did not permit for the creation of
> subcommittees at the Forum level (only under a particular Working Group).
> Since the work the FIWG needed to undertake was pressing and covered the
> needs of the Forum as a whole, it was chartered as a Working Group to
> permit this work to begin under the existing Bylaws.
>
> With the completion of the recent Bylaws changes, subcommittees may now be
> constructed at the Forum level. In addition, the recent changes to Bylaws
> and membership have identified a hole by which membership in the FIWG could
> be used to “back-door” membership in the Forum as a whole, an unintended
> consequence worth squashing.
>
> This ballot, therefore, lays down the existing FIWG and immediately
> re-charters a Forum Infrastructure Subcommittee to continue its work.
>
>
>
> *Gory Details*
>
> 24 hours after this ballot passes the following will occur:
>
> 1.   The existing Forum Infrastructure Working Group will be
> dissolved per the Bylaws section 5.3.2 item 3.
>
> 2.  A new Infrastructure Subcommittee will be chartered under the
> CA/B Forum, per the Bylaws section 5.6, with the Charter of that
> Subcommittee as described below.
>
> 3.  The existing mailing list for the FIWG will be repurposed for the
> use of the Subcommittee, following an announcement to that end on the
> existing FIWG mailer.
>
> 4.  The existing wiki pages from the FIWG will be archived, and a new
> space created for the Subcommittee's use under the main Forum namespace.
>
>
>
> *Forum Infrastructure Subcommittee (FIS) Charter*
>
> *Scope* - The authorized scope of the Forum Infrastructure Subcommittee
> shall be as follows:
>
> · To oversee the acquisition, operation, and maintenance of the
> common CA/Browser Forum website and wiki resources;
>
> · To coordinate updates to public and Forum-facing web and wiki
> content in support of the Forum Webmaster role established in the Bylaws;
>
> · To create and manage the division of access and content spaces
> required to help ensure the separation of the work of various Working
> Groups and accompanying IP commitments, as described in the Forum’s IPR
> Policy;
>
> · To manage the technical means of production of guidelines and
> other documents produced by the Forum's subcommittees;
>
> · To manage the Forum-level email lists and to offer management
> of working-group and subcommittee mailing lists as needed in support of the
> Forum List Manager role established in the Bylaws;
>
> · To perform other activities ancillary to the primary activities
> listed above.
>
> *End Date* - This Subcommittee shall continue until it is dissolved by a
> vote of the CA/B Forum.
>
> *Deliverables* - The Forum Infrastructure Subcommittee shall be
> responsible for delivering wiki and mailing list services to the Forum on
> an ongoing basis, and supplying access to these and to the management tools
> for these as is appropriate and required by the Forum. The subcommittee
> shall not propose any changes to the Bylaws or IPR agreements itself: where
> issues with these are identified, they may be redirected to the Forum as a
> whole or to appropriate subcommittees or working groups for further
> consideration.
>
> *Participation* - Any member of the CAB Forum is eligible and may declare
> their participation in the Forum Infrastructure Subcommittee by requesting
> to be added to the mailing list.
>
> *Chair* - Jos Purvis shall be the initial Chair of the Forum
> Infrastructure Subcommittee. The Chair shall not have a fixed term, but the
> Subcommittee may change its Chair from time to time by consensus of the
> Members participating in the Subcommittee or by voting method chosen by the
> Members by consensus.
>
> *Communication* - Subcommittee communications and documents shall be
> posted on mailing-lists where the mail-archives are publicly accessible,
> and the Subcommittee shall publish minutes of its meetings to the Forum
> wiki.
>
> *Effect of Forum Bylaws Amendment for Subcommittees* - In the event the
> Forum Bylaws are amended to add or modify general rules governing Forum
> Subcommittees and how they operate (“General Rules”), the provisions of the
> General Rules shall take precedence over this charter.
>
>
>
> *Key Dates*
>
> *Ballot Discussion Begins*
>
> 20 Sept 2019 21:00 UTC
>
> *Ballot Discussion Concludes*
>
> 27 Sept 2019 21:00 UTC
>
> *Ballot Vote Begins*
>
> 30 Sept 2019 21:00 UTC

Re: [cabfpub] DRAFT Ballot Forum-XX: Allow Informative Changes to Guidelines

[Ryan Sleevi via Public]

On Wed, Sep 11, 2019 at 11:14 AM Dimitris Zacharopoulos (HARICA) via Public
 wrote:

> I probably got confused by processing all the previous discussions, during
> the F2F, teleconferences and the recent discussion on the CA/B Forum
> plenary public list.
>
> Leaving the EV Guidelines change aside, which you are absolutely correct
> and I didn't consider it properly, the rationale of making this a
> Forum-ballot is because the procedures for updating the Guidelines affect
> all Working Groups. The existing Server Certificate WG Charter doesn't say
> anything about how the ballots take place because this is described in the
> Bylaws. Passing a Forum Ballot with an accepted practice would affect all
> Working Groups and therefore we would not need to pass the same ballot for
> each Working Group. Please note the Motion language which starts with "The
> Chair or Vice-Chair of a CWG..."
>

This language does not work at a Forum level, because it implicitly assumes
a document structure to Final Guidelines or Final Maintenance Guidelines,
except those are determined at the CWG level. If that's your goal, then it
emphasizes precisely why it needs to be in the Bylaws. If that's not your
goal, that emphasizes precisely why it should be up to CWGs to decide when
adopting a Final Guideline or Final Maintenance Guideline.


> I did not propose updating the Bylaws because the majority of Members
> wanted to have more substantial changes collected for Bylaws updates
> because of the extra revisions (though legal and other departments). You
> also supported that we should not make small changes to Bylaws very
> frequently. I tried to capture that in this ballot which is why it is not a
> Bylaws update but a "Forum approved" practice, which already happens today.
>

That doesn't mean it's OK to /avoid/ changing the Bylaws; that means it's
better to *batch* the change. Or, you know, propose the change anyways and
see how/if folks accept it.


> There is no contravention of the Bylaws as far as this procedure is
> concerned. The Bylaws are silent about these changes.
>

Absolutely not. These are currently part of a CWGs Final Guideline / Final
Maintenance Guideline, which have a defined process for adoption and review
of all changes.


> If you consider that this proposed procedure violates the Bylaws, then you
> are practically saying that all existing Guidelines published on our web
> site are invalid.
>

The entire point should be to reduce ambiguity and to provide the
appropriate guidance. The only way to reduce that ambiguity is to ensure
it's captured within the Bylaws. While this may "seem" like a minor point,
the entire objective is to avoid a situation where "The bylaws say X", then
a ballot comes about that says "but we meant Y".


> If members feel that this needs to be an SCWG ballot, I'd gladly move it
> to the SCWG public list. If members feel this should be a Forum ballot, for
> the reasons mentioned above, I will revise the ballot and remove the
> changes to the EV Guidelines, as these would have to be performed at the
> SCWG. I therefore welcome some feedback from other members as well.
>
> I also feel a bit offended by your expression that I am "committed to
> avoiding changes to the Bylaws". I would very much like to make this a
> Bylaws update but I respect the majority's opinion not to make small
> changes to Bylaws.
>

It's unclear why offense was received, but it was certainly not intended.
You made it clear in your earlier message that you believe this should be
in the Bylaws and you are intentionally not placing it in the Bylaws. That
seems a very clear, intentional choice, especially in light of past
discussion why it should be in the Bylaws, not do it.

In our past conversations, I tried to helpfully guide you to solutions that
would comply, but it seems those are misremembered or misunderstood.
1) Change the Bylaws at the Forum level to allow CWGs to designate
informative sections of the FG/FMG which can be modified by the CWG
Chair/Vice-Chair (Forum Ballot) and have the SCWG & CSWGs designate the
appropriate sections that meet that criteria
2) Another option, which we did not discuss at length, but has tied in to
past discussions on infrastructure, but which also clearly solves this, and
w/o a change to Bylaws, is to remove the aforementioned sections from the
FG/FMG such that they are not officially part of the FG/FMG, and merely
aspects of the presentational format.

Put differently, #2 is highlighting that we don't dispute whether the Chair
or Vice-Chair is allowed to produce a PDF or Word Doc version of the
FG/FMG, even though those transform the representation. The version in
GitHub does not, for example, have page numbers or a footer checked in -
those are part of the presentation that's generated, as is the Table of
Contents. The infrastructure group even looked at how to remove the need
for the cover page being part of the document, by having that appended
during the presentational 

Re: [cabfpub] DRAFT Ballot Forum-XX: Allow Informative Changes to Guidelines

[Ryan Sleevi via Public]

Dimitris,

I'm a bit surprised you went this way, as I do think it creates more
problems.

On a ballot legitimacy level, I do not believe you can propose a Forum
level ballot to change a Final Maintenance Guideline of a CWG, which you've
done by proposing to use the Forum to change the EV Guidelines. That seems
directly in contravention of our Bylaws.

With respect to proposing Ballots that change our procedure in
contravention of the Bylaws, this is not acceptable. If you want to change
our Bylaws, then change our Bylaws - but the suggestion of creating
procedures that conflict with and contravene our Bylaws, without actually
capturing them, undermines the entire legitimacy of the Forum and our IP
protections, which are gated upon the execution of the Bylaws.

As we've previously discussed, repeatedly, a path forward involves having
the Bylaws recognize that CWGs may designate portions of Final Guidelines
and Final Maintenance Guidelines as informative and non-binding, and permit
modifications to those sections by the Chair or Vice-Chair. This would then
allow the SCWG to designate the appropriate sections as informative.

If you're committed to avoiding changes to the Bylaws, there are also
obvious other solutions as well, which fully comport with our Bylaws and IP
policy, and which would be done at the SCWG level.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Prepare ballot to allow Chair/Vice-Chair to make informative (not normative) changes to Final Guidelines and Final Maintenance Guidelines

[Ryan Sleevi via Public]

On Tue, Sep 3, 2019 at 12:13 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> I deliberately left this out because I would like to discuss the document
> version issue on a separate ballot because I am not sure how controversial
> or not it would be. At this point, I would not like the first four to be
> overridden by the ballot. Is that ok, for now?
>

If the point is to avoid controversy, then I think it would be better to
avoid prohibiting ballots - i.e. to permit all of the changes, unless
otherwise specified by ballot - then to try to restrict what the Forum can
Ballot.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Prepare ballot to allow Chair/Vice-Chair to make informative (not normative) changes to Final Guidelines and Final Maintenance Guidelines

[Ryan Sleevi via Public]

On Tue, Sep 3, 2019 at 11:36 AM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> wrote:

> Dear Members,
>
> Following up on recent discussions,
>
>- At the last F2F in Thessaloniki
>
> 
>- On the server certificate WG list
>
>
> and since the current Bylaws (version 2.2) do not address how the Chair or
> Vice-Chair could make any changes whatsoever to the Final Guidelines or
> Final Maintenance Guidelines, I would like to prepare a ballot with some
> administrative language that would allow the Forum or WG Chair (or
> Vice-Chair) to make some changes to Final Guidelines and Final Maintenance
> Guidelines. Please note that these practices are already in place and have
> been followed for years without any "official" approval from the Forum or a
> WG and without having received any objections by the Membership.
>
> Since this is language that would normally be in the Bylaws, and while we
> have other issues pending to discuss
> ,
> I would like to propose to ballot these issues separately and once we
> collect a few, we could update the Bylaws including language for all these
> separate issues. I understand that we don't want to make too frequent
> changes to our Bylaws because it involves legal reviews that take
> additional time, etc.
>
I don't believe this can be solely done by a change to the Bylaws; I
believe it would have to be the Bylaws and the SCWG Charter, since the SCWG
would need to designate what part of the Final Guidelines / Final
Maintenance Guidelines it adopts are informative and may be edited as such.
Does that match your understanding?

> I would like to start with what seems to be an uncontroversial issue.
> There seems to be consensus to allow the Chair or Vice-Chair to update
> informative (non-normative) sections of the Guidelines. Here is a list of
> changes that the Chair or Vice-Chair should be allowed to do on a Final
> Guideline or Final Maintenance Guideline before it is published on our
> public web site and without requiring a ballot procedure:
>
>1. The cover page,
>
> This is only for the version number, right?

>
>1.
>2. The Table of Contents
>3. Headers/Footers with version numbers and page numbers
>4. The table with document revisions or Document History
>5. The table with Relevant Dates, unless the ballot explicitly updates
>this table
>
> I would also recommend removing the first paragraph of the EV Guidelines
> which reads:
>
> "This version 1.7.0 represents the Extended Validation Guidelines, as
> adopted by the CA/Browser Forum as of Ballot SC17, passed by the Forum on
> 21 May 2019 and effective as of 21 June 2019." I believe it's redundant
> because this information is included in the revision history table and the
> public web site.
>
Note that the current "effective as of" refers to the document's adoption
per our IP review period completing, while the Document History table
refers to the effective date of various provisions. You can see this in
some of the dates within the existing history table; for example, it wasn't
until Ballot 198 (Version 1.6.3) that the Effective Date began aligning
with the completion of the IP Review Period, except it then diverged by
Ballot 217 (version 1.6.8)

I highlight this, because there's two elements / two updates:
1) The version circulated for IP review, which presumably will only be
missing the "Effective" date
2) The version posted to the Website, which would then be updated following
the adoption

Does that match your understanding?

> Are there any comments or additional changes that members would like to
> see before I start drafting some language? I plan on having something ready
> by the end of next week.
>
>From past discussion, but not specified here, it would seem that implicit
in this is a desire to allow the Chair or Vice-Chair to determine the
versioning, and prohibiting it via Ballot. Is that correct? That is, only
#5 on your list is reserved as "unless the ballot explicitly updates this
table", so it's unclear if it's meant that the first four can override a
ballot.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Notice of IPR Review Period - CSCWG Ballot-1

[Ryan Sleevi via Public]

On Tue, Aug 13, 2019 at 4:10 PM Dean Coclin via Public 
wrote:

> The 60 day review period has now passed and no exclusion notices were
> filed. Therefore the draft guideline distributed via this review notice has
> been approved as a CA/B Forum Code Signing Chartered Working Group standard.
>

Did you mean to say "Final Guideline", rather than standard, as per our
bylaws? [1]

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v2.2.pdf


>
>
> The guideline will now be called the Baseline Requirements for Code
> Signing and shall be posted on the public website, after this week’s
> meeting.
>
>
>
> Dean Coclin
>
> CSCWG Chair
>
>
>
> *From:* Cscwg-public  *On Behalf Of *Dean
> Coclin
> *Sent:* Thursday, June 13, 2019 4:29 AM
> *To:* cscwg-managem...@cabforum.org; cscwg-pub...@cabforum.org
> *Subject:* [Cscwg-public] Notice of IPR Review Period - CSCWG Ballot-1
>
>
>
> *NOTICE OF REVIEW PERIOD*
>
>
>
> **
>
>
>
> This Review Notice is sent pursuant to Section 4.1 of the CA/Browser
> Forum’s Intellectual Property Rights Policy (v1.3). This Review Period is
> for a Final Guideline (60 day Review Period).  Attached is a complete Draft
> Guideline subject of this Review Notice.
>
>
>
>
>
> Ballot for Review:Ballot CSCWG-1
>
> https://cabforum.org/pipermail/cscwg-public/2019-June/43.html
>
> Start of Review Period: June 13, 2019 at 11:00am Eastern Time
>
> End of Review Period:August 13, 2019 at 11:00am Eastern Time
>
>
>
>
>
> Please forward a written notice to exclude Essential Claims to the Working
> Group Chair by email to dean.coc...@digicert.com and a copy to the CSCWG
> Working Group public mailing  list at cscwg-pub...@cabforum.org before
> the end of the Review Period.
>
>
>
>
>
> See current version of CA/Browser Forum Intellectual Property Rights
> Policy for details.
>
>
>
> Optional form of Exclusion Notice is available at
>
> https://cabforum.org/wp-content/uploads/CSCWG-Exclusion-Notice.pdf
>
>
>
>
>
> Dean Coclin
>
> CSCWG Chair
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Audits and RAs

[Ryan Sleevi via Public]

On Tue, Jun 18, 2019 at 1:35 PM Jeremy Rowley via Public <
public@cabforum.org> wrote:

> I think I heard the WebTrust auditors say last week that they have
> finished or nearly finished the WebTrust for RAs criteria. The language
> from Section 8.4 of the guidelines reads:
>
>
>
> “For Delegated Third Parties which are not Enterprise RAs,, then the CA
> SHALL obtain an audit report, issued under the auditing standards that
> underlie the accepted audit schemes found in Section 8.1, that provides an
> opinion whether the Delegated Third Party’s performance complies with
> either the Delegated Third Party’s practice statement or the CA’s
> Certificate Policy and/or Certification Practice Statement. If the opinion
> is that the Delegated Third Party does not comply, then the CA SHALL not
> allow the Delegated Third Party to continue performing delegated functions.”
>
>
>
> We know some CAs use RAs that are not audited under WebTrust/ETSI because
> “there is no appropriate audit standard”. Now that there is an audit
> standards, it seems to me this criteria goes into effect immediately and
> any RA not audited would cause the CA to be out of compliance with the BRs.
> No additional ballot required since the concept is already baked into the
> BRs.
>
>
>
> Anyone have a different interpretation?  If not, when is the exact date
> that the audits should be done? Already?
>

TL;DR: Don't worry. I don't think there's an impending doom date.

Officially, Chrome is not planning to immediately enforce the WebTrust for
RAs audit, and is still evaluating the most effective means to use and
consume this.

For best results, however, don't use RAs ;)

Here's the alternative interpretation I'll over you:

The "auditing standards that underlie the accepted audit criteria" are, in
the case of WebTrust, are SSAE 18 (US), CSAE 3000 - 3001 (CA), and ISAE
3000 (elsewhere), with potentially jurisidiction-specific
(self-?)regulatory requirements or modifications, similar to the US/CA
harmonization with IFAC.

The "auditing standards that underlie the accepted audit criteria" are, for
ETSI EN 319 411-1 and ETSI EN 319 403, either (depending on your
perspective of "standard"), going to be seen as:
  a) ETSI EN 319 411-1 / ETSI EN 319 403
  b) ISO/IEC 17065

The former takes the view that the ETSI ESI documents are themselves the
standards for auditing, in that they define a set of standards appropriate
for "an" audit scheme, although absent the eIDAS Regulation lacks any
normative guidance about who the defining authority is for the appropriate
auditor (compared to IFAC and its constituent organizations, which does).

The latter takes the view that the ETSI ESI documents are themselves
adopted from the ISO/IEC standards and guidance on the development of
certification schemes (which covers a broad scheme of activities), and that
any scheme derived from the principles of 17065 is suitably empowered. It,
similarly, lacks the guidance as to who can perform the assessments, since
that is the role of the scheme operator (e.g. EU in the case of eIDAS)

The "nice" thing about these interpretations is that for CAs that are
concerned about being beyond reproach, but still make the (unfortunate)
choice to make use of delegated third parties, they can read these
requirements as using the relevant criteria from WebTrust or ETSI, under
the existing supervisory scheme, and argue compliance. CAs that don't like
to/don't want to know what their RAs are doing, and aren't as concerned
about security, could reasonably argue that the applicability of the
underlying standard means the CA defines what the expectations are (for
example, an "Agreed Upon Procedures" report - which I'm sure Don and Jeff
will jump in mentioning the CSAE limitations there), and then allow
'anyone' to perform that audit, modulo the IFAC standards with respect to
professional licensure.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Results of Ballot Forum-8 Establishment of a Code Signing Working Group

[Ryan Sleevi via Public]

On Fri, Mar 8, 2019 at 2:19 PM Dean Coclin via Public 
wrote:

> *Voting by Certificate Consumers – 3 votes total including abstentions*
>
>- *4 Yes votes:* Cisco, Microsoft, Opera
>
> Have I miscounted? It seems that there's a lack of agreement in these
counts.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Fri, Feb 8, 2019 at 3:24 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> In any case, since this seems to be a controversial matter, I will
> create a new thread in the Server Certificate Working Group public list
> and remove the additional requirements for WebTrust. I hope you are ok
> with the additional criteria for the third option (equivalent audits
> like Government CAs). If not, I can remove that option also.
>

I'm not opposed to it, I think it merely requires clarity, since we don't
(and there isn't) a very clear definition about Government CAs. We've had
that discussion in the case of Protiviti (which participates in the
discussions on behalf of FPKI) and in cases such as, if I recall correctly,
Hong Kong Post CA. This is, admittedly, an issue with the existing BRs, but
for which the matter is (presently) resolved by Root Store members applying
their own interpretation and/or requirements regarding Section 8.4 of the
BRs.

As a concrete example relevant for those European members, given that the
status of being recognized as Qualified is not fundamentally linked to the
possession of an EN 319 411-1/-2 audit, as I understand it, would a CA that
was qualified, but lacking an EN 319 411-1/-2 audit, constitute a
Government CA by virtue of the eIDAS Regulation (EU) 910/2014 being a
European Regulation?

I suspect that the matter could be resolved by clarifying that CAs which
participate in and provide audit for schemes that meet the existing
criteria (a) and (b) (combining them) from that Section 8.4 of the BRs,
bullet 3, and for which the scheme is required by or established "any
jurisdiction in which the CA operates or issues certificates" (using the
language from 9.16.3), we can avoid the phrase "Government CA" entirely.

Putting that all together:

If the CA is required to use a different audit scheme by any jurisdiction
in which the CA operates or issues certificates, it MAY use such scheme
provided that the audit scheme criteria are available for public and review
and either (a) encompasses all requirements of one of the above schemes or
(b) consists of comparable criteria.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

Here's some references for some of the past discussions:

You can search for the discussion around Ballot 149, in which Kirk had
proposed changes similar to what you're doing now. There's quite a bit of
discussion on that from various bits, but I suspect
https://cabforum.org/pipermail/public/2015-May/005620.html probably
captures it. This was a continuation of a discussion from earlier - see
https://cabforum.org/pipermail/public/2015-March/005375.html - which itself
was a continuation of the discussion from Cupertino in Meeting 34 -
https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/

If there's concerns that we haven't captured those objections enough, I'm
sure we can make sure minutes going forward capture controversial topics
more thoroughly.

My search focused on discussions on our public list; searching our
governance reform list is a bit trickier, but this was something we
similarly discussed when revising the Bylaws to our current form, and the
same concerns and objections were shared in the discussion of the draft
SCWG charter. Let me know if the above isn't sufficient.

We know that there will be direct harm - by promoting more exclusion - by
requiring the SSL BRs w/ Net Sec. While it's true that ETSI has
incorporated them directly, were ETSI to provide a similar broad profile, I
suspect there would be support for *reducing* the current ETSI
requirements. Given how ETSI functions, I suspect that 'reducing' is
accomplished by adding yet another criteria, since unlike WebTrust, you
don't mix and match the same, but the end result would be to increase
opportunities for participation.

There's very little benefit to increasing membership requirements. The main
benefits seem to be logistical, rather than practical - increasing
requirements can exclude more members and thus make it cheaper or easier to
host or organize meetings. However, given the harm that can be caused by
that, it does not seem useful - members who are affected by the
requirements cannot contribute effectively to them.

Consider, for example, if the only way to contribute to the EVGLs was to
have an EVGL audit. Imagine how difficult it would be to correct any
criteria that prevented a CA from getting an EVGL audit, such as the
discussion we saw related to E insurance/liability limits, as raised by
our Asian CA members. Today, they could propose suggestions by virtue of
the open membership; in a world where only entities with the audits could
participate in the discussions, there would be no way to resolve that or
push for change, short of hoping someone 'takes pity' and does it
themselves.

>From our perspective; the Forum's strength is not its production of
Guidelines themselves, but in providing a venue to gather feedback about
proposed changes in a way that does not create conflicting requirements
between Root Stores. The Guidelines do not and have never represented
'best' practice - just a common baseline. As we've shifted to a WG model,
that same logic extends to WGs - the greatest value in the Forum is through
having diverse views represented and gathering feedback about potentially
conflicting requirements, to try and find solutions for those conflicts.
>From our early involvement in the first governance reform - that lead to
the creation of the public lists - to our effort to provide opportunity to
gather and share public feedback via the questions@ list, we've valued
increased participation and transparency. The Validation Summit effort in
Herndon was, in many ways, a high point in the Forum's opportunity for
participation. We should be pushing for greater involvement - as we've seen
through the participation of Cisco, for example - than adding barriers that
would limit it.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Fri, Feb 8, 2019 at 12:42 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
>
> On 8/2/2019 6:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Fri, Feb 8, 2019 at 3:19 AM Dimitris Zacharopoulos (HARICA) via Public <
> public@cabforum.org> wrote:
>
>>
>> I made the following updates in addition to Wayne's:
>>
>>- Added a process for Interested Party application to CWGs as it
>>seemed to be missing from the Bylaws. The only reference we currently have
>>is on the web site (https://cabforum.org/email-lists/).
>>- For the Server Certificate Working Group membership criteria, I
>>tried to align with section 8.4 of the BRs.
>>
>> I'm hoping this is unintentional, but this is not a good change. This has
> been discussed repeatedly in the Forum, and moving to a more restrictive
> policy for membership in the charter has been regularly rejected.
>
>
> I don't recall Members being against it for membership criteria, because
> it was discussed in the past without objections. This was for consistency
> with ETSI because ETSI EN 319 411-1 includes the baseline requirements and
> network security guidelines where WebTrust for CAs does not. This change
> better aligns the two schemes and was discussed in ballot 223
> .
> Do other Members have similar concerns with this issue? I would appreciate
> it if others can also state their objection and concerns with this change.
>

I'll dig up the multiple past discussions of concerns.


> My hope is that, as proposer of those changes on the doc, you can go
> through and reject them or update them to ensure that our current approach
> for the SCWG remains as is.
>
>
> Can you explain why there should be a difference between the Baseline
> Requirements section 8.4 and the server certificate working group
> membership criteria? Since these are accepted in the BRs, it makes sense to
> me to also be updated in the Membership criteria for the Server Certificate
> Working Group.
>

I'll dig up the multiple past discussions of concerns.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Fri, Feb 8, 2019 at 3:19 AM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> wrote:

>
> I made the following updates in addition to Wayne's:
>
>- Added a process for Interested Party application to CWGs as it
>seemed to be missing from the Bylaws. The only reference we currently have
>is on the web site (https://cabforum.org/email-lists/).
>- For the Server Certificate Working Group membership criteria, I
>tried to align with section 8.4 of the BRs.
>
> I'm hoping this is unintentional, but this is not a good change. This has
been discussed repeatedly in the Forum, and moving to a more restrictive
policy for membership in the charter has been regularly rejected.

My hope is that, as proposer of those changes on the doc, you can go
through and reject them or update them to ensure that our current approach
for the SCWG remains as is.


>- On the last call, we also agreed to add sample Membership criteria
>to the new Working Group Charter section. I added a simplified version of
>criteria based on section 8.4 of the BRs, including Government internal
>audit schemes that might also be acceptable for the S/MIME Working Group.
>
> The problem with lifting this text, as is, is that it relies on
definitions from the BRs not present within charters. For example, the
interchangability of "Government CA" / "Government Certificate Issuer" are
in no way defined.

>
>- Following the example of moving the membership criteria to the CWG
>Charters, I moved the "end membership" section to the Server Certificate
>Working Group Charter AND the template for new WG Charters. I believe that
>there was agreement that each Working Group should determine their own
>rules for ending Working Group membership, similar to determining the
>criteria for joining a working group.
>
> Similarly, the prospects of ending membership are not well-aligned with a
generic charter.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

On Wed, Feb 6, 2019 at 3:20 PM Tim Hollebeek 
wrote:

> My experience is the reverse.  IETF and groups with tight charters get
> bogged down in constant discussions about charter revisions.
>

Interesting example. While I do disagree with your conclusions, it's useful
to understand the perspective and the context - IETF WGs that would
regularly go off into the weeds and produce something unusuable,
unimplemented, and not aligned with actual needs. Recall that this is why,
especially in the PKI space, multiple WGs were shut down - because they
constantly were getting distracted, lacking consensus, and yet still
trudging on.

While I can't speak with absolute certainty, the debate about adoptions -
including in LAMPS - has I think helpfully demonstrated a very clear lack
of consensus to take on the work, and that while sometimes the work is very
important to some members, it's not seen as broadly valuable or with
consensus.

With something as broad as S/MIME, we absolutely need that level of
restraint.


> CABF has recently fallen into the same trap and I don’t think it is a
> change for the better.  There are other SDOs I participate in where groups
> have operated for 10+ years with the same charter, with no downsides other
> than the fact that they spend their time discussing and working on the
> relevant issues instead of re-chartering every time a new topic comes up.
>

And do they scope their IP protections the same? And consensus measures?

My choice of IETF and W3C wasn't accidental; they have also served as
models for our workmode and IP protections.

With something as broad as S/MIME, we absolutely need those level of
protections.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

On Wed, Feb 6, 2019 at 12:41 PM Tim Hollebeek 
wrote:

> There are many SDOs that I participate in that are able to manage their
> priorities effectively without hardcoding them into a charter.  In fact,
> it’s more common than not.  In my experience, SDOs that require a
> re-charter every time they want to discuss a new topic is indeed very
> disruptive and high overhead.
>

I've tried to provide very detailed answers to support the position I'm
advocating. Could you discuss more what parts you believe are disruptive
and high overhead? Is it because there's disagreement on embracing the
topic and/or disagreement on the appropriateness of the timing?

While there are many SDOs, I will highlight that the SDOs that have been
most successful for our line of work - that is, groups such as IETF and W3C
- have fairly consistency and explicitly required 'tight' charters with
explicit deliverables, as a way of measuring and ensuring progress. Groups
that have tended to have very broad charters - which include ETSI and OASIS
- tend to get extremely mired down in debates, much like the one we're
having now, rather than focusing on the concrete deliverables.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

On Tue, Feb 5, 2019 at 4:29 PM Dean Coclin  wrote:

> While that’s true, there’s also the risk to that approach in that the
> community feels that topic X is not included in the charter and therefore
> will not be addressed or feel that it’s not important a topic to be
> addressed.
>
>
>
> By including it in the initial charter and by specifying the order of
> events, that insures it will be covered at some point. The charter can say
> simply (with better wording):
>
>
>
> “Topics A, B, C and X, Y, Z will be covered in the charter. Topics A, B, C
> will be the first ones addressed in the initial release of the guidelines.
> Topics X, Y, Z will be addressed in a subsequent release. The initial
> guidelines will have to be voted on and approved prior to moving to topics
> X, Y, Z.” This avoids the risk you describe about starting to work on the
> secondary topics before the first ones are approved.
>
>
>
> This insures the relevant topics expressed by the community are in scope
> but that an ordering is preferred and necessary. It also avoids a problem
> later on by anyone who doesn’t want to cover topics X, Y, Z and forces the
> working group to disband before they are addressed.
>

I suspect we'll disagree on this, but what you describe as a bug is
actually a feature.

It defers the debate about topics X, Y, and Z, and how to address them, and
when to address them, to a time later suited, in order to ensure that focus
is executed on A, B, C.

I'm supportive of language that helps assuage folks concerns by clarifying
that it's excluded from scope without a statement about fitness for
purpose, if that is the only reason to include X, Y, Z in the charter, but
I believe there is substantial harm in including it as you've presented,
for the reasons I explained previously.

And while I realize that many members would prefer not to think about IP
issues, including X, Y, and Z in scope mean that, at any time,
participation may touch on IP on those topics, even if they're not 'yet'
being tackled. Explicitly excluding from scope, and rechartering, helps
provide meaningful check points for progress.

Just as we talk about how "good" ballots are one that are focused and
narrow to a problem at hand - which the Validation WG has done a fairly
great job at demonstrating - the same applies to charters. Keeping focus is
extremely valuable, and we shouldn't compromise that.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

t many CAs which are currently issuing S/MIME
> certificates are also including identity. I assume that most use similar
> methods that are defined in the BRs to validate identity. It would seem
> that it should be included in the scope to cover current practice.
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org
> ] *On Behalf Of *Wayne Thayer via Public
> *Sent:* January 25, 2019 1:37 PM
> *To:* Ryan Sleevi ; CA/Browser Forum Public Discussion
> List 
> *Subject:* [EXTERNAL]Re: [cabfpub] Draft SMIME Working Group Charter
>
>
>
> *WARNING:* This email originated outside of Entrust Datacard.
> *DO NOT CLICK* links or attachments unless you trust the sender and know
> the content is safe.
> --
>
> I agree that we should exclude identity validation from the initial scope
> of this working group.
>
>
>
> On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public <
> public@cabforum.org> wrote:
>
>
>
> Finally, regarding membership criteria, I'm curious whether it's necessary
> to consider WebTrust for CAs / ETSI at all. For work like this, would it
> make sense to merely specify the requirements for a CA as one that is
> trusted for and actively issues S/MIME certificates that are accepted by a
> Certificate Consumer. This seems to be widely inclusive and can be iterated
> upon if/when improved criteria are developed, if appropriate.
>
>
>
> This would allow a CA that is not eligible for full Forum membership to
> join this WG as a full member. How would that work? Would we require such
> an organization to join the Forum as an Interested Party? If the idea is
> that such an organization wouldn't be required to join the Forum, then I
> don't believe that was anticipated or intended in the design of the current
> structure. It's not clear to me that we should permit membership in a CWG
> without Forum membership. For instance, allowing this may create loopholes
> in the IPR obligations that are defined and administered at the Forum level.
>
>
>
> There's also a bootstrapping issue for membership, in that until we know
> who the accepted Certificate Consumers are, no CA can join as a Certificate
> Issuer. I'm curious whether it makes sense to explicitly bootstrap this in
> the charter or how we'd like to tackle this.
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Wed, Jan 30, 2019 at 2:21 AM Dimitris Zacharopoulos (HARICA) <
dzach...@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.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Tue, Jan 29, 2019 at 12:11 PM Dimitris Zacharopoulos 
wrote:

>
>
> On 29/1/2019 4:56 μ.μ., Ryan Sleevi wrote:
>
> This isn't theoretical; at least one CA member provides such audits, as
> they use such a third-party datacenter. If the datacenter provided just
> their report, would they qualify? If they don't, then what is the property
> that we're trying to achieve, and why, so that we can do it?
>
>
> Would this WebTrust for CAs audit report be sufficient for acceptance in a
> Root Program? I don't think so.  All these years, CA/B Forum Members have
> been accepted by providing WebTrust for CAs and ETSI reports that include
> core PKI procedures. What you describe is probably an exception and we can
> decide how to handle this exception if in fact we ever receive an
> application for participation in a WG with a WebTrust for CAs audit report
> scoping just the physical security of a Datacenter. I'm hope that CA had
> other WebTrust for CAs reports for their other operations.
>

Unfortunately, this doesn't really answer the question posed, and doesn't
move us closer to understanding.

Your response seems to suggest that the bar is "Whatever is enough to be
trusted by a Certificate Consumer", which is the suggestion I had made
elsewhere, as it avoids the ambiguity of the Forum interpreting and/or
setting these guidelines, and instead moves to a very objective model that
we can use and that can be extended if necessary.

You suggest it's an exception, but I think it bears repeated reminding: As
the Forum looks to undertake "new" work (in the case of S/MIME or Code
Signing), where there exist no objective industry-accepted audit criteria,
and instead a lose assortment, which includes, but is not limited to,
WebTrust for CAs, then I think our definition of membership needs to evolve
to reflect that. We cannot take on this 'new' work without figuring out how
to include those either affected by or with value to contribute to the
discussions. The selection of "Webtrust for CAs" or "ETSI" is merely a
codification of existing SSL/TLS Certificate Consumer practice, but it's
not robust to handle that new work.

So, to again put the question back to you: Do you think there's some
property, beyond "accepted by a Certificate Consumer", that you feel is
essential for the Forum to capture within its membership requirements?


> Then by this goal, I don't believe our current membership criteria meet
> this. For example, a qualified auditor is determined by... government
> regulations in the case of ETSI. Does that mean we should exclude ETSI
> audits from the scope? Or should we allow CABs that are not accredited by
> the NABs?
>
>
> This doesn't make a lot of sense. NABs are not Supervisory Bodies. It's
> different. I was referring to government audit schemes for CAs where a
> certain government unit audits a CA under national criteria.
>

Yet the use of ETSI is still regulated.


> I realize it may seem like I'm being difficult, but I think there's a core
> piece missing, which is trying to understand why it's important for some
> members to exclude some other CAs that have had long-standing operations.
> This is particularly relevant for the discussion of the S/MIME charter, in
> which there is significant and extant set of 'trusted' certificates, in a
> variety of software, that does not meet the criteria for participation.
> They would be excluded from participating in engaging or drafting the new
> criteria, by virtue of the Forum membership criteria, and I think that's
> something we should be thinking very carefully about and articulating what
> properties we expect of CAs and why.
>
>
> IMHO we need audit requirements that have undergone enough scrutiny and
> quality assurance. International standards like ISO, WebTrust and ETSI have
> such a process which provides better assurance for the audit outcome.
> That's my personal view. We can always listen to other schemes and we would
> welcome input from governments (as Interested Parties) if they choose to
> participate. If these schemes became so useful and comparable with existing
> international schemes, then the S/MIME Working Group could decide to add
> those schemes in the criteria for Membership and possibly in the produced
> Guidelines.
>

I'm trying to understand the /why/ you take that personal view. I see no
objective reasoning to support that.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Tue, Jan 29, 2019 at 2:18 AM Dimitris Zacharopoulos 
wrote:

>
>
> On 28/1/2019 8:48 μ.μ., Ryan Sleevi via Public wrote:
>
>
>
> On Thu, Jan 24, 2019 at 2:30 PM Dimitris Zacharopoulos (HARICA) via Public
>  wrote:
>
>>
>>
>> On 24/1/2019 8:16 μ.μ., Wayne Thayer via Public wrote:
>>
>> On today's call we discussed a number of changes to the bylaws aimed at
>> clarifying the rules for membership. The proposal for section 2.1(a)(1)
>> resulting from today's discussion is:
>>
>> Certificate Issuer: The member organization operates a certification
>>> authority that has a publicly-available audit report or attestation
>>> statement that meets the following requirements:
>>> * Is based on the full, current version of the WebTrust for CAs, ETSI EN
>>> 319 411-1 , or ETSI EN 319 411-2 audit criteria
>>>
>> Using the example reports for discussion (
> http://www.webtrust.org/practitioner-qualifications/docs/item85808.pdf )
>
> If a CA does not escrow CA keys, does not provide subscriber key
> generation services, or suspension services, does that count as being based
> on the "full, current version"? (Page 11, paragraph 2)
>
>
> I think so, yes. Based on the exact CA operations, the exact audit scope
> is determined. The Forum has set the WebTrust for CAs and ETSI EN 319 411-1
> as an absolute minimum that includes attestation of the existence of
> reasonable organizational and technical controls. If you recall, I had
> proposed that for the SCWG we should also require WebTrust for CAs Baseline
> and NetSec because they are already included in ETSI EN 319 411-1 and are
> more suitable for SSL/TLS Certificates. If a CA obtains a WebTrust for CAs
> or ETSI EN 319 411-1 audit report, it means that the core CA services are
> there and are operational.
>

I don't believe this is a correct understanding. By highlighting that it's
acceptable to carve out the scope, you're seemingly acknowledging that it's
acceptable to take subsets of the audit criteria. For example, if I
provided an audit for the physical security controls of my data center
against the WebTrust for CAs criteria, is that sufficient for membership as
a CA?

This isn't theoretical; at least one CA member provides such audits, as
they use such a third-party datacenter. If the datacenter provided just
their report, would they qualify? If they don't, then what is the property
that we're trying to achieve, and why, so that we can do it?


> Root programs have audit requirements exceptions and this applies equally
> to Microsoft and Mozilla. I don't disagree to being more inclusive but I
> believe the Forum must have objective and specific requirements based on
> some international standards and not just government regulations.
>

Then by this goal, I don't believe our current membership criteria meet
this. For example, a qualified auditor is determined by... government
regulations in the case of ETSI. Does that mean we should exclude ETSI
audits from the scope? Or should we allow CABs that are not accredited by
the NABs?

I realize it may seem like I'm being difficult, but I think there's a core
piece missing, which is trying to understand why it's important for some
members to exclude some other CAs that have had long-standing operations.
This is particularly relevant for the discussion of the S/MIME charter, in
which there is significant and extant set of 'trusted' certificates, in a
variety of software, that does not meet the criteria for participation.
They would be excluded from participating in engaging or drafting the new
criteria, by virtue of the Forum membership criteria, and I think that's
something we should be thinking very carefully about and articulating what
properties we expect of CAs and why.


> * Covers a period of at least 60 days
>>>
>> I'm curious for feedback from the ETSI folks, but perhaps a more
> inclusive definition would be
> - "Reports on the operational effectiveness of controls for a historic
> period of at least 60 days"
>
> The context being that ETSI is a certification scheme, but as part of that
> certification, the CAB "may" ("should") examine the historic evidence for
> some period of time. 7.9 of 319 403 only requires "since the previous audit"
>
>
> I am not representing ETSI or ACAB'c but if there are concerns with this
> requirement we can solve this issue using the language proposed by Wayne
> "Covers a period of at least 60 days". I would use "Covers a period of
> operations of at least 60 days".
>

I'm not sure what this is a response to. I was pointing out the issues with
the language proposed by Wayne and why it's insufficient, so it's not clear
to me how you've resolved that.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

On Mon, Jan 28, 2019 at 3:28 PM Tim Hollebeek 
wrote:

> Because diverse and sometimes even contradictory root program requirements
> are not a good thing.  It seems like we should be able to reach agreement
> on what the minimum criteria should be, just as we have for TLS.
>

I'm not sure which part you're replying to, but the diversity of audit
requirements is already something we already have with TLS, and I don't see
any signs of that changing.

Perhaps you can help me understand how a normative membership requirement
on audits furthers that goal.


>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Monday, January 28, 2019 3:14 PM
> *To:* Tim Hollebeek 
> *Cc:* Wayne Thayer ; CA/Browser Forum Public
> Discussion List 
> *Subject:* Re: [cabfpub] Draft SMIME Working Group Charter
>
>
>
>
>
>
>
> On Mon, Jan 28, 2019 at 2:44 PM Tim Hollebeek 
> wrote:
>
> I’m fine with “or equivalent” exceptions for various use cases, as long as
> we specify what those are and they accomplish the same goals.  I do have
> strong opinions about how “*.gov” should be managed, specifically that I
> don’t think it’s possible to assure that the domain portion of the email is
> being consistently validated, absent some oversight by some independent
> entity.
>
>
>
> I suppose this will be a core part of the discussion, then. I will,
> however, note that ICANN has adopted a very different philosophy than you
> with respect to domain names, and similarly, Microsoft has recognized the
> distinction with how they manage their program. This also aligns with a
> variety of other technology and non-technology sectors, and is, perhaps, a
> core part of disagreement.
>
>
>
> Could you help me understand why, for purposes of CA/B Forum membership,
> you believe they should be overseen by someone that the CA/B Forum
> designates, rather than by an entity that a root program designates?
> Perhaps I'm missing why it's important to exclude these parties from the
> Forum, as that might help clarify the language.
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

On Mon, Jan 28, 2019 at 2:44 PM Tim Hollebeek 
wrote:

> I’m fine with “or equivalent” exceptions for various use cases, as long as
> we specify what those are and they accomplish the same goals.  I do have
> strong opinions about how “*.gov” should be managed, specifically that I
> don’t think it’s possible to assure that the domain portion of the email is
> being consistently validated, absent some oversight by some independent
> entity.
>

I suppose this will be a core part of the discussion, then. I will,
however, note that ICANN has adopted a very different philosophy than you
with respect to domain names, and similarly, Microsoft has recognized the
distinction with how they manage their program. This also aligns with a
variety of other technology and non-technology sectors, and is, perhaps, a
core part of disagreement.

Could you help me understand why, for purposes of CA/B Forum membership,
you believe they should be overseen by someone that the CA/B Forum
designates, rather than by an entity that a root program designates?
Perhaps I'm missing why it's important to exclude these parties from the
Forum, as that might help clarify the language.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

On Mon, Jan 28, 2019 at 2:17 PM Tim Hollebeek 
wrote:

> The intent was that Forum level membership was the union of all CWG
> membership criteria.  If you’re able to join a CWG, you’re a Forum member.
>
>
>
> I think allowing in unaudited Certificate Issuers would be a huge step
> backwards.
>

Note that the proposal was not "unaudited" - merely, that the definition of
audit be left to "Certificate Consumer", which participation with is
already a required property.

For example, some Consumers allow audits by government entities, but then
constrain issuance using application-specific means (since, after all, this
is a trust anchor). Others allow for equivalent audit schemes at their
discretion.

Thus, it also runs the risk of being a "step backward" to have members who
are bound by various rules (such as an S/MIME Guideline) but that are
prevented by the Forum from joining unless they change their business,
governance, or auditability model. An example of this concretely is the
Federal PKI operated in the US.

While for SSL/TLS cases, I may be more inclined to agree, S/MIME represents
a particular area where given the nature of the 'localpart' of email
addresses (fully in control of the organization), delegated CAs and trust
relationships are far more common. For example, I don't have strong
opinions on how "*.gov" should be managed, with respect to S/MIME, provided
that the domain portion of the email is consistently validated.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Thu, Jan 24, 2019 at 2:30 PM Dimitris Zacharopoulos (HARICA) via Public <
public@cabforum.org> wrote:

>
>
> On 24/1/2019 8:16 μ.μ., Wayne Thayer via Public wrote:
>
> On today's call we discussed a number of changes to the bylaws aimed at
> clarifying the rules for membership. The proposal for section 2.1(a)(1)
> resulting from today's discussion is:
>
> Certificate Issuer: The member organization operates a certification
>> authority that has a publicly-available audit report or attestation
>> statement that meets the following requirements:
>> * Is based on the full, current version of the WebTrust for CAs, ETSI EN
>> 319 411-1 , or ETSI EN 319 411-2 audit criteria
>>
> Using the example reports for discussion (
http://www.webtrust.org/practitioner-qualifications/docs/item85808.pdf )

If a CA does not escrow CA keys, does not provide subscriber key generation
services, or suspension services, does that count as being based on the
"full, current version"? (Page 11, paragraph 2)

> * Covers a period of at least 60 days
>>
> I'm curious for feedback from the ETSI folks, but perhaps a more inclusive
definition would be
- "Reports on the operational effectiveness of controls for a historic
period of at least 60 days"

The context being that ETSI is a certification scheme, but as part of that
certification, the CAB "may" ("should") examine the historic evidence for
some period of time. 7.9 of 319 403 only requires "since the previous audit"

> * Covers a period that ends within the past 15 months
>>
> This may also be resting on the BR definition of Audit Period. I can see
similar ambiguities arising with respect to ETSI and that its certification
decisions last two years, not one, thus it might cause a CA to believe that
they have up to three years from first completing their audit (that is, if
the letter is issued at T=2 years, covering T=0 to T=2, and is valid to T=4
years, then the CA may believe it's covered until T=5 years and 3 months)

There's also the potential of surveillance audits conducted over specific
issues being resolved, without being a full recertification (e.g. if the
CAB classified it as a minor non-conformity)

"With no more than 27 months having elapsed since the beginning of the
reported-on period and no more than 15 months since the end of the
reported-on period"

It's a mouthful, but perhaps there's a more concise way to capture that
unambiguously.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft SMIME Working Group Charter

[Ryan Sleevi via Public]

Thanks for starting this, Ben!

I have a long list of feedback, which I wanted to provide on the list to be
transparent about the motivations and goals, although I'll also duplicate
them as suggested edits on the doc after sending this, to provide more
concrete and hopefully productive guidance.

I realize this has gone through several edits now, but I'm concerned that
as a result of those edits, it seems to be going in a very different
direction than was discussed in Shanghai and London, and hoping that's
largely oversight or ambition.

Specifically, we looked at the case that various S/MIME certificates are
also granted for other purposes - for example, document signing or client
ID. CAs and some root store members were keen to avoid conflicting
requirements with existing issuance practices; that is, their desire was to
specify what was practiced, rather than an aspirational side. On the other
hand, other members expressed a desire to express a clear minimum set of
technical requirements - such as a common agreement on validation for the
core function (such as e-mail) and algorithm profiles, without necessarily
considering existing certificates.

Perhaps most complicated of this space was the view of identity. There's a
clear spectrum of existing deployments, ranging from a notion that might be
best described as "Enterprise RA" - in which a domain is vetted to belong
to an organization and they subsequently vet the localpart to those that
might be described as "Legal Identity Frameworks", in which some
legally-empowered entity makes full assertion about the legal identity, and
the e-mail is perhaps not even validated at all, but merely self-attested.

The suggestion made at Shanghai was, for both scope and agility, to focus
on the core technical profile. In particular, what is the core necessary
and sufficient part for an S/MIME certificate. I came away with the
impression that there was consensus that, at the core, S/MIME is useful for
the RFC 822 validation of the e-mail address. Other pieces of information -
such as legal identity - were 'value added' but not core to the definition,
and thus optional. We (Google) see significant value in S/MIME even without
asserting legal identity, in helping both authenticate and encrypt e-mails.
This is not just a philosophical difference - one we've certainly shared in
the past for other certificates - but one that's also reflected in existing
widespread industry practice.

This path is the path that EV took, in which CAs by and large had to make
changes, some moreso than others, to approach the path of EV. Similarly, as
many CAs know, the Baseline Requirements ultimately required a number of
CAs to change their issuance practices, and existing, non-BR compliant
certificates and CAs are no longer trusted in the ecosystem.

The most recent edit appears to have been influenced to go to the other
extreme, of asserting legal identity, and that seems to bring with it all
of the significant concerns about both compatibility and naming that seemed
entirely avoidable and, arguably, non-essential to a "Baseline" document.

With that context and backstory, I'll try to highlight specific areas that
seem problematic:
> An S/MIME certificate contains the public key bound to an identity of a
natural person or legal entity.

This is a more recent edit that very explicitly states that S/MIME
certificates are about legal identities. Previous edits suggested "used
by", which was less problematic, as it was both descriptive and
non-exhaustive. However, I think it'd be much more valuable for the scope
of activities of the WG if we can focus on the core baseline of validating
e-mails, and thus I would assert that the necessary and sufficient
definition here should be:

*An S/MIME certificate contains a public key bound to an email address.*

> For effective authentication and privacy, it is imperative that the CA
validates the subject’s identity and its email address.

Similarly, in previous edits, this correctly only stated that the CA
validates the subject's email address as the core competency and function.
That's not discounting that identity may be valuable in some situations,
but at its core, S/MIME only needs vet the e-mail address.

*For effective authentication and privacy, it is imperative that the CA
validates the subject's email address.*

> to the public key, email address, and distinguished name contained

This is another recent edit, which introduces "and distinguished name". I
would similarly request this be removed, and it be asserted that the core
validation is to the public key and email address.

>  to validate an email address and the subject’s identity prior to binding
it to the email address.

This entire paragraph appears new from earlier drafts. Unfortunately, it's
intimately tied to the validation of the subject identity and existing
identity management frameworks, which significantly undermines the utility
of the S/MIME WG. Here I'm torn on how to 

Re: [cabfpub] [Servercert-wg] Ballot SC14 version 2: Updated Phone Validation Methods

[Ryan Sleevi via Public]

On Tue, Jan 8, 2019 at 11:35 AM Doug Beattie via Servercert-wg <
servercert...@cabforum.org> wrote:

>
>
> *This is version 2 of Ballot SC14 with the DNS CAA record method removed.
> Review period reset for full 7 days.*
>
>
>
> Ballot SC14: Updated Phone Validation Methods
>
>
>
> Purpose of Ballot: As discussed during the Validation Summit, Method 3 of
> the Baseline Requirements could use some improvements to close off some
> potential bad practices that might lead to security risks.  This Ballot
> tightens up the rules around phone validation in order to make sure domain
> authorization or control is verified with a person who is authorized to do
> so by introducing a replacement for Method 3.  Validations done under
> Method 3 will continue to be valid until the end of the data reuse period,
> but new phone based validations must use the new method by the date
> specified in the ballot below.
>
>
>
> This ballot also builds on “Ballot SC13: CAA Contact Property and
> Associated E-mail Validation Methods” to permit domain owners to publish
> Domain Validation phone numbers in DNS TXT records.  Since these phone
> numbers are specifically for the purpose of validating domains, it’s not
> permissible to be transferred to a different number.
>
>
>
> The following motion has been proposed by Doug Beattie of GlobalSign and
> endorsed by Bruce Morton of Entrust and Tim Hollebeek of DigiCert.
>
>
>
> --- MOTION BEGINS ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.6.2 with ballot SC13 changes:
>
>
>
> Add the following definition to section 1.6.1:
>
>
>
> DNS TXT Record Phone Contact: The phone number defined in section B.2.2.
>
>
>
> In section 1.6.1, change the section references for the definition of “DNS
> CAA Email Contact” from B.1.2 to B.1.1.
>
>
>
> In section 1.6.1, change the section references for the definition of “DNS
> TXT Record Email Contact” from B.2.2 to B.2.1 respectively
>
>
>
> In section 3.2.2.4.3, after the end of the second paragraph add the
> following text as a new paragraph: ”CAs SHALL NOT perform validations
> using this method after July 31, 2019.  Completed validations using this
> method SHALL continue to be valid for subsequent issuance per the
> applicable certificate data reuse periods.”
>

Is there a reason for half a year? I think the substance of when is how
much operational change it would bring to a CA. I'm curious what risks a
date such as April would pose, in trying to understand a bit more.


> Add sections 3.2.2.4.15 and  3.2.2.4.16 as follows:
>
>
>
> 3.2.2.4.15 Phone Contact with Domain Contact
>
>
>
> Confirm the Applicant's control over the FQDN by calling the Domain
> Contact’s phone number and obtain a confirming response to validate the
> ADN.
>

Compared to the language in other sections (e.g. 3.2.2.4.2, 3.2.2.4.4),
this omits the "utilizing a Random Value" that tends to follow "obtain a
confirming response". Was this intentional? Combined with the later section
('may leave the Random Value'), it suggests that there may be two flows
here being described, and it's not entirely clear what's expected of either.


> Each phone call MAY confirm control of multiple ADNs provided that the
> same Domain Contact phone number is listed for each ADN being verified and
> they provide a confirming response for each ADN.
>
>
>
> In the event that someone other than a Domain Contact is reached, the CA
> MAY request to be transferred to the Domain Contact.
>
>
>
> In the event of reaching voicemail, the CA may leave the Random Value and
> the ADN(s) being validated.  The Domain Contact may return the Random
> Number to the CA via Phone, Email, Fax, or SMS to approve the request.
>

I just want to confirm it's intentional: As far as I can tell, this is the
first restriction on how the Domain Contact returns Random Numbers. Other
validation methods specify the delivery mechanism of the random value, but
don't specify the confirmation channel of those random values.

Was this intentional? For example, this would prohibit a flow in which a
confirming response is left for an Applicant, and that the Applicant then
confirms by going to an account management page and enters the confirming
response. If there's a link to past discussion on the communication
channels being used back here, do you have a pointer?


> The Random Value SHALL remain valid for use in a confirming response for
> no more than 30 days from its creation. The CPS MAY specify a shorter
> validity period for Random Values.
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN.  This method is suitable for validating Wildcard Domain
> Names.
>
>
>
> 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
>
>
>
> Confirm the Applicant's control over the FQDN by calling the DNS TXT
> Record 

Re: [cabfpub] [Servercert-wg] Ballot SC14: CAA Contact Property and Associated Phone Validation Methods

[Ryan Sleevi via Public]

On Mon, Jan 7, 2019 at 5:45 PM Tim Hollebeek 
wrote:

> The IANA registration has already been made and acknowledged by IANA.
> IESG will discuss appointing an expert on their next call.
>
>
>
> I will note that what was ACTUALLY agreed to in London was that work with
> IANA need not obstruct progress at the Forum itself.
>

That is not what is reflected in the minutes or past e-mails.


> And there is certainly no requirement in either group that work on a
> previous specification must complete before the next one can be proposed.
>

I believe that materially misrepresents what has been stated. It is not
that either group formally requires that process. It's that, as
demonstrated with SC13, the process and expectations were violated, and it
would be poor form - enough to be reason to oppose a ballot that sought to
do it - were it to be repeated. We should learn from our mistakes, not seek
to justify or repeat them.


> Remember, the only purpose of expert review in this context is to make
> sure the tag name does not conflict with other proposals.
>

This is not correct. For the benefit of others:

https://tools.ietf.org/html/rfc6844#section-7.2
   Addition of tag identifiers requires a public specification and
   Expert Review as set out in [RFC6195], Section 3.1.1.

   The tag space is designed to be sufficiently large that exhausting
   the possible tag space need not be a concern.  The scope of Expert
   Review SHOULD be limited to the question of whether the specification
   provided is sufficiently clear to permit implementation and to avoid
   unnecessary duplication of functionality.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] Ballot SC14: CAA Contact Property and Associated Phone Validation Methods

[Ryan Sleevi via Public]

Doug,

It may be useful to hold off on this Ballot until Tim has performed the
necessary steps for IANA registration, which also involves the Expert
Review. As captured from the ballot discussion, the 'original' or 'agreed'
process was spec -> review -> allow, although ballot SC13 opted for
spec+allow -> review instead. In both cases, however, IANA Expert Review is
part of the process to completing the previous ballot, and it seems useful
to ensure that the Forum has not stepped on toes or missed glaring issues
with the previous ballot before we move to the next.

On Mon, Jan 7, 2019 at 12:19 PM Doug Beattie via Servercert-wg <
servercert...@cabforum.org> wrote:

> Ballot SC14: CAA Contact Property and Associated Phone Validation Methods
>
>
>
> Purpose of Ballot: As discussed during the Validation Summit, Method 3 of
> the Baseline Requirements could use some improvements to close off some
> potential bad practices that might lead to security risks.  This Ballot
> tightens up the rules around phone validation in order to make sure domain
> authorization or control is verified with a person who is authorized to do
> so by introducing a replacement for Method 3.  Validations done under
> Method 3 will continue to be valid until the end of the data reuse period,
> but new phone based validations must use one of the new methods by the date
> specified in the ballot below.
>
>
>
> This ballot also builds on “Ballot SC13: CAA Contact Property and
> Associated E-mail Validation Methods” to permit domain owners to publish
> Domain Validation phone numbers in DNS CAA and DNS TXT records.  Since
> these phone numbers are specifically for the purpose of validating domains,
> it’s not permissible to be transferred to a different number.
>
>
>
> The following motion has been proposed by Doug Beattie of GlobalSign and
> endorsed by Bruce Morton of Entrust and Tim Hollebeek of DigiCert.
>
> --- MOTION BEGINS ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.6.2 with ballot SC13 changes:
>
>
>
> Add the following two definitions to section 1.6.1:
>
>
>
> DNS CAA Phone Contact: The phone number defined in section B.1.2.
>
>
>
> DNS TXT Record Phone Contact: The phone number defined in section B.2.2.
>
>
>
> In section 1.6.1, change the section references for the definition of “DNS
> CAA Email Contact” from B.1.2 to B.1.1.
>
>
>
> In section 1.6.1, change the section references for the definition of “DNS
> TXT Record Email Contact” from B.2.2 to B.2.1 respectively
>
>
>
> In section 3.2.2.4.3, after the end of the second paragraph add the
> following text as a new paragraph: ”CAs SHALL NOT perform validations
> using this method after July 31, 2019.  Completed validations using this
> method SHALL continue to be valid for subsequent issuance per the
> applicable certificate data reuse periods.”
>
>
>
>
>
> Add sections 3.2.2.4.15, 3.2.2.4.16, 3.2.2.4.17 as follows:
>
>
>
> 3.2.2.4.15 Phone Contact with Domain Contact
>
>
>
> Confirm the Applicant's control over the FQDN by calling the Domain
> Contact’s phone number and obtain a confirming response to validate the
> ADN. Each phone call MAY confirm control of multiple ADNs provided that the
> same Domain Contact phone number is listed for each ADN being verified and
> they provide a confirming response for each ADN.
>
>
>
> In the event that someone other than a Domain Contact is reached, the CA
> MAY request to be transferred to the Domain Contact.
>
>
>
> In the event of reaching voicemail, the CA may leave the Random Value and
> the ADN(s) being validated.  The Domain Contact may return the Random
> Number to the CA via Phone, Email, Fax, or SMS to approve the request.
>
>
>
> The Random Value SHALL remain valid for use in a confirming response for
> no more than 30 days from its creation. The CPS MAY specify a shorter
> validity period for Random Values.
>
>
>
> Note: Once the FQDN has been validated using this method, the CA MAY also
> issue Certificates for other FQDNs that end with all the labels of the
> validated FQDN.  This method is suitable for validating Wildcard Domain
> Names.
>
>
>
> 3.2.2.4.16 Phone Contact with DNS CAA Phone Contact
>
>
>
> Confirm the Applicant's control over the FQDN by calling the DNS CAA Phone
> Contact’s phone number and obtain a confirming response to validate the
> ADN. Each phone call MAY confirm control of multiple ADNs provided that the
> same DNS CAA Phone Contact phone number is listed for each ADN being
> verified and they provide a confirming response for each ADN.
>
>
>
> The CA MAY NOT be transferred or request to be transferred as this phone
> number has been specifically listed for the purposes of Domain Validation.
>
>
>
> In the event of reaching voicemail, the CA may leave the Random Value and
> the ADN(s) being validated.  The DNS CAA Phone Contact may return the
> Random Number to the CA via Phone, Email, Fax, 

Re: [cabfpub] [Servercert-wg] [Ext] Voting Begins: SC13 version 5: CAA Contact Property and Associated E-mail Validation Methods

[Ryan Sleevi via Public]

On Fri, Dec 21, 2018 at 9:12 AM Doug Beattie via Servercert-wg <
servercert...@cabforum.org> wrote:

> Rob,
>
> Is there any reason we can't submit this to the IESG now saying "we're
> planning to add a property that we think meets the requirements, and as
> soon
> as you assign an expert reviewer we will submit this to the registry"?
> It's
> unfortunate this question wasn't raised earlier,


To be fair to Rob, this issue has been raised in the past. This was
discussed in the Validation WG as far back as London [1][2] as to the order
of operations. In that plan, Tim stated his intent to do exactly what Rob
suggested, and what the process would have been - to either publish an I-D
in the IETF or as an appendix in the BRs, to discuss with IANA for Expert
Review, and then adopt as permissible within the BRs. This ballot combines
those first and third steps and skips the second.

This omission seemed deliberate and intentional, as captured in the past
discussion [3], but perhaps there was some confusion in those statements.
To be clear, though, the ordering requirement that Rob's highlighting here
did continue to come up [4], as well as commitments to engage the IANA
process.

[1]
https://cabforum.org/2018/06/06/minutes-for-ca-browser-forum-f2f-meeting-44-london-6-7-june-2018/
[2] https://cabforum.org/pipermail/validation/2018-June/000915.html
[3] https://cabforum.org/pipermail/validation/2018-July/000960.html with
the counter-point and concerns at
https://cabforum.org/pipermail/validation/2018-July/000962.html
[4] https://cabforum.org/pipermail/validation/2018-August/000990.html
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Interest in Ed25519 and/or Ed448?

[Ryan Sleevi via Public]

I believe this discussion is for the servercert-wg@ mailing list, right?

On Wed, Dec 19, 2018 at 10:22 AM Wayne Thayer via Public <
public@cabforum.org> wrote:

> Mozilla is interested in adding EdDSA support to Firefox, but we don't
> currently have the work scheduled. If someone wants to submit a patch, we'd
> be happy to consider it. The tracking bug is
> https://bugzilla.mozilla.org/show_bug.cgi?id=1325335
>
> - Wayne
>
> On Wed, Dec 19, 2018 at 4:36 AM Rob Stradling via Public <
> public@cabforum.org> wrote:
>
>> Do any of our browser members have any plans to implement support for
>> Ed25519/Ed448 public keys and certificate signatures [RFC8410]?
>>
>> Are any members seeing any demand for this yet from their customers/users?
>>
>> EdDSA has a number of advantages over ECDSA, so ISTM that the idea of
>> permitting EdDSA in the BRs/EVGs is worthy of discussion.
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> Sectigo Limited
>>
>> ___
>> Public mailing list
>> Public@cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Code Signing and SMIME Working Group Charter Drafting

[Ryan Sleevi via Public]

On Thu, Nov 29, 2018 at 5:05 PM Bruce Morton via Public 
wrote:

> Hi Ben,
>
>
>
> I thought that I would provide some input on Code Signing and hopefully it
> will be considered for the charter.
>
>
>
> The public CAs are currently working with two orphaned code signing
> certificate guidelines. Here are some issues:
>
>
>
> ·Documents are be out of date as such software suppliers, CAs,
> subscribers and relying parties are not benefiting from lessons learned or
> ecosystem updates
>
> ·Clients of software suppliers may be at higher risk than
> necessary
>
> ·Subscribers of code signing certificates are required to meet
> dated specifications which may be costly
>
> ·Cloud provision of subscriber HSM has not been addressed
>
> ·The two documents specify different requirements to address the
> same problem
>
> ·CAs that issue both OV and EV code signing certificates must
> manage two sets of controls
>
> ·CAs that issue both OV and EV will have to undergo two different
> audits in 2019
>
>
>
> It would be great if an outcome of the Working Group is one document for
> code signing certificates. I think that the one document can address both
> the EV and OV code signing certificate types, especially since many of the
> requirements are just references to the Baseline Requirements or EV SSL
> Guidelines.
>
>
>
> I would also consider creating a Time-stamp certificate document. The
> advantage is that we could set a standard for time-stamp certificate and
> time-stamp authorities to support code signing, document signing, etc.
>

I would suggest that this be out of scope of Code Signing - there are
significant differences, there exist industry standards already (within the
IETF and within ETSI), and these have different purposes: timestamping
extends beyond code-signing, as you note.


> I would be interested in helping out with the Code Signing Working Group
> charter drafting.
>

As noted, Google is very concerned that, given the confusion the market
shares around what the CA/Browser Forum is and is not, a code signing WG
may be seen as either impacting non-third-party mediated code signing, or
somehow encouraging third-party mediated code-signing as being an
improvement over first-party mediated code-signing, which it is not.

In this regard, and as discussed during the Shanghai F2F, ensuring that the
scope of any charter makes it very clear that the scope of activities, and
work product, are specifically limited to those software suppliers that
engage with third-party CAs to perform identity validation and assessment,
and to explicitly exclude from the scope, goals, and activities the broader
discussion of code-signing, including that of first-party mediated
code-signing.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Audit of RAs

[Ryan Sleevi via Public]

On Wed, Nov 7, 2018 at 1:04 PM Jeremy Rowley via Public 
wrote:

> I would like to discuss whether unaudited Delegated Third Parties are
> permitted under the BRs. My reading of the BRs (combined with what happened
> to Symantec) is that unaudited RAs are, at least mildly, frowned upon by
> the browsers. However, I think the BRs may be unclear on this point which
> is leading to an increased delegation of responsibilities to unaudited
> third parties. If there is confusion, could we pass a ballot to rule one
> way or another?
>

I think in order to get a ballot, we need to make sure we understand what
is causing people's confusion - so this will presumably require those
advocating such interpretations (whether CAs or auditors) to clarify their
positions.


> Section 8.1 – Certificates Only
>
> “Certificates that are capable of being used to issue new certificates
> MUST either be Technically Constrained in line with section 7.1.5 and
> audited in line with section 8.7 only, or Unconstrained and fully audited
> in line with all remaining requirements from this section. A Certificate is
> deemed as capable of being used to issue new certificates if it contains an
> X.509v3 basicConstraints extension, with the cA boolean set to true and is
> therefore by definition a Root CA Certificate or a Subordinate CA
> Certificate”
>
>
>
> Note that certificates all covered by the audit, not Delegated Third
> Parties. The audit for an R/A is “error: no such audit exists”.
>

So, I think framing it like this naturally leads to confusion. Let's not
speak about RAs yet - hopefully there's clear consensus that certificates
(including roots) need to be audited or technically constrained. Audited
includes all the performance of activities under the rest of the BRs.

There's nothing in here to support 'excluding' any activities. This is just
a basic statement about what's required. A CA issues certificates,
everything that causes issuance must be audited - including that of
third-parties.


> Section 8.4 – Inapplicable Audit Schemes
>
> “For Delegated Third Parties which are not Enterprise RAs,, then the CA
> SHALL obtain an audit report, issued under the auditing standards that
> underlie the accepted audit schemes found in Section 8.1, that provides an
> opinion whether the Delegated Third Party’s performance complies with
> either the Delegated Third Party’s practice statement or the CA’s
> Certificate Policy and/or Certification Practice Statement. If the opinion
> is that the Delegated Third Party does not comply, then the CA SHALL not
> allow the Delegated Third Party to continue performing delegated
> functions.”
>

>
> Again, the issue is the lack of a audit of the RA, which amounts to the CA
> giving a statement to the auditor that the RA totally complies with the CA
> policies. No real check because the auditor is only looking at the CA, not
> the RA. Also, the section refers to 8.1 which covers certificates, not
> operations or process. See the previous argument that there is no audit for
> RAs, meaning the only check on the RA is the random sample of certificates
> reviewed by the auditor.
>

This is also not a defensible interpretation. The requirement is that the
CA shall obtain an audit report, for the DTP, using the same standards as
the audit schemes from 8.1.

There's no exceptions here in this 8.4. Through the reference to 8.1, it's
also not defensible to suggest that the CA can produce the audit report
themselves; they're required to get something using the same standards.


> Section 8.7 – Overriding the Audit
>
> This is where the primary  main control and where the override comes from:
>
> Except for Delegated Third Parties that undergo an annual audit that meets
> the criteria specified in Section 8.1, the CA SHALL strictly control the
> service quality of Certificates issued or containing information verified
> by a Delegated Third Party by having a Validation Specialist employed by
> the CA perform ongoing quarterly audits against a randomly selected sample
> of at least the greater of one certificate or three percent of the
> Certificates verified by the Delegated Third Party in the period beginning
> immediately after the last sample was taken. The CA SHALL review each
> Delegated Third Party’s practices and procedures to ensure that the
> Delegated Third Party is in compliance with these Requirements and the
> relevant Certificate Policy and/or Certification Practice Statemen
>
>
>
> So there is a case where Delegated Third Parties are not audited under
> 8.1. What are these? The only thing that makes sense are RAs. This means
> the CA can take full ownership of all audit and communication to the RA as
> long as they look at 3% (and provide the certs to the auditor of they are
> included in the audit by the auditor) and review the practices and
> procedures. This places all trust in the CA to ensure these entities are
> compliance.
>

No. This is not correct either. Enterprise RAs are the only 

Re: [cabfpub] Presentation at CA Day Oct 24th 2018

[Ryan Sleevi via Public]

It should come as no surprise that we support greater transparency, so
thanks for providing these, Dimitris.

As to the role of the Forum Chair, or Chair-Elect, I think perhaps it bears
mentioning that the Forum is not an organization in-and-of-itself - it's
merely a discussion roundtable. To the extent that the Chair (or
Vice-Chair) is a position established by our 2012 bylaws, it's largely to
facilitate that adherence to our bylaws for the purposes of ensuring the IP
covenant is successfully met and protected for all participants. As your
slide notes, what ultimately matters is the root program requirements, and
the role of the Forum is to serve as a venue for discussing how to
deconflict those requirements and produce guidance that hopefully the
auditing bodies can then consider and incorporate, as a means of providing
independent evaluation for the root programs.

I mention all of this to highlight that no officer 'represents' the
CA/Browser Forum positions or thinking, since the Forum is just a loose
discussion group. Similarly, because of the lack of incorporation, we don't
have protections on or rules about the use of the CA/B Forum logo. Any
member could use it, and potentially any non-member - it's going to be up
to the copyright holder on the Logo itself (which certainly, isn't the
CA/Browser Forum, as a non-entity; does anyone recall who created it?)

I think you've set a great precedent here, which is that sharing updates
about what different participants views of the CA/Browser Forum are being
presented as, but I don't think you need to worry too much about 'speaking'
for the Forum or "its" positions - no member, including the Chair and
Vice-Chair, can really do that :)

On Thu, Oct 25, 2018 at 12:21 AM Dimitris Zacharopoulos via Public <
public@cabforum.org> wrote:

> Attached is my presentation at the CA Day that took place in Berlin
> yesterday. It was a very successful event with more than 100
> participants. My participation was as "Chair elect" since the term
> officially starts November 1st 2018.
>
> I asked previous Forum officers if there was a requirement to publish
> presentations and the answer was no. We should set at least a minimum
> expectation for officers that include the CA/B Forum logo in their
> presentations, to make such presentations publicly available at the CA/B
> Forum public list or the web site. In my understanding, previous CA Day
> presentations were available only to event participants.
>
>
> Dimitris.
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [cabfquest] [Ext] FUNDAMENTAL SSL RULE CHANGE REQUIRED

[Ryan Sleevi via Public]

On Tue, Oct 23, 2018 at 12:27 AM Geoff Keating  wrote:

> [redirecting discussion to cabfpub]
>

Geoff,

While I'm always one to appreciate public discussion, I want to highlight
that
1) A member already expressed concern with redirecting to our public list
2) Our bylaws make it clear that there's an established process - 6.2 - to
deal with questions and proposed responses, which occurs on the management
list. This was also mentioned earlier on the thread in the previous
discussion.
3) Our bylaws explicitly make it clear that these discussions happen on the
management@ list (5.1(d))
4) Our bylaws also state, in 5.1 "Members are strongly discouraged from
posting the text of Member Mail List messages to the Public Mail List
without the permission of the author or commenter."

I'm a huge proponent of transparency. I'm also a proponent of consistently
following our Bylaws, since all the transparency in the world doesn't
matter when 'simple' things aren't adhered to.

> But, the claimed reason for ballot 208 is that there is some software out
there which can't support empty subjectName and also supported only
specific subjectName fields

Specifically, it was that macOS removed support for empty subject names and
critical SANs. This is since resolved in the latest releases, and perhaps
Apple may not be concerned with supporting older versions of macOS, but not
everyone has that luxury. https://no-subject.badssl.com/ is a test site
that was established that folks can use to test interoperability across a
variety of libraries, particularly to help demonstrate the macOS behaviour
change for several releases.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Proposed Bylaws Sec. 5.3.1(f) - Default procedures for new Chartered Working Groups

[Ryan Sleevi via Public]

On Tue, Oct 16, 2018 at 2:53 AM Geoff Keating  wrote:

> Although the details do need work, I support Kirk’s approach here, which
> is that the bylaws should contain a set of default rules which describe
> everything needed to operate a working group or a subcommittee, except for
> the name and scope.  It is much better if a motion to create a working
> group can be a few lines long, and focuses on the critical details of the
> working group, rather than having to be several pages of mostly boilerplate
> copied and pasted, perhaps incorrectly, from multiple sources.
>

Yes, as I mentioned, there was consensus that such an approach is good.
However, it was also pointed out that trying to do it piecemeal is going to
keep making mistakes - like this text does - and create more work for
everyone reviewing. It's more important to do a ballot well than to do it
first, and it's more beneficial to the Forum to take the time to do the
work.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft Bylaws 5.6 - Subcommittees of the CA/Browser Forum

[Ryan Sleevi via Public]

I'm afraid this misunderstands part of the concern.

I believe we've reasonably established that you believe that "Subcommittees
of the Forum" will only talk about "safe" topics, and therefore, you're
asking for specific examples of how talking about something "safe" would be
problematic. You're failing to recognize, however, that there's nothing
guaranteeing the discussions are "safe" - that's what I was referring to as
"risk" in my prior message. It seems, based on my understanding of your
replies, that you believe there to be no "risk" because you only imagine
things to be talked about as being "safe". I'm highlighting, however, that
there's no innate guarantee around that - which is why there exist more
compelling alternatives to guarantee that, and reduce the risk of talking
about something "not safe", through the structure of the WG.

On Tue, Oct 16, 2018 at 1:47 AM Kirk Hall 
wrote:

> Can you give some specific examples of how changing the Forum’s Bylaws or
> putting up a new Forum website or wiki would raise IP issues, and require a
> Review Period by all Participants, etc.  These do not affect Guidelines,
> which is the only way that IP issues arise in the Forum.
>
>
>
> Can you provide one concrete example to help everyone understand what your
> concern is?  Maybe I will change my mind and come over to your position if
> you can provide examples.  Has Google itself done an assessment when it
> comes to Bylaws changes and the website and wiki and the IP problems that
> will result?  If so, can you share?
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Tuesday, October 16, 2018 1:23 PM
> *To:* Kirk Hall 
> *Cc:* CABFPub 
> *Subject:* [EXTERNAL]Re: [cabfpub] Draft Bylaws 5.6 - Subcommittees of
> the CA/Browser Forum
>
>
>
> On Tue, Oct 16, 2018 at 1:12 AM Kirk Hall 
> wrote:
>
> I think you are mistaken in your first point – there were several people
> who spoke in favor of keeping governance change issues at the Forum level
> in some way (e.g. an informal group Forum members working together, or a
> “Committee of the Whole” of the Forum working on these issues at the Forum
> level – like we did this morning.  So there are multiple opinions on the
> best way to move forward.
>
>
>
> I don’t understand your second question at all – what do you mean by
> “assessment” and “implications”?  It seems my draft language addresses your
> concern that this subcommittee could create IP and/or become implicated
> with the IPR Agreement – it can’t and it won’t.  As you know, when we have
> changed Bylaws in the past and updated our website and wiki, there have
> never been IP issues and never a need for IPR Agreement review.  Can you
> clarify with your own assessments and implications from simply allowing
> Subcommittees that don’t work on Guidelines?
>
>
>
> Thank you for confirming that Entrust Datacard has not evaluated or
> otherwise assessed your claim that there are no IP issues. I think it may
> have been clearer to simply state that, rather than to attempt to deflect
> it with a question.
>
>
>
> As you know, and as has been discussed, one of the ways to reduce the risk
> of potential IP issues is to limit the scope of broad Forum level
> discussions to as minimal amount as needed to function. Indeed, an ideal
> result for the Forum activities at large - to ensure there's limited risk -
> is that the only Forum activities are to vote. That is, to even limit the
> discussions involved as much as possible. Your path creates a significant
> risk for broader, Forum level discussions and brainstorming that can easily
> lead to members introducing new risks, just as members have introduced
> proposals that raise concerns about the Antitrust Statement.
>
>
>
> I can understand that some members have faith that these issues are purely
> hypothetical. Another name for pure hypotheticals is risk, and risks can be
> mitigated. It may be that you disagree on the degree of risk. That's
> perhaps not surprising, as your reply makes it clear you've not yet
> assessed that risk. Other solutions were offered that would minimize risk.
> If you don't believe there's risk, there's no harm. If you do believe
> there's risk, this can address. It seems like there are solutions that are
> win/win for everyone, and it does not seem like this is one. But then
> again, that may only be obvious once you take time to assess the risk.
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Proposed Bylaws Sec. 5.3.1(f) - Default procedures for new Chartered Working Groups

[Ryan Sleevi via Public]

Kirk,

I'm afraid that wasn't my question, nor was it a suggestion.

It sounds like you haven't done what was discussed - an evaluation of the
bylaws. I'm hoping you can make a more compelling case that these will
address the issues. One way to make such a compelling case is to highlight
"The Bylaws require CWGs specify how to address X, Y, Z in their charters.
Here are samples we can use to address Y and Z in a generic way". This was
the path discussed as a positive step forward, and it does not appear this
does it.

For example, your proposal is clearly deficient and fails to address what
was discussed - such as how the formation of subcommittees is done, which
the Bylaws call for in 5.3.1(e). This is the problem with rushing to
provide language, and ignoring the discussions on possible paths forward -
it easily leads to avoidable mistakes.

On Tue, Oct 16, 2018 at 1:50 AM Kirk Hall 
wrote:

> Good point.  We can modify my language so the default provisions in my
> proposal below would apply to new CWGs **and all subcommittees created by
> a CWG*”.  How does that sound to you?
>
>
>
> Do you have any other edits to suggest?
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Tuesday, October 16, 2018 1:46 PM
> *To:* Kirk Hall ; CABFPub <
> public@cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Proposed Bylaws Sec. 5.3.1(f) -
> Default procedures for new Chartered Working Groups
>
>
>
>
>
> Thanks for proposing this.
>
>
>
> It does not seem to address some of the other topics that were discussed,
> such as the formation of subcommittees.
>
>
>
> We left the discussion with a call to provide a methodical analysis of
> where the bylaws defer to a CWGs charter, to provide better example
> guidance. Have you done this? It might be better to start from there,
> rather than proposing ballot text immediately following such discussions,
> so that we can actually have confidence that the issues are being addressed.
>
>
>
> On Tue, Oct 16, 2018 at 1:43 AM Kirk Hall via Public 
> wrote:
>
> As we discussed this morning, we need certain “default” procedures for how
> *new* Working Groups operate, which could (in theory) be specifically
> overridden by the Forum by passing *different* procedures for a particular
> CWG in the charter of a new Chartered Working Group (CWG).
>
>
>
> It is unlikely that we would ever override these standard Bylaws
> provisions for an individual CWG charter, but it would be possible.
>
>
>
> A CWG could *also* adopt *additional* procedures for its CWG by a CWG
> ballot if it wants to, so long as the additional procedures do not conflict
> with the CWG charter and/or Bylaw Sec. 5.3.1(f).
>
>
>
> So this is a potential Forum ballot to amend the Bylaws – please comment:
>
>
>
>
>
> *Bylaws Sec. 5.3.1 - Formation of Chartered Working Groups 
>
>
>
> *(f) **Unless otherwise specifically provided in the charter of a CWG, a
> CWG shall be governed by the following rules:*
>
>
>
> 1.   *Each CWG shall have a Chair and Vice Chair who shall be elected
> by CWG members following the procedures of Bylaws Section 4.1 as closely as
> possible.  The initial term for CWG officers shall expire on November 30 of
> the next even-numbered year after the CWG is established to be synchronized
> with the terms of Forum officers.*
>
>
>
> 2.   *Proposing and voting on CWG Ballots by CWG members shall follow
> the procedures stated in Bylaws Sec. 2.3 and 2.4*.
>
>
>
> * * * * *
>
>
>
> [*Note*: Bylaws Sec. 5.2 *already* requires CWGs to post Agendas,
> Minutes, and Ballots to the Public lists – see below -  so I don’t think we
> need more default provisions on those subjects.   LWG means Legacy Working
> Group, and all Legacy Working Groups have expired.]
>
>
> Bylaws Sec. 5.2 - Public Mail List and Public Web Site [Existing language]
>
>
>
> The Chair shall appoint a List Manager who shall maintain a Public Mail
> List. Members and Interested Parties may post to the Public Mail List in
> compliance with these Bylaws. Anyone else is allowed to subscribe to and
> receive messages posted to the Public Mail List, which may be crawled and
> indexed by Internet search engines.
>
>
>
> The Chair shall appoint a Webmaster. The Webmaster shall post instructions
> on the Public Web Site for subscribing to the Public Mail List.
>
>
>
> The following materials shall be posted to the Public Mail List or Public
> Web Site:
>
>
>
> (a)Draft and final agendas for LWG and *CWG* meetings, Forum Meetings
> and Forum Teleconferences (including any sub-groups or committees).
>
> (b)Final minutes of Forum Meetings and Forum Teleconferences
> (including minutes of any sub- groups or committees), and minutes of all
> LWG and *CWG* teleconferences and meetings.
>
> (c) Messages formally proposing a Forum ballot (including ballots to
> establish, extend, modify, or terminate LWGs (as applicable) and *CWGs*),
> individual votes, vote and quorum counts, and messages announcing ballot
> outcomes and 

Re: [cabfpub] Proposed Bylaws Sec. 5.3.1(f) - Default procedures for new Chartered Working Groups

[Ryan Sleevi via Public]

Thanks for proposing this.

It does not seem to address some of the other topics that were discussed,
such as the formation of subcommittees.

We left the discussion with a call to provide a methodical analysis of
where the bylaws defer to a CWGs charter, to provide better example
guidance. Have you done this? It might be better to start from there,
rather than proposing ballot text immediately following such discussions,
so that we can actually have confidence that the issues are being addressed.

On Tue, Oct 16, 2018 at 1:43 AM Kirk Hall via Public 
wrote:

> As we discussed this morning, we need certain “default” procedures for how
> *new* Working Groups operate, which could (in theory) be specifically
> overridden by the Forum by passing *different* procedures for a particular
> CWG in the charter of a new Chartered Working Group (CWG).
>
>
>
> It is unlikely that we would ever override these standard Bylaws
> provisions for an individual CWG charter, but it would be possible.
>
>
>
> A CWG could *also* adopt *additional* procedures for its CWG by a CWG
> ballot if it wants to, so long as the additional procedures do not conflict
> with the CWG charter and/or Bylaw Sec. 5.3.1(f).
>
>
>
> So this is a potential Forum ballot to amend the Bylaws – please comment:
>
>
>
>
>
> *Bylaws Sec. 5.3.1 - Formation of Chartered Working Groups 
>
>
>
> *(f) **Unless otherwise specifically provided in the charter of a CWG, a
> CWG shall be governed by the following rules:*
>
>
>
> 1.   *Each CWG shall have a Chair and Vice Chair who shall be elected
> by CWG members following the procedures of Bylaws Section 4.1 as closely as
> possible.  The initial term for CWG officers shall expire on November 30 of
> the next even-numbered year after the CWG is established to be synchronized
> with the terms of Forum officers.*
>
>
>
> 2.   *Proposing and voting on CWG Ballots by CWG members shall follow
> the procedures stated in Bylaws Sec. 2.3 and 2.4*.
>
>
>
> * * * * *
>
>
>
> [*Note*: Bylaws Sec. 5.2 *already* requires CWGs to post Agendas,
> Minutes, and Ballots to the Public lists – see below -  so I don’t think we
> need more default provisions on those subjects.   LWG means Legacy Working
> Group, and all Legacy Working Groups have expired.]
>
>
> Bylaws Sec. 5.2 - Public Mail List and Public Web Site [Existing language]
>
>
>
> The Chair shall appoint a List Manager who shall maintain a Public Mail
> List. Members and Interested Parties may post to the Public Mail List in
> compliance with these Bylaws. Anyone else is allowed to subscribe to and
> receive messages posted to the Public Mail List, which may be crawled and
> indexed by Internet search engines.
>
>
>
> The Chair shall appoint a Webmaster. The Webmaster shall post instructions
> on the Public Web Site for subscribing to the Public Mail List.
>
>
>
> The following materials shall be posted to the Public Mail List or Public
> Web Site:
>
>
>
> (a)Draft and final agendas for LWG and *CWG* meetings, Forum Meetings
> and Forum Teleconferences (including any sub-groups or committees).
>
> (b)Final minutes of Forum Meetings and Forum Teleconferences
> (including minutes of any sub- groups or committees), and minutes of all
> LWG and *CWG* teleconferences and meetings.
>
> (c) Messages formally proposing a Forum ballot (including ballots to
> establish, extend, modify, or terminate LWGs (as applicable) and *CWGs*),
> individual votes, vote and quorum counts, and messages announcing ballot
> outcomes and voting breakdowns.
>
> (d)Initial and final drafts of Forum requirements, guidelines, and
> recommendations after the drafter has had an opportunity to receive and
> respond to initial Member comments.
>
> (e)Initial and final drafts of *CWG* charter documents, guidelines,
> and recommendations after the drafter has had an opportunity to receive and
> respond to initial Working Group member comments.
>
>
>
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Bylaws 5.6 - Subcommittees of the CA/Browser Forum

[Ryan Sleevi via Public]

On Tue, Oct 16, 2018 at 1:12 AM Kirk Hall 
wrote:

> I think you are mistaken in your first point – there were several people
> who spoke in favor of keeping governance change issues at the Forum level
> in some way (e.g. an informal group Forum members working together, or a
> “Committee of the Whole” of the Forum working on these issues at the Forum
> level – like we did this morning.  So there are multiple opinions on the
> best way to move forward.
>
>
>
> I don’t understand your second question at all – what do you mean by
> “assessment” and “implications”?  It seems my draft language addresses your
> concern that this subcommittee could create IP and/or become implicated
> with the IPR Agreement – it can’t and it won’t.  As you know, when we have
> changed Bylaws in the past and updated our website and wiki, there have
> never been IP issues and never a need for IPR Agreement review.  Can you
> clarify with your own assessments and implications from simply allowing
> Subcommittees that don’t work on Guidelines?
>

Thank you for confirming that Entrust Datacard has not evaluated or
otherwise assessed your claim that there are no IP issues. I think it may
have been clearer to simply state that, rather than to attempt to deflect
it with a question.

As you know, and as has been discussed, one of the ways to reduce the risk
of potential IP issues is to limit the scope of broad Forum level
discussions to as minimal amount as needed to function. Indeed, an ideal
result for the Forum activities at large - to ensure there's limited risk -
is that the only Forum activities are to vote. That is, to even limit the
discussions involved as much as possible. Your path creates a significant
risk for broader, Forum level discussions and brainstorming that can easily
lead to members introducing new risks, just as members have introduced
proposals that raise concerns about the Antitrust Statement.

I can understand that some members have faith that these issues are purely
hypothetical. Another name for pure hypotheticals is risk, and risks can be
mitigated. It may be that you disagree on the degree of risk. That's
perhaps not surprising, as your reply makes it clear you've not yet
assessed that risk. Other solutions were offered that would minimize risk.
If you don't believe there's risk, there's no harm. If you do believe
there's risk, this can address. It seems like there are solutions that are
win/win for everyone, and it does not seem like this is one. But then
again, that may only be obvious once you take time to assess the risk.

>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Bylaws 5.6 - Subcommittees of the CA/Browser Forum

[Ryan Sleevi via Public]

On Mon, Oct 15, 2018 at 11:45 PM Kirk Hall via Public 
wrote:

> Here is a possible amendment to the Bylaws that would allow us to create
> Subcommittees of the Forum, and would require the same transparency as is
> required today for the Forum.
>
>
>
> This Bylaws change could be passed by a Forum ballot in as little as two
> weeks.  We could then have a second ballot to create a Governance
> Subcommittee of the Forum.  No IP issues are involved, so there is no
> requirement of IPR Review.
>

Thank you for your suggestion. It certainly is one approach that can take,
and it seems one that does not incorporate any of the feedback that members
have offered, but it certainly provides a path forward.

Can you help explain what assessment Entrust Datacard has done on the
provided language and its implications? And what other members you've
consulted, to lead to the confidence that there are no IP issues involved?
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Updated F2F Agenda

[Ryan Sleevi via Public]

Thank you for clarifying that your position.

Considering that it is a prepared presentation, with slides, that
necessarily examines the history of audits so that we can understand "what
was meant", it is appropriate both in chronological order and in the level
of detail to place those sections after.

I'm disappointed that, as Chair, you took a request for a session, and due
to your own interpretation, attempted to segment, reassign, and reorder it
from what was requested. Considering that you have not done that to any
other member or presentation - indeed, no other session on the schedule has
required such discussion or such difficulty - this is an unfortunate
standard being set that does not seem consistent with the expectations of
the Chair.

Considering now that I've suggested the ordering is "past", "present", and
"future", and you've suggested that 23 and 24 are "present", I hope you can
understand why it makes far more valuable use of time to reorder, and I
look forward to you accommodating that.

On Wed, Oct 10, 2018 at 11:10 AM Kirk Hall 
wrote:

> I have checked with the presenters for 23 and 24, and they don’t agree
> with you.  I don’t agree with you either.
>
>
>
> Can you explain your thinking?  Segments 23 and 24 are simply 15 minute
> refresher courses for the members on what the **current** range of audit
> reports are, and are intended to help members understand your segment and
> Wayne’s which will follow.  I can’t understand how the 15 minute refresher
> courses would be useful **after** you finish your 90 minutes segment and
> Wayne finishes his 90 minute segment on current audit issues and proposals
> for change.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Wednesday, October 10, 2018 12:38 AM
> *To:* Kirk Hall ; CABFPub <
> public@cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Updated F2F Agenda
>
>
>
> Kirk,
>
>
>
> I would again like to request that you reschedule 23 and 24 after 25, as
> originally, and now repeatedly requested, so that it might be most valuable
> for all participants. It has been rather unfortunate the level of
> difficulty that has been added - in obtaining an agenda slot, as originally
> requested, prior to such updates. I had thought it was a reasonable and
> simple request, so I'm rather surprised at the difficulty it has involved.
>
>
>
>
>
> On Tue, Oct 9, 2018 at 7:59 PM Kirk Hall via Public 
> wrote:
>
> Based on various suggestions, I have updated the Agenda for the Shanghai
> meetings – see below.  Please let me know if you have additional requests.
> Tuesday, 16 October 2018 - Working Group and Subcommittee Meetings
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> 9:15
>
> Welcome, Preliminary Matters, Logistics, Antitrust Statement
>
> Yi, Kirk
>
> 9:15
>
> 10:15
>
> 1
>
> Forum Infrastructure Working Group Meeting
>
> Jos
>
> 10:15
>
> 10:30
>
> Break
>
> 10:30
>
> 12:00
>
> 2
>
> Forum Committee of the Whole: Governance and Bylaws Issues Pre-meeting (1)
> Governance WG or Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 12:00
>
> 12:45
>
> Lunch
>
> 12:45
>
> 14:00
>
> 3
>
> SCWG Network Security Subcommittee
>
> Ben
>
> 14:00
>
> 14:15
>
> Break
>
> 14:15
>
> 16:15
>
> 4
>
> SCWG Validation Subcommittee
>
> Tim
>
> 16:15
>
> Adjourn
>   Wednesday, 17 October 2018 - Plenary Meeting (Day 1)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Call to Order and Welcome - CA/Browser Forum Plenary Meeting*
>
> Kirk, Yi
>
> 9:00
>
> 9:14
>
> Welcome, Recap of Preliminary Matters, Logistics, Antitrust Statement,
> Assign Minute Taking
>
> Yi, Kirk
>
> 9:14
>
> 9:15
>
> 1A
>
> Approval of CABF Minutes from Oct. 4 call (emailed Oct. 5)
>
> Kirk
>
> 9:15
>
> 9:30
>
> 1B
>
> Report from Forum Infrastructure Working Group
>
> Jos
>
> 9:30
>
> 9:45
>
> 2
>
> Report on Governance Change, Bylaws Issues: (1) Governance WG or
> Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 9:45
>
> 10:00
>
> 3
>
> Potential Amendments to SCWG Charter
>
> Dimitris, Tim
>
> 10:00
>
> 10:30
>
> 4
>
> Creation of additional Working Groups - Code Signing
>
> Ben
>
> 10:30
>
> 10:45
>
> Break
>
> 10:45
>
> 11:15
>
> 5
>
> Creation of additional Working Groups - Secure Mail; Other
>
> Ben
>
> 11:15
>
> Adjourn CA/Browser Plenary Meeting
>
> Kirk
>
> 11:15
>
> *Call to Order - Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 11:15
>
> 11:19
>
> Assign Minute Taking
>
> Kirk
>
> 11:19
>
> 11:20
>
> 6A
>
> Approval of SCWG Minutes from Oct. 4 call (emailed Oct. 5)
>
> Kirk
>
> 11:20
>
> 11:25
>
> 6B
>
> Opera Root Program Update
>
> Tomasz
>
> 11:25
>
> 11:45
>
> 7
>
> Mozilla Root Program Update
>
> Wayne
>
> 11:45
>
> 12:05
>
> 8
>
> Microsoft Root Program Update

Re: [cabfpub] Updated F2F Agenda

[Ryan Sleevi via Public]

Kirk,

I would again like to request that you reschedule 23 and 24 after 25, as
originally, and now repeatedly requested, so that it might be most valuable
for all participants. It has been rather unfortunate the level of
difficulty that has been added - in obtaining an agenda slot, as originally
requested, prior to such updates. I had thought it was a reasonable and
simple request, so I'm rather surprised at the difficulty it has involved.


On Tue, Oct 9, 2018 at 7:59 PM Kirk Hall via Public 
wrote:

> Based on various suggestions, I have updated the Agenda for the Shanghai
> meetings – see below.  Please let me know if you have additional requests.
>
> Tuesday, 16 October 2018 - Working Group and Subcommittee Meetings
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> 9:15
>
> Welcome, Preliminary Matters, Logistics, Antitrust Statement
>
> Yi, Kirk
>
> 9:15
>
> 10:15
>
> 1
>
> Forum Infrastructure Working Group Meeting
>
> Jos
>
> 10:15
>
> 10:30
>
> Break
>
> 10:30
>
> 12:00
>
> 2
>
> Forum Committee of the Whole: Governance and Bylaws Issues Pre-meeting (1)
> Governance WG or Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 12:00
>
> 12:45
>
> Lunch
>
> 12:45
>
> 14:00
>
> 3
>
> SCWG Network Security Subcommittee
>
> Ben
>
> 14:00
>
> 14:15
>
> Break
>
> 14:15
>
> 16:15
>
> 4
>
> SCWG Validation Subcommittee
>
> Tim
>
> 16:15
>
> Adjourn
>   Wednesday, 17 October 2018 - Plenary Meeting (Day 1)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Call to Order and Welcome - CA/Browser Forum Plenary Meeting*
>
> Kirk, Yi
>
> 9:00
>
> 9:14
>
> Welcome, Recap of Preliminary Matters, Logistics, Antitrust Statement,
> Assign Minute Taking
>
> Yi, Kirk
>
> 9:14
>
> 9:15
>
> 1A
>
> Approval of CABF Minutes from Oct. 4 call (emailed Oct. 5)
>
> Kirk
>
> 9:15
>
> 9:30
>
> 1B
>
> Report from Forum Infrastructure Working Group
>
> Jos
>
> 9:30
>
> 9:45
>
> 2
>
> Report on Governance Change, Bylaws Issues: (1) Governance WG or
> Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 9:45
>
> 10:00
>
> 3
>
> Potential Amendments to SCWG Charter
>
> Dimitris, Tim
>
> 10:00
>
> 10:30
>
> 4
>
> Creation of additional Working Groups - Code Signing
>
> Ben
>
> 10:30
>
> 10:45
>
> Break
>
> 10:45
>
> 11:15
>
> 5
>
> Creation of additional Working Groups - Secure Mail; Other
>
> Ben
>
> 11:15
>
> Adjourn CA/Browser Plenary Meeting
>
> Kirk
>
> 11:15
>
> *Call to Order - Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 11:15
>
> 11:19
>
> Assign Minute Taking
>
> Kirk
>
> 11:19
>
> 11:20
>
> 6A
>
> Approval of SCWG Minutes from Oct. 4 call (emailed Oct. 5)
>
> Kirk
>
> 11:20
>
> 11:25
>
> 6B
>
> Opera Root Program Update
>
> Tomasz
>
> 11:25
>
> 11:45
>
> 7
>
> Mozilla Root Program Update
>
> Wayne
>
> 11:45
>
> 12:05
>
> 8
>
> Microsoft Root Program Update
>
> Mike
>
> 12:05
>
> 12:50
>
> Lunch
>
> 12:50
>
> 13:10
>
> 9
>
> Speaker: International Adoption of Chinese Cryptography Algorithms - The
> Implementation and Standardization Progress
>
> Paul Yang, BaishanCloud/OpenSSL
>
> 13:10
>
> 13:30
>
> 10
>
> Speaker: [Algorithms related topic]
>
> [TBD]
>
> 13:30
>
> 13:50
>
> 11
>
> Google Root Program Update
>
> Ryan
>
> 13:50
>
> 14:10
>
> 12
>
> Cisco Systems Root Program Update
>
> J.P.
>
> 14:10
>
> 14:30
>
> 13
>
> Apple Root Program Update
>
> Geoff
>
> 14:30
>
> 14:50
>
> 14
>
> 360 Root Program Update
>
> Iñigo
>
> 14:50
>
> 15:10
>
> 15
>
> ETSI Update
>
> Arno, Phillipe
>
> 15:10
>
> 15:25
>
> Break
>
> 15:25
>
> 15:55
>
> 16
>
> WebTrust Update
>
> Jeff, Don
>
> 15:55
>
> 16:10
>
> 17
>
> Report from SCWG Validation Subcommittee
>
> Tim
>
> 16:10
>
> 16:40
>
> 18
>
> Improving validation for identity certificates
>
> Tim
>
> 16:40
>
> 16:50
>
> Announcements, Evening Social Event
>
> Kirk, Yi
>
> 16:50
>
> Adjourn and take *Group Photo*
>   Thursday, 18 October 2018 - Plenary Meeting (Day 2)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Continuation of Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 9:00
>
> 9:15
>
> Recap of Preliminary Matters, Logistics, Antitrust Statement, Assign
> Minute Taking
>
> Yi, Kirk
>
> 9:15
>
> 9:45
>
> 19
>
> Report from SCWG Network Security Subcommittee
>
> Ben
>
> 9:45
>
> 10:15
>
> 20
>
> Update on London Protocol
>
> Chris
>
> 10:15
>
> 10:30
>
> Break
>
> 10:30
>
> 11:00
>
> 21
>
> Report on Name Clash Service
>
> Daymion
>
> 11:00
>
> 11:30
>
> 22
>
> Potential changes to server certificate issuance processes for increased
> transparency
>
> Daymion
>
> 11:30
>
> *Discussion of Audit Terminology, Problems, Ideal Life Cycle for Root CA
> 

Re: [cabfpub] Revised draft F2F Agenda for Shanghai meeting

[Ryan Sleevi via Public]

Thanks Kirk.

While I still express my disagreement with your conclusions and your
scheduling, it's also clear that there's no room to improve the dialog here
or in Shanghai.

On Mon, Oct 1, 2018 at 3:46 PM Kirk Hall 
wrote:

> Thanks for the explanation – that helps, and offers more details than were
> previously available.
>
>
>
> The auditors’ 15-minute “refresher” preparations will work very well
> before your presentation and Wayne’s presentation (which are 90 minutes
> each) to make your presentations more meaningful and understandable to the
> members.  The auditor presentations will be prepared in advance, meaning it
> won’t be possible for them to rewrite them after hearing your presentation
> and Wayne’s.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Monday, October 1, 2018 12:32 PM
> *To:* Kirk Hall 
> *Cc:* CABFPub 
> *Subject:* [EXTERNAL]Re: [cabfpub] Revised draft F2F Agenda for Shanghai
> meeting
>
>
>
> I'm not sure I understand that question - I've offered several
> explanations on the list and the call. Perhaps the confusion is coming from
> the conflicting approaches from what was requested to how it'd been
> originally scheduled.
>
>
>
> I'm not sure when you've spoken with the auditor representatives, but
> given that they're active on the list, perhaps it might be a good chance to
> hear from them first hand. I've had conversations with both WebTrust and
> ETSI folks in the past week as well regarding the topic, so perhaps you're
> working on outdated information? In any event, having them chime in
> directly can help resolve issues better than indirectly, especially when we
> know some of the messaging was lost previously.
>
>
>
> As I've offered several times now, on the call and the list, the goal is
> to examine our current state of audits - by exploring how we got here, the
> objectives that browsers have with audits, the similarities and differences
> that the two approaches take in terms of assessment, reporting, and auditor
> qualifications, and arriving at an interoperable set of understanding,
> vocabulary, and expectations reflecting this. Because it is intended to be
> a breadth survey, and because its value is driven by taking a holistic look
> at these two approaches rather than our traditional depth-first exercises,
> it's necessary to treat this holistically as a single presentation.
> Following the presentation, I think there will be ample room for discussion
> to make sure that there is a collective understanding and agreement about
> the artifacts produced and their suitability for various purposes (whether
> regulatory, for inclusion in browser programs, or for membership
> recognition).
>
>
>
> Wayne's examination that follows then maps these various artifacts, as
> best as possible, to the browser inclusion process and timeline, with the
> goal of providing greater clarity of expectations in a way that harmonizes
> across both programs.
>
>
>
> This is why I think the auditor presentations having the opportunity to
> follow will greatly benefit their reception and their discussion - by
> having arrived at a common vocabulary that works for all of the various
> constituencies, and a common understanding of goals and expectations,
> taking a depth-first examination of the present and future auditor
> offerings will help map onto the discussions that precede or to call out
> differences that are more minute than the broad stroke approach. It will no
> doubt also help further understanding about the pending changes and their
> significance - the contextualization of, say, WebTrust for RAs or the work
> on TS 119 403-2 and 403-3.
>
>
>
> On Mon, Oct 1, 2018 at 3:04 PM Kirk Hall 
> wrote:
>
> Actually, the auditor representatives asked me what your presentation
> “Discussion of current state of audits and membership requirements” will
> cover, and I said I didn’t know.
>
>
>
> Do you have any more details?  Is this a lecture-style presentation, or
> will this be an interactive presentation where the auditor reps can offer
> their responses and suggestions?  It may be most useful to get feedback
> from the auditor reps on specific issues as we go along.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Monday, October 1, 2018 11:11 AM
> *To:* Kirk Hall 
> *Cc:* CABFPub 
> *Subject:* [EXTERNAL]Re: [cabfpub] Revised draft F2F Agenda for Shanghai
> meeting
>
>
>
> Thanks for clarifying.
>
>
>
> That's unfortunate, because having the time following would provide a lot
> more flexibility for the representatives to adjust their conversations to
> the discussion topics and questions raised, providing greater clarity and
> direction. Presuming the presentations are similar in content and structure
> to our past F2F, as they have been, will leave a lot of missed opportunity
> for clarity on the table.
>
>
>
> On Mon, Oct 1, 2018 at 1:52 PM Kirk Hall 
> wrote:
>
> I checked with the WebTrust and ETSI reps, and they don’t think it would
> be a 

Re: [cabfpub] Revised draft F2F Agenda for Shanghai meeting

[Ryan Sleevi via Public]

I'm not sure I understand that question - I've offered several explanations
on the list and the call. Perhaps the confusion is coming from the
conflicting approaches from what was requested to how it'd been originally
scheduled.

I'm not sure when you've spoken with the auditor representatives, but given
that they're active on the list, perhaps it might be a good chance to hear
from them first hand. I've had conversations with both WebTrust and ETSI
folks in the past week as well regarding the topic, so perhaps you're
working on outdated information? In any event, having them chime in
directly can help resolve issues better than indirectly, especially when we
know some of the messaging was lost previously.

As I've offered several times now, on the call and the list, the goal is to
examine our current state of audits - by exploring how we got here, the
objectives that browsers have with audits, the similarities and differences
that the two approaches take in terms of assessment, reporting, and auditor
qualifications, and arriving at an interoperable set of understanding,
vocabulary, and expectations reflecting this. Because it is intended to be
a breadth survey, and because its value is driven by taking a holistic look
at these two approaches rather than our traditional depth-first exercises,
it's necessary to treat this holistically as a single presentation.
Following the presentation, I think there will be ample room for discussion
to make sure that there is a collective understanding and agreement about
the artifacts produced and their suitability for various purposes (whether
regulatory, for inclusion in browser programs, or for membership
recognition).

Wayne's examination that follows then maps these various artifacts, as best
as possible, to the browser inclusion process and timeline, with the goal
of providing greater clarity of expectations in a way that harmonizes
across both programs.

This is why I think the auditor presentations having the opportunity to
follow will greatly benefit their reception and their discussion - by
having arrived at a common vocabulary that works for all of the various
constituencies, and a common understanding of goals and expectations,
taking a depth-first examination of the present and future auditor
offerings will help map onto the discussions that precede or to call out
differences that are more minute than the broad stroke approach. It will no
doubt also help further understanding about the pending changes and their
significance - the contextualization of, say, WebTrust for RAs or the work
on TS 119 403-2 and 403-3.

On Mon, Oct 1, 2018 at 3:04 PM Kirk Hall 
wrote:

> Actually, the auditor representatives asked me what your presentation 
> “Discussion
> of current state of audits and membership requirements” will cover, and I
> said I didn’t know.
>
>
>
> Do you have any more details?  Is this a lecture-style presentation, or
> will this be an interactive presentation where the auditor reps can offer
> their responses and suggestions?  It may be most useful to get feedback
> from the auditor reps on specific issues as we go along.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Monday, October 1, 2018 11:11 AM
> *To:* Kirk Hall 
> *Cc:* CABFPub 
> *Subject:* [EXTERNAL]Re: [cabfpub] Revised draft F2F Agenda for Shanghai
> meeting
>
>
>
> Thanks for clarifying.
>
>
>
> That's unfortunate, because having the time following would provide a lot
> more flexibility for the representatives to adjust their conversations to
> the discussion topics and questions raised, providing greater clarity and
> direction. Presuming the presentations are similar in content and structure
> to our past F2F, as they have been, will leave a lot of missed opportunity
> for clarity on the table.
>
>
>
> On Mon, Oct 1, 2018 at 1:52 PM Kirk Hall 
> wrote:
>
> I checked with the WebTrust and ETSI reps, and they don’t think it would
> be a good idea to move their 15 minute “refresher” course presentations to
> time slots after the presentations by you and Wayne – their purpose in
> doing a refresher presentation on existing WebTrust and ETSI reports is to
> help the Members get more out of the following presentations from you and
> Wayne.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Sunday, September 30, 2018 5:50 PM
> *To:* Kirk Hall ; CABFPub <
> public@cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Revised draft F2F Agenda for Shanghai
> meeting
>
>
>
> On Fri, Sep 28, 2018 at 9:20 PM Kirk Hall via Public 
> wrote:
>
> Here is an updated Agenda for the Shanghai F2F meeting in just over two
> weeks.  The draft is based on time requests from different discussion
> leaders, and as you see the meeting runs too long on Thursday.  I am going
> to check with discussion leaders to see if they really need all the time
> they have requested, and will likely make adjustments to this draft.
>
>
>
> If you have suggestions or requests, please let me know.
>
>
> 

Re: [cabfpub] Revised draft F2F Agenda for Shanghai meeting

[Ryan Sleevi via Public]

Thanks for clarifying.

That's unfortunate, because having the time following would provide a lot
more flexibility for the representatives to adjust their conversations to
the discussion topics and questions raised, providing greater clarity and
direction. Presuming the presentations are similar in content and structure
to our past F2F, as they have been, will leave a lot of missed opportunity
for clarity on the table.

On Mon, Oct 1, 2018 at 1:52 PM Kirk Hall 
wrote:

> I checked with the WebTrust and ETSI reps, and they don’t think it would
> be a good idea to move their 15 minute “refresher” course presentations to
> time slots after the presentations by you and Wayne – their purpose in
> doing a refresher presentation on existing WebTrust and ETSI reports is to
> help the Members get more out of the following presentations from you and
> Wayne.
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Sunday, September 30, 2018 5:50 PM
> *To:* Kirk Hall ; CABFPub <
> public@cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabfpub] Revised draft F2F Agenda for Shanghai
> meeting
>
>
>
> On Fri, Sep 28, 2018 at 9:20 PM Kirk Hall via Public 
> wrote:
>
> Here is an updated Agenda for the Shanghai F2F meeting in just over two
> weeks.  The draft is based on time requests from different discussion
> leaders, and as you see the meeting runs too long on Thursday.  I am going
> to check with discussion leaders to see if they really need all the time
> they have requested, and will likely make adjustments to this draft.
>
>
>
> If you have suggestions or requests, please let me know.
>
>
> Tuesday, 16 October 2018 - Working Group and Subcommittee Meetings
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> 9:15
>
> Welcome, Preliminary Matters, Logistics, Antitrust Statement
>
> Yi, Kirk
>
> 9:15
>
> 10:15
>
> 1
>
> Forum Infrastructure Working Group Meeting
>
> Jos
>
> 10:15
>
> 10:35
>
> Break
>
> 10:35
>
> 12:00
>
> 2
>
> Forum Committee of the Whole: Governance and Bylaws Issues Pre-meeting (1)
> Governance WG or Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 12:00
>
> 12:45
>
> Lunch
>
> 12:45
>
> 14:15
>
> 3
>
> SCWG Network Security Subcommittee
>
> Ben
>
> 14:15
>
> 14:35
>
> Break
>
> 14:35
>
> 16:35
>
> 4
>
> SCWG Validation Subcommittee
>
> Tim
>
> 16:35
>
> Adjourn
> Wednesday, 17 October 2018 - Plenary Meeting (Day 1)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Call to Order and Welcome - CA/Browser Forum Plenary Meeting*
>
> Kirk, Yi
>
> 9:00
>
> 9:15
>
> Recap of Preliminary Matters, Logistics, Antitrust Statement, Assign
> Minute Taking
>
> Yi, Kirk
>
> 9:15
>
> 9:30
>
> 1
>
> Report from Forum Infrastructure Working Group
>
> Jos
>
> 9:30
>
> 9:50
>
> 2
>
> Report on Governance Change, Bylaws Issues: (1) Governance WG or
> Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 9:50
>
> 10:05
>
> 3
>
> Potential Amendments to SCWG Charter
>
> Dimitris, Tim
>
> 10:05
>
> 10:35
>
> 4
>
> Creation of additional Working Groups - Code Signing
>
> Ben
>
> 10:35
>
> 10:50
>
> Break
>
> 10:50
>
> 11:20
>
> 5
>
> Creation of additional Working Groups - Secure Mail; Other
>
> Ben
>
> 11:20
>
> 11:30
>
> 6
>
> Pending Forum Ballots
>
> Kirk
>
> 11:30
>
> Adjourn CA/Browser Plenary Meeting
>
> Kirk
>
> 11:30
>
> *Call to Order - Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 11:30
>
> 11:35
>
> Assign Minute Taking
>
> Kirk
>
> 11:35
>
> 11:55
>
> 7
>
> Opera Root Program Update
>
> Tomasz
>
> 11:55
>
> 12:15
>
> 8
>
> Mozilla Root Program Update
>
> Wayne
>
> 12:15
>
> 12:45
>
> Lunch
>
> 12:45
>
> 13:05
>
> 9
>
> Microsoft Root Program Update
>
> Mike
>
> 13:05
>
> 13:25
>
> 10
>
> Google Root Program Update
>
> Ryan
>
> 13:25
>
> 13:45
>
> 11
>
> Cisco Systems Root Program Update
>
> J.P.
>
> 13:45
>
> 14:05
>
> 12
>
> Apple Root Program Update
>
> Geoff
>
> 14:05
>
> 14:25
>
> 13
>
> 360 Root Program Update
>
> Iñigo
>
> 14:25
>
> 14:55
>
> 14
>
> WebTrust Update
>
> Jeff
>
> 14:55
>
> 15:15
>
> Break
>
> 15:15
>
> 15:45
>
> 15
>
> ETSI Update
>
> Arno, Phillipe
>
> 15:45
>
> 16:00
>
> 16
>
> Report from SCWG Validation Subcommittee
>
> Tim
>
> 16:00
>
> 16:30
>
> 17
>
> Improving validation for identity certificates
>
> Tim
>
> 16:30
>
> 16:40
>
> Announcements, Evening Social Event
>
> Kirk, Yi
>
> 16:40
>
> Adjourn
>
> Evening: Group Social Event -- details to be provided later
> Thursday, 18 October 2018 - Plenary Meeting (Day 2)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Continuation of Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 9:00
>
> 9:15
>
> 

Re: [cabfpub] Revised draft F2F Agenda for Shanghai meeting

[Ryan Sleevi via Public]

On Fri, Sep 28, 2018 at 9:20 PM Kirk Hall via Public 
wrote:

> Here is an updated Agenda for the Shanghai F2F meeting in just over two
> weeks.  The draft is based on time requests from different discussion
> leaders, and as you see the meeting runs too long on Thursday.  I am going
> to check with discussion leaders to see if they really need all the time
> they have requested, and will likely make adjustments to this draft.
>
>
>
> If you have suggestions or requests, please let me know.
>
>
> Tuesday, 16 October 2018 - Working Group and Subcommittee Meetings
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> 9:15
>
> Welcome, Preliminary Matters, Logistics, Antitrust Statement
>
> Yi, Kirk
>
> 9:15
>
> 10:15
>
> 1
>
> Forum Infrastructure Working Group Meeting
>
> Jos
>
> 10:15
>
> 10:35
>
> Break
>
> 10:35
>
> 12:00
>
> 2
>
> Forum Committee of the Whole: Governance and Bylaws Issues Pre-meeting (1)
> Governance WG or Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 12:00
>
> 12:45
>
> Lunch
>
> 12:45
>
> 14:15
>
> 3
>
> SCWG Network Security Subcommittee
>
> Ben
>
> 14:15
>
> 14:35
>
> Break
>
> 14:35
>
> 16:35
>
> 4
>
> SCWG Validation Subcommittee
>
> Tim
>
> 16:35
>
> Adjourn
> Wednesday, 17 October 2018 - Plenary Meeting (Day 1)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Call to Order and Welcome - CA/Browser Forum Plenary Meeting*
>
> Kirk, Yi
>
> 9:00
>
> 9:15
>
> Recap of Preliminary Matters, Logistics, Antitrust Statement, Assign
> Minute Taking
>
> Yi, Kirk
>
> 9:15
>
> 9:30
>
> 1
>
> Report from Forum Infrastructure Working Group
>
> Jos
>
> 9:30
>
> 9:50
>
> 2
>
> Report on Governance Change, Bylaws Issues: (1) Governance WG or
> Subcommittee, (2) Review Bylaws Change List
>
> Ben, Jos, Dimitris
>
> 9:50
>
> 10:05
>
> 3
>
> Potential Amendments to SCWG Charter
>
> Dimitris, Tim
>
> 10:05
>
> 10:35
>
> 4
>
> Creation of additional Working Groups - Code Signing
>
> Ben
>
> 10:35
>
> 10:50
>
> Break
>
> 10:50
>
> 11:20
>
> 5
>
> Creation of additional Working Groups - Secure Mail; Other
>
> Ben
>
> 11:20
>
> 11:30
>
> 6
>
> Pending Forum Ballots
>
> Kirk
>
> 11:30
>
> Adjourn CA/Browser Plenary Meeting
>
> Kirk
>
> 11:30
>
> *Call to Order - Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 11:30
>
> 11:35
>
> Assign Minute Taking
>
> Kirk
>
> 11:35
>
> 11:55
>
> 7
>
> Opera Root Program Update
>
> Tomasz
>
> 11:55
>
> 12:15
>
> 8
>
> Mozilla Root Program Update
>
> Wayne
>
> 12:15
>
> 12:45
>
> Lunch
>
> 12:45
>
> 13:05
>
> 9
>
> Microsoft Root Program Update
>
> Mike
>
> 13:05
>
> 13:25
>
> 10
>
> Google Root Program Update
>
> Ryan
>
> 13:25
>
> 13:45
>
> 11
>
> Cisco Systems Root Program Update
>
> J.P.
>
> 13:45
>
> 14:05
>
> 12
>
> Apple Root Program Update
>
> Geoff
>
> 14:05
>
> 14:25
>
> 13
>
> 360 Root Program Update
>
> Iñigo
>
> 14:25
>
> 14:55
>
> 14
>
> WebTrust Update
>
> Jeff
>
> 14:55
>
> 15:15
>
> Break
>
> 15:15
>
> 15:45
>
> 15
>
> ETSI Update
>
> Arno, Phillipe
>
> 15:45
>
> 16:00
>
> 16
>
> Report from SCWG Validation Subcommittee
>
> Tim
>
> 16:00
>
> 16:30
>
> 17
>
> Improving validation for identity certificates
>
> Tim
>
> 16:30
>
> 16:40
>
> Announcements, Evening Social Event
>
> Kirk, Yi
>
> 16:40
>
> Adjourn
>
> Evening: Group Social Event -- details to be provided later
> Thursday, 18 October 2018 - Plenary Meeting (Day 2)
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Discussion Leader / Notes
>
> 8:00
>
> 9:00
>
> Meeting room open
>
> 8:30
>
> 9:00
>
> Breakfast - Continental
>
> 9:00
>
> *Continuation of Server Certificate Working Group Plenary Meeting*
>
> Kirk
>
> 9:00
>
> 9:15
>
> Recap of Preliminary Matters, Logistics, Antitrust Statement, Assign
> Minute Taking
>
> Yi, Kirk
>
> 9:15
>
> 10:15
>
> 18
>
> Report from SCWG Network Security Subcommittee
>
> Ben
>
> 10:15
>
> 10:35
>
> Break
>
> 10:35
>
> 10:55
>
> 19
>
> Report from SCWG Network Security Subcommittee (continued)
>
> Ben
>
> 10:55
>
> 11:25
>
> 20
>
> Update on London Protocol
>
> Chris
>
> 11:25
>
> 12:25
>
> 21
>
> Report on Name Clash Service
>
> Daymion
>
> 12:25
>
> 12:55
>
> Lunch
>
> 12:55
>
> 13:55
>
> 22
>
> Potential changes to server certificate issuance processes for increased
> transparency
>
> Daymion
>
> 13:55
>
> *Discussion of Audit Terminology, Problems, Ideal Life Cycle for Root CA
> Audits*
>
> 13:55
>
> 14:10
>
> 23
>
> (a) Types of audits/reports under WebTrust
>  and their terminology
>
> Jeff, Don
>
> 14:10
>
> 14:25
>
> 24
>
> (b) Types of audits/reports under ETSI and their terminology
>
> Arno, Clemens, Phillipe
>
> 14:25
>
> 15:15
>
> 25
>
> (c) Discussion of current state of audits and membership requirements
>
> Ryan
>
> 15:15
>
> 15:30

Re: [cabfpub] Validation Method 10

[Ryan Sleevi via Public]

I would actually make a more specific request:

If you use Method 10 for anything other than exactly
https://tools.ietf.org/html/draft-ietf-acme-tls-alpn as specified, please
speak up. If you use https://tools.ietf.org/html/draft-ietf-acme-tls-alpn ,
please specify what draft revision of that document you use. If you use
that method with a whitelist, please speak up.

On Thu, Sep 27, 2018 at 11:54 AM Tim Hollebeek via Public <
public@cabforum.org> wrote:

>
>
> The Validation WG is going to work on tightening up method 10.  TLS ALPN
> currently uses that method, as well as the deprecated TLS SNI method.  If
> any CAs out there are using method 10 in another way, please let us know.
>
>
>
> -Tim
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Proposed Shanghai Agenda covering audit issues

[Ryan Sleevi via Public]

On Sun, Sep 23, 2018 at 9:14 PM Kirk Hall via Public 
wrote:

> Ryan, I’m glad you referred to our Sept. 20 SCWG teleconference in your
> message below, and what was said there.  I went back to listen and I
> prepared draft Minutes on the Shanghai Agenda/audits issues portion.  (I’m
> sending those Minutes to the Management list because they have not yet been
> approved for publication on the Public list.)  I also included a link in
> that message to the recording so interested members can confirm for
> themselves what was said on the call.
>

These were posted to the Public List, and I think it's good for the
transparency of the discussion.


>
>
> The recording and draft Minutes of our Thursday teleconference do not
> support your recollection of the call as presented below.  Here are the
> main takeaways from the 15 minute discussion on the call.
>
>
>
> ·   I asked if anyone had Agenda items to propose for the Shanghai
> meeting.  You suggested the Forum discuss the process for inclusion of
> roots in browser root programs from the auditing standpoint, the audits
> required from birth to death of a CA, and the variety of program
> requirements in place that require different things.  You said clarity and
> consensus on that and related verbiage would be useful, and this also
> applies to reworked language in BR 8.1 and 8.2 and confusion around
> performance audits.  You thought these issues could take at least an hour
> of time at the meeting, and that 30 minutes might be necessary to get
> everyone on the same page concerning audit vocabulary, as some people use
> phrases that don’t match with professional terms.  You said the goal was to
> a common understanding as well as diagramming what the expected process
> should look like with the appropriate audit schemes recognized.  You did
> not initially say you wanted to be a presenter or the sole presenter on all
> these related issues.
>
I think the key point here is that I was requesting a slot, of 60 to 90
minutes, to cover these issues. Thank you for confirming the accuracy of
this, and it seems the only confusion here is that despite requesting this
slot, you did not believe it was being requested?

I think your record of the minutes also does not capture your
dismissiveness of the issue, and I certainly can see why clarity is
necessary, as it seems you're intent on not scheduling the request.

The request being made here - and the issue described - is because they are
all tightly coupled, and I believe would most benefit the Forum discussed
as a single, concerted topic, that explores those relations - as we
requested. I am explicitly requesting this separate from the WebTrust and
ACAB-C updates, because I believe it is beneficial to have a discussion
that focuses on the common understanding these issues as they stand. As
we've seen, our WebTrust folks are excellent about talking about WebTrust -
but are not so at ETSI, and so to the opposite.


That’s pretty much how I broke things down on my Agenda proposal on Friday.
>

Yes. And I'm objecting to that, because I believe you've taken a
description of a session that was specifically being requested, which you
disagreed with, and attempted to reorganize the content, structure, and
presentation. As discussed from our past meetings, it's clear you do not
view some of these matters as important, nor do you appreciate the issues
at play.

I believe this will be a far more productive use of folks time, energy, and
expectations, if we can have that discussion, particularly for browser
members, if taken as a cohesive single presentation that examines the
current state.

That does not conflict with the ETSI or WebTrust updates, it does not
conflict with (other than an ordering dependency) with Wayne's suggestion
made in person previously. Indeed, the specific request for this session
emerged from those discussions, and through discussions that made it clear
a more cohesive understanding was necessary.

As such, I would like to, unfortunately yet again, request that 60-90
minutes be set aside in the schedule.

For ordering purposes:
- 60-90 minutes - Discussion of current state of audits and membership
requirements (Ryan)
- 60 minutes - Discussion about future audit requirements (Wayne)

And that these discussions would best benefit independent from the WebTrust
TF or ETSI updates, which are incredibly valuable, but somewhat orthogonal
to the conversation proposed.

Please update the agenda to reflect this request.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Proposed Shanghai Agenda covering audit issues

[Ryan Sleevi via Public]

On Sun, Sep 23, 2018 at 1:59 PM Kirk Hall 
wrote:

> I believe topic #3 as I have listed it below fairly presents your request
> on the Sept. 20  teleconference call, as it covers what you said you wanted
> to discuss – “Problems faced by root programs from existing WebTrust/ETSI
> reports and terminology.”  You didn’t request #1 or #2 because I was the
> one who thought of adding those segments when drafting the Agenda – this is
> intended as an introduction to existing audit/report types from the people
> who actually run WebTrust and ETSI to help educate the Members in the room
> so they can then fully understand the remaining topics #3 - #5.
>

Kirk, I do not believe it to be fairly presented. If there is any
confusion, it's no doubt because you were interjecting during my
description of the session to indicate you did not believe it would be
necessary, as you felt it would take "60 seconds, at best".

I felt there was a clear request for a session, of 60 to 90 minutes length,
by Google, to cover these topics. Do you believe that request - the first
thing that was asked for - was unclear? At several times during the call,
you attempted to suggest different topics of discussion, or why you felt
they were not necessary, and again, the request was made.


> You didn’t request #4 – Wayne did that at the WebTrust meeting in San Jose
> on Sept. 11, and I made a note at that time.  So I think it’s appropriate
> to let Wayne present his ideas.
>
>
>
> Finally, while you did raise a different interpretation of our membership
> rules on our Sept. 6 teleconference than we have followed in the past (you
> said you thought a Point in Time audit is enough for a CA applicant to
> qualify for full membership under the current Bylaws, which is not what we
> have done in the past or what the members said they wanted in the Doodle
> poll) I was actually the person who raised the question of what form of
> audit is required for membership during that call.  Because Dimitris will
> be taking over new membership requests in November, it makes sense for him
> to present that issue.
>

While perhaps that's the case, if you also recall, on our previous call, I
indicated that I have been working with both ETSI and WebTrust to address
the issues arising from your misunderstanding and misrepresentation - of
the Doodle poll and of the respective audits. Happy to revisit that with
you, if you felt it was unclear that this was a topic that Google was
actively working on


> But I will remove Dimitris as a Moderator for the five issues – each
> presenter can be the moderator of his own topic.  And I will remove Wayne
> as a co-presenter with you on #3 and make you sole presenter – but I know
> Wayne also said he was having problems with some forms of audit reports, so
> I hope you will let him add his input during #3.
>
>
>
> If you want to suggest different wording for your #3 below, please let me
> know and I will include it on the Agenda.   How much time would you like
> for this segment?
>

I again reiterate the request that was made on the call, for 60 - 90
minutes for a session, prior to the discussion about future expectations,
to include both a presentation based on discussions Google has been having
with browser representatives and auditor members, to bring clarity to these
matters.

Can you ensure that such a thing is scheduled? Or do you believe your
schedule is the only way to get this on the agenda?

>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Proposed Shanghai Agenda covering audit issues

[Ryan Sleevi via Public]

Kirk,

I appreciate this attempt, but this wasn't what I was requesting. Could you
clarify that you're not willing to schedule the sessions as I'd requested /
and/or appointing other facilitators for those discussions?

I specifically was requesting to present on #1, #2, #3, and #5. I believe
the recordings will show that.

This is a critically important area for Google, and while we welcome
participation, the request for the sessions, as made on the call, stands,
with Google facilitating the discussion.

On Sat, Sep 22, 2018 at 3:19 PM Kirk Hall via Public 
wrote:

> On our SCWG call this week, Ryan, Wayne, and others suggested we take time
> in Shanghai to talk about the audit programs, their different forms of
> audits and reports, their terminology, and problems that browsers are
> encountering.  Wayne also indicated he wanted to discuss an “ideal audit
> life cycle” for a new trusted root from birth to death.  This seems like a
> great topic for us.
>
>
>
> We can also talk about how we want to interpret our current Bylaws Section
> 2.1 on Forum membership requirements – what type of audit reports are
> required, and whether we need to clarify Bylaws clarifications.
>
>
>
> I’ve asked Dimitris to be the Moderator on these topics to make sure we
> stay on schedule and following a logical progression.
>
>
>
> We would still have the regular auditor updates before this discussion –
> that’s just the place where WebTrust and ETSI can give us the most recent
> program news.
>
>
>
> Here is my proposed Agenda breakdown.  Comments are welcome.
>
>
>
> *
>
>
>
> 1. Types of audits/reports under *WebTrust* and their terminology,
> including new CAs and new audit/report types (Jeff, Don).  A summary
> reference table would be welcome.
>
>
>
> 2. Types of audits/reports under *ETSI* and their terminology, including
> new CAs and new audit/report types (Arno, Clemens).  A summary reference
> table would be welcome.
>
>
>
> [Jeff/Don/Arno/Clemens – do you think you can also prepare a
> summary comparison table of the different WebTrust and ETSI audits and
> reports, showing which are roughly “equivalent”, which are not, and the
> main differences?]
>
>
>
> 3. Problems faced by root programs from existing WebTrust/ETSI reports and
> terminology, including for new CAs (Ryan, Wayne)
>
> ·   Oddball report types received
>
> ·   Common issues/misunderstandings by new CAs
>
> ·   Recommendations on standard terminology to be used (if any)
>
> ·   Recommendation for clarification on audit requirements in
> *current* BRs, root programs to eliminate misunderstandings, adopt common
> terminology
>
>
>
> 4. Ideal audit life cycle – birth to death of a new CA (Wayne – also Ryan,
> or Mike, or Geoff)
>
> ·   Description of ideal cycle (with timelines, multiple use cases) –
> not necessarily what is required today by BRs, WT/ETSI, root programs, but
> what browsers would like to see
>
> ·   Once there is consensus on ideal life cycle, how do we get
> there?  Via BRs or via root programs (or both)?
>
> ·   Proposals for BR amendments to reach ideal life cycle
>
> ·   Do we need to better align BRs and root program rules?
>
>
>
> 5.  Forum membership rules Bylaws Sec. 2.1 (Dimitris)
>
> ·   What does the Forum **want** the audit requirements to be based
> on different level of membership (Associate Member, Member).  See
> https://cabforum.org/pipermail/public/2018-April/013259.html
>
> ·   Potential amendments to Bylaws to clarify audit requirements for
> Associate Member, full Member status.
>
>
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Public Digest, Vol 77, Issue 81

[Ryan Sleevi via Public]

Tim,

Could you explain what you believe is "the status quo" here? A LWG is bound
by the Bylaws in the production of minutes - a conversion to Subcommittee
triggers different behaviours, and "Tim's word" is, unfortunately, not at
all an acceptable guarantee for minimizing ongoing risk. We can address
this by either the SCWG establishing the practice for all Subcommittees -
the preferred approach - or if there is some compelling reason that
necessitates establishing a Subcommittee prior to resolving this (a matter
which no one has yet demonstrated), then in the establishment of those
Subcommittees.

This isn't that hard.

On Fri, Sep 14, 2018 at 7:45 PM Tim Hollebeek 
wrote:

> Ryan, thank you clearly explaining why it is deeply concerning that a
> Google representative is opposed to the status quo.  We will continue to
> have minutes, unless a Google prevents it.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Friday, September 14, 2018 6:52 PM
> *To:* Geoff Keating 
> *Cc:* CABFPub ; Tim Hollebeek <
> tim.holleb...@digicert.com>; Virginia Fournier 
> *Subject:* Re: [cabfpub] Public Digest, Vol 77, Issue 81
>
>
>
> You are correct that it's deeply concerning if there can be a Subcommittee
> that *doesn't* take minutes. A good ballot for such a subcommittee would
> affirm its commitment to running in such a way that reduces that risk, so
> that it's easy to support.
>
> On Fri, Sep 14, 2018 at 6:34 PM Geoff Keating  wrote:
>
> I think we’re in agreement as to the effect of not having minutes on the
> IPR policy.
>
>
>
> I don’t believe anyone is proposing a subcommittee charter which
> *prevents* it from having minutes.  So, perhaps if you’re concerned that a
> subcommittee might not have the standard of minute-taking that you would
> like, you could offer to take minutes for that subcommittee?  My experience
> is that such an offer is usually received with gratitude!
>
>
>
> On Sep 14, 2018, at 2:04 PM, Ryan Sleevi via Public 
> wrote:
>
>
>
> Please review section 8 of the IPR policy with your legal counsel, Tim,
> particularly around what constitutes a "Contribution"
>
>
>
> On Fri, Sep 14, 2018 at 4:52 PM Tim Hollebeek 
> wrote:
>
> We have the protections in the IPR policy, because we have the IPR
> policy.  To be clear, the existence or absence of minutes does not in any
> way affect the IPR policy, and there’s no text in the Bylaws or IPR policy
> that suggests that it does.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Ryan Sleevi
> via Public
> *Sent:* Friday, September 14, 2018 4:41 PM
> *To:* Virginia Fournier ; CABFPub <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] Public Digest, Vol 77, Issue 81
>
>
>
> Virginia,
>
>
>
> I do not understand how that position is at all consistent with our bylaws
> with respect to IP risk. If we have Subcommittees without the requirement
> to maintain or produce minutes, how could we possibly hope to have the IP
> protections afforded by our policy?
>
>
>
> On Fri, Sep 14, 2018 at 4:32 PM Virginia Fournier via Public <
> public@cabforum.org> wrote:
>
> It would be great if the people who continually complain that the Bylaws
> don’t contain x, or took away y, would actively participate in the process
> to create new versions of the Bylaws.  The version of the Bylaws creating
> CWGs and their Subcommittees was developed over more than a year, with
> ample time for review, comment, revision, rinse and repeat.
>
>
>
> The Bylaws say that "each CWG may establish any number of subcommittees
> within its own Working Group to address any of such CWG’s business.”
> However, there's nothing in the Bylaws that prohibits Subcommittees from
> having their own mailing lists, minutes, chairs, etc.  It looks like
> Subcommittees have the   flexibility to determine how to conduct their own
> business within the CWG.
>
>
>
> If a CWG wants a Subcommittee to do something specific (like keep
> minutes), they can specify that in the CWG charter.
>
>
>
> Best regards,
>
>
>
> Virginia Fournier
>
> Senior Standards Counsel
>
>  Apple Inc.
>
> ☏ 669-227-9595
>
> ✉︎ v...@apple.com
>
>
>
>
>
>
>
> On Sep 14, 2018, at 9:29 AM, public-requ...@cabforum.org wrote:
>
>
>
> Send Public mailing list submissions to
> public@cabforum.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://cabforum.org/mailman/listinfo/public
> or, via email, send a message with subject or body 'help' to
> public-requ...@cabforum.org
>
> You can reach the person managing the list at
> public-ow...@cabforum.

Re: [cabfpub] Public Digest, Vol 77, Issue 81

[Ryan Sleevi via Public]

You are correct that it's deeply concerning if there can be a Subcommittee
that *doesn't* take minutes. A good ballot for such a subcommittee would
affirm its commitment to running in such a way that reduces that risk, so
that it's easy to support.

On Fri, Sep 14, 2018 at 6:34 PM Geoff Keating  wrote:

> I think we’re in agreement as to the effect of not having minutes on the
> IPR policy.
>
> I don’t believe anyone is proposing a subcommittee charter which
> *prevents* it from having minutes.  So, perhaps if you’re concerned that a
> subcommittee might not have the standard of minute-taking that you would
> like, you could offer to take minutes for that subcommittee?  My experience
> is that such an offer is usually received with gratitude!
>
> On Sep 14, 2018, at 2:04 PM, Ryan Sleevi via Public 
> wrote:
>
> Please review section 8 of the IPR policy with your legal counsel, Tim,
> particularly around what constitutes a "Contribution"
>
> On Fri, Sep 14, 2018 at 4:52 PM Tim Hollebeek 
> wrote:
>
>> We have the protections in the IPR policy, because we have the IPR
>> policy.  To be clear, the existence or absence of minutes does not in any
>> way affect the IPR policy, and there’s no text in the Bylaws or IPR policy
>> that suggests that it does.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Public  *On Behalf Of *Ryan Sleevi
>> via Public
>> *Sent:* Friday, September 14, 2018 4:41 PM
>> *To:* Virginia Fournier ; CABFPub <
>> public@cabforum.org>
>> *Subject:* Re: [cabfpub] Public Digest, Vol 77, Issue 81
>>
>>
>>
>> Virginia,
>>
>>
>>
>> I do not understand how that position is at all consistent with our
>> bylaws with respect to IP risk. If we have Subcommittees without the
>> requirement to maintain or produce minutes, how could we possibly hope to
>> have the IP protections afforded by our policy?
>>
>>
>>
>> On Fri, Sep 14, 2018 at 4:32 PM Virginia Fournier via Public <
>> public@cabforum.org> wrote:
>>
>> It would be great if the people who continually complain that the Bylaws
>> don’t contain x, or took away y, would actively participate in the process
>> to create new versions of the Bylaws.  The version of the Bylaws creating
>> CWGs and their Subcommittees was developed over more than a year, with
>> ample time for review, comment, revision, rinse and repeat.
>>
>>
>>
>> The Bylaws say that "each CWG may establish any number of subcommittees
>> within its own Working Group to address any of such CWG’s business.”
>> However, there's nothing in the Bylaws that prohibits Subcommittees from
>> having their own mailing lists, minutes, chairs, etc.  It looks like
>> Subcommittees have the   flexibility to determine how to conduct their own
>> business within the CWG.
>>
>>
>>
>> If a CWG wants a Subcommittee to do something specific (like keep
>> minutes), they can specify that in the CWG charter.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Virginia Fournier
>>
>> Senior Standards Counsel
>>
>>  Apple Inc.
>>
>> ☏ 669-227-9595
>>
>> ✉︎ v...@apple.com
>>
>>
>>
>>
>>
>>
>>
>> On Sep 14, 2018, at 9:29 AM, public-requ...@cabforum.org wrote:
>>
>>
>>
>> Send Public mailing list submissions to
>> public@cabforum.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://cabforum.org/mailman/listinfo/public
>> or, via email, send a message with subject or body 'help' to
>> public-requ...@cabforum.org
>>
>> You can reach the person managing the list at
>> public-ow...@cabforum.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Public digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Ballot SC10 ? Establishing the Network Security
>>  Subcommittee of the SCWG (Ryan Sleevi)
>>   2. Re: Ballot SC10 ? Establishing the Network Security
>>  Subcommittee of the SCWG (Tim Hollebeek)
>>
>>
>> --
>>
>> Message: 1
>> Date: Fri, 14 Sep 2018 12:19:24 -0400
>> From: Ryan Sleevi 
>> To: Tim Hollebeek 
>> Cc: CABFPub 
>> Subject: Re: [cabfpub] Ballot SC10 ? Establishing the Network Security
>> Subcommittee of the SCWG
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Subcommi

Re: [cabfpub] [EXTERNAL]Re: Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG

[Ryan Sleevi via Public]

On Fri, Sep 14, 2018 at 4:50 PM Tim Hollebeek 
wrote:

> Wayne,
>
>
>
> My position is that LWGs are handled via the process in 5.3.4, and not
> 5.3.1(e), and as such, the Validation WG is somewhat special.  This was
> actually the intent of the Governance Reform effort; it was intended that
> the Governance Reform effort would not be used to obstruct or impede the
> functioning of existing working groups (I’ll note that obstructing the work
> of the Forum is explicitly called out in the Code of Conduct as a Code of
> Conduct violation).  As I’ve stated repeatedly, I will probably support any
> and/or all attempts to improve clarity in this area, as long as it doesn’t
> impede the important work of the Validation WG.  Though the suggestion that
> it is unclear whether Subcommittees have chairs is completely bizarre.
> I’ve never been a member of a standards working group or committee that
> didn’t, and I’ve been on **WAY** too many of them.  Extraordinary claims
> require extraordinary evidence.
>

Can you point to where the Bylaws describe how Subcommittees operate? Can
you point to where Ballot 206 describes how subcommittees operate? Can you
point to a list during or prior to this discussion that describes how
subcommittees operate?

The point is that these elements are not defined, anywhere. It sounds like
multiple members unsurprisingly arose at different definitions and
understandings, some reasonable, some not, and now it's an effort of the
SCWG to sort out what the definition "should" be and to adopt a process to
memorialize that in a way that isn't "Well, I threatened a Code of Conduct
complaint, so I must be right"

Here's a simple path forward:
- The SCWG has not defined how Subcommittees are formed. One interpretation
suggests that means nothing is required - not even to the degree of
consensus. Another interpretation suggests that means in the absence of
definition, a ballot is required.
- The SCWG has not defined how Subcommittees are operated, nor do the
Bylaws. A subcommittee is clearly a part of a CWG, but the obligations and
expectations of that subcommittee - does it use a public mail list, does it
produce minutes, does it permit calls - is not defined. The Bylaws allow
CWGs to define that, but the SCWG has not. One interpretation suggests that
means that subcommittees can do whatever they want. Another suggests that
until the SCWG defines that, it's inadvisable to form subcommittees.

The easiest solution is to resolve both of these with ballots, even if
other interpretations may have value.

The issue(s) with SC9 and SC10 is that they (presently) are missing that
second half that the Bylaws indicate the SCWG's charter should address, but
the current SCWG's charter does not, nor do the Bylaws. In the absence of
that, or a change in the charter, simply addressing these via SC9/SC10 to
clarify what will happen and how it will happen will resolve (temporarily)
the fundamental issue, and then subsequent work can be done to clarify for
the SCWG going forward how Subcommittees will operate.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Public Digest, Vol 77, Issue 81

[Ryan Sleevi via Public]

Please review section 8 of the IPR policy with your legal counsel, Tim,
particularly around what constitutes a "Contribution"

On Fri, Sep 14, 2018 at 4:52 PM Tim Hollebeek 
wrote:

> We have the protections in the IPR policy, because we have the IPR
> policy.  To be clear, the existence or absence of minutes does not in any
> way affect the IPR policy, and there’s no text in the Bylaws or IPR policy
> that suggests that it does.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Ryan Sleevi
> via Public
> *Sent:* Friday, September 14, 2018 4:41 PM
> *To:* Virginia Fournier ; CABFPub <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] Public Digest, Vol 77, Issue 81
>
>
>
> Virginia,
>
>
>
> I do not understand how that position is at all consistent with our bylaws
> with respect to IP risk. If we have Subcommittees without the requirement
> to maintain or produce minutes, how could we possibly hope to have the IP
> protections afforded by our policy?
>
>
>
> On Fri, Sep 14, 2018 at 4:32 PM Virginia Fournier via Public <
> public@cabforum.org> wrote:
>
> It would be great if the people who continually complain that the Bylaws
> don’t contain x, or took away y, would actively participate in the process
> to create new versions of the Bylaws.  The version of the Bylaws creating
> CWGs and their Subcommittees was developed over more than a year, with
> ample time for review, comment, revision, rinse and repeat.
>
>
>
> The Bylaws say that "each CWG may establish any number of subcommittees
> within its own Working Group to address any of such CWG’s business.”
> However, there's nothing in the Bylaws that prohibits Subcommittees from
> having their own mailing lists, minutes, chairs, etc.  It looks like
> Subcommittees have the   flexibility to determine how to conduct their own
> business within the CWG.
>
>
>
> If a CWG wants a Subcommittee to do something specific (like keep
> minutes), they can specify that in the CWG charter.
>
>
>
> Best regards,
>
>
>
> Virginia Fournier
>
> Senior Standards Counsel
>
>  Apple Inc.
>
> ☏ 669-227-9595
>
> ✉︎ v...@apple.com
>
>
>
>
>
>
>
> On Sep 14, 2018, at 9:29 AM, public-requ...@cabforum.org wrote:
>
>
>
> Send Public mailing list submissions to
> public@cabforum.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://cabforum.org/mailman/listinfo/public
> or, via email, send a message with subject or body 'help' to
> public-requ...@cabforum.org
>
> You can reach the person managing the list at
> public-ow...@cabforum.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Public digest..."
>
>
> Today's Topics:
>
>   1. Re: Ballot SC10 ? Establishing the Network Security
>  Subcommittee of the SCWG (Ryan Sleevi)
>   2. Re: Ballot SC10 ? Establishing the Network Security
>  Subcommittee of the SCWG (Tim Hollebeek)
>
>
> --
>
> Message: 1
> Date: Fri, 14 Sep 2018 12:19:24 -0400
> From: Ryan Sleevi 
> To: Tim Hollebeek 
> Cc: CABFPub 
> Subject: Re: [cabfpub] Ballot SC10 ? Establishing the Network Security
> Subcommittee of the SCWG
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Subcommittees don't have requirements for minutes or publicly-available
> notes.
>
> That's the point. All this thinking about subcommittees working "just like"
> LWGs is not the case. All of that was lost from the Bylaws. A subcommittee
> can just be two people having a chat, at least as written in the Bylaws
> today.
>
> There's nothing stating subcommittees work with their own mailing lists,
> for example, in the way our old bylaws did. There's nothing establishing
> chairs or charters or deliverables. It's a one-off note.
>
> That's the point.
>
> On Fri, Sep 14, 2018 at 12:13 PM Tim Hollebeek  >
> wrote:
>
>
> Collaborating outside of a subcommittee has a bunch of drawbacks,
> including a complete lack of public transparency and much weaker IPR
> protections.
>
>
>
> In my opinion, there?s already way, way too much going on in private that
> would be better handled in subcommittees where everyone can participate and
> there are publicly available notes.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Wayne Thayer
> via Public
> *Sent:* Thursday, September 13, 2018 7:11 PM
> *To:* Ryan Sleevi ; CA/Browser Forum Public Discussion
> List 
> *Subject:* Re: [cabfpub] Ballot SC10 ? Establishing the Network 

Re: [cabfpub] Public Digest, Vol 77, Issue 81

[Ryan Sleevi via Public]

Virginia,

I do not understand how that position is at all consistent with our bylaws
with respect to IP risk. If we have Subcommittees without the requirement
to maintain or produce minutes, how could we possibly hope to have the IP
protections afforded by our policy?

On Fri, Sep 14, 2018 at 4:32 PM Virginia Fournier via Public <
public@cabforum.org> wrote:

> It would be great if the people who continually complain that the Bylaws
> don’t contain x, or took away y, would actively participate in the process
> to create new versions of the Bylaws.  The version of the Bylaws creating
> CWGs and their Subcommittees was developed over more than a year, with
> ample time for review, comment, revision, rinse and repeat.
>
> The Bylaws say that "each CWG may establish any number of subcommittees
> within its own Working Group to address any of such CWG’s business.”
> However, there's nothing in the Bylaws that prohibits Subcommittees from
> having their own mailing lists, minutes, chairs, etc.  It looks like
> Subcommittees have the   flexibility to determine how to conduct their own
> business within the CWG.
>
> If a CWG wants a Subcommittee to do something specific (like keep
> minutes), they can specify that in the CWG charter.
>
> Best regards,
>
> Virginia Fournier
> Senior Standards Counsel
>  Apple Inc.
> ☏ 669-227-9595
> ✉︎ v...@apple.com
>
>
>
> On Sep 14, 2018, at 9:29 AM, public-requ...@cabforum.org wrote:
>
> Send Public mailing list submissions to
> public@cabforum.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://cabforum.org/mailman/listinfo/public
> or, via email, send a message with subject or body 'help' to
> public-requ...@cabforum.org
>
> You can reach the person managing the list at
> public-ow...@cabforum.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Public digest..."
>
>
> Today's Topics:
>
>   1. Re: Ballot SC10 ? Establishing the Network Security
>  Subcommittee of the SCWG (Ryan Sleevi)
>   2. Re: Ballot SC10 ? Establishing the Network Security
>  Subcommittee of the SCWG (Tim Hollebeek)
>
>
> --
>
> Message: 1
> Date: Fri, 14 Sep 2018 12:19:24 -0400
> From: Ryan Sleevi 
> To: Tim Hollebeek 
> Cc: CABFPub 
> Subject: Re: [cabfpub] Ballot SC10 ? Establishing the Network Security
> Subcommittee of the SCWG
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Subcommittees don't have requirements for minutes or publicly-available
> notes.
>
> That's the point. All this thinking about subcommittees working "just like"
> LWGs is not the case. All of that was lost from the Bylaws. A subcommittee
> can just be two people having a chat, at least as written in the Bylaws
> today.
>
> There's nothing stating subcommittees work with their own mailing lists,
> for example, in the way our old bylaws did. There's nothing establishing
> chairs or charters or deliverables. It's a one-off note.
>
> That's the point.
>
> On Fri, Sep 14, 2018 at 12:13 PM Tim Hollebeek  >
> wrote:
>
> Collaborating outside of a subcommittee has a bunch of drawbacks,
> including a complete lack of public transparency and much weaker IPR
> protections.
>
>
>
> In my opinion, there?s already way, way too much going on in private that
> would be better handled in subcommittees where everyone can participate and
> there are publicly available notes.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Wayne Thayer
> via Public
> *Sent:* Thursday, September 13, 2018 7:11 PM
> *To:* Ryan Sleevi ; CA/Browser Forum Public Discussion
> List 
> *Subject:* Re: [cabfpub] Ballot SC10 ? Establishing the Network Security
> Subcommittee of the SCWG
>
>
>
> Would it be helpful to take a step back and propose an amendment to the
> Bylaws or SCWG charter that addresses Subcommittees in sufficient detail? I
> would be willing to work on that. Meanwhile, if the Network Security WG
> left some urgent work unfinished, nothing prevents SCWG members from
> collaborating outside of the Subcommittee structure.
>
>
>
> On Thu, Sep 13, 2018 at 3:49 PM Ryan Sleevi via Public <
> public@cabforum.org> wrote:
>
> I think that, without incorporating or responding to feedback, we will be
> opposed to this ballot. I agree that it's unfortunate we have gotten
> nowhere - but it's equally unfortunate to have spent two months without
> responding to any of the substance of the issues. It's great to see
> progress, but making small steps doesn't excuse leaving glaring issues.
> It

Re: [cabfpub] [EXTERNAL]Re: Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG

[Ryan Sleevi via Public]

We're in violent agreement, Tim. :)

But there's still an issue to solve. The bylaws don't establish how
subcommittees are run - minutes and lists are two examples. Whether or not
a chair is another. That's the sort of problem that a ballot is needed to
resolve - not the conversion. That's just 5.3.1(d) and (e).

On Fri, Sep 14, 2018 at 1:38 PM Tim Hollebeek 
wrote:

> What the Bylaws actually say is:
>
>
>
> “5.3.4 Legacy Working Groups Any “Legacy” Working Groups (“LWG”) in
> existence when this Bylaws v.1.8 is approved by the Forum shall have the
> option of (a) converting to a Subcommittee under a CWG pursuant to Section
> 5.3.1(e), (b) immediately terminating, or (c) continuing in effect without
> change for 6 months following such approval. For an LWG to continue beyond
> such 6 months, it must have a charter approved as described in Section
> 5.3.1 above, as if it was a new Working Group.”
>
>
>
> The Validation Working Group has expressed its intention to become a
> Subcommittee at every opportunity.  Those who continually seek to deny it
> that option are clearly in violation of the Bylaws.
>
>
>
> Once again, the Validation Working Group has selected option (a).  If we
> want a Ballot to confirm that, we can have a ballot, but I will not allow
> members to obstruct the LWG’s right to choose option (a), a right the
> Working Group clearly has, as stated in the Bylaws.
>
>
>
> -Tim
>
>
>
> *From:* Public  *On Behalf Of *Ryan Sleevi
> via Public
> *Sent:* Friday, September 14, 2018 1:22 PM
> *To:* Kirk Hall ; CABFPub <
> public@cabforum.org>
> *Subject:* Re: [cabfpub] [EXTERNAL]Re: Ballot SC10 – Establishing the
> Network Security Subcommittee of the SCWG
>
>
>
> Kirk,
>
>
>
> You have a real opportunity to resolve these issues, and I hope you will
> incorporate that feedback into consideration. There are now multiple
> threads, in part because some of your forked replies, but to summarize
> where we stand:
>
>
>
> Nothing in the Bylaws requires resolution on/by October 3, other than that
> they will cease to be LWGs.
>
> While no longer LWGs, if they choose to be subcommittees, then it has to
> be done using the process defined by the SCWG.
>
> The SCWG has not defined or balloted its process for these.
>
> If you're proposing that these ballots use an assumed process that is not
> specified, we're opposed and remain opposed, because having the Forum and
> the Chair make up process continues to undermine the legitimacy of the
> Forum and its value, needlessly and irresponsibly.
>
>
>
> If you feel it's important to establish these before Oct 3 - which it
> isn't, procedurally - then one path you can do that can resolve the
> feedback and concerns is to actually spell out the things you are assuming,
> such as that subcommittees will produce minutes, operate on public lists,
> allow participation, etc. This is not difficult, it's just more work - but
> that's the cost of doing things right, you sometimes have to put a bit of
> effort in to do it right.
>
>
>
> As you can see from those minutes, this has been known to be a problem for
> months. The proposal was simple: "Dimitris again noted that new Bylaw
> 5.3.1(e) did not provide for a method for creating Subcommittees, and maybe
> the Bylaws or Charter should be amended to provide a method, and Wayne
> agreed."
>
>
>
> There's still no definition for how the Subcommittee will operate, and
> that should be in the ballot to form it, since the Chair did not propose a
> ballot based on the Doodle Poll that the Chair conducted for a matter the
> Chair brought to resolve.
>
>
>
> On Fri, Sep 14, 2018 at 1:08 PM Kirk Hall via Public 
> wrote:
>
> Exactly right.  To add one other point – I am the one who proposed we
> allow “Subcommittees” in the new Working Groups during the early
> discussions in the Governance Change Working Group that led to Ballot 206.
> I chose the name “Subcommittee” to avoid confusion (as we were now using
> the term “Working Group” to refer to the main group that needed
> Subcommittees to do preliminary work on ballot proposal), but I made it
> clear at the time that the new Subcommittees of the new Working Groups
> would function exactly the same as the old Working Groups of the Forum.
> There was no confusion or argument on this point among the Governance
> Change participants.
>
>
>
> I personally don’t see the need for yet more work to further define
> Subcommittees in the Bylaws, but will not object if others want to work on
> that.  In the meantime, we need to move forward on creating the Validation
> and NetSec Subcommittees so they can continue their work after Octo

Re: [cabfpub] [EXTERNAL]Re: Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG

[Ryan Sleevi via Public]

oulos [mailto:ji...@it.auth.gr]
> *Sent:* Thursday, September 13, 2018 10:43 PM
> *To:* Ryan Sleevi ; CA/Browser Forum Public Discussion
> List ; Kirk Hall 
> *Subject:* [EXTERNAL]Re: [cabfpub] Ballot SC10 – Establishing the Network
> Security Subcommittee of the SCWG
>
>
>
> It looks like a similar conversation was captured in the minutes of
> previous Server Certificate WG teleconferences.
>
>- https://cabforum.org/2018/07/12/2018-07-12-scwg-minutes/ where the
>ambiguity on how to form subcommittees was first raised
>-
>
> https://cabforum.org/2018/07/26/2018-07-26-server-certificate-working-group-minutes/
>where the members expressed their opinion (via doodle poll) and the
>majority chose to resolve this ambiguity by requiring ballots for the
>formation of subcommittees in the SCWG.
>
> IMO, members are in favor of ballots to resolve issues like this. The
> definition of a subcommittee is broad enough and described in 5.3.1(e) "to
> address any of such CWG's business". It is very clear to me that both
> proposed subcommittees (validation and NetSec) are within the SCWG's scope.
>
> I thought we had agreed that until the SCWG charter is amended (to include
> language around subcommittees, election of officers and other issues that
> were discussed in previous calls), we would proceed with using ballots as
> the agreed-upon decision making process. I understand that Kirk's proposed
> ballots (as a process) are aligned with this decision. The content of the
> ballots (whether or not we will name "chairs", etc for subcommittees) is
> debatable and under discussion.
>
> As a general comment, I would like to note that the majority of
> Contributions were taking place during "Legacy Working Groups" with the
> previous governance. These "officially declared" teams had great momentum,
> produced a lot of improvements to the Forum's Guidelines, met regularly and
> were coordinated by one or two people that facilitated the discussions and
> provided the necessary logistics (calendar scheduling, agendas, minutes and
> so on). I can't imagine that the Governance change intended to make things
> so hard to form these currently-called "subcommittees". In case of doubt,
> ballots were always a good way forward, *unless *they propose something
> that is *clearly against* the Bylaws.
>
>
> Dimitris.
>
> On 14/9/2018 3:43 πμ, Ryan Sleevi via Public wrote:
>
>
>
> On Thu, Sep 13, 2018 at 8:39 PM Kirk Hall 
> wrote:
>
> Thanks for the list, Wayne.  Responses inline.  Remember, a Subcommittee
> has no real power, it’s just a place where members interested in a subject
> who want to be involved in drafting proposals for the whole SCWG can work
> together – we have 10+ years of successful experience with this approach,
> and are just continuing it at the SCWG level.
>
>
>
> [Wayne] To respond to Kirk's question about subjects that need to be
> better defined, here is a start:
>
>
>
> * Do Subcommittees have Chairs and if so how are they appointed?  [KH]
> Yes, for the same reason we had Chairs for old-style Working Groups of the
> Forum.  There is no change here (BTW, our Bylaws didn’t include rules for
> old WG Chairs either – somehow it all worked out).  Dean has correctly
> listed what a Chair does.
>
>
>
> This answer doesn't suffice, because our new Bylaws do change things
> substantially, and the reasons for the old structure of WGs doesn't just
> naturally change to SCWGs.
>
>
>
> * How are Subcommittees chartered? (are they chartered?)  [KH] Same as in
> the past when we created old-style WGs of the Forum – by ballots, in this
> case SCWG ballots.  No change here.
>
>
>
> This is half correct, but misses the point of the question. The SCWG is
> responsible for defining how Subcommittees are created, per our Bylaws -
> and it has not. Yet.
>
>
>
> * What are the required contents of a Subcommittee charter?  [KH] Same as
> in the past when we created old-style WGs of the Forum – by ballot
> language.  We never had problems in drafting the ballots that created old
> WGs of the Forum – see Ballots 109, 128, 138, 143, 165, and 203.  No change
> here.  What problem do you see from following our past procedure?
>
>
>
> Obviously, there's nothing you can point to support this interpretation,
> and your interpretation itself isn't supported by the Bylaws, because the
> SCWG does not define what you just stated.
>
>
>
>
>
> * How are Subcommittees operated?  [KH] In the same fashion as old WGs of
> the Forum were operated – teleconferences and informal procedures.  No
> change here.
>
>
>
> Again, this is

Re: [cabfpub] [EXTERNAL]Re: Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG

[Ryan Sleevi via Public]

mment, I would like to note that the majority of
> Contributions were taking place during "Legacy Working Groups" with the
> previous governance. These "officially declared" teams had great momentum,
> produced a lot of improvements to the Forum's Guidelines, met regularly and
> were coordinated by one or two people that facilitated the discussions and
> provided the necessary logistics (calendar scheduling, agendas, minutes and
> so on). I can't imagine that the Governance change intended to make things
> so hard to form these currently-called "subcommittees". In case of doubt,
> ballots were always a good way forward, *unless *they propose something
> that is *clearly against* the Bylaws.
>
>
> Dimitris.
>
> On 14/9/2018 3:43 πμ, Ryan Sleevi via Public wrote:
>
>
>
> On Thu, Sep 13, 2018 at 8:39 PM Kirk Hall 
> wrote:
>
> Thanks for the list, Wayne.  Responses inline.  Remember, a Subcommittee
> has no real power, it’s just a place where members interested in a subject
> who want to be involved in drafting proposals for the whole SCWG can work
> together – we have 10+ years of successful experience with this approach,
> and are just continuing it at the SCWG level.
>
>
>
> [Wayne] To respond to Kirk's question about subjects that need to be
> better defined, here is a start:
>
>
>
> * Do Subcommittees have Chairs and if so how are they appointed?  [KH]
> Yes, for the same reason we had Chairs for old-style Working Groups of the
> Forum.  There is no change here (BTW, our Bylaws didn’t include rules for
> old WG Chairs either – somehow it all worked out).  Dean has correctly
> listed what a Chair does.
>
>
>
> This answer doesn't suffice, because our new Bylaws do change things
> substantially, and the reasons for the old structure of WGs doesn't just
> naturally change to SCWGs.
>
>
>
> * How are Subcommittees chartered? (are they chartered?)  [KH] Same as in
> the past when we created old-style WGs of the Forum – by ballots, in this
> case SCWG ballots.  No change here.
>
>
>
> This is half correct, but misses the point of the question. The SCWG is
> responsible for defining how Subcommittees are created, per our Bylaws -
> and it has not. Yet.
>
>
>
> * What are the required contents of a Subcommittee charter?  [KH] Same as
> in the past when we created old-style WGs of the Forum – by ballot
> language.  We never had problems in drafting the ballots that created old
> WGs of the Forum – see Ballots 109, 128, 138, 143, 165, and 203.  No change
> here.  What problem do you see from following our past procedure?
>
>
>
> Obviously, there's nothing you can point to support this interpretation,
> and your interpretation itself isn't supported by the Bylaws, because the
> SCWG does not define what you just stated.
>
>
>
>
>
> * How are Subcommittees operated?  [KH] In the same fashion as old WGs of
> the Forum were operated – teleconferences and informal procedures.  No
> change here.
>
>
>
> Again, this is not consistent with the Bylaws. This is your proposed path,
> but this is not the defined path.
>
>
>
>
>
> * What information is public/private? Do they have their own mailing
> lists?  [KH] Same as the way information was handled for the old WGs of the
> Forum – I think old WG information has always been posted to the Public
> list, so the new Subcommittees will simply post to the SCWG list, which is
> public.  No change here.
>
>
>
> Again, this is not consistent with the Bylaws. This is your proposed path,
> but this is not the defined path.
>
>
>
> * How are Subcommittees dissolved?  [KH] In the same fashion as old WGs of
> the Forum were handled.  If a Subcommittee has no work to do, it can stop
> meeting until it has more work, or I suppose we can have a new ballot to
> dissolve the Subcommittee, if we care.  Most Subcommittees will have
> ongoing work to do (Validation, NetSec), so should be perpetual.  We may
> create other Subcommittees that should have a specific termination date in
> the ballot that creates the Subcommittee it if we believe that is
> appropriate, as we did once in the past.  No change here.
>
>
>
> Again, this is not consistent with the Bylaws. This is your proposed path,
> but this is not the defined path.
>
>
>
>
> ___
>
> Public mailing list
>
> Public@cabforum.org
>
> https://cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public