Agreed. Enforcing a rule like this would be limited, so here's what I'm hoping to see:
1) Strong, clear, unambiguous wording in the specs so that we can take away the "I didn't know" argument. Nobody should ever think it's okay to use the same key in multiple ways. 2) Policies and checks put in place within each CA so that at least within their own purview the same key is only ever used once. This would take away the "well they let me do it" argument. Asking CA's to coordinate with other CA's is probably not a good idea. 3) Auditing procedures that specifically look for these policies and checks. Let's at least get a CA's public attestation that multiple-use keys are not allowed. Maybe some of that is already in place. Do CA's already have checks in place to make sure that a single, unique key is only ever used by one end entity, for those certs that that CA has issued? The idea is to try to give people a clue of how to navigate the code signing minefield even if we can't rigidly enforce certain aspects. Thanks. Original Message From: Ryan Sleevi Sent: Friday, August 29, 2014 1:44 PM On Fri, August 29, 2014 8:04 am, Jeremy Rowley wrote: > Good point. I don't think we spell it out, but I don't think anyone wants > people using the same keys for both SSL and code signing. CAs are > prohibited from using the same intermediate for both SSL and code signing, > but we should also add something that requires the Subscriber to use > separate sets of keys. > > > Except it's a requirement without teeth. That is, a subscriber could go to CA A with Key 1 and get an SSL certificate, and CA B with Key 1 and get a code-signing certificate. Is CA B expected to monitor public Certificate Transparency logs looking for examples where the private key has been used in an SSL certificate? I agree that the spec doesn't say anything in the current draft, because key hygiene is one of those things you can't enforce (although the CS draft does attempt to do so, at Microsoft's behest, in requiring a HSM - which opens itself open to a whole new licensing landmine field of trying to determine precisely how it's in an HSM short of mailing the customer an HSM) When I read requires, I think MUST, and if you're suggesting that it's not the case, but merely that the draft gently recommends key hygeine much like CAs gently recommend revocation checking, sure. I just think you'll have a hard time embodying that at MUST level. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
