Thank you Erwann. I have no other questions at this time. On Thu, Apr 28, 2016 at 7:13 AM, Erwann Abalea <eaba...@gmail.com> wrote:
> 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
