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 <[email protected]> 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:[email protected]] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Thursday, May 17, 2018 10:18 PM > *To:* Phillip <[email protected]> > *Cc:* CA/Browser Forum Public Discussion List <[email protected]> > *Subject:* Re: [cabfpub] For Discussion: S/MIME Working Group Charter > > > > > > > > On Thu, May 17, 2018 at 9:53 PM, Phillip <[email protected]> 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. >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
