CA's management assertions is exactly for this purpose, i.e. a public-facing statement. And according to Webtrust, auditor should give an independent opinion on the assertions.
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. On 8/28/2014 12:15 AM, Kathleen Wilson wrote: > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
