[Servercert-wg] Ballot SC17 version 5: Alternative registration numbers for EV certificates
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Apr 19 15:07:52 MST 2019
I would just like to point out that there is no conflict with SC16 anymore.
Dimitris.
-----Original Message-----
From: Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org>
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Sent: Fri, 19 Apr 2019 22:28
Subject: [Servercert-wg] Ballot SC17 version 5: Alternative registration numbers for EV certificates
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.
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 Appendix H."
Retitle Section 9.2 as "Subject Distinguished Name Fields".
Remove Section 9.2.2 and renumber sections 9.2.3 through 9.2.8 to 9.2.2
through 9.2.7.
Insert new section 9.2.8:
"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-regi
stration-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/20190420/1c63a5db/attachment-0001.html>
More information about the Servercert-wg
mailing list