[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

[Ryan Sleevi]

Thanks. This is far more helpful than blanket statements, because it helps
evaluate the context and claims being made here.

On Thu, Aug 9, 2018 at 1:56 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> Certainly you’re aware of the Apple proposal to put revocation contact
> information into certificates that was discussed this Spring in Virginia?
>

Sure, but the concerns there weren't, as I recall, strictly on size, but
more generally, on the applicability to RPs and the necessity of delivering
this information within the critical path.


> Various validation working group calls have at various times discussed
> putting richer validation information into certificates beyond Wayne’s
> proposal.  Stuffing random stuff into certificates is sort of a cottage
> industry at IETF, where luckily those attempts usually fail.  There’s also
> various proposals for adding information about potential locations to
> retrieve post-quantum public keys, as discussed in London.  There are a
> couple of other reasonable proposals I can’t talk about publicly.
>

I see. It's hard to evaluate these other proposals, then, so it's good to
focus on what has proposed. As discussed in London, and more generally, the
IETF, there seemed to be consensus that it was a *good* and *necessary*
thing for that PQK delivery, since that is in the critical path for RPs,
and is essential to the assurance and reliance upon the claims in the
certificate (namely, that the domain asserted in the certificate is bound
to that PQK)


> Other proposals to add this, that, or the other thing to certificates
> surface regularly on various fora I follow.  I can’t provide an exhaustive
> set of links, because I simply do not have the time.  But that doesn’t mean
> they don’t exist.  In many of these cases, a Certificate Metadata log would
> be a better solution than stuffing additional information into
> certificates.  Internally here, the pros and cons for various use cases are
> debated regularly.
>

This is where we disagree. Again, it's easy to suggest a 'log' might be a
good place for it, but the evaluation of each proposal needs to be on the
merits relative to the RP. If we can set aside the buzzwords, we could call
"OCSP" a "Revocation Metadata log" - and quickly it becomes readily
apparent the host of ecosystem issues we need to consider when moving such
information to secondary sources (How does the client get that information?
Is it necessary in order to successfully establish a connection? What are
the privacy and performance implications of that lookup? How will third
parties actually validate that data?)

Thus, I think it's helpful that every time someone suggests we "Add it to a
metadata log", we take an earnest and heartfelt evaluation about whether we
would feel the same about "Add it to OCSP instead" - and whether the
tradeoffs are being appropriately considered and articulated.

Obviously, there's an extreme level of silliness - why even bother with
certificates? We could express 'everything' with just (key + metadata log
URL), where information such as 'validity period' and 'domain name' are
provided by the log, rather than the "neo-Certificate". We recognize that's
extreme because we realize the tradeoffs - for performance, usability, and
complexity - would be terrible for the use case at hand. This is why
certificates encode information like, well, issuer, validity period, etc.
So when folks propose new extensions to be introduced to certificates, its
often because having that information readily available is essential to the
trustworthiness of the connection. Does problem reporting email make sense
for connection establishment? Maybe, maybe not. Do things like the level of
assurance of the domain validation belong there? Almost certainly.

So it's very much a spectrum, and not something a metadata log will solve
by any means (and merely introduces more complexity and challenges).


> Of course, the biggest roadblock is that currently such logs don’t exist.
> But that’s a fixable problem, for those companies with CT implementations.
>

Again, I think this is mistating how CT works, or, more generally, how
transparency works. These don't magically provide assurances - at least,
not without a whole host of other quite difficult ecosystem considerations
- and every proposal to date has been "stick a log on it", which is the
technical equivalent to "put it on the blockchain" in terms of
deployability and reasonableness (i.e. none).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180809/9e4a3767/attachment.html>