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 <[email protected] > 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 <[email protected]> > wrote: > > Thanks, I knew it had to be there somewhere. > > *From:* Public [mailto:[email protected] > <[email protected]>] *On Behalf Of *Adriano Santoni via Public > *Sent:* Wednesday, May 10, 2017 8:43 AM > *To:* [email protected] > *Cc:* Adriano Santoni <[email protected]> > *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 > > [email protected] > > https://cabforum.org/mailman/listinfo/public > > > -- > > Cordiali saluti, > > Adriano Santoni > ACTALIS S.p.A. > (Aruba Group) > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
