By my reading of the Microsoft requirements using separate intermediates is insufficient: they must be root certificates.
I'm not familiar with their reasoning behind that but I can imagine cases where that could be a good idea (a consequence of Heartbleed perhaps). Whatever the case may be, if you're going to have the rule then some enforcement mechanism is necessary hence the need for a code-signing-only cert in the trust store. I also would like to see an official statement regarding when the current QuoVadis certs in the trust store may be removed. We should require a time certain for when the "replaced certs" should be considered obsolete and thus revoked via removal. Original Message From: Stephen Davidson Sent: Monday, May 12, 2014 8:32 AM To: Chema López; Kathleen Wilson Cc: [email protected] Subject: RE: QuoVadis Request to Include Renewed Roots QuoVadis is compliant with the Microsoft requirements, and has implemented separate SHA256 intermediate CAs for the issuance of code signing certificates. (More precisely stated, QuoVadis SSL certificates are not issued from the same intermediate CAs as time stamping and code signing certificates). Kind regards, Stephen Davidson QuoVadis -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisglobal....@lists.mozilla.org] On Behalf Of Chema López Sent: Friday, May 09, 2014 4:06 AM To: Kathleen Wilson Cc: [email protected] Subject: Re: QuoVadis Request to Include Renewed Roots " turn on all three trust bits for the RCA1 and RCA3 root certs, and turn on the websites and code signing trust bits for the RCA2 root cert." Are they asking for the same bits/CA that they already had with the precious CAs? Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx> ? " *Separation of SSL and Code Signing Key Uses* Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates. " BR [email protected] +34 666 429 224 (Spain) gplus.to/chemalogo @chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo Skype: chemalogo On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <[email protected]> wrote: > On 4/24/14, 1:16 PM, Kathleen Wilson wrote: > >> On 4/7/14, 5:42 PM, Kathleen Wilson wrote: >> >>> QuoVadis has applied to include the “QuoVadis Root CA 1 G3”, >>> “QuoVadis Root CA 2 G3”, and “QuoVadis Root CA 3 G3” root >>> certificates, turn on all three trust bits for the RCA1 and RCA3 >>> root certs, and turn on the websites and code signing trust bits for >>> the RCA2 root cert. The request is to also enable EV treatment for >>> the “QuoVadis Root CA 2 G3” root certificate. These SHA256 root >>> certs will eventually replace the corresponding QuoVadis root >>> certificates that were included in NSS in bugs #238381 and #365281. >>> >>> >> Does anyone have any questions or comments about this request from >> QuoVadis? >> >> Kathleen >> >> >> > > Should I take the lack of input on this request to mean that everyone > is OK with it? > Or does it just mean that folks need more time to consider this request? > > Thanks, > > Kathleen > > _______________________________________________ > 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 _______________________________________________ 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
