[cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

Fri Aug 18 13:49:21 UTC 2017

Hi Kirk,

Your email may be confusing somethings. This is related to Entrust's
issuance of non-BR compliant certificates,
https://bugzilla.mozilla.org/show_bug.cgi?id=1390996 , correct? Hopefully
you'll have a chance to reply there, even if to only acknowledge receipt
and that Entrust is investigating.

The short answer is this language came from the Forum, because it makes
sense. As CAs have liked to suggest that the additional subject information
afforded by an EV and OV certificate is meaningful, and as both the
Baseline Requirements and the EV Guidelines exist to create a common
profile of fields, this language prohibits a practice that was previously
common, of CAs explicitly including certain attributes in fields and
putting the contents such as "n/a" or "-"

This is undesirable for many reasons, which the Forum recognized when
prohibiting.
1) One goal of our requirements is to ensure certificates from different
CAs follow a consistent profile and representation. One CA's "n/a" could be
encoded as another CA's "-", and one CAs "NA" could mean "not applicable"
could mean another CA's "North America". The current requirement helps
ensure consistency.
2) For optional fields, there's a defined way in X.509 (and, by proxy, RFC
5280) to how to represent that an optional field was not applicable or not
verified - and that's simply to not include it. There is no technical
requirement that a CA include a subject Attribute Type with an empty or
symbolic Attribute Value; if it's not applicable, the correct approach, in
all the relevant standards, is to simply omit this field.
3) Omitting this field, rather than filling it with 'junk' data (such as
'-', ' ', or other indicators of no applicability) helps keep certificates
smaller, and by doing so, ensures TLS remains accessible for a broad
spectrum of users and site operators.
4) In particular for browsers, the contents of Subject fields are
displayed. Even in cases where a localized name for the associated
Attribute Type is not included in the UI (e.g. Li-Chun's remarks about the
EV OIDs in the context of Firefox and, previously, Chrome), the Attribute
Value, by being an appropriate universal ASN.1 type, can and is displayed.
That is, in the UI, you might see something like "1.2.3.4: N/A" in the UI
for an attribute type of OID 1.2.3.4 and an attribute value of IA5String.
In order to ensure that UI behaviour is consistent, and that CAs do not
introduce additional information that confuses or misleads relying parties,
such prohibitions are useful.

As such, (j) serves a very important purpose, and while I appreciate your
questions to understand its usage as well, would be very inappropriate to
remove. More importantly, that suggestion seems to miss the first section
of that requirement (j) - namely, that the content actually be verified by
the CA. Were we to adopt your suggestion - fully removing (j) - then CAs
would be fully permitted to introduce invalid, misleading information,
which would be contained within the certificate and displayed to users,
without violating the Baseline Requirements.

Even if we were to scope your request more narrowly, and remove simply that
section of (j), we would be returning to the wild west of arbitrary CA
contents, and that's undesirable.

So no, I do not believe any changes to this section are necessary, and hope
that all CA participants are reviewing their systems to ensure compliance.

On Thu, Aug 17, 2017 at 8:54 PM, Kirk Hall via Public <public at cabforum.org>
wrote:

> There has been a discussion on a Mozilla list Certificates with
> Metadata-Only Subject Fields, https://groups.google.com/
> forum/#!topic/mozilla.dev.security.policy/Sae5lpT02Ng, that concerns BR 7.1.4.2.2.
> Subject Distinguished Name Fields:
>
>
>
> *j. Other Subject Attributes*
>
> All other optional attributes, when present within the subject field, MUST
> contain information that has
>
> been verified by the CA. Optional attributes MUST NOT contain metadata
> such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space)
>
> characters, and/or any other indication that the value is absent,
> incomplete, or not applicable.
>
>
>
> My question to the Forum is – where did this language come from?  An RFC?
> Some other standard?  Does this prohibition actually make sense (especially
> for the OU field, which is optional but must be verified by the CA if it
> includes identity-type information)?  Can we consider deleting sub (j) or
> clarifying it only applies to certain fields?
>
>
>
> *Ballot 33 – Subject attribute requirements (4 August 2009)*
>
> Vote
>
> Yes: Entrust, VeriSign, GlobalSign, DigiCert, T-Systems, QuoVadis,
> StartCom, Buypass, Trustwave, Comodo, SSC and Microsoft.
>
> No: None.
>
> Abstain: None.
>
> Result: Accepted.
>
> Motion:
>
> Steve Roylance made the following motion, and Johnathan Nightingale and
> Jay Schiavo endorsed it:
> ------------------------------
>
> Motion begins
> ------------------------------
>
> The Guidelines should be amended by the following erratum.
> ------------------------------
>
> Erratum begins
> ------------------------------
>
> Delete the following paragraph from Section 6.
>
>
>
> 6. EV Certificate Content Requirements This section sets forth minimum
> requirements for the content of the EV Certificate as they relate to the
> identity of the CA and the Subject of the EV Certificate.
>
>
>
> Insert the following paragraph:
>
>
>
> 6. EV Certificate Content Requirements This section sets forth minimum
> requirements for the content of the EV Certificate as they relate to the
> identity of the CA and the Subject of the EV Certificate. Optional data
> fields within the subject DN should contain either information verified by
> the CA or be left empty. Meta data such as ‘.’, ‘-‘ and ‘ ‘ characters
> and or any other indication that the field is not applicable should not be
> used.
>
>
>
> Delete the following paragraph from Section 6(a)(4).
>
>
>
> Contents These fields MUST contain information only at and above the level
> of the Incorporating Agency or Registration Agency – e.g., the Jurisdiction
> of Incorporation for an Incorporating Agency or Jurisdiction of
> Registration for a Registration Agency at the country level would include
> country information but not state or province or locality information; the
> Jurisdiction of Incorporation for the applicable Incorporating Agency or
> Registration Agency at the state or province level would include both
> country and state or province information, but not locality information;
> and so forth. Country information MUST be specified using the applicable
> ISO country code. State or province information, and locality information
> (where applicable), for the Subject’s Jurisdiction of Incorporation or
> Registration MUST be specified using the full name of the applicable
> jurisdiction.
>
> Insert the following paragraph:
>
> Contents These fields MUST contain information only relevant to the level
> of the Incorporating Agency or Registration Agency – e.g., the Jurisdiction
> of Incorporation for an Incorporating Agency or Jurisdiction of
> Registration for a Registration Agency at the country level would include
> country information but not state or province or locality information; the
> Jurisdiction of Incorporation for the applicable Incorporating Agency or
> Registration Agency at the state or province level would include both
> country and state or province information, but not locality information ;
> the Jurisdiction of Incorporation for the applicable Incorporating Agency
> or Registration Agency at locality level would include country and also
> state or province information where the state or province regulates the
> registration of the entities at the locality level. Country information
> MUST be specified using the applicable ISO country code. State or province
> or locality information (where applicable), for the Subject’s Jurisdiction
> of Incorporation or Registration MUST be specified using the full name of
> the applicable jurisdiction.
>
> Delete the following paragraph from the Definitions Section.
>
> 41. Jurisdiction of Incorporation: In the case of a Private Organization,
> the country and (where applicable) the state or province where the
> organization’s legal existence was established by a filing with (or an act
> of) an appropriate government agency or entity (e.g., where it was
> incorporated). In the case of a Government Entity, the country and (where
> applicable) the state or province where the Entity’s legal existence was
> created by law.
>
> Insert the following paragraph:
>
> 41. Jurisdiction of Incorporation: In the case of a Private Organization,
> the country and (where applicable) the state or province or locality where
> the organization’s legal existence was established by a filing with (or an
> act of) an appropriate government agency or entity (e.g., where it was
> incorporated). In the case of a Government Entity, the country and (where
> applicable) the state or province where the Entity’s legal existence was
> created by law.
> ------------------------------
>
> Erratum ends
> ------------------------------
> ------------------------------
>
> Motion ends
>
>
>
> _______________________________________________
> 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/20170818/466b987c/attachment-0003.html>