<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 10:28 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I know at least some platforms had issues with empty subject names.  </div></div></blockquote><div><br></div><div>That's a good point. For example, OS X has this limitation: a leaf certificate with an empty distinguished name, but has subjectAlternativeNames as a non-critical extension will be rejected. Similarly, a leaf certificate that asserts the CA bit with an empty subject will also be rejected, unless it's flagged as accepted that the leaf can be a CA (mostly, this arises with self-signed certs).</div><div><br></div><div>In an ideal world where we valued security over legacy, we would REQUIRE that subscriber certificates assert subjectAlternativeName as critical, to ensure (as best possible) that clients properly implemented sAN as the bare minimum for security, but I can understand that some people aren't ready to move off their insecure systems (c.f. SHA-1)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Right now only Common Name is carved out from “Subject Identity Information”, so another attribute type will probably need to be added to the carve out to allow CAs to issue a "Certificate complies
with these Requirements but lacks Subject Identity Information” and works with common clients.  I think there also needs to be a clear definition of what goes in that attribute when there is no subject identity asserted.</div></div></blockquote><div><br></div><div>I can get behind that argument.</div></div></div></div>