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

Fri Aug 18 14:25:33 UTC 2017

Hi Kirk and Ryan,

I think this points out a couple of important changes we should make to the BRs:

1) We should clarify which fields can’t have just meta data characters.  The statement is currently ambiguous in 2 ways:
1.1) It’s listed under “Other Subject Attributes” which implies it’s OK in any other field (which we know is not accurate).  This applies especially to the OU field that is listed above and then seems to be precluded from this requirement.
1.2) It’s not just optional fields, it should be ANY field in the subject DN. Although, all required fields should have clear requirements on what they MUST contain, it would not hurt to apply this meta data requirement to all Subject information fields.

2) The list of meta data characters is not spelled out clearly.  We say parenthetically meta data characters such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space).  I think there are 2 categories of content we need to specifically disallow:
2.1) Fields that consist of only meta data characters are clearly not allowed.  I think this is the list:  ASCII 32 - 47, 58 - 64, 91 - 96,  123 – 126.  This is easy to specify and then audit against.
2.1) The harder one is to say don’t put nonsense into any fields like N/A, NA, test, “not applicable” etc.  The descriptions of all the fields in BR section 7.1.4.2.2 items a-h are clear on the content.  Item i) OU and j) Other subject attributes, might need to more clearly specify what is permitted and what is prohibited.

The Validation WG should probably take this up.

Doug

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Friday, August 18, 2017 9:49 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

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<http://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<mailto: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<mailto: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/64ce3fec/attachment-0003.html>