<div dir="ltr">Jeremy,<div><br></div><div>I'm not sure it was clear. otherName is a wide-open type, as defined in <a href="https://tools.ietf.org/html/rfc5280#section-4.2.1.6">https://tools.ietf.org/html/rfc5280#section-4.2.1.6</a></div><div><br></div><div>More accurately, it's</div><div><div>   OtherName ::= SEQUENCE {</div><div>        type-id    OBJECT IDENTIFIER,</div><div>        value      [0] EXPLICIT ANY DEFINED BY type-id }</div><div><br></div><div>I'm trying to suggest/request that otherNames only be permitted for defined type-ids, or some other appropriate rule/guidance to mitigate any collisions (e.g. only issued by an enterprise OID arc operated by the CA), to avoid name confusion.</div><div><br></div><div>For example, you wouldn't want CAs using Kerberos 5 identities in otherName, especially if that could cause issues/security problems with PKINIT-based systems.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 8:44 AM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_157399940119467152WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Agreed. The only types I want to permit are otherNames and rfc822Names.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">Jeremy<u></u><u></u></span></p><p class="MsoNormal"><a name="m_157399940119467152__MailEndCompose"><span style="font-size:11pt;font-family:calibri,sans-serif"><u></u> <u></u></span></a></p><span></span><p class="MsoNormal"><b><span style="font-size:11pt;font-family:calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:calibri,sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>] <br><b>Sent:</b> Wednesday, December 14, 2016 9:14 AM<br><b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Cc:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>><br><b>Subject:</b> Re: [cabfpub] rfc822Names and otherNames<u></u><u></u></span></p><div><div class="gmail-h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Tue, Dec 13, 2016 at 10:13 PM, Jeremy Rowley via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p><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"><div><div><p class="MsoNormal">Therefore, I’d like to modify the baseline requirements to permit other name types. Does anyone else see a need for this? Are there risks in permitting the additional names that I’m not aware of?<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In general, permitting specific name types, with specific documentation on the information they contain, should be an OK thing.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">However, letting CAs decide entirely will forever salt the earth there for being able to use those name types, and may result in additional security risk - much like the issues with validation and "any equivalent method"<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So, to the extent possible, I'd like to treat it as a validation method - that is, there's (generally) no harm in adding additional name types (provided they don't cause compat issues), so long as the industry can agree on the nature and structure of the data. Or make sure they're not technically capable of being used as TLS certs due to their issuing intermediate being technically restricted via EKU :) <u></u><u></u></p></div></div></div></div></div></div></div></div></blockquote></div><br></div></div></div>