Re: [Bimi] Where do the signed certificates come from?

[Thede Loder <[e-mail]>]

Hi Dave, 

Thanks for engaging and providing a thoughtful reply.  Agree we need to show our work.  A value we likely share is being respectful of people's time.  If participants on this list and in the larger community are to invest their time with BIMI (such as to try to further it, shape it, or even to try to stop it), best they do it from a place of knowledge rather than ignorance - and with a clear understanding of its merits, costs, and risks.  The discussion/debate about these is really important.  

> On Feb 13, 2019, at 13:22, Dave Crocker <[e-mail]> wrote:
> 
> Thede,
> 
> On 2/13/2019 8:38 AM, Thede Loder wrote:
>>> On Feb 11, 2019, at 16:14, Dave Crocker <[e-mail]     What is the basis for thinking that this will work?  At scale?
>> Some reasons in favor of scale:
> 
> A goal for my question is thoughtful and focused consideration of the issues.  Long lists of unanchored references don't achieve that, even if the list is in fact perfectly relevant.  This is an exercise for which giving the answer is simply not enough.  We need to show our work.
> 
> So...
> 
> 
>> * Unlike 30 years ago, there are now 50+ Certificate Authorities 
> 
> 30 years ago was a starting point.  My comment was about 30 years of history, not about the starting point.  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 would be interesting to know: 

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.  

If you or someone else has a good sense of this, please enlighten and let's not repeat history.  

I personally believe an important factor for BIMI (now) is "readiness of the market", broadly "market conditions", the technology ecosystem, relevant environment.  I'll try to expand this as we go, as it's not something I know how at present to simply state or prove.  There's alot going on.  

A relevant example of an idea being around for a long time but not having success (in the form of near-ubiquity) until conditions became "right" is the radiotelephone.  Radiotelephones have been around since at least the 1930s (https://en.wikipedia.org/wiki/Radiotelephone), but practically invisible for the first 60 years unless you were a mariner involved in commercial-level oceanic shipping or in the armed forces.  

Cell phones were introduced in the early 80s, truly hand-held ones (Motorola StarTAC, anyone?) in the 90s.  But radiotelephones _really_ took off in the late 2000s with the smart phone (iPhone).  Same idea the whole time, but greatly different adoption costs, installed base (like other phone lines to call), packaging, per-unit cost, and bundled features over time.  (In 1930s, how many people had a phone, let alone a radio phone)?  

> 
> So the question is why this proposed use will enjoy a better outcome?
> 
> Also note that there are massive problems with exposures and misbehaviors of the CA operator mix.  (Oddly, folks inside the security community seem unaware of these problems, while folks outside the security community seem to view them as obvious and massive.)

We should dig into the specifics of the potential exposures and the massive problems you cite (references please).  As we've planned VM Certs so far, we've tried to address known problems.  But only the ones known to us, and there may be more.  

As it is planned, Verified Mark Certificates will be supported through their own root programs, with intermediate certificates explicitly approved.  This means existing CA roots (62 in Firefix, thank you Richard!) from the web-TLS world will have no bearing on the trust-chain for VM Certs.  At first, only a handful of CAs will be able to issue VM Certs and have any expectation of Internet users (in the IETF sense of users, not "end users" per se) trusting the contents for specific uses.  

Then there's CT, but I'll come back to it in the context of Richard's post.  

> 
> 
>> spanning the globe and serving a mix of market consituents, large and small.  Supporting VMCs are operationaly incremental.
> 
> This being a technical forum, I hope we can avoid marketing language. As for the technical point about being operationally incremental, I'm not sure what you mean.  Please be specific.

Fair point, I'll try to avoid it.  What I meant by operationally incremental is this: VM Certs, while distinct from TLS certificates, share some common vetting, auditing, and software and hardware infrastructure requirements to produce, distribute, revoke, and maintain.  There are extra vetting requirements of course.  For existing CAs or new CAs considering getting going, there's plenty of overlap, implying that issuing these certificates does not require the creation of a wholly new industry - which would otherwise weigh strongly against the success of BIMI.  

The same notion of operationally incremental applies to the efforts required of certificate applicants ("buyers"), again in comparison to what is required for TLS, code-signing, or S/MIME certificates.  We don't expect a prohibitive learning-curve with the installed base of people and processes - in fact, VM Certs are in many ways easier to explain to an Applicant, not harder.  

> 
> 
>> * TLS certificates are well known to individuals and organizations large and small.  They didn't even exist 30 years ago.
> 
> And yet the real-world semantics and efficacy of their use is impressively narrow, and there is widespread bypassing of the independent CA system.

My point was mainly to say that there's an installed base of knowledgable-enough certificate Applicants, and we anticipate significant overlap with users of VM Certs.  Lack of an installed base and a large pool of knowledgeable people is a common contributor to technology adoption failure.  

The bypassing of the CA system, while I agree is troublesome in some contexts, seems like evidence of good protocol design - users can take parts of the technology and use them independently of the whole originally-designed scheme.  (If public CA-issued certs aren't worth the trouble from the perspective of a certificate applicant, the applicant can still realize value from the technology).  

Overall, VM Certs are significantly different from TLS certificates.  Perhaps their efficacy will more closely meet expectations, perhaps not  :-) 

> 
> 
>> * the process for obtain a Verified Mark Certificate is largely the same as obtaining a TLS certificate, and the extra steps will be readily understood by those responsible for the management of intellectual property.  (At least for the first type of alternative identity contemplated)
> 
> The semantics for a VMC are significantly different than for a TLS cert.  The differences are important, as are the existing issues with getting and using a TLS cert.

Agree.  


> For the most part, the usual, reasonable benefit of a TLS cert is a private connection to the site you intended. (And note that with the popular use of self-signed certs even that benefit has some important limitations.)
> 
> That's quite different from trusting a displayed mark to an end user.

Yes, absolutely.  So we'll have to delve into this.  

> 
> 
>> * DNS scales (or we have bigger problems)
> 
> I'll guess this should translate into:  BIMI is built on top of an existing platform of services that are known to scale well.
> 
> That's not an irrelevant point, but it's also not an interesting one for this discussion, IMO, since that's not where the design and operations concerns are.

What are the main design and operations concerns?  

> 
>> * Internet users want it - clear demand
> 
> That claim keeps being made but I've never seen any serious documentation for it.
> 
> Worse is the question of efficacy.

> What is the end-user benefit in having marks displayed?  I'll suggest you point at, and comment on, the considerable research about this point that was done when the BIMI effort started a couple of years ago.


To clarify, by "Internet users", I meant all of the Internet's users, not soley end-users.  Within the set of all Internet users, there are many groups of users who want it:  brands, platform and application providers (who are also brands), CAs and auditors (who are also brands and have profit motive), email senders (who are often brands and always have identity), ESPs (who are brands and who wish to serve brands with services), financial services companies and retailers, etc. (who are brands).  

Moreover, I see no reasons why governments, local, state, and national and NGOs would not also want their non-textual identities to be available in Internet applications to those they want to communicate with.  


I don't think at this point it is reasonable to require direct evidence of end users wanting BIMI, as no end users other than those on this list or who attend email-related conferences, CA conferences, or ESP conferences have had the ability to learn of its existence.  

However, end-user do already use email MUAs which display logos representing sender identity.  While some users may feel that these logos were forced upon them, take up valuable space, and they do not want them, I would not be surprised if others are happy with their display, and that still others (perhaps the majority) experience improved ease-of-use through them even if they do not explicitly attribute the improvement to the display of the logos.  

It would be interesting to know if the product managers of these MUAs have received floods of complaints (or floods of kudos) regarding the display of logos.  Perhaps someone on the list can comment.  

For concrete examples of MUAs currently showing logos (a use-case BIMI aims to support), O365's web mail, the Gmail native IOS and Android app, the Yahoo IOS and Android app, and 1 and 1's MUAs have all been doing so for some time (on the order of 1-4 years).  I am happy to supply screenshots.  


You bring up the question of efficacy.  I am aware of the implied forms of efficacy expressed in RFC 3935, such as making the Internet better.  How do you think participants in this effort should define efficacy?  


(the quote below repeated for context) 

> What is the end-user benefit in having marks displayed?  I'll suggest you point at, and comment on, the considerable research about this point that was done when the BIMI effort started a couple of years ago.


Speaking for myself, I see two forms of benefit for end-users: 

1) Improved Safety* 
2) Improved ease-of-use* 

* Both benefits require some characterization and limitations apply.  Improved safety will come largely through improvements in the relevant surroundings and infrastructure that supports the end-users' activities, rather than through better end user-mediated conscious choices, from having increased availability of certificate-contained information users consciously consume, or through associated training.  The research confirms the latter assertion quite well; end-user mediated improvement is tiny at best.  

To the point of the primary means through which end-user safety will be improved, analogies of infrastructure improvements of this nature from the real world include: 

o  building codes enacted by governments and enforced by inspectors that improve building survivability in earth quakes 
o  highway design and construction codes that improve the safety of highways 
o  the practice and requirement deploying air-bag systems in cars

All of these things make people safer largely or entirely without users having to even be aware of them.  We know that hanging the success of BIMI on end users consciously making safer choices is unwise.  Fortunately, it's not necesssary. 

Logo display for any reasonable application is going to require verification of authenticity.  This requirement motivates adoption of authentication, along with additional transparency and vetting of actors.  


Ease-of-use, meanwhile, can come in at least two flavors: reduced cognitive costs (and real time expended) in identifying and selecting desired communication from a sender (or identifying the unwanted, as someone suggested in another thread), and fewer mistakes in attribution of sender identity to a message or post.  

Without going into too much detail, humans can read letters and words.  They can also associate meaning with images.  BIMI will make it easier for application developers to include relevant images of identity, allowing people to utilize both forms, rather than be limited to one.  Identity is kind of important, so why not bring both forms to bear?  

> 
> 
>> * there is no "rocket science" involved; the formats, process and supporting technology are straightforward extentions  and analogous to what is already in practice today
> 
> There is in fact quite a bit of rocket science.  There is even a basis for claiming that what is being attempted is beyond the state of the art, based on historical performance.

You might be right.  And it's worth hearing (and learning from) the history.  

That said, there's quite a bit of interest from many of the parties involved, quite a bit of thinking about challenges that has already occurred (and needs to be shared), and there's generally something 'in it' for the parties involved that have to invest the most to make it happen.    

Alignment and will, as we know from history, puts rockets on the moon.   

> 
> The problem with claiming things are rosy is in looking at this component or that rather than at the integrated system.

Let's look at the integrated system.  Where do you want to begin? 

> 
> 
>> * authentication schemes necessary for safe use with a primary anticipated application having 2 billion users is already widely supported
> 
> This seems to be another component-level comment, but I'm not certain.
> 
> Hoping that you are not commenting on the underlying crypto algorithms, I'll guess you mean SPF, DKIM and DMARC.  

Yes, that's right.  Others could serve in their place, but those are widely deployed at least on the application platform provider side of things.  

> If so, note the considerable misunderstandings that are prevalent about their semantics and how much broader the semantic of Bimi is, which suggests even more serious misunderstandings.

Really good point.  One consideration though is that most groups of users will only need a detailed understanding of the actions and context that they need to make to take part.  Two big constituents, senders and end users (for the use case of email) have it relatively simple.  Senders will need to post a simple BIMI Assertion Record and obtain a VM Certificate, mostly likely from their existing CA with whom they already have a relationship.  End users won't have to know or do anything at all.  Logos magically show up, as they are doing in applications now.  

Clarifying and streamlining documentation for implementors, I think of that as our (collective) jobs.  

> 
> 
>> * trademarks scale.  There are ~2M design marks with the USTO, estimated 20M world wide, and scalable processes and government support to handle increased demands.  They have legal standing.  Registration jurisdictions can be expressed as ISO country codes unambiguously
> 
> The internet is global.  How things work in a particular country are generally not that relevant to Internet standards work.
> 
> On this list already, others have have already raised some points about challenges in using trademarks within Bimi.  And this topic has been raised throughout the history of Bimi work.  To date I haven't seen any sort of comprehensive treatment of the concern that actually deals with it.  I believe that one of the submitted documents basically classes it as 'for further work'.

I am certain that some of the key issues have been considered and have partial or full solutions, but perhaps not all;  the topic is a very important one and deserves its own thread.  Would you be willing to start it, and outline some of the concerns you have or have heard?  Several on the list have been deep in the problem characterization and solution space, and can start sharing.  

> 
> FWIW:
> 
>     The string 'mark' doesn't appear in draft-chuang-bimi-certificate-00, draft-chuang-bimi-certificate-00
> 
>     It appears in draft-brotman-ietf-bimi-guidance-00 in a hypothetical context.
> 
>     So I assume the serious effort on this is in the nascent Verified Mark Certificates Usage(*) document?
> 

Yes, and in security considerations documents.  The use of 'mark' has been controversial in part because of an inclination for BIMI to support distribution of graphical identity other than true trademarks (in the sense of a nationally registered trademarks).  "Mark" is not particularly marketer-friendly, at least not universally; "brand" or "brand logo" is more common; as a result, the documents are somewhat inconsistent.  I'd like to see consistent use of terminology as we go.  

> 
> (Anecdote:  In the pre-ICANN IAHC, which developed the term gTLD, the model of registrar/registry split, and the concept of the UDRP, and for which I was the editor, our first meeting included the representative of the WTO suggesting we resolve the global DNS concerns about trademarks by using international trademarks.  Being on non-lawyer, I pretended ignorance, noting that I thought trademarks were only national constructs, and then I asked whether international trademarks already existed.  The WTO representative admitted they didn't but offered that discussions were underway.  I asked how long they had been going on for and he said 100 years.  So forgive me if I find myself rather more skeptical about resolution of this topic than one might wish...)
> 
> 
>> To the point of an existence proof, it would be impossible to have one prior to having it.  But do we think CAs can issue millions or even billiions of VM Certs?  Sure.
> 
> My question really was about related work.  To the extent that Bimi relies on existing capabilities or makes relatively small adaptations to existing capabilities, the the only risk is in the increment.  To the extent that it is doing anything that really has no serious precedent, the risk is obviously larger.  The same holds for relying on existing work that in fact has proved problematic.

Completely agree.  I personally would love to see this process tease out the latter, where it applies. 


Thank you, 
Thede



> d/
> 
> 
> (*) https://docs.google.com/document/d/1OzL9FqexZpZJQuoqAK2E3sXjOwEcLNCvXW7e88Olt2I/edit#heading=h.h31mzi4ac5st
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net


--
Thede Loder
Managing Director, Skye Logicworks LLC
E: [e-mail]
L: https://www.linkedin.com/in/thede
M: 415-420-8615