<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 12:59 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><div class=""><div dir="ltr" class="">On Thu, Apr 14, 2016 at 12:02 PM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" class="">pzb@amzn.com</a>></span> wrote:<br 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">On today’s CAB Forum call there was a request to clarify some of the background of this proposed ballot. Addressing each of the items:<br class=""> </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">
- Multiple Common Name attributes<br class="">
<br class="">
A distinguished name can contain unlimited attributes of the same type (e.g. 10 different countries or common names). However, as was pointed out in 2009 (<a href="http://www.ioactive.com/pdfs/PKILayerCake.pdf" rel="noreferrer" class="">http://www.ioactive.com/pdfs/PKILayerCake.pdf</a>), different implementations handle multiple common names inconsistently. This can result in names not being validated on the CA end and unexpected errors on the client. As the BRs already note that common name is deprecated for server certs, reducing confusion by limiting to one common name seems to make sense.<br class=""></blockquote><div class=""><br class=""></div><div class="">Alternatively, it'd be useful to understand if this can be removed, much as we've removed provisions such as issuing directly from a root or longer than 60 months. Note that the use of the commonName was already deprecated during the publication of RFC 2818 (HTTPS), 16 years ago.</div></div></div></div></div></blockquote><br class=""></div><div>I know at least some platforms had issues with empty subject names. 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><br class=""></div><div>Thanks,</div><div>Peter</div></body></html>