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

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

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=[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.