[cabfpub] Is CN value required in the SAN?

[Ryan Sleevi]

Right. To recap that thought:

>From RFC 5280's perspective, it's legal to have an empty subject in a leaf
cert IF the subjectAltName is marked critical.

This comes from the following excerpts in 4.1.2.6:
" If the subject is a CA (e.g., the basic constraints extension, as
   discussed in Section 4.2.1.9, is present and the value of cA is
   TRUE), then the subject field MUST be populated with a non-empty
   distinguished name matching the contents of the issuer field (Section
   4.1.2.4) in all certificates issued by the subject CA. "

(TL;DR: If the subject is a CA, the subject field MUST be non-empty)

"If the
   subject is a CRL issuer (e.g., the key usage extension, as discussed
   in Section 4.2.1.3, is present and the value of cRLSign is TRUE),
   then the subject field MUST be populated with a non-empty
   distinguished name matching the contents of the issuer field (Section
   5.1.2.3) in all CRLs issued by the subject CRL issuer."

(TL;DR: If the subject issues CRLs, the subject field must be non-empty)

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

(TL;DR: If neither of the above two conditions are met, meaning it's a
subscriber cert, then the subject CAN be empty, but only if the
subjectAltName is marked critical)

As Peter mentioned, several popular clients either do not support or
recently regressed support for this part of 5280, so you should not rely on
it for the time being if expecting interoperability with those clients.

Notably missing from this, for the eagled eyed readers, is any remarks
about delegated OCSP responder certificates. Since in the absence of
clarification you should assume forbidden, rather than permitted, and
indeed, because implementations defaulted to that, don't have an empty
subject for your responder certs either, even though they are not cA:True
certificates :) That is, an implied constraint similarly exists for OCSP as
the explicit constraint for CRLs.

On Wed, May 10, 2017 at 9:13 AM, Peter Bowen via Public <public at cabforum.org
> wrote:

> Doug,
>
> As we discussed at the Raleigh F2F, the CN is optional but having an empty
> subject sequence will break some very popular clients.  For DV, this means
> you effectively have to include CN until we modify the BRs to allow
> something other than CN in a pure-DV certificate.
>
> Thanks,
> Peter
>
> On May 10, 2017, at 5:45 AM, Doug Beattie via Public <public at cabforum.org>
> wrote:
>
> Thanks, I knew it had to be there somewhere.
>
> *From:* Public [mailto:public-bounces at cabforum.org
> <public-bounces at cabforum.org>] *On Behalf Of *Adriano Santoni via Public
> *Sent:* Wednesday, May 10, 2017 8:43 AM
> *To:* public at cabforum.org
> *Cc:* Adriano Santoni <adriano.santoni at staff.aruba.it>
> *Subject:* Re: [cabfpub] Is CN value required in the SAN?
>
>
> Excerpt from the BRs:
>
> 7.1.4.2.2. Subject Distinguished Name Fields
> a. Certificate Field: subject:commonName (OID 2.5.4.3)
> Required/Optional: Deprecated (Discouraged, but not prohibited)
> Contents: If present, this field MUST contain a single IP address or
> Fully‐Qualified Domain
> Name that is one of the values contained in the Certificate’s
> subjectAltName extension (see
> Section 7.1.4.2.1).
>
>
>
> Il 10/05/2017 14:36, Doug Beattie via Public ha scritto:
>
>
> In reading the BRs, I see the requirement that the SAN must contain at
> least one value (7.1.4.2.1), but I can’t find a reference that the value in
> the CN needs to be in the SAN.  Am I missing that link somewhere, or can
> the value in the CN be omitted from the SAN?  With Chrome depreciating use
> of CN, CAs will certainly want to include the value in the SAN, but is
> there a BR requirement that the CN value must be in the SAN?
>
>
>
> _______________________________________________
>
> Public mailing list
>
> Public at cabforum.org
>
> https://cabforum.org/mailman/listinfo/public
>
>
> --
>
> Cordiali saluti,
>
> Adriano Santoni
> ACTALIS S.p.A.
> (Aruba Group)
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170510/0e9d60e5/attachment-0003.html>