Re: [lamps] Draft addition of header protection to the LAMPS charter

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2019-01-03 20:24:15 -0500, John Levine wrote:
> In article <[e-mail]> you write:
>
>>I think we need to include what's the current situation with this 
>>issue, in particular mention that there is a solution in on Standards 
>>Track already (RFC5751). How about something like this:

Bernie, thanks for your proposed change.  The second revision of your
text looks fine to me.  It is certainly "not widely implemented" --
iirc, there was only one implementation of it anywhere last i looked.

FWIW, i lean in Bernie's direction as far as "somewhat underspecified"
because the specification does lead to significant usability gaps (as
identified later in the proposed charter text) due to lack of guidance
about how a receiving MUA should interpret conflicting headers on the
inside and outside of the message's cryptographic envelope ("This entity
SHOULD be presented as the top-level message, taking into account header
merging issues as previously discussed." -- but with no mention of
"merging" anywhere else in the document).

This isn't so much a UI issue (which would be out of scope, as Russ
says) as it is an open semantic question, and i do think that's within
scope here.

> If we're adding references to the charter which seems to me a
> premature optimization, add RFC 6376, which is a well-specified
> mechanism for full-message signatures, too.

John, would you be ok with leaving out RFC 6376 (DKIM) if we changed the
charter text to say "end-to-end cryptographic protection" instead of
just "cryptographic protection"?  is DKIM ever used by the sender
themselves, instead of by the domain itself (for example, with a
user-specific selector)?

I'm not sure that the charter text is a good place for such a catalog,
though perhaps these references could show up in a "related mechanisms"
section of the resultant document.

         --dkg