[cabfpub] Draft Ballot - Subject Common and Alternative Names

Peter Bowen pzb at amzn.com
Sat Apr 16 20:10:12 UTC 2016

> On Apr 14, 2016, at 11:22 PM, Ryan Sleevi <sleevi at google.com> wrote:
> On Thu, Apr 14, 2016 at 10:28 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> I know at least some platforms had issues with empty subject names.  
> That's a good point. For example, OS X has this limitation: a leaf certificate with an empty distinguished name, but has subjectAlternativeNames as a non-critical extension will be rejected. Similarly, a leaf certificate that asserts the CA bit with an empty subject will also be rejected, unless it's flagged as accepted that the leaf can be a CA (mostly, this arises with self-signed certs).
> In an ideal world where we valued security over legacy, we would REQUIRE that subscriber certificates assert subjectAlternativeName as critical, to ensure (as best possible) that clients properly implemented sAN as the bare minimum for security, but I can understand that some people aren't ready to move off their insecure systems (c.f. SHA-1)
> 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.
> I can get behind that argument.

It was also pointed out to me that section of RFC 5280 (https://tools.ietf.org/html/rfc5280#section- <https://tools.ietf.org/html/rfc5280#section->) says:

   Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present. also says:

   If subject
   naming information is present only in the subjectAltName extension
   (e.g., a key bound only to an email address or URI), then the subject
   name MUST be an empty sequence and the subjectAltName extension MUST
   be critical.

This implies that those of us creating a CN-only subject for server auth certs are not following RFC 5280.  So including other info not only ensures the subject will not be empty without CN but also ensures that other subject naming information is present.  Looking at the list of attribute types that are listed as MUST be supported by software using certs, distinguished name qualifier (dnQualifier) seems like the best candidate for an attribute to add to the SII exclusion list.  X.520 says:

"The DN Qualifier attribute type specifies disambiguating information to add to the relative distinguished name 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.”

This seems ideal — each CA define a dnQualifier, either per CA or one shared by a group of CAs all sharing a single DSA/DIT.  It is a printableString, so easily supports inclusion of a space to ensure that the dnQualifier is not confused with a valid hostname.

Does adding dnQualifier to the list of things not considered subject identity information make sense?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160416/3ff9cc00/attachment-0003.html>

More information about the Public mailing list