Re: [SPAM] Re: EKUs covered in the Mozilla CA Program
On 13/05/14 14:48, Peter Bowen wrote: I would add the old Netscape Step-Up/SGC (2.16.840.1.113730.4.1) and any EKU (2.5.29.37.0) to the list as well. The point of the bug I reference is that we'd like to stop caring about these (in code), because allowing anyEKU means that we include in scope (and permit for SSL) a bunch of certs we don't really want to include in scope and really shouldn't be permitted for SSL as they weren't intended for SSL. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: QuoVadis Request to Include Renewed Roots
On 14/05/14 13:54, fhw...@gmail.com 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: mozilla-dev-security-pol...@lists.mozilla.org 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: mozilla-dev-security-pol...@lists.mozilla.org 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 requirementshttp://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 m...@chemalogo.com +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 kwil...@mozilla.com 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
Re: CA Communication - May 12, 2014
On Monday, 12 May 2014 13:45:16 UTC-6, Jeremy Rowley wrote: +1. This is especially true in the federal space where some intermediates are stored offline most of the time. Per Section 4.9.7 of the FBCA CP, these CAs use a 31-day interval for status information. Bringing the CA online to generate responses every 10 days will actually make those CAs less secure. Perhaps I'm dense and missing something or perhaps this isn't the right place to be asking. Why would this necessitate bringing the CA online when responses can be signed by an Authorized Responder (i.e. cert with EKU id-kp-OCSPSigning)? FWIW, Rob's concerns regarding the change process are certainly reasonable. PK ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CA Communication - May 12, 2014
Not everyone signs with responders since they add bulk and complexity into the system. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Patrick Kobly Sent: Wednesday, May 14, 2014 11:07 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Communication - May 12, 2014 On Monday, 12 May 2014 13:45:16 UTC-6, Jeremy Rowley wrote: +1. This is especially true in the federal space where some intermediates are stored offline most of the time. Per Section 4.9.7 of the FBCA CP, these CAs use a 31-day interval for status information. Bringing the CA online to generate responses every 10 days will actually make those CAs less secure. Perhaps I'm dense and missing something or perhaps this isn't the right place to be asking. Why would this necessitate bringing the CA online when responses can be signed by an Authorized Responder (i.e. cert with EKU id-kp-OCSPSigning)? FWIW, Rob's concerns regarding the change process are certainly reasonable. PK ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication - May 12, 2014
On Wed, May 14, 2014 at 10:06 AM, Patrick Kobly patr...@kobly.com wrote: Perhaps I'm dense and missing something or perhaps this isn't the right place to be asking. Why would this necessitate bringing the CA online when responses can be signed by an Authorized Responder (i.e. cert with EKU id-kp-OCSPSigning)? Right. Bulk preproduction of direct-signed OCSP responses is another way of handling it. Nobody wants CA certificates to be online more than otherwise necessary just to support shorter validity periods for OCSP responses. FWIW, Rob's concerns regarding the change process are certainly reasonable. We did not intentionally want to short-circuit any process. I implemented the restriction to 10 days due to a misunderstanding of the baseline requirements, and then we decided my misunderstanding is better than what the BRs would say, so we considered leaving my misunderstanding in the code while we concurrently worked to improve the BRs to match my misunderstanding. Ultimately, we decided to revert to the less-reasonable but more compatible behavior. It is OK (good even) for us to add additional requirements that go beyond the baseline EV requirements and not everything has to be approved through CAB Forum. We do it all the time (otherwise our CA program documentation would consist solely of See the Baseline Requirements and EV Requirements). Google is doing the same with their proposed CT requirements for EV. In this case, though, it was just an accident. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Question about disclosing subCA certs
All, In response to the CA Communication, I have received the following question. Question: Please clarify Action #5: Do you expect public disclosure of all subordinate CA certificates, or just those issued to third parties? Answer: http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ 8. ... The term subordinate CA below refers to any organization or legal entity that is in possession or control of a certificate that is capable of being used to issue new certificates. ... 9. We encourage CAs to technically constrain all subordinate CA certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. ... 10. We recognize that technically constraining subordinate CA certificates as described above may not be practical in some cases. All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program MUST be audited in accordance with Mozilla’s CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla’s CA Certificate Program. ... So, my interpretation of the policy is that it applies to all, both internally-operated and externally-operated, sub CA certs. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Question about disclosing subCA certs
She's clarified in the discussion thread that it is all SubCAs chained to the a CAs root certificate that must be disclosed, regardless of who controls the private key. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kurt Roeckx Sent: Wednesday, May 14, 2014 2:37 PM To: Kathleen Wilson Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Question about disclosing subCA certs On Wed, May 14, 2014 at 01:08:12PM -0700, Kathleen Wilson wrote: All, In response to the CA Communication, I have received the following question. Question: Please clarify Action #5: Do you expect public disclosure of all subordinate CA certificates, or just those issued to third parties? Answer: http://www.mozilla.org/en-US/about/governance/policies/security-group/ certs/policy/inclusion/ 8. ... The term subordinate CA below refers to any organization or legal entity that is in possession or control of a certificate that is capable of being used to issue new certificates. ... 9. We encourage CAs to technically constrain all subordinate CA certificates. For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. ... 10. We recognize that technically constraining subordinate CA certificates as described above may not be practical in some cases. All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla's CA Certificate Program MUST be audited in accordance with Mozilla's CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla's CA Certificate Program. ... So, my interpretation of the policy is that it applies to all, both internally-operated and externally-operated, sub CA certs. I think what you're saying is all those CA certs for which they control the private key. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
On Wed, May 14, 2014 at 02:40:12PM -0600, Jeremy Rowley wrote: She's clarified in the discussion thread that it is all SubCAs chained to the a CAs root certificate that must be disclosed, regardless of who controls the private key. Right, reading the text again it looks like any certificate that has a CA:TRUE and chains to a certificates in the root store should be disclosed. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
