[cabf_validation] Topic for our next VWG call: LEI

[Ryan Sleevi]

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

> 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.
>

While I do share your concerns re: LEI, I am curious: Do you view this as
different than the status quo for other forms of identity information?

For example, how often do CAs enforce their Subscriber Agreements,
particularly that the Subscriber notifies the CA of information changing /
becoming no longer accurate?

Not wanting to pick on Sectigo, but since they're a member that recently
went through one of these events, it's an example that hopefully connects
with Forum members. A strict reading of the BRs seems that Sectigo (as
Subscriber) should have informed Sectigo (as CA) of the name change (BRs
9.6.3, Item 5), and that Sectigo (as CA) should have revoked all such
certificates (4.9.1.1 (8) ). However, that didn't happen (example:
https://crt.sh/?id=893532698 https://crt.sh/?id=893532620
https://crt.sh/?id=802815326 ).

I realize that CAs would likely argue that certificates aren't for that -
per 9.6.1 (4) being focused on "time of issuance".

Or we can take identity out of the equation - BygoneSSL shows that many
CA's cloud partners are not following the Subscriber Agreement w/r/t
notifying the CA when a 'end user' moves to another cloud partner. The
counter argument there, however, is that even the cloud providers may not
know. For example, the end user points DNS at the cloud provider/CDN, cloud
provider/CDN gets a cert, end user later points DNS elsewhere, but keeps
the account with the cloud provider/CDN - the cloud provider/CDN doesn't
know whether or not that user has gone away for good.

So we do have the problem of information changing during the lifetime of
the certificate and not necessarily being a stable identifier. We also have
requirements that they should be, as captured by Subscriber Agreement and
revocation requirements, while also CAs indemnifying themselves if it
isn't. So it's not clear that there's a "good" answer, and it may be useful
to explore similarities or differences between some of the existing
requirements, so we can ensure that CAs are consistent and principled in
treating that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190206/1d5aaff4/attachment.html>