Subject: [Bimi] x.509 scalable enough, relevance of history of expectations

From: Thede Loder <[email-masked]>
Date: Mon, 18 Feb 2019 12:41:06 -0500

(Merging some discussion points about X.509.  X.509 is relevant to BIMI as the basis of the proposed Verified Mark Certificates, which can serve as containers to convey optional evidence of proof of rights, real-world actor identity, and other information along with the graphical (or audio) “logos” or marks.  Concern over scalability has been raised.  “Is it up to the task?”  And a call to consider history) 

In summary, it remains an open question as to whether it is up to the task.  Scalability is unlikely an issue (unless, say, there are significant changes to proposed scope of use.  No proposals known).  Additional discussion of the applicability of known forms of “faillure” is a good direction to head in.  

Recap of previous points made  (paraphases of prior posts for context)
================

Tim said: "DigiCert is willing to offer these certificates”  
 
Wei wrote: "We (Authindicators WG) have been working with Entrust-Datacard (CA) on the VM Certificate Guidelines, and they are willing to issue VM Certificates.  Others appear willing as well” 

Dave wrote: “What is the basis for thinking that this will work?  At scale?”  
  and “after 30 decades, there is no existence proof at scale.”  

Thede wrote: “Unlike 30 years ago, there are now 50+ Certificate Authorities.  Issuance of VM Certs is operationally incremental to CAs existing operations”  

============
End of Recap 

> On 2/14/2019 10:57 AM, Thede Loder wrote:
>>> On Feb 13, 2019, at 13:22, Dave Crocker <[email-masked]> wrote:
>>> 
>>> And my point was that
>>> though X.500 certs were in fact originally intended to support this
>>> sort of certification of 'interesting' attributes, over that entire
>>> 30 year history, they have proved to be not up to the task.
>> My knowledge of X.500 history is limited.  When you say 'proved not
>> up to the task', do you mean there's a lack of an existence proof as
>> to some promised level of adoption?  Or that there's some flaw or set
>> of flaws that have been identified and compellingly argued as proof?
>> I'd hate for us to repeat avoidable mistakes.
> 
> (It's been pointed out that I should have used "X.509" rather than
> "X.500", since the former refers specifically to the cert work, while
> the latter is the broader directory services work it was part of.)
> 
> As with X.500, X.509 had lofty and very general goals.  It was expected
> to be the vehicle for certifying all sorts of features and capabilities.
> To my knowledge very few have been realized, and other than TLS-kinds
> of uses, none at Internet scale.  I don't know the range of uses that
> were attempted, merely that none has seemed to survive at scale.

This sounds like failure to meet expectations of "lofty and very general 
goals”, not outright failure.  And if anything, not specific failures that 
are clearly applicable at this point to BIMI.  

As proposed, BIMI’s need of X.509 does not require X.509 to succeed for 
"all sorts of features and capabilities".  It needs only to succeed for a very 
specific (narrow?) kind of use, one with highly similar requirements 
and operational characteristcs for the parties involved (according 
to some doing X.509 in their day-job) to those associated with X.509’s 
mainstay uses today. 

Is “Internet scale” use of X.509 actually a requirement for BIMI?  If you define 
Internet scale as every end user having their own VM Cert, probably not.  
Such a scale requirement of this magnitude is therefore of minimal concern.  

Meanwhile, if in 5 years there are 50 million annually issued Verified 
Mark Certificates, X.509 will be serving just fine meeting forseen needs.  

Is there an existence proof that X.509 can scale to this level?  Yes; existing 
issuances levels are of the same order of magnitude, perhaps much larger 
(others with first hand knowledge can comment).  

If there’s enormous demand for Verified Mark Certificates and the supporting 
ecosystem must grow, it probably can on its own, and or we can put our 
heads around how to accomodate the demand.  This would be a great problem 
to have.  

> 
> 
>> Did X.500 prove not up to the task because it failed on technical
>> merits?
> 
> I encourage you to explore such questions in depth.  

I accept John’s answer (repeated further below).  

> 
> My point, for the purposes of the current discussion, is that we can't be casual about assuming that X.509 or, for that matter, this level of capability certification, will work at Internet scale, because we don't have an existence proof for it and we do know there are interesting security risks to worry about and we have 30 years of discouraging experience in this space.

Nobody is being casual.   We disagree on whether or not we have an existence proof.  And we likely disagree on whether or not Internet scale is needed, until we come up with an acceptable definition of Internet scale and how it applies.  

> 
>> Thede wrote:  
> 
>> Did X.500 prove not up to the task because it failed on technical merits?  E.g. was it not capable of containing some critical piece of information that applications and their stakeholders required?  Or did it fail for other reasons, like too difficult/costly to use, not enough demand, lack of compatibility with an installed base, and or poorly marketed?  There are lots of reasons why technologies and their ecosystems fail to take off and bring their promised value.
> 
> John L wrote:
> Technically X.509 works fine.  The failure is administrative and financial.  Twenty years ago TLS certs cost several hundred dollars and required extensive documentation, way more than what green bar certs ask for now.  There was a brisk race to the bottom ending up at Let's Encrypt, which costs nothing and promises nothing.  Green bar certs are proceeding briskly down that path (price started around $300, now $75 and dropping.)
> 
> Arguments along the lines of "this time is different" are not persuasive.

Thank you John.  It sounds like X.509’s failures have not been due to technical issues.  

Also thanks for bringing up some of the history, as I think an understanding of what has happened and why is relevant.  

What I think will be important to delve into sooner or later is this question: 

"Does BIMI’s success and end-user safety hinge upon on asking something of X.509 that it cannot deliver or where it is already known to have failed?  Alternatively, does BIMI ask of X.509 something for which it has already demonstrated success? “ 

For those who have not familiarized themselves with what is being proposed as VM Certificates, the following is a place to start:  

https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w

Thede

—
Thede Loder
Managing Director, Skye Logicworks LLC
E: [email-masked]
M: +1-415-420-8615

---

From: Richard Clayton <[email-masked]>
Date: Mon, 18 Feb 2019 18:24:55 +0000

In message <[email-masked]>,
Thede Loder <thede=[email-masked]> writes

>"Does BIMI’s success and end-user safety hinge upon on asking something of X.509 
>that it cannot deliver or where it is already known to have failed?  

yes .. certificate revocation basically doesn't work today and never
has.  Here's a fairly friendly summary

https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-
broken-in-practice-af3b63b9cb3

In practice where important certs have had to be revoked the approach
taken has been to update browsers. The equivalent approach in BIMI is
not immediately clear to me.

There's also some careful thought needed about the equivalent of
"revocation" for DNS information, since I expect people will set long
TTLs on BIMI data.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755