Within 24 hours? Once the download completes? It doesn’t seem significantly harder than the other questions we grapple with. I’m sure there are plenty of reasonable solutions.
If you want to deliver the private key first, before issuance, that’d be fine too. It just means two downloads instead of one and I tend to prefer avoiding unnecessary complexity. -Tim From: Wayne Thayer [mailto:[email protected]] Sent: Wednesday, December 13, 2017 5:40 PM To: Tim Hollebeek <[email protected]> Cc: [email protected] Subject: Re: CA generated keys On Wed, Dec 13, 2017 at 4:06 PM, Tim Hollebeek via dev-security-policy <[email protected] <mailto:[email protected]> > wrote: Wayne, For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate at the same time should be allowed, and I have no problem with a requirement to delete the key after delivery. How would you define a requirement to discard the private key "after delivery"? This seems like a very slippery slope. I also think server side generation along the lines of RFC 7030 (EST) section 4.4 should be allowed. I realize RFC 7030 is about client certificates, but in a world with lots of tiny communicating devices that interface with people via web browsers, there are lots of highly resource constrained devices with poor access to randomness out there running web servers. And I think we are heading quickly towards that world. Tightening up the requirements to allow specific, approved mechanisms is fine. We don't want people doing random things that might not be secure. Why is it unreasonable in this IoT scenario to require the private key to be delivered prior to issuance?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
