<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 20, 2017, at 12:34 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Fri, Oct 20, 2017 at 3:14 PM, Geoff Keating<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:geoffk@apple.com" target="_blank" class="">geoffk@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class="">On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank" class="">sleevi@google.com</a>> wrote:</div><br class="gmail-m_-3645049599872352793Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""></div></blockquote><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""></div></blockquote></div></div></div></div></blockquote><br class=""></span><span class="gmail-"><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">- How this matches with the X.520 definition of dnQualifier, in particular the second sentence:</div><div class=""><br class=""></div><div class="">The DN Qualifier attribute type specifies disambiguating information to add to the relative distinguished nam<wbr class="">e 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.</div></div></blockquote><div class=""><br class=""></div><div class="">This matches 1:1. Is there a concern that it doesn't match, or that more rules are necessary?</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">What I quoted above is X.520.  It doesn't seem to me to be describing the same thing as the ballot.  In particular, normally you would consider a CA’s issuing infrastructure to be one single DSA, which produces a contradiction between the ballot text "The CA MAY set the dnQualifer value to the base64 encoding of the SHA1 hash of the subjectAlternativeName” and X.520’s text “its value be the same in a given DSA”.</div><span class="gmail-"><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">- How this is actually intended to be used in the web PKI?</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">As raised on our most recent call, one notable thing is that this allows CAs to issue single certificates for domain names greater than 64 characters, at a DV level, while interoperably working with the Web PKI. This flows as follows:</div><div class=""><br class=""></div><div class="">- The X.509/RFC 5280 definition for commonName is limited to 64 characters.</div><div class="">- If you have a certificate with a domain name greater than 64 characters, you cannot place it in the common name of the subject.</div><div class="">- The common name of the subject may only contain domain names and IP addresses.</div><div class="">- All other specified fields of the Subject must be validated to OV level.</div><div class=""><br class=""></div><div class="">As a consequence, the only way with DV today to represent these certificates is with an empty sequence for the subject name and a critical subjectAltName, pursuant with RFC5280. You can see this at<span class="Apple-converted-space"> </span><a href="https://no-subject.badssl.com/" target="_blank" class="">https://no-subject.badssl.com</a></div><div class=""><br class=""></div><div class="">If you tried to load that on Apple iOS, it would load.</div><div class="">If you tried to load that on Apple macOS earlier than 10.10, it would load.</div><div class="">If you tried to load that on Apple macOS since 10.10, it will fail, as empty subjects are no longer supported.</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">It works for me in 10.11—so does that mean this ballot is no longer needed?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Just tested 10.12 and 10.13 and it's still failing - perhaps it was a point release of 10.11?</div></div></div></blockquote><div><br class=""></div><div>*sigh* too many version numbers, all in the 10-13 range!  I meant macOS High Sierra 10.13, build 17A405.  That works for me when I use Safari to browse to <a href="https://no-subject.badssl.com" class="">https://no-subject.badssl.com</a>.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">Yes, it's still needed. While I highlighted Apple products specifically (given the affiliation), the problem actually affects a number of clients - hence why badssl has that site.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">This provides a way for a CA to ensure that a DV certificate with a domain name of more than 64 characters can be issued, by using the dnQualifier field (which is CA-controlled, as noted in the relevant X.520 text you cited) to serve as a disambiguator between certificates the CA has issued.</div><div class=""><br class=""></div><div class="">Does that help capture it?</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I see the problem but I’m very hesitant to standardise something in CABforum which contradicts X.520.</div><div class=""><br class=""></div><div class="">Have we really explored other alternatives?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think we have. What would help you get that confidence?</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""> For example, truncate the commonName to 60 characters and append an ellipsis in Unicode (“…”) so that it can’t be confused with a domain name.</div></div></div></blockquote><div class=""><br class=""></div><div class="">That seems significantly more dangerous - for example, there's no guarantee that the ellipsis avoids confusion, particularly in the conversion routine. I'm also not sure I understand the concern regarding X.520 - which the Forum has otherwise ignored in other specification of Subject naming attributes when establishing rules.</div><div class=""><br class=""></div><div class="">Is the substance the concern about X.520 - that is, if there is a solution to address your concern, then there's no need to get creative here?</div><div class=""><br class=""></div><div class="">For example, you can find decades-old discussion in the IETF making the same arguments you're making here, and similar disagreement about the conclusions you're reaching (e.x. <a href="https://www.ietf.org/mail-archive/web/pkix/current/msg23992.html" class="">https://www.ietf.org/mail-archive/web/pkix/current/msg23992.html</a><span class="Apple-converted-space"> </span>)</div></div></div></blockquote><div><br class=""></div><div>I don’t think there was, ultimately, disagreement.  That discussion appears to terminate with this message:</div><div><br class=""></div><div><a href="https://www.ietf.org/mail-archive/web/pkix/current/msg23960.html" class="">https://www.ietf.org/mail-archive/web/pkix/current/msg23960.html</a></div><div><br class=""></div><div>and the outcome was the creation of the uniqueIdentifier attribute (described in X.520 immediately before the section which describes dnQualifier).  So now there are clearly two fields, one of which is used to distinguish between the same DN in a DSA and the other distinguishes between different DSAs.  The uniqueIdentifier description even says</div><div><br class=""></div><div></div><blockquote type="cite" class=""><div>It may be, for example, an encoded object identifier, certificate, date, timestamp, or some other form of certification on the validity of the distinguished name.</div></blockquote><div><br class=""></div><div>which sounds like the perfect field to store a hash of the subjectAltName, or a UUID.  (The field is a bit string, which means you don’t have to base64 encode anything.)</div><div><br class=""></div><div>So, did we consider uniqueIdentifier?  If so, what were the problems?</div><div><br class=""></div><div>While I’m asking questions, if there were problems related to it being a bitstring, did we consider serialNumber?  If so, what were the problems?</div><div><br class=""></div><div>I’m sorry to be asking so many questions, but I can’t find any record in the forum archives on this topic, and the author of the ballot didn’t include a rationale.</div></div></body></html>