1 Introduction

The Rights Management Public Key Infrastructure (RMS Certification Hierarchy), operated by Microsoft Corporation, is used to provide certificates and licenses to the general public engaged in the use of Rights Management in Microsoft products.

1.1 Overview

1.1.1 Certificate Practice Statement

This Certification Practice Statement (CPS) follows the topics and outline specified by the Internet Engineering Task Force (IETF) in RFC 2527 entitled "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework." This document assumes the reader is familiar with the general concepts applicable to a certificate practice statement, certificates, and public key infrastructures. All topics in RFC 2527 are identified to facilitate comparison and policy mapping. However, certain components are identified as "no stipulation" to indicate to the reader that a conscious decision was made to exclude that particular topic and protect against inadvertent omission of a topic.

The CPS describes the minimum mandatory practices of the RMS Certification Hierarchy and applies to all Certification Authorities (CAs) within the Rights Management System certificate hierarchy. This document defines the standards by which internal and external entities should assess Microsoft's RMS certificate hierarchy implementation. This CPS is applicable to all entities with relationships with the RMS Certification Hierarchy, including Certification Authorities (CAs), Subscribers, and Relying Parties.

1.1.2 Certificate Policies

A CA issues a signed certificate to bind a public key to a particular entity, machine or person. According to X.509, a CP is "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with a common security requirement." A CP may be used by a certificate user or Relying Party to help in deciding whether a certificate and the binding therein is sufficiently trustworthy for a particular application or purpose.

1.2 Identification

This document is formally referred to as the “Rights Management Services Certification Hierarchy Practice Statement” (RMS-CPS). Rights Management System Subordinate CAs (Sub-CAs) issue certificates in accordance with Microsoft Certificate Policies (CPs). Microsoft has designed its practices such that Microsoft CPs will be supported by the RMS-CPS.

1.3 Community and Applicability

The RMS Certification Hierarchy has been established to provide certificate services to the general public. Certificate Policies (CPs) define in greater detail the specific communities for which a specific class or type of certificate is applicable, and the intended purposes and uses of such certificates. The minimum practices in this CPS shall not be violated or diminished by any associated Certificate Policy (CP).

1.3.1 Certification Authorities

Certification Authorities (CAs) are entities authorized to perform the following general functions:

Create and sign certificates
Distribute certificates to the appropriate Subscribers and Relying Parties
Revoke certificates
Distribute certificate status information in the form of Certificate Revocation Lists (CRLs) or other mechanisms, as necessary
Provide a repository where certificates and certificate status information are stored and made available.

Within the RMS Certification Hierarchy, there are three general types of CAs: a Root CA, Intermediate (Policy) CAs, and Issuing CAs.

1.3.1.1 Root CA

CA Name	Description of Function
Microsoft RMS Production Root	Root CA that serves as the “trust anchor” for the main RMS Certificate hierarchy.
Microsoft RMS ISV Root	Root CA that serves as the “trust anchor” for the hierarchy used for test purposes by 3^rd party ISVs during application development.

1.3.1.2 Intermediate (Policy) CAs

CA Name	Description of Function
Microsoft RMS Production CA	Subordinate CA which sits at the top of the Production RMS Certification Hierarchy.
Microsoft RMS Production Application Signing Server CA	Subordinate CA which issues only to the RMS Production Application Signing CA.
Microsoft RMS Production Account Certification CA	Subordinate CA which issues only to the RMS Production Account Certification Service.
Microsoft RMS Production Machine Activation CA	Subordinate CA which issues to the RMS Production Machine Activation Service and the Desktop Security Processor CA
Microsoft RMS Production Machine Activation 2 CA	Subordinate CA which issues only to the RMS Production - Mobile Security Processor Ca and the Server Security Processor CA
Microsoft RMS Production Server Enrollment CA	Subordinate CA which issues only to the RMS Production Server Enrollment Service.
Microsoft RMS ISV CA	Subordinate CA which sits at the top of the Pre-Production RMS Certification Hierarchy.
Microsoft RMS ISV Application Signing Server CA	Subordinate CA which issues only to the RMS ISV Application Signing CA.
Microsoft RMS ISV Account Certification CA	Subordinate CA which issues only to the RMS ISV Account Certification Service.
Microsoft RMS ISV Machine Activation CA	Subordinate CA which issue to the RMS ISV Machine Activation Service and the Desktop Security Processor CA
Microsoft RMS ISV Machine Activation 2 CA	Subordinate CA which issues only to the RMS ISV - Mobile Security Processor Ca and the Server Security Processor CA
Microsoft RMS ISV Server Enrollment CA	Subordinate CA which issues only to the RMS ISV Server Enrollment Service.

1.3.1.3 Function of Issuing CAs

The function of each Issuing Sub-CA within the Intranet sub-hierarchy is described in the table below.

CA Name	Description of Function
Microsoft RMS Production Application Signing CA	Issues certificates to individuals with a valid Authenticode signing certificate and have signed the Production Agreement with Microsoft for: Signing application manifests which allows the application to access content in the Production hierarchy.
Microsoft RMS ISV Application Signing CA	Issues certificates to individuals with a valid Authenticode signing certificate and have signed the Development Agreement with Microsoft for: Signing application manifests which allows the application to access content in the Pre-Production hierarchy.
Microsoft RMS Production / ISV Account Certification Service	Issue certificates to individuals for: · Passport user identity associated with a valid Passport ID
Microsoft RMS Production / ISV Machine Certificate Service	Issue certificates to individuals for: · RMS client application security
Microsoft RMS Production / ISV Server Enrollment Service	Issues certificates to individuals for: · RMS Server licenses
Microsoft RMS Production / ISV Desktop Security Processor Machine Activation CA	Issues certificates for a class of lockbox be used for Machine Certification
Microsoft RMS Production / ISV Mobile Security Processor Machine Activation CA	Issues certificates for a class of lockbox be used for Machine Certification
Microsoft RMS Production / ISV Server Security Processor Machine Activation CA	Issues certificates for a class of lockbox be used for Machine Certification

1.3.2 Registration Function

Issuing CAs perform most typical certificate registration functions, e.g. evaluate and either approve or reject Subscriber certificate management transactions (including certificate requests, renewal and rekey requests, and revocation requests). Depending on the applicable CP, the RA may collect and verify a Subscriber's information (such as a Subscriber's identity, position, or role) that is to be entered into the Subscriber's certificate. The RA may be designated for specific operations, applications, or domains. The RMS Certification Hierarchy supports both automated and manual registration functions.

Where an automated registration function is implemented, business rules are defined and used to automatically approve or reject Subscriber certificate management transactions (e.g., certificate requests) in accordance with the applicable Microsoft CP.

Where non-automated registration functionality is required, Microsoft manually approves or rejects Subscriber certificate management transactions in accordance with the applicable Microsoft CP.

1.3.2.1 Root and Intermediate CAs

For RMS Certification Hierarchy Root and Intermediate CAs, the Subscribers are Subordinate CAs which are under the control of the RMS Certification Hierarchy. Accordingly, the registration function for these CAs is performed manually by authorized RMS Certification Hierarchy personnel.

1.3.2.2 Issuing CAs

An automated registration function is currently used for the following Issuing CAs within the Microsoft RMS PCA sub-hierarchy:

· Microsoft RMS Production Account Certification Service

· Microsoft RMS Production Machine Certificate Service

· Microsoft RMS Production Server Enrollment Service

· Microsoft RMS ISV Account Certification Service

· Microsoft RMS ISV Machine Certificate Service

· Microsoft RMS ISV Server Enrollment Service

The registration function for each Issuing CA within Microsoft RMS PCA sub-hierarchy is performed as described in the table below.

CA Name	Description of Registration Function
Microsoft RMS Production Application Signing CA	A manual CA function based on presentation of a valid high-assurance certificate from a CA that performs appropriate Subscriber identification and authentication (I&A), e.g. Verisign Class 3 Code Signing or equivalent I&A classification from another CA. Issues certificates to ISVs to sign applications into the Production RMS Certification Hierarchy hierarchy.
Microsoft RMS Production Account Certification Service	An automated Registration function based on authentication of the user’s Passport ID. Issues Rights Management Account Certificates (RAC) which are used for identity purposes.
Microsoft RMS Production Machine Certificate Service	An automated service that generates both a unique software “lockbox” as well as a certificate based on presentation of the hash of a machine’s hardware information.
Microsoft RMS Production Server Enrollment Service	A registration function based on presentation of a valid high-assurance certificate from a CA that performs appropriate Subscriber identification and authentication (I&A), e.g. VeriSign Class 3 or equivalent I&A classification from another CA. Issues RMS Server Licensor Certificates to customers to operate Windows Right Management Services.
Microsoft RMS Production Desktop Security Processor Machine Activation CA	Registration function that issues machine certificates for a class of lockbox.
Microsoft RMS Production Mobile Security Processor Machine Activation CA	Registration function that issues machine certificates for a class of lockbox.
Microsoft RMS Production Server Security Processor Machine Activation CA	Registration function that issues machine certificates for a class of lockbox.
Microsoft RMS ISV Account Certification Service	An automated registration function based on authentication of the user’s Passport ID. Issues Rights Management Account Certificates (RAC) which are used for identity purposes and Client Licensor Certificates (CLC) which are used to create RMS protected content during application development.
Microsoft RMS ISV Machine Certificate Service	An automated service that generates both a unique software “lockbox” as well as a certificate based on presentation of the hash of a machine’s hardware information.
Microsoft RMS ISV Server Enrollment Service	A registration function based on presentation of a valid high-assurance certificate from a CA that performs appropriate Subscriber identification and authentication (I&A), e.g. VeriSign Class 3 or equivalent I&A classification from another CA. Issues RMS Server Licensor Certificates to customers to operate Windows Right Management Services for application development.
Microsoft RMS ISV Desktop Security Processor Machine Activation CA	Registration function that issues machine certificates for a class of lockbox.
Microsoft RMS ISV Mobile Security Processor Machine Activation CA	Registration function that issues machine certificates for a class of lockbox.
Microsoft RMS ISV Server Security Processor Machine Activation CA	Registration function that issues machine certificates for a class of lockbox.

1.3.3 End Entities

End Entities include Subscribers and Relying Parties. A Subscriber is the entity whose name or identifier appears as the subject in a certificate, and who asserts that it uses its key and certificate in accordance with this CPS (and related CPs). Subscribers typically include members of the general public who are licensees of Microsoft products incorporating Rights Management.

A Relying Party is the entity who relies on the validity and binding of the Subscriber with the public key associated with the certificate. Relying Parties include any entity that may rely upon a Subscriber certificate for purposes of verifying a Subscriber’s digital signature, for applying rights management to content.

1.3.4 Applicability

This CPS is applicable to all certificates issued by Microsoft RMS CAs within the RMS Certification Hierarchy. Microsoft RMS Certificate Policies (CPs) define the specific communities for which a specific class or type of certificate is applicable, specific RMS Certification Hierarchy practices and requirements for the issuance and management of such certificates, and the intended purposes and uses of such certificates.

1.4 Contact Details

This CPS is administered by Microsoft Corporation. Contact information is listed below:

Microsoft Corporation

Law & Corporate Affairs

Regulatory Affairs and Public Policy Group

One Microsoft Way

Redmond, WA 98052-6399

Phone: 425-882-8080

Fax: 425-936-7329

Microsoft Certificate Policies are reviewed by the Microsoft RMS Certification Hierarchy Committee, which serves as the “Policy Authority” for the RMS Certification Hierarchy and ensures that the practices specified in the Microsoft RMS CPS do not conflict with CP requirements.

The RMS Certification Hierarchy Committee consists of representatives from the Microsoft Law & Corporate Affairs Department and Security Business Technology Unit.

2 General Provisions

2.1 Obligations

2.1.1 RMS Certification Hierarchy Committee Obligations

Obligations of the RMS Certification Hierarchy Committee in its role as Policy Authority (PA) include:

Creating, maintaining and approving one or more Certification Practice Statements and Certificate Policies
Distributing and promoting Certificate Policies
Interpreting adherence to the Policies
Specifying the content of public-key certificates
Resolving or causing resolution of disputes related to Certificate Policies
Remaining current regarding security threats and taking appropriate actions to counteract threats deemed significant.

2.1.2 Certification Authority obligations

Obligations of the CAs within the Microsoft RMS Certification Hierarchy include:

Subscribing to and conforming with the stipulations in this CPS and one or more approved Certification Practice Statements and Certificate Policy(s).
Distributing the CA’s public key(s)
Generating, issuing and distributing public key certificates
Generating information on certificate status (such as CRLs)
Maintaining the security, availability, and continuity of the certificate and CRL signing functions
Providing a means for Subscribers to request revocation
Revoking public-key certificates
Maintaining ownership and control of its business records
Periodically demonstrating internal or external audited compliance with this CPS

2.1.3 Registration Authority obligations

Obligations of the Registration Authorities (RAs) within the Microsoft RMS Certification Hierarchy include:

Obtaining a public-key from the Subscriber or, optionally, generating an asymmetric key pair on behalf of the Subscriber
Identifying and authenticating (“I&A”) Subscribers:

· Verifying that identifying data provided by the Subscriber is valid. Identifying data may, but does not necessarily, include information about the identity of a Subscriber depending on the applicable CP.

· Verifying that the identifying data pertains to the Subscriber

· Verifying that the Subscriber is entitled to obtain a public-key certificate under the relevant Certificate Policy

· Verifying that the Subscriber possesses the asymmetric private key corresponding to the public-key submitted for certification

· Managing the submission of certificate request transactions binding the Subscriber’s identification data to the Subscriber’s public key.

Receiving and processing certificate revocation requests
Providing suitable training to personnel performing registration functions.

2.1.4 Subscriber obligations

Obligations of Subscribers within the Microsoft RMS Certification Hierarchy include:

Read and agree to the terms of this CPS
Note modify or alter any certificate issued under this CPS
Generating or causing to be generated one or more asymmetric key pairs
Submitting accurate public keys and credentials for registration
Providing information to the Issuing CA that is accurate and complete to the best of the Subscribers’ knowledge and belief regarding information in their certificates and identification and authentication information
Taking appropriate security measures to protect their private keys from compromise
Promptly reporting loss or compromise of private key(s) to the CA and/or RMS Certification Hierarchy in accordance with this CPS
Promptly report or update any inaccuracy of certificate information
Using its key pair(s) in conjunction with authorized applications in compliance with applicable policies
Use and authorize the use of any valid certificate for the purpose for which it was issued in accordance with this CPS, any applicable CP, and all applicable laws

2.1.5 Relying Party obligations

Obligations of Relying Parties within the Microsoft RMS Certification Hierarchy include:

Read and agree to the terms of this CPS
Confirming the validity of Subscriber public-key certificates using procedures consistent with the X.509 standard and prior to relying upon the certificate, including by reference to Certificate Revocation Lists (CRLs)
Verifying that Subscriber possesses the asymmetric private key corresponding to the public-key certificate (e.g., through digital signature verification)
Using the public-key in the Subscriber’s certificate for authorized applications and appropriate cryptographic functions in compliance with applicable policies.
Use and authorize the use of any valid certificate for the purpose for which it was issued in accordance with this CPS, any applicable CP, and all applicable law

The foregoing obligations are not an exhaustive or finite list of steps that a Relying Party should undertake to determine whether to rely upon a certificate. Each Relying Party is responsible for determining, in accordance with its policies and procedures, when and to what extent it should rely on a certificate in view of the particular set of facts and circumstances. The RMS Certification Hierarchy and any CA provide the certificate and related procedures under this CPS to assist a Relying Party in evaluating a trust relationship. Without limiting the foregoing, the RMS Certification Hierarchy and any CA shall have no liability arising out of or relating to a certificate if a Relying Party fails to adhere to its obligations under this CPS or CP.

2.1.6 Repository obligations

The RMS Certification Hierarchy and CAs shall provide repository services. In providing repository services, obligations of the RMS Certification Hierarchy include:

Storing and distributing public-key certificates
Storing and distributing information on certificate status (such as CRLs and/or online certificate status)
Storing and distributing PKI public information (e.g., Certificate Policy)
Storing and making available the proper certificate templates to the appropriate certificate applicants.

2.2 Liability

This Section 2.2 states the sole and exclusive liability of the Microsoft RMS Certification Hierarchy, any CA or RA, and any affiliate or subsidiary and any of their respective directors, employees, agents or subcontractors arising under or related to this CPS and any certificate issued by the Microsoft RMS Certification Hierarchy and any CA, including but not limited to, any claims, expenses, losses or damages in connection with a certificate whether arising out of contract, tort (including negligence), or other theories of law or any act or omission of the Microsoft RMS Certification Hierarchy or its issuing CAs. Each Subscriber and Relying Party expressly acknowledges that the allocation of risk and the limitations of liability in this CPS constitute an essential part of this CPS and any agreement with a Subscriber or Relying Party. The limitations in this Section 2.2 shall apply notwithstanding the failure of essential purpose of any remedy state regardless of whether a party has been advised of the possibility of damages.

The limitations in this Section 2.2 may be modified pursuant to a CP adopted and approved by the Microsoft RMS Certification Hierarchy. In the event of any conflict or inconsistency between this CPS and a CP with respect to the obligations set forth in this Section 2.2, the terms of the CP shall control.

2.2.1 Warranties and limitations on warranties

Except as expressly otherwise provided in this CPS, a CP or applicable agreement with a Subscriber or Relying Party, the RMS Certification Hierarchy warrants that it will use commercially reasonable efforts to provide certification authority services substantially in compliance with this CPS and the relevant Microsoft CPs. The RMS Certification Hierarchy makes no other warranties or promises and has no further obligations to Subscribers or Relying Parties.

2.2.2 Disclaimers

Except for express warranties stated in this CPS, the RMS Certification Hierarchy disclaims all other warranties, promises, representations, conditions and other obligations, including, but not limited to, implied warranties of merchantability or fitness for a particular purpose, warranties arising out of a course of dealing or trade usage or any warranty of the accuracy of any information provided (including the identity of any person or entity named in a RMS Certification Hierarchy certificate or their authority to act on behalf Microsoft or any Subscriber). The RMS Certification Hierarchy further does not represent that its or any CA's services associated with any certificate will be error free, complete or uninterrupted.

2.2.3 Loss limitations

In no event shall the RMS Certification Hierarchy and any affiliate or subsidiary and any of their respective directors, employees, agents or subcontractors be liable for any indirect, consequential, incidental, special or punitive damages, or for any loss of profits, loss of data, or other indirect or consequential damages (whether arising in contract, tort (including negligence) or other legal theory) arising from or in connection with the use, delivery, license, availability or non-availability, performance or nonperformance of certificates, digital signatures, the repository, or any other transactions or services offered or contemplated by this CPS, even if the RMS Certification Hierarchy or an issuing CA has been advised of the possibility of such damages.

The RMS Certification Hierarchy is not liable or loss associated with any of the following even if it has been advised of the possibility thereof:

Loss of revenues, profits, savings, reputation or goodwill;
Any suspension or interruption of CA or RA services due to war, natural disasters, terrorism, power, telecommunications or other factors beyond the control of the RMS Certification Hierarchy;
Losses incurred between the time a certificate is revoked and the next scheduled issuance of a CRL;
Unauthorized, negligent or fraudulent use of certificates issued by the RMS Certification Hierarchy, or use of certificates beyond the prescribed use defined by this CPS and the relevant CP;
The negligent or fraudulent use of certificates or CRLs issued by the RMS Certification Hierarchy; or
Disclosure of personal information contained within certificates or CRLs
Loss of, or damage to, any data, records or other information.

2.2.4 Other Exclusions

No stipulation.

2.3 Financial Responsibility

2.3.1 Indemnification by Relying Parties and Subscribers

Except as otherwise provided in a customer agreement, each Subscriber and Relying Party indemnify and hold harmless the RMS Certification Hierarchy and any affiliate or subsidiary and any of their respective directors, employees, agents or subcontractors from and against any claims, actions, suits, damages, losses, liabilities and expenses (including reasonable attorneys' fees) arising out of or related to (a) its unauthorized or illegal use of a certificate, digital signature, public or private key issued by the RMS Certification Hierarchy or CA, and (b) any false, inaccurate, misleading, or fraudulent information provided by it to the RMS Certification Hierarchy or CA.

2.3.2 Fiduciary relationships

The RMS Certification Hierarchy, CA and RA are not the agent, fiduciary, trustee, or other representative of Subscribers or any relying parties.

2.3.3 Administrative processes

No stipulation.

2.4 Interpretation and Enforcement

2.4.1 Governing law

This CPS is governed by the laws in force in the State of Washington and the United States of America.

2.4.2 Severability, survival, merger and notice

2.4.2.1 Assignment/Successors. This CPS shall be binding on all successors of the parties.

2.4.2.2 Severability. If any provision of this CPS is found to be unenforceable, the remaining provisions shall be interpreted to best carry out the reasonable intent of the parties. It is expressly agreed that every provision of this CPS that provides for a limitation of liability or exclusion of damages, disclaimer or limitation of any warranties, promises or other obligations, is intended to be severable and independent of any other provision and is to be enforced as such.

2.4.2.3 Waiver. This CPS shall be interpreted consistently with what is commercially reasonable in good faith under the circumstances and considering its international scope and uniform application. Failure by any person to enforce a provision of this CPS will not be deemed a waiver of future enforcement of that or any other provision.

2.4.2.4 Notice. Any notice, demand, or request pertaining to this CPS shall be communicated either using digitally signed messages consistent with this CPS, or in writing. Electronic communications shall be effective when received by the intended recipient.

2.4.2.5 Merger. This CPS, together with any applicable Subscriber or Relying Party agreement, and any associated attachments constitute the entire agreement between the parties with respect to the subject matter hereof and supersede in all respects all prior or contemporaneous proposals, negotiations, discussions and agreements.

2.4.2.6 Survival. Sections 2.2, 2.3, 2.4, and 2.8 of this CPS shall survive any termination of a certificate, this CPS, and any applicable Subscriber or Relying Party agreements.

2.4.3 Dispute resolution procedures

In the event of any dispute involving the services or provisions covered by this CPS, the aggrieved party shall notify a member of RMS Certification Hierarchy management regarding the dispute. RMS Certification Hierarchy management will involve the appropriate Microsoft personnel to resolve the dispute.

2.5 Fees

No stipulation.

2.6 Publication and Repository

2.6.1 Publication of CA information

The RMS-CPS and Microsoft Certificate Policies are published on the Microsoft Corporation Internet website at http://www.microsoft.com/pki/rms/cps/, in accordance with RMS-CPS §8.3 and the provisions of the relevant CP. Applicable CPs will be provided to Subscribers and Relying Parties as appropriate in view of the certificates being issued or used.

2.6.2 Frequency of publication

The MSC-CPS and Microsoft Certificate Policies are published in accordance with RMS-CPS §2.6.1. CRLs are published in accordance with RMS-CPS §4.4.9.

2.6.3 Access controls

Read access to the Microsoft Corporation Internet website repository for published CA information is available to all parties worldwide. Appropriate logical access controls are used to restrict access to authorized RMS Certification Hierarchy personnel the ability to write to or modify repository content.

2.6.4 Repositories

The RMS Certification Hierarchy repository consists of Microsoft Corporation Internet website and the RMS Certification Hierarchy directory.

2.7 Compliance Audit

2.7.1 Frequency of entity compliance audit

For Certification Authority activities deemed business critical by Microsoft management, an annual compliance review may be performed by an internal or external auditor to assess the effectiveness of the controls over the RMS Certification Hierarchy.

2.7.2 Identity/qualifications of auditor

The internal or external personnel who perform the annual audit should demonstrate proficiency in public key infrastructure technology, information security tools and techniques, security auditing, and the internal audit or third-party attestation function.

2.7.3 Auditor's relationship to audited party

The entity that performs the annual audit should be organizationally independent of the RMS Certification Hierarchy Committee.

2.7.4 Topics covered by audit

The scope of the annual audit should include the requirements of this CPS and Microsoft Certificate Policies as they relate to CA environmental controls, key management, and certificate life cycle management.

2.7.5 Actions taken as a result of deficiency

Significant deficiencies identified during the compliance audit will result in a determination of actions to be taken. This determination is made by the RMS Certification Hierarchy Committee with input from the auditor. RMS Certification Hierarchy Management is responsible for ensuring that corrective action plans are promptly developed and corrective action is taken within a period of time commensurate with the significance of such matters identified.

Should a severe deficiency be identified that might compromise the integrity of the RMS Certification Hierarchy, RMS Certification Hierarchy Management will consider, with input from the auditor, whether suspension of the RMS Certification Hierarchy’s operation is warranted. Should a severe deficiency be identified that might compromise the integrity of a particular CA, RMS Certification Hierarchy Management will assess whether suspension of the particular CA’s operation is warranted.

2.7.6 Communication of results

Compliance audit results are communicated to the RMS Certification Hierarchy Committee and others deemed appropriate by Microsoft Management.

2.8 Confidentiality and Privacy

2.8.1 Types of information to be kept confidential

Sensitive RMS Certification Hierarchy information must remain confidential to Microsoft. The following information is considered confidential to Microsoft and may not be disclosed:

RMS Certification Hierarchy policies, procedures and technical documentation
Subscriber registration records, including:

- Certificate applications, whether approved or rejected

- Proof of identification documentation and details

- Certificate information collected as part of the registration records, beyond that which is required to be included in Subscriber certificates

The reason for a certificate or revocation, with the exception of the revocation of a Subscriber’s certificate due to:

- The compromise of its corresponding private key, in which case a disclosure must be made to relevant Relying Parties that the private key has been compromised or

- The termination of a CA, in which case prior disclosure of the termination must be given to affected entities.

Audit trail records
Any private key within the RMS Certification Hierarchy
Compliance audit results
Contracts.

2.8.2 Types of information not considered confidential

The RMS Certification Hierarchy may publish Certificate information (including information within a certificate) and CRLs relating to RMS Certification Hierarchy CAs with external Relying Parties (e.g., Root RMS CA certificate, Intermediate CA certificate(s), Issuing CA certificates, and CRLs issued by these CAs) to an RMS Certification Hierarchy repository which provides read only access to authorized external parties or the public if required by the applicable Microsoft CP. Certificates and CRLs published in such a repository are not considered confidential.

In addition, the following types of information shall not be deemed to be confidential:

· information disclosed to the receiving party that was already known to the receiving party, without obligation to keep it confidential;

· the receiving party received the information in good faith from a third party lawfully in possession thereof without obligation to keep such information confidential;

· the information was publicly known at the time of its receipt by the receiving party or has become publicly known other than by a breach of this CPS or any applicable agreement; or

· the information is independently developed by the receiving party without use of the other party's confidential information

2.8.3 Disclosure of certificate revocation information

The fact that a particular RMS Certification Hierarchy Subscriber certificate is revoked is not confidential to Microsoft. The transactional records and other information leading up to such a revocation are considered confidential information of Microsoft. Subscriber certificate status information is provided to Relying Parties through the use of CRLs.

2.8.4 Release to law enforcement officials

As a general principle, no document or record (including registration records) belonging to or controlled by the RMS Certification Hierarchy is released to law enforcement agencies or officials except where the law enforcement official is properly identified and where the release of specific information is:

required by applicable laws or regulations
pursuant to a subpoena or order of a court or other government or regulatory authority with which Microsoft is legally obligated to comply
pursuant to a demand made by any government regulatory agency or authority with jurisdiction over Microsoft.
Authorized by the user when necessary to effect an appropriate and intended use of the certificate which may be determined by the issuing CA.

2.8.5 Release as part of civil discovery

As a general principal, no document or record belonging to or controlled by the RMS Certification Hierarchy is released to any person except where:

a properly constituted instrument requiring production of the information is produced and
the person requiring production is a person authorized to do so by a court of law and is properly identified.

2.8.6 Disclosure upon owner's request

No stipulation.

2.8.7 Other information release circumstances

No stipulation.

2.9 Intellectual Property Rights

The following are the property of Microsoft:

This CPS
Microsoft-specified Certificate Policies
Policies and procedures supporting the operation of the RMS Certification Hierarchy
Certificates and CRLs issued by Microsoft CAs
Names used to represent entities within the RMS Certification Hierarchy
CA, infrastructure and Subscriber key pairs
Smart cards and readers issued to Subscribers.

3 Identification and Authentication

3.1 Initial Registration

3.1.1 Types of names

The Issuer Name for all RMS Certification Hierarchy Certificates and the Subject Name for all RMS Certification Hierarchy CA Certificates is populated as follows:

Names generally are represented by a single string and do not contain multiple attributes.

For SLC, the URL of the server is stored.

For Application Signing certificates, the name of the ISV is stored without location.

3.1.2 Need for names to be meaningful

Distinguished Names shall be meaningful, [except for certificates issued by the Microsoft Machine Certificate CA, which uses a GUID for the Distinguished Name.]

3.1.3 Rules for interpreting various name forms

Name forms are interpreted in accordance with CPS §3.1.1 and 3.1.2.

3.1.4 Name claim dispute resolution procedure

No stipulation.

3.1.5 Recognition, authentication and role of trademarks

No stipulation.

3.1.6 Method to prove possession of private key

Where the Subscriber generates his/her own key pair(s), the Subscriber’s certificate request must contain the public key to be certified and be digitally signed with the corresponding private key. Where a Microsoft Issuing CA generates Subscriber key pairs, the Issuing CA must create and submit a certificate request which contains the public key to be certified and is digitally signed with the corresponding private key.

3.1.7 Authentication of organization (machine) identity

The RMS Certification Hierarchy authenticates machine identities in accordance with the applicable Microsoft CP.

3.1.8 Authentication of individual identity

Individual Subscribers are authenticated by Issuing CAs in accordance with the applicable Microsoft CP.

3.2 Routine Rekey

Routine rekey of the RMS Root CA and Sub-CAs is performed in accordance with CPS §4.8.

Routine rekey of Subscribers may be required in accordance with the applicable Microsoft CP. Rekey requests are approved by the applicable Microsoft Issuing CA using an automated or manual process in accordance with the applicable Microsoft CP.

3.3 Rekey After Revocation

In the event that an RMS CA certificate must be revoked, the CA will be re-keyed in accordance with CPS §4.8 or terminated in accordance with CPS §4.9.

The process for re-key after revocation or expiration of a Subscriber certificate is complete re-enrollment, which requires the generation of a new Subscriber key pair and the performance of the initial registration identification and authentication procedures specified in CPS §3.1 and the applicable Microsoft CP.

3.4 Certificate Renewal

CA certificate renewal, defined as the process whereby a new certificate with an extended validity period is created for an existing key pair, is supported.

Subscriber certificate renewal is supported for RMS Certification Hierarchy Subscribers if required by a Microsoft CP. Where certificate renewal is not supported, prior to the expiration or following the revocation or expiration of the Subscriber’s certificate, the Subscriber is required to generate a new key pair and request a new certificate (i.e., rekey) in accordance with CPS §3.2 and 3.3.

3.5 Revocation Request

A Subscriber certificate revocation request is valid if it complies with CPS §4.4 and meets one of the following requirements:

It is digitally signed with the private key of the Subscriber
It is digitally signed with the private key of an authorized Issuing CA
If the Subscriber is unable to digitally sign the revocation request, the Issuing CA must perform sufficient procedures to authenticate the Subscriber’s request in accordance with the applicable CP.

For individual certificates, where a revocation request is initiated by someone other than the Subscriber, approval from Microsoft RMS Certification Hierarchy Committee is required before the request can be processed by the RMS Certification Hierarchy.

3.6 Suspension Request

See CPS §4.4.

3.7 Request to Release Suspension

See CPS §4.4.

4 Operational Requirements

4.1 Certificate Application

Prior to a certificate being issued by the Microsoft CA, the Subscriber must submit a certificate application. The required certificate application information and form are specified in the applicable Microsoft CP.

4.2 Certificate Issuance

Certificates are generated, issued and published only after the Issuing CA performs the required authentication and validation steps in accordance with the applicable Microsoft CP. The Issuing CA function may be manual or automated as discussed in CPS §1.3.2.

4.3 Certificate Acceptance

Certificate acceptance states the requirements regarding acceptance of an issued certificate by a Subscriber and for subsequent publication and use of the certificate. A Subscriber’s receipt of a certificate and subsequent use of its keys and certificates constitute certificate acceptance. By accepting a certificate, the Subscriber:

Agrees to be bound by the continuing responsibilities, obligations and duties imposed by this CPS and applicable CP,
Represents and warrants that to its knowledge no unauthorized person has had access to the private key associated with the certificate, and
Represents and warrants that the certificate information it has supplied during the registration process is truthful and has been accurately and fully published within the certificate.

Upon receipt of a certificate, the Subscriber is responsible for verifying that the information contained within the certificate is accurate and complete and that the certificate is not damaged or otherwise corrupted. In the event the certificate is inaccurate, damaged or corrupted, the Subscriber shall contact the issuing RMS Certification Hierarchy CA to have the certificate updated, repaired or replaced as determined by the CA.

4.4 Certificate Suspension and Revocation

The RMS Certification Hierarchy supports certificate revocation for RMS Certification Hierarchy CAs if required by a specific Microsoft CP. The RMS Certification Hierarchy supports certificate suspension if required by a specific Microsoft CP. Where certificate suspension services are provided, such services are provided in accordance with the requirements of the applicable Microsoft CP.

4.4.1 Circumstances for revocation

Revocation may take place at the discretion of the RMS Certification Hierarchy CAs in the event that the security or integrity of the certificate (or information contained within it), a Subscriber or an RA is compromised or threatened. Without limiting the foregoing, under the following circumstances a certificate will be revoked:

The Subscriber is terminated.
Identifying information or attributes in the Subscriber’s certificate change before the certificate expires or otherwise reasonably believed to be false, misleading or inaccurate.
The certificate subject can be shown to have violated the stipulations of this CPS or applicable CP.
Compromise of the Subscriber private key is known or suspected.
Compromise of the issuing CA private key is know or suspected.
The security or integrity of the Subscriber's certificate or private key or confidentiality of he Subscriber or other authorized party requests certificate revocation in accordance with CPS §3.5 and specific provisions of a Microsoft CP.
The Subscriber has materially breached an obligation under this CPS, applicable CP, or certificate agreement.
As required by applicable law or regulation.

4.4.2 Who can request revocation

Subscriber certificate revocation can be initiated by the Subscriber, an authorized Issuing CA, the RMS Certification Hierarchy, or authorized third parties.

4.4.3 Procedure for revocation request or suspension request

When revocation requests are initiated by a Subscriber, the Issuing CA is responsible for:

Receiving and authenticating the request in accordance with the verification requirements of the applicable Microsoft CP,
Submitting an approved revocation request to the CA, and
Documenting the reason for revocation.

To process a revocation request initiated by an Issuing CA or Subscriber, the RMS Certification Hierarchy:

Receives and authenticates the digitally signed request from the Issuing CA,
Revokes the certificate, and
Adds the certificate to the Microsoft CA’s CRL at the next scheduled update.

For individual certificates, where a revocation request is initiated by someone other than the Subscriber, approval from the Microsoft RMS Certification Hierarchy Committee is required before the request can be processed by the RMS Certification Hierarchy.

For suspension requests, see CPS §4.4.

4.4.4 Revocation request grace period

The Issuing CA is required to verify and process revocation requests on receipt for automated requests and within two (2) business days for manual requests. The RMS Certification Hierarchy is required to process approved evocation requests on receipt. A certificate’s revoked status must be reflected on a CRL published at the next scheduled update according to the applicable Microsoft CP.

4.4.5 Circumstances for suspension

See CPS §4.4.

4.4.6 Who can request suspension

See CPS §4.4.

4.4.7 Procedure for suspension request

See CPS §4.4.

4.4.8 Limits on suspension period

See CPS §4.4.

4.4.9 CRL issuance frequency

CRLs for Microsoft CAs are issued as necessary in accordance with the following table.

CA Type	CRL Publication Frequency
Root RMS CA	No Stipulation
Intermediate (Policy) CA(s)	No Stipulation
Issuing CA(s)	No Stipulation

4.4.10 CRL checking requirements

Relying Parties are required to check certificate status using the applicable CRL before relying upon a certificate. Under no circumstances will the RMS Certification Hierarchy or its CAs and their respective directors, officers, employees, agents and subcontractors be liable for any damages whatsoever due to a Relying Party's (a) failure to check for revocation or expiration of a certificate, or (b) reliance on a revoked or expired certificate.

4.4.11 On-line revocation/status checking availability

No stipulation.

4.4.12 On-line revocation checking requirements

No stipulation.

4.4.13 Other forms of revocation advertisements available

No stipulation.

4.4.14 Checking requirements for other forms of revocation advertisements

No stipulation.

4.4.15 Special requirements for key compromise

There is no deviation from the certificate revocation procedures specified above when the revocation of a Subscriber certificate is due to private key compromise. In addition to the procedures specified above, if deemed necessary, the RMS Certification Hierarchy uses commercially reasonable efforts to notify potential Relying Parties if the RMS Certification Hierarchy discovers, or has reason to believe, that there has been a compromise of a RMS Certification Hierarchy CA private key.

4.5 Security Audit Procedures (Logical and Physical)

4.5.1 Types of events recorded

The RMS Certification Hierarchy logs the following significant events:

Significant CA key life cycle management events including CA key generation, CA key backup, and other cryptographic device information
CA and Subscriber certificate life cycle management events

- Requests for certificates, renewal, rekey, and revocation

- Successful or unsuccessful processing of requests

- Generation and issuance of certificates

- Revocation of certificates

- Issuance of CRLs

Logical security-related events including (for Issuing CAs):

- System crashes, hardware failures and other anomalies

- Account and service logon

- Object access

- Policy changes

- Account management

Physical security-related events including:

- CA facility visitor entry/exit

- Retrieval of administrator smart cards from off-site secure storage facility

Smart card life cycle management events including card personalization, distribution, and replacement.

4.5.2 Frequency of processing log

Audit logs (including system logs and physical entry logs) are reviewed on an as-needed basis.

4.5.3 Retention period for audit log

System audit logs are maintained until overwritten by the system (when a specific log size limit has been reached for the particular log). Video records of RMS Certification Hierarchy facility entry are kept for 18 days. Card reader access logs are kept for a minimum of six months.

4.5.4 Protection of audit log

Production and archived logical and physical audit logs are protected using a combination of physical and logical access controls.

4.5.5 Audit log backup procedures

Production and archived logical and physical audit logs are backed up regularly. Card reader access logs are backed up regularly as well. System audit logs are not backed up.

4.5.6 Audit collection system (internal vs. external)

Automated audit data is generated and recorded at the application, network, and operating system level. Manually generated audit data is recorded by the RMS Certification Hierarchy employees.

4.5.7 Notification to event-causing subject

The RMS Certification Hierarchy team will notify the Microsoft corporate incident response team should a critical security event occur.

Microsoft’s corporate security group must notify the RMS Certification Hierarchy team when an alarm occurs at the RMS Certification Hierarchy facility. If a forced entry has occurred, the corporate security manager and the information security director are to be contacted.

4.5.8 Vulnerability assessments

No stipulation.

4.6 Records Archival

The RMS Certification Hierarchy maintains an archive of relevant records for each CA.

4.6.1 Types of event recorded

The RMS Certification Hierarchy archives CA key generation records and CA certificates for each CA.

4.6.2 Retention period for archive

No stipulation.

4.6.3 Protection of archive

No stipulation.

4.6.4 Archive backup procedures

No stipulation.

4.6.5 Requirements for time-stamping of records

RMS Certification Hierarchy system clocks are synchronized with Microsoft corporate domain controllers. Automated journal entries include a system generated date and time field. Manual journal entries include a manually entered date and time field.

4.6.6 Archive collection system (internal or external)

No stipulation.

4.6.7 Procedures to obtain and verify archive information

No stipulation.

4.7 Key Changeover

Microsoft CAs will stop issuing certificates and will be rekeyed or terminated before the maximum key usage period for certificate signing is reached in accordance with CPS §6.3.2. The CA will continue to sign and publish CRLs until the end of the CA certificate lifetime. Key changeover or CA termination process will be performed such that it causes minimal disruption to Subscribers and Relying Parties.

4.8 Disaster Recovery and Business Resumption

The RMS Certification Hierarchy maintains offsite backups of CA systems, data, and CA private keys for purposes of routine or disaster recovery. Smart cards required for CA activation are also maintained at locations separate from the CA data center.

In the event of a disaster or key compromise, RMS Certification Hierarchy management will assess the situation and determine the appropriate course of action.

4.9 CA Termination

In the event that it is necessary to terminate the operation of a RMS Certification Hierarchy CA, RMS Certification Hierarchy management will plan and coordinate the termination process with its Subscribers and relying parties such that the impact of the termination is minimized. The RMS Certification Hierarchy should provide as much prior notice as is practicable and reasonable to Subscribers and Relying Parties and preserve relevant records for a period of time deemed fit for functional and legal purposes. Relevant certificates will be revoked no later than the time of the termination.

5 Physical, Procedural and Personnel Security Controls

5.1 Physical Controls

5.1.1 Site location and construction

RMS Certification Hierarchy systems are hosted and managed using secure facilities in the Redmond, Washington area with multiple levels of physical access controls.

5.1.2 Physical access

Production RMS Certification Hierarchy systems are housed in a secure facility requiring three factor authentication and dual control. Physical access to the facility is automatically logged and video recorded on a 24x7 basis. Within the facility, motion sensors provide an additional level of security.

5.1.3 Power and air conditioning

The current facility’s power circuit is supported by a backup generator. An air conditioning unit and heat sensor have been implemented ensure that the data center temperature is maintained within reasonable operating limits.

5.1.4 Water exposures

No stipulation.

5.1.5 Fire prevention and protection

The RMS Certification Hierarchy site is equipped with water-based sprinklers.

5.1.6 Media storage

Media containing production software, production data, and system audit information is stored within RMS Certification Hierarchy facilities with appropriate physical and logical access controls designed to limit access to authorized personnel. Backup information is stored in a secure offsite storage facility.

5.1.7 Offsite backup

Offsite backup media are stored in a physically secure manner using both Microsoft-owned and bonded third party storage facilities.

5.1.8 Waste disposal

Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information are rendered unreadable before disposal. Other waste is disposed of in accordance with Microsoft’s normal waste disposal requirements.

Cryptographic devices, smart cards, and other devices that may contain private keys or keying material are physically destroyed or zeroized in accordance the manufacturers’ guidance prior to disposal.

5.2 Procedural Controls

5.2.1 Trusted roles

All Microsoft personnel involved in the operation of RMS Certification Hierarchy systems are considered to serve in “trusted roles.” Within the RMS Certification Hierarchy organization, the following trusted roles exist:

RMS Certification Hierarchy Engineering/Architecture, responsible for the design and implementation of RMS Certification Hierarchy systems and for maintaining the highly effective operation of production PKI systems and data base administration, including managing and administering the operation of all systems supporting the RMS Certification Hierarchy in the data center.
RMS Certificate Life Cycle Operations, responsible for processing Subscriber certificate life cycle requests including requests for certificates, certificate revocation, certificate replacement (rekey or renewal).

In addition, the RMS Certification Hierarchy operation is supported by Microsoft Corporate organizations including the following, each of which is considered a “trusted” role:

Law and Corporate Affairs Group provides legal guidance related to the overall RMS Certification Hierarchy and enables three-person control for the operation of the Root CA and Intermediate (Policy) CAs.
Corporate Enterprise Domain Management, responsible for establishing users in the network domains.
Corporate Security Intrusion Response Team, respond to critical system security events.
Corporate Security Guards, responsible for monitoring and responding to physical security events.

5.2.2 Number of persons required per task

Cryptographically sensitive operations within the RMS Certification Hierarchy such as CA key generation, CA key recovery, CA key activation and CA system configuration require the participation of multiple “trusted” individuals in accordance with CPS §6.2.2. Other operations may require only one trusted individual.

5.2.3 Identification and authentication for each role

Each person performing a trusted role within the RMS Certification Hierarchy must be authorized to perform such functions and must satisfy the personnel requirements specified in CPS §5.3.

5.3 Personnel Controls

The RMS Certification Hierarchy operation relies on Microsoft corporate policies for personnel management to ensure the trustworthiness of its staff.

5.3.1 Background, qualifications, experience, and clearance requirements

The recruitment and selection practices for RMS Certification Hierarchy personnel take into account the background, qualifications, experience, and clearance requirements of each position, which are compared against the profiles of potential candidates.

5.3.2 Background check procedures

For RMS Certification Hierarchy employees, background checks are performed prior to their commencement of employment. Such checks include:

Identify verification
Character reference
Employment
Education
Credit and
Criminal checks.

RMS Certification Hierarchy employees are required to sign a nondisclosure agreement and are required to adhere to RMS Certification Hierarchy policies and procedures.

5.3.3 Training requirements

All RMS Certification Hierarchy personnel receive on the job training covering:

Basic PKI concepts
Documented RMS Certification Hierarchy security and operational policies and procedures
This CPS and relevant CPs
The use and operation of PKI system software.

5.3.4 Retraining frequency and requirements

RMS Certification Hierarchy personnel receive formal or informal training on the use of deployed PKI products and RMS Certification Hierarchy policies and procedures, upon hire and as necessary. Security awareness campaigns are ongoing.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

In accordance with corporate polices, appropriate disciplinary actions will be taken for unauthorized actions or other violations of RMS Certification Hierarchy policies and procedures.

5.3.7 Contracting personnel requirements

RMS Certification Hierarchy may employ contractors as necessary. Where contractors are used by the RMS Certification Hierarchy, they are subject to background check procedures comparable to those specified in CPS §5.3.1 and 5.3.2.

5.3.8 Documentation supplied to personnel

RMS Certification Hierarchy personnel are required to read this CPS. They are also provided with RMS Certification Hierarchy policies, procedures, and other documentation relevant to their job functions.

6 Technical Security Controls

6.1 Key Pair Generation

6.1.1 Key pair generation

CA key pair generation uses cryptographic modules that meet the requirements of CPS §6.2.1 and requires the participation of trusted employees including members of the Microsoft RMS Certification Hierarchy team and the Microsoft Law and Corporate Affairs Group.

Enrollment Agent key generation is performed in software by an authorized RMS Certification Hierarchy Issuing CA, with the private key subsequently loaded onto a smart card.

Subscriber key pair generation may be performed by the RMS Certification Hierarchy or by the Subscriber, depending on the application, in accordance with the applicable Microsoft CP.

6.1.2 Private Key delivery to entity

Microsoft CA key pairs do not require delivery as they are generated and managed by the RMS Certification Hierarchy.

Where Subscriber key pairs are generated by the RMS Certification Hierarchy, the Subscriber’s private key is securely delivered to the Subscriber in accordance with the applicable Microsoft CP.

Where Subscriber key pairs are generated by the Subscriber, there is no private key transportation requirement.

6.1.3 Public key delivery to certificate issuer

CA certificate requests are generated and processed by RMS Certification Hierarchy employees using a controlled process that requires the participation of multiple trusted individuals. CA certificate requests are PKCS #10 requests and accordingly contain the requesting CA’s public key and are digitally signed by the requesting CA’s private key.

Where Subscriber key pairs are generated by an RMS Certification Hierarchy Issuing CA or Subscriber, the public key is submitted to the CA using a certificate request signed with the Subscriber’s private key or the Issuing CA’s private key. This mechanism ensures that:

· the public key has not been modified during transit and

· the sender possess the private key corresponding to the transferred public key.

Where an automated registration process is used, the Subscriber’s public key is automatically submitted to the CA as part of the enrollment process. Where a manual registration process is used, the MCS-PKI Issuing CA submits the Subscriber’s public key to the CA for certification.

6.1.4 CA public key delivery to users

Microsoft CA certificates are loaded and resident on the Microsoft Internet website accessible to all users. If required by a Microsoft CP, the appropriate RMS Certification Hierarchy CA certificates may be made available to relevant Subscribers and relying parties through other mechanisms.

6.1.5 Key sizes

Unless otherwise specified in an applicable CP, Microsoft CA key pairs are 2048 bit RSA keys. Subscriber and Issuing CA key pairs are 1024 bit RSA keys.

6.1.6 Public key parameters generation and quality checking

No stipulation.

6.1.7 Hardware/software key generation

The Microsoft RMS Root CA key pair is generated in and protected by a hardware security module certified to FIPS 140-1 level 3. Microsoft Intermediate CA and Subordinate Issuing CA key pairs are generated in hardware security modules certified to FIPS 140-1 level 2.

Subscriber key pairs are generated in hardware or software, depending on the sensitivity of applications, in accordance with the applicable Microsoft CP.

6.1.8 Key usage purposes

Keys and certificates may be used for the purposes specified in the relevant Microsoft CP. For all RMS CAs, the key usage extension is set in accordance with the Microsoft certificate profile requirements specified in CPS §7.1.2.1.

6.2 CA Private Key Protection

6.2.1 Standards for cryptographic module

The RMS Certification Hierarchy uses cryptographic modules that meet industry standards for random number and prime number generation and the following requirements:

CA Type	Requirements
Root CA	Certified to at least FIPS 140-1 Level 3
Intermediate and Issuing CAs	Certified to at least FIPS 140-1 Level 2

Subscriber key pairs are stored in hardware or software, depending on the sensitivity of applications, in accordance with the applicable Microsoft CP.

6.2.2 Private Key multi-person control

The participation of multiple trusted employees is required to perform sensitive CA private key operations (e.g., signing operations, CA key backup, CA key recovery, etc.) for the RMS Root CA and Intermediate (Policy) CAs. This is enforced through the RMS Certification Hierarchy’s allocation among persons or groups with trusted roles of the Administrator and Operator Card Sets which are required for CA key activation.

The participation of at least two trusted employees is required to perform sensitive CA private key operations (e.g., signing operations, CA key backup, CA key recovery, etc.) for the Issuing CAs. This is enforced by the physical access controls specified in CPS §5.1.2 and physical access controls over the related Administrator Cards and Operator Cards.

6.2.3 Private Key escrow

No Stipulation. The escrow of CA and Subscriber private keys, for purposes of access by law enforcement, is not supported by the RMS Certification Hierarchy.

6.2.4 Private Key backup and archival

Backup copies of CA private keys and Issuing CA private signing keys are stored in encrypted form using cryptographic modules that meet the requirements specified in CPS §6.2.1.

Where Subscriber private key backup and recovery are required by a Microsoft CP, such functions are performed in accordance with the CP. Unless required by a Microsoft CP, Subscriber private keys are not backed up or archived by the RMS Certification Hierarchy.

Where copies of Subscriber private keys are stored by the RMS Certification Hierarchy, such keys are stored in encrypted form with physical and logical access restricted to authorized individuals.

6.2.5 Private Key entry into cryptographic module

CA private keys are generated and used only within hardware cryptographic modules meeting the requirements of CPS §6.2.1. The private key exists outside hardware cryptographic modules only in encrypted form.

6.2.6 Method of activating private key

Hardware modules used for CA private key protection utilize a smart card based activation mechanism (Operator Card) as described in CPS §6.2.2.

Enrollment Agent private keys are stored on smart cards and protected by a pass phrase.

Smart card based Subscriber private keys are activated with a pass phrase in accordance with the applicable Microsoft CP. Software-based Subscriber private keys are activated by the Subscriber in accordance with the applicable CP, typically through the use of a pass phrase.

6.2.7 Method of deactivating private key

CA private keys are de-activated by removing the corresponding Operator Card from the card reader.

Enrollment Agent keys are de-activated upon logout from the Issuing CA application or removal of their smart card from the reader.

Subscriber private keys are deactivated after each usage if the “High Security Option” is set or otherwise upon operating system log off.

6.2.8 Method of destroying private key

CA private key destruction requires the participation of multiple trusted RMS Certification Hierarchy employees and approval from the RMS Certification Hierarchy Committee and management. When CA key destruction is required, private keys stored in cryptographic modules (if applicable) may be completely destroyed through zeroization and/or physical destruction of the device in accordance with manufacturers’ guidance. Where CA private keys are stored on other media, such keys are stored in encrypted form. Where destruction of such encrypted private keys is required, the encrypted private keys should be securely overwritten or the storage medium physically destroyed.

6.3 Other Aspects of Key Pair Management

6.3.1 Public key archival

Copies of CA and Subscriber certificates are archived in accordance with CPS §4.6.

6.3.2 Usage periods for the public and private keys

For RMS Certification Hierarchy CAs and Subscribers, key and certificate usage periods meet the following requirements.

Entity	Maximum Key Usage Period (for certificate signing)	Maximum Key Usage Period (for CRL signing)	Maximum Certificate Validity Period
Microsoft RMS Production / ISV Root	11 years	13 years	13 years

Microsoft RMS Production / ISV CA	11 years	13 years	13 years
Microsoft RMS Production / ISV Application Signing Server CA	11 years	13 years	13 years

Microsoft RMS Production / ISV Machine Activation Server CA	11 years	13 years	13 years
Microsoft RMS Production / ISV Server Enrollment CA	11 years	13 years	13 years
Microsoft RMS Production / ISV Licensing Server CA	11 years	13 years	13 years
Microsoft RMS Production / ISV Account Certification Server CA	11 years	13 years	13 years
Microsoft RMS Production / ISV Manifest Signing Key CA	11 years	13 years	13 years

Microsoft RMS Production / ISV Machine Activation Service	11 years	13 years	13 years
Microsoft RMS Production / ISV Server Enrollment Service	11 years	13 years	13 years
Microsoft RMS Production Licensing Service	11 years	13 years	13 years
Microsoft RMS Production / ISV Account Certification Service	11 years	13 years	13 years

6.4 Activation Data

Hardware modules used for CA private key protection utilize a smart card based activation mechanism (Operator Card) as described in CPS §6.2.2. These cards are used only when needed and stored in a secure site when not in use.

6.5 Computer Security Controls

The RMS Certification Hierarchy uses industry standard CA software, PKI applications, cryptographic modules, and smart cards. The Microsoft corporate network as a whole is protected by industry standard intrusion detection systems and firewalls.

The Administrator account is not used for routine system operations. Each user requiring access to RMS Certification Hierarchy systems is set up as a domain administrator. Accounts are not shared.

6.6 Life Cycle Technical Controls

No stipulation.

6.7 Network Security Controls

The Microsoft corporate network as a whole is protected by industry standard intrusion detection systems (IDS) and firewalls. A corporate IDS team monitors Microsoft’s global operations.

6.8 Cryptographic Module Engineering Controls

The RMS Certification Hierarchy uses cryptographic modules that meet the requirements of CPS §6.2.1.

7 Certificate and CRL Profiles

7.1 Certificate Profile

The RMS Certification Hierarchy uses certificates according to the certificate profile described in the XrML 1.2.1 specification. The XrML 1.2.1 specification can be found at http://www.xrml.org/XrML_12.asp. Registration is required.

7.1.1 Version number(s)

The RMS Certification Hierarchy issues certificates according to the XrML 1.2.1 specification.

7.1.2 Certificate extensions

No stipulation.

8 Specification Administration