Subject: Re: [lamps] LAMPS sample keys and certificates

From: Russ Housley <[email-masked]>
Date: Thu, 19 Dec 2019 18:32:28 -0500

All:

We set a goal at IETF 106 of learning how different user agents handle the two approaches to header protection.  I would like to see reports on the mail list so that we can choose a way forward.  Please help!

Russ

> On Nov 18, 2019, at 2:45 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Hi all--
> 
> I've just published:
> 
>   https://www.ietf.org/id/draft-dkg-lamps-samples-00.html
> 
> This draft contains sample X.509v3 certificates, and corresponding
> secret keys for a sample CA, and for two e-mail users, Alice and Bob.
> It provides the certificates and keys in PEM-encoded form and (for Alice
> and Bob) in PKCS#12 bundles, so they should be relatively easy to
> import.
> 
> My hope is that they are useful for generating and interpreting sample
> S/MIME (CMS) messages, and part of a larger plan to generate test
> vectors that will be useful in demonstrating protected header behavior
> on existing clients.
> 
> I'd appreciate any feedback or suggestions on the draft and the sample
> keys and certificates and PKCS#12 files.
> 
> I'm currently building the draft from the git repo at
> https://gitlab.com/dkg/lamps-samples -- editorial patches, issues, etc
> are welcome at the gitlab interface, though i would prefer if any
> substantive issues are also addressed to the list here.
> 
>   --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 20 Dec 2019 18:48:39 -0500

Hi LAMPS folks--

On Thu 2019-12-19 18:32:28 -0500, Russ Housley wrote:

> We set a goal at IETF 106 of learning how different user agents handle
> the two approaches to header protection.  I would like to see reports
> on the mail list so that we can choose a way forward.  Please help!

Thanks for the nudge, Russ.  Turns out i've learned a lot more about
S/MIME than i ever wanted to know, in the process of creating S/MIME
test vectors for the Autocrypt-style protected headers.

I've just published
https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html

From the in-document changelog:

    Significant changes between version -01 and -02:

      - Added S/MIME test vectors in addition to PGP/MIME

      - Legacy Display parts should now be text/plain and not
        text/rfc822-headers (see
        https://github.com/autocrypt/protected-headers/issues/23)

      - Cryptographic Payload must have protected-headers parameter set
        to v1 (see
        https://github.com/autocrypt/protected-headers/issues/21)

      - Test vector sample Message-Ids have been normalized

      - Added encrypted-only (unsigned) test vectors, at the suggestion of
        Russ Housley

In addition, the test vectors are programmatically available at:

    imap://[email-masked]/inbox

(use any password, should be a read-only mailbox, with ephemeral IMAP
tags)

I'm asking folks who have clients capable of handling cryptographic
e-mail (either S/MIME or PGP/MIME or both, you don't have to handle
everything!) to submit screenshots!

It should be useful to collect screenshots following the guidance
outlined here:

    https://github.com/autocrypt/protected-headers/tree/master/screenshots

If you'd an example, take a look at the Thunderbird + Enigmail
screenshots here:

    https://github.com/autocrypt/protected-headers/tree/master/screenshots/thunderbird%2Benigmail/68.3.1%2B2.1.3

I'd appreciate any feedback about this work, particularly on:

 - the screenshot process (can we make it easier for people to generate
   screenshots from a given client)?

 - the test vectors themselves (are problems with any of them? do they
   follow the draft correctly?)

 - the text in the draft (as an implementer, is it easy to understand
   and implement)?

Regards,

        --dkg

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Dec 2019 11:29:51 -0500

A comment about Section 8.6:  Triple-Wrapping was never envisioned as a mechanism for integrity protection of mail header.  Rather, when a mail list agent is involved, the outermost signature is applied by the mail list agent to protect the mail list expansion history.  This history is needed to detect loops.

Russ

> On Dec 20, 2019, at 6:48 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Hi LAMPS folks--
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 23 Dec 2019 13:47:45 -0500

On Mon 2019-12-23 11:29:51 -0500, Russ Housley wrote:
> A comment about Section 8.6: Triple-Wrapping was never envisioned as a
> mechanism for integrity protection of mail header.  Rather, when a
> mail list agent is involved, the outermost signature is applied by the
> mail list agent to protect the mail list expansion history.  This
> history is needed to detect loops.

Thanks for the feedback, Russ.  I've actually heard people contemplating
the use of triple-wrapping for providing cryptographic authenticity and
integrity in a non-mail-list context as well, but i've hardly ever seen
it used in practice.

If you have any suggested text amendments for this section, i'd be happy
to incorporate your feedback.

   --dkg

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Dec 2019 11:55:41 -0500

> On Dec 23, 2019, at 1:47 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

I propose:

[RFC2634] defines "Triple Wrapping" as a means of providing cleartext signatures over signed and encrypted material.  A mail list agent uses triple wrapping to sign is the mail list expansion history. Others have observed that triple wrapping could be used in combination with the mechanism described in [RFC7508] to authenticate some headers for transport using S/MIME.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 24 Dec 2019 12:53:35 -0500

On Tue 2019-12-24 11:55:41 -0500, Russ Housley wrote:
> [RFC2634] defines "Triple Wrapping" as a means of providing cleartext
> signatures over signed and encrypted material.  A mail list agent uses
> triple wrapping to sign is the mail list expansion history.

I think "is" is a misplaced word here and can be dropped, right?

> Others have observed that triple wrapping could be used in combination
> with the mechanism described in [RFC7508] to authenticate some headers
> for transport using S/MIME.

Thanks!  I've pushed this change into the latest draft, modulo the
grammar fix above.

        --dkg

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Dec 2019 13:51:51 -0500

> On Dec 24, 2019, at 12:53 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Signed PGP part

Yes.  Sorry, I did this very quickly between errands today.

Russ