On 14/05/14 13:54, [email protected] wrote:
By my reading of the Microsoft requirements using separate intermediates is
insufficient: they must be root certificates.
Peter, my reading of the Microsoft requirements [1] is that using
separate intermediates is sufficient (although note the EKU requirement
for non-legacy intermediates).
"INTERMEDIATE / ISSUING CA CERTIFICATES
...
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.
Rollover root certificates will not be accepted that combine server
authentication with code signing uses unless the uses are separated by
application of EKUs at the intermediate CA certificate level that are
reflected in the whole certificate chain."
[1]
http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx
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
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
