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

[Clint Wilson via Public]

Apple votes “No” on Forum-11.

Aside from - or perhaps above all - the concerns outlined below and addressed 
in the edited draft I shared with the list here 
(https://cabforum.org/pipermail/public/2020-January/014859.html 
), Apple votes 
“No” partially on principle of there being minimal attempt to engage in 
respectful discourse around feedback provided ~during the discussion period, 
evidenced by leaving no time to respond prior to forcing the ballot to vote. I 
simply don’t believe that all of the substantive feedback below are 
“fundamentally incompatible with the path forward we agreed to in Guangzhou”; I 
question whether discussing new points under time pressure of a voting period 
is the most productive way to ensure those points are adequately addressed.

There are a number of concerns with the version of the charter associated to 
this ballot. I regret, truly, that these issues weren’t all raised, nor 
addressed, prior to the voting period beginning, as I strongly support the 
basic intent of this ballot and hopefully future CWG. We, as an industry, need 
a consistent, auditable set of requirements against which S/MIME certificates 
can be issued and, when compliant, reliably and intercompatibly consumed by 
software providers. Email as a tool for the betterment of humankind has proven 
so effective as to be arguably invaluable; improving the security, privacy, and 
safety of using email is a very worthwhile goal which we unequivocally share 
with the ballot proposer and endorsers. Similarly, I do empathize with the 
impatience which is inevitably felt by those who have shepherded this document 
along these past years and would like to thank Dimitris for his helpful 
comments regarding the proposed changes, which I hope are addressed below.

Moving fast and breaking things is a mantra I can support in some low-risk, 
low-impact situations. The formation of such a pivotal working group is not one 
of them. Highlighted below are some high-level groupings of the concerns we 
have and to which we shared an updated draft proposal that addresses these same 
concerns.
Factual/technical inaccuracies
A private key associated with an S/MIME certificate is not used to encrypt 
emails; the public key is.
An S/MIME certificate as defined solely through the presence of the 
emailProtection EKU does not, necessarily, have the capability of signing email 
(which is typically determined by a keyUsage OID).
Grammatical corrections
“ voting membership in the SMCWG must produce a develop and maintain” 
is clearly simply a grammatical error. 
The numbering of charter sections is incorrect after #4.
Overemphasis on identity
This is understandably subjective, but I’m not sure the edits I proposed 
conveyed fully the concern. 
We have no objection to CAs including identity information in S/MIME 
certificates generally speaking, and believe the SMCWG to be the appropriate 
venue for establishing S/MIME certificate profiles including subject identity 
information. You can see subject identity information in the S/MIME certificate 
used to sign this email, just to provide a little good-faith evidence backing 
this statement (though it shouldn’t be necessary...).
What we do strongly object to is the potential for the working group to be 
sidelined into re-creation and bifurcation of identity validation processes. I 
don’t know the best way to express this in the charter (though I submitted my 
attempt) and that’s part of what I hoped discussion prior to voting to include, 
but I suppose this is an item where I’m simply “late to the party”.
Imprecise pronoun usage
“validate an email address and the subject’s identity prior to binding it to 
the email address” indicates the email address is bound to the email address? 
Or the subject’s identity is bound to the email address? 
I would posit this could instead be better categorized as a factual inaccuracy, 
assuming the intent was to convey the binding of (email address) || (email 
address && subject identity) to a public key in a certificate.
Inconsistent incorporation of pre-existing and suitable reference work
In the closing paragraph of the Introduction section, it’s unclear why it’s 
appropriate to acknowledge existing methods for validating control of a domain, 
but not (in the same paragraph and context) acceptable to acknowledge existing 
methods for validating the identity of a subject. The conclusion this 
inconsistency points to for me is that the BRs and EVGs are insufficient to 
fully validate the identity of a subject. I believe this to be an erroneous 
conclusion, which I attempted to correct for with my proposed changes. 
If I’ve misunderstood and it is instead the position of the proposer that these 
other working group artifacts are indeed insufficient in representing 
“consistent and audited validation practices used by CAs in establishing the 
identity of a subject”, I think that 

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 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]
>>> 

[cabfpub] Final agenda for CA/B Forum F2F 49

[Dimitris Zacharopoulos (HARICA) via Public]

This is the final agenda for the CA/B Forum F2F 49 Plenary Meeting.**


   Wednesday, 19 February 2020 - Plenary Meeting (Day 1)

Start   StopSlotDescription Discussion Leader / Notes
9:009:30
Register / Conference pass distribution / Snacks

9:30
*Call to Order and Welcome - CA/Browser Forum Plenary Meeting*  
9:309:44
	Welcome, Recap of Preliminary Matters, Meeting Recordings, Photo 
Policy, Logistics, Antitrust Statement, Code of Conduct, Take 
Attendance, Assign Minute Takers 	Dimitris Zacharopoulos (HARICA)
9:44 	9:45 	1 	Approval of CABF Minutes from last teleconference 
Dimitris Zacharopoulos (HARICA)
9:45 	10:00 	2 	Report from Code Signing Certificate Working Group 	Dean 
Coclin (Digicert)
10:00 	10:15 	3 	Report from Forum Infrastructure Subcommittee 	Jos 
Purvis (Cisco)

10:15   10:30   
Break   
10:30 	10:45 	4 	Creation of additional Working Groups - Secure Mail 
Tim Hollebeek (Digicert), Wayne Thayer (Mozilla)
10:45 	11:00 	5 	Addressing previously discussed Bylaws issues 	Dimitris 
Zacharopoulos (HARICA)

11:00   11:30   6   Bylaws open issues  Dimitris Zacharopoulos (HARICA)
11:30 	11:50 	7 	Code Signing Formats - an overview of some of the 
different code signing formats used in the wild 	Tomas Gustavsson 
(PrimeKey)

11:50   12:00   8   *Any Other Business*

12:00   
Adjourn CA/Browser Plenary Meeting
12:00   13:00   
Lunch   

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