Microsoft Corporation
Rights Management System Public Key Infrastructure
Certification Practice Statement
Version 1.0
September 2003

Table of Contents

1          Introduction

1.1       Overview 
1.2       Identification
1.3       Community and Applicability

1.3.1    Certification Authorities
1.3.2    Registration Function
1.3.3    End Entities 
1.3.4    Applicability 

1.4       Contact Details 

2          General Provisions 

2.1       Obligations 

2.1.1    RMS-PKI Committee Obligations 
2.1.2    Certification Authority obligations 
2.1.3    Issuing CA obligations 
2.1.4    Subscriber obligations 
2.1.5    Relying Party obligations 

2.2       Liability 

2.2.1    Warranties and limitations on warranties 
2.2.2    Disclaimers 
2.2.3    Loss limitations 
2.2.4    Other Exclusions 

2.3       Financial Responsibility 

2.3.1    Indemnification by Relying Parties 
2.3.2    Fiduciary relationships 
2.3.3    Administrative processes 

2.4       Interpretation and Enforcement

2.4.1    Governing law  
2.4.2    Severability, survival, merger and notice 
2.4.3    Dispute resolution procedures 

2.5       Fees 
2.6       Publication and Repository 

2.6.1    Publication of CA information 
2.6.2    Frequency of publication 
2.6.3    Access controls 
2.6.4    Repositories 

2.7       Compliance Audit

2.7.1    Frequency of entity compliance audit
2.7.2    Identity/qualifications of auditor
2.7.3    Auditor's relationship to audited party 
2.7.4    Topics covered by audit
2.7.5    Actions taken as a result of deficiency 
2.7.6    Communication of results 

2.8       Confidentiality and Privacy 

2.8.1    Types of information to be kept confidential
2.8.2    Types of information not considered confidential
2.8.3    Disclosure of certificate revocation information 
2.8.4    Release to law enforcement officials 
2.8.5    Release as part of civil discovery 
2.8.6    Disclosure upon owner's request
2.8.7    Other information release circumstances 

2.9       Intellectual Property Rights 

3          Identification and Authentication 

3.1       Initial Registration 

3.1.1    Types of names 
3.1.2    Need for names to be meaningful
3.1.3    Rules for interpreting various name forms 
3.1.4    Name claim dispute resolution procedure 
3.1.5    Recognition, authentication and role of trademarks 
3.1.6    Method to prove possession of private key 
3.1.7    Authentication of organization (machine) identity 
3.1.8    Authentication of individual identity 

3.2       Routine Rekey 
3.3       Rekey After Revocation 
3.4       Certificate Renewal
3.5       Revocation Request
3.6       Suspension Request
3.7       Request to Release Suspension 

4          Operational Requirements 

4.1       Certificate Application 
4.2       Certificate Issuance 
4.3       Certificate Acceptance 
4.4       Certificate Suspension and Revocation 

4.4.1    Circumstances for revocation 
4.4.2    Who can request revocation 
4.4.3    Procedure for revocation request or suspension request
4.4.4    Revocation request grace period 
4.4.5    Circumstances for suspension 
4.4.6    Who can request suspension 
4.4.7    Procedure for suspension request
4.4.8    Limits on suspension period 
4.4.9    CRL issuance frequency 
4.4.10  CRL checking requirements 
4.4.11  On-line revocation/status checking availability 
4.4.12  On-line revocation checking requirements 
4.4.13  Other forms of revocation advertisements available 
4.4.14  Checking requirements for other forms of revocation advertisements 
4.4.15  Special requirements for key compromise 

4.5       Security Audit Procedures (Logical and Physical)

4.5.1    Types of events recorded 
4.5.2    Frequency of processing log 
4.5.3    Retention period for audit log 
4.5.4    Protection of audit log 
4.5.5    Audit log backup procedures 
4.5.6    Audit collection system (internal vs. external)
4.5.7    Notification to event-causing subject
4.5.8    Vulnerability assessments 

4.6       Records Archival

4.6.1    Types of event recorded 
4.6.2    Retention period for archive 
4.6.3    Protection of archive 
4.6.4    Archive backup procedures 
4.6.5    Requirements for time-stamping of records 
4.6.6    Archive collection system (internal or external)
4.6.7    Procedures to obtain and verify archive information 

4.7       Key Changeover
4.8       Disaster Recovery and Business Resumption 
4.9       CA Termination 

5          Physical, Procedural and Personnel Security Controls 

5.1       Physical Controls 

5.1.1    Site location and construction 
5.1.2    Physical access 
5.1.3    Power and air conditioning 
5.1.4    Water exposures 
5.1.5    Fire prevention and protection 
5.1.6    Media storage 
5.1.7    Offsite backup 
5.1.8    Waste disposal

5.2       Procedural Controls 

5.2.1    Trusted roles 
5.2.2    Number of persons required per task 
5.2.3    Identification and authentication for each role 

5.3       Personnel Controls 

5.3.1    Background, qualifications, experience, and clearance requirements 
5.3.2    Background check procedures 
5.3.3    Training requirements 
5.3.4    Retraining frequency and requirements 
5.3.5    Job rotation frequency and sequence 
5.3.6    Sanctions for unauthorized actions 
5.3.7    Contracting personnel requirements 
5.3.8    Documentation supplied to personnel

6          Technical Security Controls 

6.1       Key Pair Generation 

6.1.1    Key pair generation 
6.1.2    Private Key delivery to entity 
6.1.3    Public key delivery to certificate issuer
6.1.4    CA public key delivery to users 
6.1.5    Key sizes 
6.1.6    Public key parameters generation and quality checking 
6.1.7    Hardware/software key generation 
6.1.8    Key usage purposes 

6.2       CA Private Key Protection 

6.2.1    Standards for cryptographic module 
6.2.2    Private key multi-person control
6.2.3    Private Key escrow  
6.2.4    Private key backup and archival
6.2.5    Private Key entry into cryptographic module 
6.2.6    Method of activating private key 
6.2.7    Method of deactivating private key 
6.2.8    Method of destroying private key 

6.3       Other Aspects of Key Pair Management

6.3.1    Public key archival
6.3.2    Usage periods for the public and private keys 

6.4       Activation Data 
6.5       Computer Security Controls 
6.6       Life Cycle Technical Controls 
6.7       Network Security Controls 
6.8       Cryptographic Module Engineering Controls 

7          Certificate and CRL Profiles 

7.1       Certificate Profile 

7.1.1    Version number(s)
7.1.2    Certificate extensions 
7.1.3    Algorithm object identifiers
7.1.4    Name forms
7.1.5    Name constraints
7.1.6    Certificate Policy Object Identifier
7.1.7    Usage of Policy Constraints extension
7.1.8    Policy qualifiers syntax and semantics

8          Specification Administration

8.1       Specification change procedures
8.2       Publication and notification policies
8.3       Microsoft Certificate Policies

1  Introduction

The Rights Management Public Key Infrastructure (RMS-PKI), 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

This Certification Practice Statement (CPS) describes the practices of the RMS-PKI and applies to all Certification Authorities (CAs) within the Rights Management System PKI hierarchy.  This CPS is applicable to all entities with relationships with the RMS-PKI, including Certification Authorities (CAs), Policy Authorities (PAs), Subscribers, and Relying Parties.

The current Rights Management System PKI Hierarchy is displayed below.

The RMS-PKI consists of two independent PKI hierarchies: the Pre-Production hierarchy (also known as the ISV hierarchy) and the Production hierarchy.

The purpose of the Pre-Production hierarchy is to provide developers with a separate but fully functional RM system that they can use to build and test RM-enabled applications. This guarantees that applications under development or test RMS servers in the Pre-Production hierarchy cannot access the valuable information secured by the Production hierarchy.

1.2  Identification

This document is formally referred to as the “Rights Management System PKI Certification 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-PKI 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.

1.3.1  Certification Authorities

Certification Authorities (CAs) 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
• Provide a repository where certificates and certificate status information are stored and made available.

Within the RMS-PKI, 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 RM Production Root	Root CA that serves as the “trust anchor” for the main RMS PKI hierarchy.
Microsoft RM ISV Root	Root CA that serves as the “trust anchor” for the hierarchy used for test purposes by 3rd party ISVs during application development.

1.3.1.2   Intermediate (Policy) CAs
 

CA Name	Description of Function
Microsoft RM Production CA	Subordinate CA which sits at the top of the Production RMS-PKI.
Microsoft RM Production Application Signing Server CA	Subordinate CA which issues only to the RM Production Application Signing CA.
Microsoft RM Production Licensing CA	Subordinate CA which issues only to the RM Production Licensing Service.
Microsoft RM Production Account Certification CA	Subordinate CA which issues only to the RM Production Account Certification Service.
Microsoft RM Production Machine Activation CA	Subordinate CA which issues only to the RM Production Machine Activation Service.
Microsoft RM Production Server Enrollment CA	Subordinate CA which issues only to the RM Production Server Enrollment Service.
Microsoft RM ISV CA	Subordinate CA which sits at the top of the Pre-Production RMS-PKI.
Microsoft RM ISV Application Signing Server CA	Subordinate CA which issues only to the RM ISV Application Signing CA.
Microsoft RM ISV Account Certification CA	Subordinate CA which issues only to the RM ISV Account Certification Service.
Microsoft RM ISV Machine Activation CA	Subordinate CA which issues only to the RM ISV Machine Activation Service.
Microsoft RM ISV Server Enrollment CA	Subordinate CA which issues only to the RM 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 RM 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 RM 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 RM Production / ISV Account Certification Service	Issue certificates to individuals for: Passport user identity associated with a valid Passport ID
Microsoft RM Production / ISV Machine Certificate Service	Issue certificates to individuals for: RMS client application security
Microsoft RM Production / ISV Server Enrollment Service	Issues certificates to individuals for: RMS Server licenses
Microsoft RM Production Licensing Service	Issues licenses to individuals for: trials of the Office Systems 2003 Information Rights Management (IRM) features.

1.3.2  Registration Function

Issuing CAs perform most typical PKI registration functions, e.g. evaluate and either approve or reject Subscriber certificate management transactions (including certificate requests, renewal and rekey requests, and revocation requests).  The RMS-PKI 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-PKI Root and Intermediate CAs, the Subscribers are Subordinate CAs which are under the control of the RMS-PKI.  Accordingly, the registration function for these CAs is performed manually by authorized RMS-PKI personnel.

1.3.2.2   Registration Functions for Issuing CAs

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

• Microsoft RM Production Account Certification Service
• Microsoft RM Production Machine Certificate Service
• Microsoft RM Production Server Enrollment Service
• Microsoft RM Production Licensing Service
• Microsoft RM ISV Account Certification Service
• Microsoft RM ISV Machine Certificate Service
• Microsoft RM 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 RM 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-PKI hierarchy.
Microsoft RM 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 and Client Licensor Certificates (CLC) which are used to create RM protected content.
Microsoft RM 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 RM 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 RM Production Licensing Service	An automated service that issues XrML 1.2 licenses based on presentation of a Rights Management Account Certificate (RAC). This service is used to support trials of the Office Systems 2003 Information Rights Management (IRM) features.
Microsoft RM ISV 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 Pre-Production (ISV) hierarchy.
Microsoft RM 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 RM protected content during application development.
Microsoft RM 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 RM 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.

1.3.3  End Entities

End Entities include Subscribers and Relying Parties.  Subscribers typically include members of the general public who are licensees of Microsoft products incorporating Rights Management.  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, etc.

1.3.4  Applicability

This CPS is applicable to all certificates issued by Microsoft RMS CAs within the RMS-PKI.  Microsoft RMS Certificate Policies (CPs) define the specific communities for which a specific class or type of certificate is applicable, specific RMS-PKI 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-PKI Committee, which serves as the “Policy Authority” for the RMS-PKI and ensures that the practices specified in the Microsoft RMS CPS do not conflict with CP requirements.

The RMS-PKI Committee consists of representatives from the Microsoft Law & Corporate Affairs Department and Security Business Unit.

2  General Provisions

2.1  Obligations

2.1.1  RMS-PKI Committee Obligations

Obligations of the RMS-PKI 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 PKI include:

• Subscribing to one or more 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.2.1   Repository

In providing Repository services, obligations of the Microsoft RMS PKI 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.1.3  Issuing CA obligations

• Obligations of the Issuing CAs within the Microsoft RMS PKI 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
• 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 PKI include:

• Generating or causing to be generated one or more asymmetric key pairs
• Submitting 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 measures to protect their private keys from compromise
• Promptly reporting loss or compromise of private key(s) and inaccuracy of certificate information
• Using its key pair(s) in conjunction with authorized applications in compliance with applicable policies

2.1.5  Relying Party obligations

Obligations of Relying Parties within the Microsoft RMS PKI include:

• Confirming the validity of subscriber public-key certificates
• 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.

2.2  Liability

2.2.1  Warranties and limitations on warranties

The RMS-PKI warrants and promises to provide certification authority services substantially in compliance with this CPS and the relevant Microsoft Certificate Policies.  The RMS-PKI makes no other warranties or promises and has no further obligations to subscribers or relying parties, except as set forth under this CPS.

2.2.2  Disclaimers

Except for express warranties stated in this CPS, the RMS-PKI disclaims all other warranties, promises and other obligations.  In addition, the RMS-PKI is not liable for any loss:

• of CA or Issuing CA services due to war, natural disasters or other uncontrollable forces;
• incurred between the time a certificate is revoked and the next scheduled issuance of a CRL;
• due to unauthorized use of certificates issued by the RMS-PKI, or use of certificates beyond the prescribed use defined by this CPS and the relevant Microsoft Certificate Policy;
• arising from the negligent or fraudulent use of certificates or CRLs issued by the RMS-PKI; or
• due to disclosure of personal information contained within certificates or CRLs.

2.2.3  Loss limitations

In no event shall the RMS-PKI 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 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-PKI has been advised of the possibility of such damages.

2.2.4  Other Exclusions

No stipulation.

2.3  Financial Responsibility

2.3.1  Indemnification by Relying Parties

No stipulation.

2.3.2  Fiduciary relationships

The RMS-PKI is not the agent, fiduciary, trustee, or other representative of subscribers or 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

This CPS shall be binding on all successors of the parties.

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.

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.

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.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-PKI management regarding the dispute.  RMS-PKI 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. 

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-PKI personnel the ability to write to or modify repository content.

2.6.4  Repositories

The RMS-PKI repository consists of Microsoft Corporation Internet website and the RMS-PKI 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-PKI.

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-PKI 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-PKI Committee with input from the auditor.  RMS-PKI 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-PKI, RMS-PKI Management will consider, with input from the auditor, whether suspension of the RMS-PKI’s operation is warranted.  Should a severe deficiency be identified that might compromise the integrity of a particular CA, RMS-PKI 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-PKI 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-PKI information must remain confidential to Microsoft.  The following information is considered confidential to Microsoft and may not be disclosed:

• RMS-PKI 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-PKI hierarchy
• Compliance audit results
• Contracts.

2.8.2  Types of information not considered confidential

The RMS-PKI may publish Certificate information and CRLs relating to RMS-PKI 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-PKI 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.

2.8.3  Disclosure of certificate revocation information

The fact that a particular RMS-PKI 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.  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-PKI 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.

2.8.5  Release as part of civil discovery

As a general principal, no document or record belonging to or controlled by the RMS-PKI 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-PKI
• Certificates and CRLs issued by Microsoft CAs
• Distinguished Names (DNs) used to represent entities within the RMS-PKI
• 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 Distinguished Name for all RMS-PKI Certificates and the Subject Distinguished Name for all RMS-PKI CA Certificates is populated as follows:

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

For RACs, the principal is identified using an email address and the Passport ID.

For SLC, the URL of  the server, the full Subject DN, Issuer DN, and the Serial number  in the X.509 cert are also stored.

For Application Signing cerificates, 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-PKI 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-PKI 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-PKI Committee is required before the request can be processed by the RMS-PKI.

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

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.

4.4  Certificate Suspension and Revocation

The RMS-PKI supports certificate revocation for RMS-PKI CAs if required by a specific Microsoft CP.  The RMS-PKI 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

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.
• 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.
• The Subscriber or other authorized party requests certificate revocation in accordance with CPS §3.5 and specific provisions of a Microsoft CP.

4.4.2  Who can request revocation

Subscriber certificate revocation can be initiated by the Subscriber, an authorized Issuing CA, the RMS-PKI, 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-PKI:

• 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-PKI Committee is required before the request can be processed by the RMS-PKI.

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 business days for manual requests.  The RMS-PKI 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 in accordance with the following table.

CA Type	CRL Publication Frequency
Root RMS CA	Every 31 days
Intermediate (Policy) CA(s)	Every 31 days
Issuing CA(s)	Every 31 days ion

4.4.10   CRL checking requirements

Relying Parties are required to check certificate status using the applicable CRL before relying upon a 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    Checkingrequirements 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-PKI uses commercially reasonable efforts to notify potential Relying Parties if the RMS-PKI discovers, or has reason to believe, that there has been a compromise of a RMS-PKI CA private key.

4.5  Security Audit Procedures (Logical and Physical)

4.5.1  Types of events recorded

The RMS-PKI 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-PKI 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-PKI employees.

4.5.7  Notification to event-causing subject

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

Microsoft’s corporate security group must notify the RMS-PKI team when an alarm occurs at the RMS-PKI 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-PKI maintains an archive of relevant records for each CA.

4.6.1  Types of event recorded

For each CA, the RMS-PKI archives CA key generation records and CA certificates.

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-PKI 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-PKI maintains offsite backups of CA systems, data, 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-PKI 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-PKI CA, RMS-PKI 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-PKI 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-PKI 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-PKI 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-PKI 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-PKI 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-PKI systems are considered to serve in “trusted roles.”  Within the RMS-PKI organization, the following trusted roles exist:

• RMS PKI Engineering/Architecture, responsible for the design and implementation of RMS-PKI 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-PKI 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-PKI 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-PKI 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-PKI 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-PKI must be authorized to perform such functions and must satisfy the personnel requirements specified in CPS §5.3.

5.3  Personnel Controls

The RMS-PKI 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-PKI 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-PKI 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-PKI employees are required to sign a nondisclosure agreement and are required to adhere to RMS-PKI policies and procedures.

5.3.3  Training requirements

All RMS-PKI personnel receive on the job training covering:

• Basic PKI concepts
• Documented RMS-PKI 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-PKI personnel receive formal or informal training on the use of deployed PKI products and RMS-PKI 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-PKI policies and procedures.  

5.3.7  Contracting personnel requirements

RMS-PKI may employ contractors as necessary.  Where contractors are used by the RMS-PKI, 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-PKI personnel are required to read this CPS.  They are also provided with RMS-PKI 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-PKI team and the Microsoft Law and Corporate Affairs Group.

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

Subscriber key pair generation may be performed by the RMS-PKI 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-PKI.

Where subscriber key pairs are generated by the RMS-PKI, 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-PKI 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-PKI 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-PKI CA certificates may be made available to relevant subscribers and relying parties through other mechanisms.  

6.1.5  Key sizes

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

Not applicable.

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-PKI 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-PKI’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

The escrow of CA and Subscriber private keys, for purposes of access by law enforcement, is not supported by the RMS-PKI.

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

Where copies of Subscriber private keys are stored by the RMS-PKI, 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 passphrase.

Smart card based Subscriber private keys are activated with a passphrase 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 passphrase. 

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-PKI employees and approval from the RMS-PKI 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-PKI 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 RM Production / ISV Root	5 years	12 years	12 years
Microsoft RM Production / ISV CA	5 years	12 years	12 years
Microsoft RM Production / ISV Application Signing Server CA	5 years	12 years	12 years
Microsoft RM Production / ISV Machine Activation Server CA	5 years	12 years	12 years
Microsoft RM Production / ISV Server Enrollment CA	7 years	12 years	12 years
Microsoft RM Production / ISV Licensing Server CA	2 years	7 years	7 years
Microsoft RM Production / ISV Account Certification Server CA	2 years	7 years	7 years
Microsoft RM Production / ISV Manifest Signing Key CA	5 years	12 years	12 years
Microsoft RM Production / ISV Machine Activation Service	2 years	7 years	7 years
Microsoft RM Production / ISV Server Enrollment Service	2 years	7 years	7 years
Microsoft RM Production Licensing Service	2 years	7 years	7 years
Microsoft RM Production / ISV Account Certification Service	2 years	7 years	7 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-PKI 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-PKI 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-PKI uses cryptographic modules that meet the requirements of CPS §6.2.1.

7  Certificate and CRL Profiles

7.1  Certificate Profile

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

7.1.1  Version number(s)

The RMS-PKI issues certificates according to the XrML 1.2 specification.

7.1.2  Certificate extensions

The RMS-PKI populates certificates with the extensions required by this section.

7.1.2.1   Key Usage

All RMS-PKI CA certificates utilize the Key Usage extension as non-critical with the Digital Signature, Nonrepudiation, Key Certificate Signature, and CRL Signature bits set.

For Subscriber certificates, the RMS-PKI populates the Key Usage extension in accordance with the applicable Microsoft Certificate Policy.

7.1.2.2   Certificate Policies Extension

RMS-PKI CA certificates do not use the Certificate Policies extension.

For Subscriber certificates, CP Object Identifiers (OIDs) are included in the certificate extension field if required by the applicable Microsoft CP.

7.1.2.3   Subject Alternative Names

RMS-PKI certificates do not use the Subject Alternative Names extension.

7.1.2.4   Basic Constraints

All RMS-PKI CA certificates utilize the Basic Constraints extension as critical with the subject type set to CA and no path length constraints.

For Subscriber certificates, the Basic Constraints extension is utilized if required by the applicable Microsoft CP.

7.1.2.5   Extended Key Usage

RMS-PKI CA certificates do not use the Extended Key Usage extension.

For Subscriber certificates, the Extended Key Usage extension is utilized if required by the applicable Microsoft CP.

7.1.2.6   CRL Distribution Points

All RMS-PKI CA certificates utilize the CRL Distribution Points extension configured in accordance with the table below.

CA Type	CRL Locations
RMS Root CA	Via update patch distributed at http://windowsupdate.microsoft.com (for users of Windows Server 2003 only) http://www.microsoft.com/download for all other users.
Intermediate Policy CAs	Via update patch distributed at http://windowsupdate.microsoft.com (for users of Windows Server 2003 only) http://www.microsoft.com/download for all other users.
Issuing CAs	Via update patch distributed at http://windowsupdate.microsoft.com (for users of Windows Server 2003 only) http://www.microsoft.com/download for all other users.

For Subscriber certificates, the CRL Distribution Points extension is utilized if required by the applicable Microsoft CP.

7.1.2.7   Authority Key Identifier

All RMS-PKI CA certificates, except for the Root CA certificate, utilize the Authority Key Identifier extension set to non-critical and populated with the 160-bit SHA-1 hash of the public key of the CA issuing the certificate.

For Subscriber certificates, the Authority Key Identifier extension is utilized if required by the applicable Microsoft CP.

7.1.2.8   Subject Key Identifier

All RMS-PKI CA certificates utilize the Subject Key Identifier extension set to non-critical and populated with the 160-bit SHA-1 hash of the public key of the certificate subject.

For Subscriber certificates, the Subject Key Identifier extension is utilized if required by the applicable Microsoft CP.

7.1.2.9   Authority Information Access

All RMS-PKI CA certificates utilize the Authority Information Access extension set to Certification Authority Issuer (1.3.6.1.5.5.7.48.2) and configured in accordance with the table below.

CA Type	AIA Information Locations
RMS Root CA
Intermediate Policy CAs
Issuing CAs

For Subscriber certificates, the Authority Information Access extension is utilized if required by the applicable Microsoft CP.

7.1.3  Algorithm object identifiers

TBD

7.1.4  Name forms

See CPS §3.1.1.

7.1.5  Name constraints

No stipulation.

7.1.6  Certificate Policy Object Identifier

See CPS §7.1.2.2.

7.1.7  Usage of Policy Constraints extension

No stipulation.

7.1.8  Policy qualifiers syntax and semantics

No stipulation.

8  Specification Administration

8.1  Specification change procedures

Modifications to this CPS are approved by the RMS-PKI Committee and become effective upon publication in the RMS-PKI repository.

8.2  Publication and notification policies

This CPS and subsequent revisions are published in the RMS-PKI repository in accordance with CPS §2.6.1.

8.3  Microsoft Certificate Policies

Microsoft CPs are specified and approved by the RMS-PKI Committee which is also responsible for disseminating Microsoft Certificate Policies and subsequent revisions to the appropriate Subscribers and Relying Parties.