[cabfpub] Ballot 208 - dnQualifiers
sleevi at google.com
Fri Oct 20 11:30:54 MST 2017
On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public <
public at cabforum.org> wrote:
> Did we actually have a discussion period on this? I saw a pre-ballot but
> not the opening of a discussion period.
The thread you're replying to was started 8 days ago as the start of the
> In any case, can someone explain:
> - How this matches with the X.520 definition of dnQualifier, in particular
> the second sentence:
> 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 matches 1:1. Is there a concern that it doesn't match, or that more
rules are necessary?
> - How this is actually intended to be used in the web PKI?
As raised on our most recent call, one notable thing is that this allows
CAs to issue single certificates for domain names greater than 64
characters, at a DV level, while interoperably working with the Web PKI.
This flows as follows:
- The X.509/RFC 5280 definition for commonName is limited to 64 characters.
- If you have a certificate with a domain name greater than 64 characters,
you cannot place it in the common name of the subject.
- The common name of the subject may only contain domain names and IP
- All other specified fields of the Subject must be validated to OV level.
As a consequence, the only way with DV today to represent these
certificates is with an empty sequence for the subject name and a critical
subjectAltName, pursuant with RFC5280. You can see this at
If you tried to load that on Apple iOS, it would load.
If you tried to load that on Apple macOS earlier than 10.10, it would load.
If you tried to load that on Apple macOS since 10.10, it will fail, as
empty subjects are no longer supported.
This provides a way for a CA to ensure that a DV certificate with a domain
name of more than 64 characters can be issued, by using the dnQualifier
field (which is CA-controlled, as noted in the relevant X.520 text you
cited) to serve as a disambiguator between certificates the CA has issued.
Does that help capture it?
> On Oct 12, 2017, at 11:04 AM, Ben Wilson via Public <public at cabforum.org>
> *Ballot 208 - dnQualifiers*
> This ballot allows CAs to use dnQualifiers in certificates to partition
> groups of certificates into different sets and to allow non-identity
> information to be included in DV certificates.
> The following motion has been proposed by Peter Bowen of Amazon and
> endorsed by Ben Wilson of DigiCert and Ryan Sleevi of Google.
> -- MOTION BEGINS --
> In the Baseline Requirements, REPLACE the definition of "Subject Identity
> Information" with:
> "Information that identifies the Certificate Subject. Subject Identity
> Information does not include [strikeout]a domain name listed in the
> subjectAltName extension or the Subject commonName field[/strikeout]
> [insert]*dnQualifier attributes in Distinguished Names, commonName
> attributes in Distinguished Names, dNSName Subject Alternative Names,
> iPAddress Subject Alternative Names, or SRVName Subject Alternative Names*
> In Section 220.127.116.11.2 Subject Distinguished Name Fields, re-letter "j"
> (Other Subject Attributes) as letter "k" and INSERT a new subsection j.
> that reads:
> j. Certificate Field: subject:dnQualifier
> - Optional. Contents: This field is intended to be used when several
> certificates with the same subject can be partitioned into sets of related
> certificates. Each related certificate set MAY have the same dnQualifier.
> The CA may include a dnQualifier attribute with a zero length value to
> explicitly indicate that the CA makes no assertion about relationship with
> other certificates with the same subject. The CA MAY set the dnQualifer
> value to the base64 encoding of the SHA1 hash of the subjectAlternativeName
> extnValue if it wishes to indicate grouping of certificates by alternative
> name set.
> -- MOTION ENDS --
> The procedure for approval of this Final Maintenance Guideline ballot is
> as follows (exact start and end times may be adjusted to comply with
> applicable Bylaws and IPR Agreement):
> BALLOT 208 Status: Final Maintenance Guideline Start time (22:00 UTC) End
> time (22:00 UTC)
> Discussion begins October 12, 2017 22:00 UTC and ends October 19, 2017
> 22:00 UTC (7 days)
> Vote for approval begins October 19, 2017 22:00 UTC and ends October 26,
> 2017 22:00 UTC (7 days)
> If vote approves ballot: Review Period (Chair to send Review Notice) (30
> days). If Exclusion Notice(s) filed, ballot approval is rescinded and PAG
> to be created. If no Exclusion Notices filed, ballot becomes effective at
> end of Review Period. Upon filing of Review Notice by Chair 30 days after
> filing of Review Notice by Chair
> From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
> Maintenance Guideline, such ballot will include a redline or comparison
> showing the set of changes from the Final Guideline section(s) intended to
> become a Final Maintenance Guideline, and need not include a copy of the
> full set of guidelines. Such redline or comparison shall be made against
> the Final Guideline section(s) as they exist at the time a ballot is
> proposed, and need not take into consideration other ballots that may be
> proposed subsequently, except as provided in Bylaw Section 2.3(j).
> Votes must be cast by posting an on-list reply to this thread on the
> Public list. A vote in favor of the motion must indicate a clear 'yes' in
> the response. A vote against must indicate a clear 'no' in the response. A
> vote to abstain must indicate a clear 'abstain' in the response. Unclear
> responses will not be counted. The latest vote received from any
> representative of a voting member before the close of the voting period
> will be counted. Voting members are listed here: https://cabforum.org/
> In order for the motion to be adopted, two thirds or more of the votes
> cast by members in the CA category and greater than 50% of the votes cast
> by members in the browser category must be in favor. Quorum is shown on
> CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum
> number must participate in the ballot for the ballot to be valid, either by
> voting in favor, voting against, or abstaining.
> Public mailing list
> Public at cabforum.org
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public