From nobody Wed Feb 6 12:11:06 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0540130ED7 for ; Wed, 6 Feb 2019 12:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P99hcJqBcjkl for ; Wed, 6 Feb 2019 12:11:02 -0800 (PST) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD937127AC2 for ; Wed, 6 Feb 2019 12:10:58 -0800 (PST) Received: by mail-ot1-x342.google.com with SMTP id v23so14184793otk.9 for ; Wed, 06 Feb 2019 12:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rnJYwj2yuih8nXXWj5cfeIFieMKRswIy/wq7KLQa+uE=; b=K/3hibJkUfoT/ugjBMz4ZmuZ+1LdlgjbrYprr5xN7FOpu983ic4P9sy2qIGlHgZBU2 gBK9ISUKDnz5tJytq1A81WnBV6CtrAi3EKYPKp+QQP+REaflfhWMKdASafNJiIkDuaQD buDZLyO2dgksCEHkZdQEFwlTa5UHnBScvEbdygowTEihA81Z2fT20o1dt5hAxnLpwDHL I/8dGObk43CM8zbKdcpCMVybT8Ghh0BMpYMTlbcMYEBY4jd0njtbQgYvtvLyXTIiEc2x 0wjcMKdCwcaYlG/t0hEkQhlljfxNqn7w3w5WOV4YaZnK6b+0I+caG8Nl/3xM+7etOl0R B+DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rnJYwj2yuih8nXXWj5cfeIFieMKRswIy/wq7KLQa+uE=; b=rxagTJbJJOu4TWE4yx/+msYtcpyz1kWuoGdwqg9F2bs36mehpz8VNxrKsiTJyjY4zd jHbI2rdTrkGiq2hU9uO06TAN+pexhFYELOSr5oKHUD4rG5vOKt3nZ/4oZ/FXMf+TiWax kKx2IEXDza/PQ15geCTZ0vcZ1i/1aT+Psik7J1dSm/LdNlgYpEwor3qa7oS7lhb60coQ msq7nvDDtH+91d9O+zx2EodIzPF7RLWeD4r43zs452UFRvkmFi2BV8TUvg6poDiCDuQ4 iw6jH/9e9p4iamHL4SxQ4fChETD2/cHZKR9LJvpu0sc2/rR26fyTvE7AtB4RbPujJ3F/ pRdg== X-Gm-Message-State: AHQUAuacQx31g9Zuzulcle1OpYPPzd7zdf2gDQdmktThXHSIC5/HmDY0 dkim3ao+TuvaKk9ZK6oCnGMVd/ky+R9YF99m9oJaDIHaYjbo2g== X-Google-Smtp-Source: AHgI3IaLiyQ7JOE+tifh13woml+LPKSKwPOO5JA7IaxP8/KqcVZiAISzon1PfC7YA6FlHEtlS/ieB9ksSpjSrmhR5Pg= X-Received: by 2002:a9d:d83:: with SMTP id 3mr6213859ots.361.1549483857492; Wed, 06 Feb 2019 12:10:57 -0800 (PST) MIME-Version: 1.0 From: Seth Blank Date: Wed, 6 Feb 2019 12:10:35 -0800 Message-ID: To: bimi@ietf.org Content-Type: multipart/alternative; boundary="000000000000e95cec05813f52a2" Archived-At: Subject: [Bimi] New Version Notification for draft-blank-ietf-bimi-00.txt X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 20:11:05 -0000 --000000000000e95cec05813f52a2 Content-Type: text/plain; charset="UTF-8" I've uploaded two documents as I-Ds to kick off IETF discussions around BIMI. Both these documents need a good deal of work, but are ready for public discussion. For BIMI publishing and usage: - https://tools.ietf.org/html/draft-blank-ietf-bimi-00 - https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-00 For logo validation: - https://tools.ietf.org/html/draft-chuang-bimi-certificate-00 - https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing At a high level, these documents have several issues to be worked through: 1) The intent is for this to be globally accessible to any domain owner, but the current mechanisms are more approachable to larger organizations in first world countries a) We need a discussion of what other validation mechanisms could work at scale (our expectation is to have several, signposted weakly in the draft) b) We need a way to properly reflect this in the proposed a= tag 2) BIMI is NOT a new authentication mechanism, nor does it make ANY claims about user security or trust in the inbox. However, in places this draft may be unclear. How do we make this clearer while still explaining why standardizing this process is important, without crossing the line into UX or trust, of which BIMI is neither? 3) Right now, security surrounding logos is limited to SVGs per https://tools.ietf.org/html/rfc6170#section-5.2. There's clearly more that's needed here, especially against attacks that rely on steganography or resizing vectors, etc. 4) Other nits for draft-blank-ietf-bimi: a) The structure needs work, as do the Introduction and Overview b) Some of the technical construction feels like it could be dramatically simplified c) Section 8.2 mentions hashes with no definition or clarity d) The uses of MTA, MUA, and Mail Receiver feel like they overlap each other left and right i) And the document is heavily focused on larger receivers where this distinction is clear, but doesn't give any thought to other receiving architectures at all, especially mail clients that are the entire stack Several authors of these documents will be in Prague, we're looking forward to the conversations over the next few weeks and face to face! Seth ---------- Forwarded message --------- From: Date: Wed, Feb 6, 2019 at 11:11 AM Subject: New Version Notification for draft-blank-ietf-bimi-00.txt A new version of I-D, draft-blank-ietf-bimi-00.txt has been successfully submitted by Seth Blank and posted to the IETF repository. Name: draft-blank-ietf-bimi Revision: 00 Title: Brand Indicators for Message Identification (BIMI) Document date: 2019-02-06 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt Status: https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/ Htmlized: https://tools.ietf.org/html/draft-blank-ietf-bimi-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi Abstract: 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. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the indicator. This document specifies how Domain Owners communicate their desired indicators through the BIMI assertion record in DNS and how that record is to be handled by MTAs and MUAs. The domain verification mechanism and extensions for other mail protocols (IMAP, etc.) are specified in separate documents. MUAs and mail-receiving organizations are free to define their own policies for indicator display that makes use or not of BIMI data as they see fit. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000e95cec05813f52a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've uploaded two documents as I-Ds to = kick off IETF discussions around BIMI. Both these documents need a good dea= l of work, but are ready for public discussion.

For BIMI publishing = and usage:
- https://tools.ietf.org/html/draft-blank-ietf-bimi-00
- https:= //tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-00

For lo= go validation:
- https://tools.ietf.org/html/draft-chuang-bimi-certificate= -00
- https://docs.google.com/do= cument/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=3Dsharing

At a high level, these documents have several issues to be worked = through:

1) The intent is for this to be globally accessible to any = domain owner, but the current mechanisms are more approachable to larger or= ganizations in first world countries
=C2=A0 =C2=A0a) We need a discussio= n of what other validation mechanisms could work at scale (our expectation = is to have several, signposted weakly in the draft)
=C2=A0 =C2=A0b) We n= eed a way to properly reflect this in the proposed a=3D tag

2) BIMI = is NOT a new authentication mechanism, nor does it make ANY claims about us= er security or trust in the inbox. However, in places this draft may be unc= lear. How do we make this clearer while still explaining why standardizing = this process is important, without crossing the line into UX or trust, of w= hich BIMI is neither?

3) Right now, security surrounding logos is li= mited to SVGs per https://tools.ietf.org/html/rfc6170#section-5.2. There's clearly= more that's needed here, especially against attacks that rely on stega= nography or resizing vectors, etc.

4) Other nits for draft-blank-iet= f-bimi:

=C2=A0 =C2=A0a) The structure needs work, as do the Introduc= tion and Overview
=C2=A0 =C2=A0b) Some of the technical construction fee= ls like it could be dramatically simplified
=C2=A0 =C2=A0c) Section 8.2 = mentions hashes with no definition or clarity
=C2=A0 =C2=A0d) The uses o= f MTA, MUA, and Mail Receiver feel like they overlap each other left and ri= ght
=C2=A0 =C2=A0 =C2=A0 =C2=A0i) And the document is heavily focused on= larger receivers where this distinction is clear, but doesn't give any= thought to other receiving architectures at all, especially mail clients t= hat are the entire stack

Several authors of these = documents will be in Prague, we're looking forward to the conversations= over the next few weeks and face to face!

Seth

---------- Forwarded message ---------
From:=C2=A0&l= t;internet-drafts@ietf.org&= gt;
Date: Wed, Feb 6, 2019 at 11:11 AM
Subject: New Version No= tification for draft-blank-ietf-bimi-00.txt


A new version = of I-D, draft-blank-ietf-bimi-00.txt
has been successfully submitted by = Seth Blank and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-blank-ietf-bimi
Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Brand Indicator= s for Message Identification (BIMI)
Document date:=C2=A0 2019-02-06
G= roup:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 26
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0https://www.ietf.or= g/internet-drafts/draft-blank-ietf-bimi-00.txt
Status:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.= org/doc/draft-blank-ietf-bimi/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0<= a href=3D"https://tools.ietf.org/html/draft-blank-ietf-bimi-00" rel=3D"nore= ferrer" target=3D"_blank">https://tools.ietf.org/html/draft-blank-ietf-bimi= -00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi

Abstract:
=C2=A0 =C2=A0Brand Indicators for Message Identification= (BIMI) permits Domain
=C2=A0 =C2=A0Owners to coordinate with Mail User = Agents (MUAs) to display brand-
=C2=A0 =C2=A0specific Indicators next to= properly authenticated messages.=C2=A0 There
=C2=A0 =C2=A0are two aspec= ts of BIMI coordination: a scalable mechanism for Domain
=C2=A0 =C2=A0Ow= ners to publish their desired indicators, and a mechanism for Mail
=C2= =A0 =C2=A0Transfer Agents (MTAs) to verify the authenticity of the indicato= r.
=C2=A0 =C2=A0This document specifies how Domain Owners communicate th= eir desired
=C2=A0 =C2=A0indicators through the BIMI assertion record in= DNS and how that
=C2=A0 =C2=A0record is to be handled by MTAs and MUAs.= =C2=A0 The domain verification
=C2=A0 =C2=A0mechanism and extensions for= other mail protocols (IMAP, etc.) are
=C2=A0 =C2=A0specified in separat= e documents.=C2=A0 MUAs and mail-receiving
=C2=A0 =C2=A0organizations ar= e free to define their own policies for indicator
=C2=A0 =C2=A0display t= hat makes use or not of BIMI data as they see fit.




Pleas= e note that it may take a couple of minutes from the time of submission
= until the htmlized version and diff are available at=C2=A0tools.ietf.org.<= br>
The IETF Secretariat

--000000000000e95cec05813f52a2-- From nobody Thu Feb 7 12:48:47 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17750130E6C for ; Thu, 7 Feb 2019 12:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH-ndZmKuVR2 for ; Thu, 7 Feb 2019 12:48:42 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847F0130E6F for ; Thu, 7 Feb 2019 12:48:42 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id n12so494193ywn.13 for ; Thu, 07 Feb 2019 12:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=uS3OoT9fVd/HiRsg/2XBO5tsGtQyUA68YwIKlf0qVv4=; b=Odbuma6QFFoZjMKYXKs06G/rmb943A5uR64/1d3v4SBijnss8cLJF+/x+H4zENIJM0 YZSlOVxd0Xu4tL27Aahn2Vshpd651iO0x3QgUs3BOxu4luij00fWfSqMALCwNnLKzE0l LOMFfd5WLwjcdCnJoYDpWALPqISId/UNhNch0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=uS3OoT9fVd/HiRsg/2XBO5tsGtQyUA68YwIKlf0qVv4=; b=LACAIoij3wA7hRwfcR/LtlJ1NR5J3nFTC7ZdBcjkQ7iMO3PPBTJHYsvmmVY7U600vz dlk8wCej7/FvM/R/YjuK8bWsUakZC4UUUBn1SIIphcv3lKWGjWFlO3KxTsNKUNH/NCM7 bPM95xQA1zBLVQ0FatRDFZUGVsuKn+Ryj/XUg2qPQMStGKQYysMQfoVzine/ohj+nmsf h4oaxffnhA9e4Xu52826Rc97itmXjmvbE8Ej7Z5oNlmMLHFDcRMdp+FfbLOv8fNHMk/G IQTFgcZ+FoJluk+cvL1ECBNDtZkldMji0QGYMd3vanQ8F0mPkGubDSTeBUtEIerNEBqm GCuA== X-Gm-Message-State: AHQUAuaJDFLdvPhb8h7+SK8gcMtYgcIL6VQc3QiS/5qO+L4s3EUSszoD KJQ3ocqKW0rjnF83we3xaryCHS/THCQ= X-Google-Smtp-Source: AHgI3IaWJHaNnWJeqSFrJXts01vdQjD4Fr89qWendtG+f+6Cj5ZYR3H9qcFff6/TdEY2bifD56KC7A== X-Received: by 2002:a0d:f286:: with SMTP id b128mr14953913ywf.46.1549572521103; Thu, 07 Feb 2019 12:48:41 -0800 (PST) Received: from [10.1.200.76] (cpe-174-109-126-126.nc.res.rr.com. [174.109.126.126]) by smtp.gmail.com with ESMTPSA id v9sm11185ywh.2.2019.02.07.12.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 12:48:40 -0800 (PST) From: Thede Loder Content-Type: multipart/alternative; boundary="Apple-Mail=_FA170565-2BF1-47FE-AC6E-1A5501B2449E" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Feb 2019 15:48:39 -0500 References: To: Seth Blank , bimi@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] New Version Notification for draft-blank-ietf-bimi-00.txt X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 20:48:46 -0000 --Apple-Mail=_FA170565-2BF1-47FE-AC6E-1A5501B2449E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seth, thanks for getting this rolling here! I will post comments on = specific docs under different doc-specific threads where possible and = suggest others do the same. Generally agree on the highlights - lots to = cover and improve.=20 Thede -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: 415-420-8615 > On Feb 6, 2019, at 15:10, Seth Blank wrote: >=20 > I've uploaded two documents as I-Ds to kick off IETF discussions = around BIMI. Both these documents need a good deal of work, but are = ready for public discussion. >=20 > For BIMI publishing and usage: > - https://tools.ietf.org/html/draft-blank-ietf-bimi-00 = > - https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-00 = >=20 > For logo validation: > - https://tools.ietf.org/html/draft-chuang-bimi-certificate-00 = > - = https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcb= ja42w/edit?usp=3Dsharing = >=20 > At a high level, these documents have several issues to be worked = through: >=20 > 1) The intent is for this to be globally accessible to any domain = owner, but the current mechanisms are more approachable to larger = organizations in first world countries > a) We need a discussion of what other validation mechanisms could = work at scale (our expectation is to have several, signposted weakly in = the draft) > b) We need a way to properly reflect this in the proposed a=3D tag >=20 > 2) BIMI is NOT a new authentication mechanism, nor does it make ANY = claims about user security or trust in the inbox. However, in places = this draft may be unclear. How do we make this clearer while still = explaining why standardizing this process is important, without crossing = the line into UX or trust, of which BIMI is neither? >=20 > 3) Right now, security surrounding logos is limited to SVGs per = https://tools.ietf.org/html/rfc6170#section-5.2 = . There's clearly more = that's needed here, especially against attacks that rely on = steganography or resizing vectors, etc. >=20 > 4) Other nits for draft-blank-ietf-bimi: >=20 > a) The structure needs work, as do the Introduction and Overview > b) Some of the technical construction feels like it could be = dramatically simplified > c) Section 8.2 mentions hashes with no definition or clarity > d) The uses of MTA, MUA, and Mail Receiver feel like they overlap = each other left and right > i) And the document is heavily focused on larger receivers = where this distinction is clear, but doesn't give any thought to other = receiving architectures at all, especially mail clients that are the = entire stack >=20 > Several authors of these documents will be in Prague, we're looking = forward to the conversations over the next few weeks and face to face! >=20 > Seth >=20 > ---------- Forwarded message --------- > From: > > Date: Wed, Feb 6, 2019 at 11:11 AM > Subject: New Version Notification for draft-blank-ietf-bimi-00.txt >=20 >=20 > A new version of I-D, draft-blank-ietf-bimi-00.txt > has been successfully submitted by Seth Blank and posted to the > IETF repository. >=20 > Name: draft-blank-ietf-bimi > Revision: 00 > Title: Brand Indicators for Message Identification (BIMI) > Document date: 2019-02-06 > Group: Individual Submission > Pages: 26 > URL: = https://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/ = > Htmlized: https://tools.ietf.org/html/draft-blank-ietf-bimi-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi = >=20 >=20 > Abstract: > 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. There > are two aspects of BIMI coordination: a scalable mechanism for = Domain > Owners to publish their desired indicators, and a mechanism for = Mail > Transfer Agents (MTAs) to verify the authenticity of the indicator. > This document specifies how Domain Owners communicate their desired > indicators through the BIMI assertion record in DNS and how that > record is to be handled by MTAs and MUAs. The domain verification > mechanism and extensions for other mail protocols (IMAP, etc.) are > specified in separate documents. MUAs and mail-receiving > organizations are free to define their own policies for indicator > display that makes use or not of BIMI data as they see fit. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi --Apple-Mail=_FA170565-2BF1-47FE-AC6E-1A5501B2449E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Seth, thanks for getting this rolling = here!  I will post comments on specific docs under different = doc-specific threads where possible and suggest others do the same. =  Generally agree on the highlights - lots to cover and = improve. 

Thede

--
Thede = Loder
Managing Director, Skye Logicworks LLC
M: = 415-420-8615



On Feb 6, 2019, at 15:10, Seth Blank <seth@sethblank.com> = wrote:

I've uploaded two documents as = I-Ds to kick off IETF discussions around BIMI. Both these documents need = a good deal of work, but are ready for public discussion.

For BIMI publishing and usage:
- = https://tools.ietf.org/html/draft-blank-ietf-bimi-00
- https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-00=

For logo validation:
- = https://tools.ietf.org/html/draft-chuang-bimi-certificate-00
- https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBw= MkdmluwHEcbja42w/edit?usp=3Dsharing

At = a high level, these documents have several issues to be worked = through:

1) The intent is for this to be = globally accessible to any domain owner, but the current mechanisms are = more approachable to larger organizations in first world countries
   a) We need a discussion of what other validation = mechanisms could work at scale (our expectation is to have several, = signposted weakly in the draft)
   b) We need a = way to properly reflect this in the proposed a=3D tag

2) BIMI is NOT a new authentication mechanism, nor does it = make ANY claims about user security or trust in the inbox. However, in = places this draft may be unclear. How do we make this clearer while = still explaining why standardizing this process is important, without = crossing the line into UX or trust, of which BIMI is neither?

3) Right now, security surrounding logos is = limited to SVGs per https://tools.ietf.org/html/rfc6170#section-5.2. There's = clearly more that's needed here, especially against attacks that rely on = steganography or resizing vectors, etc.

4) = Other nits for draft-blank-ietf-bimi:

  =  a) The structure needs work, as do the Introduction and = Overview
   b) Some of the technical = construction feels like it could be dramatically simplified
   c) Section 8.2 mentions hashes with no = definition or clarity
   d) The uses of MTA, = MUA, and Mail Receiver feel like they overlap each other left and = right
       i) And the document is = heavily focused on larger receivers where this distinction is clear, but = doesn't give any thought to other receiving architectures at all, = especially mail clients that are the entire stack
Several authors of these documents = will be in Prague, we're looking forward to the conversations over the = next few weeks and face to face!

Seth

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: = Wed, Feb 6, 2019 at 11:11 AM
Subject: New Version = Notification for draft-blank-ietf-bimi-00.txt


A new version of I-D, = draft-blank-ietf-bimi-00.txt
has been successfully = submitted by Seth Blank and posted to the
IETF = repository.

Name:      =      draft-blank-ietf-bimi
Revision:  =      00
Title:        =   Brand Indicators for Message Identification (BIMI)
Document date:  2019-02-06
Group:  =         Individual Submission
Pages:          26
URL:            https://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.t= xt
Status:         https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/
Htmlized:       https://tools.ietf.org/html/draft-blank-ietf-bimi-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi=


Abstract:
   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.  = There
   are two aspects of BIMI coordination: a = scalable mechanism for Domain
   Owners to = publish their desired indicators, and a mechanism for Mail
   Transfer Agents (MTAs) to verify the = authenticity of the indicator.
   This document = specifies how Domain Owners communicate their desired
 =  indicators through the BIMI assertion record in DNS and how = that
   record is to be handled by MTAs and = MUAs.  The domain verification
   mechanism = and extensions for other mail protocols (IMAP, etc.) are
   specified in separate documents.  MUAs and = mail-receiving
   organizations are free to = define their own policies for indicator
  =  display that makes use or not of BIMI data as they see fit.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi

= --Apple-Mail=_FA170565-2BF1-47FE-AC6E-1A5501B2449E-- From nobody Thu Feb 7 13:39:18 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB80129A87 for ; Thu, 7 Feb 2019 13:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqb4ZtRaefqe for ; Thu, 7 Feb 2019 13:39:14 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFD8127AC2 for ; Thu, 7 Feb 2019 13:39:13 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id o81so581465yba.8 for ; Thu, 07 Feb 2019 13:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=sxOtwbHywZX0Wu1rwWWGZL7LxR1Ouysk+/0x642jxF0=; b=i6iO1x2LD3lNH8Xqlx015Jl/k605mEKAngXsIwsm7fex+Ziz/KUKNak6L42PsfK4WF RsHlyMBwfS3LnX5fusm2EDTssChlhlz6dwatLZACLhPA24ZWgIS2b99bV2AUPj+PvUbj wGY/fwQ8DJLGkXr5phSBGBfRywrTxoumnyPtQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=sxOtwbHywZX0Wu1rwWWGZL7LxR1Ouysk+/0x642jxF0=; b=N3oxbrKZW9rXAcFDKjP4N55J5cEeMwSnDLYQG43qF4Ujw2lz2rqYK5eQvHQCoWfFk5 NuhKrZQVzuOCcg0EuAlHbIIAm0TuGqzO3b69508PMzSAfNE9FNg4UBsbHrV78fOwD0O0 sdXCuomkWvSJ+HmIzDEZCSBVhpSdXfOz61Z4l41lDSAtR9roE/tFyAbtq8aQ76bmu4QZ sH4vi3gqwTKVqld8IZRU3OceuA6dPVKeZ2Fh65XwcDRYKd7vP5MMmldWzxDHEBOMo/JW 3On0Gssmz4G+Pbvp6Zf0dcqQavG1HqFtsVRWMJftt6Jjgnp6Sy1v7D+1N+ryoarj9a+R HLMg== X-Gm-Message-State: AHQUAuYhigoH7XMN990kUcRjy4iwef9CsbQJIYSch6u6NwbhVxiz4jov Lfl7TjkASyixWKGSJOvVdiBdGeSjyHE= X-Google-Smtp-Source: AHgI3IavHLfAUzeXBpJdJ8LONg14/mvXTm6I2OcUk+TLtGACetz3b6aeJA44Mket+KWdLXj7EXtIVg== X-Received: by 2002:a25:a228:: with SMTP id b37mr14897050ybi.161.1549575552060; Thu, 07 Feb 2019 13:39:12 -0800 (PST) Received: from [10.1.200.76] (cpe-174-109-126-126.nc.res.rr.com. [174.109.126.126]) by smtp.gmail.com with ESMTPSA id r20sm163717ywa.13.2019.02.07.13.39.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 13:39:11 -0800 (PST) From: Thede Loder Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <7347DF7F-C145-470F-B7FF-AACADEAC8E49@skyelogicworks.com> Date: Thu, 7 Feb 2019 16:39:10 -0500 To: bimi@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Bimi] comments sections 1-4 re: draft-brotman-ietf-bimi-guidance-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 21:39:17 -0000 Thanks to Alex and Terry for efforts to get this first draft together. =20= Comments:=20 * Title: currently says "Branded Indicators for Message Identifcation" - = suggest we unify the expasion of the acronym to "Brand Indicators..." = (Brand not Branded) - matches "draft-blank"=20 * Introduction:=20 * First sentence. Change wording when mentioning DMARC to decouple = the logo fetching of BIMI from DMARC or other crypto methods. The way = it is written suggests that DMARC is required (in addition crypto = methods), when in fact DMARC-improved SPF and DKIM are examples of ways = for receivers to assess authentic identity, and they are not actually = required by the BIMI spec. Practically of course, they will be = required. =20 Suggest instead we say BIMI enable distribution of identity logos; then = mention that given that showing logos without using reliable (but = separate) established authentication tech would be an invitation to = fraud, say that something for authentication must be in place. Maybe = "BIMI does not require any specific authentication technology; however, = given that BIMI-sourced logos can and are intended to be used to = represent sender identity, a reliable and sufficent means of verifying = identity is very important"=20 * add langauge in the introduction to describe what is in the document. = "This document assumes that some receivers will want to implement BIMI. = The purpose of this document is to highlight challenges, discuss best = practices, and give consideration to the complex task of supporting it = in practice and at scale. " (not married to this language, but this is = the gist)=20 * Overall, the intro should probably have these elements at the high = level:=20 * what is BIMI in two sentences, and a reference to the Assertion = Record spec * what the purpose of this document is, how it relate to BIMI=20 * recap the major sections and their content=20 * Section 2: Goals for BIMI. This is good background material, though I = wonder if it should either be moved to the Assertion Record spec intro = material. Overall, a question to the group is - where in the set of = IETF docs is languge of this nature go (motivations, anticipated = beneficial side effects, etc). Can we / should we consolidate this = material, or should we sprinkle a well-honed rendition in each of the = docs? =20 Secetion 3.1 Sentence 2, beginning with BIMI, restates the value prop = and says BIMI requires DMARC. Probably should be removed. =20 To the question of "If your site satisfies the requirements, this is = likely a yes" - should we have some basic yes/no questions here, both = 'requirements' and or pre-existing features of a receiver platform? = Examples:=20 "=20 * does your email platform today have a UI that shows attached images or = renders those in HTML-based email?=20 * Do you have or want to support users reading their email from a mobile = email app? =20 * Do you currently have support for one or more email authentication = standards, such as SPF, DKIM, or S/MIME? =20 * Do you support DMARC-based identity evaluation and reporting?=20 If you answered yes to these, or you are planning to soon, you already = have much of what is needed, and your end users are used to seeing = graphical identities today" =20 Suggest Terminology goes into its own section; right now it looks like = it is in Section 3 (might be a typo)?=20 Section 4: Site implementation. First sentence as it is ("In order for = a site to correctly implement BIMI, the receiver must be able to perform the following: " seems to imply that SPF, DKIM, and = DMARC are all required. Maybe we again say "pick the authetication = technology you feel good about, provided that it is sufficient". Then = we say, "most receivers already support SPF, DKIM, DMARC, S/MIME". If = you are using these, then here's here's what you systems would perform = ... blah blah blah. =20 Here's a stab at the first "As decribed in [Assertion Record Spec] = BIMI-based logos are published via a purpose-specific DNS TXT record in = direct association with the publisher's DNS domain name. Implementors = should be prepared to verify the authenticity of a message's sender, at = least at the level/specificity of the DNS domain level. This enables = the recommended practice of only showing BIMI-obtained logos when the = identity of the sender can be reasonably assured. Existing technologies = such as DKIM and SPF are good potential choices, particularly if your = platform already supports their use. " =20 Maybe 'publisher' in the above should be MAE, for Mark Asserting Entity, = and we'll want this in the glossary. =20 For the bullet on IMAP, suggest we shorten the bullet for the list, then = pull the addtional explantion to a second para below. Then have a = forward reference to a future IMAP doc? =20 Another thought - should we have a protocol mention-free overview of the = steps, in the context of a message? E.G.:=20 1) receive message 2) confirm authenticity of sender's identity (obtain authenticated DNS = domain name)=20 3) obtain BIMI-published logo=20 4) perform validation/authenticity of published logo=20 5) optionally signal to mail store 5) arrange for the display of logo in visual association with orginal = message in the UI Perhaps after, go on to the specific protocols matching these steps? =20 General questions:=20 1) Have a separate glossary in this doc, or leverage one in [Assertion = Record Spec]? =20 2) Do we have enough of an IMAP doc to also make it an Internet Draft? = Would be a great way to engage the IETF IMAP people. =20 Thede =20 -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: 415-420-8615 From nobody Fri Feb 8 13:08:23 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B593813101F for ; Fri, 8 Feb 2019 13:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKJCBSmVBVkP for ; Fri, 8 Feb 2019 13:08:19 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD85113101E for ; Fri, 8 Feb 2019 13:08:18 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id y13so1975255ybr.7 for ; Fri, 08 Feb 2019 13:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=jXA1ao4lKIxnOYXjUFhvvI2DKb+XuQNW+d3NhZMWQ5s=; b=O2miPMGxdIZyq73wMnVTv0WNNp1rnNmohxREVyr+vZlhDPIlh072/LSUK+sAXTeAkY t0nyM3mm84sS168PJcAIlTA16JnJCHC9xgjOzm1VOabzr3l+og43+moI0JpY9O7PUmuO rsy0M+uDwBVO9pJY/N0mchS6EvLcuvGUctC9w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=jXA1ao4lKIxnOYXjUFhvvI2DKb+XuQNW+d3NhZMWQ5s=; b=ehEXJe5jcL/hksALSzB5HTKKIsvPUu66m+1rDOqRU3WxQaaKwREXHVbHzcVRflWoui yEiepYKKo95gAxVhh5lYcY64guKakthn56GQvaZgBudxMmSG0EDM5EoStXdW46ZkJO2z qN31KagEiG+7wQKvQruiUhudAYmEOnvjIq0U8QtrYVWoO6bM37TC/37HH+/AQiTq3a+E 2PFmE46+ggNqHmm8huWJ5gNH0dTZBN9o/GQX3bRj43QPBx7lZRFK0uXU4zaoGTB5B3Nw 2p6cObgLav/RND+ihV7vqtgmYqqodjVMfDOqdjE27qotyYyG6XWN7F9+uoQwcDtlSanT yCUA== X-Gm-Message-State: AHQUAua3flCt59vDwbFa6ns1kABdKYfQFqA8pfzkYsdgNSn1hSPE5Ep4 BkUuXOHlHjzKNYSlBlkygzmeEue7W1Y= X-Google-Smtp-Source: AHgI3IaRT9Vx7/yJT6cankuQYi8yxycENO7h/wdX6zGV1fpGApFf6Lyv2dA+L2vMw6amqOWKK6iEwA== X-Received: by 2002:a25:d03:: with SMTP id 3mr20154129ybn.286.1549660097309; Fri, 08 Feb 2019 13:08:17 -0800 (PST) Received: from [192.168.222.87] ([136.56.75.56]) by smtp.gmail.com with ESMTPSA id 77sm1118964ywr.19.2019.02.08.13.08.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 13:08:16 -0800 (PST) From: Thede Loder Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Fri, 8 Feb 2019 16:08:15 -0500 To: bimi@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Bimi] Sec. 5-6 draft-brotman-ietf-bimi-guidance-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 21:08:22 -0000 Hi all,=20 Here are some comments, ideas, concerns for draft-brotman, Sections 5-6:=20= Overall:=20 =3D=3D=3D=3D=3D=3D * A key "theme" for the document should be to underscore/highlight that = assuring authenticity of a message sender's identity and the = authenticity of corresponding BIMI-sourced logos is paramount for a = receiver's safe implementation and support of BIMI-based logo display. = Ensuring that the outcomes from analysis reach the MUA in some usable = way is a big part of what a receiver will have to do * illustrate/recommend procedures a receiver can undertake to reach a = reasonable level of assurance that messages are authentic, and include = both general guidelines that are standard-independent and specific = examples that are standard-specific (to "make it real" to people who = will natually think about concrete examples of the technology. E.g. = SPF, DKIM, S/MIME) =20 * I do not believe it is right to say that DMARC is required; = authentication of messages should be a receiver's choice. Currently the = draft says DMARC is required in several places. =20 Comments by sections.=20 =3D=3D=3D=3D=3D=3D=3D Recomend we change the title of section 5. Possible new one: "Assuring = Sufficient Authenticity of Messages". =20 Suggest spliting the contents of 5.1, as it seems to fit into two = buckets:=20 1) minimum recommended procedures and requirements and=20 2) optional, additional requirements (content here is already good and = can be extended). =20 Might be best to merge in some of the content from the previous section = 4.=20 So, 5.1 "Minimum Recommend Requirements"=20 and 5.2 "Additional Requirements for Consideration"=20 on existing content:=20 Section 5.1 First sentence: " In the BIMI specification, a message MUST = be authenticated via DMARC." We should probably strike or re-word, = unless we intend to have BIMI require DMARC. In reality for receiver = organizations and readers of this ID, "aligned SPF" and "aligned DKIM" = are the only games in town, unless there's support for S/MIME. But we = should welcome alternative methods as they are developed, provided they = are up to the task.=20 Maybe the intro to the section says that "authenticity should be = sufficiently confirmed, and should pass a security review with a = receiver's experts. For many mature email receiving platforms, passing = DMARC-compliant authenticity checks might be considered as sufficient. = However, it is there responsibility of the receiver / email platform = operator to weigh the risks involved, and ensure that authenticity can = be assured at appropriate levels. Assuming that aligned-SPF or = aligned-DKIM analysis, suffient to pass DMARC authentication are = sufficient, the following example illustrates the steps involved..."=20 The passage:=20 "Upon receipt of an email, a receiver that implements BIMI should remove or rename any previously existing BIMI-* headers other than BIMI-Selector, as they may have come from an attacker (as long as the BIMI-Selector is covered by the DKIM signature; if not, it should be removed, renamed, or ignored)."=20 ... is a little awkward around when to remove and inclusion of the = selector in the signature. Here's a reworded version:=20 "Upon receipt of an email, a receiver that implements BIMI should remove = (strip out) any and all BIMI-* headers, as they may have come from an = attacker. The exception to this is the "BIMI-Selector" field which = should be retained if and only if it is included within a valid DKIM = signature having i=3Ddomain aligned with the message's =46rom Header = Domain". =20 For this bullet (end of section 5):=20 "It is useful for a site that has not implemented BIMI to remove those headers so that an MUA that does make use of those headers would not accidentally display a BIMI image when the message has not been properly authenticated by the email receiver (even though an MUA should not make use of BIMI headers and instead rely upon settings from the mailstore, it is possible that some MUAs will nevertheless use headers without taking appropriate precautions)." = =20 We could in theory put this into a new section which contains = recommendations for MTAs, receivers, and relays which do not directly = support the display of BIMI logos on their own platforms, but do relay = email after verifying and confirming authenticity. Not clear anyone = would want to take on 'partial' support in this way, but maybe some = will. =20 For the current Section 5.2, what we might say here is (outline) * it's important to verify authenticity of BIMI-sourced logos, just as = it is to assess the authenticity of corresponding messages * receivers should consider support for multiple methods (depending upon = what is outlined in the Assertion Record Spec, if we extend the a=3D tag = beyond pointing to a VM Cert),=20 * Verified Mark Certificates are an option [forward reference to VMC = documents] of assuring a logo is authentically attributable to a domain = registrant and we need to change the name from BIMI Certificates to Verified Mark = Certificates where references appear. =20 Section 6:=20 This section could benefit from some introductory language to set the = context. How about:=20 "There are a variety of architectures receivers have implemented and = these determine the path messages take once received by their gateway = MTAs and how they are made available to an MUA. For strategies which = entail assessments of authenticity of messages and or BIMI-sourced logos = ahead of placement in a mailbox (expected to be commonplace), receivers = will need to consider how MUAs can be passed explicit assurances that a = receiver performed checks and the results of those checks. Further, the = "mailbox access protocol" (examples IMAP or JMAP) may need to be = utilized used to convey them. It is assumed here that MUAs will rarely = be tasked with performing all or even a subset of the recommended steps = involved, and so effective means of coordination is required "upstream" = of the MUA in the mail flow. "=20 It is expected that the burden of analysis and role of recommending to = the MUA that it show a BIMI logo (or not) for a specific message is on = the receiver infrastructure. This approach has the benefit of reducing = the implementation burden for MUAs, likely to facilitate adoption of = support" =20 One recommended way for receivers to communicate to the MUAs is as = follows: ..."=20 Section 6.1:=20 Maybe we specifically mention the l=3Dtag and the a=3Dtag as sources of = logo media?=20 And, possible lead in for the caching strategy suggestion:=20 "to eliminate unnecessary costs of a = fetch-and-validate-per-individual-message strategy, receivers should = consider caching authenticated BIMI-sourced logos in ways where they can = be redistributed safely within their infrastructure as needed and = retrived by the associated domain or domains on demand" =20 While email message bodies could in principle be amended to embed a = BIMI-sourced logo, receivers can make use of the "BIMI-Location" header = to enable supporting MTAs to obtain the logo media from a protected = location" =20 Section 6.3. =20 Layout nit. Looks like there's a formatting problem after the first = sentence. Is the next sentence in a new paragraph, or the same as the = first?=20 This section 6.3 is pretty important - me wonders if we should also copy = it or re-cap it in the BIMI Assertion Record spec? =20 Content wise, a consideration and implication of CT logging associated = with Verified Mark Certificates is that receivers can obtain a copy of = each cert (and associated set of FQDNs) directly from the CT logs. It = may be a common strategy for larger platforms to run a duplicate log = locally. This would prevent disclosure to senders (and surveilance = advertising systems) through monitoring of DNS queries related to the = logo fetching. =20 Another thought: how many selectors per domain or subdomain should a = receiver be prepared to support? If it's 50 or less, information = disclosure through the DNS query channel or l=3Dtag value is going to be = much less of an issue. =20 What's the best relationship/setup between the content in Section 4 and = that in Section 6.4 - can they be unified? This on-the-fly example is = really at the heart of the matter - and is good material for FAQ / intro = to BIMI overall. =20 Re: 6.4 bullet one. We might want to mention the term 'root program' in = reference to the activity of obtain certs and vetting cert issuers, e.g. = MVAs/CAs. =20 The mail servers are unlikely to be where the set of trusted root keys = live; instead, receivers will want to have a 'centralized' Verified Mark = Certificate vetting system, and the MTAs and or Mailstore will want to = call out to it once authenticity of a message is established. The query = would bascially say: "I have an authentic message from example.com; do = we have in our repository a VM Cert and logo for example.com from a CA = we trust? (If so, I'll set a flag on this message for MUA or mailstore = consumption/use so that the MUA can fetch the trusted logo at the right = time)" =20 Overall, there's a heap of great material in the document as it is, and = this doc 'pulls it all together' - again big thanks to Alex and Terry! =20= Thede -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: 415-420-8615 From nobody Fri Feb 8 14:09:52 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2135813101C for ; Fri, 8 Feb 2019 14:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBrjWzRWGvLg for ; Fri, 8 Feb 2019 14:06:31 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4381130F84 for ; Fri, 8 Feb 2019 14:06:30 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id r6so12905636itk.0 for ; Fri, 08 Feb 2019 14:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=dMmcXnJ7uZd2D+rjzYPyNxFRz8HKc8pZak+/pn2lLVE=; b=MHJMHbEamqbNJ/yXsj1l59QsaLeQBk18XSlvgV8+Dhqn1kAIY8zj6s63t4SlOcjSDJ kwgdjkuXEUrJ864PkVBnQsd+edYIeaxkJx9PnYYx5QYqIsBzAEEblAMmCPdQhfwFsP0L eIm0q8egLQhYjZlHuBiX2unEVgreyohAo4Ju8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dMmcXnJ7uZd2D+rjzYPyNxFRz8HKc8pZak+/pn2lLVE=; b=Mvk49Lrnpwlj35d5l0OTeI4y6QPwjRMt9erq2Ew0Z36BdSlKQwgUZ/jA5UcqO41Tm/ mET/T7I88+RtBcWlwXthCBMWSE0d3WzmZgRerbkNpI8w+OvnmCWqki5E5mqH9igkul9X 2RNqCb7RIWCw4MFTRm2pCE3zjaSUznbSYgZN4wegtvLaA/aZDeIa7GQjiuc1jq6neR6E jgOEdZ+HVbZug9IBjrVE5+xS/hR4Jtdn0myxejHGJajp2cItYagHPpPSzPOUpa9ADZiu otiY1ERPJeiC2xfnu8mo7Z3UtgKxbPkN7BSpQF3pLe5EWomzlHFxIJ59TJ7FA8v6ddWU Gy/g== X-Gm-Message-State: AHQUAub3ntxGvi5NNuS6EywMOOG1PL+RYyiXAlG/Y6pyaMdbvpgXWI3n 2P0AXRE54RjKmSZkVQt2V9OPSaTQfxhizro72h0WCc07QD3lKg== X-Google-Smtp-Source: AHgI3IYlM634mDWxXk3OILk1StcafwDyPVeYqmjbjtcJd8Bz9QHzeFG57UTkgjze5qqeDGPVzrvaCjeC2Qw+n67fESM= X-Received: by 2002:a24:3282:: with SMTP id j124mr394984ita.173.1549663589276; Fri, 08 Feb 2019 14:06:29 -0800 (PST) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Fri, 8 Feb 2019 14:06:17 -0800 Message-ID: To: bimi@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2d0820581692bc5" Archived-At: X-Mailman-Approved-At: Fri, 08 Feb 2019 14:09:50 -0800 Subject: [Bimi] Concerns regarding draft-blank-ietf-bimi-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 22:06:33 -0000 --000000000000c2d0820581692bc5 Content-Type: text/plain; charset="UTF-8" These are first-pass concerns. In some cases they echo some points cited by Seth in his announcement of the I-D posting to the list, but I'm including them here too. The document strikes me as problematic in the shifting back and forth between MUA and MTA that happens frequently within the text. The "basic structure of BIMI" seems somewhat out of place in this document which is simply focused on the DNS "announcement" of the logo. Why are two URIs required in the BIMI record? As a potential publisher, my URI already resolves to over 30 globally load-balanced CDN targets. Adding another URI will end up pointing to the same repositories. 8.2 talks about some sort of unspecified hash 8.6 is attempting to dictate to mail stores (rMS) how to do their business - seems like we should stay out of that space. It also ignores JMAP as a retrieval protocol. Conflating MTAs with "their" MUAs works for webmail providers or walled gardens, but not for general use cases (such as Yahoo! mail (or Verizon Media aka Oath aka ?) or practically any mobile client fetching mail from an arbitrary rMS). Appendix B talks about recording BIMI information in the A-R, but there is nothing in the document to suggest such activity. Based on this somewhat cursory review, I'm sure that a deeper reading would highlight more discrepancies and problems. --Kurt Andersen --000000000000c2d0820581692bc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These are first-pass concerns. In so= me cases they echo some points cited by Seth in his announcement of the I-D= posting to the list, but I'm including them here too.

The document strikes me as problematic in the shifting back and fo= rth between MUA and MTA that happens frequently within the text.
=
The "basic structure of BIMI" seems somewhat out o= f place in this document which is simply focused on the DNS "announcem= ent" of the logo.

Why are two URIs required i= n the BIMI record? As a potential publisher, my URI already resolves to ove= r 30 globally load-balanced CDN targets. Adding another URI will end up poi= nting to the same repositories.

8.2 talks about so= me sort of unspecified hash

8.6 is attempting to d= ictate to mail stores (rMS) how to do their business - seems like we should= stay out of that space. It also ignores JMAP as a retrieval protocol.

Conflating MTAs with "their" MUAs works for = webmail providers or walled gardens, but not for general use cases (such as= Yahoo! mail (or Verizon Media aka Oath aka ?) or practically any mobile cl= ient fetching mail from an arbitrary rMS).=C2=A0

A= ppendix B talks about recording BIMI information in the A-R, but there is n= othing in the document to suggest such activity.

B= ased on this somewhat cursory review, I'm sure that a deeper reading wo= uld highlight more discrepancies and problems.

--K= urt Andersen
--000000000000c2d0820581692bc5-- From nobody Fri Feb 8 14:11:01 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED63130F84 for ; Fri, 8 Feb 2019 14:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdAcryvp1A8N for ; Fri, 8 Feb 2019 14:10:57 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599B8130FFA for ; Fri, 8 Feb 2019 14:10:57 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id g85so12689350ita.3 for ; Fri, 08 Feb 2019 14:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nlKAkgh7fWZrf92xoyLl5ZMbHhYoFNtn+TzBfHpKWEQ=; b=YFSVpWmc66tJ7lKJ9dnPCnRPg2NXz7TNl1CQbI9RsQrP4cJ8r+8J1mkbxdg6PjzP8k Ym5MKlKDSOlGZWJBXnaOx9RjlWpTKkMFwtWPiUMvvWeZGbPaf0AWfkXs8CPZb8nqGUkW V8R67Q4xW3OQPaaWR+5x2xgs9j+LJGM4jGTmw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nlKAkgh7fWZrf92xoyLl5ZMbHhYoFNtn+TzBfHpKWEQ=; b=nv5vH3Jk74lNPfy7ac+eyLKaj3JrM72km7ddzpAzYtn/2gpN65SRZ+/LONA0BnEEOf UBmQKwOPxRmTNQgWBt8lwzpmK0PEDgMjULkZMiSyi8GcmwqOJRPNmDlEsyXi5FHcmOIv 1tY/oQoOXTbw/kNoFgXfAOp/1fmqzfWSXEpFSW06Q+6pns5rUSDqXbgYOhm2sfuDsB3c UHqfIVEyU4odjDS5KbzuW6xhVEfbFwJeIz9sxjAsZjDJ/VrpLdO1Ji8EX+XzdBjG2sDw PapKO4cOKA558CT7FEjSbk8ROixqOInlBz6itn5X8RHSoL/9yRZQtDYhKf7DeQKRAMhF oieg== X-Gm-Message-State: AHQUAuZuQJOkIpEhdZyLG9kV3DyORjGTKZhKweGwoqxOtEmeumkDHWZV ie/AISitCpIUmBkOPWv1N1URrbyUBN26Pae6RZQ0yRgmiBhz/w== X-Google-Smtp-Source: AHgI3IajcDDLLTrKYYT91JhfEBqmumB9qoLcFYllOU0gjmJWfxzxFpLWszemGkczG++ljrfOF8XTI0kzN6OWrtEzLKU= X-Received: by 2002:a24:3047:: with SMTP id q68mr499877itq.78.1549663855969; Fri, 08 Feb 2019 14:10:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (IETF)" Date: Fri, 8 Feb 2019 14:10:44 -0800 Message-ID: To: bimi@ietf.org Content-Type: multipart/alternative; boundary="000000000000a822110581693bb8" Archived-At: Subject: [Bimi] Fwd: Concerns regarding draft-blank-ietf-bimi-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 22:11:00 -0000 --000000000000a822110581693bb8 Content-Type: text/plain; charset="UTF-8" (Resending from the right source address) These are first-pass concerns. In some cases they echo some points cited by Seth in his announcement of the I-D posting to the list, but I'm including them here too. The document strikes me as problematic in the shifting back and forth between MUA and MTA that happens frequently within the text. The "basic structure of BIMI" seems somewhat out of place in this document which is simply focused on the DNS "announcement" of the logo. Why are two URIs required in the BIMI record? As a potential publisher, my URI already resolves to over 30 globally load-balanced CDN targets. Adding another URI will end up pointing to the same repositories. 8.2 talks about some sort of unspecified hash 8.6 is attempting to dictate to mail stores (rMS) how to do their business - seems like we should stay out of that space. It also ignores JMAP as a retrieval protocol. Conflating MTAs with "their" MUAs works for webmail providers or walled gardens, but not for general use cases (such as Yahoo! mail (or Verizon Media aka Oath aka ?) or practically any mobile client fetching mail from an arbitrary rMS). Appendix B talks about recording BIMI information in the A-R, but there is nothing in the document to suggest such activity. Based on this somewhat cursory review, I'm sure that a deeper reading would highlight more discrepancies and problems. --Kurt Andersen --000000000000a822110581693bb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(Resending from the right s= ource address)

These are first-pass concerns. In some cases they echo some = points cited by Seth in his announcement of the I-D posting to the list, bu= t I'm including them here too.

The document st= rikes me as problematic in the shifting back and forth between MUA and MTA = that happens frequently within the text.

The "= ;basic structure of BIMI" seems somewhat out of place in this document= which is simply focused on the DNS "announcement" of the logo.

Why are two URIs required in the BIMI record? As a = potential publisher, my URI already resolves to over 30 globally load-balan= ced CDN targets. Adding another URI will end up pointing to the same reposi= tories.

8.2 talks about some sort of unspecified h= ash

8.6 is attempting to dictate to mail stores (r= MS) how to do their business - seems like we should stay out of that space.= It also ignores JMAP as a retrieval protocol.

Con= flating MTAs with "their" MUAs works for webmail providers or wal= led gardens, but not for general use cases (such as Yahoo! mail (or Verizon= Media aka Oath aka ?) or practically any mobile client fetching mail from = an arbitrary rMS).=C2=A0

Appendix B talks about re= cording BIMI information in the A-R, but there is nothing in the document t= o suggest such activity.

Based on this somewhat cu= rsory review, I'm sure that a deeper reading would highlight more discr= epancies and problems.

--Kurt Andersen
=
--000000000000a822110581693bb8-- From nobody Fri Feb 8 14:21:12 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986C7130F84 for ; Fri, 8 Feb 2019 14:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcHz1Oimb1mI for ; Fri, 8 Feb 2019 14:21:07 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01137129A85 for ; Fri, 8 Feb 2019 14:21:06 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id z19so4462467otm.2 for ; Fri, 08 Feb 2019 14:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sCL7CxK5HjsXWSKgri4iAetQdH2qWKzna9Pon8xiLxI=; b=MA1E9H8UKBjpvRT8dddF7jfnffJDWmUjUWEMp2N7V1O5e/dKYxjEnjqg2P5rB831n9 Nriv9l0ofKGmD/594Fw9M6rA5I0meUjdGe3E13V+9HR2z5KTqlgZ6Uv5zC+w4AVpYtYH IZmQQ2JamKtsuKiwbeoEIQSJyEHDoMd6q+9ap3MhIrQCRi7ECMk1hfawYoRtY8dU1vEB vsj8lk2LeabC13zJC6DWqtIuUjKJue8Ix+VB1d52K/e1iO4S8mMxEs+XGJ2UQQf8syuT 6qXqfIofcSKDyy7RSCGR+EUGgds7hdSzvlVOAdi8Cgb9AyWNRRR/k8s1N3A4Iw7UhekS FqwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sCL7CxK5HjsXWSKgri4iAetQdH2qWKzna9Pon8xiLxI=; b=tIaaAb/wbbsHslGEnZQC8SeOGsCTw3TSmSulubI4QdrQTUkk5Y2vBwW2eiikJDhmwq hDkfg9JijlCh2NK+cwlAF7nvC5lhyGhzE1H4fDTMS1bkheqXumJmw4NegBjSX8Zjh7AC k2VNuT6ypGWLT6Sztk39RZWMAr7wpp5jJM9WNsKb5YJMfKHnLmBmtoPdTTHK6acUrCzs W4rZfjkLdkmpMujutZ2GMUvmeGuMUCYZt7PAgeErKK2QHB7jsOUsM6m2Mm/0pHqFtscn fnDVYEPzozquL4i4P/OxGI8xhyoFJVFninhnfmwTlvL1OX15QOWXxUxsh6G9Wfydt4tS NhXw== X-Gm-Message-State: AHQUAuY3NCWbir1SpTtlvA15AmnSiRbHANa2NQqZRhSj6zBq5R+AOmFt 98JLJwZ0YBnDt/PaZGbYHt0No9Z8wQ8vLhv6ncHbnK5NKLFSxg== X-Google-Smtp-Source: AHgI3IYrQnCyhc56L018A6j8bV53rNIX5QeTYBDcEYq3UYkqlgmgeRNc4XiObOdEuolcpVJUTsCNtSq8bEp/VPKb/cI= X-Received: by 2002:a9d:784a:: with SMTP id c10mr15577501otm.175.1549664465703; Fri, 08 Feb 2019 14:21:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Fri, 8 Feb 2019 14:20:41 -0800 Message-ID: To: bimi@ietf.org Content-Type: multipart/alternative; boundary="000000000000ffef710581695f49" Archived-At: Subject: Re: [Bimi] Concerns regarding draft-blank-ietf-bimi-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 22:21:09 -0000 --000000000000ffef710581695f49 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 8, 2019 at 2:09 PM Kurt Andersen (b) wrote: > These are first-pass concerns. In some cases they echo some points cited > by Seth in his announcement of the I-D posting to the list, but I'm > including them here too. > > The document strikes me as problematic in the shifting back and forth > between MUA and MTA that happens frequently within the text. > Agreed. The intent had been to keep conversation around display implications (MUA) separate from evaluation/validation ones (MTA), but I think that got lost and a single term is needed to simplify and be comprehensive, especially since this separation isn't true all the time. The "basic structure of BIMI" seems somewhat out of place in this document > which is simply focused on the DNS "announcement" of the logo. > > Why are two URIs required in the BIMI record? As a potential publisher, my > URI already resolves to over 30 globally load-balanced CDN targets. Adding > another URI will end up pointing to the same repositories. > Honestly, this was cribbed from DMARC when we first started writing the BIMI spec and the mechanisms were far more complex; it may no longer be relevant. 8.2 talks about some sort of unspecified hash > This mistake is on me :-/ How would you suggest it be cleaned up? > 8.6 is attempting to dictate to mail stores (rMS) how to do their business > - seems like we should stay out of that space. It also ignores JMAP as a > retrieval protocol. > > Conflating MTAs with "their" MUAs works for webmail providers or walled > gardens, but not for general use cases (such as Yahoo! mail (or Verizon > Media aka Oath aka ?) or practically any mobile client fetching mail from > an arbitrary rMS). > Agreed, per above. > Appendix B talks about recording BIMI information in the A-R, but there is > nothing in the document to suggest such activity. > Not true! https://tools.ietf.org/html/draft-blank-ietf-bimi-00#section-8.3 --000000000000ffef710581695f49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 8, 2019 at 2= :09 PM Kurt Andersen (b) <kboth@drku= rt.com> wrote:
The= se are first-pass concerns. In some cases they echo some points cited by Se= th in his announcement of the I-D posting to the list, but I'm includin= g them here too.

The document strikes me as proble= matic in the shifting back and forth between MUA and MTA that happens frequ= ently within the text.

Ag= reed. The intent had been to keep conversation around display implications = (MUA) separate from evaluation/validation ones (MTA), but I think that got = lost and a single term is needed to simplify and be comprehensive, especial= ly since this separation isn't true all the time.
=C2=A0

The "basic structure of BIMI" seem= s somewhat out of place in this document which is simply focused on the DNS= "announcement" of the logo.

Why are two= URIs required in the BIMI record? As a potential publisher, my URI already= resolves to over 30 globally load-balanced CDN targets. Adding another URI= will end up pointing to the same repositories.

Honestly, this was cribbed from DMARC when we first = started writing the BIMI spec and the mechanisms were far more complex; it = may no longer be relevant.


8.2 talks about some sort of unspecified hash

This mistake is on me :-/ How would you suggest it be= cleaned up?

=C2=A0
8.6 is atte= mpting to dictate to mail stores (rMS) how to do their business - seems lik= e we should stay out of that space. It also ignores JMAP as a retrieval pro= tocol.

Conflating MTAs with "their" MUAs= works for webmail providers or walled gardens, but not for general use cas= es (such as Yahoo! mail (or Verizon Media aka Oath aka ?) or practically an= y mobile client fetching mail from an arbitrary rMS).=C2=A0

Agreed, per above.

<= div>=C2=A0
Appendix B talks about recording BIMI inform= ation in the A-R, but there is nothing in the document to suggest such acti= vity.

Not true!
=


--000000000000ffef710581695f49-- From nobody Sat Feb 9 09:24:25 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D81129AA0 for ; Sat, 9 Feb 2019 09:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marcbradshaw.net header.b=Z1M3Kz5M; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AZDcV2OI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4tFeLiNvqSs for ; Sat, 9 Feb 2019 09:24:21 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB931275F3 for ; Sat, 9 Feb 2019 09:24:21 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AB6BC21B2C for ; Sat, 9 Feb 2019 12:24:20 -0500 (EST) Received: from imap38 ([10.202.2.88]) by compute2.internal (MEProxy); Sat, 09 Feb 2019 12:24:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=message-id:date:from:to:subject :content-type; s=fm2; bh=e2ffK5ftGAf2Qb4faOf/s2flG78PT40CgbaYa7H gyok=; b=Z1M3Kz5M5UCMzZHoV8YxKFnkMoThTSGhPT9wxcfSOgkuBDgIPmYBWAo f/z0fJ4HiBhaBBrthCeUleKJxtYCfnGeEkmK8+K6otWEzoJ7OYqw3knrBU12uofx +s+/kXX0GZcGG42yWuFSGfKiStAfs1btUntd9hbCgRKx+ODEdjBujovRPsmzOf3m 9JCyJ1VWKOgLEpDdzh6VfTsXofbJ4HFBVpXVeP5dXrPr4vTlKYO4rmU+zlUxRGS6 ukQyO+/8xu+HJIBjpECNUyNkD0gtkxDJiLYB09Tg5Zvk7CSwOgKkXfy1Bx16d02k 62JXTYcSvhJbHTIBtNHfSWfBnSHOToQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=e2ffK5ftGAf2Qb4faOf/s2flG78PT40CgbaYa7Hgyok=; b=AZDcV2OI vgpBWCGvyrV6IE2dgpaLHo4Dn1gP9/UR0mmKSRacJKeDuQmgAhTs1uK1BcZYoMAe X3XgqFpSDOgZPtpjX5WfQBZdrgZZjmkIcoYrxOnF5liNlIACgV5tLfRkilk2tN4l iZNlLZRgpurLo33uR/l6qtQzFkaVc15s+I7NXVmz3XhiMJcRiG6mpw16PnH77psK xtpKbsCGWxiCxN/M6SxuDcCghzmZdc6u0wnAw0rzIHUnpouoPm4s+tr9oRhlmBD5 8d5UV9VaGsAxKshqC9TKSCCzVfZrGNRB0w7U3uOrvYpJ6JuPZ9NN/7GtapRB4OgD 0/1+DeylVZtBYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleeggddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfof grrhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnhgv theqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomh epmhgrrhgtsehmrghrtggsrhgrughshhgrfidrnhgvthenucevlhhushhtvghrufhiiigv pedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 26A3D3A69E; Sat, 9 Feb 2019 12:24:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 63695113 Message-Id: <6d3c60c3-59b7-4fe2-b0ca-ba4fa5d495bd@www.fastmail.com> Date: Sat, 09 Feb 2019 12:24:01 -0500 From: "Marc Bradshaw" To: bimi@ietf.org Content-Type: multipart/alternative; boundary=42eaa10937c24b1da7c2e063ef9ea190 Archived-At: Subject: [Bimi] PDF Formatting issue X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 17:24:23 -0000 --42eaa10937c24b1da7c2e063ef9ea190 Content-Type: text/plain Having a read through now and will prepare some comments. Page 10 of the PDF version https://tools.ietf.org/pdf/draft-blank-ietf-bimi-00.pdf is currently unreadable due to formatting issues. --42eaa10937c24b1da7c2e063ef9ea190 Content-Type: text/html
Having a read through now and will prepare some comments.

Page 10 of the PDF version https://tools.ietf.org/pdf/draft-blank-ietf-bimi-00.pdf is currently unreadable due to formatting issues.



--42eaa10937c24b1da7c2e063ef9ea190-- From nobody Sat Feb 9 15:12:10 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C43B12950A for ; Sat, 9 Feb 2019 10:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z79ojECZdoU for ; Sat, 9 Feb 2019 10:19:05 -0800 (PST) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8C41288BD for ; Sat, 9 Feb 2019 10:19:04 -0800 (PST) X-AuditID: 44571fa7-a0dff70000021550-3b-5c5f1997d425 Received: from PACDCEX18.cable.comcast.com (dlpemail-wc-5p.cable.comcast.com [24.40.13.176]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id F9.98.05456.7991F5C5; Sat, 9 Feb 2019 13:19:03 -0500 (EST) Received: from PACDCEX19.cable.comcast.com (24.40.1.142) by PACDCEX18.cable.comcast.com (24.40.1.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 9 Feb 2019 13:19:02 -0500 Received: from PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304]) by PACDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8304%19]) with mapi id 15.00.1395.000; Sat, 9 Feb 2019 13:19:02 -0500 From: "Brotman, Alexander" To: Thede Loder , "bimi@ietf.org" Thread-Topic: [Bimi] Sec. 5-6 draft-brotman-ietf-bimi-guidance-00 Thread-Index: AQHUv/JyAeguxzv1U06WL2pOP1JzwKXXcsrw Date: Sat, 9 Feb 2019 18:19:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KR0ODdoDtdMj7G4FOvoUXzuf2MFrsPvWF0 YPI4sewKq8eSJT+ZApiiGhhtSjKKUhNLXFLTUvOKU+24FDCATVJqWn5RqmtiUU5lUGpOaiJ2 ZSCVKak5mWWpRfpYjdHHak5CF1PGmhnr2Qr+RVQcuPiNqYFxinsXIyeHhICJxLm/jexdjFwc QgI7mCSO3zrNCOHsZJTYc+4MK4RzglFi4bYTTCAtbAJWEm//tzOD2CICcRL7mzcwgtjCAg4S NzdOYoSIO0qs276PHcI2klg+7zKYzSKgItH34x7YHF4BL4n/11awgNhCAq4Sz9a8ZQWxOQXc JK59uA0WZxQQk/h+ag1YPbOAuMStJ/OZIM4WkFiy5zwzhC0q8fLxP1YI20Bi69J9LBC2nMTc 1/dYIHp1JBbs/sQGYWtLLFv4mhniBkGJkzOfQNWLSxw+soN1AqP4LCTrZiFpn4WkfRaS9gWM LKsYecws9CzM9YwN9QzNzDcxAhOHS7j88h2M22dlHGIU4GBU4uH1/hUXI8SaWFZcmXuIUYKD WUmEN1UiPkaINyWxsiq1KD++qDQntfgQozQHi5I4r2hUdIyQQHpiSWp2ampBahFMlomDU6qB sSZ/lrHLW7sXs3h9FmkGRXzZ9kxe5snNzft45/7fl9BycoleXWX7//6ARPOu1Q4PpvpPZj7I E+E0ZfLhtjth9xvz9p+1dekOEz/6u/3MV75Vah0H46c6xNQw37OPWl9x9XhhUvcfpYWRz8PF 5zeKL+q6WBC75YsFv/+sbVdFev3/7L/HcvHoPyWW4oxEQy3mouJEABkMPwkYAwAA Archived-At: X-Mailman-Approved-At: Sat, 09 Feb 2019 15:12:10 -0800 Subject: Re: [Bimi] Sec. 5-6 draft-brotman-ietf-bimi-guidance-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 18:19:09 -0000 I'm going to put aside the word-smithing from this and your prior message f= or the moment. I agree with most of them, and I'll get those changes incor= porated. As for the reliance on DMARC, contained within section 2 of [draft-blank-ie= tf-bimi-00]: 2. Then, for any message received by a Mail Receiver: a. Receivers authenticate the messages using [DMARC] and whatever other authentication mechanisms they wish to apply. b. The receiver queries the DNS for a corresponding BIMI record and proof of indicator validation. c. If both the email and the logo authenticate, then the receiver adds a header to the message, which can be used by the MUA to determine the Domain Owner's preferred brand indicator. That, to me, indicates a dependency on DMARC and its associated mechanisms,= but does not limit authentication to solely DMARC, allowing for additional= methods. Also, note 8.3 which seems to indicate the same. This seems to = be related to the majority of your comments. If this is not the case, we'l= l need to reword both drafts appropriately. If that is the case, I'll get = to work with the other rewordings you've suggested (and I assume you'll hav= e more for the rest of the document on the way). -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast -----Original Message----- From: bimi On Behalf Of Thede Loder Sent: Friday, February 8, 2019 4:08 PM To: bimi@ietf.org Subject: [Bimi] Sec. 5-6 draft-brotman-ietf-bimi-guidance-00 Hi all,=20 Here are some comments, ideas, concerns for draft-brotman, Sections 5-6:=20 Overall:=20 =3D=3D=3D=3D=3D=3D * A key "theme" for the document should be to underscore/highlight that ass= uring authenticity of a message sender's identity and the authenticity of c= orresponding BIMI-sourced logos is paramount for a receiver's safe implemen= tation and support of BIMI-based logo display. Ensuring that the outcomes = from analysis reach the MUA in some usable way is a big part of what a rece= iver will have to do * illustrate/recommend procedures a receiver can undertake to reach a reaso= nable level of assurance that messages are authentic, and include both gene= ral guidelines that are standard-independent and specific examples that are= standard-specific (to "make it real" to people who will natually think abo= ut concrete examples of the technology. E.g. SPF, DKIM, S/MIME) =20 * I do not believe it is right to say that DMARC is required; authenticatio= n of messages should be a receiver's choice. Currently the draft says DMAR= C is required in several places. =20 Comments by sections.=20 =3D=3D=3D=3D=3D=3D=3D Recomend we change the title of section 5. Possible new one: "Assuring Suf= ficient Authenticity of Messages". =20 Suggest spliting the contents of 5.1, as it seems to fit into two buckets:= =20 1) minimum recommended procedures and requirements and=20 2) optional, additional requirements (content here is already good and can = be extended). =20 Might be best to merge in some of the content from the previous section 4.= =20 So, 5.1 "Minimum Recommend Requirements"=20 and 5.2 "Additional Requirements for Consideration"=20 on existing content:=20 Section 5.1 First sentence: " In the BIMI specification, a message MUST be = authenticated via DMARC." We should probably strike or re-word, unless we= intend to have BIMI require DMARC. In reality for receiver organizations = and readers of this ID, "aligned SPF" and "aligned DKIM" are the only games= in town, unless there's support for S/MIME. But we should welcome alterna= tive methods as they are developed, provided they are up to the task.=20 Maybe the intro to the section says that "authenticity should be sufficient= ly confirmed, and should pass a security review with a receiver's experts. = For many mature email receiving platforms, passing DMARC-compliant authent= icity checks might be considered as sufficient. However, it is there respo= nsibility of the receiver / email platform operator to weigh the risks invo= lved, and ensure that authenticity can be assured at appropriate levels. A= ssuming that aligned-SPF or aligned-DKIM analysis, suffient to pass DMARC a= uthentication are sufficient, the following example illustrates the steps i= nvolved..."=20 The passage:=20 "Upon receipt of an email, a receiver that implements BIMI should remove or rename any previously existing BIMI-* headers other than BIMI-Selector, as they may have come from an attacker (as long as the BIMI-Selector is covered by the DKIM signature; if not, it should be removed, renamed, or ignored)."=20 .... is a little awkward around when to remove and inclusion of the selecto= r in the signature. Here's a reworded version:=20 "Upon receipt of an email, a receiver that implements BIMI should remove (s= trip out) any and all BIMI-* headers, as they may have come from an attacke= r. The exception to this is the "BIMI-Selector" field which should be reta= ined if and only if it is included within a valid DKIM signature having i= =3Ddomain aligned with the message's From Header Domain". =20 For this bullet (end of section 5):=20 "It is useful for a site that has not implemented BIMI to remove those headers so that an MUA that does make use of those headers would not accidentally display a BIMI image when the message has not been properly authenticated by the email receiver (even though an MUA should not make use of BIMI headers and instead rely upon settings from the mailstore, it is possible that some MUAs will nevertheless use headers without taking appropriate precautions)." =20 We could in theory put this into a new section which contains recommendatio= ns for MTAs, receivers, and relays which do not directly support the displa= y of BIMI logos on their own platforms, but do relay email after verifying = and confirming authenticity. Not clear anyone would want to take on 'parti= al' support in this way, but maybe some will. =20 For the current Section 5.2, what we might say here is (outline) * it's important to verify authenticity of BIMI-sourced logos, just as it i= s to assess the authenticity of corresponding messages * receivers should consider support for multiple methods (depending upon wh= at is outlined in the Assertion Record Spec, if we extend the a=3D tag beyo= nd pointing to a VM Cert),=20 * Verified Mark Certificates are an option [forward reference to VMC docume= nts] of assuring a logo is authentically attributable to a domain registran= t and we need to change the name from BIMI Certificates to Verified Mark Cert= ificates where references appear. =20 Section 6:=20 This section could benefit from some introductory language to set the conte= xt. How about:=20 "There are a variety of architectures receivers have implemented and these = determine the path messages take once received by their gateway MTAs and ho= w they are made available to an MUA. For strategies which entail assessmen= ts of authenticity of messages and or BIMI-sourced logos ahead of placement= in a mailbox (expected to be commonplace), receivers will need to consider= how MUAs can be passed explicit assurances that a receiver performed check= s and the results of those checks. Further, the "mailbox access protocol" = (examples IMAP or JMAP) may need to be utilized used to convey them. It is= assumed here that MUAs will rarely be tasked with performing all or even a= subset of the recommended steps involved, and so effective means of coordi= nation is required "upstream" of the MUA in the mail flow. "=20 It is expected that the burden of analysis and role of recommending to the = MUA that it show a BIMI logo (or not) for a specific message is on the rece= iver infrastructure. This approach has the benefit of reducing the impleme= ntation burden for MUAs, likely to facilitate adoption of support" =20 One recommended way for receivers to communicate to the MUAs is as follows:= ..."=20 Section 6.1:=20 Maybe we specifically mention the l=3Dtag and the a=3Dtag as sources of log= o media?=20 And, possible lead in for the caching strategy suggestion:=20 "to eliminate unnecessary costs of a fetch-and-validate-per-individual-mess= age strategy, receivers should consider caching authenticated BIMI-sourced = logos in ways where they can be redistributed safely within their infrastru= cture as needed and retrived by the associated domain or domains on demand"= =20 While email message bodies could in principle be amended to embed a BIMI-so= urced logo, receivers can make use of the "BIMI-Location" header to enable = supporting MTAs to obtain the logo media from a protected location" =20 Section 6.3. =20 Layout nit. Looks like there's a formatting problem after the first senten= ce. Is the next sentence in a new paragraph, or the same as the first?=20 This section 6.3 is pretty important - me wonders if we should also copy it= or re-cap it in the BIMI Assertion Record spec? =20 Content wise, a consideration and implication of CT logging associated with= Verified Mark Certificates is that receivers can obtain a copy of each cer= t (and associated set of FQDNs) directly from the CT logs. It may be a com= mon strategy for larger platforms to run a duplicate log locally. This wou= ld prevent disclosure to senders (and surveilance advertising systems) thro= ugh monitoring of DNS queries related to the logo fetching. =20 Another thought: how many selectors per domain or subdomain should a receiv= er be prepared to support? If it's 50 or less, information disclosure thro= ugh the DNS query channel or l=3Dtag value is going to be much less of an i= ssue. =20 What's the best relationship/setup between the content in Section 4 and tha= t in Section 6.4 - can they be unified? This on-the-fly example is really = at the heart of the matter - and is good material for FAQ / intro to BIMI o= verall. =20 Re: 6.4 bullet one. We might want to mention the term 'root program' in re= ference to the activity of obtain certs and vetting cert issuers, e.g. MVAs= /CAs. =20 The mail servers are unlikely to be where the set of trusted root keys live= ; instead, receivers will want to have a 'centralized' Verified Mark Certif= icate vetting system, and the MTAs and or Mailstore will want to call out t= o it once authenticity of a message is established. The query would bascia= lly say: "I have an authentic message from example.com; do we have in our r= epository a VM Cert and logo for example.com from a CA we trust? (If so, I= 'll set a flag on this message for MUA or mailstore consumption/use so that= the MUA can fetch the trusted logo at the right time)" =20 Overall, there's a heap of great material in the document as it is, and thi= s doc 'pulls it all together' - again big thanks to Alex and Terry! =20 Thede -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: 415-420-8615 --=20 bimi mailing list bimi@ietf.org https://www.ietf.org/mailman/listinfo/bimi From nobody Sat Feb 9 21:19:53 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE70112894E for ; Sat, 9 Feb 2019 21:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=P1ZfnUN3; dkim=pass (1536-bit key) header.d=taugh.com header.b=Hl/5nxsd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa09EFxL1cXQ for ; Sat, 9 Feb 2019 21:05:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00FE124408 for ; Sat, 9 Feb 2019 21:05:52 -0800 (PST) Received: (qmail 52842 invoked from network); 10 Feb 2019 05:05:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ce67.5c5fb12d.k1902; bh=s4zsbE71E13Bv61xCsDNhapfTLWOHUtPmLRsNkUPkyk=; b=P1ZfnUN3gr3IZ0wREtajsMTUky9BKSong09P7AiQSGqI+3N7LtX5ZMB0Y/rK2QlT1kvF6Ex6Z0CEJLrwRcL3HAZZdwA5H+iwS46oO8Y14JwyzX0Pe59y0GCcLiYGjhZ0GvhBi1lIZR84E1krC6PC6l/Vj89U5h8aLMaTBcq1cWMOswp4JPsL8jHLP/SHz66ZB3ERr5u3EkOPfAew5sTU1VUVYHJ4BTEmpGUPZHUvX9d3BP+AzIkgzUaiv4AW1/EL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ce67.5c5fb12d.k1902; bh=s4zsbE71E13Bv61xCsDNhapfTLWOHUtPmLRsNkUPkyk=; b=Hl/5nxsdliCTwNKauv6SXrA/o5jbzceiGTBfPsDUjuFqrAyQ4jXyJgK4i/BG7lDlof16P7iQuZQanxtOiyKsuhXuOtzRq4MOy8HuMc/C2lkCx8HF/2uPBpjqcOH4Wxw9uwqTULehmSBTkG+PHK47gAUzizvggtAkLpxKGMVUPYGUYwADQZeQwe0twCphCG4+1eZ11+mFUhzn0MbAkuqMMaOEXh+x8cvd8dhXiK7dtQvgN4OqkyouSFAmzOh5/Xzh Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Feb 2019 05:05:49 -0000 Received: by ary.qy (Postfix, from userid 501) id 49101200E153A3; Sun, 10 Feb 2019 00:05:48 -0500 (EST) Date: 10 Feb 2019 00:05:48 -0500 Message-Id: <20190210050549.49101200E153A3@ary.qy> From: "John Levine" To: bimi@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: X-Mailman-Approved-At: Sat, 09 Feb 2019 21:19:51 -0800 Subject: Re: [Bimi] Concerns regarding draft-blank-ietf-bimi-00 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 05:05:55 -0000 In article you write: >8.6 is attempting to dictate to mail stores (rMS) how to do their business >- seems like we should stay out of that space. It also ignores JMAP as a >retrieval protocol. No kidding. I know how to put flags on messages with IMAP and probably with JMAP, but there's no such thing in POP. From nobody Sun Feb 10 20:39:16 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FED130F9D for ; Sun, 10 Feb 2019 20:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=PRgppY0r; dkim=pass (1536-bit key) header.d=taugh.com header.b=WJtg8Cla Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krEs8ms5t3TY for ; Sun, 10 Feb 2019 20:39:12 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF7F130F93 for ; Sun, 10 Feb 2019 20:39:11 -0800 (PST) Received: (qmail 62644 invoked from network); 11 Feb 2019 04:39:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=f4b2.5c60fc6e.k1902; bh=kSxzYotC9yDr27Y1nPTXZUkRobgN7eKbAJJiwWLMclE=; b=PRgppY0rr2dS5ppdCP3d1XLLSpVP6C5JMmn7JYQZkzr4Ai12/fIXcxuMO8mycYE8PUtquf/0plwXvMdkXEF3tIYSf5pG2XYTPLRPqi4gfJBVQzmqbh0qTFuJgeiX79dEiBZp01UYpKgF3r3KKwtyEoOVACPgIXJsJU8NW2BNgZTJxRSAMp/k+fQxPvmST0lOXPR6cMaMOCG7Nqog34vfYmx0aKtHS+VjxdhkuKlAIx2pdaNY36/51yGsnRVDMKj/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=f4b2.5c60fc6e.k1902; bh=kSxzYotC9yDr27Y1nPTXZUkRobgN7eKbAJJiwWLMclE=; b=WJtg8ClaxTRrBEj4Di/MsCN5UPHFLhf5f3y5zvQOuELWAsVij7tZ9HEI4wpWhkIz+A3BpcEl/I2bWHLLFRE0oCq0w4sSa7SkT2sfu6J69yGaHPFS/MCC4KTuuqbVLPaA/jt0WjyBJTyQy9Zfoir9yJ+7V3XbN9NG7Gy0cNTxVkImsE3M9YGJz5ro2CNrILJjtT4wSdYuNMd93SEDnZ9AQ+pp9bDGAMiuCDyGtGPOBGZgA3L1G1uaYByOVaIXwpMk Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 11 Feb 2019 04:39:10 -0000 Date: 10 Feb 2019 23:39:10 -0500 Message-ID: From: "John R Levine" To: bimi@ietf.org User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 04:39:14 -0000 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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Feb 10 22:19:33 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B776812894E for ; Sun, 10 Feb 2019 22:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdeaBq3S2ire for ; Sun, 10 Feb 2019 22:19:29 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC3D124BAA for ; Sun, 10 Feb 2019 22:19:29 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id d190so3769245ywd.12 for ; Sun, 10 Feb 2019 22:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n9WcmWXxgEyeXZCy2YPP7dUfS9qNe9GZjolR7suFFtA=; b=UusqHaj2vGVgDl9m0W/DGwbtfkQc4TFsJZqdp386p+OohS1x0YSBDfj9Wi8GnMbCT3 1IZLdWxaUI2WGNcw8IBrM5hMkiiKt9iyEqwbjrUOaTC2PdKfjm/0DX5+Y1TkzrSP7cAz z9JLFdJL4PdsH04kc9pHRrr1/jLINUHi8uDkswMBq8Qfee5cSctA6hH/MpZ6Sx062Nb4 u7XoSDOvqf/Vj4KDc6TPzAVjeMwUzpNmRulnGyUpzGui2pP6G2urWDdkSRfvGHoWXsXX xd+oZOdhqC2NMCBtX2TP4EbP4W6D0N+nYLvJx8VKska4mp9NSfeFKVFmZbvvCDupstAT Er8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n9WcmWXxgEyeXZCy2YPP7dUfS9qNe9GZjolR7suFFtA=; b=s3f6zuic3whm6DpfNI1S9tl2fBlkdNoA5y4VKYR07sOx3uTKhA5OMmvvKPcRgrFByM 9c1T/DdBd8WzmusDzSA7n+nOgZ44brCND7RzgmlDjgWU7XXcSW2soGK/OpapmII3hwyF AHvpudip6/GBfenfCfKvCXJa4E40LMxAR1qdwWjg/MFOnCLK8d/N4lr3PaD07qiS8qFU Bfi5oBZDuFoYZT9tPrN80hRMYQhOcwZ9KXlRBTvx0H8rtPsu5tnkE5VaWjwn5KEGAT9Q xdDRO5tacbSOio9qyTHuDKDjZd1d2Ck+fl23elINhus0boFVN54DWj6km54pNH1JlrF/ pOhA== X-Gm-Message-State: AHQUAuakXnlk3qcG+9PaSvpYdVrqEBYfvzS6IZRskXU4FF/0W3IzcFSu Ji4qAoGiioZnAnFHspx/gji6Z5Lq0KvO4Mtoe00tsGkqrh8= X-Google-Smtp-Source: AHgI3IZXDEompl78i5xgWhJGYg0I1hn/RihK8JH3jCTUej/wKuuwE27xddHJP3p4wz9JaRNTvKcI4Uewx1BEGMsLVR0= X-Received: by 2002:a81:1d44:: with SMTP id d65mr27874117ywd.483.1549865967638; Sun, 10 Feb 2019 22:19:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Wei Chuang Date: Sun, 10 Feb 2019 22:19:15 -0800 Message-ID: To: John R Levine Cc: bimi@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007f30720581984a37" Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 06:19:32 -0000 --0000000000007f30720581984a37 Content-Type: multipart/alternative; boundary="00000000000073d4060581984a27" --00000000000073d4060581984a27 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 10, 2019 at 8:39 PM John R Levine 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 > 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? 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 > any CAs that will do the logo attestation? > 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. > 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? 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 > say it's only valid in some countries. > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > -- > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi > --00000000000073d4060581984a27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 10, 2019 at 8:39 PM John = R Levine <johnl@tau= gh.com> wrote:
BIMI appears to assume that senders will have TLS certificates

BIMI (sometimes documented as Verified Mark) cert= ificates should be considered a different PKI than TLS certificates.=C2=A0 = The certificates have a distinguishing Extended Key Usage for this.
=C2=A0
that incl= ude
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?

The proposed validation as documented in the guide= lines (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 d= one for web EV.
=C2=A0
=C2=A0 Are there
any CAs that will do the logo attestation?

<= div>We (Authindicators WG) have been working with Entrust-Datacard on the G= uidelines, and they are willing to do this logo attestation.=C2=A0 We also = are talking with other CAs, and believe that at least one other is willing.= =C2=A0=C2=A0
=C2=A0
Logos, like all trademarks, have geographic scope, and it's not rare fo= r a
trademark and logo to belong to one company in, say, the US and a different= one
in Europe.=C2=A0 How will that work?

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

-Wei=
=C2=A0
= =C2=A0 I don't think there's any way for a cert to
say it's only valid in some countries.

Regards,
John Levine, johnl@iecc= .com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi
--00000000000073d4060581984a27-- --0000000000007f30720581984a37 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMWMqzbpn2SydMzpfaMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MTExNTE4NDMwM1oXDTE5MDUx NDE4NDMwM1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDOGIfi32h8dhJEeUGHfN1nAVrJsY4ph3nisYgnB2pOA4hcNkX4 xnnbD7PDr6G2S6LqYfXegzUkLT7FoOGtptBAixwpSxBUvEWQdrlbYdYuoNK7/DBASrlp4J7UocGX ZS5dkWL0IolToc52mCmOxhTqDjbD9MG3+AvyyQPK0RVgNY5n7BZBdNZDHTeswReAtjQ4t+b1IStQ 7Y59jxTOfDPpAT2Y0ON44Lx2hBLyQ8wXYCmHHbWCyGT3xZH0p8p+cGgkKvDjaxBX3ilopH8hx4zm 5HVh6wDOBHhAnRYVU1bqmjohWNuLhz/Za6lWGiylhPD+2yFLQfvHn6OBE0a/048NAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFJUPLExeOaBiYyZVRuorZTtplIumMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBuvV1bxPXhqWWCHYz7 40fvnmDIUsNiLecW3PCDQxdpPMc3V/6T31qSKYvuFigtj2MpXMCkLqbHupVN3b14UvnqNx3jnu7b Yp+rMcjjO70W3ufBqqz/QQzSykR9ATo+Zqs09dhJtTl02ApUqYipoInGx8wu0ChTI84NwR5UUo7H GSOet+Eluj5Yjq0YdM2qzfapP/XbfO7t533yiK5Cs//IlaQagdizrM/b1DTYjJ/28b3uPMS3l6a8 BoWm7kiV6GCY7zBNF9D6Gkf6U4dZgx6SwQjQoG3mSBV1zzIs0cZYoVvq/8y+5jC9CdH1ran/ahb6 1ZtMG4auBaKMRzEe3TimMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMWMqzbpn2 SydMzpfaMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBNmtYHRpbUOk/cJVhQ6oes wIH8LvU+udZhniT2Wjz2GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTAyMTEwNjE5MjhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAtTj7jOPM0W6PNlteViWXmnc2SqebZT1vgLWxSKWg cws7/Nd4Krxmw46RsNpu5vg2W3rD2XM6ptAGVpoggFEgWsgXuDVejC9zFP01gxLHHsHsPQAnnVig i4ZscETuLmAe/jORBplXhD0b8bOCCLIenAnHWVA5w248f4xSjtO8IHm1Le5mwCFFqYb80QHca71a Eq0IhZsn34VlXJz4J5vU7/kgdhskDW/5gv+eRMjNG74iVr2h5/N97bElcdoNQEpIzJbwJF5Yha5I p04D5Y5xh3Ke8l+EWYSetz9v3sUMOd9TtzYcMXXQb3/+BN/1pq+YvN/I7FvVjxeoR2fyW9iHEw== --0000000000007f30720581984a37-- From nobody Sun Feb 10 22:28:45 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6A3128B01 for ; Sun, 10 Feb 2019 22:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GneRPWM5KQ0M for ; Sun, 10 Feb 2019 22:28:41 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B4112894E for ; Sun, 10 Feb 2019 22:28:40 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id p17so3811127ywg.0 for ; Sun, 10 Feb 2019 22:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xthFYmGLa+doM7ERA8bvRDI1Nflvvp05Qwt/GoZTdIE=; b=UG7AFb54aE14cD1LsJtB5ShI1zkHVe2wqtlol++tBhrAVvIWV0LCpMNAN7czMFYASZ 1nhuDRDUsen6pmJX+aUQkvuT9aS5sTaTjc61AXiLBZ1MArS1vCITyDyw1dzOJUp5Ijyr I7jsu7vlJuRS20n5FjnNTi5HODHC30jHPaXSVU5kjogZqqbXSQbdGe7qT2KLShiEJFAK GqS92n249vW5FNZOWvmeF7cQkVMFgav0ChHiE1WgMQ5+M01xqeAsZxgWCmRJJCrD5A0/ P1cv5tb3OKy++agCDq8p0XNU8vwknN4a/+yEdV+q2Y+Rz8vZLHFWn1KWrt8bi14Vn4Ke kgDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xthFYmGLa+doM7ERA8bvRDI1Nflvvp05Qwt/GoZTdIE=; b=ITmCpnFtvBxoHzcwlf2xfERDom1TJmB8DdQURiAdcboqVr2MA9nYs2Dvn/nkcBqhsg s1Jp0TLHiVU3bqBcaCQdmFHLNnG6rToUFI3pbp3ai71aetNbDKeXWFG+2V4hRGFKtvSJ LQISrTqGzBeN5KFYwkeOqoxOudxf8acLbYyxlQrc8QTrEqYuD/yb4KH+eXk1uxyPfIkT 2TfpqPDGEkpXRCDb0fMeckmAiDXK34vLJ+Txzm/w939Bma1PUUm9r8VzREZA3/20mjYY 3ibDOxHcYc0eLOLsW3lcP2pNj3aLuvBxyAPsuAWaI8OL+KuTAp/lDJqXzuFI61WqAnL+ nl3Q== X-Gm-Message-State: AHQUAuYoie69W7JlE0F4+dQAtcLX11idLn8Ldm2lS8KxZXQDn/pojX7J 4tSTLr4l8LHCxLocol0ELNusiRhyihAyN0ksJsfRAQ== X-Google-Smtp-Source: AHgI3IZaPh1/vBAKdmutS4rT7enRHNOTFd26RzHroQXxblyLi0QAeU5olKDtJYsaT2IFI6jaKn/nhV8hYVMJzClcbVI= X-Received: by 2002:a81:52d3:: with SMTP id g202mr15567757ywb.244.1549866519214; Sun, 10 Feb 2019 22:28:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Wei Chuang Date: Sun, 10 Feb 2019 22:28:27 -0800 Message-ID: To: John R Levine Cc: bimi@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000005f3cda0581986b93" Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 06:28:44 -0000 --0000000000005f3cda0581986b93 Content-Type: multipart/alternative; boundary="0000000000005427cd0581986b14" --0000000000005427cd0581986b14 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 10, 2019 at 10:19 PM Wei Chuang wrote: > > > On Sun, Feb 10, 2019 at 8:39 PM John R Levine 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 >> 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? > > > 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 >> any CAs that will do the logo attestation? >> > > 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. > > >> 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? > > > 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 > > >> I don't think there's any way for a cert to >> say it's only valid in some countries. >> >> Regards, >> John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for >> Dummies", >> Please consider the environment before reading this e-mail. https://jl.ly >> >> -- >> bimi mailing list >> bimi@ietf.org >> https://www.ietf.org/mailman/listinfo/bimi >> > --0000000000005427cd0581986b14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 10, 2019 at 10:19 PM Wei = Chuang <weihaw@google.com> w= rote:


On Sun, Feb 10, 2019 at 8:39 PM John R Levine= <johnl@taugh.com> wrote:
BI= MI 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?

The proposed validation as documented in the guide= lines (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 d= one for web EV.
=C2=A0
=C2=A0 Are there
any CAs that will do the logo attestation?

<= div>We (Authindicators WG) have been working with Entrust-Datacard on the G= uidelines, and they are willing to do this logo attestation.=C2=A0 We also = are talking with other CAs, and believe that at least one other is willing.= =C2=A0=C2=A0
Logos, like all trademarks, have geographic scope, and it's not rare fo= r a
trademark and logo to belong to one company in, say, the US and a different= one
in Europe.=C2=A0 How will that work?



--0000000000005427cd0581986b14-- --0000000000005f3cda0581986b93 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMWMqzbpn2SydMzpfaMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MTExNTE4NDMwM1oXDTE5MDUx NDE4NDMwM1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDOGIfi32h8dhJEeUGHfN1nAVrJsY4ph3nisYgnB2pOA4hcNkX4 xnnbD7PDr6G2S6LqYfXegzUkLT7FoOGtptBAixwpSxBUvEWQdrlbYdYuoNK7/DBASrlp4J7UocGX ZS5dkWL0IolToc52mCmOxhTqDjbD9MG3+AvyyQPK0RVgNY5n7BZBdNZDHTeswReAtjQ4t+b1IStQ 7Y59jxTOfDPpAT2Y0ON44Lx2hBLyQ8wXYCmHHbWCyGT3xZH0p8p+cGgkKvDjaxBX3ilopH8hx4zm 5HVh6wDOBHhAnRYVU1bqmjohWNuLhz/Za6lWGiylhPD+2yFLQfvHn6OBE0a/048NAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFJUPLExeOaBiYyZVRuorZTtplIumMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBuvV1bxPXhqWWCHYz7 40fvnmDIUsNiLecW3PCDQxdpPMc3V/6T31qSKYvuFigtj2MpXMCkLqbHupVN3b14UvnqNx3jnu7b Yp+rMcjjO70W3ufBqqz/QQzSykR9ATo+Zqs09dhJtTl02ApUqYipoInGx8wu0ChTI84NwR5UUo7H GSOet+Eluj5Yjq0YdM2qzfapP/XbfO7t533yiK5Cs//IlaQagdizrM/b1DTYjJ/28b3uPMS3l6a8 BoWm7kiV6GCY7zBNF9D6Gkf6U4dZgx6SwQjQoG3mSBV1zzIs0cZYoVvq/8y+5jC9CdH1ran/ahb6 1ZtMG4auBaKMRzEe3TimMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMWMqzbpn2 SydMzpfaMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBOCnx0At3bwxRVghs5hbAf xfGDJrRHOhFv5WX33XElzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTAyMTEwNjI4MzlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAa2QnXBr1m10W4IwgdGW6a9s50ja5mDlV4Xw2yemf D8U/gaRrrTtx0YPqLKeuzNUfn1AnJpZ0v8XGXWoxmV7tFI3XsqNmgxuNrCWbj6bPVEE0i56WpsiW t9Yfxq4/T3wiDFoWVPCZ+dnClAFX0inX96lu1eVzuMsofGS9zl0Z+C1lkD/Jcf3am6UKHTW9GZJl YNC2aYgdBB7PMG4n2AoOigwElPG6zMahsdWega2Q7YGccdZpfFhluWHmDP3fZ4tWa2df/wT12Ns/ CuScsDGlpOc30wAwZ6/KvZV7yVJ38tIoRKH4iYA5WHhbfc1EgWu7lSxvHjWfQUGkMoAIFI7iOg== --0000000000005f3cda0581986b93-- From nobody Mon Feb 11 07:22:13 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93762130ECE for ; Mon, 11 Feb 2019 07:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbAxzPgAyzs2 for ; Mon, 11 Feb 2019 07:22:08 -0800 (PST) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83039126F72 for ; Mon, 11 Feb 2019 07:22:08 -0800 (PST) Received: by mail-yw1-xc2c.google.com with SMTP id u205so4333984ywe.1 for ; Mon, 11 Feb 2019 07:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=64ovkspke0Wu7/Dk1mCPlJ5JnWnrkCmqbw4e8/glZSI=; b=dYvVk4a0gPSpE05BRexhkYlwO5JjaZQnVcw/gEkNtywp2nfs6At3VPbWAOPX/9f/DF FSFGuHhls6qNmNaGtiR8XJjtGNJrYRb9S02TOFDrDA4IsHkZHPkKYQU4YhwLBA8aCOjv v6FdGVfjEccgd5ACshtjjEeN/XZ0/h0/d+SMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=64ovkspke0Wu7/Dk1mCPlJ5JnWnrkCmqbw4e8/glZSI=; b=OLagiL1pktc558bA401bLzpMw78XREEN8mI1TEC6ljCnfdxbBxbQb0w1WbytRDh1Dd 6miZSS1juFaFayg80A6dTuDwa31JpieMjUuGAD8oJrRpvUj5qhJOz7/M909ZIRITiC2f MTx1lTh1BzUYgOPQHMvEuD01GIAcWWe2JRNUmwxevQbmDfoSem2liGmolcvvscZ4FYjQ m+BAmLCZCEXrFkWLhFSk/ugyzhIgq3dp7ajBmIaPV57abDCLFu8J6SRvlwJtG4sTtPrW ZobnO2HJwPHZhw3j2KyghungkNw90EQg2yzDjUhDOCeGZqT/1lL3B6B1cLpvXRNYUyKi UVIA== X-Gm-Message-State: AHQUAuaIO+GgvaY+K+MxIu/SovwYR11KSj8roXTAqex0z6bx621bjwbB yIuftEMTbBb3zSPIB5nlYdFSOSFWF6E= X-Google-Smtp-Source: AHgI3IYcEyL+8YKSgYaDlUQsomomF8skcoZjM1qN3GMybVg6yLKQsq6cRHtjsYcR9CpVAKCEhaBvog== X-Received: by 2002:a0d:df52:: with SMTP id i79mr22166354ywe.448.1549898527177; Mon, 11 Feb 2019 07:22:07 -0800 (PST) Received: from [10.0.58.169] ([98.101.39.22]) by smtp.gmail.com with ESMTPSA id h189sm3910714ywd.24.2019.02.11.07.22.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 07:22:06 -0800 (PST) From: Thede Loder Message-Id: <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_242F2F8B-9AB6-43A9-897A-C1FDA241BE27" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 11 Feb 2019 10:22:04 -0500 In-Reply-To: Cc: John R Levine , bimi@ietf.org To: Wei Chuang References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 15:22:12 -0000 --Apple-Mail=_242F2F8B-9AB6-43A9-897A-C1FDA241BE27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. =20 Highlights:=20 * 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=20 * 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. =20 * VM Certs are issued by intermediates which are dedicated to the = issuance of VM Certs, and distinct from TLS intermediates. =20 * 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=20 * 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=20= * 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=20 * latest draft for reference (as Seth referenced previously) is here: = https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcb= ja42w Thede -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: 415-420-8615 > On Feb 11, 2019, at 01:19, Wei Chuang = wrote: >=20 >=20 >=20 > On Sun, Feb 10, 2019 at 8:39 PM John R Levine > wrote: > BIMI appears to assume that senders will have TLS certificates >=20 > 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. > =20 > that include=20 > RFC6170 certificate images, signed by a CA that attests that the image = is a=20 > logo that belongs to the same entity as the domain name in the = certificate. >=20 > Is this supposed to be a DV, EV, or some other kind of certificate? >=20 > 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. > =20 > Are there=20 > any CAs that will do the logo attestation? >=20 > 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. =20 > =20 > Logos, like all trademarks, have geographic scope, and it's not rare = for a=20 > trademark and logo to belong to one company in, say, the US and a = different one=20 > in Europe. How will that work? >=20 > 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. >=20 > -Wei > =20 > I don't think there's any way for a cert to=20 > say it's only valid in some countries. >=20 > Regards, > John Levine, johnl@iecc..com , Primary = Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. = https://jl.ly >=20 > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi = > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi --Apple-Mail=_242F2F8B-9AB6-43A9-897A-C1FDA241BE27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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/10IzxkdrveDazBAvTvOUa9uCIDBw= MkdmluwHEcbja42w


Thede

--
Thede = Loder
Managing Director, Skye Logicworks LLC
M: = 415-420-8615



On Feb 11, 2019, at 01:19, Wei Chuang <weihaw=3D40google.com@dmarc.ietf.org> wrote:



On Sun, Feb 10, 2019 at 8:39 PM John R Levine = <johnl@taugh.com> 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
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?

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
any CAs that will do the logo attestation?

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

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
say it's only valid in some countries.

Regards,
John Levine, johnl@iecc..com, Primary Perpetrator of "The Internet for = Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi
--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi

= --Apple-Mail=_242F2F8B-9AB6-43A9-897A-C1FDA241BE27-- From nobody Mon Feb 11 07:29:13 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A59128B33 for ; Mon, 11 Feb 2019 07:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDgQbJwjMDQa for ; Mon, 11 Feb 2019 07:29:09 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B2B126F72 for ; Mon, 11 Feb 2019 07:29:09 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1BFUUbn013879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 11 Feb 2019 07:30:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1549899030; bh=oxZOZorZKO2c+b0PGgu7rCZjX0xKY+U8FdbFTnIJM4M=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To:From; b=jZlSHfKupmXdLFFfuJVlKtFBPo4dW5Lr4GNXviSz3l2wxaHkdk3McX8KL5gCJVjvZ a6DbymCwbd13570FVbVL4r/DEu2mMzAV4MPXQ/sS92hpjzFHR8hJzQALvzxUMwG4aV KjeO5khhBFcid0t/OxmaaS7gY9LNxN1J7mFRzwX4= Reply-To: dcrocker@bbiw.net To: bimi@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> Date: Mon, 11 Feb 2019 07:29:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Bimi] Forest vs. Trees X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 15:29:12 -0000 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 nobody Mon Feb 11 07:57:34 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0566313104C for ; Mon, 11 Feb 2019 07:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-rJlCmnQMSB for ; Mon, 11 Feb 2019 07:57:29 -0800 (PST) Received: from us-smtp-delivery-213.mimecast.com (us-smtp-delivery-213.mimecast.com [216.205.24.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811C8130E94 for ; Mon, 11 Feb 2019 07:57:29 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2057.outbound.protection.outlook.com [104.47.46.57]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-97-U2VkJoMeOfGSPsJju-zFgA-1; Mon, 11 Feb 2019 10:57:24 -0500 X-MC-Unique: U2VkJoMeOfGSPsJju-zFgA-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F6pi1+AgCC+0By9kBG8B3xvl+yu0X0XugrdZLmR/1VU=; b=qqIoFDr+JbigiWv/vowrjGAT+LReJxEe9dvhVC3jkFJksl0CkSuh6ERfF4u1w+nsq9hACPb+lmrML51yaf11XSH1aFfHJQMbc2/sR9M3PAay6UjZTyIQ1M+n3gY0hdvMdUwpKq5uyST1qBLdPdp8/VcWbKuOlFJS+pJVMph2X1M= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1235.namprd14.prod.outlook.com (10.173.162.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Mon, 11 Feb 2019 15:57:22 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0%10]) with mapi id 15.20.1601.023; Mon, 11 Feb 2019 15:57:22 +0000 From: Tim Hollebeek To: Wei Chuang , John R Levine CC: "bimi@ietf.org" Thread-Topic: [Bimi] Where do the signed certificates come from? Thread-Index: AQHUwcPDIln3LKRcvUqlBYc02R5uuqXaH+SAgAChL5A= Date: Mon, 11 Feb 2019 15:57:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1235; 20:Pji6ktwhBRSE11kEh0dlwnQ3/g1F2JL67ZS0RlNFgw8M7dK4D32uyjdZSA/VJGlA5D72SXdMaYnRBqCxpOJGsqUmr2cXr0FHYRROgk3p5JrdJ6/7+0uxITkduFQwfmsgId139kKscLIaQoTrrttpXwgrC+lKYpo+9gtRfW29T0A= x-ms-office365-filtering-correlation-id: 49d0ba34-c3a0-461e-8765-08d690399c2a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1235; x-ms-traffictypediagnostic: BN6PR14MB1235: x-microsoft-antispam-prvs: x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(396003)(376002)(346002)(136003)(189003)(199004)(446003)(11346002)(25786009)(7696005)(478600001)(14454004)(71200400001)(6436002)(4326008)(44832011)(71190400001)(229853002)(74316002)(486006)(86362001)(102836004)(99286004)(6506007)(4744005)(7736002)(81166006)(68736007)(110136005)(53936002)(2906002)(66066001)(99936001)(8676002)(256004)(81156014)(8936002)(316002)(106356001)(9686003)(6116002)(97736004)(33656002)(76176011)(476003)(790700001)(3846002)(55016002)(54896002)(6306002)(26005)(6246003)(186003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1235; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6szF9pnmy82z01e/WjY8IG0F/9tOFlwkyY6nd4bhLbUm8Sgfluer+6tg89qFlsBsWE8CobfnqQFnTLpOPFgChZFpJb5lJGMVbUbEpay3b/l3Q+Fb9WrXlZEm+2s3R5z01ptD0OI/0CT/jvsX57RHh1BdSjDlrSICStL+NitTtDrDRow3omtDs2UW2yK0LQ2aZKG2Rl+jrCjxHHa4xDHyReaTPoxYNza0ny9Ha+dnSXsoAKgGxVV5hMTKrG42uwPI/MujqGOe6TcHZPBi8CLvOX+2YM+FY3ik97EkhoLFhqFU770pnb3si2BitdGD8pXEvKJR0ssk/IZm5ApCN23f4o48tmovZT5mfUD1hKTFQMLX3bSjZ1jXAB7z40GJgrnnODBib9M8W74dwUnDNqr3VdDP9kF1Q2ZCzI5hLYDyjmg= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00B5_01D4C1F8.8F9AE410" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49d0ba34-c3a0-461e-8765-08d690399c2a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2019 15:57:22.5380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1235 Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 15:57:33 -0000 ------=_NextPart_000_00B5_01D4C1F8.8F9AE410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B6_01D4C1F8.8F9AE410" ------=_NextPart_001_00B6_01D4C1F8.8F9AE410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit DigiCert is willing to offer these certificates, and is also willing to run a Certificate Transparency log for the ecosystem. -Tim Are there any CAs that will do the logo attestation? 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. ------=_NextPart_001_00B6_01D4C1F8.8F9AE410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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

 

-Tim

 

  = Are there
any CAs that will do the logo = attestation?

 

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.  

<= /html> ------=_NextPart_001_00B6_01D4C1F8.8F9AE410-- ------=_NextPart_000_00B5_01D4C1F8.8F9AE410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwMjExMTU1NzIwWjAvBgkqhkiG9w0BCQQxIgQgLrN/Upg+XqiZJfss15lXRRyAYDpk x2Ugl5eHeo3o6PowgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAJp5mZAWWACpIlBp7d3smIaAxNqXVNn+uZDZp7UZk8Dg+P+8obcyFbMEP2ikBWxS/3X2hzRt igE4LXi2+CgM1dLMVMrgrxYm8KkUK8y9UrX644noYsMZ0yNQkV/cBLi6lVqJJaGBakcAW8X/rVW0 p/78tj+8C24HGINtaT8Phk2ksLiFDclOkU9MGhX2ZTs1vvwPm5HnkrArWBdYy/kFMg+oJSzc5pH5 0oNvh0AW1W/wrNuWyJsvo0fFH3rbJmtL3Icm8zC17GU/RTeTvqIC8+grKMvUiosWPK0AWZbFcY/4 Z6DrhA0r4DAsEc/OpQOwYTU4Ui53H2zM5oXZlkpKRogAAAAAAAA= ------=_NextPart_000_00B5_01D4C1F8.8F9AE410-- From nobody Mon Feb 11 08:22:24 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7513106D for ; Mon, 11 Feb 2019 08:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR3BHDz3yD4H for ; Mon, 11 Feb 2019 08:22:19 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B4C130E91 for ; Mon, 11 Feb 2019 08:22:19 -0800 (PST) Received: from localhost ([127.0.0.1]:42446 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1gtELZ-00093Q-G4 for bimi@ietf.org; Mon, 11 Feb 2019 16:22:17 +0000 Message-ID: Date: Mon, 11 Feb 2019 16:20:51 +0000 To: bimi@ietf.org From: Richard Clayton References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:22:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message , John R Levine 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 >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. "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 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGGg4zu8z1Kouez7EQKnPgCgqhnIJ2Zzztq2TvFtCmrGCBnpS4AAn2ka ctRwQYXPyUJWtT/PuuE95Ska =2GUx -----END PGP SIGNATURE----- From nobody Mon Feb 11 08:29:56 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F255C1310BA for ; Mon, 11 Feb 2019 08:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9wMeCkFXANf for ; Mon, 11 Feb 2019 08:29:44 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353631310B4 for ; Mon, 11 Feb 2019 08:29:44 -0800 (PST) Received: from localhost ([127.0.0.1]:24799 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1gtESk-00094S-Nd for bimi@ietf.org; Mon, 11 Feb 2019 16:29:42 +0000 Message-ID: Date: Mon, 11 Feb 2019 16:28:28 +0000 To: bimi@ietf.org From: Richard Clayton References: <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com> In-Reply-To: <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:29:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com>, Thede Loder 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 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGGirDu8z1Kouez7EQJoQQCgq+wmpP2M+wmQMfhV8O/Jucot2DIAoNcQ 8xtHxqGIAs0/eEcVNt+68BNc =uTcI -----END PGP SIGNATURE----- From nobody Mon Feb 11 08:46:03 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8314413109F for ; Mon, 11 Feb 2019 08:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muKQR5UlmKou for ; Mon, 11 Feb 2019 08:45:51 -0800 (PST) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC8B1310C9 for ; Mon, 11 Feb 2019 08:45:51 -0800 (PST) Received: by mail-yw1-xc34.google.com with SMTP id u200so4425585ywu.10 for ; Mon, 11 Feb 2019 08:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fT0uMhgzGhK6NQdkqzRKwQE8pKCPcaojEV6pH9mdhtU=; b=oimHyuK7Q8lAO0zgt4QaLU8dsbuJGL/xKmf/yXNq0+wWCppZxKH5y7idQ2ozxec7fg Eck352Bm9Sf1psDR8GDhOqm+NWPSlsZefDiBXAdsMBn0YkLcR4per6V1wfXbmV4y9yHH 0msZKY40Mm+LXlygodyqWjizyCI47PvdH9Sjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fT0uMhgzGhK6NQdkqzRKwQE8pKCPcaojEV6pH9mdhtU=; b=SXbPA5wIo3D4iU9yteU42dEyquxeck+HG/t0b+GXmzRYkB1eFCKg96sCqe4Gh8WYmT ss1e3Qr9/qjPFYOvSUYSLkUPpNqqyw9QUXWqGD90X8vYyw56ieWMInoEjjavIRljzOoA YMjxogKZDgdjAxSgwfeH5zWQC0m52eakqEozvyhPXQVi/owDqvt62vDIV7IFlWPUNtFu Fz2HoXf3zuN9dxHwFWmmmIVGRU6nEGQpCzUK7ECXardSnMGma4ZdKuUqDxnkphEKHWqI xDxBa0CRvNbfl3RD5M3E8kc2gSg9yDD/7byyYuZcYQ84Hg1ZNmjqt6RjSDJNuXg2B06u yiXA== X-Gm-Message-State: AHQUAuYc4MtjdZUEPQkZxvs2FOykb63WwQlmqql2EQBNP6w8I7n/RQdR 5zoM1yhK72dxYm/I0YQOGf+cERESpuk= X-Google-Smtp-Source: AHgI3IZr7wpGatIv7yY6Q1BpYvkr/Q9r/Z2MzHHrjNtpKsaBxZ5Sk4H+jIrshaaG4dCXdKBBWNY9Gw== X-Received: by 2002:a81:6b54:: with SMTP id g81mr8861387ywc.232.1549903550423; Mon, 11 Feb 2019 08:45:50 -0800 (PST) Received: from [10.0.58.169] ([98.101.39.22]) by smtp.gmail.com with ESMTPSA id v134sm4038399ywv.90.2019.02.11.08.45.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 08:45:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: Date: Mon, 11 Feb 2019 11:45:48 -0500 Cc: bimi@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <822765FD-CD17-4FF2-B7E8-89FC34D294EE@skyelogicworks.com> References: <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com> To: Richard Clayton X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:46:02 -0000 > On Feb 11, 2019, at 11:28, Richard Clayton = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In message <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com>, > Thede Loder writes >=20 >> * Verified Mark Certificates are designed to be compatible with=20 >> BIMI's publishing and discovery mechanisms and anticipated uses=20 >> with email, OATH, and social media. >=20 > should I translate OATH to MAGY (Microsoft, AOL, Google, Yahoo) or > should I translate it to "Verizon Media" ??? Ooops, typo. Sorry, I mean OAUTH, the multi-party authentication = mechanism, not the media company. =20 Thede From nobody Mon Feb 11 09:13:51 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F141310E7 for ; Mon, 11 Feb 2019 09:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2On1ArWIqVh3 for ; Mon, 11 Feb 2019 09:13:40 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E131310D3 for ; Mon, 11 Feb 2019 09:13:40 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id n71so4180446ota.10 for ; Mon, 11 Feb 2019 09:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=I9+5B4J6z+czBicu8QXisduPAP8E2b8sJ8cEaZAqJjs=; b=ukU/UUv/bw4ImFslzUn9Xi5CxUTagfIQP4hF2crS0eVWqAfgRD0KzRpIV5RSJuT95h yQsYB44QOvTFFR+fXsHo32VU+Rn9apDqLv/ZNkNRWyGcvfczyKVah0bGd18ia7MxXksR tC5NdnypaPpU25F8MVj4H6WNtgzxUCkWFYkR7aXmeqrgMF5bxk1ovblrco9Es34Oumyk vlojghntzsyvh1lufVTMRlZohyj/Hb26wK0NKURzOulF7aj3DG0XLVgBj3dDWRNDHDA/ E3Y0GWYe7ERtmxOtOsM9lrwfjbgRs4YsSvAXZK3cIhoA3jSm/4VTkHZ0fiWUo2lRB5y/ PjTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=I9+5B4J6z+czBicu8QXisduPAP8E2b8sJ8cEaZAqJjs=; b=gdMbB/aWg6E+1VMLw2g/plE0rqT8yPlea8rBjTJ/HjQCz1u26dZpEyKebUCuHImNXG zBdL8LJmt/EVKCKyktbECjd3tiqeQnuBA4XUjVyPFG78GIHlvUcl3P66Tk9qCtrQ4rUq YURfT5taMKJMmztjHtpTBXNTEUC7eRvdQ6LNPWOgN5Vbm7Rs+2HZgk4s/atIX6c7eGh6 zDmcgnuYxg4egTyz/Mzr+m3YhyCTsw2WeLqOcPXEdmRWZFX4JAUEORZAkWS6EBNMkSrh yDFE020sRhPD1fssnzJYkGstebLy3Ic+3vIYhogyI5F6+JptAVT0p8wISl9Ih++AIduf niNw== X-Gm-Message-State: AHQUAubYCp9+tP+J96zuQdBjW0v3ILrQerENR1XmtLXuLLR/ecwaDFEs auZqhS7A7B7WbFpDmYnLPxwZbpD7pVoVLMscZs8XcyVOaRs= X-Google-Smtp-Source: AHgI3IZhnm30zIxRetS9127j6xTzA8hJQgzQLyNCQkUqoNTtNIXa3v878isTOc0eh+zfKTfUyi7Wa/RFl0m4XwYEMXs= X-Received: by 2002:a9d:d83:: with SMTP id 3mr27218033ots.361.1549905218748; Mon, 11 Feb 2019 09:13:38 -0800 (PST) MIME-Version: 1.0 References: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> In-Reply-To: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> From: Seth Blank Date: Mon, 11 Feb 2019 09:13:12 -0800 Message-ID: To: bimi@ietf.org Content-Type: multipart/alternative; boundary="000000000000ffdc890581a16d0d" Archived-At: Subject: Re: [Bimi] Forest vs. Trees X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 17:13:49 -0000 --000000000000ffdc890581a16d0d Content-Type: text/plain; charset="UTF-8" On Mon, Feb 11, 2019 at 7:29 AM Dave Crocker wrote: > 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. 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 --000000000000ffdc890581a16d0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 11, 2019 at 7:29 AM Dave Croc= ker <dhc@dcrocker.net> wrote:=
For all of the text that has been submitted, what is first need= ed 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.

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

<= /div>
We also have two older documents that we were planning on cleanin= g up and releasing as informational I-Ds around security concerns and threa= t 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
--000000000000ffdc890581a16d0d-- From nobody Mon Feb 11 09:23:21 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1A1310C4 for ; Mon, 11 Feb 2019 09:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP7I5IYngHYJ for ; Mon, 11 Feb 2019 09:23:18 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AB51310A8 for ; Mon, 11 Feb 2019 09:23:18 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1BHOdQ1022736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Feb 2019 09:24:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1549905879; bh=z8fgqhEwqMZwM7G7El0ali0Z5Ri+hfrjjJILOqfuOkU=; h=Reply-To:Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kBxXKjisetkiAIKX3TrdcUSfx4eW38S0D6Yay9YfHpJdagTYgY1LH07TlC++UlX/K C/tiow1EGorG5Cf3lRw2+pv1X8ykcp4J12q2/RFhrljFqUgASCQMN5m7hM+ipweV53 Qi3SmR9joMPLAHfPbVdEeyKNxH2uNASdwn3v/fPE= Reply-To: dcrocker@bbiw.net To: Seth Blank References: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> Cc: bimi@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 11 Feb 2019 09:23:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] Forest vs. Trees X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 17:23:19 -0000 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/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 11 10:46:02 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D6313111B for ; Mon, 11 Feb 2019 10:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wasv2qRY2ApP for ; Mon, 11 Feb 2019 10:45:58 -0800 (PST) Received: from mail-yb1-xb43.google.com (mail-yb1-xb43.google.com [IPv6:2607:f8b0:4864:20::b43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF6F13111D for ; Mon, 11 Feb 2019 10:45:57 -0800 (PST) Received: by mail-yb1-xb43.google.com with SMTP id o81so4589071yba.8 for ; Mon, 11 Feb 2019 10:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=akH/eT1QjsnAPHcTIOPDfDEss589y2uBQVZ/iHlXI4A=; b=nBQIpiI8ApmpvBv8a51qrnokDVGeSW5ENl26I7rJ66zEcZ+YDIDR1GRg4nmo9SW9Po MOels784vAreftBefqCIw4axEoxo75vOmd/sMa0SgmdiAw2suhOlT3yT6CCq1ng34hZz 5QXlK8u8VgCQ+BSa6swG7jlc0aKrWvSf2+zmY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=akH/eT1QjsnAPHcTIOPDfDEss589y2uBQVZ/iHlXI4A=; b=uHRLo6hjKFp37ARHxMfzW+wWp7MJ5TIDRyAqhCkQ9ZFEsfAyIe3CSqOkIZaYXtMNe7 S4yDya97D2pHUaTbenLRD1/+PTMg/RST5VKppky/MMyadOwf+SRWDF/vGt6amGSJIh1I RiselxBwlXRShgKwU4LuvRHgvSjHn4guDpBpqz5ZqA26qoHYAoavMaNT9KGfob66g/Oh 3A6vZrVItJ5I0DjNIkwkjsseH6XTKBpOZzKlz1ZO35HdqoUEIuN0JN+uDAi7bdbStpN4 81SHKlZyvEZdJjlcIwnwLIHt8PBJFi5nGTFYcp62IAoU4/UN+w7PzfB05Y65MXIrjpjs LLHA== X-Gm-Message-State: AHQUAuabkFm39swhCEk9TLmK3Zm+nrB9iBevjwtEb9dbH7wev3xv+p1l 1jbA+GmD7FKBpCkMyNQpiFuuW42G/W4= X-Google-Smtp-Source: AHgI3IZNsX8gwZFAi5AVd1NqTdWrvinr3C42v8EnuWC9+LkeS/gFwnadz5aMYUVEm8U43DZESl60tQ== X-Received: by 2002:a25:8e11:: with SMTP id p17mr30295506ybl.39.1549910756980; Mon, 11 Feb 2019 10:45:56 -0800 (PST) Received: from ?IPv6:2620::690:7822:a961:9d1f:14e4:49a? ([2620:0:690:7822:a961:9d1f:14e4:49a]) by smtp.gmail.com with ESMTPSA id g193sm4776246ywh.57.2019.02.11.10.45.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 10:45:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: Date: Mon, 11 Feb 2019 13:45:55 -0500 Cc: bimi@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4810C1BE-780D-49C7-A149-76E07B30A663@skyelogicworks.com> References: <63B39236-831C-4FF2-BAC1-5FF024A54381@skyelogicworks.com> To: Richard Clayton X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 18:46:01 -0000 > On Feb 11, 2019, at 11:28, Richard Clayton = wrote: >=20 >> * we anticipate that some 'Consuming Entities' (parties offering=20 >> services which partially or heavily rely upon VM Certificates) will=20= >> operate their own VM Certificate "root programs". These are=20 >> analogous to TLS "root programs" >=20 > 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?) A model for a =E2=80=9Croot program=E2=80=9D 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=E2=80=99s approved certificates and practices = for all to see. =E2=80=9Croot program=E2=80=9D 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. =20 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. =20 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) =E2=80=9Croot = program=E2=80=9D operators would accept cash like this, and it would be = unfortunate if they did. There=E2=80=99s nothing currently in the = specifications aimed at preventing issuers from trying it. Ideas = welcome! =20 One thought: require the public auditors to audit the financials of the = CA during WebTrust audits, explicitly prohibit payments, in-kind or = otherwise. =20 >=20 > 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 It=E2=80=99s 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. =20 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", =E2=80=9Croot = operators=E2=80=9D 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.=20 >=20 >> * VM Certs require f2f verification, subject to a sunset provision=20= >=20 > face-to-face never works well in the dark Hahaha, indeed! =20 Here=E2=80=99s language specific to f2f:=20 "6.1.1 Face-to-Face Validation of Applicant Representative=20 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 >=20 > - --=20 > richard Richard = Clayton >=20 > Those who would give up essential Liberty, to purchase a little = temporary=20 > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov = 1755 >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 >=20 > iQA/AwUBXGGirDu8z1Kouez7EQJoQQCgq+wmpP2M+wmQMfhV8O/Jucot2DIAoNcQ > 8xtHxqGIAs0/eEcVNt+68BNc > =3DuTcI > -----END PGP SIGNATURE----- >=20 > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi From nobody Mon Feb 11 13:15:13 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58981126C15 for ; Mon, 11 Feb 2019 13:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGgkncdhqQT2 for ; Mon, 11 Feb 2019 13:15:11 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D92126D00 for ; Mon, 11 Feb 2019 13:15:11 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1BLGHcq013344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Feb 2019 13:16:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1549919778; bh=aHqyx6DsE+ENHUwDPf1R2Vty60MfUVZc2gd5k1vetf4=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WQsodurBU6XUuemz5igfN5jMLEAaTAnb5mc6bFEftLXB8ib++LCDu4eyZ8q8ZmLso 8/YlrqliaNDbn5Xl5rUlipg8cApSedSy89Ty1B8oWxEFi4tmCJGsFioqsJDY8V3Ogd Ifkl06WypqIItkVJWyFAV+JUk7jU1OpFvtp1tfF0= Reply-To: dcrocker@bbiw.net To: Tim Hollebeek , Wei Chuang , John R Levine Cc: "bimi@ietf.org" References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> Date: Mon, 11 Feb 2019 13:14:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 21:15:12 -0000 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 > any CAs that will do the logo attestation? > > 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. 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/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 11 13:35:48 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FAE126D00 for ; Mon, 11 Feb 2019 13:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtxAY1139n1B for ; Mon, 11 Feb 2019 13:35:42 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FDB126C01 for ; Mon, 11 Feb 2019 13:35:41 -0800 (PST) Received: from localhost ([127.0.0.1]:13839 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1gtJEn-000AN2-MT for bimi@ietf.org; Mon, 11 Feb 2019 21:35:37 +0000 Message-ID: Date: Mon, 11 Feb 2019 21:34:00 +0000 To: "bimi@ietf.org" From: Richard Clayton References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> In-Reply-To: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 21:35:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net>, Dave Crocker writes >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. 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 >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. 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 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGHqSDu8z1Kouez7EQIPuACguJYI2Q31iDjs8ICwSL79VcZJn/gAn0Yu dVAplSLnqpu9KAmtCeXSJ52z =Pgvo -----END PGP SIGNATURE----- From nobody Wed Feb 13 08:13:59 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37236130E6E for ; Wed, 13 Feb 2019 08:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cVTntjPdrG0 for ; Wed, 13 Feb 2019 08:13:56 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E73130E8C for ; Wed, 13 Feb 2019 08:13:53 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id v10so3159022qtp.8 for ; Wed, 13 Feb 2019 08:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=RYENjLMhKHbCDuJ1cMloBDHFajLd+xd7nVwN1392crY=; b=kcRkIpRFXeMmjVCkKxkmBkFkRDlYmIV6w7UFeGUxzU2XCT1ooTd/I8SLLJvKWa+Cc8 q3aSv9TSlJJbYC9V663k1KtDbXXCqx3NvPeAl8OYwYkH0bLiKnyhUB8pJlI8JPY92Bom 6Xv7n3IQPHuMOkvZfbclPjDZZLUAdtNNHsMPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=RYENjLMhKHbCDuJ1cMloBDHFajLd+xd7nVwN1392crY=; b=EE0VZtku/QK48kciGCFqGRgVYdA9ZYCGqvnLOKWSBjgzdID9NeiFDHjSnPOWpuzaPX 9fCvBRSdTTa6ED7BMt0AFFJWhUfFyt2KRtlGb6XM0wK2ZLhv8zG49FQNoDMEr5QPU34W l94PmhHnp5yn/JlJkCagy9GxOCxmQ9GfzWrP/IcFqr7sqjGbgYC2X3a2nw/7lnSC5Qlz u4nLcWObossbuPNMFigC9S4jBrIOER4WvTybScm0uK7I84/uksj0CBnwUNu8HR+TGqH4 kzE45tNrVfELsfSSflGzQ19NtAcEoJ0qMFheAoNUQvfYfDjlnb8oZid+ONqZec9Kd3in nzzQ== X-Gm-Message-State: AHQUAuZqvQHpNBZrfGZKkxrQHJXd+DMkOup/Wzt7HE+uzzkR/MxXI+H6 4QSLZLG+pQBQ5EAqGcZEQGoDxgd+xfI= X-Google-Smtp-Source: AHgI3IaANKUXo52VC1YAvISz1nBbCN3jImeeebCCXUoDI8te/v3Q6mo2OcyjwFyf012+tq0wOfLLvw== X-Received: by 2002:aed:2044:: with SMTP id 62mr1036977qta.11.1550074432525; Wed, 13 Feb 2019 08:13:52 -0800 (PST) Received: from [10.255.209.194] (cpe-107-15-57-63.nc.res.rr.com. [107.15.57.63]) by smtp.gmail.com with ESMTPSA id z63sm17838748qkc.42.2019.02.13.08.13.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 08:13:51 -0800 (PST) From: Thede Loder Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 13 Feb 2019 11:13:50 -0500 References: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> To: Dave Crocker , bimi@ietf.org In-Reply-To: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Forest vs. Trees X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:13:58 -0000 Comments below.=20 > On Feb 11, 2019, at 10:29, Dave Crocker wrote: >=20 > Folks, >=20 > 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. >=20 ...=20 >=20 > 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.=20 -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com L: https://www.linkedin.com/in/thede=20 M: 415-420-8615 From nobody Wed Feb 13 08:29:56 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0398B126F72 for ; Wed, 13 Feb 2019 08:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0laawvS2qTy3 for ; Wed, 13 Feb 2019 08:29:53 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A3B1275F3 for ; Wed, 13 Feb 2019 08:29:51 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1DGVCla027142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Feb 2019 08:31:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550075473; bh=80WhXUSrs2lwUzQ3kKDqRJ5afju3gNJwswlRK+nUy10=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=M6qNsSSGx6TWy9tWaKpVt6+IAIWYaQ+DiGbK4CfjVU+edfjspJxRSDpSM01nP3UN5 9TJ8IdgT7EHluJzIGNFbmhj/OhK9c7fvgcRdKaU/zPYNWAqsxhriDmuQBQ9XNpC/TX xud9erlfPk9IEsR4ztvLwKz+Yz6DZ0uRjwcF3c/k= To: Thede Loder References: <5f0a62d9-b7c4-e6e0-7823-3723aa5cba32@dcrocker.net> Cc: bimi@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <54536bb4-28b6-1a66-6df9-a35586176324@dcrocker.net> Date: Wed, 13 Feb 2019 08:29:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] Forest vs. Trees X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:29:55 -0000 On 2/13/2019 8:13 AM, Thede Loder wrote: >> 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, 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/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Feb 13 08:39:08 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A871310BE for ; Wed, 13 Feb 2019 08:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJQx-bDN3mWz for ; Wed, 13 Feb 2019 08:38:57 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8F1131058 for ; Wed, 13 Feb 2019 08:38:57 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id w204so1734878qka.2 for ; Wed, 13 Feb 2019 08:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=92q2ADY6fms/mqgKWPXApm9g3KTuPuNEQmwM7UDnhJs=; b=o00E88u/idqOCOU4zyqZo963Bu6rbvk3lMVcuIEtra/UROFiyB8/aHxowb9Y1DhHnU Yu698aYVYL+/uqpmC867JVxZhwv2puRs42zY2iWXOIXMHo4VXPKQQZ7TOgPicUKGc3Ui UKdfHrldrA6B9OyN0fFfoyFcPYVg5pmAvqt9k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=92q2ADY6fms/mqgKWPXApm9g3KTuPuNEQmwM7UDnhJs=; b=DkuDxmMjehwaZNp/ngfaJT/RJKdYRsndYYAfPD3Q525KtBCmcKdX9PI+wZJ19mkuCv +7JZh4vnTr7ArIXoQeeHHw0/GQDyyifJMdnTX+B70lrIcbqys1+V1z+wa4M4IbJWm10Q PhwWN4Tcpsc2WDw9N0CPEkqJUguYnm8ZZfmjST3fWT3ijMHLHd0x0d4JD+WX1kzdDlB2 mhmAE4B2aoCJBs3v9n7f0WbQe9ejwijl4IrG7HN8dTxLYVCaYI6+ErNTlwIkMm0smPdt lxyHl8v/yMnoYC+czROU5Nilu32iNMF4C5KSK9N7iOw42PHNP7MPDxtOXFZAfXUut423 Fzug== X-Gm-Message-State: AHQUAubSfy/zk3UeMpTk5w9QR8Qcjg2w92xoIKQmPw1pgY0rlR34dVK1 AO388RTuy0XX859nJVrD76Lxlw== X-Google-Smtp-Source: AHgI3IbbgGbe+Feqk/gClbcxmAlZ4/eichBF7pyBVXRXNoe7gU5FJPnYLIXRvA7lEIOjWnYsImFMRg== X-Received: by 2002:a05:620a:109b:: with SMTP id g27mr1066157qkk.128.1550075935855; Wed, 13 Feb 2019 08:38:55 -0800 (PST) Received: from [10.255.209.194] (cpe-107-15-57-63.nc.res.rr.com. [107.15.57.63]) by smtp.gmail.com with ESMTPSA id l16sm12830870qke.20.2019.02.13.08.38.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 08:38:55 -0800 (PST) From: Thede Loder Message-Id: <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A8F09B4C-B7D2-4B23-A810-62795271B160" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 13 Feb 2019 11:38:53 -0500 In-Reply-To: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> Cc: Tim Hollebeek , Wei Chuang , John R Levine , "bimi@ietf.org" To: Dave Crocker References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 16:39:07 -0000 --Apple-Mail=_A8F09B4C-B7D2-4B23-A810-62795271B160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com L: https://www.linkedin.com/in/thede M: 415-420-8615 > On Feb 11, 2019, at 16:14, Dave Crocker wrote: >=20 > 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 >> any CAs that will do the logo attestation? >> 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. >=20 >=20 > Different question: >=20 > What is the basis for thinking that this will work? At scale? Some reasons in favor of scale:=20 * 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. =20 * TLS certificates are well known to individuals and organizations large = and small. They didn't even exist 30 years ago. =20 * 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)=20 * DNS scales (or we have bigger problems)=20 * Internet users want it - clear demand=20 * there is no "rocket science" involved; the formats, process and = supporting technology are straightforward extentions and analogous to = what is already in practice today=20 * authentication schemes necessary for safe use a primary anticipated = application having 2 billion users is already widely supported=20 * 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=20 * See also Verfied Mark Certificate Guidelines, as previously posted to = the list (for convenience, again here: = https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcb= ja42w/edit)=20 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. =20 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. =20 Thede >=20 > Certs have been around for a very long time and were even originally = intended to do this sort of thing. >=20 > 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. >=20 > 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. >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi --Apple-Mail=_A8F09B4C-B7D2-4B23-A810-62795271B160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
--
Thede Loder
Managing = Director, Skye Logicworks LLC
M: 415-420-8615




On Feb 11, 2019, at 16:14, Dave Crocker <dhc@dcrocker.net> = wrote:

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
=    any CAs that will do the logo attestation?
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.


Different question:

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

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/10IzxkdrveDazBAvTvOUa9uCIDBw= MkdmluwHEcbja42w/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
Brandenburg InternetWorking
bbiw.net

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi

= --Apple-Mail=_A8F09B4C-B7D2-4B23-A810-62795271B160-- From nobody Wed Feb 13 10:22:40 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE291200B3 for ; Wed, 13 Feb 2019 10:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIN_Tp5B94-9 for ; Wed, 13 Feb 2019 10:22:36 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BED128766 for ; Wed, 13 Feb 2019 10:22:36 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1DINmCI003756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Feb 2019 10:23:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550082229; bh=ycF6povxdVRpzBXQuVEX2lVTCBMRqM5bYIalm/oEjV4=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=pVuEm6aMrdIYXomSs0p3+rJVQHumHyYnHlnCydMx9RYu6JeHfl4JjtEKHrqk2G89j JZiY1hif7UNv4C5sxcFM61tCUm9j8dsYfIxLvRWa5VDKOOgQAwPAF83bdN1v3/hQrj 6iRB3cCV/8Cd7/ikXQVPcJWXF8wiE2QqeuEG3WJ4= To: Thede Loder Cc: Wei Chuang , "bimi@ietf.org" , John R Levine , Tim Hollebeek References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 13 Feb 2019 10:22:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:22:39 -0000 Thede, On 2/13/2019 8:38 AM, Thede Loder wrote: >> On Feb 11, 2019, at 16:14, Dave Crocker >     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. 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 -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Feb 13 11:53:23 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A52C128B01 for ; Wed, 13 Feb 2019 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o0EUMXp9WEl for ; Wed, 13 Feb 2019 11:53:18 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC89F1200B3 for ; Wed, 13 Feb 2019 11:53:17 -0800 (PST) Received: from localhost ([127.0.0.1]:15516 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1gu0ap-00007E-7p for bimi@ietf.org; Wed, 13 Feb 2019 19:53:15 +0000 Message-ID: <1hVuuyBcVHZcFAmv@highwayman.com> Date: Wed, 13 Feb 2019 19:51:56 +0000 To: "bimi@ietf.org" From: Richard Clayton References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 19:53:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message , Dave Crocker 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 >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.) .. 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. >> 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. 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. >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.) 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") >> * Internet users want it - clear demand > >That claim keeps being made but I've never seen any serious >documentation for it. Marketing people want it -- that may not be documented but I have sufficient anecdotes to hand to believe it be the main driver here. >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. 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 ?? >> * 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. 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. >> * 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 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 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGR1Wzu8z1Kouez7EQJg3gCfXjhWf+O2uXq0yIdeJ3s+jChYn8sAmwb3 wer3de7TQB3odl4wYGxiUrb2 =agVd -----END PGP SIGNATURE----- From nobody Wed Feb 13 13:35:17 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82C3131041 for ; Wed, 13 Feb 2019 13:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUdNRF74fKvt for ; Wed, 13 Feb 2019 13:35:05 -0800 (PST) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE0313109B for ; Wed, 13 Feb 2019 13:35:05 -0800 (PST) Received: by mail-yb1-xb33.google.com with SMTP id e131so1528528ybh.12 for ; Wed, 13 Feb 2019 13:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FVCyW23D2R5SpN/74pBVB8RyedkcMHDwLfabCbLjpSk=; b=saXCraz0HqxVllg+oqWDd3nLn5ezyUhIcamHm1K2lb4uNHRLNuQkzmQ45wY8OAN/8K KbW1Uppaj8qoTL4zGxAkH+exjC5caoqOEiS7W1We2JokIpeeA2paCxU0pgKA9uBBEyLg kPs4RuoA2UcoZt0VlX6ORQAcdazeQ4ZiREAZI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FVCyW23D2R5SpN/74pBVB8RyedkcMHDwLfabCbLjpSk=; b=hIH8/PMTbJBX5/HN8SJDZuJGqdAbTyRBvpiTSr/5bTqL3Q74mFbpNRWbayeeAZUz+T zdy8IEoUV2c+30bpVHRHZzTYdvwP3ZlnyEraU8tQ3Lh8jQvsurdSpUv5Fp4d8pT9Zj9f IEcepdOEPtdYju+n/pNZag+fXpPR/uvjkAk+mEqalhe+vt/N/hgwIP1FqDcOxGwi4lMQ J9Fvs8KNo10jGUbbjPateup7qw0Hg4n1egEiKgVnkTM2a2v0al0DGx9RHS/lm2DoDJcZ C7PyO++8bAnj+s8ONzNRuVEzezgWLG3l2THhiLfNd8SkqrlCmMqPckMq4SGIdHGQEYDa V3Sw== X-Gm-Message-State: AHQUAub8RlCSn7S17PusQ7yGp+EIm4Ahfiv0Z6bikXfy3OiLpFbbswW+ qTvuYjnQ52tacTdr7cjyvtm6DJDl45M= X-Google-Smtp-Source: AHgI3IYD4P3VNdo5VteTlts8YIKF2xq47h4FUaEoDVi4jwxo2tIC52Cg4a36oLoUhDaRKC46lXjBXA== X-Received: by 2002:a5b:946:: with SMTP id x6mr204125ybq.467.1550093704356; Wed, 13 Feb 2019 13:35:04 -0800 (PST) Received: from ?IPv6:2620::690:7822:7c7b:73d5:3644:57c5? ([2620:0:690:7822:7c7b:73d5:3644:57c5]) by smtp.gmail.com with ESMTPSA id c67sm153727ywe.51.2019.02.13.13.35.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 13:35:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: Date: Wed, 13 Feb 2019 16:35:02 -0500 Cc: "bimi@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <70D6685C-CE6A-40AC-BC08-1E4041D21BD8@skyelogicworks.com> References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> To: Richard Clayton X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 21:35:16 -0000 Hi Richard,=20 On Feb 11, 2019, at 16:34, Richard Clayton = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In message <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net>, Dave > Crocker writes >=20 >> Different question: >>=20 >> What is the basis for thinking that this will work? At scale? >>=20 >> Certs have been around for a very long time and were even originally=20= >> intended to do this sort of thing. >>=20 >> More than t h r e e d e c a d e s on -- certs date back to the=20= >> 1980s -- I believe there is no existence proof at scale. >=20 > 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. 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. =20 >=20 > If the emails carried the logo embedded within themselves then much of > the BIMI cruft disappears and perfectly standard certs can be used. >=20 > Here's someone who's thought about this for longer than I have:=20 >=20 > https://hackernoon.com/a-proposal-for-an-email-avatar-header- > 38a2879d8219 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) =20 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. =20 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. =20 >=20 >> So my query is for serious detail that permits substantive = evaluation.=20 >> Since this issue was raised when the Bimi effort started -- somewhere = in=20 >> 2017, if memory serves -- and since this issue is critical to the=20 >> operation of Bimi, there should be thoughtful material available. >=20 > 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. Funny that you say this. A great idea, and there's no reason why it = cannot be done. =20 There are registered trademarks that are audio (see = https://en.wikipedia.org/wiki/Sound_trademark)=20 Cooler still, audio is supported already - see RFC3709 Section 3. =20 Thede From nobody Thu Feb 14 02:58:03 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8662813115C for ; Thu, 14 Feb 2019 02:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucMs2G5a3chp for ; Thu, 14 Feb 2019 02:57:59 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADF3131050 for ; Thu, 14 Feb 2019 02:57:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B8B3DBE2E for ; Thu, 14 Feb 2019 10:57:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_EmtF6j1rQ9 for ; Thu, 14 Feb 2019 10:57:55 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7EB8DBE20 for ; Thu, 14 Feb 2019 10:57:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550141875; bh=ooLKm3/Aa9SqxTxkJ8SvYaCJN0YfytOUV0v0I9Co7X0=; h=To:From:Subject:Date:From; b=YPz8wV6cSOc7l7m61aSBLklHS9drgU23ZwYv5g78ZSrjWaFf7o81IkYyqmggNugaZ LlBa50afqCSoqhcD6Vm/VEENBKw1q5m+kMvQwCw1dJyQOWPXE29IL2a9A/J7vepl49 1mbonnVR2E73ANDjqsW25X1lnqDqPjJ81W4dpoeA= To: bimi@ietf.org From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 14 Feb 2019 10:57:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="71sadKePtlwETNcr2FKiKbrHu6TSD80TX" Archived-At: Subject: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 10:58:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --71sadKePtlwETNcr2FKiKbrHu6TSD80TX Content-Type: multipart/mixed; boundary="aZ3PEdozQksZRmBGNdpAP7Cq9DGvz8ACG"; protected-headers="v1" From: Stephen Farrell To: bimi@ietf.org Message-ID: Subject: (non)desire for bimi --aZ3PEdozQksZRmBGNdpAP7Cq9DGvz8ACG Content-Type: multipart/mixed; boundary="------------84A59C4DCF26F0BA443968B0" Content-Language: en-GB This is a multi-part message in MIME format. --------------84A59C4DCF26F0BA443968B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (Sorry for not replying in-thread but I just subscribed to the list, and this perhaps also deserves a separate thread.) >>> * Internet users want it - clear demand >> >> That claim keeps being made but I've never seen any serious >> documentation for it. > > Marketing people want it -- that may not be documented but I have > sufficient anecdotes to hand to believe it be the main driver here. I'd be interested in some kind of verifiable backup for that "clear demand" claim - I'm unaware that such exists, other than perhaps as Richard says for marketing purposes, and ISTM those purposes are amply met already via mail bodies. Meanwhile... I use the Internet. I do not want logos added to mail headers that increase the attack surface of my MUAs, (and MS/MTAs), that likely enable additional tracking of mail users, including me, and where mobile device and web MUAs are unlikely to offer me an option to turn all that off, even if some desktop MUAs might (eventually), at the risk of making messages harder to comprehend. I also just do not want to see your logos, thanks. Imposing those on me would decrease the utility of mail. And regardless of what PKI were built I would not treat bimi'd messages any better, more likely I'd consider them badly. As someone who sends email (not as a bulk sender) from various domains that I operate, I do not want to pay =E2=82=AC=E2=82=AC=E2=82=AC to someone for an additional cert, nor= for an "approved" logo, in order to increase the chances that my mail gets delivered. Things in that respect are bad enough, and this proposal seems to me likely to only worsen the situation for those who operate small domains, presumably to the benefit of those who operate large mail infrastructures and CAs who issue certs for money. I also do not want to have to check if someone else has abused a logo I may use in some CT log. I do not want to have to process additional headers in my MTAs nor retrieve and store your logos in some new image store. I do not want to have to deal with any of the new problems that'll arise when any of that breaks. So: No thanks, from me. Personally, as a mail user I only see downsides to this whole idea. Thanks, S. --------------84A59C4DCF26F0BA443968B0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------84A59C4DCF26F0BA443968B0-- --aZ3PEdozQksZRmBGNdpAP7Cq9DGvz8ACG-- --71sadKePtlwETNcr2FKiKbrHu6TSD80TX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxlSbIACgkQWrL68XsX K+qzYxAAjb/jD6bs+gDZgP4sT0RsS0fmWYloECs2mCWXBFYVJz3C0kEoit3yfWda Lfn7hwIEnVCMT3XP4d0WJtIex4D02oiH7YX+0bwpzXDcEvPDr4EvfqLFYvrc4dSm ZY8WSAF8yjSD4jcfQjOQbPZ7W2GxbHJxZb487NjC1Jo5uiMenXHRWE4JuS4X3jEP Zlo3PWlPhuJS+I0P/Spzs7XGwtxy9h3QdTS5Zx2auJfgYDhX31LCxGCttHl+f/Gd ln/cZHOItdOsO1bdvT42lkC1Z/uFM8Ww4LYXXRrBMIVrMhQjUWYwNyG3thLLrC0a Xf1zSQAV9HZdl3BTXNTnKr46/y5lvRei/JQN4gVn9+awiAiiMN1e6HBC71Ee2QL2 Px7KeYb6FiPdVTZVJg07Ep93E8meRC/uqg9O4gdjEULhgDQwFasE/i3WE5gqSfKH GoVKWcaM9nW+NDm5H/GHshQVX+HI/MZxRrWQEIh+cLPJmpY9b3IvvVeSQOG/D28z L7o2UrEJ0XgjY+HcPZagNiaJW9M+6tk0hqL8oIUzvcDquNSXtQao1OKpcH8qE2Aa /vwZhszWjpOHbbIdin+HewQr26cvAFdzx8Ragu5jkH07vZd5nIXWjEftg0WTqqKH JfkocRRleJnXRSFXhypMq9uE/+G4fAxzpIb4muDaAYgN6V1CRoM= =Pw7s -----END PGP SIGNATURE----- --71sadKePtlwETNcr2FKiKbrHu6TSD80TX-- From nobody Thu Feb 14 09:08:09 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65794130E2F for ; Thu, 14 Feb 2019 09:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=terryzink.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrbKVCO99Bwq for ; Thu, 14 Feb 2019 09:08:05 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760049.outbound.protection.outlook.com [40.107.76.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F00E128701 for ; Thu, 14 Feb 2019 09:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=terryzink.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xzBclKg/5D+Ja5fXy1uwTKzLyQDQiem5Oxh0RsQjYJg=; b=fWySR0GngICOMkDPn+8OCWND2F7Wxcee3DpJhie4nYGOmB60TGOaCZrsdduvBwsw/SJ7b3jHOQiYVju01rsbH3lILkhXdHZ6WFXsnbGdnSI9AsBgjwVNxcx3B9eHI3jU2ppbBPTdwzh31MouSSpuqSm2j5Nqx9HAm4VrnPn8/pQ= Received: from BL0PR11MB3107.namprd11.prod.outlook.com (20.177.205.141) by BL0PR11MB2913.namprd11.prod.outlook.com (20.177.147.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 17:08:00 +0000 Received: from BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda]) by BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda%3]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 17:08:00 +0000 From: Terry Zink To: "bimi@ietf.org" Thread-Topic: [Bimi] (non)desire for bimi Thread-Index: AQHUxFQrlnICsfeFJUyWrugVUJNeRqXfg1XE Date: Thu, 14 Feb 2019 17:08:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@terryzink.com; x-originating-ip: [174.21.90.137] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d8b0b3b7-f678-4a3a-067c-08d6929ef994 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BL0PR11MB2913; x-ms-traffictypediagnostic: BL0PR11MB2913: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; BL0PR11MB2913; 23:iccTX0kvnSGK40lQFOAW0XDVhbs0Sw4EEMgJc?= =?Windows-1252?Q?QJ30kZNTdfZiMQ7Gwz3vkqfMVlUaDyGSTUZEN/aOP/W3fJc6fW5VRTb4?= =?Windows-1252?Q?WjW7E2PZULri3v7g92R/nu/qg2sa+aDo3IFhgbiDmSWZcJX1cYAA4ABA?= =?Windows-1252?Q?Czyzaki0zFXyF3W2kUukr5JSNfsb6v2M27ZDKF7N+CxCmVlbTE/ZADV8?= =?Windows-1252?Q?iY1NhFtrXdQ52Zi5QePgZISbjmLm8zAGm1E928/an0wMckAT/lefyS4l?= =?Windows-1252?Q?WH+5m7qEaR6Ysrhenih9BZd7zO09cLJKWO7M+dwwvchAoGfcgg5TD9qJ?= =?Windows-1252?Q?WVjKZHJn4+2nUxbyfmlAZDULgzIpX+B4Y13gJjWb2FQbGYC43gHoFHP2?= =?Windows-1252?Q?8uJYMryhL9aBDCchHnop7tn+e4ntfT+1gyUfX6udjTVDOmcqWWjse1Bs?= =?Windows-1252?Q?tH1L1g1lqZ81te4bzke6ZpWy8mmOS+tkA+LMooD/UkvZmO0wAhxwfySz?= =?Windows-1252?Q?sdi4IGf/Mr8161RIc0KWzrt2jUjtmH6Za+Wi+PbCqXaIe9F52kX6RmZp?= =?Windows-1252?Q?OfO+TsHqP4WOs+kgnXfKd48MpRcB34yjJFJ2S/1YItZbpULco9WibdZj?= =?Windows-1252?Q?Az9JjIFA5XvCXLWcs9uloOQjRbQ7fPj1KLEWJmdlTKfArYiON//RjS6p?= =?Windows-1252?Q?dKl/83BkU3FP6PibCNq4uSYmfIsCsc1VwvzZatCkMxRff+xtZnwKZryC?= =?Windows-1252?Q?KG7uPK5z9r0t5hCPmTxCJDjDGcbMRR1x9BwAbzWgtLrtQNJxHejIOM0g?= =?Windows-1252?Q?1vXQbB4XfDZjnGma3TkrS/PF9GVSVtQcuO+HukQLngUw/U8W3rkfcXqv?= =?Windows-1252?Q?ETOOGwwuVQW5WvtVmlmtxKGXknbznuStFuTYraqfib/hqHFQoT5Ncugv?= =?Windows-1252?Q?gJFzNV64WHFdVEgXsxs5r/NyTbI1AHr4EY5eO8cmolvHUxj7j9OZgjNj?= =?Windows-1252?Q?gapS1w+Nz327qCA1+2meJnS7JXgHb1JFysBd+DZoONN/RKLy+z6ujBxK?= =?Windows-1252?Q?X2itwGRvnJnysd7JE7Jho4AwCnOw/boxnlu9mIO7BJ08jGF+Q9X7SXts?= =?Windows-1252?Q?VGzZzKJZCExdxVeyDi9KlbO3uCPU12GNpBIvxDvjqB6glSOsuWnBQ591?= =?Windows-1252?Q?eSGqz4+Fw2n7oS7WmlF1bDtI79O2jepyWOy2S2JOMcJEzBBcfD6Y0Zt0?= =?Windows-1252?Q?zYVwdXI92B5+/iyM4xYDoMq94uNqqpM8nEfi8oZ+GoYkguPjDLeQ7Tvi?= =?Windows-1252?Q?2r2oL3/oF/FTeu5aplkVnLWYYGJ2OQUtTJhzs5/UV3w9ppLTAHxStl11?= =?Windows-1252?Q?2RBipkyqvf3eHxvBdJ/Z2BLIhsSgvxWp/WkUkr//kEhgkVXvS1k/DNKh?= =?Windows-1252?Q?2tEg9VEppMBbddHNkYF6b9ZZ0h+xr472jmMpGkL7iDmyq6BIAamiWlBp?= =?Windows-1252?Q?7Y5uSVgG8Nphb0YqeFXFNL8Dwjk?= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(446003)(561944003)(566704002)(14454004)(105586002)(2906002)(476003)(6916009)(53546011)(6506007)(11346002)(106356001)(53936002)(14444005)(25786009)(229853002)(97736004)(256004)(8936002)(71190400001)(71200400001)(486006)(66066001)(105004)(33656002)(7736002)(5640700003)(186003)(316002)(99286004)(2501003)(55016002)(74316002)(68736007)(6116002)(6246003)(7696005)(6436002)(9686003)(19627405001)(26005)(1730700003)(76176011)(81166006)(8676002)(81156014)(102836004)(45080400002)(66574012)(54896002)(86362001)(508600001)(3846002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB2913; H:BL0PR11MB3107.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: terryzink.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: N5r2klMrFt9xm6xCPj/veshBjUtQl9s7JYGzkV1PCpGZ8KB0jh5z7Xg++024gJa32vx39NuVyMya2QxHvL3z0pcS4DF9zcSXVesW6tBrtAXYjgKZTO/dQgdP4L6EBoNZqEdCEpYgZsVvQ3N3SYIxEMPOCcuQGEyJMk+lls7dDieNpbN7WisMXRgltFeOs3URXn5D4Y1HVBATVpU5lxFgSmHYTJEzhswdGvyHL8DvkRa8+uHhuiP3HuVsCVqJsAzYW2kZxHdeAb5k22nY2P+23S5c65h/VR2DJ5/PVrkwa1YRpgCNByzYuewzY3MomBN3yDMwMeD9X0sYTd+WizZduv9cLE8WdKWPfT5b72f8bCmnN4I+Rep9e65TLmkXlP2g7+M22sa/0ilKhBAexPzC/e0mRAieRS0F4ButQyj2Usw= Content-Type: multipart/alternative; boundary="_000_BL0PR11MB3107712FFFD2D92E911B909DA9670BL0PR11MB3107namp_" MIME-Version: 1.0 X-OriginatorOrg: terryzink.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8b0b3b7-f678-4a3a-067c-08d6929ef994 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 17:08:00.7018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 470dd1c0-25dc-4cce-857e-0d65849495b7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2913 Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:08:08 -0000 --_000_BL0PR11MB3107712FFFD2D92E911B909DA9670BL0PR11MB3107namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for your comments, Stephen. Here are my thoughts. > I'd be interested in some kind of verifiable backup > for that "clear demand" claim To me, it seems intuitively obvious. For example, in the Office 365 web int= erface, I see logos from several different companies in the list view and t= he sender photo when I open the message - Amazon, Lyft, Facebook, LinkedIn,= Netflix, BackCountry, Quora, etc (this is displayed via Microsoft's Brand = Cards program). My old Yahoo Mail interface has something similar. For a wh= ile, Gmail showed a company logo pulled from its Google+ page. How does this not show demand? Isn't this an example of web mail providers = wanting to enhance the user experience, and companies happily obliging, and= me as a user being pleased? I am not representative of the entire space, but I really *like* those send= er photos. > I use the Internet. I do not want logos added to mail > headers that increase the attack surface of my MUAs, > (and MS/MTAs), that likely enable additional tracking > of mail users, including me, and where mobile device > and web MUAs are unlikely to offer me an option to > turn all that off, even if some desktop MUAs might > (eventually), at the risk of making messages harder > to comprehend. I'm not sure I understand this comment. The logos are not added to mail hea= ders, but instead headers point to a location where the logo can be picked = up and then shown to the end user. What's the difference between the sender= /brand providing an authoritative source (DNS record that points to a CDN) = vs Office 365/Yahoo pulling from their own internal database? > I also just do not want to see your logos, thanks. Again, I am not sure I understand this comment. Logos are everywhere. Most large companies have Facebook and Twitter pages,= and they all have logos. You see logos painted on the sides of walls, on s= tores, on TV, in newspapers, on web pages, as favicons, etc. Are you saying these are all fine but in the sender photo it isn't? What's = the fundamental difference between seeing a company's logo in the sender ph= oto vs seeing it in the body of an email? Is it just a matter of turning of= HTML and preventing those from loading? > As someone who sends email (not as a bulk sender) > from various domains that I operate, I do not want > to pay =80=80=80 to someone for an additional cert, nor > for an "approved" logo, in order to increase the > chances that my mail gets delivered. Nobody is going to make you buy a cert, nobody is going to make you buy a l= ogo, and so forth. It's up to you. BIMI is an add-on; it augments the default experience, the lack of it doesn= 't downgrade the default experience. > I also do not want to have to check if someone else > has abused a logo I may use in some CT log. I do > not want to have to process additional headers in my > MTAs nor retrieve and store your logos in some new > image store. I do not want to have to deal with any > of the new problems that'll arise when any of that > breaks. Again, I'm unclear about the context of this statement. Nobody is going to = make you as a sender, brand, or receiver send with BIMI. Nobody is going to= make you retrieve logos from a store, nobody is going to make you verify a= ny log, nobody is going to make you process additional headers. Instead, it's about enhancing the email experience for those motivated to d= o so. And, BIMI provides a way to do this. --Terry ________________________________ From: bimi on behalf of Stephen Farrell Sent: Thursday, February 14, 2019 2:57 AM To: bimi@ietf.org Subject: [Bimi] (non)desire for bimi (Sorry for not replying in-thread but I just subscribed to the list, and this perhaps also deserves a separate thread.) >>> * Internet users want it - clear demand >> >> That claim keeps being made but I've never seen any serious >> documentation for it. > > Marketing people want it -- that may not be documented but I have > sufficient anecdotes to hand to believe it be the main driver here. I'd be interested in some kind of verifiable backup for that "clear demand" claim - I'm unaware that such exists, other than perhaps as Richard says for marketing purposes, and ISTM those purposes are amply met already via mail bodies. Meanwhile... I use the Internet. I do not want logos added to mail headers that increase the attack surface of my MUAs, (and MS/MTAs), that likely enable additional tracking of mail users, including me, and where mobile device and web MUAs are unlikely to offer me an option to turn all that off, even if some desktop MUAs might (eventually), at the risk of making messages harder to comprehend. I also just do not want to see your logos, thanks. Imposing those on me would decrease the utility of mail. And regardless of what PKI were built I would not treat bimi'd messages any better, more likely I'd consider them badly. As someone who sends email (not as a bulk sender) from various domains that I operate, I do not want to pay =80=80=80 to someone for an additional cert, nor for an "approved" logo, in order to increase the chances that my mail gets delivered. Things in that respect are bad enough, and this proposal seems to me likely to only worsen the situation for those who operate small domains, presumably to the benefit of those who operate large mail infrastructures and CAs who issue certs for money. I also do not want to have to check if someone else has abused a logo I may use in some CT log. I do not want to have to process additional headers in my MTAs nor retrieve and store your logos in some new image store. I do not want to have to deal with any of the new problems that'll arise when any of that breaks. So: No thanks, from me. Personally, as a mail user I only see downsides to this whole idea. Thanks, S. --_000_BL0PR11MB3107712FFFD2D92E911B909DA9670BL0PR11MB3107namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for your comments, Stephen. Here are my thoughts.

> I'd be interested in s= ome kind of verifiable backup
> for that "clear demand" claim

To me, it seems intuitively= obvious. For example, in the Office 365 web interface, I see logos from se= veral different companies in the list view and the sender photo when I open= the message - Amazon, Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is displayed via Microsof= t's Brand Cards program). My old Yahoo Mail interface has something similar= . For a while, Gmail showed a company logo pulled from its Google+ page= .

How does this not show dema= nd? Isn't this an example of web mail providers wanting to enhance the user= experience, and companies happily obliging, and me as a user being pleased= ?

I am not representative of = the entire space, but I really *like* those sender photos.

> I use the Internet. I = do not want logos added to mail
> headers that increase the attack surface of my MUAs,
> (and MS/MTAs), that likely enable additional tracking
> of mail users, including me, and where mobile device
> and web MUAs are unlikely to offer me an option to
> turn all that off, even if some desktop MUAs might
> (eventually), at the risk of making messages harder
> to comprehend.

I'm not sure I understand t= his comment. The logos are not added to mail headers, but instead headers p= oint to a location where the logo can be picked up and then shown to the en= d user. What's the difference between the sender/brand providing an authoritative source (DNS record that points= to a CDN) vs Office 365/Yahoo pulling from their own internal database?


> I also just do not wan= t to see your logos, thanks.

Again, I am not sure I unde= rstand this comment.

Logos are everywhere. Most = large companies have Facebook and Twitter pages, and they all have logos. Y= ou see logos painted on the sides of walls, on stores, on TV, in newspapers= , on web pages, as favicons, etc.

Are you saying these are al= l fine but in the sender photo it isn't? What's the fundamental difference = between seeing a company's logo in the sender photo vs seeing it in the bod= y of an email? Is it just a matter of turning of HTML and preventing those from loading?

> As someone who sends e= mail (not as a bulk sender)
> from various domains that I operate, I do not want
> to pay =80=80=80 to someone for an additional cert, nor
> for an "approved" logo, in order to increase the
> chances that my mail gets delivered. 

Nobody is going to make you= buy a cert, nobody is going to make you buy a logo, and so forth. It's up = to you.

BIMI is an add-on; it augme= nts the default experience, the lack of it doesn't downgrade the default ex= perience.

> I also do not want to = have to check if someone else
> has abused a logo I may use in some CT log. I do
> not want to have to process additional headers in my
> MTAs nor retrieve and store your logos in some new
> image store. I do not want to have to deal with any
> of the new problems that'll arise when any of that
> breaks.

Again, I'm unclear about the context of this statement. Nobody is going to = make you as a sender, brand, or receiver send with BIMI. Nobody is going to= make you retrieve logos from a store, nobody is going to make you verify a= ny log, nobody is going to make you process additional headers.

Instead, it's about enhancing the email experience for those motivated to d= o so. And, BIMI provides a way to do this.

--Terry

From: bimi <bimi-bounces= @ietf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
Sent: Thursday, February 14, 2019 2:57 AM
To: bimi@ietf.org
Subject: [Bimi] (non)desire for bimi
 

(Sorry for not replying in-thread but I just subscribed
to the list, and this perhaps also deserves a separate
thread.)

>>> * Internet users want it - clear demand
>>
>> That claim keeps being made but I've never seen any serious
>> documentation for it.
>
> Marketing people want it -- that may not be documented but I have
> sufficient anecdotes to hand to believe it be the main driver here.
I'd be interested in some kind of verifiable backup
for that "clear demand" claim - I'm unaware that
such exists, other than perhaps as Richard says for
marketing purposes, and ISTM those purposes are amply
met already via mail bodies.

Meanwhile...

I use the Internet. I do not want logos added to mail
headers that increase the attack surface of my MUAs,
(and MS/MTAs), that likely enable additional tracking
of mail users, including me, and where mobile device
and web MUAs are unlikely to offer me an option to
turn all that off, even if some desktop MUAs might
(eventually), at the risk of making messages harder
to comprehend.

I also just do not want to see your logos, thanks.
Imposing those on me would decrease the utility of
mail. And regardless of what PKI were built I would
not treat bimi'd messages any better, more likely
I'd consider them badly.

As someone who sends email (not as a bulk sender)
from various domains that I operate, I do not want
to pay =80=80=80 to someone for an additional cert, nor
for an "approved" logo, in order to increase the
chances that my mail gets delivered. Things in that
respect are bad enough, and this proposal seems to
me likely to only worsen the situation for those
who operate small domains, presumably to the benefit
of those who operate large mail infrastructures
and CAs who issue certs for money.

I also do not want to have to check if someone else
has abused a logo I may use in some CT log. I do
not want to have to process additional headers in my
MTAs nor retrieve and store your logos in some new
image store. I do not want to have to deal with any
of the new problems that'll arise when any of that
breaks.

So: No thanks, from me. Personally, as a mail user
I only see downsides to this whole idea.

Thanks,
S.
--_000_BL0PR11MB3107712FFFD2D92E911B909DA9670BL0PR11MB3107namp_-- From nobody Thu Feb 14 09:52:47 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B180812EB11 for ; Thu, 14 Feb 2019 09:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bwOdSCLj; dkim=pass (1536-bit key) header.d=taugh.com header.b=fYxInzWP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PgjLF6GORMU for ; Thu, 14 Feb 2019 09:52:45 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558E612D829 for ; Thu, 14 Feb 2019 09:52:45 -0800 (PST) Received: (qmail 47321 invoked from network); 14 Feb 2019 17:52:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b8d3.5c65aaec.k1902; bh=FV0DtXZ8V/Hnyjxms68YY6GvQLGKogQ9kFBHEALAyxM=; b=bwOdSCLjXKlysyaWgKfbrXv8TIw4CPfzmPMtt1wMF1jXyPdeho255HcOuv6mvIK19BojfDoyHkB0HI5+gzRsDi69L034aH/KegRP/qBN3ZaS+4mQcTasqZteRYO3TUA+hNvAgQJ/O2aJrmcYBrSGVaFv1c1bV5FfK1Cf1+P+5N2zlmL4Nq9sKCKAkU6rGgFaaX8CU/lrWwu7Ffp802Tm4ErBbCCTQR+xYSCH8Sn4xZPFnuO8rGDfmqBYZ0eMqlHO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b8d3.5c65aaec.k1902; bh=FV0DtXZ8V/Hnyjxms68YY6GvQLGKogQ9kFBHEALAyxM=; b=fYxInzWPotSZEAL8mYaARJWWNNf9hQrFvR43puJ5hwo7Li45O97OH8EfnqCPbaXvZqzUr/cCfHE1c0WLiRAiQnfH9A8LiPXu6YILLZeEzD/+CG/lOmCBZZZhyVHEfM8Y1NabphOHGmP1LAhHqh8zMUSjl9Sssz4A31b4bAUhNePDbbFaoNBJpePlkJKG4A2AxoWk8TW5BcLDfv0w/Boz6LCQcZrm+XjjvBOcRmsV5YkWhom4JlrElnlWCowhmYXA Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 14 Feb 2019 17:52:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 950C2200E509D1; Thu, 14 Feb 2019 12:52:42 -0500 (EST) Date: 14 Feb 2019 12:52:42 -0500 Message-Id: <20190214175243.950C2200E509D1@ary.qy> From: "John Levine" To: bimi@ietf.org Cc: tzink@terryzink.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:52:47 -0000 In article you write: >How does this not show demand? Isn't this an example of web mail providers wanting to enhance the user >experience, and companies happily obliging, and me as a user being pleased? I think you're extrapolating from a point. To extrapolate from another point, I find all those blinky things extremely annoying and specifically choose mail software that does not show them. >I'm not sure I understand this comment. The logos are not added to mail headers, but instead headers >point to a location where the logo can be picked up and then shown to the end user. What's the >difference between the sender/brand providing an authoritative source (DNS record that points to a CDN) >vs Office 365/Yahoo pulling from their own internal database? It makes it in effect another web bug. R's, John From nobody Thu Feb 14 10:06:38 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292AE124BAA for ; Thu, 14 Feb 2019 10:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4zmGcyF7sMI for ; Thu, 14 Feb 2019 10:06:35 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23031200ED for ; Thu, 14 Feb 2019 10:06:35 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1EI7vq8019793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Feb 2019 10:07:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550167678; bh=b8pDxO+GgD5KQNUaqYveryIRXeniBsd7aT613pqFQCs=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=lzWmGVJQE0bloVju8ZGPzIN7iHZPlQNTMEB3EFC2atsH7JYZXouDYEEHswet9ODCA fcV0eUz+Zyejs6Fnd5LTKkEjwFbH+cnhAynAaxn/582umLy71eOBVDmXZWpQKX6Ise fjwAhSWQX8PXIYoqgEg+JmmCM2fgX/vFZAXwGf28= To: John Levine , bimi@ietf.org Cc: tzink@terryzink.com References: <20190214175243.950C2200E509D1@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 14 Feb 2019 10:06:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190214175243.950C2200E509D1@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:06:37 -0000 On 2/14/2019 9:52 AM, John Levine wrote: > In article you write: >> How does this not show demand? Isn't this an example of web mail providers wanting to enhance the user >> experience, and companies happily obliging, and me as a user being pleased? > > I think you're extrapolating from a point. To extrapolate from > another point, I find all those blinky things extremely annoying and > specifically choose mail software that does not show them. Indeed. 1. An axiom in usability research is to not treat developers or researchers as subjects (unless they really are the target audience.) In terms of cognitive detail and usage style, such folk differ substantially from the general user population. 2. Any general claim about users in general needs to have some sort of statistical basis that gives credence to that generalization. Simply put, you or I or John do not matter in this calculus. We are the essence of a biased sample... -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Feb 14 10:23:29 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA98C1200ED for ; Thu, 14 Feb 2019 10:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=terryzink.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlBvILZZLhau for ; Thu, 14 Feb 2019 10:23:25 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700089.outbound.protection.outlook.com [40.107.70.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C112867A for ; Thu, 14 Feb 2019 10:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=terryzink.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uTwbrUXYi7wNeSmDWz+sXVGWkOKst3pSiX4YS3QICrc=; b=LBgKOl01QN2187QwY7uLQH8u1v67kqZsvooce7iwIAJhYeSUEcp3MIXHddeLcgpggz9g9t1ujA8ObcD+ozmXJCBlF1xnXdSodse8wJaVvYd61nAroDrB9NA0aOpSbLeEIu+2JIh7jigfZVUpeCYtTZ5utL70sERmC10FhZPiCXA= Received: from BL0PR11MB3107.namprd11.prod.outlook.com (20.177.205.141) by BL0PR11MB3265.namprd11.prod.outlook.com (10.167.234.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 18:23:21 +0000 Received: from BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda]) by BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda%3]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 18:23:21 +0000 From: Terry Zink To: "bimi@ietf.org" Thread-Topic: [Bimi] (non)desire for bimi Thread-Index: AQHUxFQrlnICsfeFJUyWrugVUJNeRqXfg1XEgAAQLACAAAPYgIAAAlHy Date: Thu, 14 Feb 2019 18:23:21 +0000 Message-ID: References: <20190214175243.950C2200E509D1@ary.qy>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@terryzink.com; x-originating-ip: [2620:10d:c090:200::7:2ad9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8dd29198-c644-4436-5657-08d692a9800a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BL0PR11MB3265; x-ms-traffictypediagnostic: BL0PR11MB3265: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BL0PR11MB3265; 23:fIW8reMxD8Io39eG/nSs60CBJ2dC5duFIrkk6+LN/?= =?us-ascii?Q?XouoRS/aKDUgZo4yZVBxPkx+xBmsHCTN1i5eleFT4lyKH3SZq4cyGcsiKDGN?= =?us-ascii?Q?g8zfOa7Age/uqjSBtMFcJ3JlkQc+KJs/XCNuYE7uzaEWydQ7zl6LabCo+gg1?= =?us-ascii?Q?ejKAtSi3v2rvP1f3Ra45CM7d6ef64eXWxMIquWGGyYJAVE+AfN7TALbj1Fxo?= =?us-ascii?Q?gC3sKQZpf08Ctq1E/TP4z8T5PoSsJu6nrzajM3iLIpA2v8n+izJIUZUgVK0y?= =?us-ascii?Q?YL2NQVXTSGELJaIVYWclb4PrrVOjqSsBd21VTDmMlmpqaOZOj7snsdw0IgIC?= =?us-ascii?Q?OApb+qk01UGrgz0clU8lbimJDw6ZAt73rhDO/J93vU51sgmsXLxwj1MnxAH+?= =?us-ascii?Q?0JUSOLyac4lsIq3ZAivgMiLgyIFOXQNZM2G3xbISxtc6E5SsTwfLMkCxy3iY?= =?us-ascii?Q?fA5W9Nch5/vnmk/JvENPEz+6sU5fQdUm1FVgiWh13NoUBc/VWPcIaxCrb+Oy?= =?us-ascii?Q?2OVBJlL7pWQS2pByn3Y65qwJ19Dn0P3P7CXC/MH4kYwYSB2Jx4NhJMp+y/fS?= =?us-ascii?Q?CU72ZEwWk1T5eec+7KYz/qrqD8cajmdjFb3o98qE5UchvIvIsHb7AAPYa1Xt?= =?us-ascii?Q?5cR7km3wCGg1VYeP1dnmK0rwkmjr2nlqzP8nmB9ketI6s9jjA/VTXdXp1md7?= =?us-ascii?Q?cu7dBbSxQfE0x51qzbjyf0NFH6hwqjDXEYhihSAB9vfopwJIhMKSr43pBbSj?= =?us-ascii?Q?nfnevSHCjVAHQnTGHIN2huyWbyET99iYWo7g67I/Q5aQj6Yg2WqnwWUG+g4v?= =?us-ascii?Q?LPnjLHGoRHjwCbWm2jB+eG64cCcUbxP52f640aUoS2Brzo7Wc8sSlEJFJzCy?= =?us-ascii?Q?mrNT1KY+jUu/2bYu2yELn23SptNxpaIVvqEB7AMuxJCPr/bxnUx3YkOk0hVy?= =?us-ascii?Q?esxUF99AfjeT23jf3Yn2p3S2Y2E7kS7vUMGx3p8RzARU1SPwri+283a8fZZe?= =?us-ascii?Q?NhoFwezBtN+GSgQtpM79dGztjnYufk0C07kzan7Ks3rAVtAW7xFRaOpNWNnR?= =?us-ascii?Q?gK6+ikQqrzTnZZSE93a9FZomF63Fw7C2Q7+h26C9TiOfEVugrTrUr/oW/FM/?= =?us-ascii?Q?sGNCO+NvtBgHkMt/w53LyGNLgbHZed04epD/gL9rIisiIe6KsRMBrAUS1kXV?= =?us-ascii?Q?IWgqbHwGuEJRfWbx2QhGLaMPSPSXFvG1fP1ABiuYx7vwS/R10cGyRT+yNBq4?= =?us-ascii?Q?DZe6kZmIws7nsZ/qpeSYasSjaUJ1Zn7VP4eN3K89WNiKC9eRWrrDOioRiq6s?= =?us-ascii?Q?S4aXH/R8ya1IwhZl2tZmmh6OTJXk3iFRci4xArgSdug2kPy8lpEDTZshCqDg?= =?us-ascii?Q?kp4YEPHnlYDyosfbZzEIfyO9qU=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(376002)(39830400003)(199004)(189003)(53546011)(33656002)(102836004)(186003)(53936002)(2501003)(76176011)(6506007)(316002)(7696005)(6116002)(606006)(99286004)(97736004)(966005)(19627405001)(106356001)(8936002)(71200400001)(55016002)(71190400001)(105586002)(2351001)(25786009)(14454004)(5640700003)(14444005)(7736002)(9686003)(256004)(6916009)(86362001)(566704002)(236005)(45080400002)(54896002)(508600001)(2906002)(46003)(68736007)(6246003)(81156014)(81166006)(1730700003)(8676002)(105004)(229853002)(476003)(486006)(6436002)(74316002)(11346002)(446003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3265; H:BL0PR11MB3107.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: terryzink.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pYlBeXv9EesRkeDrMfMEiC2w6z69oO70mIcpo+HAUYX3Vd3ZabbiV13HY6/7rF0cqFF6z2aepegUQZVlsZpSfKUZO5xtgMsttsgV7IjBjvxSbyAVSfyXfaavgR8AC467pJts5v9i99CLxBPQBBKHYwfZNYUCOb2KYKfNgiqTIZLQjBCNle3k0KHhb+O5nejnyQroAURh63KZxAJglgE1miVzOOXee2m05XdQzMdHejQA47NGJd/bWQjLT+MBwYox8XxKVPxaAxwysDZK+A6KwyjNk74iuv2dBZINHDdCnpGrS+ieJ5IJfftbWsYw2xWRhyJTjLS4nGS9jUvc++n6uQKzKZhRkjnFJTRkS87LpX3fqxtAH1eAUQhZTYkkevQTdMkksj1JAh7xrnnU899JLfikcaWRy9h9WRx6eoteTac= Content-Type: multipart/alternative; boundary="_000_BL0PR11MB3107E380194F10A297485BBCA9670BL0PR11MB3107namp_" MIME-Version: 1.0 X-OriginatorOrg: terryzink.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8dd29198-c644-4436-5657-08d692a9800a X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 18:23:21.4182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 470dd1c0-25dc-4cce-857e-0d65849495b7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3265 Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:23:28 -0000 --_000_BL0PR11MB3107E380194F10A297485BBCA9670BL0PR11MB3107namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks John, and Dave. > 1. An axiom in usability research is to not treat developers or > researchers as subjects (unless they really are the target audience.) > In terms of cognitive detail and usage style, such folk differ > substantially from the general user population. > > Simply put, you or I or John do not matter in this calculus. We are the > essence of a biased sample... I agree, which is why I said earlier that I am not representative of the en= tire space. > I think you're extrapolating from a point. To extrapolate from > another point, I find all those blinky things extremely annoying and > specifically choose mail software that does not show them. Yes, there are some people that don't like this type of UX. And with BIMI, = you'll still be able to use the same software that doesn't show images, HTM= L, sender photos, etc. There's no change there. > It makes it in effect another web bug. Hmm... That heavily depends upon implementation. A web bug, as I understand it, he= lps to track user behavior - did the user open up my mail? While I concede = that BIMI could be used this way, it's not a particularly effective way to = do it. It would require setting up a lot of DNS records, and then being abl= e to stand up infrastructure that can handle all those requests. Most large receives wouldn't serve up a BIMI logo from the actual location = pointed to by headers/DNS records each time they needed it. Instead, they'd= periodically poll the logos/certs they need, upload them into a local data= base, and then pull from there. So, as a sender/brand, you might send out 1= 00,000 messages to a single receiver and intend to use BIMI to see how many= people interacted with the message. But in reality, you might see only 1 r= equest - the one where that receiver saw it needed your logo and then downl= oaded it after verifying it. And then 30 days later, you saw them download = it again. So, while a web bug is a possible concern, a large receiver (and I would th= ink even a medium sized one) would have to make use of more efficient archi= tectural implementations to make the web bug concerns a minor one on the li= st of things to worry about. --Terry ________________________________ From: bimi on behalf of Dave Crocker Sent: Thursday, February 14, 2019 10:06 AM To: John Levine; bimi@ietf.org Cc: Terry Zink Subject: Re: [Bimi] (non)desire for bimi On 2/14/2019 9:52 AM, John Levine wrote: > In article you write: >> How does this not show demand? Isn't this an example of web mail provide= rs wanting to enhance the user >> experience, and companies happily obliging, and me as a user being pleas= ed? > > I think you're extrapolating from a point. To extrapolate from > another point, I find all those blinky things extremely annoying and > specifically choose mail software that does not show them. Indeed. 1. An axiom in usability research is to not treat developers or researchers as subjects (unless they really are the target audience.) In terms of cognitive detail and usage style, such folk differ substantially from the general user population. 2. Any general claim about users in general needs to have some sort of statistical basis that gives credence to that generalization. Simply put, you or I or John do not matter in this calculus. We are the essence of a biased sample... -- Dave Crocker Brandenburg InternetWorking bbiw.net -- bimi mailing list bimi@ietf.org https://www.ietf.org/mailman/listinfo/bimi --_000_BL0PR11MB3107E380194F10A297485BBCA9670BL0PR11MB3107namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks John, and Dave.

> 1. An axiom in usabili= ty research is to not treat developers or
> researchers as subjects (unless they really are the target audience.) =
> In terms of cognitive detail and usage style, such folk differ
> substantially from the general user population.
>
> Simply put, you or I or John do not matter in thi= s calculus.  We are the
> essence of a biased sample...

I agree, which is why I said earlier that I am not representative of the en= tire space.


> I think you're extrapolating from a point.  To extrapolate from > another point, I find all those blinky things extremely annoying and > specifically choose mail software that does not show them.

Yes, there are some people = that don't like this type of UX. And with BIMI, you'll still be able to use= the same software that doesn't show images, HTML, sender photos, etc. Ther= e's no change there.

> It makes it in effect another web bug.

Hmm...

That heavily depends upon i= mplementation. A web bug, as I understand it, helps to track user behavior = - did the user open up my mail? While I concede that BIMI could be used thi= s way, it's not a particularly effective way to do it. It would require setting up a lot of DNS records, and then b= eing able to stand up infrastructure that can handle all those requests.

Most large receives wouldn'= t serve up a BIMI logo from the actual location pointed to by headers/DNS r= ecords each time they needed it. Instead, they'd periodically poll the logo= s/certs they need, upload them into a local database, and then pull from there. So, as a sender/brand, you mig= ht send out 100,000 messages to a single receiver and intend to use BIMI to= see how many people interacted with the message. But in reality, you might= see only 1 request - the one where that receiver saw it needed your logo and then downloaded it after verifyi= ng it. And then 30 days later, you saw them download it again.

So, while a web bug is a po= ssible concern, a large receiver (and I would think even a medium sized one= ) would have to make use of more efficient architectural implementations to= make the web bug concerns a minor one on the list of things to worry about.

--Terry

From: bimi <bimi-bounces= @ietf.org> on behalf of Dave Crocker <dhc@dcrocker.net>
Sent: Thursday, February 14, 2019 10:06 AM
To: John Levine; bimi@ietf.org
Cc: Terry Zink
Subject: Re: [Bimi] (non)desire for bimi
 
On 2/14/2019 9:52 AM, John Levine wrote:
> In article <BL0PR11MB3107712FFFD2D92E911B909DA9670@BL0PR11MB3107.na= mprd11.prod.outlook.com> you write:
>> How does this not show demand? Isn't this an example of web mail p= roviders wanting to enhance the user
>> experience, and companies happily obliging, and me as a user being= pleased?
>
> I think you're extrapolating from a point.  To extrapolate from > another point, I find all those blinky things extremely annoying and > specifically choose mail software that does not show them.


Indeed.

      1. An axiom in usability research is to not = treat developers or
researchers as subjects (unless they really are the target audience.)
In terms of cognitive detail and usage style, such folk differ
substantially from the general user population.

      2. Any general claim about users in general = needs to have some
sort of statistical basis that gives credence to that generalization.

Simply put, you or I or John do not matter in this calculus.  We are t= he
essence of a biased sample...




--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
bimi mailing list
bimi@ietf.org
https://www.ietf.org= /mailman/listinfo/bimi
--_000_BL0PR11MB3107E380194F10A297485BBCA9670BL0PR11MB3107namp_-- From nobody Thu Feb 14 10:35:38 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3418913104C for ; Thu, 14 Feb 2019 10:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6VOJwqCcPKO for ; Thu, 14 Feb 2019 10:35:33 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F8F12D829 for ; Thu, 14 Feb 2019 10:35:33 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1EIaqen023380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Feb 2019 10:36:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550169413; bh=2C+/rzYT0tPxB5zraL3AcD0FWxdFbygsJJYbAhvQyKU=; h=Subject:To:References:From:Cc:Reply-To:Date:In-Reply-To:From; b=AK1rQKPNFJIwoaan2SRqk4bzMjaGCURN1Ysyt0H9e/tgcNdw1i0jaCocXMHlzorg+ 7u+V2fejzVb2fW7tnPavBMrWXV7FHRbp8uBsKF22ffocTbr1coiu5Ab68scZGSQ5ja 34rUNQ0bQlZ9HGOk57x5caJ4KOMUSYS66ZIdPrKE= To: Terry Zink References: <20190214175243.950C2200E509D1@ary.qy> From: Dave Crocker Cc: "bimi@ietf.org" Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 14 Feb 2019 10:35:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:35:36 -0000 On 2/14/2019 10:23 AM, Terry Zink wrote: > Thanks John, and Dave. > >> 1. An axiom in usability research is to not treat developers or >> researchers as subjects (unless they really are the target audience.) >> In terms of cognitive detail and usage style, such folk differ >> substantially from the general user population. >> >> Simply put, you or I or John do not matter in this calculus.  We are the >> essence of a biased sample... > > I agree, which is why I said earlier that I am not representative of the > entire space. Except that you only cited yourself and then said "How does this not show demand?" You started with "To me, it seems intuitively obvious." If there is anything in usability design that would qualify as speech of the devil, that sentence probably qualifies. Usability design often needs to make choice that goes exactly against what is "intuitive" to one person or another. By way of example, there is a common view that giving end users more information is always a good thing, but this flies in the face of well-understood cognitive limits. > Yes, there are some people that don't like this type of UX. And with > BIMI, you'll still be able to use the same software that doesn't show > images, HTML, sender photos, etc. There's no change there. This is another fundamental usability design error: thinking that adding something is fine because users can turn it off. This burdens users, and often creates a barrier because they don't know how to fix it or even that they can. >> It makes it in effect another web bug. > > Hmm... > > That heavily depends upon implementation. A web bug, as I understand it, > helps to track user behavior - did the user open up my mail? While I > concede that BIMI could be used this way, it's not a particularly > effective way to do it. So you are countering a security concern by saying that we should not worry about it because there are other vectors you consider better? This suggests that additional attack vectors aren't to be worried aboout, as long as easier ones are available? > Most large receives wouldn't serve up a BIMI logo from the actual > location pointed to by headers/DNS records each time they needed it. I don't understand how this point is relevant to the underlying concern. How is a statement predicated on "most" a useful security concern counter? It almost sounds as if systems not part of that 'most' don't matter... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Feb 14 10:52:21 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2E12DDA3 for ; Thu, 14 Feb 2019 10:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8-6Dr8yo234 for ; Thu, 14 Feb 2019 10:52:16 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74B71289FA for ; Thu, 14 Feb 2019 10:52:15 -0800 (PST) Received: from localhost ([127.0.0.1]:36618 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1guM7K-0006Sr-65 for bimi@ietf.org; Thu, 14 Feb 2019 18:52:14 +0000 Message-ID: Date: Thu, 14 Feb 2019 18:50:36 +0000 To: "bimi@ietf.org" From: Richard Clayton References: <20190214175243.950C2200E509D1@ary.qy> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:52:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message , Terry Zink writes > That heavily depends upon implementation. A web bug, as I > understand it, helps to track user behavior - did the user open up > my mail? While I concede that BIMI could be used this way, it's not > a particularly effective way to do it. It would require setting up > a lot of DNS records, and then being able to stand up > infrastructure that can handle all those requests. ... and surely marketing people would never do that ?+ > Most large receives wouldn't serve up a BIMI logo from the actual > location pointed to by headers/DNS records each time they needed > it. Instead, they'd periodically poll the logos/certs they need, > upload them into a local database, and then pull from there. Please explain how they would "poll the certs they need" ? I understand that they might cache certificates that they had already fetched once, but that's not the same thing at all. How do they know what certificates they need a priori ? is it just for the brand owners who have sent them cheques to pay for the display of their logo ?? > So, as > a sender/brand, you might send out 100,000 messages to a single > receiver and intend to use BIMI to see how many people interacted > with the message. But in reality, you might see only 1 request - > the one where that receiver saw it needed your logo and then > downloaded it after verifying it. And then 30 days later, you saw > them download it again. the way you would get tracking (and of course mess up the caching behaviour by the mail receiver) would be to use a different (sub)domain for every email... ... so if you wish to forbid this (or make it expensive) you need language about wildcard certificates. Where do I find that in the spec? > So, while a web bug is a possible concern, a large receiver (and I > would think even a medium sized one) would have to make use of more > efficient architectural implementations to make the web bug > concerns a minor one on the list of things to worry about. the reverse -- without protocol restrictions the large receiver would be worried that their caching architecture was subject to attack - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGW4fDu8z1Kouez7EQL6iwCfWUNBwQvx20LG1lzQ4YDaHiEI7TYAmgJd wOsceIENtEVbG51TLit0kTod =2QC5 -----END PGP SIGNATURE----- From nobody Thu Feb 14 10:54:22 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E38F12426A for ; Thu, 14 Feb 2019 10:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTCbL8bF9Oh8 for ; Thu, 14 Feb 2019 10:54:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACD71200ED for ; Thu, 14 Feb 2019 10:54:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D65ECBE38; Thu, 14 Feb 2019 18:44:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1qbxMlt3KaW; Thu, 14 Feb 2019 18:44:43 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0761BE20; Thu, 14 Feb 2019 18:44:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550169882; bh=WjaJQt3X9Tthl7xRwYpScjXi/oqXolrzAmWC0rH5CHI=; h=To:References:From:Subject:Date:In-Reply-To:From; b=yFemC4+W6KReaM7SULKzhDt0FVBNUslqyeTRjEaZxj4d7AqzdmM7hLwzXiOTtxTWZ qW3WPq6ksPMYKo5NBJXchBPO9CZSNO+2YF/M3aZT/JcISJ2u3OHrzE25YbdDRQJ4aX eNJiKZRRXuYut0WugchqUT0uglJ3/2YXYE8YGt8U= To: Terry Zink , "bimi@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> Date: Thu, 14 Feb 2019 18:44:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t9wpQ5V5bYySZWvkKB8HfSQQyxqYM5JvC" Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:54:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t9wpQ5V5bYySZWvkKB8HfSQQyxqYM5JvC Content-Type: multipart/mixed; boundary="d5WA0LA1MnT8xFPpBUoTNOnxVcQQmEJ0i"; protected-headers="v1" From: Stephen Farrell To: Terry Zink , "bimi@ietf.org" Message-ID: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> Subject: Re: [Bimi] (non)desire for bimi References: In-Reply-To: --d5WA0LA1MnT8xFPpBUoTNOnxVcQQmEJ0i Content-Type: multipart/mixed; boundary="------------7A19CF0B89F0263CB6AE4095" Content-Language: en-GB This is a multi-part message in MIME format. --------------7A19CF0B89F0263CB6AE4095 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Terry, (I agree with both John and Dave's points upthread so will try not repeat those, but I'm happy to elaborate if it's useful.) On 14/02/2019 17:08, Terry Zink wrote: > Thanks for your comments, Stephen. Here are my thoughts. >=20 >> I'd be interested in some kind of verifiable backup for that "clear >> demand" claim >=20 > To me, it seems intuitively obvious. For example, in the Office 365 > web interface, I see logos from several different companies in the > list view and the sender photo when I open the message - Amazon, > Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is > displayed via Microsoft's Brand Cards program). My old Yahoo Mail > interface has something similar. For a while, Gmail showed a company > logo pulled from its Google+ page. >=20 > How does this not show demand? Isn't this an example of web mail > providers wanting to enhance the user experience, and companies > happily obliging, and me as a user being pleased? > > I am not representative of the entire space, but I really *like* > those sender photos. Right. And nor am I representative in my dislike of such. >=20 >> I use the Internet. I do not want logos added to mail headers that >> increase the attack surface of my MUAs, (and MS/MTAs), that likely >> enable additional tracking of mail users, including me, and where >> mobile device and web MUAs are unlikely to offer me an option to=20 >> turn all that off, even if some desktop MUAs might (eventually), at >> the risk of making messages harder to comprehend. >=20 > I'm not sure I understand this comment.=20 I'm not sure which bit of my para above you mean. If it's the last point - I often get mail now where substantive parts of the mail are only present in HTML and I don't render that in my latop MUA, which forces me to occasionally delve into the raw message to find out what some correspondent means. The desire for dancing kittens in HTML body parts does sometimes make emails less comprehensible. I reckon incorporating images as per bimi would have a similar effect. > The logos are not added to > mail headers, but instead headers point to a location where the logo > can be picked up and then shown to the end user. What's the > difference between the sender/brand providing an authoritative source > (DNS record that points to a CDN) vs Office 365/Yahoo pulling from > their own internal database? Aside from John and Dave's points another difference is that I don't need to care about the latter, (as I don't use 'em) whereas where bimi a standard that got deployed then my MUA may add such (from my POV) broken-ness. >> I also just do not want to see your logos, thanks. >=20 > Again, I am not sure I understand this comment. John answered that I think. > Logos are everywhere. Most large companies have Facebook and Twitter > pages, and they all have logos. You see logos painted on the sides of > walls, on stores, on TV, in newspapers, on web pages, as favicons, > etc. >=20 > Are you saying these are all fine but in the sender photo it isn't? > What's the fundamental difference between seeing a company's logo in > the sender photo vs seeing it in the body of an email? Is it just a > matter of turning of HTML and preventing those from loading? I don't see sender photos and do not render HTML, except on mobile device MUAs where I do not get that choice, which is, for me, negative. Were bimi standardised it is entirely unclear to me how various MUAs might handle it. But I very much doubt that mobile device MUAs would provide that level of user-control for bimi as they do not for bodies. And all of us here are likely far more capable of configuring things than most users. >> As someone who sends email (not as a bulk sender) from various >> domains that I operate, I do not want to pay =E2=82=AC=E2=82=AC=E2=82=AC= to someone for an >> additional cert, nor for an "approved" logo, in order to increase >> the chances that my mail gets delivered. >=20 > Nobody is going to make you buy a cert, nobody is going to make you > buy a logo, and so forth. It's up to you. >=20 > BIMI is an add-on; it augments the default experience, the lack of it > doesn't downgrade the default experience. Perhaps. Nonetheless there is at least one large mail service that sends all mail from some domains I operate (that have never sent spam and that have had stable IP addresses for years, DKIM etc all good) to /dev/null and who won't respond to any form of poking to try get that fixed despite a number of attempts. And that provider is used (as MX) by people with whom I do need to correspond, so I'm forced to use a different mail a/c to mail those folks. Yes I do indeed fear that bimi could and would be (ab)used by some services to do more such dis-service. ISTM that damages the mail environment rather than enhances it. >> I also do not want to have to check if someone else has abused a >> logo I may use in some CT log. I do not want to have to process >> additional headers in my MTAs nor retrieve and store your logos in >> some new image store. I do not want to have to deal with any of the >> new problems that'll arise when any of that breaks. >=20 > Again, I'm unclear about the context of this statement. Nobody is > going to make you as a sender, brand, or receiver send with BIMI. I'm afraid that continues to be a concern of mine. (As an aside, I am not a "brand" and have no ambition to become one:-) > Nobody is going to make you retrieve logos from a store, nobody is > going to make you verify any log, nobody is going to make you process > additional headers. In fact, my reading of bimi is that it does attempt to force a receiving MTA/MS to actively download the image(s) and replace the URL with one pointing at the MS (or nearby) - not doing so would expose users of the MUAs using that MS to tracking once those MUAs de-reference bimi URLs from the sender. > Instead, it's about enhancing the email experience for those > motivated to do so. And, BIMI provides a way to do this. I realise that's your/the proponents position. Mine is that bimi is only a negative. Cheers, S. >=20 > --Terry >=20 > ________________________________ From: bimi > on behalf of Stephen Farrell Sent: > Thursday, February 14, 2019 2:57 AM To: bimi@ietf.org Subject: [Bimi] > (non)desire for bimi >=20 >=20 > (Sorry for not replying in-thread but I just subscribed to the list, > and this perhaps also deserves a separate thread.) >=20 >>>> * Internet users want it - clear demand >>>=20 >>> That claim keeps being made but I've never seen any serious=20 >>> documentation for it. >>=20 >> Marketing people want it -- that may not be documented but I have=20 >> sufficient anecdotes to hand to believe it be the main driver >> here. >=20 > I'd be interested in some kind of verifiable backup for that "clear > demand" claim - I'm unaware that such exists, other than perhaps as > Richard says for marketing purposes, and ISTM those purposes are > amply met already via mail bodies. >=20 > Meanwhile... >=20 > I use the Internet. I do not want logos added to mail headers that > increase the attack surface of my MUAs, (and MS/MTAs), that likely > enable additional tracking of mail users, including me, and where > mobile device and web MUAs are unlikely to offer me an option to turn > all that off, even if some desktop MUAs might (eventually), at the > risk of making messages harder to comprehend. >=20 > I also just do not want to see your logos, thanks. Imposing those on > me would decrease the utility of mail. And regardless of what PKI > were built I would not treat bimi'd messages any better, more likely=20 > I'd consider them badly. >=20 > As someone who sends email (not as a bulk sender) from various > domains that I operate, I do not want to pay =E2=82=AC=E2=82=AC=E2=82=AC= to someone for an > additional cert, nor for an "approved" logo, in order to increase > the chances that my mail gets delivered. Things in that respect are > bad enough, and this proposal seems to me likely to only worsen the > situation for those who operate small domains, presumably to the > benefit of those who operate large mail infrastructures and CAs who > issue certs for money. >=20 > I also do not want to have to check if someone else has abused a logo > I may use in some CT log. I do not want to have to process additional > headers in my MTAs nor retrieve and store your logos in some new=20 > image store. I do not want to have to deal with any of the new > problems that'll arise when any of that breaks. >=20 > So: No thanks, from me. Personally, as a mail user I only see > downsides to this whole idea. >=20 > Thanks, S. >=20 >=20 --------------7A19CF0B89F0263CB6AE4095 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------7A19CF0B89F0263CB6AE4095-- --d5WA0LA1MnT8xFPpBUoTNOnxVcQQmEJ0i-- --t9wpQ5V5bYySZWvkKB8HfSQQyxqYM5JvC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxltxoACgkQWrL68XsX K+oCgw//f+k/BY/NL0hMnyuUp7e7UV1jBKYEbxc5PfBfMqdc/RWxzL1jpILFYlZC akUuVqgYsaMWf8NPOchlVCEoaLkEh+seNezNd5qFQPDdYNDVlOcluDcd1C1viRDa XKyp6bbFxAGwdRIa2hfR8VGf0gYUi3PjtyUAOiqyRPgrr8PO1E03/+eM3LH2tepU 1ygWaqd1vz1/DxQ26ddjPVpd3JQJXwOj/T3xkqU/xi3sfz37jIn7jY19C2daCGgL iw/9Sv79em4da2WXUis8MCa4Aik3/nMDoqdFZbDi+j3Qf98orzqPgYmFlwQFvj4w ZnLzBhjRyO6P/eYHYDkd3tKGKhwiajiO5ixPKJ7mjxcrsnCvjTP03gVePbMkoKoc rXNID2VisHSoSeZkx/BMsKIKW5uHNNmd14z6rKPjWj7GqhSyN/USaAdvmyx8GDeb fwxxzVJl4PMWv7fxvH1kCX83+X3x5Tw39VYkxn9L40PTZ85cpz97N8f6FedphPBp a43Z2Przj0iHbIIm4C5GQJM/jjCKWpTGLq2tLaMukJNW/0nNtvy0bQL3GIJ7xEwn stCZoy2lWrNqsMO9CSvUOw0d83Oonv1V773CaRYCIY9WgRfgtLpyFo+FmFWQfu+b eA3AgRS4UDrfYBZpvcHBM/Ual8PuyK8ZSZwIOQL3C+2aWuEQBYI= =EiXa -----END PGP SIGNATURE----- --t9wpQ5V5bYySZWvkKB8HfSQQyxqYM5JvC-- From nobody Thu Feb 14 10:57:35 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2291200ED for ; Thu, 14 Feb 2019 10:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi9qbLT6jdDo for ; Thu, 14 Feb 2019 10:57:29 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1C91288BD for ; Thu, 14 Feb 2019 10:57:28 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id 2so2810688ybw.4 for ; Thu, 14 Feb 2019 10:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yzO2G4AlrVREcq0tkJs7diQGqv89l+9S6T8B4o/VYyY=; b=nr5a2xqm6c5ejrO9Vu/rjWNtRC+jSEWkq+snZsDN2JXCq9Wq1aU09TZBF/1ie7M8C8 K1u+8qxizS+lupdoiK1wIOuSHe8Ln/s9RXklU+MAbfz+jK6IlY4v3A1otX89/Sdp7eoI AJxGJEJVDwpFuWi9Xqq0+luM+HVWLSYydGxko= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yzO2G4AlrVREcq0tkJs7diQGqv89l+9S6T8B4o/VYyY=; b=tqzgUweoMqFFKLOsPWcFuV6beOvHtI9vPSVIZZ9BYVKyIxwMXyeKYviGzheuRf6RaW /CR0fKL6NWfD8BSqYe8KZTmgHbaMKz8XpFshUmv5VbE2NghRRMj2/laZ2oKEWu9m4IVM y6GvhjOJfdZyVviKvb9HygAuqXmKYH6P+z4aqOOpmF/hkFR8nWECiprk9E3Yh2beFb5Q 0xbC/bzGRmX/Mw1ikW4zuJ2p4HWcREMv3vPZDFlCg0ug8FMbedJ7X1ZCWYy15QZ2/uB6 DA3EPmU2JoaD0R6RqiLtPL6RaBZqMxussLN8jcmrMzMcU9sZ4Zj3wP8FQIcEj2htVNgz iXRw== X-Gm-Message-State: AHQUAuZG47nLgKTtiu/qzIrq3FlPTspVg2YH2uDxdcHqc+6+zZ10Vy5b pHwKzFIvB+28BYEk3qG1aY2I/w== X-Google-Smtp-Source: AHgI3IYcMG4HLoO+qhPm/FsIQTPAV9ii0T08yyR3wXt8FTULI11hVgQKW/Z541JPCsjooeyWu6VHwg== X-Received: by 2002:a25:a1e1:: with SMTP id a88mr4674250ybi.187.1550170647249; Thu, 14 Feb 2019 10:57:27 -0800 (PST) Received: from ?IPv6:2620::690:7822:ec17:f79d:ffca:6133? ([2620:0:690:7822:ec17:f79d:ffca:6133]) by smtp.gmail.com with ESMTPSA id 77sm1213958ywr.19.2019.02.14.10.57.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 10:57:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: Date: Thu, 14 Feb 2019 13:57:25 -0500 Cc: Wei Chuang , "bimi@ietf.org" , John R Levine , Tim Hollebeek Content-Transfer-Encoding: quoted-printable Message-Id: References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:57:34 -0000 Hi Dave,=20 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. =20 > On Feb 13, 2019, at 13:22, Dave Crocker wrote: >=20 > Thede, >=20 > On 2/13/2019 8:38 AM, Thede Loder wrote: >>> On Feb 11, 2019, at 16:14, Dave Crocker > Some reasons in favor of scale: >=20 > 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. >=20 > So... >=20 >=20 >> * Unlike 30 years ago, there are now 50+ Certificate Authorities=20 >=20 > 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. =20 It would be interesting to know:=20 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. =20 If you or someone else has a good sense of this, please enlighten and = let's not repeat history. =20 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. =20 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. =20= 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)? =20 >=20 > So the question is why this proposed use will enjoy a better outcome? >=20 > 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. =20 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. =20= Then there's CT, but I'll come back to it in the context of Richard's = post. =20 >=20 >=20 >> spanning the globe and serving a mix of market consituents, large and = small. Supporting VMCs are operationaly incremental. >=20 > 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. =20 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. =20 >=20 >=20 >> * TLS certificates are well known to individuals and organizations = large and small. They didn't even exist 30 years ago. >=20 > 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. =20 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). =20 Overall, VM Certs are significantly different from TLS certificates. = Perhaps their efficacy will more closely meet expectations, perhaps not = :-)=20 >=20 >=20 >> * 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) >=20 > 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. =20 > 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.) >=20 > That's quite different from trusting a displayed mark to an end user. Yes, absolutely. So we'll have to delve into this. =20 >=20 >=20 >> * DNS scales (or we have bigger problems) >=20 > I'll guess this should translate into: BIMI is built on top of an = existing platform of services that are known to scale well. >=20 > 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? =20 >=20 >> * Internet users want it - clear demand >=20 > That claim keeps being made but I've never seen any serious = documentation for it. >=20 > 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). =20 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. =20 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. =20 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. =20 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. =20 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. =20 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? =20 (the quote below repeated for context)=20 > 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:=20 1) Improved Safety*=20 2) Improved ease-of-use*=20 * 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. =20 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:=20 o building codes enacted by governments and enforced by inspectors that = improve building survivability in earth quakes=20 o highway design and construction codes that improve the safety of = highways=20 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.=20 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. =20 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. =20 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? =20 >=20 >=20 >> * there is no "rocket science" involved; the formats, process and = supporting technology are straightforward extentions and analogous to = what is already in practice today >=20 > 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. =20 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. =20 Alignment and will, as we know from history, puts rockets on the moon. =20= >=20 > 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?=20 >=20 >=20 >> * authentication schemes necessary for safe use with a primary = anticipated application having 2 billion users is already widely = supported >=20 > This seems to be another component-level comment, but I'm not certain. >=20 > Hoping that you are not commenting on the underlying crypto = algorithms, I'll guess you mean SPF, DKIM and DMARC. =20 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. =20 > 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. =20= Clarifying and streamlining documentation for implementors, I think of = that as our (collective) jobs. =20 >=20 >=20 >> * 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 >=20 > The internet is global. How things work in a particular country are = generally not that relevant to Internet standards work. >=20 > 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. =20 >=20 > FWIW: >=20 > The string 'mark' doesn't appear in = draft-chuang-bimi-certificate-00, draft-chuang-bimi-certificate-00 >=20 > It appears in draft-brotman-ietf-bimi-guidance-00 in a = hypothetical context. >=20 > So I assume the serious effort on this is in the nascent Verified = Mark Certificates Usage(*) document? >=20 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. =20= >=20 > (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...) >=20 >=20 >> 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. >=20 > 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.=20 Thank you,=20 Thede > d/ >=20 >=20 > (*) = https://docs.google.com/document/d/1OzL9FqexZpZJQuoqAK2E3sXjOwEcLNCvXW7e88= Olt2I/edit#heading=3Dh.h31mzi4ac5st >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com L: https://www.linkedin.com/in/thede M: 415-420-8615 From nobody Thu Feb 14 11:16:24 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9462C129441 for ; Thu, 14 Feb 2019 11:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0IndHJeQYQm for ; Thu, 14 Feb 2019 11:16:22 -0800 (PST) Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E6A12867A for ; Thu, 14 Feb 2019 11:16:21 -0800 (PST) Received: by mail-yw1-xc2f.google.com with SMTP id x21so2749788ywx.11 for ; Thu, 14 Feb 2019 11:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oAY9wrqTKAuUg40d0QErImum990Z/uNwuPfRcDbcEUE=; b=Mv+KWlpcRkL0T834Trj4HxHSlOtejudmGvgF+5WDaAPeNsACKTYzrA6E0HklfxWPFr F4E5WC+Df5IW7HIpwocB86rokFEMzaJZDq3NpvtdGzK7ZJKTUGKe0dH8lYtCMonIVsbU w8k233iupxct+jcTmKIjoM8t6NjGkCtq1Nu64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oAY9wrqTKAuUg40d0QErImum990Z/uNwuPfRcDbcEUE=; b=IoEvcMX1THjWJ+SZVruTFZzAJxUSCruApDjWciRaQpcG/jzHU6GoDP4Lq1GXarhw8p KIRDPZ6h7j1p0pS6zGoE8lzj+NYDaFjUAyKiBlUd4s1KkyAMOqAzMJpCBKFwT3w+HLRZ pXpfVGnWiNaGswZJ6qUhLRjsybq0A69JQiMJaTrhpX2KK80JdDqgwVlQeiLvhyV3LMvH eJoawbdiyXawPOI2UDBaAe2yR4xx+P4yyRJ9ajLzCjvApzb9u6+v1CgXloWW8jljmz6I Uu3hfj2abPp3POG3PUgruO8/5ZBDU0n0GpMmYJCkSE+iGU7cOZ5yTaJjzMfG0NdXzdp/ 8s9g== X-Gm-Message-State: AHQUAubjoinvz0399r9Ld/ulqhOEDX3citUeiLkOvbTMvjocheuMpPSc 4N3yfHJrQQAayd2tmodAZXLp4g== X-Google-Smtp-Source: AHgI3IaZOISfDlTOH1Flu+hqsFt7V2rtoUnmvXYfnsoSTVpb8Je1DswGE0Ou3dmnxiCr1wy0aXxL9g== X-Received: by 2002:a81:5fd5:: with SMTP id t204mr4552007ywb.312.1550171780918; Thu, 14 Feb 2019 11:16:20 -0800 (PST) Received: from ?IPv6:2620::690:7822:7162:f332:f7c8:d6f9? ([2620:0:690:7822:7162:f332:f7c8:d6f9]) by smtp.gmail.com with ESMTPSA id 206sm1518356yws.95.2019.02.14.11.16.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 11:16:20 -0800 (PST) From: Thede Loder Message-Id: <0C4A5662-D199-4898-9E72-615EC3523D52@skyelogicworks.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F33F1678-9392-480F-BCF6-10597F8BA36B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 14 Feb 2019 14:16:19 -0500 In-Reply-To: Cc: Terry Zink , "bimi@ietf.org" To: Dave Crocker References: <20190214175243.950C2200E509D1@ary.qy> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:16:23 -0000 --Apple-Mail=_F33F1678-9392-480F-BCF6-10597F8BA36B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 14, 2019, at 13:35, Dave Crocker wrote: >=20 > On 2/14/2019 10:23 AM, Terry Zink wrote: >=20 >> Yes, there are some people that don't like this type of UX. And with = BIMI, you'll still be able to use the same software that doesn't show = images, HTML, sender photos, etc. There's no change there. >=20 > This is another fundamental usability design error: thinking that = adding something is fine because users can turn it off. This burdens = users, and often creates a barrier because they don't know how to fix it = or even that they can. I think Terry may have been saying that there are MUAs already in use = which do not display images by default, or cannot at all. For example, = pine, elm, mailx. There's not going to be any burden to end users of = these, as there's nothing to swtich off. =20 To Dave's point, if MUA maintainers adopt BIMI in MUAs for which logo = display makes sense (from their perspective) and they turn logo display = on by default, for people who find logos annoying there will be a burden = to turn them off, if such an option is provided. =20 Thede --=20 Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com L: https://www.linkedin.com/in/thede M: 415-420-8615 --Apple-Mail=_F33F1678-9392-480F-BCF6-10597F8BA36B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 14, 2019, at 13:35, Dave Crocker = <dhc@dcrocker.net> wrote:

On = 2/14/2019 10:23 AM, Terry Zink wrote:

Yes, there are some = people that don't like this type of UX. And with BIMI, you'll still be = able to use the same software that doesn't show images, HTML, sender = photos, etc. There's no change there.

This is another fundamental usability design error: =  thinking that adding something is fine because users can turn it = off.  This burdens users, and often creates a barrier because they = don't know how to fix it or even that they can.

I = think Terry may have been saying that there are MUAs already in use = which do not display images by default, or cannot at all.  For = example, pine, elm, mailx.   There's not going to be any burden to = end users of these, as there's nothing to swtich off. =  

To Dave's point, if MUA = maintainers adopt BIMI in MUAs for which logo display makes sense (from = their perspective) and they turn logo display on by default, for people = who find logos annoying there will be a burden to turn them off, if such = an option is provided.  

Thede


-- 
Thede = Loder
Managing Director, Skye Logicworks LLC
M: = 415-420-8615


= --Apple-Mail=_F33F1678-9392-480F-BCF6-10597F8BA36B-- From nobody Thu Feb 14 11:26:11 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA6212426A for ; Thu, 14 Feb 2019 11:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Tsqu71v0kIK for ; Thu, 14 Feb 2019 11:26:08 -0800 (PST) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C081200ED for ; Thu, 14 Feb 2019 11:26:07 -0800 (PST) Received: by mail-yw1-xc2b.google.com with SMTP id k188so2775941ywa.6 for ; Thu, 14 Feb 2019 11:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QC2UTKilFDlGX06JGtCl5t2m/4iJWGBrEu3U0JKWXb8=; b=avZ3WFz4qHo1leaXA+Nt6L37JphWPBOhIX9uBc0GNE+iGEIg7OJ2ttjSCFZwiL6Itb yzwip8XoLTwWxnSs+wKrdYf5JviH4TpElbglEkN9C1OECt1wUO3yhLhEDc44amwor5AQ SByK5koT7UD0WUcfLT/BIfBkY7xQpNeyTIihA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QC2UTKilFDlGX06JGtCl5t2m/4iJWGBrEu3U0JKWXb8=; b=eUsjL9gEsx2AprPjVL4UZ+RSS6xm5avFuztS6h+YVqn7TKqQN2KQIzMcZGAW4kKl3Z PN9zy5TBriEY57kcbjBIottL8rR48+Knu0AVyHGs3XTrGMCEkElSBpRKH3k4eDIRhzIn Hg5kKMEZquNMoANP0z74ccPCKClOv55w+/gCjOr+bU6XQz3f4AmQQWnoTUl18UQur/en qHn+7b82HMhG6hepatfo2FUcTLdFTjWu9XoKjaOCCHzFf9G5uK5Cd9NRpZlo9FHXuk/2 VsuhKYyzGVy62OWJo9zN2PUkPJiG4xZ9wblX7d0Vw7mk+B5EKUP0oAbCdC+Y2lQQky98 8nMg== X-Gm-Message-State: AHQUAuYRFLCCGIvV24eFfgfbaKwsNxdAzzDA+A28uzwqGF20CI9zIXw0 jP6J/8gdWqe/xGa0cXYOz1g7AA== X-Google-Smtp-Source: AHgI3IaJThmEE3aR0KkkmPUG3QN28jqI+fTlYbj/sGQn1GUZq7VJgJ/tkIwaiqbuqmJU4uIXplG21w== X-Received: by 2002:a81:1017:: with SMTP id 23mr4751279ywq.72.1550172366788; Thu, 14 Feb 2019 11:26:06 -0800 (PST) Received: from ?IPv6:2620::690:7822:7162:f332:f7c8:d6f9? ([2620:0:690:7822:7162:f332:f7c8:d6f9]) by smtp.gmail.com with ESMTPSA id v4sm982689ywb.98.2019.02.14.11.26.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 11:26:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: <20190214175243.950C2200E509D1@ary.qy> Date: Thu, 14 Feb 2019 14:26:05 -0500 Cc: bimi@ietf.org, tzink@terryzink.com Content-Transfer-Encoding: quoted-printable Message-Id: <44BEEBF3-D4A9-4EF9-995C-B88A13FAC462@skyelogicworks.com> References: <20190214175243.950C2200E509D1@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:26:10 -0000 >=20 >> I'm not sure I understand this comment. The logos are not added to = mail headers, but instead headers >> point to a location where the logo can be picked up and then shown to = the end user. What's the >> difference between the sender/brand providing an authoritative source = (DNS record that points to a CDN) >> vs Office 365/Yahoo pulling from their own internal database? >=20 > It makes it in effect another web bug. The topic of BIMI potentially enabling another form of tracking or "web = bug" has come up in discussions. =20 Speaking for myself, my general sense is that no one substantively = involved sees creating yet another tracking capability as a benefit, and = that we should avoid doing so if possible.=20 This is not the same as saying we've provably designed a system that = denies tracking. That would be better. =20 Overall, I think we need to address this issue head on, with a careful = analysis. =20 Thede >=20 > R's, > John >=20 > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi From nobody Thu Feb 14 11:31:23 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE171311A2 for ; Thu, 14 Feb 2019 11:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=YtXbv91B; dkim=pass (1536-bit key) header.d=taugh.com header.b=SRlBgmtZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcOJCqLciAN4 for ; Thu, 14 Feb 2019 11:31:14 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06809131179 for ; Thu, 14 Feb 2019 11:31:13 -0800 (PST) Received: (qmail 72196 invoked from network); 14 Feb 2019 19:31:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11a02.5c65c1ff.k1902; bh=LaX9lhnVyqhBB6dV84ozqDTxTCoAv3h7W/ImT3wPOdc=; b=YtXbv91BWiLEXNKHuq3mIHMWjv4n4aT02S2bE07Y/8QOaBjMU5CtbBLKqFFAjdIJ6vNwyCXx3jpEbX0g4FVHeI2zRJfgMwU5OL8DQ+DtEhwRwIHTl1PtUTEgt1QvGOfPQwUklxdmqrYjr3wLSf1iYPmAyWoGFt8nT7okpTBfUA6EZv7pDR/SSZkrWYcYd76zb6jPgzEYnwAqmsyXMdqnLEkXgbyFrh6M6ZotYvbIt2tTvtq+S0heoK2O+sgXCDJK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11a02.5c65c1ff.k1902; bh=LaX9lhnVyqhBB6dV84ozqDTxTCoAv3h7W/ImT3wPOdc=; b=SRlBgmtZt8FocdnP67B8yOVBsPJ9gJlMNAnN5a/ej+mtTGx+JtKrKBi/REMrFozSumiFUMKssskZR0FKV7ojDWbe67HeAiU4jnnDvlt8Fb8KeRW7Q6Gwn7x0ssjCPQ4S7IotYO9B1vGzLeG+VrMSY75OrGBVxuGLCKjhkXrRJUbm0TWHKBCZgP96y0wFgHAVv4zkOHvAcaWsWd6dgXwL1IzMXJgQTVk95bXeekMAUUGNaLV+Q+9O6Qx8pUERhPmk Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 14 Feb 2019 19:31:11 -0000 Date: 14 Feb 2019 14:31:10 -0500 Message-ID: From: "John R Levine" To: "Thede Loder" Cc: "Dave Crocker" , "bimi@ietf.org" In-Reply-To: References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:31:22 -0000 > 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, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Feb 14 12:47:28 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C0412D4F2 for ; Thu, 14 Feb 2019 12:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hCmcpcIy0g3 for ; Thu, 14 Feb 2019 12:47:24 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF01129532 for ; Thu, 14 Feb 2019 12:47:24 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1EKmaSN003739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Feb 2019 12:48:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550177317; bh=MopL2o8ej9m2WG1FgmQvfI/rJE58uNaTxqAiZ3jsq5g=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=K2c/gs4J5SmAfDxpoO6iksX7H3Iz3xz3BcaGowJI/Eb14bqoLEovrT5DHOKDbQXBk EErOgYoVeGoTDxY9uCbs7yzA3IVYynaFDOTZsjlV+G+rw6MlqieS5wt20O+bKsA1cY Igfys0rkbOpFreiWvbNZpH2FljRWeA4rN+i/ZApo= To: Thede Loder Cc: Wei Chuang , "bimi@ietf.org" , John R Levine , Tim Hollebeek References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <06280007-fcdb-fbed-3711-ad7ed26c287b@dcrocker.net> Date: Thu, 14 Feb 2019 12:47:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:47:27 -0000 On 2/14/2019 10:57 AM, Thede Loder wrote: >> On Feb 13, 2019, at 13:22, Dave Crocker wrote: >>> * 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'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. > Did X.500 prove not up to the task because it failed on technical > 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. >> 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. 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. >> >> 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. 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. >>> * 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). 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. > Speaking for myself, I see two forms of benefit for end-users: > > 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. >>> * 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. 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 > moon. 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/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Feb 14 15:36:44 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1D91289FA for ; Thu, 14 Feb 2019 15:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=terryzink.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t42aaeikExZ for ; Thu, 14 Feb 2019 15:36:39 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690070.outbound.protection.outlook.com [40.107.69.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC5C128B36 for ; Thu, 14 Feb 2019 15:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=terryzink.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6hAUPv4fafOidboA9nTqThdcTyRlyrkeBrQNBKQR/uQ=; b=pDEk7voP2waN6fvVF5KCmU8nwoEtwolaaW4QoWSPVAno15zv9pZh00KJEA+WGWHLNDlmLDjmITdhwZg0uflVMdupReFMXWFqQcEGyyvGxhL4LEHXWdn65RKZ837ASrW0yVTpV7ZnD9eh4kEv1sXoVEbrCbPgkSc4PER6hG8P1so= Received: from BL0PR11MB3107.namprd11.prod.outlook.com (20.177.205.141) by BL0PR11MB2993.namprd11.prod.outlook.com (20.177.204.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 23:36:35 +0000 Received: from BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda]) by BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda%3]) with mapi id 15.20.1622.016; Thu, 14 Feb 2019 23:36:35 +0000 From: Terry Zink To: "bimi@ietf.org" Thread-Topic: [Bimi] (non)desire for bimi Thread-Index: AQHUxFQrlnICsfeFJUyWrugVUJNeRqXfg1XEgAAetACAAEy+qg== Date: Thu, 14 Feb 2019 23:36:34 +0000 Message-ID: References: , <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> In-Reply-To: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@terryzink.com; x-originating-ip: [2620:10d:c090:200::4:2f3b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa0d08e5-70a6-434a-d8f7-08d692d541f0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BL0PR11MB2993; x-ms-traffictypediagnostic: BL0PR11MB2993: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; BL0PR11MB2993; 23:szWiE580t4Ajogk5BIw3iDAHu8NOw72HFqmg9?= =?Windows-1252?Q?tQHyn+CY2Xbf0T/83Cjd1ybK6KP5fQ6GC5FQ6gV/r6vUO3p5JBzRvqCx?= =?Windows-1252?Q?LNU5qQGFPugK8cMsyNBz3pQVQhIx+R5FPlTUyTwl0284oRWcPBqvmBJY?= =?Windows-1252?Q?hxO75m6+Oz9qvZ7mksRPFtlK/0SIqL0rEwHAKwckmZftAoVqaA4vM7dM?= =?Windows-1252?Q?G+lcZD0uvDjNq5jNeZb5sYsUlT7MiuWL4eKU2j4xmkokK7u61UmsY2Pl?= =?Windows-1252?Q?F8XKpNWXqYcCq85MaVvKGtudpkbxBBKi7iBa1li108huTnHSsk4w/cJ9?= =?Windows-1252?Q?UjaZkh3jZDafN1HDXwyzIdL8Clz0aAvyuJZyN6iBTNSk/LQ2uSTtU6TR?= =?Windows-1252?Q?KGHtMxzc/9jt3QKuqyRzLRyH+CX0LFK8BI+voPqFXJzpbyBwP3uCYMdp?= =?Windows-1252?Q?M7bLssagR+VatSUyrn/374XBgJHFnj1HWM5LeJW6mDShQ0CvuedF+zMq?= =?Windows-1252?Q?yAXkSD7xLlYdGSA3V/fyF0CHhFDooaPHbA2axtFZmoCwhmDrgtC9W/1y?= =?Windows-1252?Q?7ohv2ZxehM5tCPqYmCFM3xmuX84GFV88K24QAZTPyorSh4VmrCgAkAvp?= =?Windows-1252?Q?mOgx/11gmkA7k0NUVTJ77FHyjzJzQWjSestvsG2JjoDs5pncuLj7ztr7?= =?Windows-1252?Q?o/EMzgKjeWelLjkA1JdC5tq3wOIW5jFv0AsKlawHXwmmrIdauTJQwLWL?= =?Windows-1252?Q?UUsN1lHZNJzOKNmH0WkJhETdVa9Mxef9pRfhoKa9bCxupbR4Wcsvxlu9?= =?Windows-1252?Q?ALHF98AGh2h3lPRbp2/ZBQ0Uqbdn5sRJ+p6l7ik/pfSNAmyx5Xb2zxy8?= =?Windows-1252?Q?8j5yWRTvv4oEk2aBU7CnkcirHS0LYmzkf208Hu22xv63ARXI1MmeyMr7?= =?Windows-1252?Q?SWsRYNDL2TWh4xoEMcdoJlnrUT9UeZwPjg1HLjVZljPbYdrrDZnWx5YQ?= =?Windows-1252?Q?U6wlJ6xihAJLpRTERto4v/JJTovknEiovkPCNkKmbECXAj+P79zJ89PJ?= =?Windows-1252?Q?7jJo8HTz0ZzmCFP5g9Q4iOIC6iMAk+JYDoMYp7tY93UkmoA4UjbStGbE?= =?Windows-1252?Q?gaKs3jDw2aliSOjSjg1baNph0QJtXc8+rRyubel8nYlLJeF8ABQsfeH5?= =?Windows-1252?Q?jm1us0d0trNSfNEejI8Hb5JD2gY5rwInMDpodr2yMglwJWjhLIe8I3wD?= =?Windows-1252?Q?5Itp9VF3bNcXXcLoV5mFBaHs7VVHfDrlQE3zZMzwIP4ciwj/sO3A2i/h?= =?Windows-1252?Q?53K0pd/WqSpj7xEmD+/QD6MbaQ+EV/Y217zqVBwesBzSiNjLppItJnfE?= =?Windows-1252?Q?q+L7Fp8SKGi79O14B3GftwnQ2s8Coa1q3Oxcm22nrhkPYRUnT1DqvbBS?= =?Windows-1252?Q?CBEbq+L05IfftjxEwlXGvsLZ2nTvHMhEIU1eAmyNqMe5fTUws1NT5ArM?= =?Windows-1252?Q?4zWsEw=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(396003)(366004)(376002)(136003)(346002)(199004)(189003)(2501003)(81156014)(1730700003)(45080400002)(2906002)(8676002)(76176011)(25786009)(316002)(81166006)(7696005)(68736007)(71190400001)(6116002)(71200400001)(486006)(5640700003)(55016002)(476003)(14454004)(561944003)(9686003)(54896002)(7736002)(8936002)(6436002)(66574012)(2351001)(102836004)(33656002)(19627405001)(11346002)(74316002)(53546011)(6246003)(6506007)(6606003)(97736004)(446003)(229853002)(46003)(86362001)(105586002)(566704002)(256004)(14444005)(186003)(6916009)(53936002)(508600001)(99286004)(106356001)(30864003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB2993; H:BL0PR11MB3107.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: terryzink.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qP78H9RsaQzIBOi2gTukKrCUD991LjI+tQpU8ZOkYz7PamZBiHI0smUfvVbxqbfpBZfTyY/4WK4NqI600A8bTyctQdTg664FTonUNTrSJ9PQIE6yrSyGfWZocfeRozUktAYWWsVzxj7d3HtpeMSnaaJPTISRrvlyiNa9ogS+6YY0g4IQ00LwkhTIEGktK6WW/hSRVQ3wluJIgHtVcZ/qt4YFdZUgkrr9I/D9Uzzvxv0RDoMrQQXSkl+kB/rZBwJohhH+JMiCXTLHRggDdgDZAHUldlVzL7zLSAJRfoax/ZubtLl0zInK+Jf8eyT7vqjl5WYPzWO06yfhGX7i72yVOZh6OXL/7Qj4/gTvTK7XknFU7x2uE92VEyPYuetVjdbHipFWSUwOOulBrAdFSkK6fVsoIoQaG9Ym5jrlKuVIyuU= Content-Type: multipart/alternative; boundary="_000_BL0PR11MB310709095F044652035CD225A9670BL0PR11MB3107namp_" MIME-Version: 1.0 X-OriginatorOrg: terryzink.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa0d08e5-70a6-434a-d8f7-08d692d541f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 23:36:34.9084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 470dd1c0-25dc-4cce-857e-0d65849495b7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2993 Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 23:36:43 -0000 --_000_BL0PR11MB310709095F044652035CD225A9670BL0PR11MB3107namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Stephen, I won't respond to all of your points, only a handful in the interest of ke= eping these responses manageable. > The desire for dancing kittens in HTML body parts does sometimes > make emails less comprehensible. I reckon incorporating images as > per bimi would have a similar effect. Do you think it's kind of a stretch to equate dancing kittens and general l= ate-90's annoyance in HTML with a sender photo? Even in my mail client righ= t now, there's a sender photo - it's a letter "B" for bimi @ ietf.org. If m= y email client decided to show the logo for the IETF instead, you'd find th= at as distracting as loud HTML? > But I very much doubt that mobile device MUAs would provide that level > of user-control for bimi as they do not for bodies. And all > of us here are likely far more capable of configuring things > than most users. It sounds to me like you're saying you want to turn off BIMI logos in an em= ail client. All you need is a checkbox in the MUA? >> Again, I'm unclear about the context of this statement. Nobody is >> going to make you as a sender, brand, or receiver send with BIMI. > I'm afraid that continues to be a concern of mine. (As an aside, > I am not a "brand" and have no ambition to become one:-) I'm trying to understand your position here, but I still don't get it. BIMI is an add-on service; literally every domain in the world could publis= h a BIMI logo, and you might not, and you'd be none the wiser if you stuck = to your plain text emails and MUAs. Are you saying that email receivers wou= ld eventually then force you to set up a BIMI record because the lack of it= would cause your email/domain to suffer deliverability problems? That they= would eventually strong-arm you into publishing BIMI records? >> Nobody is going to make you retrieve logos from a store, nobody is >> going to make you verify any log, nobody is going to make you process >> additional headers. > In fact, my reading of bimi is that it does attempt to force a > receiving MTA/MS to actively download the image(s) and replace > the URL with one pointing at the MS (or nearby) - not doing so > would expose users of the MUAs using that MS to tracking once > those MUAs de-reference bimi URLs from the sender. Where does it say that in the BIMI spec? I helped write and edit some of the first documents for BIMI. For the brand= , you upload an image somewhere, and create a DNS record that points to it.= You then have it signed so that it can be verified by an email receiver. A= s a mail receiver, you use a bunch of DNS checks along with standard email = auth checks to figure out where and if to pull the image. As an email receiver, you could choose to pull it from where the brand publ= ishes it (and therefore deal with the unreliability of everyone else's arch= itecture), or you could pull it locally and replicate it on your own infras= tructure. Indeed, that's already done today. If I'm an email receiver and I= 'm showing images based upon my best guess of what a brand's logo is, and a= brand instead tells me what the authoritative source is, then I go pick it= up from there instead of scraping it from the web. If BIMI requires the things you say it does, I'd like to understand where. -- Terry ________________________________ From: Stephen Farrell Sent: Thursday, February 14, 2019 10:44 AM To: Terry Zink; bimi@ietf.org Subject: Re: [Bimi] (non)desire for bimi Hi Terry, (I agree with both John and Dave's points upthread so will try not repeat those, but I'm happy to elaborate if it's useful.) On 14/02/2019 17:08, Terry Zink wrote: > Thanks for your comments, Stephen. Here are my thoughts. > >> I'd be interested in some kind of verifiable backup for that "clear >> demand" claim > > To me, it seems intuitively obvious. For example, in the Office 365 > web interface, I see logos from several different companies in the > list view and the sender photo when I open the message - Amazon, > Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is > displayed via Microsoft's Brand Cards program). My old Yahoo Mail > interface has something similar. For a while, Gmail showed a company > logo pulled from its Google+ page. > > How does this not show demand? Isn't this an example of web mail > providers wanting to enhance the user experience, and companies > happily obliging, and me as a user being pleased? > > I am not representative of the entire space, but I really *like* > those sender photos. Right. And nor am I representative in my dislike of such. > >> I use the Internet. I do not want logos added to mail headers that >> increase the attack surface of my MUAs, (and MS/MTAs), that likely >> enable additional tracking of mail users, including me, and where >> mobile device and web MUAs are unlikely to offer me an option to >> turn all that off, even if some desktop MUAs might (eventually), at >> the risk of making messages harder to comprehend. > > I'm not sure I understand this comment. I'm not sure which bit of my para above you mean. If it's the last point - I often get mail now where substantive parts of the mail are only present in HTML and I don't render that in my latop MUA, which forces me to occasionally delve into the raw message to find out what some correspondent means. The desire for dancing kittens in HTML body parts does sometimes make emails less comprehensible. I reckon incorporating images as per bimi would have a similar effect. > The logos are not added to > mail headers, but instead headers point to a location where the logo > can be picked up and then shown to the end user. What's the > difference between the sender/brand providing an authoritative source > (DNS record that points to a CDN) vs Office 365/Yahoo pulling from > their own internal database? Aside from John and Dave's points another difference is that I don't need to care about the latter, (as I don't use 'em) whereas where bimi a standard that got deployed then my MUA may add such (from my POV) broken-ness. >> I also just do not want to see your logos, thanks. > > Again, I am not sure I understand this comment. John answered that I think. > Logos are everywhere. Most large companies have Facebook and Twitter > pages, and they all have logos. You see logos painted on the sides of > walls, on stores, on TV, in newspapers, on web pages, as favicons, > etc. > > Are you saying these are all fine but in the sender photo it isn't? > What's the fundamental difference between seeing a company's logo in > the sender photo vs seeing it in the body of an email? Is it just a > matter of turning of HTML and preventing those from loading? I don't see sender photos and do not render HTML, except on mobile device MUAs where I do not get that choice, which is, for me, negative. Were bimi standardised it is entirely unclear to me how various MUAs might handle it. But I very much doubt that mobile device MUAs would provide that level of user-control for bimi as they do not for bodies. And all of us here are likely far more capable of configuring things than most users. >> As someone who sends email (not as a bulk sender) from various >> domains that I operate, I do not want to pay =80=80=80 to someone for an >> additional cert, nor for an "approved" logo, in order to increase >> the chances that my mail gets delivered. > > Nobody is going to make you buy a cert, nobody is going to make you > buy a logo, and so forth. It's up to you. > > BIMI is an add-on; it augments the default experience, the lack of it > doesn't downgrade the default experience. Perhaps. Nonetheless there is at least one large mail service that sends all mail from some domains I operate (that have never sent spam and that have had stable IP addresses for years, DKIM etc all good) to /dev/null and who won't respond to any form of poking to try get that fixed despite a number of attempts. And that provider is used (as MX) by people with whom I do need to correspond, so I'm forced to use a different mail a/c to mail those folks. Yes I do indeed fear that bimi could and would be (ab)used by some services to do more such dis-service. ISTM that damages the mail environment rather than enhances it. >> I also do not want to have to check if someone else has abused a >> logo I may use in some CT log. I do not want to have to process >> additional headers in my MTAs nor retrieve and store your logos in >> some new image store. I do not want to have to deal with any of the >> new problems that'll arise when any of that breaks. > > Again, I'm unclear about the context of this statement. Nobody is > going to make you as a sender, brand, or receiver send with BIMI. I'm afraid that continues to be a concern of mine. (As an aside, I am not a "brand" and have no ambition to become one:-) > Nobody is going to make you retrieve logos from a store, nobody is > going to make you verify any log, nobody is going to make you process > additional headers. In fact, my reading of bimi is that it does attempt to force a receiving MTA/MS to actively download the image(s) and replace the URL with one pointing at the MS (or nearby) - not doing so would expose users of the MUAs using that MS to tracking once those MUAs de-reference bimi URLs from the sender. > Instead, it's about enhancing the email experience for those > motivated to do so. And, BIMI provides a way to do this. I realise that's your/the proponents position. Mine is that bimi is only a negative. Cheers, S. > > --Terry > > ________________________________ From: bimi > on behalf of Stephen Farrell Sent: > Thursday, February 14, 2019 2:57 AM To: bimi@ietf.org Subject: [Bimi] > (non)desire for bimi > > > (Sorry for not replying in-thread but I just subscribed to the list, > and this perhaps also deserves a separate thread.) > >>>> * Internet users want it - clear demand >>> >>> That claim keeps being made but I've never seen any serious >>> documentation for it. >> >> Marketing people want it -- that may not be documented but I have >> sufficient anecdotes to hand to believe it be the main driver >> here. > > I'd be interested in some kind of verifiable backup for that "clear > demand" claim - I'm unaware that such exists, other than perhaps as > Richard says for marketing purposes, and ISTM those purposes are > amply met already via mail bodies. > > Meanwhile... > > I use the Internet. I do not want logos added to mail headers that > increase the attack surface of my MUAs, (and MS/MTAs), that likely > enable additional tracking of mail users, including me, and where > mobile device and web MUAs are unlikely to offer me an option to turn > all that off, even if some desktop MUAs might (eventually), at the > risk of making messages harder to comprehend. > > I also just do not want to see your logos, thanks. Imposing those on > me would decrease the utility of mail. And regardless of what PKI > were built I would not treat bimi'd messages any better, more likely > I'd consider them badly. > > As someone who sends email (not as a bulk sender) from various > domains that I operate, I do not want to pay =80=80=80 to someone for an > additional cert, nor for an "approved" logo, in order to increase > the chances that my mail gets delivered. Things in that respect are > bad enough, and this proposal seems to me likely to only worsen the > situation for those who operate small domains, presumably to the > benefit of those who operate large mail infrastructures and CAs who > issue certs for money. > > I also do not want to have to check if someone else has abused a logo > I may use in some CT log. I do not want to have to process additional > headers in my MTAs nor retrieve and store your logos in some new > image store. I do not want to have to deal with any of the new > problems that'll arise when any of that breaks. > > So: No thanks, from me. Personally, as a mail user I only see > downsides to this whole idea. > > Thanks, S. > > --_000_BL0PR11MB310709095F044652035CD225A9670BL0PR11MB3107namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi, Stephen,


I won't respond to all of your po= ints, only a handful in the interest of keeping these responses manageable.=


> The desire for dancing kittens in HTML body parts doe= s sometimes
> make emails less comprehensible. I reckon incorporating images as
> per bimi would have a similar effect. 


Do you think it's kind of a stretch to equate dancing kitte= ns and general late-90's annoyance in HTML with a sender photo? Even in my = mail client right now, there's a sender photo - it's a letter "B" for bimi @ ietf.org. If my email clien= t decided to show the logo for the IETF instead, you'd find that as distrac= ting as loud HTML?


> But I very much doubt that mobile device MUAs would provide that level=
> of user-control for bimi as they do not for bodies. And all
> of us here are likely far more capable of configuring things
> than most users.


It sounds to me like you're saying you want to turn off BIM= I logos in an email client. All you need is a checkbox in the MUA?



>> Again, I'm unclear about the context of this statement. Nobody is<= br> >> going to make you as a sender, brand, or receiver send with BIMI.<= br>
> I'm afraid that continues to be a concern of mine. (As an aside,
> I am not a "brand" and have no ambition to become one:-)


I'm trying to understand your position here, but I still do= n't get it.


BIMI is an add-on service; literally every domain in the wo= rld could publish a BIMI logo, and you might not, and you'd be none the wis= er if you stuck to your plain text emails and MUAs. Are you saying that email receivers would eventually then force = you to set up a BIMI record because the lack of it would cause your email/d= omain to suffer deliverability problems? That they would eventually strong-= arm you into publishing BIMI records?



>> Nobody is going to make you retrieve logos from a store, nobody is=
>> going to make you verify any log, nobody is going to make you proc= ess
>> additional headers.

> In fact, my reading of bimi is that it does attempt to force a
> receiving MTA/MS to actively download the image(s) and replace
> the URL with one pointing at the MS (or nearby) - not doing so
> would expose users of the MUAs using that MS to tracking once
> those MUAs de-reference bimi URLs from the sender.


Where does it say that in the BIMI spec?


I helped write and edit some of the first documents for BIM= I. For the brand, you upload an image somewhere, and create a DNS record th= at points to it. You then have it signed so that it can be verified by an email receiver. As a mail receiver, you u= se a bunch of DNS checks along with standard email auth checks to figure ou= t where and if to pull the image.


As an email receiver, you could choose to pull it from wher= e the brand publishes it (and therefore deal with the unreliability of ever= yone else's architecture), or you could pull it locally and replicate it on your own infrastructure. Indeed, that'= s already done today. If I'm an email receiver and I'm showing images based= upon my best guess of what a brand's logo is, and a brand instead tells me= what the authoritative source is, then I go pick it up from there instead of scraping it from the web.


If BIMI requires the things you say it does, I'd like to un= derstand where.


-- Terry

From: Stephen Farrell <= ;stephen.farrell@cs.tcd.ie>
Sent: Thursday, February 14, 2019 10:44 AM
To: Terry Zink; bimi@ietf.org
Subject: Re: [Bimi] (non)desire for bimi
 

Hi Terry,

(I agree with both John and Dave's points upthread so will try
not repeat those, but I'm happy to elaborate if it's useful.)

On 14/02/2019 17:08, Terry Zink wrote:
> Thanks for your comments, Stephen. Here are my thoughts.
>
>> I'd be interested in some kind of verifiable backup for that "= ;clear
>> demand" claim
>
> To me, it seems intuitively obvious. For example, in the Office 365 > web interface, I see logos from several different companies in the
> list view and the sender photo when I open the message - Amazon,
> Lyft, Facebook, LinkedIn, Netflix, BackCountry, Quora, etc (this is > displayed via Microsoft's Brand Cards program). My old Yahoo Mail
> interface has something similar. For a while, Gmail showed a company > logo pulled from its Google+ page.
>
> How does this not show demand? Isn't this an example of web mail
> providers wanting to enhance the user experience, and companies
> happily obliging, and me as a user being pleased?
>
> I am not representative of the entire space, but I really *like*
> those sender photos.

Right. And nor am I representative in my dislike of such.

>
>> I use the Internet. I do not want logos added to mail headers that=
>> increase the attack surface of my MUAs, (and MS/MTAs), that likely=
>> enable additional tracking of mail users, including me, and where<= br> >> mobile device and web MUAs are unlikely to offer me an option to <= br> >> turn all that off, even if some desktop MUAs might (eventually), a= t
>> the risk of making messages harder to comprehend.
>
> I'm not sure I understand this comment.

I'm not sure which bit of my para above you mean. If it's the last
point - I often get mail now where substantive parts of the mail
are only present in HTML and I don't render that in my latop MUA,
which forces me to occasionally delve into the raw message to
find out what some correspondent means. The desire for dancing
kittens in HTML body parts does sometimes make emails less
comprehensible. I reckon incorporating images as per bimi would
have a similar effect.

> The logos are not added to
> mail headers, but instead headers point to a location where the logo > can be picked up and then shown to the end user. What's the
> difference between the sender/brand providing an authoritative source<= br> > (DNS record that points to a CDN) vs Office 365/Yahoo pulling from
> their own internal database?

Aside from John and Dave's points another difference is that I
don't need to care about the latter, (as I don't use 'em)
whereas where bimi a standard that got deployed then my MUA may
add such (from my POV) broken-ness.

>> I also just do not want to see your logos, thanks.
>
> Again, I am not sure I understand this comment.

John answered that I think.

> Logos are everywhere. Most large companies have Facebook and Twitter > pages, and they all have logos. You see logos painted on the sides of<= br> > walls, on stores, on TV, in newspapers, on web pages, as favicons,
> etc.
>
> Are you saying these are all fine but in the sender photo it isn't? > What's the fundamental difference between seeing a company's logo in > the sender photo vs seeing it in the body of an email? Is it just a > matter of turning of HTML and preventing those from loading?

I don't see sender photos and do not render HTML, except on
mobile device MUAs where I do not get that choice, which is,
for me, negative. Were bimi standardised it is entirely
unclear to me how various MUAs might handle it. But I very
much doubt that mobile device MUAs would provide that level
of user-control for bimi as they do not for bodies. And all
of us here are likely far more capable of configuring things
than most users.

>> As someone who sends email (not as a bulk sender) from various
>> domains that I operate, I do not want to pay =80=80=80 to someone = for an
>> additional cert, nor for an "approved" logo, in order to= increase
>> the chances that my mail gets delivered.
>
> Nobody is going to make you buy a cert, nobody is going to make you > buy a logo, and so forth. It's up to you.
>
> BIMI is an add-on; it augments the default experience, the lack of it<= br> > doesn't downgrade the default experience.

Perhaps. Nonetheless there is at least one large mail service
that sends all mail from some domains I operate (that have never
sent spam and that have had stable IP addresses for years, DKIM
etc all good) to /dev/null and who won't respond to any form of
poking to try get that fixed despite a number of attempts. And
that provider is used (as MX) by people with whom I do need to
correspond, so I'm forced to use a different mail a/c to mail
those folks.

Yes I do indeed fear that bimi could and would be (ab)used by
some services to do more such dis-service. ISTM that damages
the mail environment rather than enhances it.

>> I also do not want to have to check if someone else has abused a >> logo I may use in some CT log. I do not want to have to process >> additional headers in my MTAs nor retrieve and store your logos in=
>> some new image store. I do not want to have to deal with any of th= e
>> new problems that'll arise when any of that breaks.
>
> Again, I'm unclear about the context of this statement. Nobody is
> going to make you as a sender, brand, or receiver send with BIMI.

I'm afraid that continues to be a concern of mine. (As an aside,
I am not a "brand" and have no ambition to become one:-)

> Nobody is going to make you retrieve logos from a store, nobody is
> going to make you verify any log, nobody is going to make you process<= br> > additional headers.

In fact, my reading of bimi is that it does attempt to force a
receiving MTA/MS to actively download the image(s) and replace
the URL with one pointing at the MS (or nearby) - not doing so
would expose users of the MUAs using that MS to tracking once
those MUAs de-reference bimi URLs from the sender.

> Instead, it's about enhancing the email experience for those
> motivated to do so. And, BIMI provides a way to do this.

I realise that's your/the proponents position. Mine is that
bimi is only a negative.

Cheers,
S.

>
> --Terry
>
> ________________________________ From: bimi <bimi-bounces@ietf.org&= gt;
> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie> Sent: > Thursday, February 14, 2019 2:57 AM To: bimi@ietf.org Subject: [Bimi]<= br> > (non)desire for bimi
>
>
> (Sorry for not replying in-thread but I just subscribed to the list, > and this perhaps also deserves a separate thread.)
>
>>>> * Internet users want it - clear demand
>>>
>>> That claim keeps being made but I've never seen any serious >>> documentation for it.
>>
>> Marketing people want it -- that may not be documented but I have =
>> sufficient anecdotes to hand to believe it be the main driver
>> here.
>
> I'd be interested in some kind of verifiable backup for that "cle= ar
> demand" claim - I'm unaware that such exists, other than perhaps = as
> Richard says for marketing purposes, and ISTM those purposes are
> amply met already via mail bodies.
>
> Meanwhile...
>
> I use the Internet. I do not want logos added to mail headers that
> increase the attack surface of my MUAs, (and MS/MTAs), that likely
> enable additional tracking of mail users, including me, and where
> mobile device and web MUAs are unlikely to offer me an option to turn<= br> > all that off, even if some desktop MUAs might (eventually), at the
> risk of making messages harder to comprehend.
>
> I also just do not want to see your logos, thanks. Imposing those on > me would decrease the utility of mail. And regardless of what PKI
> were built I would not treat bimi'd messages any better, more likely <= br> > I'd consider them badly.
>
> As someone who sends email (not as a bulk sender) from various
> domains that I operate, I do not want to pay =80=80=80 to someone for = an
> additional cert, nor for an "approved" logo, in order to inc= rease
> the chances that my mail gets delivered. Things in that respect are > bad enough, and this proposal seems to me likely to only worsen the > situation for those who operate small domains, presumably to the
> benefit of those who operate large mail infrastructures and CAs who > issue certs for money.
>
> I also do not want to have to check if someone else has abused a logo<= br> > I may use in some CT log. I do not want to have to process additional<= br> > headers in my MTAs nor retrieve and store your logos in some new
> image store. I do not want to have to deal with any of the new
> problems that'll arise when any of that breaks.
>
> So: No thanks, from me. Personally, as a mail user I only see
> downsides to this whole idea.
>
> Thanks, S.
>
>
--_000_BL0PR11MB310709095F044652035CD225A9670BL0PR11MB3107namp_-- From nobody Thu Feb 14 17:00:11 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF87130E57 for ; Thu, 14 Feb 2019 17:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbfIUNC15vA4 for ; Thu, 14 Feb 2019 17:00:07 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A963B130E1C for ; Thu, 14 Feb 2019 17:00:07 -0800 (PST) Received: from [192.168.1.168] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1F11TaT023172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Feb 2019 17:01:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550192490; bh=dM2q2gXqpFrmhn134Ws/0P5KUEra6HJR/CLvBLSYsrE=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=euZE1255eAFSnxkPpcGzTYdPbPu2mi0ZulI+6Xz18p6xS9ON2TXLp8i6+9ibk2z3h VephH8rZKWAeGf5d+P5iWCZRE90OVdzgHC+IDdyx8vbME61ulI0muv012xqfwpnnbZ 4LHL1w7rvhEbNvc4LhCYKwrEBG97QPKX63/qMKtA= To: Terry Zink , "bimi@ietf.org" References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 14 Feb 2019 17:00:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:00:09 -0000 On 2/14/2019 3:36 PM, Terry Zink wrote: > It sounds to me like you're saying you want to turn off BIMI logos in an > email client. All you need is a checkbox in the MUA? Terry, in the context of usability design, language like "all you need is a checkbox" hasn't been credible for at least 35 years. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Feb 14 21:22:45 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E92130F40 for ; Thu, 14 Feb 2019 21:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs6RwzGShe7M for ; Thu, 14 Feb 2019 21:22:40 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92306130F37 for ; Thu, 14 Feb 2019 21:22:39 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id v10so9622794qtp.8 for ; Thu, 14 Feb 2019 21:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l06Jt/+80YewqBKUK5SMs2fy4zoBkHXivqjr9FfZQEY=; b=sext0x7f8Mrm3mTMCDHYNqbojg4LAomt4m3GQdVIdMTh8fQRqrQCl/n56wo163dNQ+ qEqfb6BfGpeqemBGiNXagM3pYFPA/30hXiGp5ycqYTt1A776b5LYAORo7gPLtHQZrkHT ddwY5X9etYewkMl3ax8gmB2ytE78Eu2dz3o5Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=l06Jt/+80YewqBKUK5SMs2fy4zoBkHXivqjr9FfZQEY=; b=kiXLYYZzeeSTJdxvVR1ybtKVzsnTs1QPUN7NhEDif8gmu53eVN7Fm2DMst4zSV50US jJgfwnZkoP4p05DOZ+Iw4bN+sT5Saj4BsoLeN8nFKa+eOTxDkMpuuzi4x52x7RrfHTaI bIk5vUY1ECOuyEQMC1R4CpxXicqxqXThVQrHCxVnwqYXVJRnLR2KB+cv6EjbQjrvwWCY l7RU0WnVK1Uo4TcT1C7v9KJtEBhv3OaerLy0jlyTk+y05yNhO/EMyxwPRZQ2BTBUE/he 4tSrrkGFWMY1yrjz30vvxB0zIXZBKDe2arm9OSJMrmu0yw+RyGccvwE5vVRkFwaJ707j TBCw== X-Gm-Message-State: AHQUAuboP/aLTXlqAzLTb8zlxpj1KXDfeiZ/bRLvCAEvYWk1jaVQfGfc bbxhjIv2yXJLGV7Z2W32ShRamsLW9rY= X-Google-Smtp-Source: AHgI3IaIv6m/Ex5gPK2/9XwtniTHV+LPkr/JxHxwStZtOpuff43bEBn57Y5z2h+Ymu1dSwAxQKnCpw== X-Received: by 2002:ac8:6c2:: with SMTP id j2mr5943411qth.387.1550208158260; Thu, 14 Feb 2019 21:22:38 -0800 (PST) Received: from thedes-mbp.localdomain (cpe-45-37-171-73.nc.res.rr.com. [45.37.171.73]) by smtp.gmail.com with ESMTPSA id f33sm2766688qta.91.2019.02.14.21.22.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 21:22:37 -0800 (PST) From: Thede Loder Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_15A46F54-DD84-4240-8D08-56301B546448" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 15 Feb 2019 00:22:36 -0500 In-Reply-To: <1hVuuyBcVHZcFAmv@highwayman.com> Cc: "bimi@ietf.org" To: Richard Clayton References: <8ba3c80f-74d1-b739-070a-f0003eb82a22@dcrocker.net> <4FCA9CB5-56CE-4AC7-9BC1-1069777A9F95@skyelogicworks.com> <1hVuuyBcVHZcFAmv@highwayman.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] Where do the signed certificates come from? X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 05:22:43 -0000 --Apple-Mail=_15A46F54-DD84-4240-8D08-56301B546448 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard,=20 Thank you for your thoughful response. I have responded in a few=20 places below, and also ask you some questions. =20 > On Feb 13, 2019, at 14:51, Richard Clayton = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In message , Dave > Crocker writes >=20 >>> * Unlike 30 years ago, there are now 50+ Certificate Authorities=20 >=20 > Firefox currently lists 62, with 151 root certificates that are = trusted >=20 > your browser may vary >=20 >> Also note that there are massive problems with exposures and=20 >> misbehaviors of the CA operator mix. (Oddly, folks inside the = security=20 >> community seem unaware of these problems, while folks outside the=20 >> security community seem to view them as obvious and massive.) >=20 > ... 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, Can you provide a few references that could serve as an introduction=20 to the interchangeability problem? And the extensions? I'd like to=20 understand how the issues might carry over to our current design +=20 strategies for VM Certs. Hopefully the same issues will not apply,=20 but if they do, perhaps they can be mitigated. =20 > but all BIMI seems to envisage > is the use of Certificate Transparency to detect unexpected = certificates > after the fact... >=20 > .... 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. Agree that such a thing would be unfortunate. =20 It's not mentioned in the VM Cert Guidelines, as its content is mainly = focused =20 on describing the vetting and requirements beyond Extended Validation = and=20 the Certificate Profile contents, but there is a straightforward = strategy here to=20 address the concern and situation you highlight. =20 Receivers ("Consuming Entities" more broadly) can and should prohibit = (not=20 bother?) to display logos made available and extracted from newly issued = VM=20 Certificates. A best practice is to allow sufficient time to pass (e.g. = several=20 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=20 prioritization, and automation can be brought to bear.) =20 So unless a significant number of people are monitoring the CT logs = directly=20 themselves, under normal circumstances those outside the security sphere would not see such a logo. Meanwhile, if significant numbers of people = were=20 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=20= logging besides the 'catch while in review' period enabled by = transparency. =20 Offhand, CT implies a history of data to assess CA quality over time (as = a basis of=20 CA reputation), and the CT logs are a direct source of certificates = independent=20 of DNS (helpful, though not a necessary means to aid in thwarting = tracking=20 web-bugs-style via DNS)=20 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=20 advantages or mitigations possible through CT logging? If so, I would = love=20 to know of additional strategies than can improve safety, reduced abuse, = etc.,=20 please share!=20 > should the documents explain why some variant of certificate pinning = is > not being envisaged ? If only in the security considerations section. Thanks for mentioning, good point. Yes, we should include a discussion = of=20 the relevance or application of pinning. That reminds me -- we should = also=20 add assessment of CAA. Do you have a view here? =20 I do think some MUAs would benefit from pinning, particularly for IMAPS = access.=20 IMAP itself could use an extension to signal to aware updated clients = that=20 it is ok to honor/trust/load a BIMI-Location header's image URL. =20 The evaluation of VM Certificates and the root and intermediate with = which they=20 are signed, along with the extraction and distribution of the embedded = logo if=20 trusted, are generally activities envisioned as taking place on a = receiver's=20 systems. There may be less risk of a trust-store compromise in those=20 environments, vs. on a non-security aware end-user's PC. =20 >=20 >>> spanning the globe and serving a mix of market consituents, large = and=20 >>> small. Supporting VMCs are operationaly incremental. >>=20 >> This being a technical forum, I hope we can avoid marketing language.=20= >=20 > 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 Yes, thank you, I did mean to imply at varying prices. =20 >=20 > It is believed that the reason people pay $$$$ is because they are > effectively purchasing a certificate management system rather than = just > a single cert. >=20 > Security Economics in the HTTPS Value Chain. Asghari, H., Van Eeten, > M.J.G., Arnbak, A., & Van Eijk, N. (2013). WEIS 2013. >=20 >> For the most part, the usual, reasonable benefit of a TLS cert is a=20= >> private connection to the site you intended. (And note that with the=20= >> popular use of self-signed certs even that benefit has some important=20= >> limitations.) >=20 > 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 >=20 > 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") >=20 >>> * Internet users want it - clear demand >>=20 >> That claim keeps being made but I've never seen any serious=20 >> documentation for it. >=20 > Marketing people want it -- that may not be documented but I have > sufficient anecdotes to hand to believe it be the main driver here. Generally speaking, marketing people do want it. An early trial of some=20= parts of BIMI was able to recruit both big and small brands, despite = some=20 substantial effort required on their part. They are often promoters of = a=20 brand's brand. However, if it were just marketers expressing interest,=20= I personally would be worried it will be less likely to get anywhere. =20= >=20 >> Worse is the question of efficacy. >>=20 >> What is the end-user benefit in having marks displayed? I'll suggest=20= >> you point at, and comment on, the considerable research about this = point=20 >> that was done when the BIMI effort started a couple of years ago. >=20 > 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'm not sure we can say conclusively what the research says, as there = are=20 plenty of limitations, at least with the studies I am aware of. =20 I do think the research indicated measured effects on end user choices = in the=20 Seznam study were small, and consequently any security benefits made=20 possible through end-user mediated choices (with their study design) = would=20 be necessarily small. =20 But such a conclusion is a very different thing than making the = conclusion=20 that the security benefits of BIMI's broad adoption will be small. = There are=20 a great many more factors at play. =20 A relevant analogy here is the difference in the importance of end-user=20= mediated outcomes with two different safety devices commonplace in=20 automobiles: seatbelts vs airbags. Seatbelts require user-action, user=20= training, and have various user-influenced failure modes (failing to put=20= them on, or putting them on improperly which can do more harm than=20 good). Training and practice can help (implying costs, but worth it = with=20 people's lives at stake). Training for reading email headers or=20 differentiating logos/non logos, maybe less so. =20 Airbags, by comparision, do not require changes in end-user choices to=20= improve outcomes. They are part of the infrastructure of the car, safer=20= by design. BIMI is airbags. =20 BIMI's primary mechanism of improved safety is through driving adoption = of actor=20 authentication (sender authentication in the context of email), making = impersonation=20 attacks through existing applications harder, and motivating higher = levels of=20 real-world / online identity transparency. =20 As to increase happiness and rapid selection, you nailed it. That too! =20= >=20 >>> * authentication schemes necessary for safe use a primary = anticipated=20 >>> application having 2 billion users is already widely supported >>=20 >> This seems to be another component-level comment, but I'm not = certain. >>=20 >> Hoping that you are not commenting on the underlying crypto = algorithms,=20 >> I'll guess you mean SPF, DKIM and DMARC. =20 >=20 > 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. True. So by some definitions of scalable, SPF, DKIM, and DMARC are = small. =20 But in terms of impact, there's been at least a little bit of impact for = nearly every=20 Internet email user (Facebook alone has 2.3 B monthly actives, and they = send with=20 DMARC)=20 I have clear biases, but to me DMARC adoption, limited though it is at = this point,=20 exmplifies how a technology does have to be directly adopted by every = end user=20 of the Internet (on their own device) to provide a beneficial impact and = to have=20 been worth while to create. =20 >=20 >>> * trademarks scale. There are ~2M design marks with the USTO, = estimated=20 >>> 20M world wide, and scalable processes and government support to = handle=20 >>> increased demands. They have legal standing. Registration=20 >>> jurisdictions can be expressed as ISO country codes unambiguously >=20 > 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 ?=20 It's a good question. But if we are really worried about it, we should = probably=20 consider rolling back DNS. Because lloyds.co .uk, = l1oyds.co.uk , and lloydds.co.uk = =20 all look somewhat alike when viewed on a phone screen too. :-)=20 Joking aside, there are well know 'collisions' in the "design mark" = trademark space -=20 look no further than Paypal and Pandora. =20 There may be a difference here that works in BIMI's and VM Certificate's=20= favor. With trademarks, there's a well-defined legal process (and = system for=20 supporting it, the legal system) for evaluating the relative propensity = and level=20 of risk associated with confusing marks. =20 I'm not sure if there's an analogous process for DNS names. If I = register an "off-by-one"=20 character look-alike domain name, can a well known brand do anything = about it at all,=20 other than try to buy it from me? =20 >=20 > also, most people are rubbish at remembering what logos look like >=20 > https://www.signs.com/branded-in-memory/ = Thank you, great resource! And a facinating set of studies. I'll write = something more=20 after I've had a chance to sleep and give it a think. =20 Thede >=20 > - --=20 > richard Richard = Clayton >=20 > Those who would give up essential Liberty, to purchase a little = temporary=20 > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov = 1755 >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 >=20 > iQA/AwUBXGR1Wzu8z1Kouez7EQJg3gCfXjhWf+O2uXq0yIdeJ3s+jChYn8sAmwb3 > wer3de7TQB3odl4wYGxiUrb2 > =3DagVd > -----END PGP SIGNATURE----- >=20 > --=20 > bimi mailing list > bimi@ietf.org > https://www.ietf.org/mailman/listinfo/bimi -- Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com L: https://www.linkedin.com/in/thede M: 415-420-8615 --Apple-Mail=_15A46F54-DD84-4240-8D08-56301B546448 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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 <richard@highwayman.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

In message <ebf7e79e-d651-f385-d0a7-e9a156a59013@dcrocker.net>, = Dave
Crocker <dhc@dcrocker.net> 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

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

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

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

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! 

should the documents explain why some variant of certificate = pinning is
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.  


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.

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

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


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.

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

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

* Internet = users want it - clear demand

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

Marketing people want it -- that may not be documented but I = have
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.  


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.

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


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

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.

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.  


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

It's a = good question.  But if we are really worried about it, we should = probably 
consider rolling back DNS.  Because lloyds.co.uk, l1oyds.co.uk, and 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?  


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

=        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



- --
richard =             &n= bsp;           &nbs= p;            =             &n= bsp;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

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBXGR1Wzu8z1Kouez7EQJg3gCfXjhWf+O2uXq0yIdeJ3s+jChYn8sAmwb= 3
wer3de7TQB3odl4wYGxiUrb2
=3DagVd
-----END PGP SIGNATURE-----

-- =
bimi mailing list
bimi@ietf.org
https://www.ietf.org/mailman/listinfo/bimi


--
Thede = Loder
Managing Director, Skye Logicworks LLC
M: = 415-420-8615

= --Apple-Mail=_15A46F54-DD84-4240-8D08-56301B546448-- From nobody Fri Feb 15 08:17:06 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C5A130FD6 for ; Fri, 15 Feb 2019 08:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXfkbWaknXKR for ; Fri, 15 Feb 2019 08:17:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E8B130FC1 for ; Fri, 15 Feb 2019 08:17:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76B4BBE47; Fri, 15 Feb 2019 16:16:58 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6camKti0gYUh; Fri, 15 Feb 2019 16:16:58 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C4E3BE24; Fri, 15 Feb 2019 16:16:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550247418; bh=400EWnzeWNBfDKSu0hMnw3fYNhC0aZujTW7nl9xx1/Q=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZN8JG3eIOO/7entT0aLdyw5jxvTYz6FlXuABOga+urOsVmNxWgvj+TW1pJfeX1RZ/ /s6Qxnzx3AtOnV3rS1p6r02Isl+kvTTWsXgaqJfueZUgpUbzOeuHTuRsKH9y5nfhqf DTkbeoP30CX4Eg2V4TuDv9pSzdlNMS+rZxF+emJY= To: Terry Zink , "bimi@ietf.org" References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <69304caf-2e46-d223-9e53-80b8c18ab25f@cs.tcd.ie> Date: Fri, 15 Feb 2019 16:16:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vihRH2ehLm5sTviSRMeuXkP7pP9W39DsN" Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 16:17:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vihRH2ehLm5sTviSRMeuXkP7pP9W39DsN Content-Type: multipart/mixed; boundary="h9UvwXIx78YTOtvgRwIQEvldw0NwAC5Zb"; protected-headers="v1" From: Stephen Farrell To: Terry Zink , "bimi@ietf.org" Message-ID: <69304caf-2e46-d223-9e53-80b8c18ab25f@cs.tcd.ie> Subject: Re: [Bimi] (non)desire for bimi References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> In-Reply-To: --h9UvwXIx78YTOtvgRwIQEvldw0NwAC5Zb Content-Type: multipart/mixed; boundary="------------DF33406784912ECABDBF4AD8" Content-Language: en-GB This is a multi-part message in MIME format. --------------DF33406784912ECABDBF4AD8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Terry, Just on this point for now... On 14/02/2019 23:36, Terry Zink wrote: >> In fact, my reading of bimi is that it does attempt to force a >> receiving MTA/MS to actively download the image(s) and replace >> the URL with one pointing at the MS (or nearby) - not doing so >> would expose users of the MUAs using that MS to tracking once >> those MUAs de-reference bimi URLs from the sender. >=20 > Where does it say that in the BIMI spec? I'd have to go check the drafts again, but that's how it was described to me at [1] and that matches my recollection of the drafts. Cheers, S. [1] https://mailarchive.ietf.org/arch/msg/spasm/cf-jmY5tOx-zIdklMyfLGdp9Y= qY >=20 >=20 > I helped write and edit some of the first documents for BIMI. For the b= rand, you upload an image somewhere, and create a DNS record that points = to it. You then have it signed so that it can be verified by an email rec= eiver. As a mail receiver, you use a bunch of DNS checks along with stand= ard email auth checks to figure out where and if to pull the image. >=20 >=20 > As an email receiver, you could choose to pull it from where the brand = publishes it (and therefore deal with the unreliability of everyone else'= s architecture), or you could pull it locally and replicate it on your ow= n infrastructure. Indeed, that's already done today. If I'm an email rece= iver and I'm showing images based upon my best guess of what a brand's lo= go is, and a brand instead tells me what the authoritative source is, the= n I go pick it up from there instead of scraping it from the web. >=20 >=20 > If BIMI requires the things you say it does, I'd like to understand whe= re. --------------DF33406784912ECABDBF4AD8 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------DF33406784912ECABDBF4AD8-- --h9UvwXIx78YTOtvgRwIQEvldw0NwAC5Zb-- --vihRH2ehLm5sTviSRMeuXkP7pP9W39DsN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxm5fgACgkQWrL68XsX K+rE4A/+Mf/LMiSE5EiidoTGVmWbOLBjbRLLnn4VD4YDLEO3hQl4WA3um0WiLPZ7 E+sMaqf/T/PEFFQ/YExxpmmXvaWc9CngTgsIfDbSzRZpP/UhxLtQJwJTpwusV/vW 2o0yo9R1jEAbELeAXxhHZbaATB8iy/EeZAL876pfr3qfuKZhL3mqmbsZv2Mi/o3w aNSBiLIw+NuCPIePIiX1ybRsqDopw/z841vLJbAFkWC9zYtttzTI1S/GkU608Eno 5+tNb8MmS37mIepFMy37gFWoRQQvf6+ZLvz+d9ZXK/Yr6N1Np/QvGC+YYEE7Ex6M H6CGGPKdQfETNB9c2FxKdgzABHTZSp3cDB83dgPhF1L5EFHc/demUZJZO+p2I/FF wrlklILbIsxeYqf2terZP98ZQjqkwSnAMTkjlr7O1NR3GRibr3+k2LlYS+ppYfyo kTcGfxcu4ncnTUDh/G5C4QcljxB7M/icFWA0cPCwc4ccsoTySozAjjZ/gx2DxFcV Iy8H6HJrCHQJvvC6fdfSWzzt0Z6VrJl5E4V1TeZdeDW5dDTjRnGPu+5vmgtitmxr PUO+H2F4IuNHHRyT61ym9xdoYrDnKljsOpYR3N4ogByvRRrPnIXmehV2dvywcKl0 cLPnzQSGR2bkTRD26jQ8HzJKR9CWTtJWJoWG7qO8yGXMNqL9AUo= =qFOM -----END PGP SIGNATURE----- --vihRH2ehLm5sTviSRMeuXkP7pP9W39DsN-- From nobody Fri Feb 15 09:09:27 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56AB130FE2 for ; Fri, 15 Feb 2019 09:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=terryzink.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhFGuzIXratc for ; Fri, 15 Feb 2019 09:09:20 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780047.outbound.protection.outlook.com [40.107.78.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CF6126C7E for ; Fri, 15 Feb 2019 09:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=terryzink.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YfOfY19g6F1/PCi39+Wt5V6l2Bk3bAr21k93PtwhM1w=; b=cRFsOZYWSfI+TU6yl9m4/IdtwtTEH/lZ/w1w2BH93pvCDFgAIPEVJZ5SDYvbhh5nqfs3sS0LkcIZgxosTaByta7r61doOhLgwiMGOH5m5PFc2DTMaMPYMRxzmT3Jd6N3+dg3PV516xmhPSQ20mjRXmJgJ2A096ufQDNoSk0Ebm8= Received: from BL0PR11MB3107.namprd11.prod.outlook.com (20.177.205.141) by BL0PR11MB3522.namprd11.prod.outlook.com (20.177.205.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Fri, 15 Feb 2019 17:09:12 +0000 Received: from BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda]) by BL0PR11MB3107.namprd11.prod.outlook.com ([fe80::e934:a609:cbdd:1bda%3]) with mapi id 15.20.1622.018; Fri, 15 Feb 2019 17:09:12 +0000 From: Terry Zink To: "bimi@ietf.org" Thread-Topic: [Bimi] (non)desire for bimi Thread-Index: AQHUxFQrlnICsfeFJUyWrugVUJNeRqXfg1XEgAAetACAAEy+qoAAHB+AgAEOcEo= Date: Fri, 15 Feb 2019 17:09:12 +0000 Message-ID: References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@terryzink.com; x-originating-ip: [174.21.90.137] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a313a5f-d2dc-4299-4b44-08d693684eb0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BL0PR11MB3522; x-ms-traffictypediagnostic: BL0PR11MB3522: x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; BL0PR11MB3522; 23:T489W9d/XD8E5ty0S7JgN3cHG3wyEiPfkDA3vr3?= =?iso-8859-1?Q?Ny0rq8YOHxQvSQ8B9En3kYlNvjwfQZ1Byg4K2g1BO3bDgqARTwVPp4MtpU?= =?iso-8859-1?Q?9HepKeNcUIYWcCwxbYgwh9UuUNCTejna7O6WQGc/TRPJ9Nln95Y6ZA+E56?= =?iso-8859-1?Q?9H/nQPTvcljqdtgFbYfm4vMEjoy6Xihezmw5pLbzRo+Vg/0T/eW8mvvmn6?= =?iso-8859-1?Q?QIq/Dkyo5QdCsAZXjwb/wqAcU2JOaK4rfKiktSH9QA3g70rLSwpEqsCwC0?= =?iso-8859-1?Q?coYz+sy25prrnlr7QH3BnO9vMviAdynxZF378NG6AqNEv960VKueebcCBm?= =?iso-8859-1?Q?DnzJy0swHcEeWxCxBlYra0YDMmr+AmMdYQBxokTOJ/veeJhsUqqDJdaNsn?= =?iso-8859-1?Q?AUArET7GURvUB5/wJj8qOJb+dz1v1qWrCVUoU/HJFcer0Iq8wDq/ZM4m20?= =?iso-8859-1?Q?LtuZDM7IcefXCUFIT10kZBQRCxnOHpiiAaTOypD59JDRB0GY7uDl6pHpBY?= =?iso-8859-1?Q?THljZZ434SMcoRKU8OX6i0yfZrOhHFzbri/5SGTXxyFLHhmg/Tp3Xoomag?= =?iso-8859-1?Q?REhX+eSuUaC24GQWPs+Xq78Wtw3IqLQvhZCw75rlUuUnbnXkAbBi93EZ1c?= =?iso-8859-1?Q?1eYgEMJ8nQZE5MhHo0fY2ZreXWdMsr7SHNFo8PmuhPFDY8CcBQuNK/Pn0C?= =?iso-8859-1?Q?G9/X/sv0n7UCIDiWM6icIoIm+NMc2ydwwbzAjUZ4CkOsiF2N363buuUw7A?= =?iso-8859-1?Q?GvMnTWJCfH8au3LetGkYHtsaXkLoGImqQgUnK4hOR9Wefy2r8EaG04q1tf?= =?iso-8859-1?Q?S+I+Ja2ikxUseDDm00cZBY26hpBPeaRPDLxRIfmZS0AyzCBun+ee2E9XI7?= =?iso-8859-1?Q?pp2aVbxMMzL/H7QBMVySTbHXcLGF7GYwo//AFSg1w6qEJD4ZBx2+Tg6lar?= =?iso-8859-1?Q?xrGCdFePX+AikWmqk8yNycnTpcSeYEpy7BXiD1+r7KD5CC/XnbYy2ux96r?= =?iso-8859-1?Q?Yhn5AeiXMtojPFvURNhgF8ynIqlyaWlxSPqdHgvcnhjqQiSzR/IPKW941H?= =?iso-8859-1?Q?Maxr5sqLHRkRn+HtTmzktjFNVjAs3Qv+q21WX8g8NYB+cSaDOdx2vA49aJ?= =?iso-8859-1?Q?IsYXMzTKRzxR+jXcPh+ArhgnxbnAyLz/5bNPXNb44nFcT3U3St7FQhZ/kf?= =?iso-8859-1?Q?SxbItTR4VoQfgQBY64fphe0Vj85TRmUm4RhkLApjh6ACZfLiJZHzuQT2rw?= =?iso-8859-1?Q?+h+GrGPDjfaIKdZ7I3dkAj13gU9KuVE4Sn2VtEX1nPvbzAG8InUmf8ejyf?= =?iso-8859-1?Q?b+W3wBpcmWbnf2SZzeamT+RXB6sf5kvxQl4w6uEST0IBNYeBOcN+klt4Ll?= =?iso-8859-1?Q?LewBmD+o=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09497C15EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(136003)(39830400003)(199004)(189003)(186003)(54896002)(2906002)(97736004)(229853002)(6246003)(86362001)(93886005)(8936002)(66066001)(7736002)(53546011)(25786009)(7696005)(53936002)(105586002)(106356001)(19627405001)(2351001)(446003)(6506007)(68736007)(76176011)(102836004)(486006)(33656002)(476003)(81166006)(81156014)(26005)(8676002)(9686003)(99286004)(71190400001)(6916009)(256004)(11346002)(71200400001)(1730700003)(6116002)(508600001)(3846002)(6436002)(4744005)(316002)(55016002)(2501003)(74316002)(5640700003)(14454004)(105004); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3522; H:BL0PR11MB3107.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: terryzink.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4aj1qWYbGnv0JJGuFZzf4ZoruiPn6AnS2/leFJLJCz5SN6X7ZJmrAXBDPdK9E5Hr4Cc6Vw96NGJPw4oumxbc7efhtGPeaY1UhMmMyM9QsRDzEqhgnzwBJR4mBCT2ofxznr1xxdmnjGAv27AViSwsyyF+QcoslGVt/NL1wz2anaseTQDEIIjbA5kaO/ZtGQ3BdoVsIE3h9HGBmcOdrqxKy4XTWlgQNApvpBx1uCYVg1pFK71MHEtE5CEp3i4+LyVlRwcwnxFVMFvUQ+3wr1A337AuqqwBw52DHViO7zT7GSpjg4ofxkAcMmzTLu3o9pne+H1X7Z/Dwk3HpzthpRHsJgZLanCeXX8EwP4ofEhuBIklsooWKqMVChvqLJPTbzlpMSBKCqPYsk8TZiNIzmWoFj87LauAzD8vt7sHMy1qo0E= Content-Type: multipart/alternative; boundary="_000_BL0PR11MB31073C55866BF10C07A1184FA9600BL0PR11MB3107namp_" MIME-Version: 1.0 X-OriginatorOrg: terryzink.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a313a5f-d2dc-4299-4b44-08d693684eb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 17:09:12.2319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 470dd1c0-25dc-4cce-857e-0d65849495b7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3522 Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 17:09:23 -0000 --_000_BL0PR11MB31073C55866BF10C07A1184FA9600BL0PR11MB3107namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Dave, > Terry, in the context of usability design, language like "all you need > is a checkbox" hasn't been credible for at least 35 years. LOL! Yes, I know. I phrased it that way on purpose - to oversimplify the discuss= ion as if to say "All that's required is a simple way to disable it?" ________________________________ From: Dave Crocker Sent: Thursday, February 14, 2019 5:00 PM To: Terry Zink; bimi@ietf.org Subject: Re: [Bimi] (non)desire for bimi On 2/14/2019 3:36 PM, Terry Zink wrote: > It sounds to me like you're saying you want to turn off BIMI logos in an > email client. All you need is a checkbox in the MUA? Terry, in the context of usability design, language like "all you need is a checkbox" hasn't been credible for at least 35 years. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --_000_BL0PR11MB31073C55866BF10C07A1184FA9600BL0PR11MB3107namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Dave,

> Terry, in the context = of usability design, language like "all you need
> is a checkbox" hasn't been credible for at least 35 years.=

LOL!

Yes, I know. I phrased it t= hat way on purpose - to oversimplify the discussion as if to say "All = that's required is a simple way to disable it?"

From: Dave Crocker <dh= c@dcrocker.net>
Sent: Thursday, February 14, 2019 5:00 PM
To: Terry Zink; bimi@ietf.org
Subject: Re: [Bimi] (non)desire for bimi
 
On 2/14/2019 3:36 PM, Terry Zink wrote:
> It sounds to me like you're saying you want to turn off BIMI logos in = an
> email client. All you need is a checkbox in the MUA?

Terry, in the context of usability design, language like "all you need=
is a checkbox" hasn't been credible for at least 35 years.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--_000_BL0PR11MB31073C55866BF10C07A1184FA9600BL0PR11MB3107namp_-- From nobody Sat Feb 16 06:04:22 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289CC130E74 for ; Sat, 16 Feb 2019 06:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=DeUaIMXk; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=EbrzadW3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyyr7UOFqZ_w for ; Sat, 16 Feb 2019 06:04:18 -0800 (PST) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEF1130E73 for ; Sat, 16 Feb 2019 06:04:17 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1550325854; h=from : subject : to : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from : subject : date; bh=P8ZWeQZaXbezem86Jjx3LmzOZ2e+Jk3aLwHH7G9j4Oo=; b=DeUaIMXk2hZgHyjppcPuufOZxaMz0quRymIMghoc5qaJtzj5UjQXsCqb +6WEAcIKXfKeIqSd8x0Yr/2WGZVpDA== From: "A. Schulze" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20190120-D99A; t=1550325854; x=1555325854; bh=P8ZWeQZaXbezem86Jjx3LmzOZ2e+Jk3aLwHH7G9j4Oo=; h=From:Subject:To:References:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=EbrzadW39/SHO/alo5vA54yUCNsxAjJ9KOMqsniPpmdWaoT2q02YDLHu5wrrjqNRg 6ziTIStXa/Jcb7t1WnNC80oIyhyOxJIwbAI+vEVk4gqd/cL+KYkKWb3WtDZEJxO/rN H0PKskFAeSFJapzRCWmW7y5gAlzjAiGjP/jzeQqF+eSB02LvvoImeOacJtfTXGZxUa BDNSVct9jIb100/WT0aWgyJhdVlhLG1ga2hAk7RcnjFQnMGQvLHnlCJdtGBcDoAnLV pL+SqbI/rw8c8KCq9lnOThCGs3NYZJODJtBP1PYSkGXQqYoXIDFwQX/6ADBNcAukuo jgPXTEinTdmWA== To: bimi@ietf.org References: Message-ID: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> Date: Sat, 16 Feb 2019 15:03:40 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 14:04:21 -0000 Am 14.02.19 um 11:57 schrieb Stephen Farrell: > I also just do not want to see your logos, thanks. Hello, I agree with Stephen. We all, but specially MUA developer/maintainer, fail to teach the user what the technical meaning of RFC5322.From is. It is simply text choosed by message originator, no difference to RFC5322.subject Users expect this to be something other. That's the problem. So we created these horrible zoo named SPF, DKIM, DMARC and ARC. And what's the result? RFC5322.From contain something I use to name "Display Name" All the authentication tech ignore this part. But what do MUAs present as "FROM" ? Most of the time exactly this last piece of unauthenticated data. All, what BIMI could do, is to teach "Hey User, this message from $BRAND is only valid if you also see $BRAND's logo" So BIMI sounds to me like an authentication method for the display name. I would say, we failed... Andreas From nobody Sat Feb 16 08:07:37 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326F4130E73 for ; Sat, 16 Feb 2019 08:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizonmedia.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnY56Lu-2nlZ for ; Sat, 16 Feb 2019 08:07:33 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D621275F3 for ; Sat, 16 Feb 2019 08:07:33 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id f2so10275232edy.13 for ; Sat, 16 Feb 2019 08:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizonmedia.com; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to; bh=UiFPPcLljb2eB4aEvzoCkK9NPe5QsUZdPc50ERbTphA=; b=V58jfk4QkrZAjKVMpuDn/cGqjNH3fEQefoNTf9/sRA2bd6EUTJy7hpws2owwVtxOsi qkasf8V7RAR442WYqx+8glbEG1vYyvZNMXNqhSiiyOvGzmOkXhhHodm3pQwfeRU3vCYG ssOWQjTCqgXDgUwV4WbrSKpSBzeA9H4+flkzVDG11wwQv7lLZclBBwbjAU+IRN+dpGq9 JVUqUZt12n63oxmTPYi/RqtY/oEBLeNT2MRfkCuVb2Jhulb8Pqs4fK+d+JO1pe6MIvIR cIuVBQyultCaaFP1rNPOu3qY3bUjYD25tccZvEPpaohsnkEs23jsAcyBu9YAVYYBffw8 id1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to; bh=UiFPPcLljb2eB4aEvzoCkK9NPe5QsUZdPc50ERbTphA=; b=YXtJrk1F6c3X9KTKR14MwyxT4tVB3e74gNQNhoeXbohiAubwEhKWQvU4zMzPI4/Uyt Gj+xT+r6ylWquzO8DwP85OJQXDp/5pNMUDBJqYWWyJbP9qOfs9FEXsVBWf0DSyMq/uJA NP0edmlvMTFhP0593mTccOcjr4dvgmHRTVC+lwVEDpUX2QlSeEwlgQEXbSCIjtBKjX+x ECUmyaS5CSBFlI3LxeDYayKHkwTgcJ+qKFp4fO9CiN7fLJjpDHc/CZd5ztYRZeyLq7BI Cs8Zw5Iwv/LUdiNarJju1/vhPj+TfsH1JYdJknuRjKcJ9zKVHgVob20WIV0rgDz7qSbD E0Nw== X-Gm-Message-State: AHQUAuagVh8yHBpysQiISOEEUeynzwauvyHWKn5qYVA+8z38XNN7jVLT DECjQ8i0CSaxK+o4K3dbizTVDVFOh5sZL+p3b51MRUYGMg== X-Google-Smtp-Source: AHgI3IaVQ+ngf45oIWZuS+pdrqVXk9OhrZNYoUb2OKmF7MlEverWGNTW02ms+5iQ5d7yeMaia+0uLhPSRP+ytZTFNYI= X-Received: by 2002:aa7:db0e:: with SMTP id t14mr12169597eds.292.1550333250679; Sat, 16 Feb 2019 08:07:30 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Sat, 16 Feb 2019 08:07:29 -0800 From: Marcel Becker Mime-Version: 1.0 (1.0) References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> In-Reply-To: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> Date: Sat, 16 Feb 2019 08:07:29 -0800 Message-ID: To: bimi@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 16:07:35 -0000 On Feb 16, 2019, at 06:03, A. Schulze wrote: > > >> Am 14.02.19 um 11:57 schrieb Stephen Farrell: >> I also just do not want to see your logos, thanks. > > > I agree with Stephen. Personal preferences of visual message presentation and mua visual design (while interesting) should not be really relevant to this discussion imo. > All, what BIMI could do, is to teach > "Hey User, this message from $BRAND is only valid if you also see $BRAND's logo" > And that would be bad thing? From nobody Sat Feb 16 08:12:06 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3606D1275F3 for ; Sat, 16 Feb 2019 08:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPs0-vJ2-YYM for ; Sat, 16 Feb 2019 08:12:03 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F89130E73 for ; Sat, 16 Feb 2019 08:12:03 -0800 (PST) Received: from [192.168.1.168] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1GGDMsw024356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 16 Feb 2019 08:13:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550333602; bh=vyQ08f5BVs53XS46NIA9M84IkcuiuLKJEl6wMP4VYxY=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=cUZQNuEL9TZrJNzsQtrTMzn89RouoBws2kpaV6fwbYiqtqGYc+PuZMdEjDJoQqfne Tzerq2R9Ow0GEGjYxeXPKiArCmYmNLSHBNhXsEKd6CSe+IjQSsXDRk5WrJ+vCIn1c1 rZTs753gQ/pLxZrBPRiXXqTLv2eGuR5mIyafIv7Y= To: Marcel Becker References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> Cc: bimi@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> Date: Sat, 16 Feb 2019 08:11:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 16:12:05 -0000 On 2/16/2019 8:07 AM, Marcel Becker wrote: >> All, what BIMI could do, is to teach >> "Hey User, this message from $BRAND is only valid if you also see $BRAND's logo" >> > And that would be bad thing? Except, of course, that it will not have that effect on users, because there is extensive experience demonstrating that users mostly do not learn or use such signals. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Feb 16 08:17:10 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D26130EFE for ; Sat, 16 Feb 2019 08:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohAiTnzloGgm for ; Sat, 16 Feb 2019 08:17:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23991275F3 for ; Sat, 16 Feb 2019 08:17:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 07232BE24; Sat, 16 Feb 2019 16:17:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfaY7dd7Eth7; Sat, 16 Feb 2019 16:17:01 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E454BE20; Sat, 16 Feb 2019 16:17:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550333821; bh=u4kivqoagcNlm82m+wHB+jEAj611id9T5ItPA1Ks/pQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JRotkgyNuF8YcN7kkTClzR3GGDebrvj6oAWKU01rF8epTWtwrVM2wDYVPWQsH49Il vK9oOl1K/IfqJgWRgL25OlVkc3M96sZFh0h46K2szAmCIRYJ8UTUqtyATk7yaJkRGr TQV3CRYMUt4mi8AVASSoQv4lp2vOA7Ma55xuRIms= To: Marcel Becker , bimi@ietf.org References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <2e957f28-4589-60ab-b48e-30fbdb4cc12d@cs.tcd.ie> Date: Sat, 16 Feb 2019 16:17:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9N4fyHF0xitPxgGTJeaE0sKjBK7qaP7wV" Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 16:17:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9N4fyHF0xitPxgGTJeaE0sKjBK7qaP7wV Content-Type: multipart/mixed; boundary="AsGUPTQD93DgZxP4oUHhOe0rpSYBixLqb"; protected-headers="v1" From: Stephen Farrell To: Marcel Becker , bimi@ietf.org Message-ID: <2e957f28-4589-60ab-b48e-30fbdb4cc12d@cs.tcd.ie> Subject: Re: [Bimi] (non)desire for bimi References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> In-Reply-To: --AsGUPTQD93DgZxP4oUHhOe0rpSYBixLqb Content-Type: multipart/mixed; boundary="------------2261E59987F8D48581F37D46" Content-Language: en-GB This is a multi-part message in MIME format. --------------2261E59987F8D48581F37D46 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 16/02/2019 16:07, Marcel Becker wrote: > Personal preferences of visual message presentation=20 To an extent, yes. The fact that you or I have some preference here isn't very relevant, being effectively anecdotal. The reasons for those preferences (and reasons have been described) are however entirely relevant. > and mua visual > design (while interesting) should not be really relevant to this > discussion imo. I disagree here though - the proponents of bimi are arguing or assuming that presentation of a logo will have some positive effect. ISTM that means that calls for providing some convincing arguments about MUA visual design (which admittedly is not a common thing in an IETF context). I've yet to see such argument offered. Cheers, S. --------------2261E59987F8D48581F37D46 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------2261E59987F8D48581F37D46-- --AsGUPTQD93DgZxP4oUHhOe0rpSYBixLqb-- --9N4fyHF0xitPxgGTJeaE0sKjBK7qaP7wV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxoN3wACgkQWrL68XsX K+o9Ug/+JEMGN+VWtFQQb56ZG6dtpmfqIyjxQGnLilV+AzsNHxRgxQZhlpY7y1b1 EbS+/WgB+oZLqJxMMhZR8uq5Xt1r8zyqgS952Cuinn9bTWP+TeSnDfa6WH5rL2rD QYM0ajqrSGwURzjVrnLx4A9l4cHayvHTE95FCo9mGeTLFHlEVLWApz866V0/IHoG XFbmW132yQ94oda8SuWyRig6qsKk5lCR8n2Xo6JY3EqySSKTAjv30IN4nkbN2ZNg GsxlGm91iOLpuJLwcoijq53hK9H0aInSYVizXrd57dPELJYon7YjMg+CBHFIrtxA K9xQgmFOw6AFdZteM/CcXm13tUjRLmmmLwa/Cu0Gm60yxmo4FLgpLqDkRn8Zxgq9 7d+YGUXuDAZLvm0tqICxDt8NdTFhFQh2vU9mesicYO2DGqNgwd7xtOmdYt6q7Q9+ 5k2iyWqvOjSLEJDZ7Vs6WuZh8szVnIygK6iOLcIMjgpOva5xU80aC7XfuUXoDvqv uKkKyAKzZaiI5+0Gjxxxp/b2QF3stW0uyWP5D8sXb1qlH64AS1fSa4mayqyfXSp8 Kag2trgGcWtojogDvr3T8/C22IAY4hXS9Ea4Ty/pt1U8ARRQB/LypRx2xnlxgB6J Mk7Zr739dDYNNlpjeGixvO7LVShGMofwprwNSwuU7ekPXLCNDI0= =V0kz -----END PGP SIGNATURE----- --9N4fyHF0xitPxgGTJeaE0sKjBK7qaP7wV-- From nobody Sat Feb 16 08:25:01 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8D1275F3 for ; Sat, 16 Feb 2019 08:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizonmedia.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRFamy_o2CAr for ; Sat, 16 Feb 2019 08:24:58 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993DA130EFF for ; Sat, 16 Feb 2019 08:24:57 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id m12so10333682edv.4 for ; Sat, 16 Feb 2019 08:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizonmedia.com; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :content-transfer-encoding; bh=mx6oY8HYcQIqIBDwvDZgOe50WEJjY2mngUWJdnq99YM=; b=Z59Ohb8GFTDEHLsXQxz6PT2DPmlHvzdFJtgzawJaHhnP2y4GIdz/WXIe0UVetLdXi5 wcIY2/QAvr9SNWpLuqBMK50NwKKPir3g8uCOInuBfqOWXjqsxsNcOWvrKfNNgN/KBqQE qqSkWjWEWwIzBBqoceZwqb+3DJbN+Dy3F7ae3/SRlyx77bKGulicgnx7HtkgybHBTbeS 7Wt0tgo1G2YV3zALgyMIgxgSNLxrNgFBeboUOXZTEUbQxbaySW94Dj0Y68QdnsKq2a4T K2r+OHSkR6/om15sLe3Js6YOKHmgNrvCBDnRxwJCq1z9ORPla/uIzWDmxQJYz8mPks/T Iq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:content-transfer-encoding; bh=mx6oY8HYcQIqIBDwvDZgOe50WEJjY2mngUWJdnq99YM=; b=XYVQUh2BR4w+mEhP0MyMbxNZdlZqEbsf/vYEwzqmxKb70j1DY9Q9I6h7XRwtzbUCFc 4lPwjoVQT8dtLckzX1Z8m8qHSMb1K1CHjA4RwnSsNRlZSwmDvjfhp/Hks8S5XJSW0aMv IEO99BXfkUJDgiJx0A9lTgrvkSyy4MFMZCrDuoREFHTDnwB2NWFHdLuFst9DbS4/fxBA 8WGlKvbsrWojyk0XFh15gNYtwGifQvPiMzPKqExDtb9Gqi7aP+ua34B9LxfeyB/xVLm0 pu/1x0sSG1wfh5MG90gqFuzs87SrW+AwYlAspwfMUifg63gBCfTYmaJiwkMAYQWBjD2l OXQA== X-Gm-Message-State: AHQUAuZFWAsCmsGj17q+GJAaWFKw6hzMihR54clr+68y3zIcyapSimnA LNUn+WMR9ExK178VtD4vSMWK26QiI9U58F7ujA4p02IjZQ== X-Google-Smtp-Source: AHgI3IYOLue28gmltPOXnHnHAPJwLDFwh1yc2OmD62jU+ro51rk3DC6036Ip0VffdRpe5FyT/GneFdybCoMjM+JRyZ4= X-Received: by 2002:a17:906:4692:: with SMTP id a18mr10518170ejr.96.1550334295331; Sat, 16 Feb 2019 08:24:55 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Sat, 16 Feb 2019 08:24:54 -0800 From: Marcel Becker Mime-Version: 1.0 (1.0) References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> In-Reply-To: <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> Date: Sat, 16 Feb 2019 08:24:54 -0800 Message-ID: To: bimi@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 16:24:59 -0000 On Feb 16, 2019, at 08:11, Dave Crocker wrote: > >>> All, what BIMI could do, is to teach >>> "Hey User, this message from $BRAND is only valid if you also see $BRAN= D's logo" >>> >> And that would be bad thing? > > > Except, of course, that it will not have that effect on users, because th= ere is extensive experience demonstrating that users mostly do not learn or= use such signals. While I usually tend to agree with that statement it is =E2=80=94 in that absolut form =E2=80=94 not necessarily true. We know that, given time, user= s are quite capable of learning and using such signals. When specifically designed for that task. But above I was merely reacting to a statement portraying that potential outcome as failure. IF it had that effect, I wouldn=E2=80=99t cal= l it failure. But that=E2=80=99s besides the point of this conversation now a= s well so I will shut up. From nobody Sat Feb 16 09:11:21 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A38130F0B for ; Sat, 16 Feb 2019 09:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n67OedKDPYeA for ; Sat, 16 Feb 2019 09:03:26 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691CB130F06 for ; Sat, 16 Feb 2019 09:03:26 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id v62so12951074otb.3 for ; Sat, 16 Feb 2019 09:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kPg90ktIdiWNNcIceYbRN7bNsXexdG/JK+oS94M4Lf8=; b=NSTAwwct0Y1lL4m78kqyvzFoPVvkS1y+m7/zCmb+iDB4LKs8IFOy3Gf/Qqr6tJHIad S581aidcwaEYzOCtvt+b/2Th02YbVZfGNsCPk40DxDXvetoGPIbc6/jWYHw3Yo6UIy8N BDtOL8ltP9pFluaSoSAaW0qLAk8fN0kwrJ95+kpa5vb21Bu4Ycpn+XbXd7U+Ri6RU1ni Iii3T7OiB67Gqy+7VgzDe7iihfHceRUrSsHv4rNxt99bCHluFBlAhVkn5G6+tUZMPxAC qTrRfLOJqsoquXt6UbeCd5/LK/abzXcUCxsTZrgTMYc0KRQphR7wbyliTmO7SX3Z+t6g dKhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kPg90ktIdiWNNcIceYbRN7bNsXexdG/JK+oS94M4Lf8=; b=UfBQjGW2S7MOHa7L0C5YMMVsN0vFfmCWy9TkpFKbH9iVKHL6L7iYzGLMkoqrijvPFn AnZo/lh3Ru8R/PBl2DgzODxO0uzz1nIwppQKu3A7i4gh/9NTCJclLnqPAHfnwd6wG1V5 qvp4+SmleXXL9XeaqwAYhZURIAT4hTXsgsXGmZa8eXkgmXznsM9OhNd76M0IGoHd3gQX 3/8O/G+a6Iij7zEppmE4ZEKYjZNQWzmuwGcNZPtHZ47dnXWCV3abZnM8zcN9URm9ARNW omwhWNPsBIxUnXMf3cq4XC7j+TOhAVmuEFOZVMV1DeQqX7JoLGqLvxUfZ+1KB8O4tTDX 9N1A== X-Gm-Message-State: AHQUAuZcjH+xarXayLGQb4zK+xac6Qr8jJIr+jVjzRABF9zHFIX0Id/a c65mSUoB7vJLdekHnBpgf/XfjWRk X-Google-Smtp-Source: AHgI3IbfgcoWyUo0ofy9MkTb+DdqbVGp19ps3luYwWZDEmxOJhvM1sWzCnoECv/j9SLa8Vib3Td/TQ== X-Received: by 2002:a54:4698:: with SMTP id k24mr8665032oic.37.1550336604979; Sat, 16 Feb 2019 09:03:24 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:110e:5911:3998:b7de? ([2600:1700:a3a0:4c80:110e:5911:3998:b7de]) by smtp.gmail.com with ESMTPSA id h19sm3463735otr.34.2019.02.16.09.03.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Feb 2019 09:03:23 -0800 (PST) To: Marcel Becker , bimi@ietf.org References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> From: Dave Crocker Message-ID: <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> Date: Sat, 16 Feb 2019 09:03:19 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sat, 16 Feb 2019 09:11:20 -0800 Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 17:03:29 -0000 On 2/16/2019 8:24 AM, Marcel Becker wrote: > On Feb 16, 2019, at 08:11, Dave Crocker wrote: >> Except, of course, that it will not have that effect on users, because there is extensive experience demonstrating that users mostly do not learn or use such signals. > > While I usually tend to agree with that statement it is — in that > absolut form — not necessarily true. We know that, given time, users > are quite capable of learning and using such signals. When > specifically designed for that task. In real life, for this kind of task, no, they aren't. On the average, they don't have an adequate threat model, they do not understand the security mechanisms, and they do not allocate the necessary time and effort to making the real-time decision. If you have evidence of average users making security-related decisions in real-time -- in the midst of boring, daily tasks -- please provide it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Feb 17 17:55:17 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED249130EA8 for ; Sun, 17 Feb 2019 17:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWccsqJY2oQB for ; Sun, 17 Feb 2019 17:55:14 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0B8130DC9 for ; Sun, 17 Feb 2019 17:55:13 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id z39so17638215qtz.0 for ; Sun, 17 Feb 2019 17:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=YvxSWaUR9/gPnpEXBmV4kID+1tetfh/w/m7UOA8lubM=; b=JbhXkog87VLn7tluB37xG4aoZO2a360xE2PkRb0imQV8USzLFnauaCaBkqbpcplCxr ox+Hf2dXjh9Np8IEeWJaz6Z6V3E4j580AA+S2tm0tyfyir5fAIX+kwbrd0tuXRCx03N0 CSBSMebyMLcTvXAYYtk+g4cq6+DgBNB97+IXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=YvxSWaUR9/gPnpEXBmV4kID+1tetfh/w/m7UOA8lubM=; b=mHk4RNek7NJMEULXPyUxBi7EGrXo6OTBoUXJU8qiPiXU6p6agikXbZE0R+PFOtuoTv J8SYlkMslKidKzToG7OUIws957XbvwdEVBDAdZzMijuHYLLuizfp/NfIMGeGKBhiz2MQ OuIdPB5e+A9kEXZQrrcfv0jC3zs7w09Uou7InuQpD/vtg8A6Dhx4ASpaIIMDzvbh5FP/ F6SHYKi3yzvsPujuOyGZREO6QfOLAMU5nMONe+wfakO4QlgOsUXu9zPGIQdzJDvehpWx DbqVptLCaTk21UVi06j6eWxeEwQaYRzIjU6UbWU2+VJcw5wE+5+R8ji0a3aA4gfPSvlb xcBw== X-Gm-Message-State: AHQUAuZBNjKzmwMayFQaY6EIzTkUi1uP9UnuhrCjJFcdNrAqOfb4R198 28WKvT4MjMek/zwdvlcS3xec4Rg1Gp8= X-Google-Smtp-Source: AHgI3Ib6qs19V1oJG6UcNPpoa6Xhudg+u2r73jhRzkC/E8MGZ4GEXM/8PJ7Z0Jsto4//seXKue+rLA== X-Received: by 2002:a0c:b39e:: with SMTP id t30mr15412924qve.206.1550454912087; Sun, 17 Feb 2019 17:55:12 -0800 (PST) Received: from macbook-pro.localdomain (cpe-45-37-171-73.nc.res.rr.com. [45.37.171.73]) by smtp.gmail.com with ESMTPSA id d55sm7662605qtb.93.2019.02.17.17.55.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 17:55:11 -0800 (PST) From: Thede Loder Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 17 Feb 2019 20:55:09 -0500 References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> To: bimi@ietf.org, Stephen Farrell , Dave Crocker , Marcel Becker In-Reply-To: <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 01:55:16 -0000 > On Feb 16, 2019, at 12:03, Dave Crocker wrote: > On 2/16/2019 8:24 AM, Marcel Becker wrote: >> On Feb 16, 2019, at 08:11, Dave Crocker wrote: >>> Except, of course, that it will not have that effect on users, = because there is extensive experience demonstrating that users mostly do = not learn or use such signals. >> While I usually tend to agree with that statement it is =E2=80=94 in = that >> absolut form =E2=80=94 not necessarily true. We know that, given = time, users >> are quite capable of learning and using such signals. When >> specifically designed for that task. >=20 >=20 > In real life, for this kind of task, no, they aren't. >=20 > On the average, they don't have an adequate threat model, they do not = understand the security mechanisms, and they do not allocate the = necessary time and effort to making the real-time decision. >=20 > If you have evidence of average users making security-related = decisions in real-time -- in the midst of boring, daily tasks -- please = provide it. If end users treat messages with or without logos exactly the same, = through what means will end users be made worse off or less safe when = BIMI-sourced logos are widely used? =20 Thede > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 =E2=80=94 Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: +1-415-420-8615 From nobody Sun Feb 17 18:50:33 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067A1130F03 for ; Sun, 17 Feb 2019 18:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnLRkDwYuSyN for ; Sun, 17 Feb 2019 18:50:23 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B75C130EE2 for ; Sun, 17 Feb 2019 18:50:23 -0800 (PST) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1I2pgkB009622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 17 Feb 2019 18:51:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550458303; bh=0NFzRkY1u/+YGIAra2tBQ4GB6gSgtAz10N4jwUgzxSM=; h=From:Subject:To:References:Cc:Reply-To:Date:In-Reply-To:From; b=neiocULLmPW6winGzMA7gWalnPKWOLzYxOEChOan/E43ndPUP0PGO2WU+IYCcZg1u vWwvxKlZ/Sjp01SrDmZa147JeMv5biQ0THJyIAmoLmdjq1+q1Ycr8iSAEcOQ6QER0g uv4afU5fA/adqEgsgqAExGcTAf1j89SCCuGagBLw= From: Dave Crocker To: Thede Loder References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> Cc: bimi@ietf.org, Stephen Farrell , Marcel Becker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <6ac6da1c-6c60-b983-7e1a-90d3fb30ac5b@dcrocker.net> Date: Sun, 17 Feb 2019 18:50:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:50:29 -0000 On 2/17/2019 5:55 PM, Thede Loder wrote: > If end users treat messages with or without logos exactly the same, through what means will end users be made worse off or less safe when BIMI-sourced logos are widely used? Thede, This line of logic implies that the only valid argument against doing a standard is demonstrable proof that it will do harm. Besides that basic flaw in the implied foundation of your question, others have noted a variety of concerns both larger strategic opportunity cost and narrow, increased security exposures, and, of course, plausible misuse. There is also the concern for the cost of doing a standard; they are extremely expensive. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 18 07:59:39 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34046130F2F for ; Mon, 18 Feb 2019 07:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJI6ZpUH3fPQ for ; Mon, 18 Feb 2019 07:59:21 -0800 (PST) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BBB12950A for ; Mon, 18 Feb 2019 07:59:20 -0800 (PST) Received: by mail-yw1-xc2d.google.com with SMTP id p17so6631008ywg.0 for ; Mon, 18 Feb 2019 07:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YWhTVMjXjjzmQSBAktMTIecZk+BRSVG1vd7Xy3u2OI0=; b=Hw2LGMEPNY0ovkgczV1bONXWPq2A7rpgdJImkqmjgMiwhpaQdPldRi5fbTRn8qJPvz CGzxWsa6PoWR1cu4mM+HuVofgVxz8JV1vRA3s8YLhkx7Oj/TUPuqH3OvKAVNnEi1Ogb8 jXZm5qzECT5KDCv/7qm6ifSHIT1LWgv8Ltylg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YWhTVMjXjjzmQSBAktMTIecZk+BRSVG1vd7Xy3u2OI0=; b=VaLMNVhVpAsJu5rn6lHEcmKGAxJN8WEyRZZQX8MsDsd/K5Gev/6guzbX+u4KpaoRqR kgSPZoy11qvDF8l9A8DtJMB9esPPjzjMzjVD7/qgXNgUfqVrrapnFFUb4gVhTBLECf7i TVPdnUtOacWoZPreyOjo83wi4s4jB2OEJIAg8YCM0XX80GAzOHBAb4r+LzepPcU3OJjj rzWm9m2op/P0RMKhf2TxPs2NdMsy9iXf+o3Tjq6mB/nAXKLinrZ0GIWp3mJoj//wawiQ DTSnbpWOVw2ybQfMX8wCPC3drHJoH5wTfhYS3ttr1sgI0wR8AAX2yQ6JaedRZ+6XnO/P t/cw== X-Gm-Message-State: AHQUAuZDPt8Y894Y2Z4P1/4D9Rnz70NqBlx+cVwSGP252huRrYAidUyO Ipyze5Q2kbvBY8ENK/xWBOS0sg== X-Google-Smtp-Source: AHgI3IY3uLEGnGq8XnZHUWWVpOU2Aep/b8AKoOArlS5iGMh+wjjwIxKeqKC+KwbJkj/muGVf3/oX2w== X-Received: by 2002:a81:8384:: with SMTP id t126mr19439574ywf.200.1550505559581; Mon, 18 Feb 2019 07:59:19 -0800 (PST) Received: from ?IPv6:2620::690:7822:f9af:ce2:cb00:522a? ([2620:0:690:7822:f9af:ce2:cb00:522a]) by smtp.gmail.com with ESMTPSA id g193sm5793708ywh.57.2019.02.18.07.59.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 07:59:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: <6ac6da1c-6c60-b983-7e1a-90d3fb30ac5b@dcrocker.net> Date: Mon, 18 Feb 2019 10:59:17 -0500 Cc: Stephen Farrell , Marcel Becker Content-Transfer-Encoding: quoted-printable Message-Id: <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com> References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> <6ac6da1c-6c60-b983-7e1a-90d3fb30ac5b@dcrocker.net> To: Dave Crocker , bimi@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 15:59:23 -0000 > On Feb 17, 2019, at 21:50, Dave Crocker wrote: >=20 > On 2/17/2019 5:55 PM, Thede Loder wrote: >> If end users treat messages with or without logos exactly the same, = through what means will end users be made worse off or less safe when = BIMI-sourced logos are widely used? >=20 >=20 > Thede, >=20 > This line of logic implies that the only valid argument against doing = a standard is demonstrable proof that it will do harm. Which line of logic (or form of logic) lets you derive that implication? = =20 Even if we assume that the premise is true (end users treat messages = exactly the same), and if we agree that this implies end users will not = be made worse off through their own choices as a consequence, it says = nothing of other mechanisms through which users might be made worse off = (or better off). (If A implies B, it does not hold that not A implies = not B. The contrapositive does hold). =20 Under the logic rules that I am familiar with, your proposed implication = is not what is implied (nor am I implying it). =20 I asked the question to help move the discussion forward. Maybe we can = agree on some things. =20 If people believe that end users treat messages with and without logos = exactly the same, then we could potentially move on from considering the = positive or negative implications of end user-mediated choices. End = user choices can neither be a cause of improvement nor a cause of = worsening. =20 On the other hand, and given that end user security and safety is really = really important, it might not be the wisest thing to assume away = end-user mediated choices as a potential factor of change in outcomes. =20= If we let in the possibility that changes in choices could exist and may = make users worse off, we have to let in the possibility that end-user = choices may be a means through which we can make users better off. One = cannot have it both ways. =20 My personal opinion is that we need to leave open the possibility, = because to do otherwise violates the engineering practice of = =E2=80=98fail-safe=E2=80=99. =20 (That said, none of BIMI=E2=80=99s proponents are arguing that end = users' choices resulting from the display of logos will be a primary or = substantive cause of improvement in outcomes. No one is saying that = this mechanism should even be considered for reasons other than for its = potential to reduce safety. If you see language in the documentation = asserting otherwise, please bring it to the group=E2=80=99s attention ) = =20 The other reason I asked the question above was to motivate disclosure = of additional objections to BIMI. =E2=80=9CBIMI won=E2=80=99t do what = its designers think it will do=E2=80=9D does not seem like a reasonable = justification for disqualify it, even if it were true. Let=E2=80=99s = begin to consider the other issues. =20 > Besides that basic flaw in the implied foundation of your question, = others have noted a variety of concerns both larger strategic = opportunity cost and narrow, increased security exposures, and, of = course, plausible misuse. >=20 > There is also the concern for the cost of doing a standard; they are = extremely expensive. What I hear from the above as additional concerns are:=20 A) larger strategic opportunity costs B) narrow, increased security exposures=20 C) plausable misuse D) extremely expense of doing a standard=20 Can you elaborate on A? Help us understand these costs. =20 Can you provide examples for B and C so that we can begin a discussion = of mitigation strategies? =20 Regarding D, let=E2=80=99s begin a larger discussion of costs. Given = your experience, where do you see the costs in doing a standard? =20 Thede > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net =E2=80=94 Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: +1-415-420-8615 From nobody Mon Feb 18 08:31:11 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D3D130F2D for ; Mon, 18 Feb 2019 08:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-U-kLhLP97r for ; Mon, 18 Feb 2019 08:31:07 -0800 (PST) Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5291E1277D2 for ; Mon, 18 Feb 2019 08:31:07 -0800 (PST) Received: by mail-yw1-xc41.google.com with SMTP id n12so6635918ywn.13 for ; Mon, 18 Feb 2019 08:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IU/AotxQk7o8GZn+fZKVYjL24uyJ8fiPQFDWlZ6Q6bE=; b=uq2JSbiv9o4Ynx5IsvuyZkygqqgDHCQO993+dYqngOBkbO8YK1GelpZTNDqVhhDUN/ /FAhyAyvaMuFD4lARV8ERBgfo108q/luTq/OxGGMD5cbZkHTSXZvgbaJF/iRDagi+Hy5 JQMwy6pGQZZApkITbRDS5FC7Z1aMdrpm+Y96k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IU/AotxQk7o8GZn+fZKVYjL24uyJ8fiPQFDWlZ6Q6bE=; b=rHFzrzGSTSYprjEUw2vl+MwAYVwc1pxW8aDw04knRdEgDRO0bGZKCs+BdzW7LibRkg Xd6Tgc6yPE3n99AcCYRcrAfXo850fRsoHJ9cldrUXreT6EbXRwUv1vnOqi+7mJlg9pKt 0LMiOyzGlZzkSOOqR15yblkVweCpO1U+k4szYEgJKrrHW5+ik4ueQtqByagLZBJK2pWh FVBX4fUvkAAYyk5YQtdfk+G5WA3G7S9zba9NrDFhzp439P7Eu73kSkJtsvhPEAqVIJiJ 5nMN4nZM5sv0D+Qr6/mhTsUmNPAqOMBcy2XY266nw2ry6FQzsRb7wj8HWYeCYnUqhsCE s9xQ== X-Gm-Message-State: AHQUAuaQcuTvvmzbHOGsFWKI0Fwdx04+P8TFF7Kyx18lMnQn1XAeiMa+ 6edbDk4I27WTNG1TBSrA/35+We8ZB3Y= X-Google-Smtp-Source: AHgI3IaCDAT+iq1LGqB+Cc7gGlGD0mIyN5aAtCD3u7YGjNIwVTCY/zCF6s7ZKdIKJwY0lvaxwOPfGw== X-Received: by 2002:a81:6c17:: with SMTP id h23mr19290947ywc.250.1550507466220; Mon, 18 Feb 2019 08:31:06 -0800 (PST) Received: from ?IPv6:2620::690:7822:d07c:b578:21eb:1ff9? ([2620:0:690:7822:d07c:b578:21eb:1ff9]) by smtp.gmail.com with ESMTPSA id t136sm7045699ywe.101.2019.02.18.08.31.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 08:31:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> Date: Mon, 18 Feb 2019 11:31:04 -0500 Cc: "bimi@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> To: Stephen Farrell , Terry Zink X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 16:31:10 -0000 > On Feb 14, 2019, at 13:44, Stephen Farrell = wrote: >> On 14/02/2019 17:08, Terry Zink wrote: >> Are you saying these are all fine but in the sender photo it isn't? >> What's the fundamental difference between seeing a company's logo in >> the sender photo vs seeing it in the body of an email? Is it just a >> matter of turning of HTML and preventing those from loading? >=20 > I don't see sender photos and do not render HTML, except on > mobile device MUAs where I do not get that choice, which is, > for me, negative. Were bimi standardised it is entirely > unclear to me how various MUAs might handle it. But I very > much doubt that mobile device MUAs would provide that level > of user-control for bimi as they do not for bodies. And all > of us here are likely far more capable of configuring things > than most users. Hi Stephen,=20 Knowing your personal dislike of HTML-based email, and also that ~1 = billion =20 people read HTML email messages each day, many of whom like seeing=20 graphics, tables, and other mark up, would you have proposed back when=20= it was being considered for standardiation that it should never be = developed=20 or standardized? =20 >=20 >>> As someone who sends email (not as a bulk sender) from various >>> domains that I operate, I do not want to pay =E2=82=AC=E2=82=AC=E2=82=AC= to someone for an >>> additional cert, nor for an "approved" logo, in order to increase >>> the chances that my mail gets delivered. >>=20 >> Nobody is going to make you buy a cert, nobody is going to make you >> buy a logo, and so forth. It's up to you. >>=20 >> BIMI is an add-on; it augments the default experience, the lack of it >> doesn't downgrade the default experience. >=20 > Perhaps. Nonetheless there is at least one large mail service > that sends all mail from some domains I operate (that have never > sent spam and that have had stable IP addresses for years, DKIM > etc all good) to /dev/null and who won't respond to any form of > poking to try get that fixed despite a number of attempts. And > that provider is used (as MX) by people with whom I do need to > correspond, so I'm forced to use a different mail a/c to mail > those folks. >=20 > Yes I do indeed fear that bimi could and would be (ab)used by > some services to do more such dis-service. ISTM that damages > the mail environment rather than enhances it. Your fear is justifiable. =20 One can imagine future anti-spam or anti-fraud systems. They could =20 include message scoring functions that assign messages=20 from domains lacking authentication setup (or which do not have a valid=20= VM Cert) lower scores. And one can also imagine that this scoring=20 strategy will have a larger negative impact on deliverability if too few=20= other post-delivery derived reputation signals are available for a given=20= sender. In other words, low volume and newly registered domains. =20 While potentially raising the costs differentially to prohibative levels=20= for some of the =E2=80=9Cbad guys=E2=80=9D, cost is also raised for = those who were not=20 causing harm under the original system design; the =E2=80=98good = actors=E2=80=99 have=20 increased costs to continue to to get what they had before. =20 An analogy here from the offline world: =E2=80=9CBecause criminals = abused=20 ID-less open flying previously the norm for air travel, a system was=20 implemented in which everyone must now present IDs at airports;=20 if fliers do not have IDs they have to bear the costs of going out and=20= getting them, whether or not they were a good actor or a bad actor. =E2=80= =9C =20 I think the relevant question is:=20 If BIMI adoption contributes to a shift in the norms and certain costs=20= associated with effectively using applicable existing media, on the=20 balance, have we made these media better for the actors we care=20 about? =20 >>=20 >> Again, I'm unclear about the context of this statement. Nobody is >> going to make you as a sender, brand, or receiver send with BIMI. >=20 > I'm afraid that continues to be a concern of mine. (As an aside, > I am not a "brand" and have no ambition to become one:-) >=20 >> Nobody is going to make you retrieve logos from a store, nobody is >> going to make you verify any log, nobody is going to make you process >> additional headers. >=20 > In fact, my reading of bimi is that it does attempt to force a > receiving MTA/MS to actively download the image(s) and replace > the URL with one pointing at the MS (or nearby) - not doing so > would expose users of the MUAs using that MS to tracking once > those MUAs de-reference bimi URLs from the sender. Tracking is a concern and my personal take is that I=E2=80=99d like to = see it=20 become either impractical or completely transparent (or both)?. =20 Can someone from the Authindicators Working Group comment on Stephen=E2=80=99s interpretation? Stephen, can you point us to a = section? =20 >=20 >> Instead, it's about enhancing the email experience for those >> motivated to do so. And, BIMI provides a way to do this. >=20 > I realise that's your/the proponents position. Mine is that > bimi is only a negative. This is certainly a valid position, and thank you for stating it. This = is=20 in part what having a dialogue is about. =20 From nobody Mon Feb 18 08:37:00 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1931295D8 for ; Mon, 18 Feb 2019 08:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXBRQOsQEQtK for ; Mon, 18 Feb 2019 08:36:56 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B8C1277D2 for ; Mon, 18 Feb 2019 08:36:56 -0800 (PST) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1IGcGQc004092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2019 08:38:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550507897; bh=9NEGpnQFBubpLgEVXUX/L+jKWA17K5X9z1eGs/DKHQU=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=cFFpPu2ahPFr1TfFyZf3L+LA62SghR4r5jJvVCAWBovA1M0kGt/BDIWHqYWR+rh8E gbzbCvznSI94pQMDKwVUnl1XIbWdvRIsqoXv/JikoLS/IR57dLFrCfITJ6nLxWMaEq vIDrbmabs4eWPTapDLrNaZsNcNHFPhvigyp1H2z4= To: Thede Loder , bimi@ietf.org Cc: Marcel Becker , Stephen Farrell References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> <6ac6da1c-6c60-b983-7e1a-90d3fb30ac5b@dcrocker.net> <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 18 Feb 2019 08:36:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 16:36:59 -0000 On 2/18/2019 7:59 AM, Thede Loder wrote: > >> On Feb 17, 2019, at 21:50, Dave Crocker wrote: > Even if we assume that the premise is true (end users treat messages exactly the same), and if we agree that this implies end users will not be made worse off through their own choices as a consequence, it says nothing of other mechanisms through which users might be made worse off (or better off). Yes, limiting the scope of discussion to the topic at hand is certainly constraining. So, how is your point relevant to an evaluation of /this/ proposal? > I asked the question to help move the discussion forward. Maybe we can agree on some things. Thede, there has already been a number of very substantial concerns raised. You seem to be focusing on trying to raise new ones rather than dealing with the ones already raised. Your summary list, below, is more helpful. > If people believe that end users treat messages with and without logos exactly the same, then we could potentially move on from considering the positive or negative implications of end user-mediated choices. We could do that if Bimi documentation and its advocates didn't keep suggesting improvements in recipient handling of email. > End user choices can neither be a cause of improvement nor a cause of worsening. That implies that a user's choosing to believe a phishing message doesn't make things worse. > On the other hand, and given that end user security and safety is really really important, it might not be the wisest thing to assume away end-user mediated choices as a potential factor of change in outcomes. That seems to suggest ignoring the long and solid track record that expecting end-user mediated choices will happen has been wrong. Please explain why that's being ignored. > If we let in the possibility that changes in choices could exist and may make users worse off, we have to let in the possibility that end-user choices may be a means through which we can make users better off. One cannot have it both ways. You're introducing a view that hasn't been put forward. What's been put forward is that justifying a security mechanism based on an expectation of recipient decision-making during message processing is known to be inappropriate. > My personal opinion is that we need to leave open the possibility, because to do otherwise violates the engineering practice of ‘fail-safe’. Please explain. > (That said, none of BIMI’s proponents are arguing that end users' choices resulting from the display of logos will be a primary or substantive cause of improvement in outcomes. They have. And some of the documentations can be taken to imply that it will. > No one is saying that this mechanism should even be considered for reasons other than for its potential to reduce safety. The mechanism will /reduce/ safety??? > What I hear from the above as additional concerns are: > > A) larger strategic opportunity costs > B) narrow, increased security exposures > C) plausable misuse > D) extremely expense of doing a standard > > > Can you elaborate on A? Help us understand these costs. An effort like this both sets expectations and consumes resources. The former won't be met and will disappoint the market which will incline it to have lower receptiveness to the next proposal. People working on this won't be working on other strategic effort. Both of these are significant downsides. > Can you provide examples for B and C so that we can begin a discussion of mitigation strategies? I believe Stephen offered B. As fort C, cf DMARC. > Regarding D, let’s begin a larger discussion of costs. Given your experience, where do you see the costs in doing a standard? Consider the aggregate effort to produce a standard and consider the cost of the people who do that work. 30 years ago, I estimated at least US$1M for the simplest IETF standard. It hasn't gotten cheaper. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 18 08:45:07 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411B81277CC for ; Mon, 18 Feb 2019 08:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFj3uqX3C_nl for ; Mon, 18 Feb 2019 08:45:02 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799571277D2 for ; Mon, 18 Feb 2019 08:45:02 -0800 (PST) Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1IGkNr4004478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2019 08:46:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550508384; bh=f15MC9q0vElbqj2sLx7Ja3m4mGkGJ9runMSb++1F6eA=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=VwPz+ADZQGpze8uK+QNifbGU2H2W0kc8dtPUsrFwpfAp3w4oTZ14/1iUXA5plUGCc cWGIE4dv+Q/r1qYaZ+tXMJ83UawvnlMpcAb5XGqIYWGfb+zSdPQgwaIA4y2IEE12+4 ZHIFETvWivbjADbJzMpxYSF/yOLfCuHkj+hz6i4w= To: Thede Loder , Stephen Farrell , Terry Zink Cc: "bimi@ietf.org" References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 18 Feb 2019 08:44:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 16:45:05 -0000 On 2/18/2019 8:31 AM, Thede Loder wrote: >> On Feb 14, 2019, at 13:44, Stephen Farrell wrote: > Hi Stephen, > > Knowing your personal dislike of HTML-based email, and also that ~1 billion > people read HTML email messages each day, many of whom like seeing > graphics, tables, and other mark up, would you have proposed back when > it was being considered for standardiation that it should never be developed > or standardized? Thede, This seems to be in the "what about" realm of responding to criticism by raising a purportedly related hypothetical. That response mode typically seeks to dilute the original criticism. In effect in this case, it seems to suggest that no one should ever worry about new security attack surfaces. At the least, it certainly does not respond to the concern about the attack surface that was cited. >> Yes I do indeed fear that bimi could and would be (ab)used by >> some services to do more such dis-service. ISTM that damages >> the mail environment rather than enhances it. > > Your fear is justifiable. > > One can imagine future anti-spam or anti-fraud systems. Sorry. I am not understanding how the hypothetical that followed is relevant. Please explain. > I think the relevant question is: > > If BIMI adoption contributes to a shift in the norms and certain costs > associated with effectively using applicable existing media, on the > balance, have we made these media better for the actors we care > about? What norms? What costs? How will it do either? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Feb 18 09:34:34 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0949130E6E for ; Mon, 18 Feb 2019 09:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z07DFNgOQ0kg for ; Mon, 18 Feb 2019 09:34:30 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A94128D0B for ; Mon, 18 Feb 2019 09:34:30 -0800 (PST) Received: from localhost ([127.0.0.1]:31321 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1gvmo0-000FNY-SL for bimi@ietf.org; Mon, 18 Feb 2019 17:34:27 +0000 Message-ID: <94f8IUC7kuacFAOU@highwayman.com> Date: Mon, 18 Feb 2019 17:19:55 +0000 To: bimi@ietf.org From: Richard Clayton References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> <6ac6da1c-6c60-b983-7e1a-90d3fb30ac5b@dcrocker.net> <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com> In-Reply-To: <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com> MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 17:34:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com>, Thede Loder writes >(That said, none of BIMI’s proponents are arguing that end users' choices >resulting from the display of logos will be a primary or substantive cause of >improvement in outcomes. No one is saying that this mechanism should even be >considered for reasons other than for its potential to reduce safety. increase ? > If you >see language in the documentation asserting otherwise, please bring it to the >group’s attention ) from the front page of the brand indicators website: "What If You Could Put Your Brand On Every Email and Users Could Trust It’s You?" "will use brand logos as indicators to help people avoid fraudulent email" "When users see your logo, they’ll trust the email" "Stop Phishing" this reads to me that an improvement in outcomes is a key aim of BIMI since there is very little other substantive messaging there: Except of course it also says "giving marketers a huge new opportunity to put their brands in front of consumers for free" "we believe brand indicators will increase response rates, magnifying the power and reach of our marketing efforts." But I look forward to the "forest" document which sets out the high level of what is intended to be achieved, so that it is possible to assess the technical suggestions against that... ... and yes, if the main driver here is marketing then say so and the effort can be properly tuned, by those who are prepared to work on the standard effort, to get that right. But Aims first, Tech Details second: No point talking about certificate pinning if there will only ever be one CA for example. >The other reason I asked the question above was to motivate disclosure of >additional objections to BIMI. it's hard to object to generic aims if they aren't documented and appear to dilettantes like me to change with the year >Regarding D, let’s begin a larger discussion of costs. Given your experience, >where do you see the costs in doing a standard? Hiring me to read your last email, check your website text and proofread the brief response that I have penned here would likely cost you $100 at my chargeout rate. The opportunity cost of doing this email rather than working on better schemes for mitigating list bombing (say for a concrete example) is substantially more than $100 given the cost to the community (and particular victims) of that abuse. Multiply my small contribution by all the experts who need to keep up with email lists, consider the consequences of minor changes, brainstorm major improvements etc. and you will soon be talking substantial sums. The IETF does not pay for the expertise they garner (and I think would probably be rather worse off if they did) but "opportunity cost" is the key issue here -- in my view. - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGrpOzu8z1Kouez7EQJpCgCgn0xQxK5o32eG/EaZE8+oyHP/BW0AoKy1 7lI+D0FR5Peva1oVxKzgBluR =Mh0c -----END PGP SIGNATURE----- From nobody Mon Feb 18 09:41:13 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BBF1295D8 for ; Mon, 18 Feb 2019 09:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA-gIHUiDT7B for ; Mon, 18 Feb 2019 09:41:09 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1263312D4F0 for ; Mon, 18 Feb 2019 09:41:09 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id j85so3728681ybg.11 for ; Mon, 18 Feb 2019 09:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=K9cdjVGfppW4mwkvGia+p3espiUDNF/LyhXcFJwNzFQ=; b=NsV13RMhZ65+BlzF0UMucvrD8zTcgX0sSOpFCh8g2Cm7nhCUwoV72EhjzVTaxY+6C8 vSI5kjz/JCtJ03EGKV9fqs9kyc/yo+CJFy0qCyRSC9NVyU2xpN3jWvtv3zKgb+Fs7J4Q ZTvRmeGgNXbZ5nlfg6nrNdhyVN/Q0p6CtPr5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=K9cdjVGfppW4mwkvGia+p3espiUDNF/LyhXcFJwNzFQ=; b=DBp4N5QQUFXunNUviOUo3uwe1BJdAtpyYVfLlzedDy87QDbVdDsgp1lGe+tYiZZNwb UnDRtvtwogrXsHaFOv95oqmYgpAEE9ZlP296Amjkah/oqOv9XtBHsVLAkjaLKoDcsXd2 +caihECoCx7xPrXgTuG0NhVVeIpf97Joac/3zPFxhpxeqIwgQqXylI2JmvxPqlN2Ka9E Yf/8uYXNVR22Q4RNc5ZeSUJZ7jidAc4dn+7OmtAuUjsNwn2NUCyDH4yjTWRoPnR+35x4 AsUpzy9cXHhRmktaNZj/Etst3hpjWy4/gY6yeiCNM6+VG6eBtkBy4WPockS6sLucaa2b TUTA== X-Gm-Message-State: AHQUAuZTk6qrUq0lxenZqk9kSqVZxhzJCHQGvggmzxxI+S4C9RK+n9PY 2FODdNLBKN2MdAtQoRK4E95x9SNIcIk= X-Google-Smtp-Source: AHgI3IYRPahgzTNw8lzkiQe7A5CU6TGWIk0tzAp18YE0QFr0QvcKeKyWsP0iuZUSTTBtqmq5LZxeYQ== X-Received: by 2002:a25:2fd4:: with SMTP id v203mr20055444ybv.184.1550511668019; Mon, 18 Feb 2019 09:41:08 -0800 (PST) Received: from ?IPv6:2620::690:7822:a8b5:8fe9:6198:14de? ([2620:0:690:7822:a8b5:8fe9:6198:14de]) by smtp.gmail.com with ESMTPSA id 206sm7728119yws.95.2019.02.18.09.41.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 09:41:07 -0800 (PST) From: Thede Loder Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <90A7E47F-18E8-4EE7-B176-FA5FF3BAD41A@skyelogicworks.com> Date: Mon, 18 Feb 2019 12:41:06 -0500 Cc: "bimi@ietf.org" To: Dave Crocker , John R Levine , Tim Hollebeek X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Bimi] x.509 scalable enough, relevance of history of expectations X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 17:41:12 -0000 (Merging some discussion points about X.509. X.509 is relevant to BIMI = as the basis of the proposed Verified Mark Certificates, which can serve = as containers to convey optional evidence of proof of rights, real-world = actor identity, and other information along with the graphical (or = audio) =E2=80=9Clogos=E2=80=9D or marks. Concern over scalability has = been raised. =E2=80=9CIs it up to the task?=E2=80=9D And a call to = consider history)=20 In summary, it remains an open question as to whether it is up to the = task. Scalability is unlikely an issue (unless, say, there are = significant changes to proposed scope of use. No proposals known). = Additional discussion of the applicability of known forms of = =E2=80=9Cfaillure=E2=80=9D is a good direction to head in. =20 Recap of previous points made (paraphases of prior posts for context) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tim said: "DigiCert is willing to offer these certificates=E2=80=9D =20 =20 Wei wrote: "We (Authindicators WG) have been working with = Entrust-Datacard (CA) on the VM Certificate Guidelines, and they are = willing to issue VM Certificates. Others appear willing as well=E2=80=9D=20= Dave wrote: =E2=80=9CWhat is the basis for thinking that this will work? = At scale?=E2=80=9D =20 and =E2=80=9Cafter 30 decades, there is no existence proof at = scale.=E2=80=9D =20 Thede wrote: =E2=80=9CUnlike 30 years ago, there are now 50+ Certificate = Authorities. Issuance of VM Certs is operationally incremental to CAs = existing operations=E2=80=9D =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D End of Recap=20 > On 2/14/2019 10:57 AM, Thede Loder wrote: >>> On Feb 13, 2019, at 13:22, Dave Crocker wrote: >>>=20 >>> 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. >=20 > (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.) >=20 > As with X.500, X.509 had lofty and very general goals. It was = expected > to be the vehicle for certifying all sorts of features and = capabilities. > To my knowledge very few have been realized, and other than TLS-kinds > of uses, none at Internet scale. I don't know the range of uses that > were attempted, merely that none has seemed to survive at scale. This sounds like failure to meet expectations of "lofty and very general=20= goals=E2=80=9D, not outright failure. And if anything, not specific = failures that=20 are clearly applicable at this point to BIMI. =20 As proposed, BIMI=E2=80=99s need of X.509 does not require X.509 to = succeed for=20 "all sorts of features and capabilities". It needs only to succeed for = a very=20 specific (narrow?) kind of use, one with highly similar requirements=20 and operational characteristcs for the parties involved (according=20 to some doing X.509 in their day-job) to those associated with X.509=E2=80= =99s=20 mainstay uses today.=20 Is =E2=80=9CInternet scale=E2=80=9D use of X.509 actually a requirement = for BIMI? If you define=20 Internet scale as every end user having their own VM Cert, probably not. = =20 Such a scale requirement of this magnitude is therefore of minimal = concern. =20 Meanwhile, if in 5 years there are 50 million annually issued Verified=20= Mark Certificates, X.509 will be serving just fine meeting forseen = needs. =20 Is there an existence proof that X.509 can scale to this level? Yes; = existing=20 issuances levels are of the same order of magnitude, perhaps much larger=20= (others with first hand knowledge can comment). =20 If there=E2=80=99s enormous demand for Verified Mark Certificates and = the supporting=20 ecosystem must grow, it probably can on its own, and or we can put our=20= heads around how to accomodate the demand. This would be a great = problem=20 to have. =20 >=20 >=20 >> Did X.500 prove not up to the task because it failed on technical >> merits? >=20 > I encourage you to explore such questions in depth. =20 I accept John=E2=80=99s answer (repeated further below). =20 >=20 > My point, for the purposes of the current discussion, is that we can't = be casual about assuming that X.509 or, for that matter, this level of = capability certification, will work at Internet scale, because we don't = have an existence proof for it and we do know there are interesting = security risks to worry about and we have 30 years of discouraging = experience in this space. Nobody is being casual. We disagree on whether or not we have an = existence proof. And we likely disagree on whether or not Internet = scale is needed, until we come up with an acceptable definition of = Internet scale and how it applies. =20 >=20 >> Thede wrote: =20 >=20 >> 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. >=20 > John L wrote: > Technically X.509 works fine. The failure is administrative and = financial. Twenty years ago TLS certs cost several hundred dollars and = required extensive documentation, way more than what green bar certs ask = for now. There was a brisk race to the bottom ending up at Let's = Encrypt, which costs nothing and promises nothing. Green bar certs are = proceeding briskly down that path (price started around $300, now $75 = and dropping.) >=20 > Arguments along the lines of "this time is different" are not = persuasive. Thank you John. It sounds like X.509=E2=80=99s failures have not been = due to technical issues. =20 Also thanks for bringing up some of the history, as I think an = understanding of what has happened and why is relevant. =20 What I think will be important to delve into sooner or later is this = question:=20 "Does BIMI=E2=80=99s success and end-user safety hinge upon on asking = something of X.509 that it cannot deliver or where it is already known = to have failed? Alternatively, does BIMI ask of X.509 something for = which it has already demonstrated success? =E2=80=9C=20 For those who have not familiarized themselves with what is being = proposed as VM Certificates, the following is a place to start: =20 = https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcb= ja42w Thede =E2=80=94 Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: +1-415-420-8615 From nobody Mon Feb 18 10:03:33 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BB1130F6F for ; Mon, 18 Feb 2019 10:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSOEm1nC7cfZ for ; Mon, 18 Feb 2019 10:03:29 -0800 (PST) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3439012D4E7 for ; Mon, 18 Feb 2019 10:03:29 -0800 (PST) Received: by mail-yw1-xc31.google.com with SMTP id q128so6759266ywg.8 for ; Mon, 18 Feb 2019 10:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sSGuM6HNskpjw5llZnBWZw0s5ExRUBFL+odmYVYrBT4=; b=CYuhNcJD+YFsO22rN9KBr2SHbD2ArL/dbVXHacEVq+K4I4u55d8HmQGwEa4rOXzD03 30K88FGkxBVEXldLb39ye4mR8/B0LGlJHYkbo2Op2t+f2ZDDbLVR+kt3qrwUKr1MZfi/ fcHynQiXt2uHIDwO6cs2B1UujVrnALX80CdXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sSGuM6HNskpjw5llZnBWZw0s5ExRUBFL+odmYVYrBT4=; b=uoRUlfiZ0ejXT7TSFoTbvuN3kLGhjMlrdj2mz8m1K3ZEXeiFVPdZSnVPseFdgSuiEX i8Y3UZWGlLl+N3i7NTsLqjh/K9Mko9mGaKLKPuDHc7Ziz/hR3fJYGkLFpGaVt9+plt5D Dvc4E+DaSP8i78XF5B6uVKMHsHWZU/LIiMiM81xiNYj7rDBqS1kp2/pyAfdDPPzzrmiL fABkzlBlt9gZ75ddDSB44kWxKhTIDQOQHHu7sB8w703fHQt5h8A8p5eh5tBpYH8QP10m fzaT7w9jIV6q22FEyElbBcf4IngdZXH9glyZWKLSSztXQ5hnDNLwyIi35OaBECHH8H0a PciQ== X-Gm-Message-State: AHQUAubUAi/kHgn9aR7L1rjTgokwZ78/UuNSldYKEcmzyq7YG95NKl9P fSox/uvAbwB4FzlUWqd/Mv2pAA7okn0= X-Google-Smtp-Source: AHgI3IaNhUOfHHzasTZTq743byAEBnUm5YHLz5/Xp4GLFZJDgBX5FuKDf1I74diGvBz6tGtaO4u8Aw== X-Received: by 2002:a81:b101:: with SMTP id p1mr20463696ywh.454.1550513008267; Mon, 18 Feb 2019 10:03:28 -0800 (PST) Received: from ?IPv6:2620::690:7822:3457:63ab:a70f:2946? ([2620:0:690:7822:3457:63ab:a70f:2946]) by smtp.gmail.com with ESMTPSA id j20sm240409ywj.69.2019.02.18.10.03.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 10:03:27 -0800 (PST) From: Thede Loder Message-Id: <81ADFED9-C076-4C9E-BD29-914490D04DF8@skyelogicworks.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F618FB51-C630-4C2F-8C31-DF30210C6935" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 18 Feb 2019 13:03:26 -0500 In-Reply-To: <69304caf-2e46-d223-9e53-80b8c18ab25f@cs.tcd.ie> Cc: Terry Zink , "bimi@ietf.org" To: Stephen Farrell References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> <69304caf-2e46-d223-9e53-80b8c18ab25f@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 18:03:32 -0000 --Apple-Mail=_F618FB51-C630-4C2F-8C31-DF30210C6935 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 15, 2019, at 11:16, Stephen Farrell = wrote: >=20 > Hi Terry, >=20 > Just on this point for now... >=20 > On 14/02/2019 23:36, Terry Zink wrote: >>> In fact, my reading of bimi is that it does attempt to force a >>> receiving MTA/MS to actively download the image(s) and replace >>> the URL with one pointing at the MS (or nearby) - not doing so >>> would expose users of the MUAs using that MS to tracking once >>> those MUAs de-reference bimi URLs from the sender. >>=20 >> Where does it say that in the BIMI spec? >=20 > I'd have to go check the drafts again, but that's how it > was described to me at [1] and that matches my recollection > of the drafts. >=20 > Cheers, > S. >=20 > [1] = https://mailarchive.ietf.org/arch/msg/spasm/cf-jmY5tOx-zIdklMyfLGdp9YqY = Stephen, thanks for this reference. While its technically possible that = a receiver might fetch a certificate at message-receipt time, receivers not wishing = to=20 enable sender tracking have another straightforward option: they can = maintain=20 access to the Certificate Transpareny logs, and therefore have a copy of=20= every issued certificate (and their embedded list of FQDNs) and so = retrieve relevant contents without any outbound communication to the net. In = practice,=20 receivers might implement daily DNS checks, during which they lookup and=20= confirm the current BIMI record for the set of domains known to be = publishing=20 them, or to discover new ones that have begun doing so.=20 Thede --Apple-Mail=_F618FB51-C630-4C2F-8C31-DF30210C6935 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 15, 2019, at 11:16, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Terry,

Just on this point for now...

On = 14/02/2019 23:36, Terry Zink wrote:
In fact, = my reading of bimi is that it does attempt to force a
receiving MTA/MS to actively download the image(s) and = replace
the URL with one pointing at the MS (or nearby) - = not doing so
would expose users of the MUAs using that MS = to tracking once
those MUAs de-reference bimi URLs from = the sender.

Where does it say = that in the BIMI spec?

I'd = have to go check the drafts again, but that's how it
was = described to me at [1] and that matches my recollection
of = the drafts.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/msg/spasm/cf-jmY5tOx-zIdklMyf= LGdp9YqY


Stephen, thanks for this = reference.  While its technically possible that a = receiver
might fetch a certificate at message-receipt time, = receivers not wishing to 
enable sender tracking have = another straightforward option: they can maintain 
access = to the Certificate Transpareny logs, and therefore have a copy = of 
every issued certificate (and their embedded list of = FQDNs) and so retrieve
relevant contents without any outbound = communication to the net.  In practice, 
receivers = might implement daily DNS checks, during which they lookup = and 
confirm the current BIMI record for the set of = domains known to be publishing 
them, or to discover new = ones that have begun doing so. 

Thede




= --Apple-Mail=_F618FB51-C630-4C2F-8C31-DF30210C6935-- From nobody Mon Feb 18 10:26:38 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FB0130F58 for ; Mon, 18 Feb 2019 10:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKpHc9Wz0SlF for ; Mon, 18 Feb 2019 10:26:32 -0800 (PST) Received: from mail.highwayman.com (happyday.demon.co.uk [80.177.121.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D19012894E for ; Mon, 18 Feb 2019 10:26:32 -0800 (PST) Received: from localhost ([127.0.0.1]:22723 helo=happyday.al.cl.cam.ac.uk) by mail.highwayman.com with esmtp (Exim 4.91) (envelope-from ) id 1gvncR-000FlR-JR; Mon, 18 Feb 2019 18:26:19 +0000 Message-ID: Date: Mon, 18 Feb 2019 18:24:55 +0000 To: Thede Loder Cc: Dave Crocker , John R Levine , Tim Hollebeek , "bimi@ietf.org" From: Richard Clayton References: <90A7E47F-18E8-4EE7-B176-FA5FF3BAD41A@skyelogicworks.com> In-Reply-To: <90A7E47F-18E8-4EE7-B176-FA5FF3BAD41A@skyelogicworks.com> MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: Turnpike Integrated Version 5.03 M Archived-At: Subject: Re: [Bimi] x.509 scalable enough, relevance of history of expectations X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 18:26:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <90A7E47F-18E8-4EE7-B176-FA5FF3BAD41A@skyelogicworks.com>, Thede Loder writes >"Does BIMI’s success and end-user safety hinge upon on asking something of X.509 >that it cannot deliver or where it is already known to have failed? yes .. certificate revocation basically doesn't work today and never has. Here's a fairly friendly summary https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is- broken-in-practice-af3b63b9cb3 In practice where important certs have had to be revoked the approach taken has been to update browsers. The equivalent approach in BIMI is not immediately clear to me. There's also some careful thought needed about the equivalent of "revocation" for DNS information, since I expect people will set long TTLs on BIMI data. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBXGr4dzu8z1Kouez7EQJ+LQCgtBnU1iq8xsfMQlQc9ErncDRxo3UAnRIp /VEEvEI/AzwCpDAAyXkQwIDD =6znR -----END PGP SIGNATURE----- From nobody Mon Feb 18 10:37:16 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4B9130F3F for ; Mon, 18 Feb 2019 10:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=skyelogicworks.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46qznboVed5s for ; Mon, 18 Feb 2019 10:37:13 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C4C130F3E for ; Mon, 18 Feb 2019 10:37:13 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id s5so7139536ybp.6 for ; Mon, 18 Feb 2019 10:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skyelogicworks.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q6W6+Biq0bqDAxCmk+aqV11MjWjqqtdOdTMRP0RJNhY=; b=Jbk680bYGTnhHq9hWcErHarcEf7b8U/sFlEspumhYeY4Txbk6QD6kQ9DMxiz/e1mSu ZBNxPjictlVMsLP+9BG9POfWPVGjypQ26I5yDExa9X9/j84fp+quQF2b6SuOQB4x3Bd2 tPizERbEKbrgHjxZaZsa8J/9mgOPzgYdfNbXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q6W6+Biq0bqDAxCmk+aqV11MjWjqqtdOdTMRP0RJNhY=; b=AiULwef6SlMyMeYGUFhxzfqbvKWE1QbHMl0l5fz8W2zVvOCzN1Ncp1stPQzTygeLz/ lISRJ2P7LVn3N+AxndcHsx2kzqwbmLe5Dve6fJkvAyudb9EuG7AeV8rRIm/nyumClb6R rIM2uyu0Mm183zpRFu1MlF76DWpaleg7CCHaZ75W65kAvB8+i06MzAQQihq8Onz1C80X /aqbockVUi6clhhjFxdTXxUMg3arAnShQkRrqBqGcbRl4rkJtrf+Bm+mS9b6EPq6peky SP+yJxZmmEshaLT3/z567znzEPwOt9tOKfJd21EeK55XRdAmf9TFK8jOSFYHRIoSNgPm G6mA== X-Gm-Message-State: AHQUAuYsQOV/V5/PXcAa2WxT+fq3983DOR3DR9MX/3NsOJUUllUWnjDL rzTEbkhEXk5SwVxD3NCHEFYkqg== X-Google-Smtp-Source: AHgI3IY3QUZu8lLQAhlgcgdmf5Pry8W4hfPufgtSw4RBrPpkNGPRkyvSrguTfQfq4dsO6WGqLa2Tyg== X-Received: by 2002:a25:dc49:: with SMTP id y70mr20667397ybe.288.1550515032322; Mon, 18 Feb 2019 10:37:12 -0800 (PST) Received: from ?IPv6:2620::690:7822:b031:4868:37ae:2b3e? ([2620:0:690:7822:b031:4868:37ae:2b3e]) by smtp.gmail.com with ESMTPSA id d70sm3863519ywh.34.2019.02.18.10.37.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 10:37:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Thede Loder In-Reply-To: <2e957f28-4589-60ab-b48e-30fbdb4cc12d@cs.tcd.ie> Date: Mon, 18 Feb 2019 13:37:10 -0500 Cc: bimi@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4B35F22C-59B5-4815-8973-42D2027995AA@skyelogicworks.com> References: <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <2e957f28-4589-60ab-b48e-30fbdb4cc12d@cs.tcd.ie> To: Stephen Farrell , Marcel Becker X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 18:37:15 -0000 Stephen,=20 >> and mua visual >> design (while interesting) should not be really relevant to this >> discussion imo. >=20 > I disagree here though - the proponents of bimi are arguing or > assuming that presentation of a logo will have some positive > effect. ISTM that means that calls for providing some convincing > arguments about MUA visual design (which admittedly is not a > common thing in an IETF context). I've yet to see such argument > offered. Can you tell me if you agree or disagree with the following statement?=20= "To say that facilitating the regular practice of displaying logos (as=20= sender identity) can bring about positive effects is not the same=20 as saying the positive effects are due to, for example, improved=20 end user-mediated choices. =E2=80=9C=20 If you and others agree, maybe a way to move ahead is to next establish=20= an agreement on possibility:=20 =E2=80=9CIs it possible that ways might exist for end users to be made = safer=20 without the users having to be reponsible for directly making safer=20 choices for themselves? =E2=80=9C =20 If we agree such a thing might be possible (and it sounds like perhaps you do, but are waiting for a proposal to evaluate), then we can move to=20= a discussion of evaluating proposed ways. =20 Thede =E2=80=94 Thede Loder Managing Director, Skye Logicworks LLC E: thede@skyelogicworks.com M: +1-415-420-8615 From nobody Mon Feb 18 13:47:09 2019 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C2D131056 for ; Mon, 18 Feb 2019 13:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp78xufGKtwV for ; Mon, 18 Feb 2019 13:47:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4AE131051 for ; Mon, 18 Feb 2019 13:47:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5433BBE47; Mon, 18 Feb 2019 21:46:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAc0SrPCMbKR; Mon, 18 Feb 2019 21:46:57 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A09FBBE2F; Mon, 18 Feb 2019 21:46:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550526417; bh=vW7owyqNbyRagDnrQug/yRPMRPNPOjZ6G1Ssnuz6920=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=z/jLpqx07pHsppOjXYlj//x0xxGt73Ej0PUdlqaaZVOII5gh1XBxNFLstxNrABrfI DKxnAUFhYxB/DYsX+LhCp4WkInL3ezEMg9dFXFhz3p4B4ZQ3RfzDvw+YAgyj3IEYLE WcAY0/N5vmr/EdgBrjCXI/e/s/dpwij/jJzn2vVY= To: Thede Loder , Terry Zink Cc: "bimi@ietf.org" References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 18 Feb 2019 21:46:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YmvDVwTr3wPEM6iZJWi0HrA80lbVmMTMO" Archived-At: Subject: Re: [Bimi] (non)desire for bimi X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 21:47:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YmvDVwTr3wPEM6iZJWi0HrA80lbVmMTMO Content-Type: multipart/mixed; boundary="6pSbKOthXxTF1l5UvJa8eQOIBMm8RixOP"; protected-headers="v1" From: Stephen Farrell To: Thede Loder , Terry Zink Cc: "bimi@ietf.org" Message-ID: Subject: Re: [Bimi] (non)desire for bimi References: <17a79377-587a-c1fa-5927-23712ef15227@cs.tcd.ie> <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> In-Reply-To: <751D273E-3813-442C-98C4-BC0212093E37@skyelogicworks.com> --6pSbKOthXxTF1l5UvJa8eQOIBMm8RixOP Content-Type: multipart/mixed; boundary="------------C61458C088E416B1F4490096" Content-Language: en-GB This is a multi-part message in MIME format. --------------C61458C088E416B1F4490096 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Answering 3 mails at once.. On 18/02/2019 16:31, Thede Loder wrote: > Hi Stephen, >=20 > Knowing your personal dislike of HTML-based email, and also that ~1 > billion people read HTML email messages each day, many of whom like > seeing graphics, tables, and other mark up, would you have proposed > back when it was being considered for standardiation that it should > never be developed or standardized? I don't recall details of when HTML body parts were standardised. I do consider that blindly running random code from the Internet as a default is one of the worst errors that web and mail user agent developers have made in the last two decades. We are still discovering some of the non-obvious consequences (Spectre etc.) I am happy to be tech savvy to know that I can, and how to, turn that down to something acceptable, which I find entirely usable. I'm sad that's not the default. I do maintain that the world would be a little better were user agents much more conservative in how they handle active content like HTML. >> Yes I do indeed fear that bimi could and would be (ab)used by some >> services to do more such dis-service. ISTM that damages the mail >> environment rather than enhances it. >=20 > Your fear is justifiable. I'm sad to hear that. > If BIMI adoption contributes to a shift in the norms and certain > costs associated with effectively using applicable existing media, on > the balance, have we made these media better for the actors we care=20 > about? That's an unanswerable (and hence badly formed) question. A "shift in norms" can be overall negative or not so "on the balance" can't be answered, at least not as an answer to that question. > Tracking is a concern and my personal take is that I=E2=80=99d like to = see it > become either impractical or completely transparent (or both)?. Can > someone from the Authindicators Working Group comment on Stephen=E2=80=99= s > interpretation? Stephen, can you point us to a section? Don't have time 'right now to re-read the various drafts sorry. Logically though, adding a URL that gets de-referenced has to be a new tracker, and hence is IMO bad. Supposed ways of avoiding the MUA doing the de-referencing seem almost fictional as they require all MDAs to have intercepted and replaced that URL to avoid their MUAs doing so. I don't believe you can eliminate that form of tracking unless you send the image inline. (Which'd have other downsides is a very different design.) I can't see how that tracking aspect could be a surprise to anyone. On 18/02/2019 18:03, Thede Loder wrote:> >=20 > Stephen, thanks for this reference. While its technically possible that a receiver > might fetch a certificate at message-receipt time, receivers not wishing to > enable sender tracking have another straightforward option: they can maintain > access to the Certificate Transpareny logs, and therefore have a copy > of every issued certificate (and their embedded list of FQDNs) and > so retrieve > relevant contents without any outbound communication to the net. In practice, > receivers might implement daily DNS checks, during which they lookup > and confirm the current BIMI record for the set of domains known to > be publishing > them, or to discover new ones that have begun doing so. I have to say that seems pretty far-fetched (to put it kindly). But if there's a more fleshed-out design I'd be interested in a pointer. To poke at just one aspect, I've no idea what CT data structure you are assuming is in a mail. If it's not e.g. an SCT or signed tree-head then that seems to be nothing to do with CT and more that you seem to be imagining a new image repository where images just happen to be wrapped in X.509 cruft. Lastly, if the supposed CT-log/image-DB is accessed by the MUA then that's the same tracking as before. If you envisage the MDA doing that daily then that seems quite brittle and unlikely (as before). On 18/02/2019 18:37, Thede Loder wrote: >=20 > Can you tell me if you agree or disagree with the following > statement? >=20 > "To say that facilitating the regular practice of displaying logos > (as sender identity) can bring about positive effects is not the > same as saying the positive effects are due to, for example, > improved end user-mediated choices. =E2=80=9C I think that's a loaded question, sorry and I don't plan to take the bait:-) I continue to maintain that MUA UI design is relevant to this discussion (which is unusual in an IETF context) and that I'm unaware of evidence as to the claimed effects (good or bad) of displaying graphics as proposed here. If no evidence is offered that such graphics overall do good, then my conclusion is that this effort is not worthwhile. (But that it is worthwhile opposing, as I do see dangers, as well as costs, in what is proposed - sorry again;-) If you or someone has some evidence that displaying these logos has some overall positive effect, then sending a pointer to that evidence would seem the obvious answer. Cheers, S. --------------C61458C088E416B1F4490096 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------C61458C088E416B1F4490096-- --6pSbKOthXxTF1l5UvJa8eQOIBMm8RixOP-- --YmvDVwTr3wPEM6iZJWi0HrA80lbVmMTMO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxrJ9EACgkQWrL68XsX K+o9uQ/8DuRKE1XV+yUfpIK5/6rA/dbXF4xI6ScHuS0KwYekBA1R6iCCaGQMPmSj ittjr4VNPvCICZp32hjnx8v89IAWI4Uvt4Ns8up+lzlpJDosNEYlCtjO/MlMhQ5k X7SESOmGoWI045UE1RuGoMXApEng2oAAlThtjTT1DQc+EbM6UH6bhM/qpfKxEX9c KSkyrO4O8w7oMgo/uprYWMML3yFTV49LZT0/tYjrQGR+s3TnLSo3CpzDzZb9B6CJ lql2MPTomYn8AhWfxECN+g+TwAkEH9gi1cBXn0lv2oqoeN9Fc8Udhtob6nREFxMr mQNlhTwMQA08ahNwvN22A4e9L2+lqCUbPoj211QaUBBN+pxZJY/l3Col7DVfISHA StGLj3e2MWB+fVIIDRV3+YoJzchtTwGda9lmiHQAEOoUWn1EA85SG9MuUNTDnS24 QK0f29Wy6SWeWqJIX2QC0CmNVoLhC2QlxO+tbKOOIemJ42Z7g1wrarCD4XnB+vOL R7omjhBxSuJMI0qvOkX75zJaoe98GyQR0WIu7XodRBWsNgBceMbz1QlDXuY4Euqy peJ17PoOtJX7TMT64Uot11oxnd54Xf2hPDr/HIDpXgznKQjfDtoxuOdLFsP/bcaQ KS5XQ00R61PnvdybfZgwEgpseby5tNvN13kVpM0hXhKC1QVZxNE= =08LD -----END PGP SIGNATURE----- --YmvDVwTr3wPEM6iZJWi0HrA80lbVmMTMO-- From nobody Tue Feb 19 12:55:29 2019 Return-Path: X-Original-To: bimi@ietf.org Delivered-To: bimi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4480C130EAB; Tue, 19 Feb 2019 10:40:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: bimi-chairs@ietf.org, bimi@ietf.org, lflynn@amsl.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155060165819.20717.17704923301786260120.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2019 10:40:58 -0800 Archived-At: X-Mailman-Approved-At: Tue, 19 Feb 2019 12:55:28 -0800 Subject: [Bimi] bimi - New Meeting Session Request for IETF 104 X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 18:40:58 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the bimi working group. --------------------------------------------------------- Working Group Name: Brand Indicators for Message Identification Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: dmarc lamps dispatch jmap extra People who must be present: Alexey Melnikov Resources Requested: Special Requests: Also avoid security area BOFs. Request Tues, Wed, Thurs ---------------------------------------------------------