Swiss Government root inclusion request

[Aaron Wu]

This request from the Swiss Government is to include the “Swiss Government Root CA III” root certificate, turn on the Websites trust bit, and enable EV treatment.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=435026

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8859143

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8924456

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8752168

* Documents are provided in English.
Document Repository: https://www.bit.admin.ch/adminpki/
CP/CPS Root CA III: http://www.pki.admin.ch/cps/CPS_2_16_756_1_17_3_61_0.pdf

* CA Hierarchy:
CPS section 1.3.1: This root signs subordinate CAs that are operated exclusively by Swiss Government PKI staff appointed to the task.

CPS section 1.3.1.2: This root currently has the following internally-operated subordinate CAs:
- Swiss Government Public Trust Standard CA 02
- Swiss Government Public Trust EV CA 02
- Swiss Government Public Trust Code Signing Standard CA 02
- Swiss Government Public Trust EV Code Signing EV CA 02

CPS section 1.3.1.2.1.1: The “Swiss Government Public Trust Standard CA 02” subCA has been cross-signed by QuoVadis Enterprise Trust CA 2 G3. The cross-signed certificate is technically constrained to the domains listed in Annex B (section 9.19) of the CPS.

* The request is to turn on the Websites trust bit and enable EV treatment.

CPS section 3.2.2 Authentication of organization and Domain Identity
SG PKI Root III does not process applications that contain Subject identity Information comprised only of the countryName field.
SG PKI verifies the identity of all Applicants, and the authenticity of the applicant representative's certificate request using a verification process meeting the requirements of Section 3.2.2.1.
SG PKI will inspect any document relied upon under this Section for alteration or falsification. SG PKI Root III and its Subordinated CAs do not issue certificates containing internationalized domain names (IDNs).

CPS section 3.2.2.4: Authorization by Domain Name Registrant
For each Fully-Qualified Domain Name listed in a Certificate, SG PKI confirms that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company or Affiliate, collectively referred to as “Applicant” for the purpose of this Section) either is the Domain Name Registrant or has control over the FQDN by:
- communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS records “registrant”, “technical” or “administrative” field.
- Relying upon a Domain Authorization Document approved by the Domain Name Registrant. The document MUST be dated on or after the certificate request date or used by SG PKI to verify a previously issued certificate and that the Domain Name’s WHOIS record has not been modified since the previous certificate issuance.

CPS 3.2.3 Authentication of individual identity
For individual identity authentication a smart card based on a certificate of type “Klasse B” issued under the “Swiss Government Root CA I” [20] SHALL be used. Certificates of type “Klasse B” are combining the government identity directory (AdminDir) and a qualified identification process in combination with a strong authentication token (smart card)

* EV Policy OID: 2.16.756.1.17.3.61.2

* Test Websites
Valid : https://www.valid-ev.pki.admin.ch
Revoked : https://www.revoked-ev.pki.admin.ch
Expired : https://www.expired-ev.pki.admin.ch

* CRL URLs:
http://www.pki.admin.ch/crl/RootCAIII.crl
CPS section 4.9.7.1: The value of the nextUpdate field is never more than ten days beyond the value of the thisUpdate field.

* OCSP URLs:
http://www.pki.admin.ch/aia/ocsp
CPS section 4.9.9: certificate status database, used by the OCSP service, is updated every 4 hours during office hours.

* Audit: Annual audits are performed by KPMG according to the ETSI TS 102 042 for CA and BR audit criteria.
http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf

* Forbidden or Problematic Practices
None Noted

This begins the discussion of the request from the Swiss Government is to include the “Swiss Government Root CA III” root certificate, turn on the Websites trust bit, and enable EV treatment.

Aaron

[Julien Cristau]

On Thu, Nov 2, 2017 at 9:29 AM, Aaron Wu via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> * Audit: Annual audits are performed by KPMG according to the ETSI TS 102
> 042 for CA and BR audit criteria.
> http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-
> Certification-Confirmation-2017_Final.pdf
>
>

This returns 404. Also, from the other thread, it sounded like ETSI TS
should be replaced by ETSI EN standards nowadays?

Cheers,
Julien

[Michael.vonN...@bit.admin.ch]

Hi Julien

The link got cut by a linefeed in the original post:

http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf

The annual audits are updated for the actual period. The certification confirmation is for 2017 where the audits were still performed ETSI TS.

Regards
Michael





-----Ursprüngliche Nachricht-----
Von: dev-security-policy [mailto:dev-security-policy-bounces+michael.vonniederhaeusern=bit.ad...@lists.mozilla.org] Im Auftrag von Julien Cristau via dev-security-policy
Gesendet: Donnerstag, 2. November 2017 10:03
An: Aaron Wu <a...@mozilla.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Betreff: Re: Swiss Government root inclusion request

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[wth...@gmail.com]

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 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.
- 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 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.
- 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/.
- 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.
- The CP/CPS doesn’t include the conformance statement required by BR section 2.2.
- The CP/CPS doesn’t specify how it is licensed per Mozilla policy 3.3(3).
- Section 4.1.1 of the CPS describes the enrollment process but does not mention how suspicious certificate requests are identified.
- Section 4.2.1 of the CPS does not provide any information on high risk certificate requests.
- 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.
- 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.

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.

Thanks,

Wayne

[westm...@gmail.com]

Hello Wayne,

At me the link on the pdf file is work correctly from Google Chrome ver. 49, but I cannot load this file in my post...

[Michael.vonN...@bit.admin.ch]

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 .

>> - 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.

>> - 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.

>> - 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.

>> - 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.

>> - 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


--------------

[wth...@gmail.com]

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.

[Michael.vonN...@bit.admin.ch]

Hi Wayne

> 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.

- You are referring to the comment section of #4.
The relevant section is the "check criteria".
In practice the CA will ask for an authorization letter which among others must contain the signature of the domain owner (see " Berechtigungsformular zum Bezug von SSL/TLS Zertifikaten", https://www.bit.admin.ch/adminpki/00240/00241/05913/05914/index.html).

- 2.2(3) says: " The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with."
In our opinion this does not mean that the very description has to be in CP/CPS itself.
We choose to "clearly specify the procedure " by referring to our checklist for this purpose (4.2.1).
The reference section of the CP/CPS wrongly states that this checklist is not publicly available. It is of course publicly available.

We will update this in the next revision of the CPS.

> Could you explain what a "direct contractual relationship" means?

A registration agent is identified beforehand with a NCP+ certificate and must sign a contract stating that he/she accepts the terms and conditions of the CA.
The registration agent may then use an online tool to file the registration request for a defined set of domains only.
Before further processing, the request will be checked by a CA employee against the checklist.

> 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.

We take note of your opinion.
In practice, this contact information is indeed used for problem reporting.
We therefore assume that the indication is clear enough.

> Per section 2.2 of the BRs, this was required as of 8-September.

We fully agree.

> 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.

We fully agree. Compliance is already mentioned in paragraph 8.4: "SG Root CA III is compliant to ETSI 102.042 V 2.4.1 with EV requirements and to the Guidelines and Baseline Requirements published by the CA/Browser Forum [17] [18] [19] and covers all aspects of a Web Trust certification.". We will further update the CPS with a more specific statement.

Best Regards
Michael



-----Ursprüngliche Nachricht-----
Von: dev-security-policy [mailto:dev-security-policy-bounces+michael.vonniederhaeusern=bit.ad...@lists.mozilla.org] Im Auftrag von wthayer--- via dev-security-policy
Gesendet: Mittwoch, 15. November 2017 19:56
An: mozilla-dev-s...@lists.mozilla.org

Betreff: Re: Swiss Government root inclusion request

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

[Matt Palmer]

On Thu, Nov 23, 2017 at 06:43:42AM +0000, =?utf-8?q?Michael_von_Niederh=C3=A4usern_via_dev-security-policy_=3Cd?=@lists.mozilla.org wrote:
> - 2.2(3) says: " The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with."
> In our opinion this does not mean that the very description has to be in CP/CPS itself.

Really? "The [...] CPS must clearly specify the procedure" doesn't mean the
description has to be in the CPS? I'm sorry, but your opinion is misguided
and ill-advised.

- Matt

[Michael.vonN...@bit.admin.ch]

Hi Matt

Thank you for your statement.

Let me try to clarify:

In 3.2.2.4 we specify the Authorization by Domain Name Registrant as follows:

3.2.2.4 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, SG PKI confirms that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company or Affiliate, collectively referred to as "Applicant" for the purpose of this Section) either is the Domain Name Registrant or has control over the FQDN by:
- communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS records "registrant", "technical" or "administrative" field.
- Relying upon a Domain Authorization Document approved by the Domain Name Registrant. The document MUST be dated on or after the certificate request date or used by SG PKI to verify a previously issued certificate and that the Domain Name's WHOIS record has not been modified since the previous certificate issuance.

And in paragraph 4.2 the certificate application process is described and refers in the end to the before mentioned checklist:

[...]
The validation process is detailed in a checklist for each certificate type. [25][26][27] [...]

As the checklist potentially needs to be adapted to actual threats, we chose to leave it in a separate document and refer to it in the CPS to make the check procedure transparent.
If required, we will adapt this procedure and integrate all steps into the CPS. That would make the checklist document handling less agile. I would appreciate some more input on this point from others, before we change that.

Regards
Michael



-----Ursprüngliche Nachricht-----
Von: dev-security-policy [mailto:dev-security-policy-bounces+michael.vonniederhaeusern=bit.ad...@lists.mozilla.org] Im Auftrag von Matt Palmer via dev-security-policy
Gesendet: Donnerstag, 23. November 2017 08:55
An: dev-secur...@lists.mozilla.org

Betreff: Re: Swiss Government root inclusion request

[wth...@mozilla.com]

On Thursday, November 23, 2017 at 4:03:27 AM UTC-7, Michael.vonN...@bit.admin.ch wrote:
> Hi Matt
>
> Thank you for your statement.
>
> Let me try to clarify:
>
> In 3.2.2.4 we specify the Authorization by Domain Name Registrant as follows:
>
> 3.2.2.4 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, SG PKI confirms that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company or Affiliate, collectively referred to as "Applicant" for the purpose of this Section) either is the Domain Name Registrant or has control over the FQDN by:
> - communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS records "registrant", "technical" or "administrative" field.
> - Relying upon a Domain Authorization Document approved by the Domain Name Registrant. The document MUST be dated on or after the certificate request date or used by SG PKI to verify a previously issued certificate and that the Domain Name's WHOIS record has not been modified since the previous certificate issuance.
>

The Mozilla policy requires the CPS to reference the specific BR section, so at the very least the CPS is out of compliance because it does not contain these references.

>
> And in paragraph 4.2 the certificate application process is described and refers in the end to the before mentioned checklist:
>
> [...]
> The validation process is detailed in a checklist for each certificate type. [25][26][27] [...]
>

Mozilla's Required Practices document [1] specifies more details on the amount of disclosure required for a CA's domain validation methods.

>
> As the checklist potentially needs to be adapted to actual threats, we chose to leave it in a separate document and refer to it in the CPS to make the check procedure transparent.
> If required, we will adapt this procedure and integrate all steps into the CPS. That would make the checklist document handling less agile. I would appreciate some more input on this point from others, before we change that.
>

I'm familiar with a number of CPS documents and they all include details on domain validation practices. I'm also concerned about the separate document because:
1. It was not accessible when I originally requested it (404)
2. It contains a comment that implies the use of 7 methods instead of just two as stated in the CPS
3. That comment references outdated methods including "any other"
4. It appears that the document hasn't been updated in over a year and it contains no version control information other than a date and "version 1.0"
>
> Regards
> Michael

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership

[wth...@mozilla.com]

I've placed this discussion on hold pending:

1. Updated audit statement specifying the audit period.
2. Updated CP/CPS including CAA information, BR compliance statement, and clearer specification of the domain validation procedures that are in use.

Wayne