<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ryan,<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 18, 2018, at 6:57 AM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class="">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.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 18, 2018 at 8:31 AM, Tim Hollebeek <span dir="ltr" class=""><<a href="mailto:tim.hollebeek@digicert.com" target="_blank" class="">tim.hollebeek@digicert.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" class=""><div class="gmail-m_8365951703538584342WordSection1"><p class="MsoNormal">Yup. id-kp-serverAuth is always the server working group, not the S/MIME group.<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">I’d actually like to split id-kp-serverAuth into id-kp-serverAuth-browser and id-kp-serverAuth-<wbr class="">noBrowsersInvolved. It would make life much simpler.<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">-Tim<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt" class=""><div class=""><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in" class=""><p class="MsoNormal"><b class="">From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank" class="">public-bounces@<wbr class="">cabforum.org</a>] <b class="">On Behalf Of </b>Ryan Sleevi via Public<br class=""><b class="">Sent:</b> Thursday, May 17, 2018 10:18 PM<br class=""><b class="">To:</b> Phillip <<a href="mailto:philliph@comodo.com" target="_blank" class="">philliph@comodo.com</a>><br class=""><b class="">Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>><span class="gmail-"><br class=""><b class="">Subject:</b> Re: [cabfpub] For Discussion: S/MIME Working Group Charter<u class=""></u><u class=""></u></span></p></div></div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal">On Thu, May 17, 2018 at 9:53 PM, Phillip <<a href="mailto:philliph@comodo.com" target="_blank" class="">philliph@comodo.com</a>> wrote:<u class=""></u><u class=""></u></p><div class=""><div class="gmail-h5"><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><p class="MsoNormal">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.<u class=""></u><u class=""></u></p></div></div></blockquote><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">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 "<a href="http://www.google.com/" target="_blank" class="">www.google.com</a>", this does not somehow mean I exempt from the BRs or the existing scope of the server certificate working group.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">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.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p><p class="MsoNormal">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’.<u class=""></u><u class=""></u></p><p class="MsoNormal"> <u class=""></u><u class=""></u></p><p class="MsoNormal"> <u class=""></u><u class=""></u></p><p class="MsoNormal">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 ‘<a href="http://example.com/" target="_blank" class="">example.com</a>’, and not ‘alice@’, maybe it is better to perform validation on the organization.<u class=""></u><u class=""></u></p></div></div></blockquote></div></div></div><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><div class="gmail-h5"><div class=""><p class="MsoNormal">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.<u class=""></u><u class=""></u></p></div></div></div></div></div></div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""></div></blockquote></div><br class=""></div></body></html>