Return to Windows Root Certificate Program Main Page
Last Updated: April 6, 2011
April 6, 2011 - Added a new Section F Certification Authority Practices
A Note on Implementation of the Requirement to Issue Longer Key Length Certificates December 7 2010
New root certificates must meet the following technical requirements:
A. Root Certificate Requirements
Root certificates must be x.509 v3 certificates.
Subject Name must contain a meaningful name of the CA (cannot be “CA1”)
Basic Constraints extension: cA=true
Key Usage (if present): keyCertSign and cRLSign only
Root Key Sizes requirements are based on NIST SP 800-57:
a. RSA greater than or equal to 2048-bit modulus
b. ECC greater than or equal to P256 modulus
Hash algorithm must be at least SHA1. No MD2, MD4 or MD5 hashes accepted.
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.
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)
From January 1, 2011, CAs must issue 2048-bit RSA or equivalent intermediate and end-entity certificates.
a. The CA may issue 1024-bit RSA end-entity certificates from root certificates distributed by the Program until December 31, 2010.
b. 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.
Issued 1024-bit RSA intermediate and end-entity certificates must expire by December 31, 2013.
a. 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.
b. 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.
c. 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)
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.
a. 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.
b. By SerialNumber field, Microsoft does not refer to the serial number component of the subject name, identified by OID 18.104.22.168.
c. The random number must appear before all other fields in the Subject Name.
d. The random or pseudo-random number generator must be provided by an operating system or by a hardware crypto module.
e. 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)
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.
CAs should make SHA2 end-entity certificates available on request to customers after December 31, 2011.
a. SHA2 end-entity certificates must be issued from SHA2 intermediate certificates. SHA2 intermediate and end-entity certificates may be issued from SHA1 root certificates.
b. 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.
Return to the Microsoft Root Certificate Program Main Page