[Servercert-wg] Ballot SC17 version 5: Alternative registration numbers for EV certificates

Kirk Hall Kirk.Hall at entrustdatacard.com
Mon Apr 22 17:53:25 MST 2019


Tim - thanks for all your work on this.  I think we are almost there.

As you know, we started working on this issue to accommodate ETSI / the EU and their desire to issue PSD2 certificates, which include a new PSD organizationIdentifier field according to both ETSI 319 412-1 Sec. 5.1.4 and ETSI TS 119 495, Sec. 5.2.  [Phew!]

I think your text for new EVGL 9.2.8 fairly captures those ETSI requirements - but you have added something I don't understand, and I wanted to see if you would share your thinking.  I propose a ballot change at the end of my message.

You added a definition to the EVGL not found in the ETSI documents: "Registration Reference: A unique identifier assigned to a Legal Entity."  So far, so good - we can use the definition in describing different Registration Schemes (which you also define).  In 412-1 of the ETSI document, they use the phrase "legal person identity type reference" instead of "Registration Reference".

ETSI wants to start out with three Registration Schemes - NTR, VAT, and PDS - that's also covered in your ballot.  Coding for the Registration Reference under all three Schemes is covered by your ballot.

Then you give useful examples of properly coded ordID strings for all three.  It's the third example below that is puzzling me, and I wanted to understand your thinking.

Examples:

* NTRGB-12345678 (NTR scheme, Great Britain, Unique Identifier at Country level is 12345678)
* NTRUS+CA-12345678 (NTR Scheme, United States - California, Unique identifier at State level is 12345678)
* NTRJP-ABCDEF-12345678 (NTR Scheme, Japan, Registration Reference provider is ABCDEF, Unique Identifier at Country level is 12345678)
* VATDE-123456789 (VAT Scheme, Germany, Unique Identifier at Country Level is 12345678)
* PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890)

Looking at Examples 1 and 2, the NTR (which is basically the same as the Serial Number in an EV cert, just restated as an orgID identifier), the coding is easy - Example 1 is how to do it if the corporate serial number is assigned by a national registry, as in Great Britain, and Example 2 is how to do it if the corporate serial number is assigned at the state/province level, as in the US.

But Example 3 introduces something new when it inserts a data block ("ABCDEF" as an example) right after the Country code (Japan, in your example) with this explanation: "Registration Reference provider is ABCDEF, Unique Identifier at Country level is 12345678"  In what kinds of situations do you see this type of coding being used?  I can only think of three known levels at which a unique identifier (corporate serial number) is assigned - at the national level, state/province level, or local level (e.g., Germany), which would very likely need three data segments to fully identify the serial number (country, state, and town).  So I don't know of any actual situation when some "Registration Reference provider" which is not a country and is not a state could be fully represented by a blob of data, such as "ABCDEF" just below the country level.  (Are there countries where two national agencies each can assign unique national identifiers to corporations?  I'm not aware of any.)

Your Appendix H already says that about the NTR field, "The information carried in this field shall be the same as held in Subject Registration Number Field as specified in 9.2.6 and the country code used in
the Registration Scheme identifier shall match that of the subject's jurisdiction as specified in Section 9.2.5."  So I think we are already constrained as to the data fields we can use in the orgID field to those in other sections of the EVGL Sec. 9.2 - it can only be Locality, State/Province, Country, and Serial Number for an NTR field.  We are prohibited from using any other type of data.

My suggestion is that you modify Example 3 above to allow for both State and Locality (such as in Germany) and drop reference to any other type of Registration Reference provider.  I don't know enough about local registrations in Germany or other local registrations, but maybe you should change Example 3 to something like the following?


  *   NTRDE+Bavaria+München-12345678 (NTR Scheme, Germany - Bavaria - München, Unique identifier at Locality level is 12345678)

We can ask Enrico and Arno if this example makes sense for Germany.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Tim Hollebeek via Servercert-wg
Sent: Friday, April 19, 2019 12:27 PM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL][Servercert-wg] Ballot SC17 version 5: Alternative registration numbers for EV certificates

Ballot SC17: Alternative registration numbers for EU certificates ***

---MOTION BEGINS---

*** Add to section 4 definitions: ***

Registration Reference: A unique identifier assigned to a Legal Entity.

Registration Scheme: A scheme for assigning a Registration Reference meeting the
   requirements identified in Appendix H." ***

"9.2.8. Subject Organization Identifier Field

**Certificate field**: organizationIdentifier (OID: 2.5.4.97)

**Required/Optional**: Optional

**Contents**: If present, this field MUST contain a Registration Reference for a
   Legal Entity assigned in accordance to the identified Registration Scheme.

The organizationIdentifier MUST be encoded as a PrintableString or UTF8String
(see RFC 5280).

The Registration Scheme MUST be identified using the following structure
in the presented order:

* 3 character Registration Scheme identifier;
* 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code "XG" shall be used;
* For the NTR Registration Scheme identifier, if required under Section 9.2.4, a 2 character ISO 3166-2 identifier for the subdivision (state or province) of the nation in which the Registration Scheme is operated, preceded by plus "+" (0x2B (ASCII), U+002B (UTF-8));
* a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8));
* (optional) 2-8 character Registration Reference provider without country code (A-Z uppercase only, no separator) as registrationReferenceProvider, followed by a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8));
* Registration Reference allocated in accordance with the identified Registration Scheme

To avoid parsing ambiguities, the Registration Reference Provider and Registration Reference MUST NOT contain a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)).

As in section 9.2.4, the specified location information MUST match the scope of the
registration being referenced.

Examples:

* NTRGB-12345678 (NTR scheme, Great Britain, Unique Identifier at Country level is 12345678)
* NTRUS+CA-12345678 (NTR Scheme, United States - California, Unique identifier at State level is 12345678)
* NTRJP-ABCDEF-12345678 (NTR Scheme, Japan, Registration Reference provider is ABCDEF, Unique Identifier at Country level is 12345678)
* VATDE-123456789 (VAT Scheme, Germany, Unique Identifier at Country Level is 12345678)
* PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, NCA's identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890)

Registration Schemes listed in Appendix H are currently recognized as valid under
these guidelines.

The CA SHALL:

1. confirm that the organization represented by the Registration Reference is the
   same as the organization named in the organizationName field as specified in
   Section 9.2.1 within the context of the subject's jurisdiction as specified in
   Section 9.2.5;
2. further verify the Registration Reference matches other information verified
   in accordance with section 11;
3. take appropriate measures to disambiguate between different organizations as
   described in Appendix H for each Registration Scheme;
4. Apply the validation rules relevant to the Registration Scheme as specified
   in Appendix H."

Insert new section 9.8 (renumbering following sections as necessary):

"9.8. Certificate Extensions



The extensions listed in the Section 9.8 are recommended for maximum interoperability
between certificates and browsers / applications, but are not mandatory on the CAs
except where indicated as "Required".  CAs may use other extensions that are not
listed in this Section 9.8, but are encouraged to add them to this section by ballot
from time to time to help increase externsion standardization across the industry.



If a CA includes an extension in a certificate that has a Certificate field which is
named in this Section 9.8, the CA must follow the format specified in that subjection.
However, no extension or extension format shall be mandatory on a CA unless
specifically stated as "Required" in the subsection that describes the extension.

9.8.1. Subject Alternative Name Extension

**Certificate field:**  _subjectAltName:dNSName_

**Required/Optional:**  Required

**Contents:** This extension MUST contain one or more host Domain Name(s) owned or controlled
by the Subject and to be associated with the Subject's server.  Such server MAY be owned and
operated by the Subject or another entity (e.g., a hosting service).  Wildcard certificates
are not allowed for EV Certificates.

9.8.2. CA/Browser Forum Organization Identifier Field

**Extension Name**: _cabfOrganizationIdentifier_ (OID: 2.23.140.3.1)

**Verbose OID**: {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
              certificate-extensions(3) cabf-organization-identifier(1) }

**Required/Optional**: Optional (but see below)

**Contents**: If the subject:organizationIdentifier is present, this field SHOULD be present.
Effective January 31, 2020, if the subject:organizationIdentifier field is present,
this field MUST be present.

If present, this field MUST contain a Registration Reference for a
Legal Entity assigned in accordance to the identified Registration Scheme.

The Registration Scheme MUST be encoded as described by the following ASN.1 grammar:

    id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-extensions(3) cabf-organization-identifier(1) }

    ext-CABFOrganizationIdentifier EXTENSION ::= { SYNTAX CABFOrganizationIdentifier IDENTIFIED BY id-CABFOrganizationIdentifier }

    CABFOrganizationIdentifier ::= SEQUENCE {
        registrationSchemeIdentifier   PrintableString (SIZE(3)),
        registrationCountry            PrintableString (SIZE(2)),
        registrationStateOrProvince    [0] IMPLICIT PrintableString OPTIONAL (SIZE(0..128)),
        registrationReferenceProvider  PrintableString (SIZE(0..8)),
        registrationReference          UTF8String
    }

where the subfields and have the same meanings and restrictions described in Section 9.2.8.
The CA SHALL validate the contents using the requirements in Section 9.2.8."

Add new Appendix H - Registration Schemes

"The following Registration Schemes are currently recognised as valid under these
guidelines:

**NTR**: The information carried in this field shall be the same as held in Subject
   Registration Number Field as specified in 9.2.6 and the country code used in
   the Registration Scheme identifier shall match that of the subject's jurisdiction
   as specified in Section 9.2.5.

   Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.5

   includes more than the country code, the additional locality information shall

   be included as specified in sections 9.2.8 and/or 9.8.1.

**VAT**: Reference allocated by the national tax authorities to a Legal Entity. This
   information shall be validated using information provided by the national tax
   authority against the organisation as identified by the Subject Organization
   Name Field (see 9.2.1) and Subject Registration Number Field (see 9.2.6) within
   the context of the subject's jurisdiction as specified in Section 9.2.5.

**PSD**: Authorization number as specified in ETSI TS 119 495 clause 4.4 allocated to a
   payment service provider and containing the information as specified in
   ETSI TS 119 495 clause 5.2.1.  This information SHALL be obtained directly from the
   national competent authority register for payment services or from an information
   source approved by a government agency, regulatory body, or legislation for this
   purpose.  This information SHALL be validated by being matched directly or indirectly
   (for example, by matching a globally unique registration number) against the
   organisation as identified by the Subject Organization Name Field (see 9.2.1) and
   Subject Registration Number Field (see 9.2.6) within the context of the subject's
   jurisdiction as specified in Section 9.2.5.  The stated address of the organisation
   combined with the organization name SHALL NOT be the only information used to
   disambiguate the organisation."

---MOTION ENDS---

*** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE OFFICIAL VERSION
OF THE CHANGES (CABF Bylaws, Section 2.4(a)):

A comparison of the changes can be found at:

https://github.com/cabforum/documents/compare/Ballot-SC17---Alternative-registration-numbers-for-EV-certificates?diff=unified&expand=1

Changes since version 4:

0. Re-based redline to be based on SC16 results.
1. Restore compatibility with ETSI OrgID requirements and remove parsing ambiguity related to hyphens in values in another way.
2. Added a "Relevant Dates" table after the document versions table.
3. the definition of Registration Scheme should point to Appendix H and not section 9.2.x because a) section numbers change and b) the Schemes themselves are in the Appendix.
4. Renamed section 9.2 to "Subject Distinguished Name Fields" as in the BRs.
5. SubjectAltName moved to the Extensions section.
6. Renumbered the subsections of 9.2 and checked for any existing references to these subsections. I didn't locate any. The only references to these subsections are introduced by this ballot regarding orgID
7. Fix formatting of field names in all of Section 9.2 to be consistent.
8. Fix reference in Section 9.8.

A comparison of the changes since version 4:

https://github.com/cabforum/documents/compare/28764a1..1aae336 (includes changes due to incorportating SC16)

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: April 19, 2019 3:30pm Eastern

End Time: Not before April 19, 2019 3:30pm Eastern

Vote for approval (7 days)

Start Time: TBD

End Time: TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190423/087f96d3/attachment-0001.html>


More information about the Servercert-wg mailing list