Subject: Re: [lamps] Call for adoption for draft-dkg-lamps-samples

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 03 May 2021 19:03:18 -0400

On Fri 2021-04-30 15:14:04 -0400, Russ Housley wrote:
> I heard support from several people, and I did not hear objections from anyone.  Please post an draft-ietf-lamps version of the document.

Thanks, I did so, making no changes from draft-dkg-lamps-samples-05
other than moving myself to an editor role.  datatracker says It's
awaiting confirmation from [email-masked].

I think the document is functionally complete if the only thing we care
about is RSA certificates for S/MIME.

I think we should add another set of certificates using the modern
curves (ed25519 and x25519 in particular).

I have three asks for other members of LAMPS:

 - Do you agree that this document should have an additional set of
   certificates using curve25519?

 - Please try to import these certificates into your preferred S/MIME
   client, and use them to generate or handle
   cryptographically-protected e-mail.  Whether they work or not, it
   would be great to hear the results on-list.

 - What else do you think this document needs before it is ready for
   publication?

The source for the document continues to be maintained via git at:
https://gitlab.com/dkg/lamps-samples

Regards,

        --dkg

---

From: Henning Krause <[email-masked]>
Date: Tue, 4 May 2021 15:36:41 +0000

>    certificates using curve25519?

Yes please.

>  - What else do you think this document needs before it is ready for

I think it would be great not only to have certificates and keys but also sample emails for rsa/ecc encryption and signing. I think this would help implementors tremendously and improve interoperability.

Kind regards,
Henning

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 04 May 2021 12:29:52 -0400

>>    certificates using curve25519?

thanks for following up.  Unless I hear any objections from the list,
i'll produce a -01 draft that includes the 25519 key material.

Did you get a chance to try using the existing certificates with any
S/MIME-enabled MUA?

> I think it would be great not only to have certificates and keys but also sample emails for rsa/ecc encryption and signing. I think this would help implementors tremendously and improve interoperab…

I'm separately working on sample e-mail messages using the RSA
certificates in draft-ietf-header-protection, which i'll follow up about
on-list soon.

It turns out sample e-mail messages can make a draft overwhelmingly
large, since there are *many* different variations that could affect
their validity and interpretation.  I'm personally inclined to avoid
those combinatorics for this particular draft, and have this draft just
focus on certificates for use in secure e-mail.  I think it makes the
draft more tractable and more finishable :) If other folks in LAMPS (or
the chairs) have an opinion on this suggestion, i'd be happy to hear it.

     --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 May 2021 16:32:32 +0000

I think it's reasonable to leave sample messages to another document/author.  I think putting the rationale for not including it into the intro/abstract would help avoid having to re-answer the question ad nauseum.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 May 2021 15:29:52 -0400

On Tue 2021-05-04 16:32:32 +0000, Salz, Rich wrote:
> I think it's reasonable to leave sample messages to another
> document/author.  I think putting the rationale for not including it
> into the intro/abstract would help avoid having to re-answer the
> question ad nauseum.

The "prior work" section, when talking about how it differs from RFC
4134, already says:

    This document intends to focus specifically on identity and key
    material, as a starting point for other documents that can develop
    examples or test cases from them.

I'm moving that sentence to the end of the Introduction, where i've
rewritten it as:

    This document focuses narrowly on functional, well-formed identity
    and key material.  It is a starting point that other documents can
    use to develop sample signed or encrypted messages, test vectors, or
    other artifacts for improved interoperability.

This change will be in -01.  Feel free to suggest additional
improvements!

Regards,

        --dkg