Re: Audit Reminder Email Summary
Kurt, Thank your for raising this issue. As documented in the bug you referenced, there was a good deal of confusion about Mozilla's acceptance (or not) of SwissSign's 2017 audit statements. Mozilla rejected the first statements and then asked questions about the second set of statements but never clearly rejected them. A verbal agreement was reached that SwissSign would obtain new audits, but it resulted in only one of their 3 included roots being re-audited later in 2017. Given the lack of documentation, I am willing to accept that as a misunderstanding of scope between Mozilla and SwissSign. The result is that we have 2017 audit statements in CCADB that are marked as having been accepted despite the significant concerns that were raised in the bug you referenced. I believe the fact that the audit period extended for more than a year was caused by SwissSign's (understandable) decision to use a different auditor this year. However, I agree that this is a problem because it directly contradicts BR section 8.1 which states "An audit period MUST NOT exceed one year in duration" and Mozilla's requirement that "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually". I believe these new audit statements (both for the Platinum and Silver roots) should be rejected on that basis, and I would also welcome a response from SwissSign and/or their auditors. In addition, Kathleen is researching why this was not flagged by CCADB when the audit cases were processed. When choosing to switch auditors for 2018, SwissSign asked Mozilla to permit them to use TUV Austria prior to the firm's formal eIDAS accreditation. Given that the individuals performing the audits were well-known as auditors for TUV Germany who moved to the Austrian entity, Mozilla agreed to this exception as permitted under Root Store Policy section 3.2. TUV Austria has since informed us that they have received their accreditation. Finally, the audit submitted for the (not yet included) SwissSign Silver G3 root is point-in-time, and thus not acceptable as documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c44 I have discussed this with SwissSign's auditors, and their belief was that a point-in-time report is appropriate when no certificates have been issued from a root during the period. I do not agree with this interpretation and plan to have further discussions with ETSI folks on this topic (WebTrust has already confirmed that it is possible report on a root over a period-of-time even when no issuance has occurred). Meanwhile, I believe that TUV Austria may reissue the reports for this root as period-of-time since the audits themselves covered the entire period. - Wayne On Wed, Aug 22, 2018 at 1:32 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2018-08-21 21:03, Kathleen Wilson wrote: > > Mozilla: Overdue Audit Statements > > Root Certificates: > > SwissSign Platinum CA - G2** > > > > ** Audit Case in the Common CA Database is under review for this root > > certificate. > > > > Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552 > > Audit Statement Date: 2017-03-30 > > BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552 > > BR Audit Statement Date: 2017-03-30 > > CA Comments: null > > Is this not properly marked in the database? > > I found https://bugzilla.mozilla.org/show_bug.cgi?id=1374381, which > seems to be related to it, and was closed. > > The linked audits there: > - For one claiming the period covering 2015: The statement does not > state which period was covered. > - For one claiming the period covering 2016: The statement does not > state which period was covered. A previous report from the auditor for > that period stated that it was a point in time audit. > The changed report removed this sentence: "KPMG has performed a point in > time audit. The reference date is 8 March 2017." and replaced > "We were not engaged to and did not conduct an examination, the object > of which would be the expression of an opinion on the Application for > Extended Validation (EV) Certificate. Accordingly, we do not express > such an opinion. Had we performed additional procedures, other matters > might have come to our attention that would have been reported to you" > with: > "KPMG has assessed the architecture, operation and procedures on a > sample approach although we have not assessed every configuration > setting on technical devices." > - The report from a new auditor covered the period: March, 9th 2017 > until June, 6th 2018, which is longer than 1 year. > > > Kurt > ___ > 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
Re: Certigna Root Renewal Request
Thank you for your response. On Wed, Aug 22, 2018 at 11:51 AM josselin.allemandou--- via dev-security-policy wrote: > We confirm that no, this is not the case. This is what we said in the CP / > CPS because we thought that these constraints could be regularly > encountered and that it could be bad for the business, but as I said in our > answer, the controls to report the blocking cases were positioned since the > beginning of the application of the requirements about CAA records, but we > have failed to update the documents. > > > You are stating that your system has, since 8-September 2017, checked CAA records in compliance with the BRs, and whenever a CAA record indicated that you did not have permission to issue the certificate, the system alerted your RA Officers who then rejected the request. Is this correct? > > Requests are processed not only automatically but also involving human > validation by our Registration Authority and in particular, our > Registration Officiers are systematically warned in case of alert on a CAA > record. We confirm to you, despite what has not been updated in the CP / > CPS that we block request well in accordance with the requirements > expressed. > > > What evidence do you have that all requests that failed CAA validation were indeed denied? How many requests failed the CAA check and then were manually rejected by an RA Officer? > > We wanted to wait for your feedback on the other points before updating > our CP / CPS, but we can update them before the end of the week if > necessary. > > > I would recommend that you go ahead and make the CPS changes that you have proposed rather than waiting for Devon's reply, but do not rush to complete them this week. > > We hope that it meets yours expectation and remain at your disposal for > further information. > > Best regards > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certigna Root Renewal Request
And just to clarify, when we specified this in the CP / CPS, we thought that the document signed by a legal representative at the time of the certificate request could be sufficient in terms of consent, and that despite our requests, the applicant have not wished to update their CAA registration in addition to providing the document. So that's what was specified in the CP / CPS but we still set up the controls and monitor these points since to block the applications concerned. We only failed to regularize the point in the CP / CPS. We hope that it meets yours expectation and remain at your disposal for further information. Best regards ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certigna Root Renewal Request
We confirm that no, this is not the case. This is what we said in the CP / CPS because we thought that these constraints could be regularly encountered and that it could be bad for the business, but as I said in our answer, the controls to report the blocking cases were positioned since the beginning of the application of the requirements about CAA records, but we have failed to update the documents. Requests are processed not only automatically but also involving human validation by our Registration Authority and in particular, our Registration Officiers are systematically warned in case of alert on a CAA record. We confirm to you, despite what has not been updated in the CP / CPS that we block request well in accordance with the requirements expressed. We wanted to wait for your feedback on the other points before updating our CP / CPS, but we can update them before the end of the week if necessary. We hope that it meets yours expectation and remain at your disposal for further information. Best regards ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certigna Root Renewal Request
On Wed, Aug 22, 2018 at 2:10 AM josselin.allemandou--- via dev-security-policy wrote: > > > > CPS Section 4.2.1: If the request is valid and allows to obtain with > accuracy the authorization to issue the certificate by a legal > representative of the entity which is owner of the domain names, the CA > authorizes itself to issue the certificate even if the CA is not present in > the list of authorized CA. > This appears to directly contravene BR Section 3.2.2.8, which specifies > the following 3 scenarios in which a CA can issue a certificate despite not > appearing in the CAA record: > • CAA checking is optional for certificates for which a Certificate > Transparency pre-certificate was created and logged in at least two public > logs, and for which CAA was checked. Forum Guideline Baseline Requirements, > v. 1.6.0 21 > > • CAA checking is optional for certificates issued by a Technically > Constrained Subordinate CA Certificate as set out in Baseline Requirements > section 7.1.5, where the lack of CAA checking is an explicit contractual > provision in the contract with the Applicant. > > • CAA checking is optional if the CA or an Affiliate of the CA is the DNS > Operator (as defined in RFC 7719) of the domain's DNS. > > -> Indeed, we were operating up to now a control with an alert and a > notification to the applicant (pointing on this page > https://www.certigna.fr/dns-caa.xhtml) to add us in the field CAA if that > It is present, but it was not blocking for the request because we > considered that having a signed authorization of the legal representative > was sufficient even if the applicant not having updated the CAA > registration. > > > This response implies that Certigna has misissued certificates that failed CAA validation. I have opened a bug [1] asking Certigna to identify and remediate these certificates, and to file an incident report. > > Now, our control processes foresee that the certificate request is blocked > notably in the following cases: > - The CAA DNS field is present, it contains an "issue" or "issuewild" tag > and it does not list Certigna as an authorized CA. > - The CAA DNS field is present, designed as critical and the tag used is > not supported by the CA (so if it is not an "issue" or "issuewild"). > > We will be releasing the CP / CPS update to clarify these practices being > implemented now. If this is enough for you, we will immediately publish the > documents. > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certigna Root Renewal Request
Just in addition, because the point was raised to us, we also take into account the problem related to DNSSEC with the case where the zone is validly DNSSEC-signed and our CAA query times out. As mentioned above, the publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you. Thank you in advance for your help and your reply. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certigna Root Renewal Request
Thank you very much Devon for this analysis and the time past on our request. You will find below additional information. Sorry for the delay, I was on vacation. The publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you. Thank you in advance for your help and your reply. CPS Section 1.4.2 states "Unless stated otherwise, in this document, “RA” covers the Registration Authority and Delegate Registration Authorities." CPS Section 3.2 calls out DRAs ability to perform initial identity validation steps and uses the phrasing “RA (RA or DRA)” at the beginning of the section. CPS Section 4.2.1 states that during the identification and request validation process, that a DRA forwards the steps undertaken (including validation of domain control), and the RA "ensures that the request corresponds to the mandate of the DRA operator" Due to the language in 1.4.2 stating that unless stated otherwise, “RA” refers to both Registration Authorities and Delegated Registration Authorities, can you direct me to where in the CP/CPS it calls out that DRAs, Certificate Managers, and Certificate Agents (as defined in Section 1.4.5) are specifically unable to perform the validation checks of 3.2.2.4 and 3.2.2.5? Additionally, what does it mean for an RA to “ensure that the request corresponds to the mandate of the DRA operator”? -> In the CPS, the term RA is mainly used for the registration authority, which rely on the DRA for some of its operations, such as collecting or issuing information to the certificate manager. However, we have made the choice for the moment that the majority of the verifications are currently carried out by our internal RA, and not the DRAs however some controls such as face to face can be ensure to the DRA. Paragraph 4.2.1 was added in particular to address this case where the face-to-face was in particular carried out by a DRA, however the other controls, in particular that concerning the control of the domain is well realized by the Certigna internal RA through technical means put in place by our services and not those of our DRAs. We can, if you wish, specify in our CP / CPS that these checks are carried out by the RA and not the DRA. For clarification, the control of the DRA operator mandate is to verify that the person who sends a proof (eg attestation of face to face) is among the authorized persons of the DRA and that the signature (handwritten or electronic) of the document comes from this person. CPS Section 4.2.1: If the request is valid and allows to obtain with accuracy the authorization to issue the certificate by a legal representative of the entity which is owner of the domain names, the CA authorizes itself to issue the certificate even if the CA is not present in the list of authorized CA. This appears to directly contravene BR Section 3.2.2.8, which specifies the following 3 scenarios in which a CA can issue a certificate despite not appearing in the CAA record: • CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. Forum Guideline Baseline Requirements, v. 1.6.0 21 • CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. • CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS. -> Indeed, we were operating up to now a control with an alert and a notification to the applicant (pointing on this page https://www.certigna.fr/dns-caa.xhtml) to add us in the field CAA if that It is present, but it was not blocking for the request because we considered that having a signed authorization of the legal representative was sufficient even if the applicant not having updated the CAA registration. Now, our control processes foresee that the certificate request is blocked notably in the following cases: - The CAA DNS field is present, it contains an "issue" or "issuewild" tag and it does not list Certigna as an authorized CA. - The CAA DNS field is present, designed as critical and the tag used is not supported by the CA (so if it is not an "issue" or "issuewild"). We will be releasing the CP / CPS update to clarify these practices being implemented now. If this is enough for you, we will immediately publish the documents. CPS Section 3.2.7 calls out special actions taken for “High Risk Certification Requests”. It says the procedures for
Re: Audit Reminder Email Summary
On 2018-08-21 21:03, Kathleen Wilson wrote: Mozilla: Overdue Audit Statements Root Certificates: SwissSign Platinum CA - G2** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552 Audit Statement Date: 2017-03-30 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552 BR Audit Statement Date: 2017-03-30 CA Comments: null Is this not properly marked in the database? I found https://bugzilla.mozilla.org/show_bug.cgi?id=1374381, which seems to be related to it, and was closed. The linked audits there: - For one claiming the period covering 2015: The statement does not state which period was covered. - For one claiming the period covering 2016: The statement does not state which period was covered. A previous report from the auditor for that period stated that it was a point in time audit. The changed report removed this sentence: "KPMG has performed a point in time audit. The reference date is 8 March 2017." and replaced "We were not engaged to and did not conduct an examination, the object of which would be the expression of an opinion on the Application for Extended Validation (EV) Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you" with: "KPMG has assessed the architecture, operation and procedures on a sample approach although we have not assessed every configuration setting on technical devices." - The report from a new auditor covered the period: March, 9th 2017 until June, 6th 2018, which is longer than 1 year. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
