[cabfpub] Creation of S/MIME Certificates Working Group

Fri Mar 13 17:51:16 UTC 2020

This doesn't incorporate Pedro's feedback, but this hopefully accurately
reflects Clint's proposal, with all of the proposed additions/deletions
provided by Apple, incorporated:
https://github.com/sleevi/cabforum-docs/blob/2020-03-13-SMCWG_Charter/docs/SMCWG-charter.md

To facilitate discussion, I've opened it up as a PR -
https://github.com/cabforum/documents/pull/167

Under the files tab, this allows you to suggest in-place edits, and helps
track the evolution of the document

On Fri, Mar 13, 2020 at 12:35 PM Pedro FUENTES <pfuentes at wisekey.com> wrote:

> Hello,
> I was about to send a new version of the doc with a couple of comments… I
> send it anyway, just in case.
>
> On my side, as main point I’m not in full agreement with the definition of
> the “Certificate Consumer” role.
>
> Considering the current formulation…
>
> *(2) A Certificate Consumer eligible for voting membership in the SMCWG
> must produce and maintain [1] a mail user agent (web-based or application
> based) or email service provider that processes S/MIME certificates[2] *
>
>
> I added this comment:
>
> This doesn’t seem fully clear. What are exactly the requirements for those
> that provide a mail user agent? Does “that processes S/MIME
> certificates” applies only to the email service provider or to both types
> of certificate consumers? What implies to “process S/MIME”… It should be
> maybe agreed that the certificate consumers must actively use S/MIME to
> sign/encrypt email, as a passive processing of the S/MIME parts not
> performing any action is not enough
>
>
> Best,
> Pedro
>
>
>
> On 13 Mar 2020, at 17:21, Ryan Sleevi via Public <public at cabforum.org>
> wrote:
>
> Thanks Clint.
>
> We still have a number of concerns, many of which have been captured in
> the minutes and, in past meetings, received commitment from DigiCert that
> these would be addressed.
>
> To avoid circulating a bunch of Word docs around, it seems like a
> reasonable next step would the conversion to Markdown and having inline
> discussion.
>
> Thematically, these elements include:
> 1) If natural or legal identity is included in scope, it's clearly
> indicated that work on such efforts will not begin until the successful
> adoption of standard controls on domain / email validation. For example,
> this was discussed at Thessaloniki and proposed by DigiCert -
> https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/ as
> an alternative to the previous path that DigiCert had agreed to in
> Cupertino .
>   - The solution for this needs to be a clear articulation of the priority
> of activities, and a commitment in charter that the identity work does not
> begin unless and until a common baseline has been delivered for
> email/domain validation
> 2) The removal of the government equivalent audit was something discussed
> in Cupertino -
> https://cabforum.org/2019/05/03/minutes-for-ca-browser-forum-f2f-meeting-46-cupertino-12-14-march-2019/ -
> as being intentional to prevent unnecessary exclusion. For example, see the
> discussion regarding the US Federal PKI's approach
>   - It looks like there was some concern about why this bullet existed,
> and its removal might have just been due to lack of context with the past
> discussions
> 3) The transition from "updates" to "support" misses much of the intent
> with Ballot 205 -
> https://cabforum.org/2017/07/06/ballot-205-membership-related-clarifications/
>
>   - It introduces a new issue, regarding "end of life", which potentially
> allows one to declare an "end of life" in 2038, and then ceases all
> maintenance, while qualifying "support" as providing online documentation
>   - Given that this document strives to be a living document of best
> practices, the intent in Ballot 205 and with the original (now stricken)
> language was to ensure that participants were invested in the success of
> the ecosystem. I'm not sure this proposed change adequately encourages this?
>   - To be fair, this is somewhat mooted by the fact that if the Forum
> fails to be a useful venue for discussion, Root Programs can and will make
> and discuss changes through their existing Root Program policies, so it may
> be that this is perfectly fine, but just sets up that probability even
> greater
> 4) The use of "publicly trusted root" and "publicly trusted" certificate
> are ill-defined
>   - We know and have seen repeatedly the concerns and confusion this
> causes in the SCWG
>   - Any attempt to tie this back to Certificate Consumer is just going to
> create a circular dependency
>   - The SMCWG's scope is to create a common set of minimum guidelines
> which can be used by Certificate Consumers in evaluating Certificate
> Issuers, such as by Certificate Issuers incorporating these guidelines into
> their CP/CPS and through the use of audits which derive auditable criteria
> that evaluate against such guidelines
>
> These are just a small sampling of some of the issues we've discussed in
> the past. I appreciate the energy towards getting this out, and I'm glad to
> see that progress is being made in actually updating these to reflect
> discussions, but despite the amount of time that's passed since we first
> began discussing, there are still many core, systemic issues to work
> through, and still ample feedback that has been provided in good faith that
> has been committed to be integrated, but not yet integrated. I don't mean
> that as a criticism for Apple's many welcome improvements, merely that we
> should continue with this enthusiasm to update, while making sure we're not
> overlooking things.
>
>
> On Thu, Mar 12, 2020 at 11:07 AM Clint Wilson <clintw at apple.com> wrote:
>
>> Sure thing, here’s a Word formatted version :)
>>
>>
>>
>> On Mar 12, 2020, at 8:05 AM, Ryan Sleevi <sleevi at google.com> wrote:
>>
>> Hey Clint,
>>
>> Is it possible to convert that file to a standard format? I'm having
>> trouble opening it
>>
>> On Wed, Mar 11, 2020 at 10:30 PM Clint Wilson <clintw at apple.com> wrote:
>>
>>> Hello all,
>>>
>>> I’ve attached below an updated draft charter which addresses the
>>> concerns I raised previously, especially with regards to section 4.2.3.
>>> There are additionally changes seeking to address Tim and Ryan’s
>>> comments/responses below and a few minor updates that seemed warranted as I
>>> went through another comprehensive review of the document. For each area
>>> changed, there is a corresponding comment; if anything is unclear, please
>>> let me know and I’d be happy to address.
>>>
>>> Thank you for your patience and understanding in getting this back to
>>> the group. Have a great evening!
>>> -Clint
>>>
>>>
>>>
>>> On Feb 18, 2020, at 1:57 PM, Ryan Sleevi via Public <public at cabforum.org>
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Feb 18, 2020 at 1:57 PM Tim Hollebeek via Public <
>>> public at cabforum.org> wrote:
>>>
>>>>
>>>>    - 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.
>>>>
>>>
>>> I'm not quite sure I understand this rationale, could you explain more.
>>>
>>> Why does this charter need to follow the SCWG/CSWG charter? Who is "all
>>> involved" that would be confused?
>>>
>>> It seems very valuable to learn from mistakes and concerns and address
>>> them, but perhaps I'm overlooking something?
>>>
>>>
>>>>
>>>>    - 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.
>>>>
>>>
>>> I understand one group was the Code Signing Working Group, which perhaps
>>> did not have careful or close review from all Forum members due to the
>>> explicit lack of intent to participate in the venue or fundamental
>>> disagreements about the working group objectives.
>>>
>>> However, I'm not sure, what's the other Chartered Working Group you're
>>> thinking of? The SCWG explicitly did not follow this process, as part of
>>> the Legacy Working Group transition, and so I'm not sure what the other CWG
>>> is that avoided this?
>>>
>>> Also, while I agree that this was discussed extensively, I must
>>> respectfully disagree that the "current procedures were deemed to be
>>> sufficient". The current (proposed) procedures were known to be problematic
>>> in bootstrapping, something we discussed, and something we knew we could
>>> avoid by defining an open and welcoming charter. This WG does not seem to
>>> set out to do this.
>>>
>>> In all fairness, this seems a repeat of the same issues the bedeviled,
>>> and nearly derailed, the Forum in it's first start. The attempt to exclude
>>> some CAs, via narrowly and restrictively scoped membership, nearly resulted
>>> in the implosion of the Forum, as the management@ archives from 2009
>>> show. Ultimately, it was the Forum's rejection of such exclusionary
>>> attempts that helped grow the membership. In particular, it was DigiCert
>>> who some were trying to prevent from joining the Forum, so it would be
>>> unfortunate to have DigiCert repeat that same process.
>>>
>>> I'm hoping you're open to addressing these issues, but I don't think we
>>> can support the charter without this issue being addressed.
>>> _______________________________________________
>>> Public mailing list
>>> Public at cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>>>
>>>
>>>
>> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200313/a952c471/attachment-0003.html>