[Servercert-wg] Ballot SC17 version 3: Alternative registration numbers for EU certificates

Erwann Abalea Erwann.Abalea at docusign.com
Fri Apr 5 12:02:20 MST 2019


I wrote some comments in the Github flow, but I’ll repeat them below.

Is the proposal really adding 2 new clauses, 9.2.8 and 9.2.9 with the same exact title « Subject Organization Identifier Field » ? Reading the text, I think that 9.2.8 goal is trying to explain the content of the organizationIdentifier attribute, while 9.2.9 goal is to define an extension (which is a different beast).

Under 9.2.8, the subdivision is arbitrarily set to be 2 characters long. In ISO 3166-2, some codes are shorter or longer than 2 characters. I haven’t bought the standard yet, so I don’t know if there’s a size constraint defined.

If 9.2.9 is an extension, let me propose a rephrase of the definition, adjust accordingly (uppercase/lowercase initials are important in ASN.1) :

id-euPSD2AuthorizationNumber OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
              certificate-extensions(3) eu-psd2-authorization-number(1) }

ext-euPSD2AuthorizationNumber EXTENSION ::= { SYNTAX EUPSD2AuthorizationNumber IDENTITIED BY id-euPSD2AuthorizationNumber }

EUPSD2AuthorizationNumber ::= SEQUENCE {
  registrationSchemeIdentifier   PrintableString,
  registrationCountry            PrintableString,
  registrationStateorProvince    PrintableString OPTIONAL,
  registrationReference          PrintableString

I’d be tempted to change at least the PrintableString for registrationReference into something that allows a larger character set. X.520 defines the organizationIdentifier as a DirectoryString, thus allowing UTF8. PrintableString is fine for a country code, probably for a scheme identifier, but I don’t see any reason to fix in stone right now what characters are registries allowed to use in states/provinces codes (ISO3166-2) or registration identifiers.

Pleade also add that this extension MUST NOT be critical.

Erwann Abalea

De : Servercert-wg <servercert-wg-bounces at cabforum.org> au nom de Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org>
Répondre à : Tim Hollebeek <tim.hollebeek at digicert.com>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Date : vendredi 5 avril 2019 à 15:23
À : CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Objet : [Servercert-wg] Ballot SC17 version 3: Alternative registration numbers for EU certificates

Just posting a “new” version to refresh the discussion period timer.

I’ll have more comments later today after I’m done catching up with all the email I got while I was gone …



Ballot SC17: Alternative registration numbers for EU certificates
Purpose of Ballot: Allow for the inclusion of additional information in
certificates in order to comply with relevant EU regulations.

The following motion has been proposed by Tim Hollebeek of DigiCert and endorsed
by Dimitris Zacharopoulos of Harica and Enrico Entshew of D-Trust.

Conflicts with other ballots:

Ballot SC16 modifies EV Guidelines Section 9.2.8 and adds Section 9.2.9.  The
new sections 9.2.8 and 9.2.9 from this ballot should be placed in front of the
sections from SC16 if both ballots pass, renumbering those sections as 9.2.10
and 9.2.11, and renumbering the following sections as necessary.


Update to CAB Forum EV Guidelines to cater for alternative registration numbers
caused by EU Legal Requirements:

i. The EU Regulation No 910/2014 (eIDAS [https://eur-lex.europa.eu/eli/reg/2014/910/oj])
   defines regulatory requirements for certificates with an agreed quality level
   called Qualified. This regulation specifies in Annex IV specific requirements
   for “Qualified certificates for website authentication” including the
   statement that the certificate shall contain: “for a legal person: the name
   and, where applicable, registration number as stated in the official records,”

ii. It is understood that this requirement relates to validated attributes for
   the identification of the certificate subject and hence is best fitted in the
   subject’s distinguished name.

iii. In line with the regulatory framework ETSI has defined a general structure
   for carrying “registration numbers” in TS 119 412-1
   [https://www.etsi.org/standards-search#page=1&search=TS119412-1] clause 5.1.4.
   This uses the X.520 [https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-201210-S!!PDF-E&type=items]
   organizationIdentifier within the subject’s distinguished name in line with its
   stated purpose being “holds an identification of an organization different
   from the organization name”. This is used for ETSI requirements to carry
   registration numbers for certificates, Qualified or otherwise.

iv. It is considered that this use of organizationIdentifier supports the primary
   purpose of EV certificates as stated in section 2.1.1 of the EV Guidelines as
   “other disambiguating information”.

v. A recent EU delegated Regulation 2018/389 on secure communications for payment
   services (RTS [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R0389])
   states in Article 34.2 that for Qualified Website certificates (QWACs) the
   registration number required in eIDAS “shall be the authorisation number of the
   payment service provider … or equivalent [reference made to earlier regulations
   relating to banks]”.

vi. ETSI has specified TS 119 495
   [https://www.etsi.org/standards-search#page=1&search=TS119495] requirements for
   carrying PSD2 related registration numbers in the general structure for
   registration numbers defined in TS 119 412-1 clause 5.1.4 as mentioned in
   iii. above.

vii. ETSI has endeavoured to ensure and always intended that requirements relating
   to web site certificates at the Qualified level are in line with the CA/B Forum
   EV Guidelines.

viii. This proposal only includes some of the Registration Schemes as used in
   ETSI TS 119 412-1, which have clear validation rules (NTR, VAT, PSD) that provide
   reasonable assurance in line with the EV Guidelines. The IPR for the semantics
   of this scheme is proposed to be released to the CA/B Forum allowing it to
   further extend the use of organizationIdentifier to include other Registration
   Schemes (e.g. LEI) and corresponding validation rules, at the CA/B Forum’s
   discretion. Also, any further changes by ETSI to ETSI TS 119 412-1 will not
   impact the CA/B Forum.

ix. Having found out that CA/B Forum’s interpretation of EV Requirements in section
   9.2.8 “Other Attributes” was not in line with those understood by ETSI experts,
   ETSI would like to harmonise with CA/B Forum approach to carrying alternative
   forms of registration number for PSD2 and other registration schemes.

b) CA/B Forum specific concerns are:

i. Requirements regarding Attributes to be included in the Subject DN need to be
   explicitly covered in 9.2.

ii. Organisations may wish to identify OrganisationalUnits within their organisation.
   It is unclear if this is currently allowed in the EV Guidelines (similar
   ambiguity in section 9.2.8).

iii. There are objections to ETSI specific usage of the orgID field (no squating).

iv. The procedures for validation of the attribute need to be clearly stated.

v. There may be other uses of the organizationIdentifier field in various PKIs,
   however it is not considered to be a problem. Because of the unique semantics we
   are specifying for each identifier, applications should be able to understand
   different uses of the OrgID field by different issuers and users. There are many
   different "PKIs" out there that can use all X.500 attributes differently and with
   different validation or no validation at all. To the best of our knowledge, the
   WebPKI has never used this subjectDN attribute before for Publicly-Trusted
   Certificates. Thus there is no "conflict" by using this attribute in the EV
   Guidelines for SSL/TLS Certificates, and perhaps later for EV Code Signing

vi. This use of organisationIdentifier must be extendable to allow for use by other
   registration numbers allocated by different registration schemes. Some CAB Forum
   members have indicated interest in carrying registration numbers other than for
   Incorporation within EV Certificates. This is catered for in the current proposal.

vii. There is interest by some CA/B Forum members in carrying LEIs within CA/B Forum
   certificates but as yet the LEI registration scheme is not currently considered
   sufficiently robust to be recognised as an registration numbering scheme to be
   accepted by CA/B Forum. Therefore this proposal only introduces a limited set of
   Registration Schemes (namely NTR, VAT, PSD) which have reasonably robust
   validation rules.

viii. Some CA/B Forum members have indicated the possible need for multiple
   identifiers in the subject name.  This, however, cannot be achieved using X.520
   organizationIdentifier which defined this attribute as being “SINGLE VALUE”.  The
   use of a single value has the advantage is it is clear what is the registration,
   in addition to the company registration, which identifies the subject.


Purpose of Ballot: Update to CAB Forum EV Guidelines to allow alternative
   registration numbers

Proposed Ballot for Changes to EVG 1.6.8

Add to section 4 definitions:

"Legal Entity: A Private Organization, Government Entity, Business Entity, or
   Non-Commercial Entity.

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

Registration Scheme: A scheme for assigning a Registration Reference meeting the
   requirements identified in Section 9.2.8."

Insert new sections 9.2.8 and 9.2.9 (renumbering following sections as necessary):

"9.2.8. Subject Organization Identifier Field

Certificate field: organizationIdentifier (OID:
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 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;
• hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8));
• if required under Section 9.2.5, a 2 character ISO 3166-2 identifier for the
     subdivision (state or province) of the nation in which the Registration Scheme
     is operated, followed by hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); and
• Registration Reference allocated in accordance with the identified Registration

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





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


a) 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;
b) further verify the Registration Reference matches other information verified
   in accordance with section 11;
c) take appropriate measures to disambiguate between different organizations as
   described in Appendix H for each Registration Scheme;
d) Apply the validation rules relevant to the Registration Scheme as specified
   in Appendix H.

"9.2.9. Subject Organization Identifier Field

Certificate field: euPSD2AuthorizationNumber (OID:
Verbose OID: {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
              certificate-extensions(3) eu-psd2-authorization-number(1) }
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 Registration Scheme MUST be encoded as described by the following ASN.1 grammar:

RegistrationScheme ::= BEGIN

    euPSD2AuthorizationNumber ::= SEQUENCE {
        RegistrationSchemeIdentifier   PrintableString,
        RegistrationCountry            PrintableString,
        RegistrationStateorProvince    PrintableString,
        RegistrationReference          PrintableString


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

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.

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.

   Where the Subject Jurisdiction of Incorporation or Registration Field in 9.2.5
   includes more than the country code, the Registration Number shall be preceded
   by a globally recognised identifier such as defined in ISO 3166-2, representing
   the same locality, state or province, followed by hyphen-minus
   ((0x2D (ASCII), U+002D (UTF-8))."


OF THE CHANGES (CABF Bylaws, Section 2.4(a)):

A comparison of the changes can be found at:


Changes since version 2:


A comparison of the changes since version 2:

No changes.

The procedure for approval of this ballot is as follows:
Discussion (7+ days)
Start Time: April 5, 2019 9:30am Eastern
End Time: Not before April 12, 2019 9:30am 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/20190405/ab972088/attachment-0001.html>

More information about the Servercert-wg mailing list