[cabfpub] Draft Ballot - Subject Common and Alternative Names

[Peter Bowen]

> On Apr 14, 2016, at 12:59 PM, Ryan Sleevi <sleevi at google.com> wrote:
> On Thu, Apr 14, 2016 at 12:02 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> 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:
>   
> - Multiple Common Name attributes
> 
> 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 (http://www.ioactive.com/pdfs/PKILayerCake.pdf <http://www.ioactive.com/pdfs/PKILayerCake.pdf>), 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.
> 
> 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.

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.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160414/352853ed/attachment-0003.html>