> The more I think about it, the more I see this is actually a interesting question :-)
I had the same feeling. It seems like an easy question to answer until you start thinking about it. > 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. This may or may not be true. I think it probably isn't. The standard method via a CSR is actually simpler, so I think that will continue to be the predominant way of doing things. I think it's more likely to remain limited to large enterprise customers with unique requirements, IoT use cases, and so on. > > 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 know it happens. I can try to find out how common it is, and what the use cases are. > > 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? I'd argue that the second is worse, since the large number of independent people are going to have a much harder time becoming aware of the issue, applying the appropriate fixes, and performing whatever remediation is necessary. The general rule is that you're able to do more rigorous things at scale than you can when you're generating a key or two a year. > > 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? I don't know but it's worth talking about. I think the discussion should be "when should this be allowed, and how can it be done securely?" -Tim
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
