Bonsoir, Le vendredi 19 février 2016 00:55:02 UTC+1, Charles Reiss a écrit : > On 02/18/16 21:40, Erwann Abalea wrote: > > 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. > > Mozilla's definition of independent auditor requires that the auditor " > not [be] affiliated with the CA as an employee or director". I assume > that this will be the case for subCAs for which an internal audit is > performed by virtue of the audit being performed employees of the parent > CA, a different company. > > I don't believe having CAs audit their unconstrained subCAs is within > the spirit of Mozilla's policy (since a sufficiently non-compliant subCA > is an existential risk to the parent CA) though it is probably > technically in conformance. > > I assume you believe the internal audit fits the third option of item > 14's second requirement: "the party is bound by law, government > regulation, and/or a professional code of ethics to render an honest and > objective judgement regarding the CA" (since I imagine you aren't going > to be disclosing your financial relationship with external subCAs). Can > you identify what law, regulation, or code of ethics is involved?
Our Root CA and intermediate CAs are ETSI TS 102042 compliant, and the audit is performed by an external auditor (LSTI). As described in our CP (section 8), we have an internal organization that allows fulfilling the requirements set in ETSI TS 102042 section 7.5, including the independence of trusted roles regarding to any "commercial, financial, or other pressures which might adversely influence trust in the services it provides." The organization team at DocuSign France performing the internal audits and validating the CP/CPS is the PMA (Policy Management Authority), and has no hierarchical relationship with the department operating the CAs. This is also in line with TS 102042 section 5.4.1). This requirement is verified during the annual ETSI TS 102042 audit performed by the external auditor. > [snip] > > > >> 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. > > In the event of serious certificate misissuance, what information about > those certificates and how they were issued will DocuSign be able to > share with the public? In compliance with applicable law and reglementation, facing a serious misissuance, DocuSign will be able to publicly share the affected certificates (since they're not confidential), certificate lifecycle (production, detection, and revocation date), what caused the misissuance, what countermeasures are to be applied. Depending on the nature of what caused the misissuance, if the cause may also impact other CAs, we'll responsibly disclose more details with CABForum members on the Management list. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
