On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy <[email protected]> wrote: > Therefore the newly re-issued > certificate *will* end up with it's private key compromised *again*, > no matter how well it may be obfuscated in the application, it is > still against the very principle.
I'm pretty confused by this as well. First off, while people have proposed multiple solutions to this problem, they are not trivially implementable, nor are they widespread. I think if you shook the tree with some automation, you'd find on the order of 50 or more publicly trustable private keys embedded in firmware pretty quickly. So at what point does the CA become culpable to misissuance in a case like this? Is it okay that we let them turn a blind eye to issuing or reissuing certificates where they have a strong reason to believe the private key will be published in firmware? Clearly we wouldn't require them to vet every use of every certificate they issue, but if they revoke a certificate for being used in this fashion, it seems reasonable for them to ask the customer to at least give them an explanation of how they've changed things such that a newly issue certificate for the same domain will not be used in the exact same way. Is it reasonable for us to ask a CA to do this (that is, to ask their customer)? Is it reasonable to require it? -tom _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
