Loosen the interpretation of escrow from a box surrounded by KRAs, KROs, and access controls with a rolling LTSK and escrow could describe what many white glove and CDN tier hosting operations do. The CDN has written consent, but the end customer never touches the TLS cert.
> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of Jeremy > Rowley via dev-security-policy > Sent: Monday, December 11, 2017 11:18 AM > To: Gervase Markham <[email protected]>; mozilla-dev-security- > [email protected] > Subject: RE: CA generated keys > > I think key escrow services are pretty rare related to TLS certs. However, > there's lots of CAs and services that escrow signing keys for s/MIME certs. > Although, I'm not sure how companies can claim non-repudiation if they've > escrowed the signing key, a lot of enterprises use dual-use keys and want at > least the encryption portion in case an employee leaves. > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy- > [email protected] > .org] On Behalf Of Gervase Markham via dev-security-policy > Sent: Monday, December 11, 2017 12:48 AM > To: [email protected] > Subject: Re: CA generated keys > > Hi Tim, > > The more I think about it, the more I see this is actually a interesting > question :-) > > I suspect the first thing Mozilla allowing this would do would be to make it > much more common. (Let's assume there are no other policy > barriers.) I suspect there are several simpler workflows for certificate > issuance and installation that this could enable, and CAs would be keen to > make their customers lives easier and reduce support costs. > > On 09/12/17 18:20, Tim Hollebeek wrote: > > First, third parties who are *not* CAs can run key generation and > > escrow services, and then the third party service can apply for a > > certificate for the key, and deliver the certificate and the key to a > customer. > > That is true. Do you know how common this is in SSL/TLS? > > > I'm not > > sure how this could be prevented. So if this actually did end up > > being a Mozilla policy, the practical effect would be that SSL keys > > can be generated by third parties and escrowed, *UNLESS* that party is > trusted by Mozilla. > > Another way of putting it it: "unless that party were the party the customer > is already dealing with and trusts". IoW, there's a much lower barrier for > the customer in getting the CA to do it (trust and > convenience) compared to someone else. So removing this ban would > probably > make it much more common, as noted above. If it's something we want to > discourage even if we can't prevent it, the current ban makes sense. > > > Second, although I strongly believe that in general, as a best > > practice, keys should be generated by the device/entity it belongs to > > whenever possible, we've seen increasing evidence that key generation > > is difficult and many devices cannot do it securely. I doubt that > > forcing the owner of the device to generate a key on a commodity PC is > > any better (it's probably worse). > > That's also a really interesting question. We've had dedicated device key > generation failures, but we've also had commodity PC key generation > failures > (Debian weak keys, right?). Does that mean it's a wash? What do the risk > profiles look like here? One CA uses a MegaRNG2000 to generate hundreds > of > thousands of certs.. and then a flaw is found in it. Oops. > Better or worse than a hundred thousand people independently using a > broken > OpenSSL shipped by their Linux vendor? > > > With an increasing number of small devices running web servers, keys > > generated by audited, trusted third parties under whatever rules > > Mozilla chooses to enforce about secure key delivery may actually in > > many circumstances be superior than what would happen if the practice > is > banned. > > Is there a way to limit the use of this to those circumstances? > > Gerv > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://clicktime.symantec.com/a/1/7IiyfqIYVYHVo4yJwZ1gujE6ewgPbVhd > eNR8nQYMk > tE=?d=-Wn_VctZunngdEk_ioG0- > YmJpPH0bSY7avkVy2G5jkppW7WbRwmFtauXnqI4GVKzIanQD2 > ZA6NInKdI3JGkcf9ryTq6n-s4c4pg5s3wE4vkp4yda03M7jQfN5_Ag8- > 70lEsjQb45m2On8sIoG_ > dT07uGS0eLuIUFBs5Ejb7aU7SMDef- > aiw2SMmHSy34HrobgXESUV5rtJhwEAyCZvSWTdlhTt2mUM > XVuNXdmFtAYun19fEnhCuxZTm44Inip_9XUfKb73PIvmELdwusC79xu_Wg > oRGUvPUEFfEYMZQJLz > r1wo3PfgH3YtIhu55H4aSMlU8UOVe5JjW6WYG0wIKfKfGKta_cm5JB9HGO > NmcRvB8nw-A2xd5kr6 > jSh2Pb6kH9EJMOhxcnioBU4Gm_IH7he9MnhbhTu2BATkoSNvbqOoNB&u > =https%3A%2F%2Flists > .mozilla.org%2Flistinfo%2Fdev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
