Huawei Root Certificate Program

1. Purpose
2. Requirements for CAs
3. Certificate Requirements
4. Requirements for CA Operational Changes
5. Application
6. Root Store Management
7. Change History

1 Purpose

To help users identify trusted, secure certificates and prevent risks caused by certificate issuance abuse and mis-issuance, Huawei creates and maintains a root store to manage Huawei-trusted certification authority (CA) certificates. The CA certificates in Huawei's root store need to meet specified requirements and specifications. This document specifies the requirements and specifications for CAs and certificates.

2 Requirements for CAs

This section describes the requirements of the Huawei Root Certificate Program (HRCP) for CAs, including the certificate baseline specifications, certificate policy (CP), certification practice statement (CPS), audit requirements, and self-assessment, communication, and disclosure requirements.

2.1 Specification Requirements

• CA operations relating to issuance of certificates capable of being used for Transport Layer Security (TLS) servers must comply with the CA/Browser Forum's latest Baseline Requirements for TLS Server Certificates.
• CA operations relating to issuance of certificates capable of being used for extended validation (EV) TLS servers must comply with the CA/Browser Forum's latest EV Guidelines for TLS Server Certificates.
• CA operations relating to issuance of certificates capable of being used to sign code must comply with the CA/Browser Forum's latest Baseline Requirements for Code-Signing Certificates.
• CA operations relating to issuance of certificates capable of being used to sign EV code must comply with the CA/Browser Forum's latest EV Code Signing Certificate Guidelines.
• CA operations relating to issuance of certificates capable of being used to sign or encrypt/decrypt email messages must comply with the CA/Browser Forum's latest Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates.

If the HRCP's policy requirements are inconsistent with TLS, code signing, or Secure/Multipurpose Internet Mail Extensions (S/MIME) baseline requirements, the HRCP's policy requirements prevail.

2.2 CPs and CPSs

A CA must publicly disclose the CP and CPS to ascertain that Huawei's requirements are met. The requirements are as follows:

• Publicly disclosed documents must provide adequate information for Huawei to determine whether the CA complies with the HRCP.
• Publicly disclosed documents must be available from the CA's official website and be provided to Huawei.
• All CPs, CPSs, and CP/CPS combinations must be reviewed and updated at least once every 365 days, and a version record (by incrementing the version number) as well as the change history and date must be provided, even if no other changes are made to the documents.
• All CPs, CPSs, and CP/CPS combinations must be structured according to RFC 3647 and include at least each section and subsection defined in RFC 3647.
• A CA must explicitly provide descriptions to identify which CP, CPS, or CP/CPS combination applies to each of its root and intermediate certificates.
• The CA should maintain the links to all historical versions of each CP, CPS, and CP/CPS combination from the creation of included CA certificates, regardless of changes in ownership or control of such CA certificates, until the CA certificates are no longer in Huawei's root store.

2.3 Audit Requirements

A CA must provide Huawei with the evidence of a qualifying audit for its root certificate and all intermediate certificates in the public key infrastructure (PKI) chain, before the root certificate is added to Huawei's root store and thereafter on an annual basis.

2.3.1 Audit Criteria

If the audit is performed in accordance with WebTrust criteria, the following audit criteria apply:

• WebTrust: Principles and Criteria for Certification Authorities v2.2.2 or later
• WebTrust: Principles and Criteria for Certification Authorities – SSL Baseline v2.8 or later
• WebTrust: Principles and Criteria for Certification Authorities – Extended Validation SSL v1.8 or later
• WebTrust: Principles and Criteria for Certification Authorities – Code Signing Baseline Requirements v3.2 or later
• WebTrust: Principles and Criteria for Certification Authorities – S/MIME v1.0.3 or later

If the audit is performed in accordance with criteria of the European Telecommunications Standards Institute (ETSI), the following audit criteria apply:

• ETSI EN 319 411-1 V1.4.1 or later: Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements
• ETSI EN 319 411-2 V2.5.1 or later: Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates
• ETSI TS 119 411-6 V1.1.1 or later: Policy and security requirements for Trust Service Providers issuing certificates; Part 6: Requirements for Trust Service Providers issuing publicly trusted S/MIME certificates

The HRCP acknowledges WebTrust and ETSI audit criteria and provides more detailed audit requirements for different certificate uses.

The following table provides references for WebTrust audits.

The following table provides references for ETSI audits.

2.4 CA Self-assessment and Additional Audits

A CA must perform a compliance self-assessment annually. The annual self-assessment must be completed and submitted to Huawei within 92 days from the CA's earliest appearing root record "BR Audit Period End Date."

The CA should use the latest available version of the compliance self-assessment template of the Common CA Database (CCADB) and must not use a version that has been superseded by more than 90 calendar days before submission.

In necessary scenarios, Huawei may require HRCP participants to undergo additional audits. Such scenarios include the destruction of private keys for CA certificates and incident-specific remediation verification.

2.5 Incidents and Communication/Disclosure Requirements

2.5.1 Incidents

A CA's mis-issuance, procedural or operational issue, or any other form of non-compliance is classified as an incident, and the CA must report the incident to Huawei immediately after becoming aware of it.

Any matter documented in an audit as a qualification, modification opinion, or major non-conformity is also considered an incident and must have a corresponding audit report.

In response to an incident, Huawei may require the CA to submit an incident resolution plan or an audit report on the incident.

2.5.2 Communication and Disclosure Requirements

A CA must provide a contact communication matrix, including the contact person, official email address, and contact information, and ensure that the communication channel is prompt and effective.

A CA must disclose its complete PKI hierarchy to Huawei every year.

A CA must notify Huawei by sending an email to rootcaprogram@huawei.com at least 30 days before transferring the ownership of the registered root or intermediate certificate to another entity or individual.

3 Certificate Requirements

3.1 Technical Requirements

All CA certificates in the HRCP must meet specified technical requirements. If Huawei determines that a CA does not meet the following requirements, it will reject the CA.

3.1.1 Root Certificate Requirements

• Root certificates must be X.509 v3 certificates.
  1. The CN attribute must identify the publisher and must be unique.
  2. The CN attribute must use a common language in the industry and must be easy to read.
  3. Basic Constraints must be true.
  4. The KeyUsage extension must be present and must be marked critical. KeyCertSign and CRLSign must be set. If the root CA private key is used for signing Online Certificate Status Protocol (OCSP) responses, the KeyUsage extension must be set to digitalSignature.
• Certificates to be added to the root store must be self-signed root certificates.
• Newly minted root certificates must be valid for a minimum of 8 years, and a maximum of 15 years, from the date of submission.
• The 1024-bit Rivest-Shamir-Adleman (RSA) algorithm must not be used to issue certificates.
• All end-entity certificates must contain an authority information access (AIA) extension with a valid OCSP URL. These certificates may also contain a CRL distribution points (CDP) extension with a valid certificate revocation list (CRL) URL. Other types of certificates must contain either an AIA extension with a valid OCSP URL or a CDP extension with a valid CRL URL.
• The private key and subject name of each root certificate must be unique. Reusing private keys or subject names in subsequent root certificates by the same CA may result in unexpected certificate chaining issues. When generating a new root certificate, a CA must generate a new private key and apply a new subject name so that the certificate can be added to the root store.
• Root certificate usages, such as server authentication, S/MIME, and code signing, must be separated. A single intermediate certificate must not combine server authentication with the S/MIME or code signing usage. A separate intermediate certificate must be used for each use case.
• End-entity certificates must meet the CA/Browser Forum's latest requirements for algorithm type and key size.
• The CP extension of all end-entity certificates should comply with the object identifiers (OIDs) defined by the CA/Browser Forum's Baseline Requirements, and only one OID can be selected:

  a EV: 2.23.140.1.1
  b Domain Validated (DV): 2.23.140.1.2.1
  c Organization Validated (OV): 2.23.140.1.2.2
  d EV code signing: 2.23.140.1.3
  e Non-EV code signing: 2.23.140.1.4.1
  

• The Basic Constraints field of an end-entity certificate must be set to False, and the pathLenConstraint field must be absent.

3.1.2 Signature and Key Requirements

3.1.3 Intermediate Certificate Requirements

• Intermediate certificates should contain the Basic Constraints extension field, and its value must be set to True.
• Intermediate certificates must meet the following extended key usage (EKU) requirements (except for cross-certificates that share private keys with the root certificate):
  1. The EKU extension must be included.
  2. The EKU must not contain anyExtendedKeyUsage.
  3. The EKU must not contain both id-kp-serverAuth and id-kp-emailProtection.
• The extendedKeyUsage field must be set to id-kp-serverAuth or id-kp-serverAuth&id-kp-clientAuth for the intermediate certificates of the TLS server.
• The extendedKeyUsage field must be set to id-kp-serverAuth or id-kp-serverAuth&id-kp-clientAuth for the end-entity certificates of the TLS server.

3.1.4 EKU Requirements

CAs must provide a business description for all the EKUs of their root certificate. The description may be the public evidence of issuing certificates of a type or types, or a business plan demonstrating an intention to issue such certificates in the short term. Huawei supports only the following EKUs:

• Server authentication: 1.3.6.1.5.5.7.3.1
• Client authentication: 1.3.6.1.5.5.7.3.2
• Code signing: 1.3.6.1.5.5.7.3.3
• Secure email: 1.3.6.1.5.5.7.3.4

3.2 Revocation Requirements

CAs must have a formal revocation policy and revoke certificates in accordance with the CA/Browser Forum's Baseline Requirements. In addition, CAs must maintain an online 24/7 store check mechanism to check the status of all unexpired certificates they have issued. CAs that issue server authentication certificates must support OCSP responder requirements: The minimum validity period is 8 hours and the maximum validity period is 7 days. The next update must be available at least 8 hours before the current validity period expires.

All certificates issued by a root CA must support the CRL distribution point extension and/or the AIA extension with an OCSP responder URL. If a CA issues code signing certificates, it must use a time stamp authority that complies with RFC 3161 "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)."

In addition, CAs must be able to revoke certificates on a date specified by Huawei.

4 Requirements for CA Operational Changes

A CA in Huawei's root store must send an email to rootcaprogram@huawei.com 30 days in advance to notify Huawei of the following situations:

• The ownership or control of the CA's certificates changes.
• An organization other than the CA obtains control over an unconstrained intermediate certificate that is directly or indirectly chained to a certificate in Huawei's root store.
• The ownership or control of the CA's operations changes.
• There is a change in the CA's operations that may affect the CA's ability to comply with HRCP requirements.
• The CA's CP, CPS, or CP/CPS combination changes.

In addition, the CA must continue to meet HRCP requirements throughout any change. If any of the preceding situations occurs, Huawei may require an additional audit as a condition for retaining the certificates in the root store.

5 Application

CAs must meet all applicable policy requirements before submitting an application for joining the HRCP.

CA applicants fill in applications and send them to rootcaprogram@huawei.com. Huawei will review and test the applications according to the initial application time sequence, and notify the CAs of the results within the specified period.

6 Root Store Management

Changes that are motivated by a security concern, such as a root or intermediate certificate compromise, should be treated as security-sensitive, and a vulnerability disclosure must be filed in Huawei.

Huawei reserves the right to remove the certificates of a particular CA from the root store. This includes, but is not limited to, cases where Huawei believes that a CA has caused undue risks to users' security. Huawei is not obligated to explain the reasoning behind such decisions.

Huawei will disable or remove the certificates of a CA from the root store, if the CA demonstrates ongoing or egregious practices that do not maintain the expected level of service or that do not comply with the requirements of the HRCP.

If Huawei finds that a CA has knowingly or intentionally mis-issued a certificate, Huawei will take any measures it deems appropriate to protect its users, including disabling or removing the CA's certificates from Huawei's root store. The category of mis-issued certificates includes, but is not limited to, those issued to someone who should not have received them, those containing information which was not properly validated, those having incorrect technical constraints, and those using prohibited algorithms.

If a CA's actions (or failures to act) violate the HRCP, Huawei will disable or remove the CA's certificates from Huawei's root store. In addition, Huawei has the right to publicize that fact and may also alert relevant news, government, or industry organizations.

Huawei will continuously remove expired root certificates from the root store.

A CA should apply for the next-generation root certificate from Huawei at least 2 years before the current certificate expires.

For the list of certificates in Huawei root certificate store, refer to Huawei trusted root certificate list.

7 Change History