[cabfpub] Update about S/MIME Charter

[Tim Hollebeek]

And, I forgot one other important point that I wanted to call out.
Microsoft commented on earlier drafts of the charter in the previous ballot,
and one of their concerns was that S/MIME emails sent from automated systems
and mailing lists that contain identity information could potentially be
construed as out of scope.  That led to language in the previous ballot
explicitly including such emails in the scope.

 

That language was discussed, and the consensus was that those emails remain
in scope, even without the additional language, and therefore the additional
language is unnecessary (and potentially harmful).  So it was removed.  It
would be useful to know if Microsoft agrees with that interpretation,
otherwise we are going to have to find another solution to that issue.

 

-Tim

 

From: Public <public-bounces at cabforum.org> On Behalf Of Tim Hollebeek via
Public
Sent: Friday, April 17, 2020 7:57 PM
To: CABforum1 <public at cabforum.org>
Subject: [cabfpub] Update about S/MIME Charter

 

 

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:

 

https://github.com/clintwilson/cab-docs/blob/SMCWG-draft-feedback/docs/SMCWG
-charter.md

 

Apple, DigiCert, and Mozilla support this proposal.  If we're reading Ryan's
github comments correctly, it seems he also supports this version of the
charter, though I will let him speak for himself on that topic.

 

It would be useful if people began reviewing this charter proposal, and if
there are additional comments, hopefully we can get them resolved soon.  We
should also discuss ballot language and a potential path forward towards
getting this adopted, and I agree with Ryan that it would be more useful if
that discussion happened on the public list (or github).

 

DigiCert would vote for the current charter as proposed by Apple, but there
is one point that I did notice while reviewing it one last time, and it
relates to the following provision:

 

"Certificates issued under a root certificate that is not publicly trusted
SHALL be out of scope."

 

I have two comments:

 

1.	The concept of "root certificate" is clear in most circumstances,
but in messy PKIs that involve cross signing and other complicated trust
relationships, it can get a bit fuzzy.  And the S/MIME ecosystem is
certainly very messy right now.  One potential fix is to change it to "Root
Certificate", so it refers to the defined term in the Baseline Requirements.
But then everyone has to agree that that's what we mean, and not something
else.
2.	Second, related to the first point, "publicly trusted" can be a bit
ambiguous, especially with respect to a new working group like S/MIME, where
we do not know in advance who the Certificate Consumers will be.  Language
along the lines of "that is not trusted by any participating Certificate
Consumer" would probably be more clear.  And what does trusted mean?  What
if it chains to a trusted ICA, but that ICA has been blacklisted by all
Certificate Consumers via their revocation mechanisms?  It would be useful
to definitively say what we mean up front, to avoid differences of
interpretation later.

 

Additional clarity and precision in expressing this requirement would
probably be helpful, and I'd welcome discussion and suggestions.  Or we
could just go with the current language, acknowledging its potential
limitations.

 

-Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200418/57dc8e51/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200418/57dc8e51/attachment-0003.p7s>