Re: Allow Redaction of issues detailed in BR Audit statements?
On 2014-08-27 18:15, Kathleen Wilson wrote: Based on the discussion so far, I think the answer is that the CAs need to work with their auditors to create a public-facing audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with. I agree with this too. I think it's important to know that there are problems and that they are being worked on. I've been checking certificates and filing bugs in Mozilla's bugzilla, so all those things are currently also public. But I try to only put there what I think is needed, and if the CA wants more detailed information I'm happy to send it to them directly instead of via bugzilla. The wiki you pointed to about the baseline requirements says that the first audit might have a list of things it's not in compliance with and that we expect the next one confirm they have been fixed. Do such reports explicitly confirm that they have been fixed? It seems to give the impression that next audit report is not supposed to give a (public) list of requirements it's not in compliance with. But since the requirements change over time, for instance 1024/2048 bit, SHA1/SHA256, procedures and used software might change over time, and so on, I expect that a next audit might find new issues that were previously not found. So I expect every report to give such a list, or explicitly say that no problems where found. And that would go for all the audit reports. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/28/2014 9:42 AM, Man Ho (Certizen) wrote: I think some CAs don't even want to claim they are CAB/Forum BR compliant, but just want to be included in all root certificate programs. What I mean is that some CAs don't want to claim they are CAB/Forum BR compliant, but committed to conform to it in order to be included in all root certificate programs. They just don't bother to publicly claim that they have any connection with CAB/Forum. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On Thu, Aug 28, 2014 at 02:40:08PM +0800, Man Ho (Certizen) wrote: On 8/28/2014 9:42 AM, Man Ho (Certizen) wrote: I think some CAs don't even want to claim they are CAB/Forum BR compliant, but just want to be included in all root certificate programs. What I mean is that some CAs don't want to claim they are CAB/Forum BR compliant, but committed to conform to it in order to be included in all root certificate programs. They just don't bother to publicly claim that they have any connection with CAB/Forum. I don't believe a CA has to claim any connection with the CA/B Forum. They merely have to assert (and have that assertion supported by an audit finding) that they're compliant with either the WebTrust criteria (which are based off the CA/B Forum requirements), or one of a couple of ETSI standards (which, I believe, aren't). - Matt -- I invented the term object-oriented, and I can tell you I did not have C++ in mind. -- Alan Kay ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
Please see page 7 of ETSI 102 042: ETSI - Electronic Signature and Infrastructure (ESI) includes in the present document provisions consistent with the requirements for issuing Extended Validation Certificates (EVC), as specified in the above mentioned CAB Forum EVC Guidelines (EVCG [16]) as well as Publicly trusted TLS/SSL certificates, as specified in the mentioned CAB Forum PTC guidelines (BRG [19]) As a consequence, EVC and PTC issued by CAs operating in compliance with the EVC and PTC related provisions as indicated in the present document can be assessed as meeting the requirements specified by the CAB Forum in their EVCG [16] and BRG [19] plus recognised good practice for CA's issuing certificates. Thanks, M.D. Matt Palmer mpal...@hezmatt.org wrote: On Thu, Aug 28, 2014 at 02:40:08PM +0800, Man Ho (Certizen) wrote: On 8/28/2014 9:42 AM, Man Ho (Certizen) wrote: I think some CAs don't even want to claim they are CAB/Forum BR compliant, but just want to be included in all root certificate programs. What I mean is that some CAs don't want to claim they are CAB/Forum BR compliant, but committed to conform to it in order to be included in all root certificate programs. They just don't bother to publicly claim that they have any connection with CAB/Forum. I don't believe a CA has to claim any connection with the CA/B Forum. They merely have to assert (and have that assertion supported by an audit finding) that they're compliant with either the WebTrust criteria (which are based off the CA/B Forum requirements), or one of a couple of ETSI standards (which, I believe, aren't). - Matt -- I invented the term object-oriented, and I can tell you I did not have C++ in mind. -- Alan Kay ___ 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: Allow Redaction of issues detailed in BR Audit statements?
On 8/27/14, 9:15 AM, Kathleen Wilson wrote: Based on the discussion so far, I think the answer is that the CAs need to work with their auditors to create a public-facing audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with. I added text about this to https://wiki.mozilla.org/CA:BaselineRequirements#BR_Audits == As with the other audits required of CAs in Mozilla's Program, the BR Audit statement must be a public-facing document. Section 6 of Mozilla's CA Certificate Inclusion Policy says: We require that all CAs whose certificates are distributed with our software products: ... publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement); ... provide *public attestation* of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA’s internal operations. As previously stated, it is acceptable for an audit statement to list the BRs that the CA is not yet fully in compliance with. However, this may result in an auditor providing information in the BR audit statement that the CA considers sensitive (e.g. subordinate CA specifics, RA information, customer information, or security sensitive information). Each CA must work with their auditor to create a public-facing BR audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with. Here are some examples of the level of information that should be included in the BR audit statement in regards to BRs that the CA is not yet fully conforming to. BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support legacy customer apps) BR 13.2.6 - OCSP giving status “good” for unknown serial numbers. BR 16.5 - multi-factor authentication for all accounts capable of directly causing certificate issuance BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed one year BR 17.8 – audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken BR 11.2 – re-verifying identity for cert renewal requests == I'll appreciate feedback on this. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
David E. Ross a écrit : With a redacted audit report, the presumption should be that hidden negative information exists that would disqualify the certification authority from having its root certificate in the NSS database if such information were disclosed. any redaction would imply the existence of hidden negative information that would necessitate removal of the affected root certificate from the NSS database if such information were disclosed. I think there's miscomprehension here. I understand that the CAs are OK with people knowing that some unknown serial numbers would give status “good”, but not with them knowing the exact values of the concerned serial numbers, which could be used to attack the system. Likewise with the 1024-bit certs with validity beyond 2013, it's useful to know they existed but a different matter to get the name of the client (in that case, Mozilla could published the number of certificates concerned). Or letting people know which accounts exactly didn't have multi-factor authentication for certificate issuance. I understand the redaction not to be about which kind of problem there was, but about letting specific nominative information be published about each problem. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/27/2014 7:11 AM, Jean-Marc Desperrier wrote: David E. Ross a écrit : With a redacted audit report, the presumption should be that hidden negative information exists that would disqualify the certification authority from having its root certificate in the NSS database if such information were disclosed. any redaction would imply the existence of hidden negative information that would necessitate removal of the affected root certificate from the NSS database if such information were disclosed. I think there's miscomprehension here. I understand that the CAs are OK with people knowing that some unknown serial numbers would give status “good”, but not with them knowing the exact values of the concerned serial numbers, which could be used to attack the system. Likewise with the 1024-bit certs with validity beyond 2013, it's useful to know they existed but a different matter to get the name of the client (in that case, Mozilla could published the number of certificates concerned). Or letting people know which accounts exactly didn't have multi-factor authentication for certificate issuance. I understand the redaction not to be about which kind of problem there was, but about letting specific nominative information be published about each problem. If a certification authority (CA) were concerned that its audit report would be made public without any redaction whatsoever, that CA should operate in a way that ensures nothing in the report would be embarrassing to itself or harmful to its customers. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/27/14, 7:11 AM, Jean-Marc Desperrier wrote: David E. Ross a écrit : With a redacted audit report, the presumption should be that hidden negative information exists that would disqualify the certification authority from having its root certificate in the NSS database if such information were disclosed. any redaction would imply the existence of hidden negative information that would necessitate removal of the affected root certificate from the NSS database if such information were disclosed. I think there's miscomprehension here. I understand that the CAs are OK with people knowing that some unknown serial numbers would give status “good”, but not with them knowing the exact values of the concerned serial numbers, which could be used to attack the system. Likewise with the 1024-bit certs with validity beyond 2013, it's useful to know they existed but a different matter to get the name of the client (in that case, Mozilla could published the number of certificates concerned). Or letting people know which accounts exactly didn't have multi-factor authentication for certificate issuance. I understand the redaction not to be about which kind of problem there was, but about letting specific nominative information be published about each problem. Yes. That is a good explanation of the issue. So, I thought I would float the idea and see what happens, or see if others had ideas about this. Based on the discussion so far, I think the answer is that the CAs need to work with their auditors to create a public-facing audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On Thu, Aug 28, 2014 at 09:42:13AM +0800, Man Ho (Certizen) wrote: Concerning about a list of BRs that the CA is still working to conform with, I don't think CAs will agree to publish in public for security reason and also because of business sensitivity. I think some CAs don't even want to claim they are CAB/Forum BR compliant, but just want to be included in all root certificate programs. And I want a pony. But wishing don't make it so. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On Tue, Aug 26, 2014 at 11:35 AM, Kathleen Wilson kwil...@mozilla.com wrote: I am running into a problem with BR audit statements that list details about issues that have been found. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements ...The first BR audit for each CA and subCA may include a reasonable list of BRs that the CA (or subCA) is not yet in compliance with. ... The problem is that some BR audit statements provide information about the CA's BR non-conformance that the CA considers to be sensitive (and non-publishable) information. Without any concrete data on the scope of the items that are not yet in compliance it is hard to make judgements. In the spreadsheet of included roots, I could add a column to list BR section numbers that were in the redacted information. Could you publish a list of BR section numbers which one or more CA is saying they do not yet comply with, not including any CA names? That would help determine the scope of the request and provide some guidance on the possible impact of the non-compliance without calling out any specific CA(s). Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/26/14, 12:10 PM, Peter Bowen wrote: Could you publish a list of BR section numbers which one or more CA is saying they do not yet comply with, not including any CA names? That would help determine the scope of the request and provide some guidance on the possible impact of the non-compliance without calling out any specific CA(s). Collected from BR audit statements from multiple CAs... BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support legacy customer apps) BR 13.2.6 - OCSP giving status “good” for unknown serial numbers. BR 16.5 - multi-factor authentication for *all* accounts capable of directly causing certificate issuance BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed one year BR 17.8 – audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or *at least three percent* of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken BR 11.2 – re-verifying identity for cert renewal requests ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/26/14, 1:14 PM, Chris Palmer wrote: On Tue, Aug 26, 2014 at 1:09 PM, Kathleen Wilson kwil...@mozilla.com wrote: BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support legacy customer apps) BR 13.2.6 - OCSP giving status “good” for unknown serial numbers. BR 16.5 - multi-factor authentication for *all* accounts capable of directly causing certificate issuance BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed one year BR 17.8 – audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or *at least three percent* of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken BR 11.2 – re-verifying identity for cert renewal requests It is a bad idea to censor these highly relevant facts. These are the baseline requirements for a company to be trusted by the entire planet. This is the level of information I could list for each CA who had a redacted section in their BR audit. The problem is that the BR audit statements have further details that the CAs do not want published. I'm just exploring how to get past the current situation of CAs not being able to provide public-facing BR audit statements for their first full-year BR audit. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On 8/26/14, 1:42 PM, Chris Palmer wrote: If CAs can't meet the baseline requirements that they themselves helped set, and prove so to the public, perhaps the current situation is the end of the road. Sigh. It'll get better. I can see in those audit statements that the issues either were resolved or are soon to be resolved. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
On Tue, Aug 26, 2014 at 1:24 PM, Kathleen Wilson kwil...@mozilla.com wrote: On Tue, Aug 26, 2014 at 1:09 PM, Kathleen Wilson kwil...@mozilla.com wrote: BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support legacy customer apps) BR 13.2.6 - OCSP giving status “good” for unknown serial numbers. BR 16.5 - multi-factor authentication for *all* accounts capable of directly causing certificate issuance BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed one year BR 17.8 – audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or *at least three percent* of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken BR 11.2 – re-verifying identity for cert renewal requests This is the level of information I could list for each CA who had a redacted section in their BR audit. The problem is that the BR audit statements have further details that the CAs do not want published. I'm just exploring how to get past the current situation of CAs not being able to provide public-facing BR audit statements for their first full-year BR audit. The Mozilla CA Communcation in Jan 2013 asked each CA whether they comply with the BR. (https://wiki.mozilla.org/CA:Communications#January_10.2C_2013 question 2). According to the results spreadsheet, a number of CAs disclosed non-compliance with remediation dates (Option C under Action 2). I would propose than any findings that match those called out in that spreadsheet be redacted. For example, unfairly picking on a CA, Unizeto said they would have the OCSP requirement met by Oct 2013. If their audit shows that they did not meet BR 13.2.6 until September 2013, then this would match the spreadsheet and the finding would be redacted. However if, again unfairly picking a CA, A-Trust, who chose option A, had findings, these would not be redacted. This would allow the finer/more sensitive details of previously disclosed items (for example the names of Unizeto's sub-CAs who didn't have OCSP) to not be further disclosed. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Allow Redaction of issues detailed in BR Audit statements?
Hi Kathleen, My take on this is that any information that is relevant to a CA's conformance (or lack thereof) with the BRs (or any other part of Mozilla's inclusion criteria) needs to be disclosed to those who are passing judgment on the suitability of the CA for inclusion in the Mozilla trust store. If the public (or at least that subset which is subscribed to and participates on this list) are deemed to be passing judgment, then yes, that information needs to be publically disclosed. At this point, though, there shouldn't be any CAs with an adverse finding in their audit report. The audit done by Feb 2013 could list adverse findings, but the next audit statement (which was due in Feb 2014 -- six months ago) should have been clean and without qualification. Any CA who isn't willing to hold up their audit report to the world and say See! We're clean! is eligible for removal, either because their audit is out of date (by at least six months) or else is documented to not be in conformance with the BRs. On an unrelated point, I'd like to thank you, Kathleen, for the work you do in this area. Going over the minutiae of audit reports can't be a particularly fun job, but it *is* a very necessary one, so thanks for being the one who does it. - Matt On Tue, Aug 26, 2014 at 11:35:27AM -0700, Kathleen Wilson wrote: I am running into a problem with BR audit statements that list details about issues that have been found. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements ...The first BR audit for each CA and subCA may include a reasonable list of BRs that the CA (or subCA) is not yet in compliance with. ... The problem is that some BR audit statements provide information about the CA's BR non-conformance that the CA considers to be sensitive (and non-publishable) information. As you know, Mozilla's policy requires public-facing audit statements. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ 6. ... provide public attestation of their conformance to the stated verification requirements ... So, I need a way forward that enables the CA to provide the required BR audit statement without publicly disclosing sensitive information. Just brainstorming... Would it be OK to accept public-facing BR audit statements that have the information about the issues redacted? In the spreadsheet of included roots, I could add a column to list BR section numbers that were in the redacted information. I will appreciate thoughtful and constructive input on this topic. 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
Re: Allow Redaction of issues detailed in BR Audit statements?
On Tue, Aug 26, 2014 at 5:18 PM, Matt Palmer mpal...@hezmatt.org wrote: On an unrelated point, I'd like to thank you, Kathleen, for the work you do in this area. Going over the minutiae of audit reports can't be a particularly fun job, but it *is* a very necessary one, so thanks for being the one who does it. And a hearty +1 to that! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
