Subject: [Acme] S/MIME and ACME: concerns about dual certificates (maybe pull the S/MIME draft back to ACME WG)

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Nov 2020 03:51:49 -0500

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?  if
   so, how does it specify which certificate is for signing and which is
   for encryption?

 - 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?

 - 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?

   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?

 - 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=[email-masked],
    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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Nov 2020 07:48:07 -0500

Thank you for taking this on!

    > per e-mail account it manages: one for signing, and one for encryption.

Gosh, I thought we got all of this right even for RSA years ago.
{I sure remember a debate in Memphis in a conference room with lovely doors}

The keys need to be different for reasons of escrow (both corporate and
personal: I need to leave my decryption key to my spouse).
Certainly PGP has gotten this right for decades, and I just assumed that
SMIME did too, but I honestly never really checked, because SMIME for email
is just so uncommon.  (I have checked S/MIME signatures on email though)

    > so, how does it specify which certificate is for signing and which is

I think that it gets one authorization, and then processes two orders.
That's based upon my understanding of how ACME would work for draft-friel-acme-subdomains.
You are essentially doing the same thing, but instead of foo.example.com,
and bar.example.com, you are doing it for KEY1<[email-masked]>, and KEY2<[email-masked]>

    > user indicate that they want different issuance parameters for the

I don't know.

    > the semantics of such a request?

These are definitely sensible policies and should be supported.
I am unaware of CSR attributes that express designed lifetime.
That's usually the perogative of the CA.  I agree that it needs to be tweaked.

    > of cross-protocol attack.

I'm not comfortable with this.
I need to be able to leave some (if not all) of my encryption keys to my
spouse/next-of-kin, etc.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Nov 2020 17:52:09 +0000

Hi DKG,

On 19/11/2020 08:51, Daniel Kahn Gillmor wrote:
>   - should the MUA run the ACME process twice, once per certificate?
Yes.
>     if
How does the change in 
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-13 look?
>     these hoops twice as well, responding to two different e-mail
I am open to suggestions, but for simplicity of implementation, I think 
this is acceptable.
>     user indicate that they want different issuance parameters for the
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.
>     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.
>   > signing and encryption and gives several reasons.

Best Regards,

Alexey

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Fri, 20 Nov 2020 19:05:08 +0100

The certificates can have different extended key usages, either digital
signature or encryption - and thus an email client will automatically pick
the right certificate.

However, the reason the same key shouldn't be used for both signing and
encryption, is that in textbook RSA, it exist sheninigans, where a attacker
could send an snooped encrypted message, to the receiver, but blinded with a
random number. (multiplied).

If the receiver accidentially signs this, or if the receiver has an
automated responder or holiday message, which signs messages - including the
quoted message, you can run in the trick that signing the encrypted message,
will decrypt it - but with the blinded random number, it will not be
apparent to the receiver that he just decrypted a message.

The attacker, which receives the now encrypted--blinded--siigned message,
could now de-blind it and get the received message in the clear.

BUT!!! This is ONLY for textbook RSA - where you sign the message raw in
directly.
In current SMIME protocol, you NEVER do that!!!!

Normally, you sign a HASH of  the message, meaning theres NO danger in
having the same key for encryption and signing UNLESS an attacker could
compose a message M such as hash(M) == E, where E is an encrypted message
that the attacker snooped (either unblinded or blinded).

But that would require some serious bruteforcing. Thus not a viable attack.

Thus no danger in using the same RSA key for both signing and encryption.

-----Ursprungligt meddelande-----
Från: [email-masked] <[email-masked]> För Alexey Melnikov
Skickat: den 20 november 2020 18:53
Till: Daniel Kahn Gillmor <[email-masked]>; [email-masked]
Ämne: Re: [Acme] S/MIME and ACME: concerns about dual certificates (maybe
pull the S/MIME draft back to AC

Hi DKG,

On 19/11/2020 08:51, Daniel Kahn Gillmor wrote:
> probably shouldn't expect the same cryptographic key material to be 
> used for both signing and encryption. [0]
>
> digital signatures or key agreement.  And a public key of type "RSA" 
> can be used for digital signatures or key encapsulation.  ("ECDSA" and 
Yes.
How does the change in
>     these hoops twice as well, responding to two different e-mail
I am open to suggestions, but for simplicity of implementation, I think this
is acceptable.
>     user indicate that they want different issuance parameters for the
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.
> [0] in Message-ID
CALhKWgj=W-Yo_t=[email-masked],

Best Regards,

Alexey

_______________________________________________
Acme mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/acme

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Nov 2020 19:14:12 -0800

Hi Sebastian,

> random number. (multiplied).

While this may be *a* reason, I don't think it's the only reason.  Another
reason that comes up with some regularity is that isolating a given key to
a single usage greatly simplifies formal analysis of the containing
protocol's security properties, as cross-protocol and cross-algorithm
attacks are definitionally out of scope.

Thanks,

Ben