[cabf_validation] Topic for our next VWG call: LEI

Wed Feb 6 13:57:34 MST 2019

Just as an FYI, we’ve arranged for Stephan Wolf, CEO of GLEIF, to be a guest speaker in Thessaloniki.

Dean

From: Validation <validation-bounces at cabforum.org> On Behalf Of Tim Hollebeek via Validation
Sent: Wednesday, February 6, 2019 3:10 PM
To: Ryan Sleevi <sleevi at google.com>; Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Topic for our next VWG call: LEI

Yup, it’s a great topic for both the call and further discussion on the list.

I find myself in Ryan and Rich’s shoes, wondering how this is different from other cases where the exact same thing can happen.  A certificate makes no promise about the immutability of information that may be found in third party information sources.  There are even cases where this is a good thing.  For example, an error in the LEI database is corrected post-issuance.  Certainly you aren’t going to revoke a certificate because the publicly available information is now BETTER than it was at the time of issuance?

-Tim

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Wednesday, February 6, 2019 2:57 PM
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> >
Cc: Richard Smith <rich at sectigo.com <mailto:rich at sectigo.com> >; Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Subject: Re: [cabf_validation] Topic for our next VWG call: LEI

I agree, it sounds like a great topic for the call, and trying to make sure to do as much pre-work and carry some of that momentum.

It's not clear to me why you'd have concern with the DUNS number but would be OK with the Organization Name. It seems that both can change without the CA verifying/approving the changes, so it's not clear to me what the essential difference is.

On Wed, Feb 6, 2019 at 2:54 PM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

I think this is why an agenda item for the call…

It’s different because the data in the corporate registration database isn’t bound into the certificate and asserted as true by the CA.  If we included a DUNS number I’d have the same question/concern.

Assume that we include just the DUNS number or LEI in a certificate, and the CA validated the information at the time of issuance, then the data changed.  Without the CA verifying/approving these changes, we’ve lost control over what was validated.  Rogue changes could be made to the repositories that would normally be caught by the CA.

From: Richard Smith <rich at sectigo.com <mailto:rich at sectigo.com> > 
Sent: Wednesday, February 6, 2019 2:26 PM
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

And again, how is that any different to data changing in the corporate registration database after issuance?

Regards,

Rich

From: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > 
Sent: Wednesday, February 6, 2019 1:17 PM
To: Richard Smith <rich at sectigo.com <mailto:rich at sectigo.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

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 <mailto:rich at sectigo.com> > 
Sent: Wednesday, February 6, 2019 12:54 PM
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

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 <mailto:doug.beattie at globalsign.com> > 
Sent: Wednesday, February 6, 2019 11:37 AM
To: Richard Smith <rich at sectigo.com <mailto:rich at sectigo.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

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?

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

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