Hi Michael,

On Wednesday, November 15, 2017 at 6:07:44 AM UTC-7, 
michael.vonn...@bit.admin.ch wrote:
> Hi Wayne
> 
> Thank you for the review of our CP/CPS. Please find our answers to your 
> findings/questions below.
> 
> >> I reviewed the CP/CPS, BR self assessment, audit statement, and other 
> >> information provided as part of this request. Overall, I found the CPS and 
> >> BR self assessment to be lacking in detail, and in some cases the CPS 
> >> references non-public documents.
> 
> >> Here are my specific comments:
> 
> >> - I’m also receiving a 404 periodically when loading 
> >> http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf,
> >>  leading me to believe that the file is missing from one or more servers.
> 
> The URL is 
> http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf
>  and the document was available as of 2017-11-15, 0650 UTC. We will observe 
> the availability and try to figure out why you received a 404 error.
> 
> >> - The audit statement linked above doesn’t include the period covered nor 
> >> list any of the sub-CAs covered as required by Mozilla policy section 
> >> 3.1.4.
> 
> This is correct. We are expecting an updated version of this document and 
> will see with the audit body to receive an updated version as required by 
> Mozilla policy. This update has been ordered by us on 2017-03-09, but we did 
> not receive that as of now. We will contact KPMG to speed up that process.
> 
> >> - The current 1.4 version of the CPS at 
> >> https://www.bit.admin.ch/adminpki/00243/06257/index.html?lang=de dated 
> >> 2017-08-17 uses obsolete descriptions of domain authorization methods in 
> >> section 3.2.2.4. These methods are not described at the level of detail 
> >> required by Mozilla policy and may not comply with the current version of 
> >> the BRs.
> 
> The checklist is published here: 
> http://www.pki.admin.ch/public/83823_Checkliste-Genehm-SSL-TLS-ZertifAntr-CAs-SwissGov-PKI-160513-e_pub.pdf
>  and linked on our product information page: 
> https://www.bit.admin.ch/adminpki/00240/00241/05913/05914/index.html?lang=de .
> 
Thank you, I am now able to access the checklist. Unfortunately, item #4 of the 
checklist also lists obsolete domain validation methods including "any other 
method". Mozilla policy section 2.2(3) requires domain validation methods to be 
clearly described in the CA's CPS.
>
> >> - The answer to the self-assessment question 1.3.2 on Delegated Third 
> >> Parties states that “CA does not allow initial identity validation 
> >> delegated to third parties”; however, CPS section 1.3.2 uses the 
> >> [undefined] term 'Registration Agent' to describe what appears may be a 
> >> Delegated Third Party in 1.3.2.3.
> 
> It may appear to be, but it is not. All 'Registration Agent's are public 
> employees, mandated, trained and checked by the CA in a direct contractual 
> relationship with the CA.
> 
Could you explain what a "direct contractual relationship" means?
>
> >> - BR 4.9.3 requires the CA to publicly disclose instructions for problem 
> >> reporting through a readily accessible online means. Section 4.10.2 of the 
> >> CPS states that ‘High-Priority Certificate Problem Reports can be 
> >> submitted on the SG PKI Homepage 24x7’ but I don’t find any clear 
> >> reference to problem reporting at https://www.bit.admin.ch/adminpki/.
> 
> See https://www.bit.admin.ch/adminpki/00252/index.html?lang=de. The BIT 
> Service Desk is available 24/7 for high priority problem reports.
> 
This appears to be generic contact information, which is fine as long as it is 
monitored 24x7, however, I don't see any indication that this is the place 
where problem reports are accepted.
>
> >> - The current 1.4 version of the CPS at 
> >> https://www.bit.admin.ch/adminpki/00243/06257/index.html?lang=de dated 
> >> 2017-08-17 does not include information about CAA as required by the 
> >> latest version of the BRs.
> 
> Yes, CAA was required after that, on 2017-09-08. We will update this in the 
> next revision of the CPS.
> 
Per section 2.2 of the BRs, this was required as of 8-September.
>
> >> - The CP/CPS doesn’t include the conformance statement required by BR 
> >> section 2.2.
> 
> The CP/CPS is dated 2017-08-17, at that date no conformance statement was 
> required. We will update this in the next revision of the CPS.
> 
I am referring to BR section 2.2 paragraph 3 which states:

The CA SHALL publicly give effect to these Requirements and represent that it 
will adhere to the latest published version.  The CA MAY fulfill this 
requirement by incorporating these Requirements directly into its Certificate 
Policy and/or Certification Practice Statements or by incorporating them by 
reference using a clause such as the following (which MUST include a link to 
the 
official version of these Requirements):
[Name of CA] conforms to the current version of the Baseline Requirements for 
the Issuance and Management of Publicly‐Trusted Certificates published at 
http://www.cabforum.org.  In the event of any inconsistency between this 
document and those Requirements, those Requirements take precedence over this 
document.

I believe this has been a requirement since version 1.0 of the BRs.
>
> >> - The CP/CPS doesn’t specify how it is licensed per Mozilla policy 3.3(3).
> 
> We fully accept Mozilla policy 3.3, but this is not something that has to be 
> mentioned in a CP/CPS. As in 3.3 (3): If no such license is indicated, the 
> fact of application is considered as permission from the CA to allow Mozilla 
> and the public to deal with these documents, and any later versions for root 
> certificates which are included in Mozilla's trust store, under CC-BY-ND 4.0
> 
> >> - Section 4.1.1 of the CPS describes the enrollment process but does not 
> >> mention how suspicious certificate requests are identified.
> 
> The checklist is published here: 
> http://www.pki.admin.ch/public/83823_Checkliste-Genehm-SSL-TLS-ZertifAntr-CAs-SwissGov-PKI-160513-e_pub.pdf
>  and linked on our product information page: 
> https://www.bit.admin.ch/adminpki/00240/00241/05913/05914/index.html?lang=de .
> 
> >> - Section 4.2.1 of the CPS does not provide any information on high risk 
> >> certificate requests.
> 
> That’s on the checklist (see above)
> 
> >> - Section 4.2.2 makes 'Domain names within the range assigned to the 
> >> requesting Registration Agent (as of 3.2.3)' a 'Condition for Approval', 
> >> but section 3.2.3 is titled ‘Authentication of individual identity’ and 
> >> doesn’t appear to describe domain restrictions.
> 
> That’s on the checklist, too (see above)
> 
> >> - Section 7.1.2.3 refers the reader to the 'Object Identifiers' document 
> >> at https://www.bit.admin.ch/adminpki/00243/index.html?lang=de for 
> >> subscriber certificate profiles. I believe the reference should be to the 
> >> 'CA Layout and Policies' document at the same location.
> 
> Yes you’re right, the text should refer to [29] not [30]. We will update this 
> in the next revision of the CPS.
> 
> >> Please note that responses to section 3 of the BR self-assessment included 
> >> references to a “Checklist”, but I’m unable to load 
> >> http://www.pki.admin.ch/public/83823_Checkliste-Genehm-SSL-TLS-ZertifAntr-CAs-SwissGov-PKI-160513-e_pub.pdf
> >>  (I get a 404), so my comments do not reflect any information contained 
> >> therein.
> 
> The document was available as of 2017-11-15, 0650 UTC. We will observe the 
> availability and try to figure out why you receive a 404 error.
> 
> 
> If you have further questions or remarks, I am happy to help.
> 
> Regards
> Michael
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to