[Bimi] Alternate proposal

[John C Klensin <[e-mail]>]

As promised in my recent "Radical critique" note, a suggestion
about a completely different way to approach the BIMI problem,
one that would be far less complex and problematic.  This is
just an outline with many details left to be filled in -- my
purpose in sending the note is to encourage people to think
differently about the issues and see if there is interest in
further discussion.

Overview: 

Drop the idea of new mail header fields entirely.  With them,
drop the (slightly odd) uses of mechanisms intended to validate
mail senders, header field integrity, etc., the requirement for
MUAs to be "Affiliated" with MBPs, and for Mailboxes or Mailbox
Providers to be special in any way.  Also drop DNS dependencies
connected with entirely different concepts.

Instead, define a new MIME content-type, presumably something
like Application/BIMI.  If any trick supplemental information is
needed, use parameters to the Content-type: header field.
Probably that would give a typical message these day three body
parts with content types respectively
   BIMI
   text/plain
   text/html

If you really needed to, you could make BIMI multipart, but that
would lose the advantages of the message looking perfectly
reasonable to MUAs that were not BIMI-aware (see below).

Make it as complicated as it needs to be (but not worse),
including providing for relevant parts of the content to be
digitally signed.  From the discussions so far, I don't see any
need for encryption, which makes things much less complex, but
there is nothing in what I'm suggesting that would prevent it.
MUAs who do not recognize the content type may generate warning
messages to the user, but every MUA in the world with MIME
support already has code for dealing with unrecognized content
types.  

An MUA that does want to handle the content type presumably
installs appropriate application code.   Vendors who want to use
BIMI could reasonably provide that code as a library or
equivalent without getting involved with "affiliated".   And,
then, that content-type specific MUA extension or add-on
provides for  downloading whatever special (i.e., specific to
BIMI) certificates the user wants to have available.  My
instinct at the moment would be to build validation on OpenPGP -
most of the code that would be needed is readily available, many
MUAs already have parts of it built-in, and so on.  Especially
if encryption is not needed, this is perfect web of trust stuff,
with the MUA client needing to install only those keys locally
that it obtains from the MSP and trusts.   The certificates and
keys would also be specific to BIMI, rather than shared with
other applications, so things like expiration dates (and what to
do with expired ones) could be per-MSP and tailored to the needs
of BIMI, rather than compromises with the needs of other
applications.

The MBP would not need to be special in any way.  And just
exactly how to handle / display valid BIMIs would be a UI issue
for the MUA, not more complexity that needed to be specified in
the protocol.

Would something along those lines make any sense at all?

best,
    john