9. Certificate Content and Profile

9.1 Issuer Information

As specified in BR Section 7.1.4.1.

9.2 Subject Information

Code Signing Certificates issued to Subscribers MUST include the following information in the fields listed:

9.2.1 Subject Alternative Name Extension

No Stipulation

9.2.2 Subject Common Name Field

Certificate Field: subject:commonName (OID 2.5.4.3)

Required/Optional: Required

Contents: This field MUST contain the Subject’s legal name as verified under BR Section 3.2.

9.2.3 Subject Domain Component Field

This field MUST not be present in a Code Signing Certificate.

9.2.4 Subject Distinguished Name Fields

a. Certificate Field: subject:organizationName (OID 2.5.4.10)

Required/Optional: Required.

Contents: The subject:organizationName field MUST contain either the Subject’s name or DBA as verified under BR Section 3.2. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”. Because subject name attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application software, the CA MAY use the subject:organizationName field to convey a natural person Subject’s name or DBA. The CA MUST have a documented process for verifying that the information included in the subject:organizationName field is not misleading to a Relying Party.

b. Certificate Field: Number and street: subject:streetAddress (OID: 2.5.4.9)

Required/Optional: Optional.

Contents: If present, the subject:streetAddress field MUST contain the Subject’s street address information as verified under BR Section 3.2.2.1 or 3.2.3.

c. Certificate Field: subject:localityName (OID: 2.5.4.7)

Required/Optional: Required if the subject:stateOrProvinceName field is absent. Optional if the subject:stateOrProvinceName field is present.

Contents: If present, the subject:localityName field MUST contain the Subject’s locality information as verified under BR Section 3.2. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with BR Section 7.1.4.2.2.g., the localityName field MAY contain the Subject’s locality and/or state or province information as verified under BR Section 3.2.2.1 or 3.2.3.

d. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)

Required/Optional: Required if the subject:localityName field is absent. Optional if thesubject:localityName field is present.

Contents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under BR Section 3.2.2.1 or 3.2.3. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with BR Section 7.1.4.2.2.g., the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under BR Section 3.2.2.3.

e. Certificate Field: subject:postalCode (OID: 2.5.4.17)

Required/Optional: Optional

Contents: If present, the subject:postalCode field MUST contain the Subject’s zip or postal information as verified under BR Section 3.2.2.1 or 3.2.3

f. Certificate Field: subject:countryName (OID: 2.5.4.6)

Required/Optional: Required

Contents: The subject:countryName MUST contain the two-letter ISO 3166-1 country code associated with the location of the Subject verified under BR Section 3.2.2.3. If a Country is not represented by an official ISO 3166-1 country code, the CA MAY specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2 code has not been assigned.

9.2.5 Reserved

9.2.6 Subject Organizational Unit Field

Certificate Field: subject:organizationalUnitName

Required/Optional: Optional.

Contents: The CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with BR Section 3.2.

9.2.7 Reserved

9.2.8 Other Subject Attributes

As specified in BR Section 7.1.4.2.2.i.

9.3 Certificate Policy Identification

This section sets forth minimum requirements for the content of the Subscriber, Subordinate CA, and Root CA Certificates, as they relate to the identification of Certificate Policy.

9.3.1 Certificate Policy Identifiers

The following Certificate Policy Identifier is reserved for use by CAs as a required means of asserting compliance with these Requirements as follows:

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) code-signing-requirements(4) code signing(1)} (2.23.140.1.4.1)

9.3.2 Root CA Requirements

A Root CA Certificate SHOULD NOT contain the certificatePolicies extension.

9.3.3Subordinate CA Certificates

A Certificate issued after the Effective Date to a Subordinate CA that is not an Affiliate of the Issuing CA:

1.MUST include the policy identifier specified in Section 9.3.1 that indicates the Subordinate CA’s adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum reserved identifiers or identifiers defined by the CA in its Certificate Policy and/or Certification Practice Statement), and

2.MUST NOT contain the “anyPolicy” identifier (2.5.29.32.0).

A Certificate issued after the Effective Date to a Subordinate CA that is an affiliate of the Issuing CA:

1.MUST include the CA/Browser Forum reserved identifier specified in Section 9.3.1 to indicate the Subordinate CA’s compliance with these Requirements, and

2.MAY contain the “anyPolicy” identifier (2.5.29.32.0) in place of an explicit policy identifier.

A Subordinate CA MUST represent, in its Certificate Policy and/or Certification Practice Statement, that all Certificates containing a policy identifier indicating compliance with these Requirements are issued and managed in accordance with these Requirements.

9.3.4 Subscriber Certificates

A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the CA, in the Certificate’s certificatePolicies extension that indicates adherence to and compliance with these Requirements. CAs complying with these Requirements MAY also assert the reserved policy OIDs in such Certificates.

The CA MUST document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Requirements.

9.4 Maximum Validity Period

Subscribers and Signing Authorities MAY sign Code at any point in the development or distribution process. Code Signatures may be verified at any time, including during download, unpacking, installation, reinstallation, or execution, or during a forensic investigation.

The validity period for a Code Signing Certificate issued to a Subscriber or Signing Service MUST NOT exceed 39 months.

The Timestamp Authority MUST use a new Timestamp Certificate with a new private key no later than every 15 months to minimize the impact to users in the event that a Timestamp Certificate's private key is compromised. The validity for a Time Stamp Certificate must not exceed 135 months. The Timestamp Certificate MUST meet the "Minimum Cryptographic Algorithm and Key Size Requirements" in Appendix A for the communicated time period.

9.5 Subscriber Public Key

The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Appendix A or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys).

9.6 Certificate Serial Number

As specified in BR Section 7.1.

9.7 Reserved

9.8 Reserved