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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: > >> Sure thing, here’s a Word formatted version :) >> >> >> >> On Mar 12, 2020, at 8:05 AM, Ryan Sleevi <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>> >>> >>> >>> On Tue, Feb 18, 2020 at 1:57 PM Tim Hollebeek via Public < >>> [email protected]> 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 >>> [email protected] >>> https://cabforum.org/mailman/listinfo/public >>> >>> >>> >> _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
