[cabf_validation] Topic for our next VWG call: LEI

Wed Feb 6 12:56:38 MST 2019

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> 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>
> *Sent:* Wednesday, February 6, 2019 2:26 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
>
>
>
> 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>
> *Sent:* Wednesday, February 6, 2019 1:17 PM
> *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
>
>
>
> 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>
> *Sent:* Wednesday, February 6, 2019 11:28 AM
> *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
>
>
>
> 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> *On Behalf Of *Doug
> Beattie via Validation
> *Sent:* Tuesday, February 5, 2019 1:21 PM
> *To:* Tim Hollebeek (tim.hollebeek at digicert.com) <
> tim.hollebeek at digicert.com>
> *Cc:* validation (validation at cabforum.org) <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
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190206/6be64818/attachment-0001.html>