Hi DKG,
On 19/11/2020 08:51, Daniel Kahn Gillmor wrote:
Over in LAMPS, we've been discussing how a given S/MIME certificate
probably shouldn't expect the same cryptographic key material to be used
for both signing and encryption. [0]
In particular, public keys of type "EC Public Key" can be used for
digital signatures or key agreement. And a public key of type "RSA" can
be used for digital signatures or key encapsulation. ("ECDSA" and
"ECDH" key types can only be used for signing or encryption,
respectively, so maybe they aren't affected by this)
So, an S/MIME MUA probably wants to control two distinct certificates
per e-mail account it manages: one for signing, and one for encryption.
It's not clear to me how a MUA is expected to deal with this.
- should the MUA run the ACME process twice, once per certificate?
Yes.
if
so, how does it specify which certificate is for signing and which is
for encryption?
How does the change in
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-13 look?
- If so, are we expecting the users of non-ACME MUAs to jump through
these hoops twice as well, responding to two different e-mail
prompts?
I am open to suggestions, but for simplicity of implementation, I think
this is acceptable.
- If not, how does the client communicate both certificate requests to
the server at the same time? If there's a way to do that, can the
user indicate that they want different issuance parameters for the
different key usages?
If you really want different parameters for different key usages, I
think you are basically reenforicing my comment above that this would
require 2 separate requests.
For example, maybe a sensible MUA with an automated workflow might
want to rotate their signing certificate every month (it's cheap and
easy to get a new one, and a validity period of a month on each
certificate limits the window of any particular compromise). But it
might want to request a new encryption certificate every 6 months
(and it might want the validity window for the encryption certificate
to last for a year, so that any acquaintance that receives mail from
the user will be able to reply encrypted up to a year later without
having to rediscover the user's certificate). Can/should the MUA
just indicate those preferences in the generated CSRs? if it's
embedded in the CSR, do we have rules for how a CA ought to verify
the semantics of such a request?
I think in the base ACME this is already indicated in the "notAfter"
field in the newOrder request. This is not conveyed in the CSR itself.
- alternately, are we comfortable with just saying that the ACME S/MIME
work doesn't actually support this dual-certificate model, and just
have the same key used for both signing and encryption? that seems
to go against NIST guidance at least, and risks introducing some kind
of cross-protocol attack.
sorry to bring this up when the draft is already so far into the
editorial review process!
--dkg
[0] in Message-ID
CALhKWgj=W-Yo_t=k0fcl+vsfa3ace2lfygetithjqpw-upf...@mail.gmail.com,
Jonathan Hammell writes:
> Section 5.2 of NIST SP 800-57-1 rev 5 forbids using a key for both
> signing and encryption and gives several reasons.
Best Regards,
Alexey
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
