[cabfpub] Creation of S/MIME Certificates Working Group

Tue Feb 18 18:56:43 UTC 2020

Here is an attempt to address Apple’s comments during the voting.  This is based on discussions with Clint about how to resolve some of Apple’s concerns.  Clint had some additional comments but I’ll let him provide those.

One of the biggest roadblocks is that Apple’s legal team has a problem with the rules about continuing to be a member of the working group, despite them being identical to the rules Apple is already subject to as part of the server certificate working group.  It’s not entirely clear to me what the concerns are yet, but I’d suggest it would be helpful to decouple that issue from the creation of the S/MIME working group.  I’m happy to discuss revisiting and revising those rules, but I think it should happen in a Forum-wide manner, and not hold up the S/MIME working group.

As always, very interested in hearing feedback from others who are looking to support the ballot.

-Tim

Explanation of changes inline with Apple’s voting comments:

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.

ACCEPT: Since the sentence is not intended to be technical, it is now more generic, and only talks about the key pair collectively being used to sign, encrypt, and decrypt emails.

*	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).

REJECT: The fact that the EKU is necessary but not sufficient for email signing does not invalidate the charter’s use of the EKU to identity S/MIME certificates.  There are lots of things that can potentially prevent a certificate from being able to sign, encrypt or decrypt email, and it does not seem necessary to list all of them in a clause that is simply intended to draw a clear, bright line between certificates that are in scope for this working group, and certificates that are in scope for other working groups.  This matches existing practice for the code signing and server certificate working groups.

*	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.

ACCEPT.  It appears to be after section 5 where things go wrong.

*	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”.

PARTIALLY ACCEPTED: Identity is not overemphasized; indeed it is only mentioned at all to counter the assertions by some that it should not be discussed at all.  It should be noted that identity is NOT mentioned in the purpose of the ballot as an important priority, so it is already somewhat de-emphasized.  I added an exhortation to reuse existing identity work, even though this is always a best practice in standards work and shouldn’t need to be explicitly stated.  Note that the use cases for identities in S/MIME certificates are not entirely the same as for TLS certificates (e.g. individual identities are far more common), so some potential for divergence is inevitable.

I think it is fallacious to assert that preventing discussion of some topics will accelerate work on unrelated topics.  How rapidly work proceeds on any given topic will depend on the amount of time individual members are willing to commit to that topic, and their willingness to work together with others to bring the topic to a speedy resolution. 

*	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.

ACCEPT: It doesn’t appear to be a pronoun issue; that both are bound to the public key makes more sense.

*	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.

ACCEPT: Previous work on identity should also be mentioned.  It is up to the working group to decide whether this previous work is sufficient or not, and how it should be incorporated.

*	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.

*	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.

REJECT: The language was intentionally added to address concerns from a potential certificate consumer that the provisions might be misinterpreted as not allowing addresses of mailing lists and other automated emails.

*	“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).

ACCEPT: This language is less helpful.

*	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.

ACCEPT: Though we may regret not including this, as modification of messages by MTAs and display of messages from legacy clients both are complicated issues, which sometimes interact with certificate profile considerations.  See recent header protection discussions on IETF LAMPS for more details.

*	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.

Be well,

Clint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20200218/ceb2fe25/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SMIME Charter 2020-02-12.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 26708 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20200218/ceb2fe25/attachment-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20200218/ceb2fe25/attachment-0001.p7s>