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 <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 would be incredibly useful to understand. 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). Unnecessary augmentative stipulations The statement “Verification of control over RFC822-compliant email addresses” fully encompasses the statement “Baseline verification of control over email addresses, including those used by a natural person or a legal entity, or used by automated systems such as for mailing lists”. In other words, the additional text following “including” is unnecessary and distracting to the primary scope as the text preceding “including” does not exclude natural persons, legal entities, nor automated systems. One might mark this as a nit, and given discussion it’s almost certainly something that could be accepted as “Won’t Fix”, but the proposed change does improve the ballot and it does so without changing the actual scope or function of the working group. “even though they are managed by third-party service providers” seems to either intentionally introduce ambiguity around what’s truly out of scope (Is it “certs issued under a non-public root AND managed by a third-party service provider”?) or, hopefully more likely, simply attaches a clause to this scope item that neither adds clarity to nor detracts purpose from the intended scope (and should therefore be removed). Overly broad scope The inclusion of “Handling of messages during transport and on various mail user agents” is inappropriate for this forum. Handling of messages during transport is a matter of protocol specification, better suited to entities like the IETF. Handling of messages on various mail user agents is imprecise and therefore essentially meaningless, which is the opposite of what one would hope to find when defining the concrete, inclusive scope of a working group. Removal seemed the best option, as I haven’t seen any concrete representation of example work items related to this scope item. 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 <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. Be well, Clint > On Feb 5, 2020, at 2:08 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: 2020-02-05 17:10 EDT > > End Time: 2020-02-12 17:10 EDT > > > <SMIME Charter 2020-01-24.docx>_______________________________________________ > Public mailing list > Public@cabforum.org <mailto:Public@cabforum.org> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
