Exportar (0) Imprimir
Expandir Tudo
EN
Este conteúdo não está disponível em seu idioma, mas aqui está a versão em inglês.

Microsoft Root Certificate Program

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated: January 15, 2009

This document lists the details and requirements for the Microsoft Root Certificate Program ("Program"). Certification Authorities ("CAs") that are current members of the Program are listed at http://support.microsoft.com/kb/931125 .

On This Page

Introduction
How Root Certificate Distribution Works
General Requirements
Technical Requirements
Government CAs
Extended Validation (EV) CAs
Code Signing Certificates
Exclusions from the Program
How to Apply
Annual Renewal
In the Event of Algorithm Attacks that Affect Root Certificates
Frequently Asked Questions

Introduction

The Microsoft Root Certificate Program supports the distribution of root certificates, enabling trust among Windows clients. To date, Microsoft has approved nearly one hundred commercial and government CAs for participation in the Program. This page describes the terms for participation and will help new CAs get started to apply to the Program.

How Root Certificate Distribution Works

Root certificates are updated on Windows Vista automatically. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate. If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes.

Root certificates are also delivered for Windows XP and earlier via the Microsoft Update Catalog. Visitors to the Catalog can search on “root update” or the KB article for the Root Certificate Program, “KB931125”, and download the latest Root Update package. Root Updates are cumulative, so it should only be necessary to install the latest one to receive all root certificates in the Program.

Whether a user, or “relying party”, should trust a root certificate for any particular purpose can be a difficult question. CAs must be on guard against issuing certificates to people who put them to bad use, such as signing malicious software to make it seem more acceptable. CAs should have effective revocation policies and procedures to adequately deal with such certificates. Also, users are expected to scan a CA’s Certificate Practice Statement (CPS) before deciding to trust a certificate - to ensure that acceptance would not cause undue risk to a user’s security, for example. Such documents can be hundreds of pages long though, making user trust decisions complex. Microsoft’s role is to assess CAs and qualify them according to the Program requirements before enabling distribution of their root certificates. We rely upon the judgment of qualified assessors who have themselves been inside the doors of a CA and audited them against publicly available criteria. While our scope of review is relatively narrow and confined to parameters we can verify in advance, our intention is to help customers make difficult trust decisions.

General Requirements

  1. The CA must provide the information requested below (see Step 1. Contact Microsoft), and receive preliminary approval for membership in the Program.

  2. The CA must provide a test certificate issued from the CA’s root certificate for testing purposes. Optionally, a CA can provide to Microsoft a URL of a publicly accessible server where certificates issued from their root certificate can be verified. (See FAQ for details)

  3. The CA must complete a Microsoft CA Agreement. The agreement will be provided only after you have completed Step 1 of the application process and received preliminary approval of your application.

  4. Root certificates must comply with the Technical Requirements section below. In particular, we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. We prefer that new roots are valid for at least 8 years from date of submission but expire before the year 2030, especially if they have a 2048-bit RSA modulus.

  5. Certificates issued from a root certificate must support the CRL distribution point extension. The CRL distribution point should point to a location that is publicly accessible.

  6. The CA must have a documented revocation policy, and the CA should be able to revoke any certificate they issue.

  7. The CA must complete an audit and submit audit results to Microsoft every twelve (12) months. The Audit must cover the full PKI hierarchy that will be enabled by Microsoft through the assignment of Extended Key Usages (EKUs). All certificate usages that we enable must be audited periodically. The audit report must document the full scope of the PKI hierarchy including any sub-CA that issues a specific type of certificate covered by an audit. Eligible audits include:

These are the accepted audits at this time for non-government CAs. We reserve the right to change the audits listed above and/or accept other comparable audits in the future.

Technical Requirements

New root certificates must meet the following technical requirements:

  1. Root certificates must be x.509 v3 certificates.

  2. Subject Name must contain a meaningful name of the CA (ex. cannot be “Root” or “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:

    • RSA greater or equal to 2048-bit modulus

    • ECC greater 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. Intermediate CA certificates are excluded from the Root CA Program (See Frequently Asked Questions for more information)

  9. 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.

  10. Existing (“legacy”) 1024-bit RSA root certificates may remain in distribution by the Program until the NIST deadline of December 31, 2010, except as provided by Microsoft.

  11. The CA may issue 1024-bit RSA certificates from root certificates distributed by the Program until the NIST deadline of December 31, 2010.

Government CAs

Increasingly national and regional governments are establishing Certification Authorities intended primarily for government to government or citizen to government (e-government) transactions. These government CAs may be actual government entities, or private parties operating according to a government Certification Practice Statement (“CPS”). Government CAs must meet all the General and Technical Requirements for inclusion in the Program with the exception of audit. Microsoft may accept the following audit equivalency from government CAs.

Audit equivalency – for government CAs who issue certificates to secure government to government or citizen to government transactions, Microsoft will accept a statement from a government or private party auditor attesting to the CA’s audit status, giving the name of and reference to their audit guidelines, the date of the last audit, and equivalence of their audit criteria to the Operating Standards (e.g. WebTrust For CAs, ETSI TS 102 042, ETSI 101 456, ISO 21188).

Extended Validation (EV) CAs

CAs have begun to issue a new, enhanced type of digital certificate known as Extended Validation (“EV”) certificates. Microsoft will mark a root certificate for issuance of EV digital certificates only when a Program-eligible CA has completed a qualified EV audit. Currently the only qualified EV audit is the WebTrust for CAs – WebTrust Extended Validation Criteria from a licensed WebTrust auditor. The WebTrust for CAs EV audit necessarily requires successful completion of a base audit as well. See General Requirements, above.

Code Signing Certificates

If a CA requests application of the code signing EKU to their root certificate, a supplementary agreement to the Root CA agreement may be required, covering the following requirements.

  1. In the subscriber agreement the CA should require of the applicant or subscriber that the application details they provide be truthful, accurate, and not misleading, (application name, information URL, and application description). The subject also must be identified by a verified organization name. Failure by a subscriber to comply, or to promptly correct inaccurate information should result in revocation of the code signing certificate.

  2. In the subscriber agreement the CA should give notice that they will revoke certificates issued to subscribers who use it to digitally sign hostile code, including spyware or other malicious software (malware) downloaded without user consent.

Exclusions from the Program

Microsoft includes in this Program CAs from all regions, regardless of relative size or market share. However, we currently exclude any of the following types of CAs from the Program:

  • Enterprise CAs: root certificates that are used internally within an organization or among partners (ex. large enterprises and businesses) are not accepted in the Program.

  • CA certificate usages must be public, meaning that the CA must issue certificates with approved usages to members of the public.

  • CAs who fail an audit, who fail to submit required audit results to Microsoft, or otherwise don’t meet the General or Technical Requirements.

  • CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers.

These are the current Program exclusions. We will give consideration to CAs addressing legitimate customer needs that may fall outside these guidelines, however. See the FAQ for some discussion of the issues we face and our philosophy for change. We reserve the right to change the exclusions listed above at any time in response to the needs of the Program.

How to Apply

We recommend that CAs applying for the Program complete these steps in order:

  1. Contact Microsoft. To begin the Program application process, send an email with the following information to casubmit@microsoft.com:

    • Company name and address

    • Company Web page address (URL)

    • Two contacts from your organization (first and last name, e-mail address, and phone number)

    • Number of roots you would like to submit – maximum of three (3). Up to three roots per CA can be accepted into the Program because each additional root negatively impacts users by increasing download time.

    • Please answer the following questions about your root certificates:

      • What is the business purpose of the certificates issued from the root certificate(s)?

      • To whom will you issue certificates? For example, to the general public, or to members of a certain organization (please specify).

      • What Extended Key Usage does the root require? For example, SSL server or client authentication, secure email, or code signing (See the FAQ for EKUs that are allowed and not allowed by the Program).

      • What is done to validate the identity of someone requesting a certificate you issue?

    • Provide a pointer to your Certification Practices Statement (URL).

    • List any third-party audits your CA practice has undergone.

    • Please describe how the services for which your root will be used to provide broad value to Microsoft customers.

  2. Obtain Preliminary Approval of your application. Microsoft will respond to your email within a commercially reasonable timeframe after confirmation of receipt. An email will be sent with any questions or concerns, or containing a preliminary approval of your application and Next Steps to join the Program.

  3. Engage an auditor. Engage a qualified auditor, and audit according to their assessment criteria (see General Requirements). Unless you would engage an auditor in the ordinary course of doing business, we do not recommend that you engage an auditor for purposes of joining this Program until after you have received preliminary approval of your application for membership.

  4. Complete a Microsoft CA Agreement. Complete a Microsoft CA Agreement, memorializing the above program requirements. Return two (2) signed copies (signed by a duly authorized representative of your organization) to Microsoft at the following address:

    Microsoft Root Certificate Program
    Attn: Tom Albertson
    Program Manager, Windows Security
    Bldg 9/1342
    Microsoft Corporation
    One Microsoft Way
    Redmond, WA 98052- 6399
    Ph 425-882-8080

    Microsoft will review the submitted CA Agreement and, if accepted, will counter-sign and return the Agreement to you after steps 5 and 6 below have been successfully completed.

  5. Send your Root Certificates. Send your root certificate(s) as an email attachment to Microsoft, at casubmit@microsoft.com. It is best to send .cer or .der files packaged in a .zip format to avoid Microsoft’s mail filters.

  6. Publication of roots via Windows Update. Microsoft will distribute new Root Updates on a regular basis, typically 3-4 times per year, or as necessary to ensure distribution of the root certificates. Root certificates accepted by Microsoft are made available to Windows Vista and Windows XP clients through Windows Update and the Microsoft Update Catalog.

Annual Renewal

Microsoft will endeavor to contact each CA approximately three (3) months prior to expiration of the twelve (12) month period after their participation in the Program commences. Remember that participation in the Program requires annual renewal of the following:

  • CA must complete a qualified audit and submit the audit report to Microsoft every twelve (12) months.

  • CA must complete or extend a Microsoft CA Agreement, as necessary.

CAs are responsible to perform a qualified audit of their operations in a timely manner regardless whether Microsoft contacts them as described here.

In the Event of Algorithm Attacks that Affect Root Certificates[NEW January 15, 2009]

In light of recent progress in mounting MD5 collision attacks against MD5 certificates, we have advised Certificate Authorities who are members of the Program to stop issuing MD2, MD4 or MD5 certificates from any root certificate distributed by the Program, effective immediately. We have also advised them to transition their subordinate and end-certificates to 2048-bit RSA certificates, and to complete this transition for any root certificate distributed by the Program no later than December 31, 2010. And we have clarified the Program Technical Requirements to state that we will remove 1024-bit root certificates from distribution by the Program no later than December 31, 2010, except as provided by Microsoft.

In this section we outline Microsoft’s contingency plan for removing affected 1024-bit or 2048-bit RSA root certificates from distribution, in the event of a practical factoring attack against 1024-bit RSA keys; a practical collision attack against SHA-1 certificates; and continued MD5 collision attacks. Microsoft is not aware of any specific attack against RSA, MD5 or SHA algorithms, but the MD5 collision attack shows significant interest in compromising these algorithms. We want Microsoft’s mitigation strategy against such attacks to be as transparent as possible, for the benefit of Program CA members and Windows users in general.

In the event of a 1024-bit RSA compromise attack

The compromise of 1024-bit RSA will affect end entity and subordinate CA certificates, in addition to root certificates. NIST had provided public guidance not to rely on 1024-bit RSA after December 31, 2010. Our primary strategy is to ask CAs to move away from 1024-bit certificates and onto 2048-bit RSA or stronger certificates as quickly as possible, but in no case later than NIST guidance. For CAs that still rely on 1024-bit RSA certificates at the time of a 1024-bit RSA compromise attack, their businesses may be disrupted.

In the event of a successful compromise of 1024-bit RSA, we will follow this process:

  1. Assess root certificates in the Program for vulnerability to the specific attack.
  2. Contact affected CAs and inform them of the attack and its projected consequences for their root certificates. Likely this will include information on Microsoft’s intention to remove affected root certificates from distribution, and the tentative schedule to do so.
  3. Remove all affected root certificates from distribution by the Program within one month maximum.
    • 1024-bit RSA root certificates will be removed from distribution by the Program, effectively immediately. We will use the Windows Update mechanism to update these certificates with 2048-bit root certificates, if available.
    • 2048-bit RSA or ECC equivalent root certificates that have issued 1024-bit RSA certificates may also be affected by a 1024-bit RSA attack. We will need to know if the CA has begun the process to revoke all affected certificates. The CA must be able to give us a date when all 1024-bit RSA certificates will be revoked – this should be accomplished within one month maximum. Otherwise, the 2048-bit RSA root certificate may be removed as well.
  4. Communications are vital during an attack of this nature. If we cannot confirm contact with any CA within 72 hours of a public disclosure of a 1024-bit RSA compromise, we may make the assumption of disinterest, and remove affected root certificates, regardless of our records of the strength of their root key. For Microsoft’s part, unless specifically advised by Microsoft of an alternate point of contact, the point of outside contact during a compromise is casubmit@microsoft.com.

In the event of a SHA-1 collision attack

Given the recent success of the MD-5 collision attacks, it is not inconceivable to anticipate a future successful collision attack against SHA-1 before CAs can retire their SHA-1 root certificates. In the event of a SHA-1 compromise, CAs will have two options, either:

  1. Ensure that all new certificates will contain a large random serial number, or
  2. Switch to SHA-2 root certificates immediately.

Microsoft will use the process defined for 1024-bit RSA compromise attacks to assess certificates for vulnerabilities, contact affected CAs, then remove vulnerable certificates and distribute new ones.

In the event of an imminent MD5 pre-image attack

Microsoft may update Windows to reject all MD2, MD4 or MD5 end-entity and subordinate CA certificates when it has reasons to believe that successful MD5 pre-image attacks are imminent. In such an event, Microsoft will use the process defined for 1024-bit RSA compromise attacks to assess certificates for vulnerabilities, contact affected CAs, then modify Windows to reject vulnerable certificates.

Frequently Asked Questions

  • How much does the program cost?

    Microsoft does not currently charge for the Root Certificate Program. However, there is a material cost to CAs payable to an assessor associated with meeting the annual audit requirements. The CA is solely responsible for, and shall bear all financial and other costs and obligations associated with, meeting the requirements of the Program.

  • How can I establish the equivalency of my audit / auditor to WebTrust or ETSI?

    The burden is on the CA to establish audit equivalency. Typically we do not accept audit equivalency except from government CAs. In the case of government CAs, we may accept a statement of equivalency from their auditor, documenting where the audit meets, exceeds or falls short of eligible audit criteria.

    Audits are an obligatory part of the Program, and it’s also the area where our requirements can be the most adaptable. The CA industry is relatively new, laws can vary, and few audits exist specifically to validate a CA’s typical PKI operations. Over time we have expanded our list of accepted CA audits to include ETSI 102 042, ETSI 101 456, WebTrust for CAs, WebTrust EV Readiness audits, and ISO 21188. We also recognize a statement of audit equivalency from a government CA or from a private party operating according to a government designated CPS.

    At the moment we do not accept an ISO 27001 certification primarily because it is not focused on CA operations. But we intend to investigate ISO 27001 in the future, and if you have any additional information on its use to evaluate CA PKIs in particular we would appreciate hearing about it. Until our requirements change, if you have an interest in participating in our Program we recommend that you contact your auditor to pursue one of the other audits.

  • What is the deadline for submitting my root certificate?

    Microsoft will accept root certificates on an on-going basis, so there is no hard deadline. We publish the Root Update 3-4 times per year on what is known as the Windows Update Non-Security refresh schedule, which releases on the 4th Tuesday of the month. The Root Update is due to Windows Update near the beginning of the month, and we need at least 2 weeks time to test the Root Update package before that. Generally speaking when we anticipate a Root Distribution in the following month (January), CAs should be approved and have all materials at Microsoft by the 15th of the previous month (December). However, Microsoft cannot guarantee distribution of a Root Update on a regular schedule or in a specific month, as Windows Update may cancel non-security refresh releases on short notice in order to prepare for update releases that require additional attention.

    CAs who have received preliminary approval for membership will be kept advised of upcoming deadlines for distribution. If you have a specific release deadline for your root certificate, talk to us, and we will do what we can to help you meet it. As it is with many things, much can be accomplished with communication and preparation. Microsoft will use commercially reasonable efforts to accommodate a CA’s start date for root availability via Windows Update; however, Microsoft makes no representations, warranties, guarantees or other promises with respect to the actual date of availability on Windows Update or the Microsoft Update Catalog.

  • What is meant by “how the services for which your root will be used provide broad value to Microsoft customers”?

    Roughly speaking, it means the benefits to including the root certificate outweigh any risks to Microsoft customers. Among potential benefits include alignment of a CA’s certificate issuance with Microsoft strategies.

  • What is meant by “the Audit must cover the full PKI hierarchy that will be enabled by Microsoft through the assignment of Extended Key Usages (EKUs)?”

    All certificate usages that we enable via the Program must be audited. The audit report must document the full scope of the PKI hierarchy, including any sub-CA that issues a specific type of certificate covered by an audit. This audit requirement holds the CA accountable for their certificate usages, nothing more. In the past, CAs might produce audit reports covering only a chosen part of their PKI, while we would be asked to enable their root certificate for a number of unaudited usages. Going forward, if a CA wants to be enabled for [code signing], they must be audited for [code signing]. Same for client and server authentication (SSL) and S/MIME.

    This lack of an audit was also reflected in revocation policies: some CAs might neglect to define revocation policies for certain certificate usages, leaving their subscribers and relying parties uncertain as to their actual responsibilities after they issue a certificate. Going forward, CAs must have revocation policies in their Subscriber Agreements that clearly cover the EKUs that they specify for their root certificates. Every certificate policy must include a revocation policy. We will seek evidence of revocation policies during annual audits, and rely on those audits to determine which EKUs we will apply to the root certificates.

    We believe this is a reasonable audit requirement, in that under most any regulatory framework a PKI is not allowed to function without that aspect of its usage being audited.

  • What is meant by “the CA must have clear policy and be able to revoke any certificate they have issued?” How will you monitor this?

    CAs must have revocation policies in their Subscriber Agreements that clearly cover the EKUs that they specify for their root certificates. Every certificate policy must include a revocation policy. We will seek evidence of revocation policies during annual audits.

  • Can you explain some more about issuing test certificates as part of the application process? Our certificate policy for the root certificate does not allow us to issue test certificates.

    We don’t exhaustively test certificates for compatibility with Windows, but a test certificate is used to verify the automatic root update feature on Windows XP and later. If permitted by a CA’s CPS, the test certificate should be issued under the production root hierarchy, and the certificate chain should be sent to Microsoft. Optionally, a CA can provide an HTTPS URL which we can connect to during test and verify proper chaining to the root certificate.

  • Why won’t you distribute my intermediate root CAs? I have problems building chains to my root certificate without them.

    The Program is responsible for updating root certificates only. Intermediate certificates included in Windows today are purely for legacy reasons. Managing the distribution of intermediate certificates for all CAs in the root program is not scalable since CAs frequently add and remove intermediate CAs for business and lifecycle reasons. Generally intermediate CA certificates can be distributed in two ways:

    • PKI applications such as SSL, S/MIME, and Microsoft Authenticode always send the intermediate CA certificates with the end certificate to facilitate intermediate certificate distribution. This is the preferred solution.

    • The CA has the option to specify a URL in a certificate via the Authority Information Access extension (RFC 3280) that serves as a hint to Windows CryptoAPI to download the issuer certificate. Most CAs today issue certificates with the AIA extension to enable issuer certificate discovery.

  • I have more than three roots certificates I would like considered for distribution in the Program, how can I get them in?

    Generally you cannot have more than three roots per CA in the Program, except for root rollover or legacy situations. CAs submitting multiple roots must justify why each additional root is necessary – such as, it was created to accommodate specific government regulations, a legacy deployment, access control requirements etc. We will accept any additional certificates beyond three roots as a ‘rollover root’ (intended to replace an existing root certificate) provided we can agree on a date for removal of the legacy root. Generally we will work together with CAs on these dates, but we expect to remove expired root certificates 6-12 months after expiration and an existing root certificate 6-12 months after we begin to distribute a rollover root certificate.

  • Why must I specify EKUs for my roots?

    The intent of the Program is to enable PKI scenarios for the mass consumer market such as e-commerce, secure e-mail, and code signing. It is not intended to enable enterprise-only scenarios.

    EKUs in Windows are inherited from the root certificate down to the end entity certificate. This ensures certificates issued by any CA under this root can only be used for the stated list of usages.

    We will attach EKU metadata to the certificate as metadata in the Windows certificate store so you do not need to regenerate your root certificate with the EKU extension.

What EKUs are allowed?

The following is a list of allowed EKUs. Other EKUs may be granted if the applicant is able to provide justification:

  • Server Authentication =1.3.6.1.5.5.7.3.1

  • Client Authentication =1.3.6.1.5.5.7.3.2

  • Secure E-mail EKU=1.3.6.1.5.5.7.3.4

  • Code Signing EKU=1.3.6.1.5.5.7.3.3

  • Time stamping EKU=1.3.6.1.5.5.7.3.8

  • OCSP EKU=1.3.6.1.5.5.7.3.9

  • Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4

  • IPSec (Tunnel, User) EKU=1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

What EKUs are typically not allowed?

The following EKUs do not fit the Program criteria or are no longer necessary:

  • Smart card logon

  • Digital rights

    • This EKU is obsolete. Windows Media DRM uses it own XML format for licenses and does not use X.509.

  • Qualified subordination

    • This EKU is obsolete and is ignored by Windows.

  • Key recovery

    • Enterprise CA scenario.

  • File recovery

    • This EKU is obsolete and is ignored by the Windows Encrypting File System (EFS).

  • All application policies

    • We cannot grant “all usages” since this necessarily admits enterprise-only and other unacceptable EKUs.

  • Directory service email replication

    • Enterprise scenario

  • Certificate request agent

    • Enterprise CA scenario

  • Key recovery agent

    • Enterprise CA scenario

  • CA encryption certificate

    • Enterprise CA scenario

  • Is there a maximum number of roots that can be included in the Program? May there come a time when you don’t accept any more root certificates?

    Yes. Increasing the number of root certificates made available through this Program can negatively affect Windows performance, since all root certificates are decoded into memory in every process that uses certificates. Actual performance degradation may differ based on version of Windows and type of hardware, but we consider the long-term impact of every decision to incorporate new root certificates, and new classes of CAs. We have not approached the number of root certificates where performance might be impacted, but we make individual application decisions with the long-term in mind. We reserve the right to make membership decisions in our sole discretion based on these criteria, and to change those criteria without notice in the event of any disruption to Windows performance.

  • Also, every additional root certificate increases the risk of a key compromise or bad certificates due to CA error for hundreds of millions of Windows users worldwide. As a result, we face increasing pressure from the worldwide security community to limit the number of root certificates we distribute for CAs. We only accept CAs that provide value to a large percentage of Microsoft Windows users worldwide or within a country or region. Going forward, we intend to work with the PKI and audit communities on audit regimes and assessor guidelines that will improve CA practices and justify our decision to admit additional CAs.

What is the significance of the MD5 collision attack?(January 2009)


In late December 2008, research was published at a security conference proving a successful attack against X.509 digital certificates signed using the MD5 hashing algorithm. This attack method could allow an attacker to generate additional digital certificates with different content that have the same digital signature as an original certificate. The MD5 algorithm had been shown to be vulnerable, but a practical attack had not been demonstrated. Microsoft is not aware of any active attacks using this issue and is actively working with certificate authorities to ensure they are aware of this new research, and encourages them to migrate to the newer SHA-1 and SHA-2 algorithms.

  • For how long will you distribute legacy 1024-bit RSA root certificates?(January 2009)

    In most cases, we will continue to distribute legacy 1024-bit RSA root certificates until the NIST deadline of December 31, 2010. However we may also move 1024-bit RSA root certificates in the event of an algorithm attack that threatens the root certificate. We may also continue to distribute 1024-bit RSA root certificates at the CA’s request past the NIST deadline, as long as there are unexpired end-certificates that rely on them and there are no attacks that threaten the root certificate. This is subject to several important conditions.

    Microsoft has not accepted for several years now any new 1024-bit RSA root certificate for distribution, but there remain a number of 1024-bit root certificates in distribution that are commonly used to secure websites. We stopped accepting new 1024-bit root certificates on the advice of NIST 800-57, which recommends discontinuing reliance on 1024-bit RSA keys and certificates no later than December 31, 2010. All versions of Microsoft Windows released since 1996 support 2048-bit RSA or greater. All root certificates accepted into the Program in recent years have been 2048-bit RSA or 4096-bit RSA or ECC equivalent, and are good for distribution according to current NIST guidance until at least 2030. In most cases, we will continue to distribute legacy 1024-bit root certificates past the NIST deadline as long as there are unexpired end-certificates that rely on them, subject to three important conditions:

    • No new certificates are issued with MD2, MD4 or MD5 either by the root CA, or any subordinate CA under the root.
    • The CA discontinues issuing 1024-bit RSA certificates from the root certificate, no later than the NIST deadline of December 31, 2010.
    • The period before a relying end-certificate expires is not unreasonably long, given the fact that 1024-bit RSA is no longer recommended after December 31, 2010.
    • Most importantly, there are no successful attacks against 1024-bit RSA, or against MD5, which is utilized by a subset of 1024-bit RSA root certificates.

CAs may request and receive extensions of the December 31, 2010 deadline for 1024-bit root certificate removal provided they meet these conditions. Microsoft may assign a different certificate removal date that does not take into account the expiration of any or all certificates. In particular, Microsoft reserves the right to remove any root certificate if it becomes insecure, such as in the event of a successful algorithm attack. Particularly in cases where the CA has requested that they receive an extension of the period for distribution of their 1024-bit RSA root certificate, the CA must be aware that in the event of a 1024-bit compromise attack, the root certificate will be subject to automatic removal from distribution regardless of the number of relying subordinate and end-entity certificates. CAs that are members of the Program are advised to begin their transition to issuing 2048-bit end-certificates now, and to make the transition to 2048-bit RSA certificate chains complete no later than the NIST deadline, December 31, 2010. CAs should consider transitioning to 2048-bit certificates even earlier, as it would reduce the risk to their operations and their customers in the event of a successful attack on 1024-bit RSA. We will consider other dates both before and after the NIST deadline; however any request for a date after the NIST deadline must be supported with information on the type and the number of relying subordinate and end-certificates that will be time-valid and may require support.

Example 1: a 1024-bit RSA root certificate expires on Jan 1, 2018. Microsoft will assign a default root certificate removal date of December 31, 2010, the NIST deadline. If notified by a CA that they have issued 2 year end-certificates right up to the end of the NIST deadline of December 31, 2010, the CA may request and we will assign a root certificate removal date of December 31, 2012, to allow end-certificates that rely on the root certificate to expire. If notified by a CA that their last time valid end-certificate expires before that date, we will assign a root certificate removal date that corresponds to that end-certificate expiration date.

Example 2: a 1024-bit RSA root certificate expires on Jan 1, 2009. Microsoft will assign a default root certificate removal date of December 31, 2010, the NIST deadline. If notified by a CA that they have issued 2 year end-certificates right up to the expiration of the root certificate on Jan 1, 2009, the CA may request and we will assign a root certificate removal date of Jan 1, 2011, to allow end-certificates that rely on the root certificate to expire. If notified by a CA that their last time valid end-certificate expires before that date, we will assign a root certificate removal date that corresponds to that end-certificate expiration date.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft