Bonjour, Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit : > OpenTrust has requested EV treatment in Chrome, with bug: > https://bugs.chromium.org/p/chromium/issues/detail?id=385090 > > As such I've reviewed the "EV SSL CA Certificate Practice Statement" version > 0.8 dated Feb 1st 2016, and have the following comments and questions for > them: > > 1.1 Overview > > We encourage honouring CAA records, even though it's not currently required. > We also encourage CAs to publish how they would use CAA values in the future > if they were to support it, to allow domain owners to start creating such > records.
Ok, we'll adapt our procedures if necessary. > For Club EV and ISP EV, it says they perform "All checks required to issue EV > Certificates, in accordance with this CPS." Could you confirm that KEYNECTIS > EV still performs the final cross check, per 3.2.6 Validation of Authority. As described in sections 4.2.1.2 and 4.2.1.3, Club EV and ISP EV offers can't be open unless KEYNECTIS EV CA has performed necessary identification and authentication processes under dual control (RA operator 1 and RA operator 2), to perform this cross-check. > 1.2 Document Name and Identification > > The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but this > section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11. Are both > being requested? If so, please update in the Chromium bug. The Google Chromium application request will be updated accordingly. > 1.5.4 CPS Approval Procedure > > Please clarify the exact details regarding "Parts of the CPS are remains > (sic) confidential and are not published." Internal procedures, such as management of badges, management of access controls (physical and logical), management of secret shares, etc. > 1.6 Definitions and Acronyms > > Independent confirmation from applicant: definition missing. We meant to copy/paste the definition from EV guidelines, and missed it. This will be corrected in the next CPS revision. > 3.2.2.4 Verification of an Entity Domain Name > > "For Government Entity Applicants, the CA relies on the domain name listed > for that entity in the records of the QGIS in Applicant's Jurisdiction to > verify Domain Name." > > Please describe how this is covered by one of items 1 to 7 of section 3.2.2.4 > of the Baseline Requirements. This is an unfortunate mix, inspired by section 3.2.2.1 (dealing with Entity legal existence verifications). This phrase will be removed in the next CPS revision. We only use methods 1 to 4. > 4.1.2.1 K.EV offer > > "at the following address:" - no address is specified That's an error, the proper address is transmitted with the purchase order. This will be corrected in the next CPS revision. > 4.2.1.1 K.EV offer > > Missing section reference in the 7th bullet The next 2 bullets should have been right-indented, as in sections 4.2.1.2 and 4.2.1.3. Will be corrected in the next CPS revision. > 4.9.4 Time within Which CA Must Process the Revocation Request > > "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm Monday to > Friday, except during bank holidays." > > Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a Certificate > within 24 hours", and 4.9.3. "The CA SHALL maintain a continuous 24x7 ability > to accept and respond to revocation requests and related inquiries.". Please > confirm that a revocation request can go directly to the CA if the RA isn't > currently open. This 9-18 Mon-Fri time frame is only for OPENTRUST RA human personnel. KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as written on the preceding page. > 5.8 EV CA component termination > > Several sections of the Baseline Requirements refer to CA being revoked > making arrangements for another CA to provide revocation support for issued > certificates. Would such an arrangement be considered here? No. > 7.1 Certificate Profile > > Key length still mentions 1024 bits, without caveat. > > Public key algorithm still mentions SHA1, without caveat. 1024 bits and SHA1 were not removed from the CPS, this will be done in the next CPS revision. In the meantime, we of course follow CABF BR regarding key sizes and signature algorithm (keys smaller than 2048 bits are rejected, and certificates are signed with SHA2 only since 01/01/2016). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
