<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 13, 2016 at 10:13 PM, Jeremy Rowley via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_4709513654060931272WordSection1"><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?</p></div></div></blockquote><div><br></div><div>In general, permitting specific name types, with specific documentation on the information they contain, should be an OK thing.</div><div><br></div><div>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"</div><div><br></div><div>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 :) </div></div></div></div>