Re: Audits of CA conformance to the BRs
On 2014-09-17 00:52, Kathleen Wilson wrote: https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs I really like this section, it makes things clear. https://wiki.mozilla.org/CA:BaselineRequirements#WebTrust_BR_Audit_Statement https://wiki.mozilla.org/CA:BaselineRequirements#ETSI_BR_Audit_Statement.2FCertificate It's not clear that you need either of those 2. Maybe we need to be more explicit in saying which audit are acceptable for what? For the first it has: The BR audit statement may be qualified and list BRs that the CA is not yet in compliance with. The second BR audit (the following year) is expected to confirm that the issues that were listed in the previous BR audit have been resolved. Shouldn't something like that also be in the 2nd? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
All, I updated the following sections of the CA:BaselineRequirements wiki page based on feedback that I received from auditors. Please re-review these sections, and reply if you have feedback on them. https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs https://wiki.mozilla.org/CA:BaselineRequirements#WebTrust_BR_Audit_Statement https://wiki.mozilla.org/CA:BaselineRequirements#ETSI_BR_Audit_Statement.2FCertificate https://wiki.mozilla.org/CA:BaselineRequirements#A_CA.27s_First_BR_Audit https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
I updated this part of the wiki page: https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes The section is long, so I won't copy it all here. The most significant change is the addition of the last sentence in this paragraph: When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. Basically, if an auditor intends to continue to audit CAs in Mozilla's program, then we need assurances from the auditor that the things that were missed will not be missed in future audits. I will appreciate feedback on this section of the wiki page. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
Kathleen, Would it make sense to poll auditors with this wording change? The are some on the CABForum mailing list (Wayne could verify) as I suspect it would be more beneficial for auditors themselves to see, agree and above all acknowledge the intent behind the stance you are taking? Thanks. Sent from my iPhone On 3 Sep 2014, at 22:24, Kathleen Wilson kwil...@mozilla.com wrote: I updated this part of the wiki page: https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes The section is long, so I won't copy it all here. The most significant change is the addition of the last sentence in this paragraph: When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. Basically, if an auditor intends to continue to audit CAs in Mozilla's program, then we need assurances from the auditor that the things that were missed will not be missed in future audits. I will appreciate feedback on this section of the wiki page. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 9/3/2014 2:43 PM, Matt Palmer wrote: On Wed, Sep 03, 2014 at 02:24:04PM -0700, Kathleen Wilson wrote: The most significant change is the addition of the last sentence in this paragraph: When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. Basically, if an auditor intends to continue to audit CAs in Mozilla's program, then we need assurances from the auditor that the things that were missed will not be missed in future audits. Would it worth making that explicit, by saying something like, Failure of the Auditor to satisfy Mozilla that they have corrected the deficiencies in their auditing process may jeopardise their standing as a trusted auditor for the Mozilla root program? While we on this list understand the ramifications of not doing so, I'm not sure that an auditor or other person reading that paragraph would understand the consequences of the auditor not providing the necessary documentation. Personally, I find it rather amusing that we've got a Quis custodiet ipsos custodes? situation with auditors. Kinda makes you wonder if giving auditing responsibility for technical systems to *accountants* was such a winning move... - Matt I strongly agree with Matt Palmer's suggestion. -- 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: Audits of CA conformance to the BRs
On 9/3/14, 3:53 PM, David E. Ross wrote: On 9/3/2014 2:43 PM, Matt Palmer wrote: On Wed, Sep 03, 2014 at 02:24:04PM -0700, Kathleen Wilson wrote: The most significant change is the addition of the last sentence in this paragraph: When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. Basically, if an auditor intends to continue to audit CAs in Mozilla's program, then we need assurances from the auditor that the things that were missed will not be missed in future audits. Would it worth making that explicit, by saying something like, Failure of the Auditor to satisfy Mozilla that they have corrected the deficiencies in their auditing process may jeopardise their standing as a trusted auditor for the Mozilla root program? While we on this list understand the ramifications of not doing so, I'm not sure that an auditor or other person reading that paragraph would understand the consequences of the auditor not providing the necessary documentation. Personally, I find it rather amusing that we've got a Quis custodiet ipsos custodes? situation with auditors. Kinda makes you wonder if giving auditing responsibility for technical systems to *accountants* was such a winning move... - Matt I strongly agree with Matt Palmer's suggestion. Added... https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. If the auditor fails to assure Mozilla that they have corrected the deficiencies in their auditing process, then their standing as a trusted auditor for the Mozilla root program may be jeopardized. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 8/20/14, 5:57 PM, Ryan Sleevi wrote: Regarding Whole-Population BR Audit of Intermediate Certs, since the BRs are for SSL certs, this should probably only apply to intermediate certs that are capable of issuing SSL certs. Agreed, which will require a definition of capability. This was discussed during the Mountain View F2F in the Forum though, and roughly aligns with Anything browsers recognize as SSL capable (something Mozilla's policy already explores) Updated https://wiki.mozilla.org/CA:BaselineRequirements#Whole-Population_Audit_of_Intermediate_Certs to intermediate certificates that are capable of issuing SSL certs. Regarding auditing for things in RFC 5280... Added: https://wiki.mozilla.org/CA:BaselineRequirements#RFC_5280 It includes the information you provided. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 8/19/14, 5:37 PM, Kathleen Wilson wrote: All, I started a new wiki page to document Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs. https://wiki.mozilla.org/CA:BaselineRequirements It is a very rough draft, but I would appreciate feedback on it. Thanks, Kathleen Regarding Whole-Population BR Audit of Intermediate Certs, since the BRs are for SSL certs, this should probably only apply to intermediate certs that are capable of issuing SSL certs. Regarding auditing for things in RFC 5280... There are things in RFC 5280 (such as duplicate serial numbers) that aren't stated in the BRs. So, does the CAB Forum need to add important requirements from RFC 5280 to the BRs, so they get added to the BR audit criteria? Why I ask... It is my understanding that when an auditor performs a BR audit, she will follow a BR audit criteria such as the WebTrust BR audit criteria or the ETSI TS 102 042 PTC-BR criteria. For the requirements that are explicitly defined in the BR audit criteria, the auditor will examine the technical settings and sampled certificates to check for those things. For things that are not explicitly defined in BR audit criteria, the auditor may use some less strict audit procedures such as asking CA personnel or reviewing the CP/CPS to check for those things. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On Wed, August 20, 2014 5:17 pm, Kathleen Wilson wrote: On 8/19/14, 5:37 PM, Kathleen Wilson wrote: All, I started a new wiki page to document Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs. https://wiki.mozilla.org/CA:BaselineRequirements It is a very rough draft, but I would appreciate feedback on it. Thanks, Kathleen Regarding Whole-Population BR Audit of Intermediate Certs, since the BRs are for SSL certs, this should probably only apply to intermediate certs that are capable of issuing SSL certs. Agreed, which will require a definition of capability. This was discussed during the Mountain View F2F in the Forum though, and roughly aligns with Anything browsers recognize as SSL capable (something Mozilla's policy already explores) Regarding auditing for things in RFC 5280... There are things in RFC 5280 (such as duplicate serial numbers) that aren't stated in the BRs. So, does the CAB Forum need to add important requirements from RFC 5280 to the BRs, so they get added to the BR audit criteria? They are. From BR 1.1.9 From Section 4, Terminology Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280 From Appendix B - Certificate Extensions (Normative) All other fields and extensions MUST be set in accordance with RFC 5280. Note fields includes non-extension fields. Why I ask... It is my understanding that when an auditor performs a BR audit, she will follow a BR audit criteria such as the WebTrust BR audit criteria or the ETSI TS 102 042 PTC-BR criteria. For the requirements that are explicitly defined in the BR audit criteria, the auditor will examine the technical settings and sampled certificates to check for those things. For things that are not explicitly defined in BR audit criteria, the auditor may use some less strict audit procedures such as asking CA personnel or reviewing the CP/CPS to check for those things. Kathleen RFC 5280 is clear as a profile of what constitutes a 'valid' PKIX X.509 certificate. Fields that fail to adhere to the technical requirements do not conform to the BRs. For example, RFC 5280 Section 4.1.2.2. (Serial Number) The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. This basic requirement has been in RFC 5280 since 2008, RFC 3280 since 2002. The uniqueness requirement is present in RFC 2459 since 1999. (however, the positive integer requirement was not, at least not within 4.1.2.2) Given that the BRs normatively incorporate RFC 5280, auditors MUST be checking compliance in order to evaluate whether or not a given certificate conforms to the BRs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
All, I started a new wiki page to document Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs. https://wiki.mozilla.org/CA:BaselineRequirements It is a very rough draft, but I would appreciate feedback on it. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 2014-08-13 20:16, Kathleen Wilson wrote: 4) I think we need to formally augment the audit process with software tools; such as analysis of data of existing sites chaining up to roots being considered for inclusion. And also run periodically for included roots. I think it would be useful if we could at least start with documenting things that someone external can (try to) look at. Maybe not all of them can be automated, and such a list would at least be useful to do a manual check. So some of the things I'm thinking about: - The checks I already do on the certificates itself. I can of course add more tests if needed. - On a collection of certificates we can check things like duplicate serial number or that it has enough entropy - That OCSP work. There are probably others that I'm forgetting. But I'm also wondering what our policy should be if we can detect problems. It's probably going to depend on the problem we find. But if there are problems that we consider that it requires a new audit, maybe we should also document which one we find so serious? Do we also need a policy about how fast we would like issues to be fixed? At which point do we remove a CA that does not comply? Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 2014-08-14 14:42, Kurt Roeckx wrote: Do we also need a policy about how fast we would like issues to be fixed? At which point do we remove a CA that does not comply? So CAB baseline has: 13.1.5 Reasons for Revoking a Subscriber Certificate The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: [...] 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; [...] 13.1.6 Reasons for Revoking a Subordinate CA Certificate The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs: [...] 5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with these Baseline Requirements or the applicable Certificate Policy or Certification Practice Statement; I currently have 24 open bugs in violation of those requirements. The (root) CA's have been made aware of those problems. The subscriber certificates have not been revoked within the 24 hour limit nor have the subordinate CA's been revoked within 7 days. So it's my believe that we have every right to remove and distrust all those root CA's. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Audits of CA conformance to the BRs
All, As the CFCA discussion showed, there are a few things still to figure out regarding the audits of CA conformance to the BRs. Here are my proposals. 1) BR Audits should always include the whole-population audit of intermediate certificates. The CA's roots and all of their intermediate certificates should *always* be audited for conformance to the stated standards. In the audit, sampling can be used only for end-entity certificates. I think this would need to happen in the CA/Browser Forum, probably as an update to the BRs. 2) BR point-in-time audits may not be sufficient. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. *Note that the CA's first Baseline Requirements audit may be a Point in Time audit.* We could change that to say that the first BR audit may be performed over a minimum of 3 months, and include testing of issuance and infrastructure. i.e. If it is the CA's first BR audit (because they were not in the program and did not know about the BRs) then the audit should cover 3 months, and the certificates/CRLs/OCSP-responses issued during that time must be evaluated against the BRs. Would this help? i.e. Is it needed in addition to proposal #1? 3) If the CA's auditor missed something regarding the BRs, then the CA has to fix the problems and be re-audited by a different auditor. Would a *complete* audit need to be performed? Or just an audit to show the problems have been resolved? Should we require that the re-audit to be for a minimum of 3 months? This can be added to our wiki pages now, and we may want to consider adding this to the actual policy. 4) I think we need to formally augment the audit process with software tools; such as analysis of data of existing sites chaining up to roots being considered for inclusion. And also run periodically for included roots. I will appreciate your constructive feedback on these items. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 8/13/2014 11:16 AM, Kathleen Wilson wrote [in part]: All, As the CFCA discussion showed, there are a few things still to figure out regarding the audits of CA conformance to the BRs. Here are my proposals. [snipped} 3) If the CA's auditor missed something regarding the BRs, then the CA has to fix the problems and be re-audited by a different auditor. Would a *complete* audit need to be performed? Or just an audit to show the problems have been resolved? Should we require that the re-audit to be for a minimum of 3 months? This can be added to our wiki pages now, and we may want to consider adding this to the actual policy. Often, a new auditor will require a complete audit. Changing an auditor is somewhat like changing a primary-care physician. The new physician will often require a complete physical of the patient instead of relying records from the prior primary-care physician. As with a new physician, a completely new audit is an expense for the certification authority, which I suspect would resist any request for such an audit. Compliance might not be obtained unless (as proposed in the past) we institute publicizing non-compliance, not merely with a wall of shame on a Mozilla Web site but also sending out press releases to appropriate news media, alerts to US-CERT, and messages to non-Mozilla newsgroups. -- 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: Audits of CA conformance to the BRs
On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson kwil...@mozilla.com wrote: 2) BR point-in-time audits may not be sufficient. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. *Note that the CA's first Baseline Requirements audit may be a Point in Time audit.* We could change that to say that the first BR audit may be performed over a minimum of 3 months, and include testing of issuance and infrastructure. i.e. If it is the CA's first BR audit (because they were not in the program and did not know about the BRs) then the audit should cover 3 months, and the certificates/CRLs/OCSP-responses issued during that time must be evaluated against the BRs. Would this help? i.e. Is it needed in addition to proposal #1? It seems there two reasons that CAs might get a point in time readiness assessment (PITRA) rather than a period of time audit: 1) They didn't know about the BRs. In this case, it would seem possible that only having a PITRA is due to previously not following the BRs or at least not having auditable processes defined that required them to follow the BRs. 2) They don't yet issue certificates. If an organization is creating a brand new CA, there is no history of operation to be audited, so the only thing an auditor can perform is a PITRA. It is very possible that the CA will not start issuing certificates until they are accepted into the Mozilla program. I think AffirmTrust's application a couple of years ago demonstrated this scenario. It seems reasonable to continue to accept the PITRA for CAs that are not yet issuing certificates. This should be different than handling a CA that has issued certificate which do not follow the BR. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On Wed, August 13, 2014 12:41 pm, Peter Bowen wrote: On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson kwil...@mozilla.com wrote: 2) BR point-in-time audits may not be sufficient. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. *Note that the CA's first Baseline Requirements audit may be a Point in Time audit.* We could change that to say that the first BR audit may be performed over a minimum of 3 months, and include testing of issuance and infrastructure. i.e. If it is the CA's first BR audit (because they were not in the program and did not know about the BRs) then the audit should cover 3 months, and the certificates/CRLs/OCSP-responses issued during that time must be evaluated against the BRs. Would this help? i.e. Is it needed in addition to proposal #1? It seems there two reasons that CAs might get a point in time readiness assessment (PITRA) rather than a period of time audit: 1) They didn't know about the BRs. In this case, it would seem possible that only having a PITRA is due to previously not following the BRs or at least not having auditable processes defined that required them to follow the BRs. 2) They don't yet issue certificates. If an organization is creating a brand new CA, there is no history of operation to be audited, so the only thing an auditor can perform is a PITRA. It is very possible that the CA will not start issuing certificates until they are accepted into the Mozilla program. I think AffirmTrust's application a couple of years ago demonstrated this scenario. It seems reasonable to continue to accept the PITRA for CAs that are not yet issuing certificates. This should be different than handling a CA that has issued certificate which do not follow the BR. Thanks, Peter For 2, it seems a PITRA prior to the inclusion request, but that there may need to be some monitoring phase after the request, and then an audit, like Kathleen proposed. For example, to ensure that OCSP responses are being handled properly (e.g. not returning Good, etc), that the infrastructure is correct. A PITRA, in an ideal world, would be performing these basic RFC 5280 and BR compliance checks, but I suspect auditors may not be fully assessing the conformance to technical requirements, and instead assessing assertions of conformance to technical requirements (assertions which are, unfortunately, more false than not) For 1, for a new CA, I don't see this as something desirable for inclusion. It means that there's an untold number of certs that would be usuable by a publicly trusted anchor but which don't conform to any particular set of (acceptable) technical requirements. I feel like the ONLY suitable answer to this is that they should be (2) (spinning up a new CA). But I suspect that's more controversial :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 8/13/2014 12:34 PM, Ryan Sleevi wrote: On Wed, August 13, 2014 12:02 pm, David E. Ross wrote: On 8/13/2014 11:16 AM, Kathleen Wilson wrote [in part]: All, As the CFCA discussion showed, there are a few things still to figure out regarding the audits of CA conformance to the BRs. Here are my proposals. [snipped} 3) If the CA's auditor missed something regarding the BRs, then the CA has to fix the problems and be re-audited by a different auditor. Would a *complete* audit need to be performed? Or just an audit to show the problems have been resolved? Should we require that the re-audit to be for a minimum of 3 months? This can be added to our wiki pages now, and we may want to consider adding this to the actual policy. Often, a new auditor will require a complete audit. Changing an auditor is somewhat like changing a primary-care physician. The new physician will often require a complete physical of the patient instead of relying records from the prior primary-care physician. As with a new physician, a completely new audit is an expense for the certification authority, which I suspect would resist any request for such an audit. Compliance might not be obtained unless (as proposed in the past) we institute publicizing non-compliance, not merely with a wall of shame on a Mozilla Web site but also sending out press releases to appropriate news media, alerts to US-CERT, and messages to non-Mozilla newsgroups. You are correct, it is an expense for the applying Certification Authority. However, Mozilla's policy clearly states, in Section 16 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ The burden is on the CA to provde that is has met the above requirements. However the CA may request a preliminary determination from us regarding the acceptability of the criteria and/or the competent independent party or parties by which it proposes to meet the requirements of this policy. The alternative to the CA bearing the burden of a re-audit is for Mozilla to bear the (effective) cost of performing the competent audit, and bearing the cost to its users if that audit turns out to be insufficient. A CA that is unwilling or unable to perform such an audit seems like it is unable to demonstrate to Mozilla (and the community) it's ability or willingness to adhere to the Mozilla Inclusion Policy. So I wholeheartedly endorse Kathleen's proposal, especially in the broader context of requiring the auditor examine the known bits of infrastructure and capabilities for technical conformance. If this was a financial institution, and one discovered the books were proverbially cooked, using the same auditor calls into question Why didn't they notice it the first time? Were they not paying attention? Will they pay attention now? Were there other things they were not paying attention to? Will they catch them? Was there malfeasance? Did they conspire? In a system based on trust, as certificates intrinsically are, leaving these questions outstanding seems seriously detrimental. Thus having an independent third party - another auditor - perform the examination seems entirely appropriate. Note that I definitely did NOT intend to argue against Kathleen's item #3. I merely wanted to point out where pushback from certification authorities might occur. However, I do argue in favor of publicity against authorities that refuse compliance. -- 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
