Re: [cabfpub] Draft SMIME Working Group Charter
On Mon, Jan 28, 2019 at 3:28 PM Tim Hollebeek wrote: > Because diverse and sometimes even contradictory root program requirements > are not a good thing. It seems like we should be able to reach agreement > on what the minimum criteria should be, just as we have for TLS. > I'm not sure which part you're replying to, but the diversity of audit requirements is already something we already have with TLS, and I don't see any signs of that changing. Perhaps you can help me understand how a normative membership requirement on audits furthers that goal. > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Monday, January 28, 2019 3:14 PM > *To:* Tim Hollebeek > *Cc:* Wayne Thayer ; CA/Browser Forum Public > Discussion List > *Subject:* Re: [cabfpub] Draft SMIME Working Group Charter > > > > > > > > On Mon, Jan 28, 2019 at 2:44 PM Tim Hollebeek > wrote: > > I’m fine with “or equivalent” exceptions for various use cases, as long as > we specify what those are and they accomplish the same goals. I do have > strong opinions about how “*.gov” should be managed, specifically that I > don’t think it’s possible to assure that the domain portion of the email is > being consistently validated, absent some oversight by some independent > entity. > > > > I suppose this will be a core part of the discussion, then. I will, > however, note that ICANN has adopted a very different philosophy than you > with respect to domain names, and similarly, Microsoft has recognized the > distinction with how they manage their program. This also aligns with a > variety of other technology and non-technology sectors, and is, perhaps, a > core part of disagreement. > > > > Could you help me understand why, for purposes of CA/B Forum membership, > you believe they should be overseen by someone that the CA/B Forum > designates, rather than by an entity that a root program designates? > Perhaps I'm missing why it's important to exclude these parties from the > Forum, as that might help clarify the language. > ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
Because diverse and sometimes even contradictory root program requirements are not a good thing. It seems like we should be able to reach agreement on what the minimum criteria should be, just as we have for TLS. -Tim From: Ryan Sleevi Sent: Monday, January 28, 2019 3:14 PM To: Tim Hollebeek Cc: Wayne Thayer ; CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Draft SMIME Working Group Charter On Mon, Jan 28, 2019 at 2:44 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: I’m fine with “or equivalent” exceptions for various use cases, as long as we specify what those are and they accomplish the same goals. I do have strong opinions about how “*.gov” should be managed, specifically that I don’t think it’s possible to assure that the domain portion of the email is being consistently validated, absent some oversight by some independent entity. I suppose this will be a core part of the discussion, then. I will, however, note that ICANN has adopted a very different philosophy than you with respect to domain names, and similarly, Microsoft has recognized the distinction with how they manage their program. This also aligns with a variety of other technology and non-technology sectors, and is, perhaps, a core part of disagreement. Could you help me understand why, for purposes of CA/B Forum membership, you believe they should be overseen by someone that the CA/B Forum designates, rather than by an entity that a root program designates? Perhaps I'm missing why it's important to exclude these parties from the Forum, as that might help clarify the language. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
On Mon, Jan 28, 2019 at 2:44 PM Tim Hollebeek wrote: > I’m fine with “or equivalent” exceptions for various use cases, as long as > we specify what those are and they accomplish the same goals. I do have > strong opinions about how “*.gov” should be managed, specifically that I > don’t think it’s possible to assure that the domain portion of the email is > being consistently validated, absent some oversight by some independent > entity. > I suppose this will be a core part of the discussion, then. I will, however, note that ICANN has adopted a very different philosophy than you with respect to domain names, and similarly, Microsoft has recognized the distinction with how they manage their program. This also aligns with a variety of other technology and non-technology sectors, and is, perhaps, a core part of disagreement. Could you help me understand why, for purposes of CA/B Forum membership, you believe they should be overseen by someone that the CA/B Forum designates, rather than by an entity that a root program designates? Perhaps I'm missing why it's important to exclude these parties from the Forum, as that might help clarify the language. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
I’m fine with “or equivalent” exceptions for various use cases, as long as we specify what those are and they accomplish the same goals. I do have strong opinions about how “*.gov” should be managed, specifically that I don’t think it’s possible to assure that the domain portion of the email is being consistently validated, absent some oversight by some independent entity. For government entities, that may be some regulatory body and/or internal review process instead of a traditional WebTrust/ETSI audit, but we should at least make sure that someone is responsible for making sure appropriate controls are in place. -Tim From: Ryan Sleevi Sent: Monday, January 28, 2019 2:22 PM To: Tim Hollebeek Cc: Wayne Thayer ; CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Draft SMIME Working Group Charter On Mon, Jan 28, 2019 at 2:17 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: The intent was that Forum level membership was the union of all CWG membership criteria. If you’re able to join a CWG, you’re a Forum member. I think allowing in unaudited Certificate Issuers would be a huge step backwards. Note that the proposal was not "unaudited" - merely, that the definition of audit be left to "Certificate Consumer", which participation with is already a required property. For example, some Consumers allow audits by government entities, but then constrain issuance using application-specific means (since, after all, this is a trust anchor). Others allow for equivalent audit schemes at their discretion. Thus, it also runs the risk of being a "step backward" to have members who are bound by various rules (such as an S/MIME Guideline) but that are prevented by the Forum from joining unless they change their business, governance, or auditability model. An example of this concretely is the Federal PKI operated in the US. While for SSL/TLS cases, I may be more inclined to agree, S/MIME represents a particular area where given the nature of the 'localpart' of email addresses (fully in control of the organization), delegated CAs and trust relationships are far more common. For example, I don't have strong opinions on how "*.gov" should be managed, with respect to S/MIME, provided that the domain portion of the email is consistently validated. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
On Mon, Jan 28, 2019 at 2:17 PM Tim Hollebeek wrote: > The intent was that Forum level membership was the union of all CWG > membership criteria. If you’re able to join a CWG, you’re a Forum member. > > > > I think allowing in unaudited Certificate Issuers would be a huge step > backwards. > Note that the proposal was not "unaudited" - merely, that the definition of audit be left to "Certificate Consumer", which participation with is already a required property. For example, some Consumers allow audits by government entities, but then constrain issuance using application-specific means (since, after all, this is a trust anchor). Others allow for equivalent audit schemes at their discretion. Thus, it also runs the risk of being a "step backward" to have members who are bound by various rules (such as an S/MIME Guideline) but that are prevented by the Forum from joining unless they change their business, governance, or auditability model. An example of this concretely is the Federal PKI operated in the US. While for SSL/TLS cases, I may be more inclined to agree, S/MIME represents a particular area where given the nature of the 'localpart' of email addresses (fully in control of the organization), delegated CAs and trust relationships are far more common. For example, I don't have strong opinions on how "*.gov" should be managed, with respect to S/MIME, provided that the domain portion of the email is consistently validated. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
The intent was that Forum level membership was the union of all CWG membership criteria. If you’re able to join a CWG, you’re a Forum member. I think allowing in unaudited Certificate Issuers would be a huge step backwards. -Tim From: Public On Behalf Of Wayne Thayer via Public Sent: Friday, January 25, 2019 2:06 PM To: Ryan Sleevi Cc: CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Draft SMIME Working Group Charter On Fri, Jan 25, 2019 at 11:45 AM Ryan Sleevi mailto:sle...@google.com> > wrote: On Fri, Jan 25, 2019 at 1:37 PM Wayne Thayer mailto:wtha...@mozilla.com> > wrote: I agree that we should exclude identity validation from the initial scope of this working group. On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public mailto:public@cabforum.org> > wrote: Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate. This would allow a CA that is not eligible for full Forum membership to join this WG as a full member. How would that work? Would we require such an organization to join the Forum as an Interested Party? If the idea is that such an organization wouldn't be required to join the Forum, then I don't believe that was anticipated or intended in the design of the current structure. It's not clear to me that we should permit membership in a CWG without Forum membership. For instance, allowing this may create loopholes in the IPR obligations that are defined and administered at the Forum level. Ah, drat, thanks for pointing that out, Wayne. You're right that the changes would need to be accompanied by changes the Forum-level bylaws membership, whether to be more explicit (e.g. government issuers w/ their own audit frameworks, as an example, such as the FPKI) or more implicitly inclusive as this proposed. Absent a Bylaw change, it sounds like the most such folks could achieve would be Interested Party in the CWG. Does that match your understanding? I'm not aware of anything that requires membership in a CWG to be at a level equivalent to that of the Forum, but I do think that is the intent of the bylaws. There may be no harm in having an Interested Party at the Forum level be a full member of a CWG, but I think it would be best for that to be clarified in the bylaws before creating a CWG with looser membership criteria than the Forum. smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
On Fri, Jan 25, 2019 at 11:45 AM Ryan Sleevi wrote: > > On Fri, Jan 25, 2019 at 1:37 PM Wayne Thayer wrote: > >> I agree that we should exclude identity validation from the initial scope >> of this working group. >> >> On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public < >> public@cabforum.org> wrote: >> >>> >>> Finally, regarding membership criteria, I'm curious whether it's >>> necessary to consider WebTrust for CAs / ETSI at all. For work like this, >>> would it make sense to merely specify the requirements for a CA as one that >>> is trusted for and actively issues S/MIME certificates that are accepted by >>> a Certificate Consumer. This seems to be widely inclusive and can be >>> iterated upon if/when improved criteria are developed, if appropriate. >>> >>> This would allow a CA that is not eligible for full Forum membership to >> join this WG as a full member. How would that work? Would we require such >> an organization to join the Forum as an Interested Party? If the idea is >> that such an organization wouldn't be required to join the Forum, then I >> don't believe that was anticipated or intended in the design of the current >> structure. It's not clear to me that we should permit membership in a CWG >> without Forum membership. For instance, allowing this may create loopholes >> in the IPR obligations that are defined and administered at the Forum level. >> > > Ah, drat, thanks for pointing that out, Wayne. You're right that the > changes would need to be accompanied by changes the Forum-level bylaws > membership, whether to be more explicit (e.g. government issuers w/ their > own audit frameworks, as an example, such as the FPKI) or more implicitly > inclusive as this proposed. Absent a Bylaw change, it sounds like the most > such folks could achieve would be Interested Party in the CWG. Does that > match your understanding? > I'm not aware of anything that requires membership in a CWG to be at a level equivalent to that of the Forum, but I do think that is the intent of the bylaws. There may be no harm in having an Interested Party at the Forum level be a full member of a CWG, but I think it would be best for that to be clarified in the bylaws before creating a CWG with looser membership criteria than the Forum. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
I agree that we should exclude identity validation from the initial scope of this working group. On Fri, Jan 25, 2019 at 10:04 AM Ryan Sleevi via Public wrote: > > Finally, regarding membership criteria, I'm curious whether it's necessary > to consider WebTrust for CAs / ETSI at all. For work like this, would it > make sense to merely specify the requirements for a CA as one that is > trusted for and actively issues S/MIME certificates that are accepted by a > Certificate Consumer. This seems to be widely inclusive and can be iterated > upon if/when improved criteria are developed, if appropriate. > > This would allow a CA that is not eligible for full Forum membership to join this WG as a full member. How would that work? Would we require such an organization to join the Forum as an Interested Party? If the idea is that such an organization wouldn't be required to join the Forum, then I don't believe that was anticipated or intended in the design of the current structure. It's not clear to me that we should permit membership in a CWG without Forum membership. For instance, allowing this may create loopholes in the IPR obligations that are defined and administered at the Forum level. There's also a bootstrapping issue for membership, in that until we know > who the accepted Certificate Consumers are, no CA can join as a Certificate > Issuer. I'm curious whether it makes sense to explicitly bootstrap this in > the charter or how we'd like to tackle this. > > ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Draft SMIME Working Group Charter
Thanks for starting this, Ben! I have a long list of feedback, which I wanted to provide on the list to be transparent about the motivations and goals, although I'll also duplicate them as suggested edits on the doc after sending this, to provide more concrete and hopefully productive guidance. I realize this has gone through several edits now, but I'm concerned that as a result of those edits, it seems to be going in a very different direction than was discussed in Shanghai and London, and hoping that's largely oversight or ambition. Specifically, we looked at the case that various S/MIME certificates are also granted for other purposes - for example, document signing or client ID. CAs and some root store members were keen to avoid conflicting requirements with existing issuance practices; that is, their desire was to specify what was practiced, rather than an aspirational side. On the other hand, other members expressed a desire to express a clear minimum set of technical requirements - such as a common agreement on validation for the core function (such as e-mail) and algorithm profiles, without necessarily considering existing certificates. Perhaps most complicated of this space was the view of identity. There's a clear spectrum of existing deployments, ranging from a notion that might be best described as "Enterprise RA" - in which a domain is vetted to belong to an organization and they subsequently vet the localpart to those that might be described as "Legal Identity Frameworks", in which some legally-empowered entity makes full assertion about the legal identity, and the e-mail is perhaps not even validated at all, but merely self-attested. The suggestion made at Shanghai was, for both scope and agility, to focus on the core technical profile. In particular, what is the core necessary and sufficient part for an S/MIME certificate. I came away with the impression that there was consensus that, at the core, S/MIME is useful for the RFC 822 validation of the e-mail address. Other pieces of information - such as legal identity - were 'value added' but not core to the definition, and thus optional. We (Google) see significant value in S/MIME even without asserting legal identity, in helping both authenticate and encrypt e-mails. This is not just a philosophical difference - one we've certainly shared in the past for other certificates - but one that's also reflected in existing widespread industry practice. This path is the path that EV took, in which CAs by and large had to make changes, some moreso than others, to approach the path of EV. Similarly, as many CAs know, the Baseline Requirements ultimately required a number of CAs to change their issuance practices, and existing, non-BR compliant certificates and CAs are no longer trusted in the ecosystem. The most recent edit appears to have been influenced to go to the other extreme, of asserting legal identity, and that seems to bring with it all of the significant concerns about both compatibility and naming that seemed entirely avoidable and, arguably, non-essential to a "Baseline" document. With that context and backstory, I'll try to highlight specific areas that seem problematic: > An S/MIME certificate contains the public key bound to an identity of a natural person or legal entity. This is a more recent edit that very explicitly states that S/MIME certificates are about legal identities. Previous edits suggested "used by", which was less problematic, as it was both descriptive and non-exhaustive. However, I think it'd be much more valuable for the scope of activities of the WG if we can focus on the core baseline of validating e-mails, and thus I would assert that the necessary and sufficient definition here should be: *An S/MIME certificate contains a public key bound to an email address.* > For effective authentication and privacy, it is imperative that the CA validates the subject’s identity and its email address. Similarly, in previous edits, this correctly only stated that the CA validates the subject's email address as the core competency and function. That's not discounting that identity may be valuable in some situations, but at its core, S/MIME only needs vet the e-mail address. *For effective authentication and privacy, it is imperative that the CA validates the subject's email address.* > to the public key, email address, and distinguished name contained This is another recent edit, which introduces "and distinguished name". I would similarly request this be removed, and it be asserted that the core validation is to the public key and email address. > to validate an email address and the subject’s identity prior to binding it to the email address. This entire paragraph appears new from earlier drafts. Unfortunately, it's intimately tied to the validation of the subject identity and existing identity management frameworks, which significantly undermines the utility of the S/MIME WG. Here I'm torn on how to
[cabfpub] Draft SMIME Working Group Charter
Here is a draft SMIME WG Charter. Please provide your comments. https://docs.google.com/document/d/1vEswtzzMm0_G0ujoAT5ChiajyqfRfDTydG9Nmsc-eo4/edit?usp=sharing Thanks, Ben Wilson ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
