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
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
