Share via

Windows Root Certificate Program - Technical Requirements version 1.1

  • Article

These Technical Requirements have been superseded by the Technical Requirements version 2.0, published November 11, 2013. 

They are provided here for information purposes only.

Latest update

Last Updated: April 6, 2011

April 6, 2011 - Added a new Section F Certification Authority Practices

Notes

A Note on Implementation of the Requirement to Issue Longer Key Length Certificates December 7 2010 

Requirements

New root certificates must meet the following technical requirements:

A.  Root Certificate Requirements

  1. Root certificates must be x.509 v3 certificates.
  2.  Subject Name must contain a meaningful name of the CA (cannot be “CA1”)
  3. Basic Constraints extension: cA=true
  4.  Key Usage (if present): keyCertSign and cRLSign only
  5.  Root Key Sizes requirements are based on NIST SP 800-57 :
    1.  RSA greater than or equal to 2048-bit modulus
    2. ECC greater than or equal to P256 modulus
  6.  Hash algorithm must be at least SHA1. No MD2, MD4 or MD5 hashes accepted.
  7.  For a root key size of greater or equal to an RSA 2048-bit modulus, root certificate must not expire until at least 8 years after submission and no later than 2030. Longer expiration may be afforded to larger root key sizes.
  8.  Existing (“legacy”) 1024-bit RSA root certificates may remain in distribution by the Program until December 31, 2010, except as provided by Microsoft.

B. Distribution of Intermediate CA certificates is excluded from this Agreement.

C.  Migration to longer key lengths (2048-bit RSA or greater)

  1. From January 1, 2011, CAs must issue 2048-bit RSA or equivalent intermediate and end-entity certificates.
    1.  The CA may issue 1024-bit RSA end-entity certificates from root certificates distributed by the Program until December 31, 2010. 
    2.  CAs issuing to smart cards or other hardware devices that are incapable of accepting 2048-bit RSA certificates may issue 1536-bit RSA or greater end-entity certificates. 
  2. Issued 1024-bit RSA intermediate and end-entity certificates must expire by December 31, 2013. 
    1.  1024-bit RSA intermediate and end-entity certificates with longer expirations will lose trust in the event it becomes necessary to revoke their root certificates on short notice. 
    2.  1024-bit RSA intermediate and end-entity certificates with expirations after 2013 are considered to have a lower value to customers than similar certificates with longer key lengths. 
    3.  CAs who issue 1024-bit intermediate and end-entity certificates with expirations beyond December 31, 2013 do so at their own peril.

D.  Additional Security for Intermediate and End-Entity Certificates (random value)

  1. For all intermediate and end-entity certificates issued after December 31, 2010, the CA must include an 8-byte random or pseudo-random value in either the Serial Number certificate field or the first component of the Subject Name certificate field.
    1.  This requirement is for all certificates signed with SHA1, and optional but recommended for certificates signed with SHA2 until SHA2 begins to show weakness to collision attacks.
    2.  By SerialNumber field, Microsoft does not refer to the serial number component of the subject name, identified by OID 2.5.4.5. 
    3. The random number must appear before all other fields in the Subject Name.
    4.  The random or pseudo-random number generator must be provided by an operating system or by a hardware crypto module.
    5.  There is also the possibility of a 3-byte random value in the Hour:Minute:Second part of the Validity Period field.  This 3-byte random value is shorter than the 8-byte value for other certificate fields, but if there is no other option to introduce a random value, it will mitigate a potential attack and will be accepted.

E.  Migration to a more secure hash algorithm (SHA2)

  1. The CA will not issue MD2, MD4 or MD5 subordinate or end-entity certificates from any root certificate distributed by the Program, effective January 15, 2009.
  2. CAs should make SHA2 end-entity certificates available on request to customers after December 31, 2011. 
    1.  SHA2 end-entity certificates must be issued from SHA2 intermediate certificates.  SHA2 intermediate and end-entity certificates may be issued from SHA1 root certificates. 
    2.  Root, intermediate and end-entity certificates based on SHA1 remain acceptable for the Program until there is a clear indication (e.g. public security vulnerability) that SHA1 is broken for pre-image attacks.

F. Certification Authority Practices (operation of certificate infrastructure) (added April 6, 2011)

Section F is introduced to collect interim Technical Requirements deemed necessary for participation of CAs in the Windows Root Certificate Program. Requirements under Section F are enforced until such a time that they may be incorporated into the audit criteria of qualified audit authorities (WebTrust, ETSI). Technical Requirements in this Section may be modified in the process of incorporation into those audit criteria.

Multifactor authentication

1. The CA will implement multi-factor authentication (ex. smartcard and password, biometric and password) for system or user accounts that can cause issuance or approval of certificates on behalf of the Program CA.

Multi-factor authentication tokens will not be left in a permanent or semi-permanent state (ex. plugged into a device that accesses the root certificate chain and enables authorization of certificates), such that the integrity of the physical security separating root certificates from the organization’s systems or authorized employees and accounts is compromised.

Offline state

2. All root certificates distributed by the Program must be maintained in an offline state – that is, root certificates may not issue end-entity certificates of any kind, except as explicitly approved from Microsoft.

There are limited scenarios for direct issuance of end-entity certificate from a root certificate: for example, special configurations may exist to provision certain types of hardware, and the CAs can account for the security of the root certificate in such scenarios. However, issuance of code signing or SSL certificates directly from an online root certificate is prohibited. Program CAs must disclose any scenario where they issue end-entity certificates directly from root certificates distributed by the Program, and receive specific approval from Microsoft.

RAs

3. Resellers and Registration Authorities (RAs) may not cause the issuance of certificates on behalf of a Program CA.

For purposes of the Program, a reseller or RA that can cause the issuance of certificates on behalf of a Program CA is in fact a sub-CA of the Program CA, and will be treated as an extension of the CA, and is subject to the same terms and conditions as the Program CA, including audit requirements by a qualified audit authority.

This is an immediate clarification on the assumed role of resellers and RAs: no RA or reseller shall cause the issuance of certificates on behalf of a Program CA. The conduct or misconduct of any sub-CA will have direct consequences for the Program CA, up to and including removal of root certificates from distribution by the Program.

For purpose of the Program, a reseller may solicit business for a Program CA, but may not approve or cause the issuance of certificates on their behalf – if they do so, they are considered a sub-CA, and will be treated as an extension of the CA (they must be audited, and their security can have ramifications for the status of the CA in the Program). An RA may validate some or all certificate assertions, but may not approve or cause the issuance of certificates on behalf of a Program CA – if they do so, they are considered a sub-CA, not an RA, and will be treated as an extension of the CA (they must be audited, and their security can have ramifications for the status of the CA in the Program).

This is not intended to impact Enterprise CAs, or third party private sub-CAs who issue certificates within domain(s) defined and controlled by technical means, private contract or other CA-driven means, for which the CA is ultimately responsible, as an extension of their CA.

Return to the Microsoft Root Certificate Program Main Page