Re: [lamps] Common Protected Header practice documented (was "Memory Hole")

[Alexey Melnikov <[e-mail]>]

Hi Bernie,

Just to close the loop on this:

On 14/06/2020 15:10, Bernie Hoeneisen wrote:
> Hi Daniel
>
> Thanks for this great document! I was finally able to read and assess 
> it. I believe it is quite useful to assist in finding a solution for 
> our chartered work item on Header Protection.
>
> I have some questions related to the S/MIME examples:
>
> 1) The examples you provide for S/MIME have a simple structure, i.e. 
> the body consist of a single MIME entity. How would an example look 
> with the solution your are proposing, if it was a tree of MIME 
> entities (e.g. text and html as multipart/alternative)?
>
> 2) In the examples (e.g. 9.2.) you are using "Content-Type: 
> text/plain", however the content appears to be a full "message/rfc822" 
> email. To me this looks like a mismatch between Media-Type and 
> Content. To my understanding, whatever is in "Content-Type: 
> text/plain" is unformated and is not guaranteed to be parsable. 
> However your proposal suggests to parse this to replace the outer 
> header fields. Have I misunderstood anything?

So the protected body part in that example is:

    Content-Type: text/plain; charset="us-ascii"; protected-headers="v1"
    From: Alice Lovelace <[e-mail]>
    To: Bob Babbage <[e-mail]>
    Date: Tue, 26 Nov 2019 20:03:00 -0400
    Subject: The FooCorp contract
    Message-ID: <[e-mail]>

    Bob, we need to cancel this contract.

    Please start the necessary processes to make that happen today.

    (this is the 'smime-multipart-signed' message)

    Thanks, Alice
    --
    Alice Lovelace
    President
    Example Corp

This is a correct body part (using RFC 2045 terminology) of media type 
"text/plain". Presence of "From" or "Subject" doesn't change its media 
type. BNF for body part header is described in Section 3 of RFC 2045:

      MIME-part-headers := entity-headers
                           [ fields ]
                           ; Any field not beginning with
                           ; "content-" can have no defined
                           ; meaning and may be ignored.
                           ; The ordering of the header
                           ; fields implied by this BNF
                           ; definition should be ignored.

Best Regards,

Alexey

> Looking forward to your answer!
>
> cheers,
>  Bernie
>
> -- 
>
> http://ucom.ch/
> Modern Telephony Solutions and Tech Consulting for Internet Technology
>
>
> On Mon, 4 Nov 2019, Daniel Kahn Gillmor wrote:
>
>> Hey LAMPS folks--
>>
>> At (and shortly after) the OpenPGP e-mail summit [0], a group of MUA
>> developers went ahead and documented the way that several of us have
>> been handling header protection in a backward-compatible way.
>>
>> This bundle of techniques used to be known as "Memory Hole" a while back
>> but for a couple years now we've been calling it just "Protected
>> Headers", since "Memory Hole" was confusing and weird for some people.
>>
>> Hopefully this document can serve as input for appendix A.1.1 of
>> draft-ietf-lamps-header-protection-requirements-01 [1].
>>
>> The new draft is at:
>>
>> https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/
>>
>> (it's "draft-autocrypt-…" because it's not a single-person draft, and
>> because most of the experience we have in this comes from
>> implementations actively engaged in the Autocrypt project [2]. But it is
>> not a formal part of the Autocrypt specifications at this time, and it
>> is not intended to ever be limited to Autocrypt implementations.)
>>
>> To whet your appetite, the summary:
>>
>> -------
>>   The Protected Headers scheme relies on three backward-compatible
>>   changes to a cryptographically-protected e-mail message:
>>
>>   *  Headers known to the composing MUA at message composition time are
>>      (in addition to their typical placement as Exposed Headers on the
>>      outside of the message) also present in the MIME header of the
>>      root of the Cryptographic Payload.  These Protected Headers share
>>      cryptographic properties with the rest of the Cryptographic
>>      Payload.
>>
>>   *  When the Cryptographic Envelope includes encryption, any Exposed
>>      Header MAY be _obscured_ by a transformation (including deletion).
>>
>>   *  If the composing MUA intends to obscure any user-facing headers,
>>      it MAY add a decorative "Legacy Display" MIME part to the
>>      Cryptographic Payload which additionally duplicates the original
>>      values of the obscured user-facing headers.
>>
>>   When a composing MUA encrypts a message, it SHOULD obscure the
>>   "Subject:" header, by using the literal string "..." (three U+002E
>>   FULL STOP characters) as the value of the exposed "Subject:" header.
>>
>>   When a receiving MUA encounters a message with a Cryptographic
>>   Envelope, it treats the headers of the Cryptographic Payload as
>>   belonging to the message itself, not just the subpart.  In
>>   particular, when rendering a header for any such message, the
>>   renderer SHOULD prefer the header's Protected value over its Exposed
>>   value.
>>
>>   A receiving MUA that understands Protected Headers and discovers a
>>   Legacy Display part SHOULD hide the Legacy Display part when
>>   rendering the message.
>> -------
>>
>> Please don't be put off by the draft length -- nearly half of the
>> document consists of test vectors that implementers can use to verify
>> their ability to consume well-formed, protected-header messages.
>>
>> I'd be happy to present this work in Singapore if there's space on the
>> agenda.
>>
>> Feedback, critiques, comments, etc, are all welcome.
>>
>> Regards,
>>
>>        --dkg
>>
>> [0] https://wiki.gnupg.org/OpenPGPEmailSummit201910
>> [1] 
>> https://tools.ietf.org/html/draft-ietf-lamps-header-protection-requirements-01#appendix-A.1.1
>> [2] https://autocrypt.org/
>>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm