[cabfpub] LEI information in web certificates

[Ryan Sleevi]

On Fri, Jul 6, 2018 at 7:09 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> So, if you read my original email, I already made the point that there is
> no need to go through the CA/Browser forum for this … it’s allowed today
> via CA-defined extensions.  I intentionally avoided the topic of subject
> information because the ETSI folks already stepped on that landmine, and
> had a bad experience.  My personal preference would be to be more
> supportive of their efforts as well, so we can allow new kinds of subject
> information where it makes sense to do so.  But I don’t think that’s
> necessary here.
>
>
>
> I really don’t care what OID arc it is on.  If you want it on the GLEIF
> OID arc and are willing to support a proposal for such an extension,
> great.  I just think there’s value in everyone using the same OID for the
> extension that is already allowed.  That’s kind of what standards are for.
>

In theory, I agree, but the CA/Browser Forum's structure and nature is that
it's far more preferable to define standards in a more open SDO than the
Forum allows - e.g. one that can actually allow and support the
participation of RPs. Whether that's through GLEIF or through another
organization, I don't think the CA/Browser Forum is or can be a good place
for those sorts of bespoke-extension-development.


> I don’t actually see anywhere in our requirements that using a GLEIF OID
> actually requires that the semantics are the GLEIF semantics.  I would have
> thought that would be something we’d have to specify, regardless of where
> the OID happened to live.  One of the reasons I think it should be
> standardized in CABF is exactly because I think the semantics and
> validation requirements should be standardized, instead of being contrived
> on an ad hoc basis by CAs operating independently.  I think that’s
> something people should be able to get behind.
>

I don't think it's such a black/white contrast. If using the GLEIF OID,
then you can allow GLEIF to define both the semantic expression and the
validation semantics. And that seems strictly more desirable than having
the CA/Browser Forum do so, considering that we are not GLEIF, and the
semantics will be dictated by the RP needs, which is all the more reason
that GLEIF should do it.


> So I do think there is a useful role for CABF here, even for an extension:
> specifying the OID to be used, and the semantics.  The actual details
> matter less, once people are productively working towards that goal.
>
>
>
> Yes, CAs can do this independently in coordination with GLEIF, but I’d
> prefer to not have to do that.  But avoiding that is going to require CABF
> members working together to find a solution that is acceptable to everyone.
>

Right, I disagree with this view that the Forum is the appropriate venue
for that. There's working with GLEIF, or within IETF if it's truly
applicable in the context of the Public Internet (c.f. 7.1.2.4 of the BRs).

As you note, the Subject information is a can of worms - but just because
that is so, doesn't necessarily mean we should be in the business of
defining extensions either. If the Forum is to take it up, which I don't
think it should (but am not opposed to industry doing so), then I think a
demonstration about its applicability and relevance to the public Internet,
and its use cases, is very much a relevant conversation to be had.


>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Friday, July 6, 2018 6:39 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
> *Cc:* CABFPub <public at cabforum.org>
> *Subject:* Re: [cabfpub] LEI information in web certificates
>
>
>
> Tim,
>
>
>
> I'm not sure that sort of hand-waving will help us find a good technical
> solution. By defining precisely how these LEI identifiers are to be used,
> we can better understand and address the design space.
>
>
>
> For example, we've already standardized on "someone else's" OID arc for
> plenty of X.500 attributes. While OIDs are a dime a dozen, it's important
> in identifying who the change management authority is and the context for
> this information. If it's using the CA/Browser Forum OID arc, then it's an
> expression that the CA/Browser Forum believes there is particular value in
> this expression - and thus, the expression of, and suitability of, that
> information is extremely relevant to the discussion.
>
>
>
> If using a GLEIF arc, then it's saying that the naming and attribute
> authority is GLEIF. This avoids the host of issues with the ETSI
> repuroposing of the X.500 attributes in a way that are ambiguous, and makes
> it far easier to say "If you believe this attribute has value, then sure,
> you can include it". Relying parties know to trust that information as far
> as GLEIF throws it. Put differently, I'd be inclined to suggest that if it
> uses a GLEIF OID arc, then there's nothing that the Baseline Requirements
> would need to endorse or specially support - it would simply be "validated
> as defined by GLEIF" - and they can set their own requirements there for
> those that would wish to use this information.
>
>
>
> As for the CA/Browser Forum being in the business of telling people how to
> use the information that is validated - I think that's a rather absurd
> suggestion. If we're saying it's valuable to include in certificates, it's
> because it fit for a purpose when validated according to a set of
> requirements. If we'd like to avoid that responsibility to the Web PKI
> community, then either not expressing it in server certificates (an
> entirely appropriate response) OR deferring the requirements of that
> validation (and, therefore, the RP usage) to GLEIF entirely - through the
> expression of the GLEIF OID arc - is another.
>
>
>
> That's why this is such an important thing to resolve. Just because we can
> stick things in certs does not mean we should. The CA/Browser Forum offers
> considerable flexibility with respect to X.509v3 extensions, and for good
> reason - it allows a host of innovations in the space. In this regard, it
> is a blacklist, rather than a whitelist. But to the extent folks in the
> Forum believe that there is any value in subject information beyond that
> which is essential for server certificates (namely, the domain name), then
> it's necessary to blacklist.
>
>
>
> Now, obviously, one can do an end-run around this whole issue by
> expressing the LEI identifier as an X.509v3 extension, rather than as a
> subject attribute, without any involvement of the CA/Browser Forum (nor any
> changes required). However, to the extent folks believe it is relevant in
> the Subject Name (or Subject Alt Name), then it's necessary to discuss and
> resolve these expected, valid, and anticipated use cases, in order to
> choose an appropriate design.
>
>
>
> On Fri, Jul 6, 2018 at 6:27 PM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
> I’m not sure us standardizing using someone else’s OID arc instead of ours
> has a lot of added value, but it could be done.  I doubt they really care.
> I certainly don’t.
>
>
>
> Google is certainly free to not consume the information if they do not
> feel it is valuable to them.  To be clear, the link would be between a
> validated identity and the associated LEI (we continue to see lots of value
> in asserted and validated identities whether it be a VAT id or any other
> identifier with well-defined validation rules).  You can put LEIs into DV
> certificates, but I’m not sure I see the point.
>
>
>
> Relying parties are free to make use of validated information found in
> certificates in any way they find useful.  We’re generally not in the
> business of telling people how to use the information we validate, which is
> one of the things that distinguishes us from some other CAs.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Friday, July 6, 2018 5:37 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CABFPub <
> public at cabforum.org>
> *Subject:* Re: [cabfpub] LEI information in web certificates
>
>
>
>
>
> On Fri, Jul 6, 2018 at 4:29 PM Tim Hollebeek via Public <
> public at cabforum.org> wrote:
>
>
>
> As many of you are aware, the GLEIF foundation recently invited CA/Browser
> Forum members to its identity management workshop.  Some people have
> contacted us about the possibility of putting LEI identifiers into web
> certificates.  This is in some ways similar to the recent proposal from
> ETSI to put additional identity information into certificates, though it
> has the advantage that we are free to determine ourselves how best to
> encode it.
>
>
>
> CAs are already allowed to include this information in certificates,
> assuming it has been appropriately validated.  There is a Global Legal
> Entity Identifier Index that is authoritative for LEIs.  However it would
> be valuable if there were a standardized CABF OID and extension so that
> every CA that chooses to include this information includes it in an
> interoperable way.  This also allocates the OID in a namespace we control,
> allowing us to state in the BRs the purpose and semantics of the extension,
> and require that it only be used for authentic and validated LEIs.
>
>
>
> It seems to me that it would be worthwhile to standardize this, instead of
> every CA coming up with their own way of doing it.  What do other people
> think?
>
>
>
> Could you explain how this information would be used by Relying Parties?
>
>
>
> The GLEIF model effectively relies on third-party RAs, with all of the
> attendant issues, and without a clear framework for addressing many of the
> issues that has been held in the CA ecosystem. I'm not sure the value
> proposition here, or that the information is something RPs should
> necessarily use. As to whether or not it's appropriate, I think that's
> going to be very much contingent upon what the intended semantics being
> introduced are - that is, what relationship, if any, is being expressed
> between the LEI ID and the domain - and that opens a host of complexity
> that could easily detract from the far more pressing and meaningful work on
> improving the domain and information validation.
>
>
>
> I'm not sure why a CABF OID would be more useful than a GLEIF OID (which
> seems far more appropriate), and with a defined syntax relevant for GLEIF.
> I can think of no good reason to use the CABF arc, so I'm hoping you could
> explain more that thinking.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180706/f312fdb1/attachment-0003.html>