Thank you for taking this on! Daniel Kahn Gillmor <[email protected]> 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<[email protected]>, and
KEY2<[email protected]>
> - 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
