[lamps] advertising multiple S/MIME encryption-capable keys [was: Re: On the need for standardization of software-based interoperable private keys]

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

On Thu 2021-08-12 07:19:08 -0400, Carl Wallace wrote:
> [CW] I can have a mail server send an out of office note. Why can’t I
> have a mail server send a set of keys? Maybe for some well-known +
> appendage, as an example. I don’t know, as I am not saying I have a
> fleshed out an answer.

Four years ago, the IETF specified RFC 8162 as an experiment in
distributing S/MIME certificates via the DNS using the SMIMEA RR
type. The value of an SMIMEA record is a structure identical to TLSA
records.  The RFC explicitly references §2.1 of RFC 6698 for the wire
format, despite the fact the definitions in that section of 6698 have
multiple references to "the end entity certificate given by the server",
which doesn't make sense in the context of S/MIME.  But hopefully some
S/MIME implementers have figured out what it's supposed to mean?  8162
does some handwaving around that requirement, and also seems to treat
the DNS record as a way to *confirm* a peer's cert as received from
another MUA.  But of course it could also be used as a way to advertise
S/MIME certs for a peer in advance of contacting them.

If used for the purposes of certificate advertising, it seems critical
that the SMIMEA records all use selector 0 (full X.509 certificate),
because without the keyUsage and extendedKeyUsage markers are necessary
to know how to apply the keys.  SPKI alone *might* be sufficient to
distinguish CFRG curves (e.g. OBJECT IDENTIFIER curveEd25519 (1 3 101
112) for signing vs OBJECT IDENTIFIER curveX25519 (1 3 101 110) for
encryption) but for EC and RSA, you'd definitely need the full cert.

Each SMIMEA record distributes at most a single certificate (selector 0)
or SPKI (selector 1). To distribute a set of S/MIME certificates for a
given address via the DNS, you'd need to publish multiple SMIMEA records
for a given address.

This is necessary for the expected case of two certs per user anyway
(one for signing and one for encryption), and seems simple to extend to
multiple certs for encryption, *but* implementers would need to
understand that they should encrypt to both certificates instead of
choosing one.

Has anyone done any work with this experiment (or with other
experiments) to see how existing S/MIME implementations deal with
sending a message in the face of multiple encryption-capable keys for
the intended user?

This is an interesting line of inquiry, but unless we can show some
clear, obvious (and surprising!) already-implemented wins here, i don't
think it's a plausible replacement for standardized interoperable
private keys in the near term.

         --dkg