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-
> bounces+steve.medin=digicert....@lists.mozilla.org] On Behalf Of Jeremy
> Rowley via dev-security-policy
> Sent: Monday, December 11, 2017 11:18 AM
> To: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-
> pol...@lists.mozilla.org
> 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-
> bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Gervase Markham via dev-security-policy
> Sent: Monday, December 11, 2017 12:48 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> 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
> dev-security-policy@lists.mozilla.org
> 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to