Ryan, I agree that “splitting” that existing EKU is not productive. However I would not shoot things down so quickly. In addition to a different PKI, it is also completely possible to simply define a new EKU (id-kp-iot-serverAuth or something) that has its own rules for validation. Bonus points if the specification has a RAND-Z/FRAND license.
What I think this is pointing out is that we need to consider whether there should be a WG/guideline that covers all types of certificates issued from a “publicly trusted” PKI so that the iot-serverAuth (and id-kp-emailProtection) working groups don’t have to reinvent the whole wheel. Thanks, Peter > On May 18, 2018, at 6:57 AM, Ryan Sleevi via Public <public@cabforum.org> > wrote: > > 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.holleb...@digicert.com > <mailto:tim.holleb...@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-boun...@cabforum.org > <mailto:public-boun...@cabforum.org>] On Behalf Of Ryan Sleevi via Public > Sent: Thursday, May 17, 2018 10:18 PM > To: Phillip <phill...@comodo.com <mailto:phill...@comodo.com>> > Cc: CA/Browser Forum Public Discussion List <public@cabforum.org > <mailto:public@cabforum.org>> > Subject: Re: [cabfpub] For Discussion: S/MIME Working Group Charter > > > > > > > > On Thu, May 17, 2018 at 9:53 PM, Phillip <phill...@comodo.com > <mailto:phill...@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 <http://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 <http://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 > Public@cabforum.org > https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
