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

From: "John R Levine" <[email-masked]>
Date: 10 Feb 2019 23:39:10 -0500

BIMI appears to assume that senders will have TLS certificates that include 
RFC6170 certificate images, signed by a CA that attests that the image is a 
logo that belongs to the same entity as the domain name in the certificate.

Is this supposed to be a DV, EV, or some other kind of certificate?  Are there 
any CAs that will do the logo attestation?

Logos, like all trademarks, have geographic scope, and it's not rare for a 
trademark and logo to belong to one company in, say, the US and a different one 
in Europe.  How will that work?  I don't think there's any way for a cert to 
say it's only valid in some countries.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Wei Chuang <[email-masked]>
Date: Sun, 10 Feb 2019 22:19:15 -0800

On Sun, Feb 10, 2019 at 8:39 PM John R Levine <[email-masked]> wrote:

> BIMI appears to assume that senders will have TLS certificates

BIMI (sometimes documented as Verified Mark) certificates should be
considered a different PKI than TLS certificates.  The certificates have a
distinguishing Extended Key Usage for this.

> that include
> Is this supposed to be a DV, EV, or some other kind of certificate?

The proposed validation as documented in the guidelines (see Seth Blank's
Feb 6th post) builds upon web EV but of course includes a logo (and
optionally name) validation that goes beyond what is done for web EV.

>   Are there

We (Authindicators WG) have been working with Entrust-Datacard on the
Guidelines, and they are willing to do this logo attestation.  We also are
talking with other CAs, and believe that at least one other is willing.

> in Europe.  How will that work?

There is a trademark registration country/region level jurisdiction field.
Currently the guideline specification only allows for a single
jurisdiction.  One open question is whether to specify multiple
jurisdiction in a single cert and another is how to do this.  (There are
some compounding issues in this space that make this potentially
challenging)  That's something I hope the IETF can help with.

-Wei

>   I don't think there's any way for a cert to
> --
> bimi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bimi
>

---

From: Wei Chuang <[email-masked]>
Date: Sun, 10 Feb 2019 22:28:27 -0800

On Sun, Feb 10, 2019 at 10:19 PM Wei Chuang <[email-masked]> wrote:

> There is a trademark registration country/region level jurisdiction
> field.  Currently the guideline specification only allows for a single
> jurisdiction.
>

One more bit of nuance here.  We think a single jurisdiction is sufficient
to start, but we welcome feedback on this.

-Wei

> One open question is whether to specify multiple jurisdiction in a single
> cert and another is how to do this.  (There are some compounding issues in
> this space that make this potentially challenging)  That's something I hope
> the IETF can help with.
>
> -Wei
>
>

---

From: Thede Loder <[email-masked]>
Date: Mon, 11 Feb 2019 10:22:04 -0500

Here are a few more tidbits on Verified Mark Certificates and their relationship to BIMI.  Some on the list will not have been close to their development over the last year.  

Highlights: 

* Verified Mark Certificates are designed to be compatible with BIMI's publishing and discovery mechanisms and anticipated uses with email, OATH, and social media.  However, VM Certs are not tied to BIMI in any way, nor does BIMI itself require domain registrants to obtain them 

* issued VM Certs must be published in well-known Certificate Transparency (CT) logs in order to be considered valid.  The CT entry must include all material contents of the cert, allowing review.  

* VM Certs are issued by intermediates which are dedicated to the issuance of VM Certs, and distinct from TLS intermediates.  

* we anticipate that some 'Consuming Entities' (parties offering services which partially or heavily rely upon VM Certificates) will operate their own VM Certificate "root programs".  These are analogous to TLS "root programs"

* VM Certs require f2f verification, subject to a sunset provision 

* While a VM Cert can contain a signed public key of the certificate Applicant, the certificate is not for server identification as with EV, and has a different EKU.  The important components of the cert are instead a list of FQDNs, the legal entity identifying information, the embedded logo, and the trademark registration and jurisdiction information which substantiate the Applicant's rights rights to the logo 

* the initial draft defined a set of acceptable vetting methods.  We would like over time to define other acceptable vetting methods suitable for situations beyond the one where the Applicant holds the registration of the mark directly 

* latest draft for reference (as Seth referenced previously) is here: https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w

Thede

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

> On Feb 11, 2019, at 01:19, Wei Chuang <weihaw=[email-masked]> wrote:
> 
> 
> 
> On Sun, Feb 10, 2019 at 8:39 PM John R Levine <[email-masked] <mailto:[email-masked]>> wrote:
> BIMI (sometimes documented as Verified Mark) certificates should be considered a different PKI than TLS certificates.  The certificates have a distinguishing Extended Key Usage for this.
>  
> that include 
> The proposed validation as documented in the guidelines (see Seth Blank's Feb 6th post) builds upon web EV but of course includes a logo (and optionally name) validation that goes beyond what is done for web EV.
>  
>   Are there 
> We (Authindicators WG) have been working with Entrust-Datacard on the Guidelines, and they are willing to do this logo attestation.  We also are talking with other CAs, and believe that at least one other is willing.  
>  
> There is a trademark registration country/region level jurisdiction field.  Currently the guideline specification only allows for a single jurisdiction..  One open question is whether to specify multiple jurisdiction in a single cert and another is how to do this.  (There are some compounding issues in this space that make this potentially challenging)  That's something I hope the IETF can help with.
> 
> -Wei
>  
> John Levine, johnl@iecc..com <mailto:[email-masked]>, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly <https://jl.ly/>
> 
> -- 
> bimi mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bimi <https://www.ietf.org/mailman/listinfo/bimi>
> -- 
> bimi mailing list
> [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Feb 2019 07:29:02 -0800

Folks,

BIMI sits at the crossroads of challenging security and usability (human 
factors) issues.  It is far too easy to take the collection of submitted 
drafts and focus on their many details, without first establishing the 
basic functional goals and issues, design goals and issues, and 
operational goals and issues.

For all of the text that has been submitted, what is first needed is a 
document that discusses these at a level that allows meaningful 
consideration of its conceptual and operational foundations, so as to 
establish what aspects of BIMI are clear, well understood and tractable, 
vs. what aspects are not, and how the latter can reasonably be resolved.

Of course, the submitted drafts do contain some text tailored to this 
level of discussion, but only as an adjunct to the extensive detail in 
the specifications.  Hence they contain basic descriptions and 
assertions, but lack necessary detail and substantiation.

Merely by way of example, the opening sentence in the Abstract of 
draft-blank-ietf-bimi-00 says:

>    Brand Indicators for Message Identification (BIMI) permits Domain
>    Owners to coordinate with Mail User Agents (MUAs) to display brand-
>    specific Indicators next to properly authenticated messages.

So the principal actors are domain owners and MUAs?  That's probably not 
quite right, since there is reference to brands, without clarifying the 
relationship between brands and domain owners.  (What's intended is 
pretty obvious but actually needs extensive discussion, as John L's note 
from last night exemplifies.)

And then there's "properly authenticated messages" which is reasonable 
if the nature of "properly authenticated" is well understood, but which 
is we regularly see is highly problematic for an average reader who will 
think that the phrase means far more than it actually does.

Again, this is just an example.  Other summary text in the drafts 
invites similar concerns.

I strongly suggest collecting and developing such language into a 
separate, coherent concepts and facilities draft, so that discussion can 
focus on the BIMI forest, before inspecting its trees.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 11 Feb 2019 15:57:22 +0000

DigiCert is willing to offer these certificates, and is also willing to run a 
Certificate Transparency log for the ecosystem.

-Tim

  Are there

---

From: Richard Clayton <[email-masked]>
Date: Mon, 11 Feb 2019 16:20:51 +0000

In message <[email-masked]>, John R Levine
<[email-masked]> writes

>Logos, like all trademarks, have geographic scope, 

they also have an "area of business" scope within the same geographic
area ... and there's a substantial amount of caselaw which is meant to
(IMO rather ineffectually) clarify this issue

that's fine in the real world where I can tell by context whether I am
dealing with the maker of widgets or the maker of thingummys ... but a
list of unread email does not have particularly good context

>and it's not rare for a 

"10 Massive Companies With Unbelievably Similar Logos" is even available
as clickbait:

http://whatculture.com/offbeat/10-massive-companies-unbelievably-
similar-logos

the substantive issue here (and I endorse Dave Crocker's view that
little useful progress will be made until we establish the reason for
wanting to wander around this forest in the first place) is that there
is not a 1-1 mapping between domain names and brand logos and any
attempt to pretend otherwise is doomed to fail (and messily in the
courts)

- -- 
richard                                                  Richard Clayton

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

---

From: Richard Clayton <[email-masked]>
Date: Mon, 11 Feb 2019 16:28:28 +0000

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

>    * Verified Mark Certificates are designed to be compatible with 
>    BIMI's publishing and discovery mechanisms and anticipated uses 
>    with email, OATH, and social media.

should I translate OATH to MAGY (Microsoft, AOL, Google, Yahoo) or
should I translate it to "Verizon Media" ???

>    * we anticipate that some 'Consuming Entities' (parties offering 
>    services which partially or heavily rely upon VM Certificates) will 
>    operate their own VM Certificate "root programs".  These are 
>    analogous to TLS "root programs"

do you expect these to operate akin to 1990s TLS "root programs" where
the offer of a suitable bribe appeared to be a key way of ending up in
the list of trusted people ??  or like a more modern "root program"
where there are objective criteria (so all the arguments about meeting
those criteria come down to bias and politics?)

this is not meant to be a flippant question because if display of your
logo is "pay to play" then we are all going to be wasting our time
considering details of a complex technical protocol when all that
actually matters is whether or not the cheque cleared

>    * VM Certs require f2f verification, subject to a sunset provision 

face-to-face never works well in the dark

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

---

From: Thede Loder <[email-masked]>
Date: Mon, 11 Feb 2019 11:45:48 -0500

> On Feb 11, 2019, at 11:28, Richard Clayton <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Ooops, typo.  Sorry, I mean OAUTH, the multi-party authentication mechanism, not the media company.  

Thede

---

From: Seth Blank <[email-masked]>
Date: Mon, 11 Feb 2019 09:13:12 -0800

> vs. what aspects are not, and how the latter can reasonably be resolved.

Are there some RFCs that you believe accomplish this particularly well that
we could use as a reference?

We also have two older documents that we were planning on cleaning up and
releasing as informational I-Ds around security concerns and threat models
for BIMI, that we were planning to publish next month. Would these make
sense in this same overview document, or as something separate?

Seth

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Feb 2019 09:23:12 -0800

On 2/11/2019 9:13 AM, Seth Blank wrote:
> Are there some RFCs that you believe accomplish this particularly well 
> that we could use as a reference?

Search the RFC archive for documents about concepts, architecture, goals 
and the like.

The exact language for labeling this class of document varies quite a 
bit, as does the approach to writing them, including the level of detail.

d/

---

From: Thede Loder <[email-masked]>
Date: Mon, 11 Feb 2019 13:45:55 -0500

> those criteria come down to bias and politics?)

A model for a “root program” could include objective criteria, regular WebTrust audits (or the ETSI or Government equivalents) extended for VM Certs, and transparency with the operator publishing their program’s approved certificates and practices for all to see.  “root program” operators will probably want to be inclusive, provided that from their perspective the issuers they let in are seen as trustworthy enough for forseen uses.  

VM Certs as proposed will require CT.  One implication being that every certificate issued will be visible to anyone who wants to look.  Aside from enabling pre-attack detection of an attempt to prepare a look-alike or exact copy of an audience-recognizable logo for an impersonation attack, CT logging will also assist with monitoring CA vetting quality (and errors) over time.  

CAs wishing to promote acceptance of their intermediates with various root programs could in theory try to buy acceptance.  I would be surprised if any of the larger (and transparency-leaning) “root program” operators would accept cash like this, and it would be unfortunate if they did.  There’s nothing currently in the specifications aimed at preventing issuers from trying it.  Ideas welcome!  

One thought: require the public auditors to audit the financials of the CA during WebTrust audits, explicitly prohibit payments, in-kind or otherwise.  

> actually matters is whether or not the cheque cleared

It’s a good question and observation.  We anticipate a competitive market for VM Cert issuance.  There is some real work that CAs will have to undertake, and they will carry liability and risk for not performing the needed actions correctly and accurately.  It is true also that Applicants (those seeking a certificate) will have some costs, including costs associated with creating, obtaining and demonstrating the rights they believe they have to a logo/mark.  By example, registering a trademark is not free in most places, nor a sure thing for any given proposed mark.  

Overal though, Consuming Entities are likely to lean towards creating a more inclusive ecosystem, with costs as low as can be while still providing sufficient safety from their perspective.  If logos are not available at scale and inclusive of the "long tail", “root operators” and the larger set of Consuming Entities could skip all this and use a private database of domains and logos they maintain themselves or source from a private provider, with say a few thousand hand-audited logos.  A key idea here is to get away from that model. 

> face-to-face never works well in the dark

Hahaha, indeed!  

Here’s language specific to f2f: 

"6.1.1 Face-to-Face Validation of Applicant Representative 
The MVA must conduct face-to- face validation of the Applicant Representative for all types of Applicant (for the sake of clarity, for Private Organizations, Business Entities, Government Entities, and Non-Commercial Entities) and must use one of the methods specified in EVGL Sec. 11.2.2 (4) (A). If any form of Third Party Validator is to be used, the Third Party Validator must have a current and active license or charter and must be chosen or designated by the MVA. The MVA must maintain a record of such validation. Further, the MVA duties in sections 11.2.2 (4) B and 11.2.2 (4) C of the EVGLs must be performed.

6.1.2 Exceptions to Face-to-Face Validation of 6.1.1
The face-to-face validation in Section 6.1.1 are not required if the MVA has already completed EV validation for the Organization and issued an EV certificate to the Organization more than 90 days before the Verified Mark Certificate request, and the request was made by the same Organization Applicant Representative or a new Organization representative that the Organization specifically authorizes. This exception is allowed up through and including 2019-12-31, after which it is no longer allowed.

In addition, face-to-face validation is not required more than once for any Organization (or Parent, Subsidiary, or Affiliate) so long as the MVA has maintained continuous contact with Organization representatives and maintains a system for authorization of new Organization representatives (or representatives of a Parent, Subsidiary, or Affiliate) by the Organization and its previously authorized representatives.  "

Thede

> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
> 
> iQA/AwUBXGGirDu8z1Kouez7EQJoQQCgq+wmpP2M+wmQMfhV8O/Jucot2DIAoNcQ
> 8xtHxqGIAs0/eEcVNt+68BNc
> =uTcI
> -----END PGP SIGNATURE-----
> 
> -- 
> bimi mailing list
> [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Feb 2019 13:14:50 -0800

On 2/11/2019 7:57 AM, Tim Hollebeek wrote:
> DigiCert is willing to offer these certificates, and is also willing to 
> run a Certificate Transparency log for the ecosystem.
> 
> -Tim
> 
>        Are there
> Guidelines, and they are willing to do this logo attestation.  We also 
> are talking with other CAs, and believe that at least one other is willing.

Different question:

      What is the basis for thinking that this will work?  At scale?

Certs have been around for a very long time and were even originally 
intended to do this sort of thing.

More than   t h r e e   d e c a d e s   on -- certs date back to the 
1980s -- I believe there is no existence proof at scale.

So my query is for serious detail that permits substantive evaluation. 
Since this issue was raised when the Bimi effort started -- somewhere in 
2017, if memory serves -- and since this issue is critical to the 
operation of Bimi, there should be thoughtful material available.

d/

---

From: Richard Clayton <[email-masked]>
Date: Mon, 11 Feb 2019 21:34:00 +0000

In message <[email-masked]>, Dave
Crocker <[email-masked]> writes

>1980s -- I believe there is no existence proof at scale.

As to things being around a long time, if the recipients of the email
are going to make up their own mind whether or not a sender is trusted
enough that their logo should be displayed (which appears to be the only
viable model here) then BIMI could use X-Face which has been, at least
in the past, widely deployed.

If the emails carried the logo embedded within themselves then much of
the BIMI cruft disappears and perfectly standard certs can be used.

Here's someone who's thought about this for longer than I have: 

https://hackernoon.com/a-proposal-for-an-email-avatar-header-
38a2879d8219

>operation of Bimi, there should be thoughtful material available.

I'm particularly disappointed that BIMI isn't planning to use the
facility to embed audio into certificates ... that would be much more
cool than a few pretty pictures.

- -- 
richard                                                   Richard Clayton

---

From: Thede Loder <[email-masked]>
Date: Wed, 13 Feb 2019 11:13:50 -0500

Comments below. 

> On Feb 11, 2019, at 10:29, Dave Crocker <[email-masked]> wrote:
> 
> Folks,
> 
> BIMI sits at the crossroads of challenging security and usability (human factors) issues.  It is far too easy to take the collection of submitted drafts and focus on their many details, without first establishing the basic functional goals and issues, design goals and issues, and operational goals and issues.
> 
... 
> 
> I strongly suggest collecting and developing such language into a separate, coherent concepts and facilities draft, so that discussion can focus on the BIMI forest, before inspecting its trees.

Agree.   A draft of this is being prepared, and will be posted to the IETF list soon. 

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 13 Feb 2019 08:29:44 -0800

> Agree.   A draft of this is being prepared, and will be posted to the IETF list soon.

Thede,

That's good news.

I suggest that discussion of the detailed specification wait until after 
there is some convergence on this framework/concepts/architecture/etc. 
document.

d/

---

From: Thede Loder <[email-masked]>
Date: Wed, 13 Feb 2019 11:38:53 -0500

> On Feb 11, 2019, at 16:14, Dave Crocker <[email-masked]> wrote:
> 
>> DigiCert is willing to offer these certificates, and is also willing to run a Certificate Transparency log for the ecosystem.
>> -Tim
>>       Are there

Some reasons in favor of scale: 

* Unlike 30 years ago, there are now 50+ Certificate Authorities spanning the globe and serving a mix of market consituents, large and small.  Supporting VMCs are operationaly incremental.  

* TLS certificates are well known to individuals and organizations large and small.  They didn't even exist 30 years ago.  

* 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) 

* DNS scales (or we have bigger problems) 

* Internet users want it - clear demand 

* there is no "rocket science" involved; the formats, process and supporting technology are straightforward extentions  and analogous to what is already in practice today 

* authentication schemes necessary for safe use a primary anticipated application having 2 billion users is already widely supported 

* 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 

* See also Verfied Mark Certificate Guidelines, as previously posted to the list (for convenience, again here: https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit) 

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.  

To your later point of the need for an overview - could not agree more.  Among other things, if we want to get this to scale quickly while also being done 'right', we'll need additional experienced and skilled minds to be involved.  Overviews remove barriers to participation and boostrap that.  

Thede

> 
> Certs have been around for a very long time and were even originally intended to do this sort of thing.
> 
> More than   t h r e e   d e c a d e s   on -- certs date back to the 1980s -- I believe there is no existence proof at scale.
> 
> So my query is for serious detail that permits substantive evaluation. Since this issue was raised when the Bimi effort started -- somewhere in 2017, if memory serves -- and since this issue is critical to the operation of Bimi, there should be thoughtful material available.
> 
> d/
> 
> 
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 13 Feb 2019 10:22:19 -0800

Thede,

On 2/13/2019 8:38 AM, Thede Loder wrote:
>> On Feb 11, 2019, at 16:14, Dave Crocker <[email-masked] 

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.

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

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

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

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

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.

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

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

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

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

> * authentication schemes necessary for safe use 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.  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.

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

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?

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

d/

(*) 
https://docs.google.com/document/d/1OzL9FqexZpZJQuoqAK2E3sXjOwEcLNCvXW7e88Olt2I/edit#heading=h.h31mzi4ac5st

---

From: Richard Clayton <[email-masked]>
Date: Wed, 13 Feb 2019 19:51:56 +0000

In message <[email-masked]>, Dave
Crocker <[email-masked]> writes

>> * Unlike 30 years ago, there are now 50+ Certificate Authorities 

Firefox currently lists 62, with 151 root certificates that are trusted

your browser may vary

>security community seem to view them as obvious and massive.)

.. besides misbehaviour and there is also a significant problem with the
interchangeability of CA's. There are now various protocol extensions to
try and mitigate the issues this causes, but all BIMI seems to envisage
is the use of Certificate Transparency to detect unexpected certificates
after the fact...

... if a CA missues a certificate containing a defamatory (or indecent)
logo then catching this once it has been displayed to significant
numbers of people may not be much comfort.

should the documents explain why some variant of certificate pinning is
not being envisaged ? If only in the security considerations section.

>This being a technical forum, I hope we can avoid marketing language. 

I think the statement is meant to imply "at varying prices" which is
certainly the case ... you can pay $$$$ $$$ $$ or $ for a certificate
(or get one for free) and they are -- from the practical point of view
in securing things -- absolutely identical

It is believed that the reason people pay $$$$ is because they are
effectively purchasing a certificate management system rather than just
a single cert.

Security Economics in the HTTPS Value Chain. Asghari, H., Van Eeten,
M.J.G., Arnbak, A., & Van Eijk, N. (2013). WEIS 2013.

>popular use of self-signed certs even that benefit has some important 

browser changes over the past few years have made self-signed
certificates for HTTPS rather less attractive -- and the majority have
moved to LetsEncrypt. I don't have figures for that but it is certainly
a strong impression

this change (and the far wider prevalence of HTTPS) has brought into
sharper relief the fact that certificates underpin privacy they do not
especially underpin authentication  (relevant meme: "It wasn't called
LetsAuthenticate for a reason")

>That claim keeps being made but I've never seen any serious 

Marketing people want it -- that may not be documented but I have
sufficient anecdotes to hand to believe it be the main driver here.

>that was done when the BIMI effort started a couple of years ago.

yes please ... there exists research to show there are no security
benefits, so presumably the benefit is some sort of increase in
happiness in seeing logos; or perhaps the benefit is in rapid selection
of which mail to discard and which to open ? If you recognise the logo
then delete it ??

>I'll guess you mean SPF, DKIM and DMARC.  

You could probably argue that the number of "users" of SPF, DKIM and
DMARC was under 10,000 -- statistics like the number of mailboxes
involved are skewed by less than 10 large companies, and the number of
domains involved are skewed by (a) spammers and (b) some large DNS
providers.

>> jurisdictions can be expressed as ISO country codes unambiguously

the numbers here are actually one of the problems ... what estimates
have been made as to how many unique logos (when viewed on a mobile
phone screen from 30cm away) can actually be distinguished by an average
user ? 

also, most people are rubbish at remembering what logos look like

        https://www.signs.com/branded-in-memory/

- -- 
richard                                                   Richard Clayton

---

From: Thede Loder <[email-masked]>
Date: Wed, 13 Feb 2019 16:35:02 -0500

Hi Richard, 

> in the past, widely deployed.

Generally I imagine MUA maintainers will decide upon the basis of their VM Cert-specific root programs whether or not they trust the sender (and issuing CA) enough to display the logo.  However, I don't see why the MUA maintainer could not also allow end users to override the platform choice, e.g. faciliate a user-maintained domain whitelist, or a community/crowd-sourced list of domains and their certs.  More sophisticated users can evaluate the certificates themselves, too.  "Many eyes makes for shallower bugs. "

Thanks for the reference to X-Face, I'll check it out.   

> https://hackernoon.com/a-proposal-for-an-email-avatar-header-

Interesting, and there's an obvious benefit to including the header within the DKIM signature and requiring it to pass.  It's incomplete though as described - its still missing something rather important: third-party verification of rights, and the association of the registrant with the image mark (or face)  

Example: attacker registers "bankalike.co.uk", sends messages with X-Face, signs with DKIM, includes the field.  The email UI faithfully displays the attacker-chosen logo.  

The roll of VM Certs is to address the problem of domain registrants who properly authenticate and yet want to impersontate the non-DNS identity of others.  

> cool than a few pretty pictures.

Funny that you say this.  A great idea, and there's no reason why it cannot be done.  

There are registered trademarks that are audio (see https://en.wikipedia.org/wiki/Sound_trademark) 

Cooler still, audio is supported already - see RFC3709 Section 3.  

Thede

---

From: Thede Loder <[email-masked]>
Date: Thu, 14 Feb 2019 13:57:25 -0500

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 <[email-masked]> wrote:
> 
> Thede,
> 
>>> On Feb 11, 2019, at 16:14, Dave Crocker <[email-masked]     What is the basis for thinking that this will work?  At 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...
> 
> 
> 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)?  

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

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

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

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

> That claim keeps being made but I've never seen any serious documentation for it.
> 

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

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

---

From: "John R Levine" <[email-masked]>
Date: 14 Feb 2019 14:31:10 -0500

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

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.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Thu, 14 Feb 2019 12:47:06 -0800

On 2/14/2019 10:57 AM, Thede Loder wrote:
>> 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'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.

> merits?

I encourage you to explore such questions in depth.

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.

> I personally believe an important factor for BIMI (now) is "readiness
> of the market", broadly "market conditions", the technology

Where is the data to support a claim that the /recipient/ market is 
ready (and even eager) for this capability?

As for the examples you supplied, I do not see how they are relevant to 
the concerns that have been expressed.

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

In other words, you are planning to create an entirely new and 
independent CA service.

Oh boy.  No risks there.

I'm also curious about the expense of such an independent service for 
this narrow use.

>     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

This is like saying that starting Tesla was operationally incremental 
because there was already quite a lot of experience elsewhere in making 
cars.

What you are requiring is creation of an entirely new infrastructure 
service.  That's not incremental.  In fact we have regularly seen such a 
requirement stop an effort cold, or cause it to fail to scale.  That's 
why we so often see existing infrastructure get expanded beyond it's 
original scope.

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

So the premise is that because they were able to get a cert for a domain 
name it's not much different to get one for a mark?  Really?

>>> * TLS certificates are well known to individuals and
>>> organizations large and small.  They didn't even exist 30 years
>>> ago.
>> 
> 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.

cf, my reference to international trademarks.  This is a significantly 
different use of certs than has been done before at scale.  (cf, John 
L's observation that the failures have been admin and ops, not technical.)

> The bypassing of the CA system, while I agree is troublesome in some
> contexts, seems like evidence of good protocol design

It has been nothing of the sort, since it both broke the technical 
operation and taught people ignore warnings.

> Overall, VM Certs are significantly different from TLS certificates.

We agree.

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

Interesting redundancy in the references, since it really divides into: 
  people who want to make money (or other form of benefit) from 
recipients (directly or indirectly) vs. recipients.  Everyone on your 
list is in the first category.

In abstract discussions, yes it is reasonable to refer to the variety of 
folk falling into the first category as 'users'.

In terms of the current discussion, it's not, and to use the term 
'users' in this context to mean anyone other than recipients frankly is 
likely deceptive.  These are not 'users'.  They are vendors, operators, 
senders, and the like.  They are not typically called 'users'.

So the question remains:

      Where is the basis for claiming that /recipients/ want this?

And the related question remains:

      Where is the empirical basis for claiming that this will be useful 
for recipients?

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

This line of comment asserts efficacy by demanding proof of 
non-efficacy.  Please consider not trying to use this.

If there is a foundation for claiming efficacy, beyond some highly 
abstract and detached reference, then please show it.

> I don't think at this point it is reasonable to require direct
> evidence of end users wanting BIMI,

I agree, which is why there should not be a claim that users want this.

> However, end-user do already use email MUAs which display logos
> representing sender identity.

That tries to use existence and tolerance by 'some' users as 
substantiation of 'want', which it isn't, nevermind 'at scale' which it 
also isn't.

   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

I'm sure you'll agree that our personal lack of surprise about a 
possible outcome does not constitute substantiation of that outcome...

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

This seems to impose a requirement for high levels of recipient 
complaints as proof of not wanting something, which suggests a rather 
narrow model for end user behavior.  People tolerate all sorts of things 
they don't like but don't complain about.

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

Excellent.  So that means they have data showing that there is actual 
recipient /desire/ for this feature, doesn't it, and even some basis for 
claiming recipient 'benefit'?  Can't wait to see the data.

cf, the early BIMI effort to review existing research on this topic.

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

There are a number of foundational indications that neither of these is 
true.

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

This characterization is sufficiently general and vague that I don't see 
how anyone can apply it for evaluating the current effort.

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

wrt the list that followed:  ditto.

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

Since spf/dkim/dmarc have essentially nothing to do with such 
verification, you are referring to an entirely new, and significantly 
challenging, area of work, as was noted when the Bimi work was started.

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

You are claiming some improved recipient behaviors, contrary to research 
that indicates it won't happen and field experience that shows it 
doesn't happen.

> Without going into too much detail, humans can read letters and
> words.  They can also associate meaning with images. 

I am impressed that you would think it helpful to offer the above 
sentences as relevant to the set of concerns here.

>  Identity is kind of important, so why not bring both
> forms to bear?

I'm even more impressed you'd offer this.

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

Except that all this was covered more than once when the Bimi effort was 
started and perhaps I'm missing it but I see no indication that any of 
that history has been heeded or even heard.

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

What put rockets on the moon was careful engineering.  Alignment and 
will, without that careful engineering, killed people.

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

You ask that as if I hadn't already attempted it for the initial Bimi 
effort.

Here's the catch:  As has been pointed out since the effort started, 
Bimi touches a number of legal and security topics that are well-known 
to be extremely challenging and yet the effort appears to have performed 
none of the relevant due diligence to deal with those topics 
meaningfully, nor have we yet seen any design solutions to those concerns.

The burden for that effort is on the advocates.

d/

---

From: Thede Loder <[email-masked]>
Date: Fri, 15 Feb 2019 00:22:36 -0500

Hi Richard, 
Thank you for your thoughful response.  I have responded in a few 
places below, and also ask you some questions.  

> On Feb 13, 2019, at 14:51, Richard Clayton <[email-masked]> wrote:
> 
> ... besides misbehaviour and there is also a significant problem with the
> try and mitigate the issues this causes,

Can you provide a few references that could serve as an introduction 
to the interchangeability problem?  And the extensions?  I'd like to 
understand how the issues might carry over to our current design + 
strategies for VM Certs.  Hopefully the same issues will not apply, 
but if they do, perhaps they can be mitigated.  

> but all BIMI seems to envisage
> .... if a CA missues a certificate containing a defamatory (or indecent)

Agree that such a thing would be unfortunate.  

It's not mentioned in the VM Cert Guidelines, as its content is mainly focused  
on describing the vetting and requirements beyond Extended Validation and 
the Certificate Profile contents, but there is a straightforward strategy here to 
address the concern and situation you highlight.  

Receivers ("Consuming Entities" more broadly) can and should prohibit (not 
bother?) to display logos made available and extracted from newly issued VM 
Certificates.  A best practice is to allow sufficient time to pass (e.g. several 
weeks) so that abuse attempts can be caught.  (It may be possible to reduce
this 'wait period' over time, as review technologies, risk-assisted review 
prioritization, and automation can be brought to bear.)  

So unless a significant number of people are monitoring the CT logs directly 
themselves, under normal circumstances those outside the security sphere
would not see such a logo.  Meanwhile, if significant numbers of people were 
in fact monitoring newly issued certs in the CT logs, that would be fantastic!  :-)

Second point.  There are several advantages and benfits to mandatory CT 
logging besides the 'catch while in review' period enabled by transparency.  
Offhand, CT implies a history of data to assess CA quality over time (as a basis of 
CA reputation), and the CT logs are a direct source of certificates independent 
of DNS (helpful, though not a necessary means to aid in thwarting tracking 
web-bugs-style via DNS) 

With regard to what you wrote above, 'all BIMI seems to envisage...' -- are
you implying that you are aware of more that can be done - e.g. other 
advantages or mitigations possible through CT logging?  If so, I would love 
to know of additional strategies than can improve safety, reduced abuse, etc., 
please share! 

> not being envisaged ? If only in the security considerations section.

Thanks for mentioning, good point.  Yes, we should include a discussion of 
the relevance or application of pinning.  That reminds me -- we should also 
add assessment of CAA.  Do you have a view here?  

I do think some MUAs would benefit from pinning, particularly for IMAPS access. 
IMAP itself could use an extension to signal to aware updated clients that 
it is ok to honor/trust/load a BIMI-Location header's image URL.  

The evaluation of VM Certificates and the root and intermediate with which they 
are signed, along with the extraction and distribution of the embedded logo if 
trusted, are generally activities envisioned as taking place on a receiver's 
systems.  There may be less risk of a trust-store compromise in those 
environments, vs. on a non-security aware end-user's PC.  

> in securing things -- absolutely identical

Yes, thank you, I did mean to imply at varying prices.  

> sufficient anecdotes to hand to believe it be the main driver here.

Generally speaking, marketing people do want it.  An early trial of some 
parts of BIMI was able to recruit both big and small brands, despite some 
substantial effort required on their part.   They are often promoters of a 
brand's brand.  However, if it were just marketers expressing interest, 
I personally would be worried it will be less likely to get anywhere.  

> of which mail to discard and which to open ? If you recognise the logo

I'm not sure we can say conclusively what the research says, as there are 
plenty of limitations, at least with the studies I am aware of.  

I do think the research indicated measured effects on end user choices in the 
Seznam study were small, and consequently any security benefits made 
possible through end-user mediated choices (with their study design) would 
be necessarily small.   

But such a conclusion is a very different thing than making the conclusion 
that the security benefits of BIMI's broad adoption will be small.  There are 
a great many more factors at play.  

A relevant analogy here is the difference in the importance of end-user 
mediated outcomes with two different safety devices commonplace in 
automobiles: seatbelts vs airbags.  Seatbelts require user-action, user 
training, and have various user-influenced failure modes (failing to put 
them on, or putting them on improperly which can do more harm than 
good).  Training and practice can help (implying costs, but worth it with 
people's lives at stake).  Training for reading email headers or 
differentiating logos/non logos, maybe less so.  

Airbags, by comparision, do not require changes in end-user choices to 
improve outcomes.  They are part of the infrastructure of the car, safer 
by design.   BIMI is airbags.  

BIMI's primary mechanism of improved safety is through driving adoption of actor 
authentication (sender authentication in the context of email), making impersonation 
attacks through existing applications harder, and motivating higher levels of 
real-world / online identity transparency.  

As to increase happiness and rapid selection, you nailed it.  That too!  

> domains involved are skewed by (a) spammers and (b) some large DNS

True.  So by some definitions of scalable, SPF, DKIM, and DMARC are small.  
But in terms of impact, there's been at least a little bit of impact for nearly every 
Internet email user (Facebook alone has 2.3 B monthly actives, and they send with 
DMARC) 

I have clear biases, but to me DMARC adoption, limited though it is at this point, 
exmplifies how a technology does have to be directly adopted by every end user 
of the Internet (on their own device) to provide a beneficial impact and to have 
been worth while to create.  

> phone screen from 30cm away) can actually be distinguished by an average

It's a good question.  But if we are really worried about it, we should probably 
consider rolling back DNS.  Because lloyds.co <http://lloyds.co/>.uk, l1oyds.co.uk <http://l1oyds.co.uk/>, and lloydds.co.uk <http://lloydds.co.uk/> 
all look somewhat alike when viewed on a phone screen too.  :-) 

Joking aside, there are well know 'collisions' in the "design mark" trademark space - 
look no further than Paypal and Pandora.  

There may be a difference here that works in BIMI's and VM Certificate's 
favor.  With trademarks, there's a well-defined legal process (and system for 
supporting it, the legal system) for evaluating the relative propensity and level 
of risk associated with confusing marks.  

I'm not sure if there's an analogous process for DNS names.  If I register an "off-by-one" 
character look-alike domain name, can a well known brand do anything about it at all, 
other than try to buy it from me?  

>        https://www.signs.com/branded-in-memory/ <https://www.signs.com/branded-in-memory/>

Thank you, great resource!  And a facinating set of studies.  I'll write something more 
after I've had a chance to sleep and give it a think.  

Thede

> iQA/AwUBXGR1Wzu8z1Kouez7EQJg3gCfXjhWf+O2uXq0yIdeJ3s+jChYn8sAmwb3
> wer3de7TQB3odl4wYGxiUrb2
> =agVd