<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 14, 2016, at 11:22 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</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=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Apr 14, 2016 at 10:28 PM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.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 style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">I know at least some platforms had issues with empty subject names.  </div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""> </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" class=""><div class="">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 class=""><br class=""></div><div class="">I can get behind that argument.</div></div></div></div>
</div></blockquote></div><br class=""><div class=""><font face="Arial" class="">It was also pointed out to me that section 4.2.1.6 of RFC 5280 (<a href="https://tools.ietf.org/html/rfc5280#section-4.2.1.6" class="">https://tools.ietf.org/html/rfc5280#section-4.2.1.6</a>) says:</font></div><div class=""><font face="Arial" class=""><br class=""></font></div><div class=""><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; widows: 1;"><font face="Arial" class="">   Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present.</font></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; widows: 1;"><font face="Arial" class=""><br class=""></font></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; widows: 1;"><font face="Arial" class="">4.1.2.6 also says:</font></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; widows: 1;"><font face="Arial" class=""><br class=""></font></pre><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; widows: 1;"><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px;"><font face="Arial" class="">   If subject
   naming information is present only in the subjectAltName extension
   (e.g., a key bound only to an email address or URI), then the subject
   name MUST be an empty sequence and the subjectAltName extension MUST
   be critical.</font></pre><div class=""><font face="Arial" class=""><br class=""></font></div></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="Arial" class=""><span style="white-space: normal;" class="">This implies that those of us creating a CN-only subject for server auth certs are not following RFC 5280.  So including other info not only ensures the subject will not be empty without CN but also ensures that other subject naming information is present.  Looking at the list of attribute types that are listed as MUST be supported by software using certs, distinguished name qualifier (dnQualifier) seems like the best candidate for an attribute to add to the SII exclusion list.  X.520 says:</span></font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><span style="white-space: normal;" class=""><font face="Arial" class=""><br class=""></font></span></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><span style="white-space: normal;" class=""><font face="Arial" class="">"</font></span><span style="font-size: 10pt; font-family: TimesNewRoman;" class="">The </span><span style="font-size: 10pt; font-family: 'TimesNewRoman,Italic';" class="">DN Qualifier </span><span style="font-size: 10pt; font-family: TimesNewRoman;" class="">attribute type specifies disambiguating information to add to the relative distinguished name of an
entry. It is intended to be used for entries held in multiple DSAs which would otherwise have the same name, and that its
value be the same in a given DSA for all entries to which this information has been added.</span><font face="TimesNewRoman" size="3" class="">”</font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><span style="font-size: 10pt; font-family: TimesNewRoman;" class=""><br class=""></span></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="TimesNewRoman" size="3" class="">This seems ideal — each CA define a dnQualifier, either per CA or one shared by a group of CAs all sharing a single DSA/DIT.  It is a printableString, so easily supports inclusion of a space to ensure that the dnQualifier is not confused with a valid hostname.</font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="TimesNewRoman" size="3" class=""><br class=""></font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="TimesNewRoman" size="3" class="">Does adding dnQualifier to the list of things not considered subject identity information make sense?</font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="TimesNewRoman" size="3" class=""><br class=""></font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="TimesNewRoman" size="3" class="">Thanks,</font></pre><pre class="newpage" style="widows: auto; margin-top: 0px; margin-bottom: 0px;"><font face="TimesNewRoman" size="3" class="">Peter</font></pre></div></body></html>