Re: [art] Artart last call review of draft-ietf-lamps-e2e-mail-guidance-14

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

Hi Steffen--

On Thu 2024-02-22 00:43:36 +0100, Steffen Nurpmeso wrote:
>   user SHOULD have both a signing-capable certificate and an
>   encryption-capable certificate (and the corresponding secret
>   keys)
>
> is something that causes a headache for me.

It may be a headache, but it sounds like that's due to your tooling for
X.509 and secret key management, which has poor usability.  One of the
critical observations in this draft is that the tooling needs better
usability if we expect normal users to adopt.

That said, no normal e-mail user should ever come near the OpenSSL
interface, either the cli or the C interface.  The MUA needs to handle
these operations for the user in a reasonable fashion.

> Anyhow, there is no distinction in between a "signing capable" and
> an "encryption capable" key.  

The keyUsage and extendedKeyUsage flags in X.509 certificates clearly
distinguish between signing and encryption use cases.  Using the same
underlying cryptographic object for both protocols without a proof that
the protocols cannot interact runs the risk of cross-protocol
vulnerability.  The cryptographic objects in question are cheap.  There
is no shortage there, and there should be no harm in producing two of
them rather than one of them.

If the process of getting a corresponding X.509 from an authority is too
cumbersome to handle two at a time, that is a flaw in the process with
the CA.  No reasonable CA should want their subscriber to rely on the
same cryptographic object in two distinct cryptographic schemes; that
simply puts the certificate that they have issued at risk of abuse.

> Ie, i do not understand
>
>   8.2.3.1.  Shipping Certificates in S/MIME Messages
>
> either, because i would not even know how to avoid including the
> certificate that any receiver can then use to send encrypted email
> back to me.

The guidance in the draft is intended for MUA implementers, not for end
users.  End users are not expected to select which certificate to
include.  If the MUA implementer cannot control which certificates are
included in the CMS object due to limitatins of their chosen CMS
toolkit, that is a flaw in the CMS toolkit.

> Btw i have sympathy for full key management and master keys and
> dedicated subkeys.  However a nice TLS+DNSSEC secure DNS TXT entry
> with an ED25519 or so certificate (ie: *impossible* with OpenSSL),
> with an identifier (or, in DKIM terms: selector) i can bake into
> the certificate in order to be able to rotate, i find even better.
> Ie, if compromised, create a new one.  No CRLS, no OCSP, simply
> a X509-baked-in selector and a DNS record.

It sounds to me like you're asking for some sort of DANE authentication
record.  The most straightforward approach for that would be SMIMEA (RFC
8162), which is referenced in the draft.

> Btw i have yet to see ACME for S/MIME in real life.  Does this
> exist?

Are you talking about RFC 8823?  That certainly exists, and there are
software packages that implement it (e.g. https://acme.castle.cloud/).
Or, are you asking whether any major CA offers it?  I haven't done a
full survey, so i'm not sure.  Maybe some CA operator wants to weigh in
on this?  Certainly an enterprise running their own CA could offer it in
a pretty straightforward way.

> I was thrilled by your efforts to bake this into a standard, but now
> the IETF really kills business models, does it.

???

> That is: i see no dedicated subkeys or anything.

An X.509 certificate does not have "subkeys".  You need a distinct X.509
certificate for each cryptographic public key operation: one for
verifying signatures, and another for encrypting data.  They should be
over different underlying public keys, but have the same identity
information.

Regards,

        --dkg