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

Tim Hollebeek tim.hollebeek at digicert.com
Tue Mar 12 11:00:58 MST 2019

Fair point.  I’ll add it.




From: Wayne Thayer <wthayer at mozilla.com> 
Sent: Sunday, March 10, 2019 11:53 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC17: Alternative registration numbers for EU certificates


Because this ballot modifies some of the same sections as SC16, I think it needs to comply with Bylaws section 2.4(j):


If a ballot is proposed to amend the same section of the Final Guidelines or the Final Maintenance Guidelines as one or more previous ballot(s) that has/have not yet been finally approved, the newly proposed ballot must include information about, and a link to, any such previous ballot(s), and may include provisions to avoid any conflicts relating to such previous ballots.


- Wayne


On Fri, Mar 8, 2019 at 2:02 PM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org> wrote:

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.




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 <https://www.etsi.org/standards-search#page=1&search=TS119412-1> &search=TS119412-1] clause 5.1.4. 

   This uses the X.520 [https://www.itu.int/rec/dologin_pub.asp?lang=e <https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-201210-S!!PDF-E&type=items> &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 <https://www.etsi.org/standards-search#page=1&search=TS119495> &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 section 9.2.8 (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 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."


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: Authorisation Number or equivalent allocated to a payment service provider under 

   EU Commission Delegated Regulation (EU) 2018/389 Article 34 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 



   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: 


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


The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: March 8, 2019 4pm Eastern

End Time: Not before March 15, 2019 4pm Eastern

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190312/bc546abe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190312/bc546abe/attachment-0001.p7s>

More information about the Servercert-wg mailing list