[cabfpub] For Discussion: S/MIME Working Group Charter

Ryan Sleevi sleevi at google.com
Fri May 18 13:57:17 UTC 2018


To avoid unnecessary and potentially wasted effort: I don't think exploring
such a split would be productive. There's already a way you can do that
split. It's called use a different PKI.

On Fri, May 18, 2018 at 8:31 AM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Yup.  id-kp-serverAuth is always the server working group, not the S/MIME
> group.
>
>
>
> I’d actually like to split id-kp-serverAuth into id-kp-serverAuth-browser
> and id-kp-serverAuth-noBrowsersInvolved.  It would make life much simpler.
>
>
>
> -Tim
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Thursday, May 17, 2018 10:18 PM
> *To:* Phillip <philliph at comodo.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter
>
>
>
>
>
>
>
> On Thu, May 17, 2018 at 9:53 PM, Phillip <philliph at comodo.com> wrote:
>
> We seem to have a terminology issue here. What is a server? This is
> obvious in HTTP but far from obvious in the context of email because there
> is an inbound and an outbound ‘server’ and it acts as a client and a server
> at different times.
>
>
>
> I'm afraid that discussion misses an important word in the discussion -
> server *certificate*. That word helps us clarify that we're speaking about
> certificates and their capabilities, not about the different flows in
> different protocols. If I use an id-kp-serverAuth certificate with a SAN of
> "www.google.com", this does not somehow mean I exempt from the BRs or the
> existing scope of the server certificate working group.
>
>
>
> So I think we can avoid such discussions about the terminology of servers,
> and instead focus on the certificates and the existing charted working
> group, which handles such certificates, regardless of the service context
> or the role within the protocol.
>
>
>
>
>
> I agree that certificates used to authenticate Mail Transport Agents are
> properly part of what the Server WG is specifying. But they may be used by
> a host acting as a TLS ‘server’ or ‘client’.
>
>
>
>
>
> Another little oddity is that we are assuming that the entity a CA
> validates and issues certificates to in the S/MIME world is properly the
> end user rather than the organization. That might not be the right
> approach. If what the CA is effectively validating is ‘example.com’, and
> not ‘alice@’, maybe it is better to perform validation on the
> organization.
>
>
>
> I think that's something that could be discussed by the S/MIME WG - with a
> refined charter scoped to S/MIME BRs. That discussion does not seem to
> conflict with such a charter scoped simply to the BRs, as what you're
> discussing is validation methods, which would be rather premature to
> discuss in the absence of such a chartered group.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180518/a2c5a7bb/attachment-0003.html>


More information about the Public mailing list