[cabfpub] Draft Ballot - Subject Common and Alternative Names

Kurt Roeckx kurt at roeckx.be
Mon Apr 25 13:33:39 MST 2016


On Sat, Apr 16, 2016 at 01:10:12PM -0700, Peter Bowen wrote:
> 
> > 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 4.2.1.6 of RFC 5280 (https://tools.ietf.org/html/rfc5280#section-4.2.1.6 <https://tools.ietf.org/html/rfc5280#section-4.2.1.6>) 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.
> 
> 4.1.2.6 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 are you saying that for DV certificate, the subject DN MUST be
an empty sequence?  That at least seems to be one way of
interpreting that.

> 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.

I'm not sure why you want to do that.  So you would instead create
DV certificates with only the name of the CA in the subject?  I'm
not sure what you're trying to fix.


Kurt



More information about the Public mailing list