[Servercert-wg] Ballot SC17: Alternative registration numbers for EU certificates
Wayne Thayer
wthayer at mozilla.com
Sun Mar 10 11:53:03 MST 2019
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.
>
>
>
> Motivation:
>
>
>
> 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
>
> Certificates.
>
>
>
> 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.
>
>
>
> ---MOTION BEGINS---
>
>
>
> 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: 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 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
>
> Scheme
>
>
>
> As in section 9.2.5, the specified location information MUST match the
> scope of the
>
> registration being referenced.
>
>
>
> Examples:
>
>
>
> NTRGB-12345678
>
> NTRUS-CA-12345678
>
>
>
> VATDE-123456789
>
>
>
> PSDBE-NBB-1234.567.890
>
>
>
> Registration Schemes listed in Appendix H are currently recognized as
> valid under
>
> these guidelines.
>
>
>
> The CA SHALL:
>
>
>
> 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
>
> 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.
>
>
>
> 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
>
> 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))."
>
>
>
> ---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-EU-certificates?diff=unified&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
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190310/96aa146c/attachment-0001.html>
More information about the Servercert-wg
mailing list