[cabf_validation] Topic for our next VWG call: LEI

Wed Feb 6 12:16:56 MST 2019

Maybe an example will help:

A CA issues a certificate to Stripe Inc, Kentucky.  The LEI matches what's
in the certificate and the CA asserts all is good at this point in time.

A week later, the LEI changes the location of Stripe Inc, to New Hampshire.
Relying parties now think the CA asserted/verified Stripe Inc, New Hampshire
because that is in the certificate and bound via digital signature in the OU
field (although, they are bit confused because the DN in the certificate
remains Kentucky).  It appears that the CA validated both identifies, but in
fact, the CA never validated Stripe Inc, New Hampshire.

How do we reconcile this?  I think it's important that everyone understands
what was validated, and with the ability of LEI data to change, I don't
understand how a CA can include that as validated information.

From: Richard Smith <rich at sectigo.com> 
Sent: Wednesday, February 6, 2019 12:54 PM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Validation
WG List <validation at cabforum.org>; Tim Hollebeek
(tim.hollebeek at digicert.com) <tim.hollebeek at digicert.com>
Subject: RE: Topic for our next VWG call: LEI

I don't understand this concern at all.  Subject information and
verification thereof is and has always been point in time.  None of the data
sources we use for verification of subject information are static or use
Merkle trees or anything else.  The exact same thing you are saying about
LEI information applies to corporate registration information tied to the
registration number which we are REQUIRED to include in the subject of an EV
certificate.  The company name, registered address, registered agent,
directors/owners could all change the day after certificate issuance.

Regards,

Rich

From: Doug Beattie <doug.beattie at globalsign.com> 
Sent: Wednesday, February 6, 2019 11:37 AM
To: Richard Smith <rich at sectigo.com>; CA/Browser Forum Validation WG List
<validation at cabforum.org>; Tim Hollebeek (tim.hollebeek at digicert.com)
<tim.hollebeek at digicert.com>
Subject: RE: Topic for our next VWG call: LEI

Hi Rich,

Yes, we're getting inquires also.  I understand the requirements and those
statements from the BRs and EVGs for data contained in the certificate.  The
question I have is how should we handle a link to data that can change?  If,
at the time of issuance, the data in the certificate is validated, then we
have a good spec because the data is covered with a signature so we know it
can't be changed.  The issue with LEI is that the data can change post
issuance.  It's a bit like permitting a 3rd party to change the contents of
the certificate after issuance; we would certainly not permit that.  If
there was a hash of the LEI data in the certificate or if the LEI database
never changed (Merkle tree or something), then I have no issues, but it's
the fact the data can change post issuance and the CA never verified that,
yet it's asserting it's true by virtue of the link in the certificate. 

Doug

From: Richard Smith <rich at sectigo.com <mailto:rich at sectigo.com> > 
Sent: Wednesday, February 6, 2019 11:28 AM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; CA/Browser Forum Validation WG List
<validation at cabforum.org <mailto:validation at cabforum.org> >; Tim Hollebeek
(tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> )
<tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Subject: RE: Topic for our next VWG call: LEI

We've been asked about using LEIs from some customers so I recently looked
into this as well.

Everything from BR and EVG related to the use of the OU field that I could
find is below.  IMO

nothing stated precludes the use of a verified LEI number in the OU field.

>From BR Section 7.1.4.2

i. Certificate Field: subject:organizationalUnitName Optional. The CA SHALL

implement a process that prevents an OU attribute from including a name,

DBA, tradename, trademark, address, location, or other text that refers to a

specific natural person or Legal Entity unless the CA has verified this

information in accordance with Section 3.2 and the Certificate also contains

subject:organizationName, subject:givenName, subject:surname,

subject:localityName, and subject:countryName attributes, also verified in

accordance with Section 3.2.2.1.

And from 9.6.1

3.            Accuracy of Information: That, at the time of issuance, the CA
(i)

implemented a procedure for verifying the accuracy of all of the information

contained in the Certificate (with the exception of the

subject:organizationalUnitName attribute); (ii) followed the procedure when

issuing the Certificate; and (iii) accurately described the procedure in the

CA's Certificate Policy and/or Certification Practice Statement;

4.            No Misleading Information: That, at the time of issuance, the
CA (i)

implemented a procedure for reducing the likelihood that the information

contained in the Certificate's subject:organizationalUnitName attribute

would be misleading; (ii) followed the procedure when issuing the

Certificate; and (iii) accurately described the procedure in the CA's

Certificate Policy and/or Certification Practice Statement;

EVG don't say anything specific about OU field. Section 9.2.8 states:

Other Subject Attributes

All other optional attributes, when present within the subject field, MUST

contain information that has been verified by the CA. CAs SHALL NOT include

Fully-Qualified Domain Names in Subject attributes except as specified in

Sections 9.2.1 and SHALL NOT include any Subject Organization Information

except as specified in Section 9.2. Optional subfields within the Subject

field MUST either contain information verified by the CA or MUST be left

empty. Metadata such as '.', '-', and ' ' characters, and/or any other

indication that the field is empty, absent or incomplete, MUST not be used.

Regards,

Rich

From: Validation <validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org> > On Behalf Of Doug Beattie via
Validation
Sent: Tuesday, February 5, 2019 1:21 PM
To: Tim Hollebeek (tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> ) <tim.hollebeek at digicert.com
<mailto:tim.hollebeek at digicert.com> >
Cc: validation (validation at cabforum.org <mailto:validation at cabforum.org> )
<validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: [cabf_validation] Topic for our next VWG call: LEI

Hi Tim,

I'd like to bring up the topic of LEIs at our VWG call next Thursday.  While
the topic was discussed last July
(https://cabforum.org/pipermail/public/2018-July/013659.html), I don't feel
like we reached an agreement.  

The OU fields seems like the most obvious place and the BRs say this about
the OU field:

*	The CA SHALL implement a process that prevents an OU attribute from
including a name, DBA, tradename, trademark, address, location, or other
text that refers to a specific natural person or Legal Entity unless the CA
has verified this information in accordance with Section 3.2 and the
Certificate also contains subject:organizationName, , subject:givenName,
subject:surname, subject:localityName, and subject:countryName attributes,
also verified in accordance with Section 3.2.2.1.

I'd like to discuss if the use of LEI identifiers in SSL certificates is
compliant with the BRs.  This is a pointer to the Legal Entity data at a
point in time (which a CA is obligated to verify at issuance per the
definition of OU above), however, LEIs can change over time:
https://leismart.com/blog/lei-data-is-not-static/  This means that while the
data will be verified by the CA when issued, there is no guarantee that the
data remains unchanged/vetted by the CA if it changes.

Is using LEIs in the subject name of SSL certificates permitted?

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