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

[Sebastian Nielsen <[e-mail]>]

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: [e-mail] <[e-mail]> För Alexey Melnikov
Skickat: den 20 november 2020 18:53
Till: Daniel Kahn Gillmor <[e-mail]>; [e-mail]
Ä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:
> 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=[e-mail],
>      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
[e-mail]
https://www.ietf.org/mailman/listinfo/acme