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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Wed Apr 17 11:39:18 MST 2019


Tim,

I will try to update the GitHub version of the EVG with version 1.6.9 
that incorporates the changes of ballot SC16. This way, ballot SC17 can 
be added to create a "clean" red-line against the latest version of the 
Guidelines.

Also, when pasting to GitHub, make sure you use the MarkDown format for 
the equivalent formatting (e.g. bulleted items). The current red-line 
version you posted includes the bullet symbols from Microsoft Word.


Thanks,
Dimitris.

On 17/4/2019 9:26 μ.μ., Tim Hollebeek via Servercert-wg wrote:
>
> As usual, there is a changelog, and a diff from both the current EVGL 
> and version 3
>
> of this ballot in the summary at the end.
>
> If you commented on version 3, please make sure I addressed your 
> comments correctly
>
> as I may have made some small errors or omissions.
>
> I think we’re pretty close.  Thanks to everyone for their hard work on 
> getting this done!
>
> -Tim
>
> 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 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 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 NTR identifiers, 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, preceded by plus "+" (0x2B 
> (ASCII), U+002B (UTF-8));
>
> • (optional) 2-8 character Registration Reference provider without 
> country code
>
>   (A-Z uppercase only, no separator) as registrationReferenceProvider, 
> preceded
>
>   by a percent "%" (0x25 (ASCII) U+0025 (UTF-8)); and
>
> • hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8));
>
> • 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 (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. 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-registration-numbers-for-EU-certificates?diff=unified&expand=1
>
> Changes since version 3:
>
> Thanks to Arno, Dimitris, Erwann, Kirk, Nick, and Ryan for their 
> careful review of
>
> version 3, resulting in these many improvements:
>
> - Fixed formatting of new sections to match rest of section 9.2.
>
> - Removed potentially confusing reference to RFC 5280.
>
> - Fixed specification of NTR subdivisions to be unambiguously parseable.
>
> - Added optional Registration Reference provider field.
>
> - Added explanations of what the examples mean.
>
> - Changed CA/Browser Forum organizationIdentifier to a certificate 
> extension
>
>   instead of a subjectDN field, to address potential concerns about 
> software
>
>   that doesn't properly implement RFC 5280 and may not handle new 
> subjectDN
>
>   fields correctly.
>
> - Moved the certificate extension to a new section 9.8 that standardizes
>
>   optional EV certificate extensions.
>
> - Renamed the extension to cabfOrganizationIdentifier since it is neither
>
>   EU-specific nor PSD2-specific.
>
> - Added a compliance deadline of January 31, 2020.  This gives 
> implementors
>
>   approximately 6 months after the end of IPR review to implement, in line
>
>   with what we usually do.  It's slightly longer to avoid the winter 
> holidays.
>
> - Various ASN.1 improvements suggested by Ryan and Erwann.
>
> - Moved the paragraph about subdivisions in Appendix H to the NTR section,
>
>   to make it more clear it is only necessary for NTR schemes and not 
> VAT or
>
>   PSD.
>
> A comparison of the changes since version 3:
>
> https://github.com/cabforum/documents/compare/afdb167..1aae336
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: April 17, 2019 2:30pm Eastern
>
> End Time: Not before April 24, 2019 2:30pm 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/20190417/161904af/attachment-0001.html>


More information about the Servercert-wg mailing list