[Servercert-wg] Ballot SC17 version 2: Alternative registration numbers for EU certificates
Ryan Sleevi
sleevi at google.com
Mon Mar 18 11:11:59 MST 2019
Hey Tim,
If you opened it as a pull request against either your fork or the BRs, I
could more easily comment. I left a number of in-line comments in
https://github.com/cabforum/documents/commit/afdb167170ded32eae0508a796ebd32a3c42dabb#diff-4d3fa7e751e9cac20a3014852be12e82
which
will hopefully be helpful, but I suspect having these in a PR might more
easily track the evolution and feedback.
Overall, I think this is a good approach towards the resolution we
discussed in Cupertino, by providing a 'legacy' compatibility path as well
as a more idiomatic forward path. I'm still apprehensive about encoding the
structured data within the Subject itself, as opposed to an extension,
since it really is a separate hierarchy and structure for expressing that
identity. I think it's reasonable to avoid using QCStatements here, if the
intent is that this scheme is usable outside the qualified certificate
realm (e.g. with GLEIF LEIs), but since you pulled the OID from the
extension space, it seems like we're fairly close to having it as an
extension already. This is especially relevant since 5.1.4 of TS 119 412-1
v.1.2.1 (aka the one with PSD2) uses the qcs semantics ID to
redefine/reinterpret what the identifier should be.
I think we need to vet the ASN.1 module (say, using the 2002 ASN.1 syntax,
aligning with RFC 5912), but that should be doable. It wasn't clear if
you've already performed that, and if so, using what tools.
One area of ambiguity in comparing your proposal against that of 5.1.4 of
119 412-1 is that in between the country code identifier you introduced an
(optional) stateOrProvince identifier. This extension certainly highlights
the ambiguity that lead to my original suggestion of structured data; that
is, an identifier of "NTRUS-CA-12345678" is ambiguous as to whether it's an
NTR identifier in (ISO 3166 code of US, subdivision of CA, identifier
12345678) or (ISO 3166 code of US, identifier CA-12345678). In this regard,
TS 119 412-1 is less ambiguous.
I also want to highlight one significant difference, which I think is a
structurally significant improvement, which is that this ballot would
preclude "Option 4" from Section 5.1.4 TS 119 412-1; namely, the use of a
locally defined two character prefix (followed by colon), along with the
use of a nameRegistrationAuthorities in the SemanticsInformation of RFC
3739 that is qualified by the uniformResourceIdentifier. I think if we
wanted to allow that degree of extensibility, then this MUST NOT be present
in the Subject, and instead should be moved to an extension, which I think
is the thing that this ballot is trying to avoid. Put differently, if our
ETSI colleagues feel that such an option is an important and necessary
aspect of 5.1.4, I don't think it's compatible with the principles of
placing it in the organizationIdentifier for an EV certificate.
On Fri, Mar 15, 2019 at 5:13 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.
>
>
>
> 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.
>
>
>
> 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 sections 9.2.8 and 9.2.9 (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 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
>
> 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.
>
>
>
> "9.2.9. Subject Organization Identifier Field
>
>
>
> Certificate field: euPSD2AuthorisationNumber (OID: 2.23.140.3.1)
>
> 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
>
> }
>
>
>
> END
>
>
>
> 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.
>
>
>
> 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))."
>
>
>
> ---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
>
>
>
> Changes since version 1:
>
>
>
> 1. Clarify how to merge with ballot SC16
>
> 2. Require that OrganizationIdentifier fields are encoded as
> PrintableString or UTF8String
>
> 3. Remove "or equivalent" language for identifiers and point to the
> relevant ETSI specification
>
> 4. Allow for encoding of authorization identifiers as a ASN.1 SEQUENCE
>
>
>
> A comparison of the changes since version 1:
>
>
>
>
> https://github.com/cabforum/documents/commit/afdb167170ded32eae0508a796ebd32a3c42dabb#diff-4d3fa7e751e9cac20a3014852be12e82
>
>
> https://github.com/cabforum/documents/commit/c1cad0eb5040cb04fac66eeaf741f7ddb3928eb7#diff-4d3fa7e751e9cac20a3014852be12e82
>
>
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: March 15, 2019 5:15 pm Eastern
>
> End Time: Not before March 22, 2019 5:15 pm 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/20190318/951af68b/attachment-0001.html>
More information about the Servercert-wg
mailing list