<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 20, 2017 at 3:14 PM, Geoff Keating <span dir="ltr"><<a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.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 style="word-wrap:break-word"><br><div><span class="gmail-"><br><blockquote type="cite"><div>On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:</div><br class="gmail-m_-3645049599872352793Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"></div></blockquote></div></div></div></div></blockquote><br></span><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>- How this matches with the X.520 definition of dnQualifier, in particular the second sentence:</div><div><br></div><div>The DN Qualifier attribute type specifies disambiguating information to add to the relative distinguished nam<wbr>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><br></div><div>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><br></div></span><div>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><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>- How this is actually intended to be used in the web PKI?</div><div><br></div></div></blockquote><div><br></div><div>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><br></div><div>- The X.509/RFC 5280 definition for commonName is limited to 64 characters.</div><div>- 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>- The common name of the subject may only contain domain names and IP addresses.</div><div>- All other specified fields of the Subject must be validated to OV level.</div><div><br></div><div>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 <a href="https://no-subject.badssl.com" target="_blank">https://no-subject.badssl.com</a></div><div><br></div><div>If you tried to load that on Apple iOS, it would load.</div><div>If you tried to load that on Apple macOS earlier than 10.10, it would load.</div><div>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><br></div></span><div>It works for me in 10.11—so does that mean this ballot is no longer needed?</div></div></div></blockquote><div><br></div><div>Just tested 10.12 and 10.13 and it's still failing - perhaps it was a point release of 10.11?</div><div><br></div><div>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> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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><br></div><div>Does that help capture it?</div></div></div></div></blockquote><div><br></div></span><div>I see the problem but I’m very hesitant to standardise something in CABforum which contradicts X.520.</div><div><br></div><div>Have we really explored other alternatives?</div></div></div></blockquote><div><br></div><div>I think we have. What would help you get that confidence?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>  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><br></div><div>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><br></div><div>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><br></div><div>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">https://www.ietf.org/mail-archive/web/pkix/current/msg23992.html</a> )</div><div><br></div><div>Solutions in this space include:</div><div>- Fixing all products that fail to adhere to this aspect of RFC 5280 (In general, penalize DV site holders due to the ecosystem) before allowing it to be used</div><div>- Forcing the interoperability pain on Subscribers by allowing them to get such certificates, despite knowing they won't work (even in particularly popular products)</div><div>- Attempting to use an existing unbounded directory name type from RFC 5280, thus avoiding potential compatibility issues (which potentially runs into your concerns regarding X.520 even more substantially)</div><div>- Introducing a new attribute type and value with the arbitrary syntax we describe, much like was done for EV - still a risk of compatibility</div><div>- Defining our own annotation scheme for such long names (as you propose) - introduces security risk into the ecosystem, given how many systems perform matches and the risk of unicode folding (case in point: Consider null terminators in the commonName, as pointed out by Moxie Marlinspike, and the issues they caused)</div><div><br></div><div>Of these, it seems both aligned with X.520, past IETF discussions, and the purpose itself of dnQualifier to help provide this disambiguator. Should such an approach fail in the Forum due to a substantial number of members sharing a concern about diverging from the intent of the global Directory Information Tree, then the next possible approach would arguably be the introduction of a new attribute, compared to the other solutions.</div></div></div></div>