Right - about the only thing the guidelines can do is require that CAs include it as a contractual representation in their subscriber agreement, which is what I was thinking of doing. There isn't a way to monitor whether key was used for multiple purposes.
Fun note - one version of the draft required the key be kept on a hardware token and that the CA verify it as on a hardware token before issuing. That would have effectively prevented anyone from using the same key for both SSL and code signing. Jeremy -----Original Message----- From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, August 29, 2014 12:44 PM To: Jeremy Rowley Cc: '[email protected]'; [email protected] Subject: RE: Code Signing Draft 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. > > Jeremy > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, August 29, 2014 7:39 AM > To: Jeremy Rowley; [email protected] > Subject: Re: Code Signing Draft > > Thanks for sharing this Jeremy. I'm still reading through it myself > but one thing that jumps out at me is the implicit(?) allowing for > the same key to be used for SSL and code signing. > > From a security standpoint ‎that's a horrible idea. I'll elaborate > if desired, but I first wanted to find out what the current thinking > is among CABF participants regarding this practice. Has there been any > discussion? > I don't know that Mozilla has an opinion on it? > > Thanks. >  Original Message  > From: Jeremy Rowley > Sent: Monday, August 25, 2014 5:46 PM‎ > > The CAB Forum released a proposed new baseline requirements around > code signing today that might be of interest to participants here. > You can see the document here: > > > https://cabforum.org/2014/08/25/cabrowser-forum-releases-code-signing- > baseline-requirements-public-comment-draft/ > > Public comments and feedback are welcome. > > Jeremy > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > 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
