[cabfpub] Update about S/MIME Charter

Tim Hollebeek tim.hollebeek at digicert.com
Fri Apr 17 23:57:17 UTC 2020


 

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/20200417/a431d2f1/attachment-0002.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/20200417/a431d2f1/attachment-0002.p7s>


More information about the Public mailing list