Bonsoir, Le mercredi 10 février 2016 00:15:11 UTC+1, Charles Reiss a écrit : > On 02/09/16 20:07, Kathleen Wilson wrote: > > This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include > > the following root certificates, turn on the Websites and Email trust > > bits for all of them, and enable EV treatment for all of them. These new > > certs will eventually replace the 'Certplus Class 2' root certificate > > that was included via Bugzilla Bug #335392. > > + Certplus Root CA G1 - (SHA512, RSA4096) > > + Certplus Root CA G2 - (SHA384, ECC) > > + OpenTrust Root CA G1 - (SHA256, RSA4096) > > + OpenTrust Root CA G2 - (SHA512, RSA4096) > > + OpenTrust Root CA G3 - (SHA384, ECC) > > > > Previously the company was known as Keynectis, with the Certplus and > > OpenTrust brands, issuing certs to public or private corporations, > > associations. > > > > Ownership changed November 3, 2015, from Keynectis to DocuSign France, > > which was acquired by DocuSign Inc. The root keys remained at the same > > physical location operated by the same team. During the transfer of > > activity, all past agreements/contracts and so on remain available. > > People linked to this activity were also transferred to the new company. > > > > The request is documented in the following bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1025095 > > > > And in the pending certificates list: > > https://wiki.mozilla.org/CA:PendingCAs > > > > Summary of Information Gathered and Verified: > > https://bugzilla.mozilla.org/attachment.cgi?id=8692112 > > > > Noteworthy points: > > > > * The primary documents are the RCA CP, SSL CP, and EV CPS. Documents > > are provided in French and some are translated into English. > > > > Document Repository (French): http://www.OpenTrust.com/PC > > Document Repository (English): > > https://www.opentrustdtm.com/security-policies/?lang=en > > RCA - Root Certificate Authorities - CP (English): > > https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf > > > My reading of section 8.1 of the CP is that if CA is > - _not_ technically constrained (as defined by Mozilla); and > - not "issuing SSL certificates" > (e.g. a CA lacking any EKU or name constraints that only issues > certificates to individuals), then, it can be audited only by auditors > who do not meet Mozilla's definition of an independent auditor. (8.2 > allows internal auditors to be only "sufficiently organizationally > separated from that entity to provide an unbiased, independent > evaluation", which seems like it could include a CA employee.) Is this > correct?
For CAs not issuing TLS certificates, an internal audit is performed, as permitted by Mozilla's definition of an independent auditor. See Mozilla Inclusion Policy version 2.2, items 11, 12, 13, and 14. During our regular ETSI TS 102042 and ETSI TS 101456 audits, the auditor ensures that the internal audit team (a trusted role) is free from any pressures that might adversely influence trust in the service it provides. See section 7.5 of the aforementioned ETSI TS documents. > Section 9.3.1 of this CP suggests that "audit results and reports" are > confidential information, which seems to be at odds with Mozilla's > public attestation requirement. The conclusion of the auditor is public, not the findings and mentions. Those are transmitted to the supervisory body. > Section 9.3.3 of this CP states in part: > "PKI components must not disclose certificate or certificate-related > information to any third party unless authorized by this policy" > while section 9.4.3 states: > "Any and all information within a certificate is inherently public > information and shall not be considered confidential information." > > What is the 'certificate information' contemplated by section 9.3.3 that > is not contained within a certificate? Certificate-related information that are protected by privacy laws, such as telephone numbers, copies of ID cards, passwords or PIN numbers exchanged between the customer and the CA/RA. Event logs are also confidential. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
