360 Browser Root Certificate Program
360 is a security company in China and has always been working on the secure development of the Internet.
Over the last years, the Internet environment has become increasingly complex. With the rapid development of the Internet Infrastructure and the web, certificates management are more and more a burden to the Public Key Infrastructure (PKI) and digital certificate security issues are drawing more and more concerns worldwide. Web Browser vendors are facing this situation. The users only focus on the content of the web pages, but know little about what is going on behind the scenes.
Newly generated and revoked certificates from each CA everyday have increased to a considerable amount while overissue, misissuance and unconscious trust happen from time to time. Certificate’s reliability and authenticity cannot be effectively validated. In order to address these issues, CAs have implemented some methods for a better management, but sometimes is difficult to rely on them, meaning that there are still unresolved security issues related to certificates management. In order to enhance our ability to respond to these issues, by improving the efficiency of problem processing, reducing the risk cycle and clearly identifying that a certificate of a website is issued by a specific CA to help users identify trusted certificates for security reasons, 360 has decided to establish its own Root Certificate Program.
Usually 360 browsers trust the root CA certificates from the store of the underlying operating system but now will configure its own root store. 360 reserves the right to remove any certificate.
360 Browser Root Certificate Program is primarily intended for 360 browsers.
360 Browser CA Policy
- - Introduction
This is the official 360 Browser CA Policy. This policy is intended initially for end user certificates issued by CAs and used by web servers for SSL/TLS authentication.
360 representatives will maintain this policy and will evaluate new requests from CAs. 360 reserves the right to make changes to this policy at any time
360 will decide which CA certificates are included in this program independently of those accepted in the underlying operating system. For this reason it also reserves the right to not include a CA in this program or to remove it.
360 will not charge any fee for including a CA’s certificates in this program.
- - Certification Authorities (CAs)
This section refers to technical implementations.
All CAs must:
- That for any root CA certificate to be include in 360 root store, the expiration date at the date of submission must be more than 8 years.
- Have root CA certificates which validity time no more than 25 years after the date of submission.
- Ensure that all the subordinate CA certificates and end entity certificates are issued in accordance with the CA/Browser Forum Baseline Requirements and/or EV guidelines.
- Ensure that subordinate CA certificates no longer sign 1024 bits and use SHA-1 algorithm.
- Have the Extended Key Usage (EKU) in the subordinate CA certificates as defined by the CA/Browser Forum Baseline requirements
- Revoke a certificate according to the CA/Browser Forum Baseline Requirements. Maintain an online 24x7 repository that 360 can use to automatically check the current status of all unexpired certificates issued by the CA.
- Secure the networks and operations by conforming to the CA/Browser Forum Network Security Guidelines or a similar document.
- Enforce multi-factor authentication for all accounts capable of causing certificate issuance or implement similar technical controls operated by the CA.
- Comply with the RFC 6844 related to the CAA and indicate how they manage it.
All end user certificates must:
- Contain valid OCSP, AIA and CRL URLs, and appropriate OIDs as defined by the CA/Browser Forum documents.
- Verify that all of the information that is included remains current and with a correct validity period, this is 825 days or less
- - Documentation
This section refers to the CPS (Certification Practice Statement) and CP (Certificate Policy) documents that every CA shall have and maintain. Also, all the audit information provided by the auditor.
All CAs must:
- Maintain its own CP/CPS and ensure that they are disclosed in a 7 X 24 available online mechanism.
- Ensure that the CP/CPS is in conformance with the latest version of CA/Browser Forum Baseline Requirements.
- Submit audit reports for all the roots included in this program to 360 in an annual basis. The CAs must be audited under one of the audit schemes specified in the CA/Browser Baseline requirements or extended validation guidelines.
- Provide audits covering all the subordinate CA certificates and cross-signed certificates signed by the CA, indicating the whole hierarchy.
- Assign an official contact and provide detailed contact information to 360.
- Notify 360 at least 30 days in advance when the ownership control of the CA’s certificate(s) changes, or when ownership control of the CA’s operations changes.
- Notify 360 within 24 hours when a serious security issue like root compromise, infrastructure fault or misissuance occurs and provide an incident report to 360.
- Ensure that the CP/CPS clearly specify the procedure(s) that the CA employs to verify all the information contained in the end user certificate according to subsection 184.108.40.206 of the CA/Browser Forum Baseline Requirements.
360 Browser Root Inclusion Process
The 360 Browser Root Inclusion Process consists of 5 phases, related to CA root inclusion request, information verification, decision on inclusion, code change for inclusion and testing and formal approval.
In order for a root certificate to be included, the CA must conform to the 360 Browser CA Policy
and provide all the documentation required. 360 representatives will review this documentation.
CA root inclusion request
- The organization that is applying for the inclusion must be a legal Certification Authority in its country.
- The CA root inclusion request must be filed in the name of the organization. An official representative of the CA must submit and participate in the root inclusion request, communicate with 360 representatives to address any issues.
- The CA representative will send an email with all the necessary information to 360 to submit a formal request.
- The CA must complete the CA Information Form, which includes general information about the CA, technical information about each root certificate, CA hierarchy information for each root certificate and information about policies and practices.
- The CA shall be sure that all documentation and audit reports meet the requirements in CA/Browser Forum Baseline Requirements.
- 360 will assign a representative to review and verify the information submitted by the CA. 360 may ask for additional information if it is needed. The duration of this phase depends on the completeness of the information provided and the CA’s responsiveness in providing further information when asked for it.
- Review the root certificate to make sure that it is provided in accordance with the CA/Browser Forum Baseline Requirements and applicable CRL, AIA and OCSP services are running accordingly.
- Review the CP/CPS provided by the CA to ensure it is in conformance with the current version of Baseline Requirements, regularly updated and 24 x 7 online available.
- Review the audit documents to make sure that meet the 360 Browser CA Policy.
- For those requests to enable EV issuance, 360 will check all practices to ensure that they are in conformance with the CA/Browser Forum’s EV Guidelines.
- When in this stage, the submitted information is unclear or in doubt, 360 may ask for additional information or clarification.
Decision on inclusion
- If there are no open issues, and there is general agreement that you comply with 360 policy requirements, then 360 will move the request into the Decision on Inclusion Phase.
- The representative of 360 Browser Root Certificate Inclusion Program reserves the right to make the final decision on a root inclusion request.
- If the request is not approved, 360 will list all the items that need to be improved for the CA to make the necessary changes.
- If the request is approved, 360 will confirm the approval and move into the next phase.
Code change for inclusion and testing
- This phase is generally completed within 1 to 2 months, and the duration of the testing depends on how quickly the issues found in the process can be resolved.
- After the completion of the testing, 360 will confirm the success and the CA will need to wait for the formal inclusion of the root into the 360 Trusted Root Store.
- After the testing, 360 will formally trust the root which the CA requests for inclusion, and will include it into the 360 Trusted Root Store in the next release.
360 Trusted Root Certificates