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

[Michael Richardson <[e-mail]>]

Thank you for taking this on!

Daniel Kahn Gillmor <[e-mail]> wrote:
    > 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.

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)

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

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<[e-mail]>, and KEY2<[e-mail]>

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

I don't know.

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

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.

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

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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [



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