> On Apr 14, 2016, at 12:59 PM, Ryan Sleevi <[email protected]> wrote:
> On Thu, Apr 14, 2016 at 12:02 PM, Peter Bowen <[email protected]
> <mailto:[email protected]>> 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
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
