1 THE RSA ROOT SIGNING SERVICE Certification Practice Statement For RSA Certificate Authorities (CAs) Last Revision Date: June 28, 2007 Version: 3.0 Published By: RSA Security Inc.
2 Copyright by RSA Security Inc. All rights reserved. No part of this document may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without prior written permission of RSA Security Inc. THIS DOCUMENT IS CONFIDENTIAL AND MAY NOT BE DISTRIBUTED UNLESS AUTHORIZED BY RSA Security Inc. BSAFE, RSA, SecurCare and SecurID are registered trademarks, and RSA Security Inc., Confidence Inspired and the RSA logo are trademarks of RSA Security Inc. All other trademarks mentioned herein are the property of their respective owners. RSA Security, The Security Division of EMC 2 heretofore known as RSA Security Inc; shall be referenced in the text of the pages that follow as "RSA". RSA Security Inc. ii 6/28/2007
3 Revision History Version Date Author s initials Description of changes /7/24 MS Initial release /7/26 MS Incremental changes /7/27 MS Added architecture /7/31 MS Added logical diagram /8/07 MS Physical controls, termination, disaster recovery (severity), compliance review, application /8/8 MS Name claim dispute resolution /8/14 MS Marketing content in Part A, changed to the RSA ROOT SIGNING SERVICE CPS for issuing certificates to CAs only /8/15 MS, TS Added Tom Strickland s section 2.7, 4.5 and 4.6, adjusted section 3.1.6, /9/6 MS Created CPS for online root (CPS2) Removed and limited sections dealing with end entities, RAs and subcas /9/13 MS Clean up of terms, adjustments to Compliance Review to make it easier for customers, clean up of must to will in sections /10/2 MS Change name from RSA CA to RSA PUBLIC ROOT CA V1. Add changes from Andrew Nash. Add tier diagram to overview section /10/15 MS Changes to CPS to reflect new direction chaining service offering only /11/16 MS Incorporate comments from Beth MacMonigle, revised section 4.5 to more clearly define audit logs collected /12/06 DF Minor revision to clarify Service provider requirements /12/07 MS Minor revisions in section 7 to clarify key bit assertions for path length and basic constraints /2/7 MS Major revisions to include CA Operations processes, RSA Administration Processes, Customer Processes and updated EDS facility procedures and policies /2/28 MS Added the to the front of RSA ROOT SIGNING SERVICE where appropriate /2/28 DF Promoted to final version from draft /3/31 MS Modifications to CPS to conform to Web Trust requirements /8/26 DF Change to section 4.9 regarding CA termination and changed company name to RSA Inc /11/27 DF Update in preparation for conversion to 3647 Removed Keon brand reference. Incorporated the operation of the RSA 2048 v3 root /14/2005 DF Converted to RFC3647 format/ 3.0 6/28/2007 DF Incorporation of EV certificate validation. RSA Security Inc. iii 4/17/2007
4 Table of Contents OVERVIEW... 1 THE RSA ROOT SIGNING SERVICE PUBLIC KEY INFRASTRUCTURE HIERARCHY... 2 CPS SPECIFICATION INTRODUCTION OVERVIEW DOCUMENT NAME AND IDENTIFICATION PKI PARTICIPANTS Certification authorities Registration authorities Subscribers Relying parties Other participants CERTIFICATE USAGE Appropriate certificate uses Prohibited certificate uses POLICY ADMINISTRATION Organization administering the document Contact person Person determining CPS suitability for the policy CPS approval procedures DEFINITIONS AND ACRONYMS PUBLICATION AND REPOSITORY RESPONSIBILITIES REPOSITORIES PUBLICATION OF CERTIFICATION INFORMATION TIME OR FREQUENCY OF PUBLICATION ACCESS CONTROLS ON REPOSITORIES IDENTIFICATION AND AUTHENTICATION NAMING Types of names Need for names to be meaningful Anonymity or pseudonymity of subscribers Rules for interpreting various name forms Uniqueness of names Recognition, authentication, and role of trademarks INITIAL INDENTITY VALIDATION Method to prove possession of private key Authentication of organization identity Authentication of individual identity Non-verified subscriber information Validation of authority Criteria for interoperation IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS Identification and authentication for routine re-key Identification and authentication for re-key after revocation IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS CERTIFICATE APPLICATION RSA Security Inc. iv 6/28/2007
5 4.1.1 Who can submit a certificate application Enrollment process and responsibilities CERTIFICATE APPLICATION PROCESSING Performing identification and authentication functions Approval or rejection of certificate applications Time to process certificate applications CERTIFICATE ISSUANCE CA actions during certificate issuance Notification to subscriber by the CA of issuance of certificate CERTIFICATE ACCEPTANCE Conduct constituting certificate acceptance Publication of the certificate by the CA Notification of certificate issuance by the CA to other entities KEY PAIR AND CERTIFICATE USAGE Subscriber private key and certificate usage Relying party public key and certificate usage CERTIFICATE RENEWAL Circumstance for certificate renewal Who may request renewal Processing certificate renewal requests Notification of new certificate issuance to subscriber Conduct constituting acceptance of a renewal certificate Publication of the renewal certificate by the CA Notification of certificate issuance by the CA to other entities CERTIFICATE RE-KEY Circumstance for certificate re-key Who may request certification of a new public key Processing certificate re-keying requests Notification of new certificate issuance to subscriber Conduct constituting acceptance of a re-keyed certificate Publication of the re-keyed certificate by the CA Notification of certificate issuance by the CA to other entities CERTIFICATE MODIFICATION Circumstance for certificate modification Who may request certificate modification Processing certificate modification requests Notification of new certificate issuance to subscriber Conduct constituting acceptance of a renewal certificate Publication of the modified certificate by the CA Notification of certificate issuance by the CA to other entities CERTIFICATE REVOCATION AND SUSPENSION Circumstances for revocation Who can request revocation Procedure for revocation request Revocation request grace period Time within which CA must process the revocation request Revocation checking requirement for relying parties CRL issuance frequency Maximum latency for CRLs Online revocation/status checking availability Online revocation checking requirements Other forms of revocation advertisements available Special requirements re key compromise Circumstances for suspension Who can request suspension Procedure for suspension request RSA Security Inc. v 6/28/2007
6 Limits on suspension period CERTIFICATE STATUS SERVICES Operational characteristics Service availability Optional features END OF SUBSCRIPTION KEY ESCROW AND RECOVERY Key escrow and recovery policy and practices Session key encapsulation and recovery policy and practices FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS PHYSICAL CONTROLS Site location, construction and physical access PROCEDURAL CONTROLS CA Trusted roles Number of persons required per task Identification and authentication for each role Roles requiring separation of duties PERSONNEL CONTROLS Qualifications, experience, and clearance requirements Background check procedures Training requirements Retraining frequency and requirements Job rotation frequency and sequence Sanctions for unauthorized actions Independent contractor requirements Documentation supplied to personnel AUDIT LOGGING PROCEDURES Types of Events Recorded Frequency of processing data Retention period for Audit Log Protection of Audit Log Audit Log backup procedures Audit collection system (internal vs. external) Notification to event-causing subject Vulnerability Assessments RECORDS ARCHIVAL Types of events archived Retention period for archive Protection of archive Archive backup procedures Requirements for Time-Stamping of Records KEY CHANGEOVER COMPROMISE AND DISASTER RECOVERY CA TERMINATION RSA CAs termination Participating CA termination TECHNICAL SECURITY CONTROLS KEY PAIR GENERATION AND INSTALLATION Key pair generation Private key delivery to subscriber Public key delivery to certificate issuer CA public key delivery to relying parties Key sizes Public key parameters generation and quality checking RSA Security Inc. vi 6/28/2007
7 6.1.7 Key usage purposes (as per X.509 v3 key usage field) PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS Cryptographic module standards and controls Private key (n out of m) multi-person control Private key escrow Private key backup Private key archival Private key transfer into or from a cryptographic module Private key storage on cryptographic module Method of activating private key Method of deactivating private key Method of destroying private key Cryptographic Module Rating OTHER ASPECTS OF KEY PAIR MANAGEMENT Public key archival Certificate operational periods and key pair usage periods ACTIVATION DATA Activation data generation and installation Activation data protection Other aspects of activation data COMPUTER SECURITY CONTROLS Specific computer security technical requirements Computer security rating LIFE CYCLE TECHNICAL CONTROLS System development controls Security management controls Life cycle security controls NETWORK SECURITY CONTROLS TIME-STAMPING CERTIFICATE, CRL, AND OCSP PROFILES CERTIFICATE PROFILE Version number(s) Certificate extensions Algorithm object identifiers Name forms Name constraints Certificate policy object identifier Usage of Policy Constraints extension Policy qualifiers syntax and semantics Processing semantics for the critical Certificate Policies extension CRL PROFILE Version number CRL and CRL entry extensions OCSP PROFILE Version number(s) OCSP extensions COMPLIANCE AUDIT AND OTHER ASSESSMENTS Compliance Audit IDENTITY/QUALIFICATIONS OF ASSESSOR COMPLIANCE AUDITOR S RELATIONSHIP TO ASSESSED ENTITY TOPICS COVERED BY ASSESSMENT ACTIONS TAKEN AS A RESULT OF DEFICIENCY COMMUNICATION OF RESULTS RSA Security Inc. vii 6/28/2007
8 9 OTHER BUSINESS AND LEGAL MATTERS FEES Certificate issuance or renewal fees Certificate access fees Revocation or status information access fees Fees for other services Refund policy FINANCIAL RESPONSIBILITY Insurance coverage Other assets Insurance or warranty coverage for end-entities CONFIDENTIALITY OF BUSINESS INFORMATION Scope of confidential information Information not within the scope of confidential information Responsibility to protect confidential information PRIVACY OF PERSONAL INFORMATION Privacy plan Information treated as private Information not deemed private Responsibility to protect private information Notice and consent to use private information Disclosure pursuant to judicial or administrative process Other information disclosure circumstances INTELLECTUAL PROPERTY RIGHTS REPRESENTATIONS AND WARRANTIES CA representations and warranties RA representations and warranties Subscriber representations and warranties Relying party representations and warranties Representations and warranties of other participants DISCLAIMERS OF WARRANTIES LIMITATIONS OF LIABILITY INDEMNITIES TERM AND TERMINATION Term Termination Effect of termination and survival INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS AMENDMENTS Procedure for amendment Notification mechanism and period Circumstances under which OID must be changed DISPUTE RESOLUTION PROVISIONS Negotiation Mediation Arbitration or litigation GOVERNING LAW COMPLIANCE WITH APPLICABLE LAW MISCELLANEOUS PROVISIONS Entire agreement Assignment Severability Enforcement (attorneys' fees and waiver of rights) Force Majeure OTHER PROVISIONS RSA Security Inc. viii 6/28/2007
9 10 ACRONYMS DEFINITIONS...55 RSA Security Inc. ix 6/28/2007
10 OVERVIEW This Certification Practice Statement (CPS) defines the practices and procedures for the RSA ROOT SIGNING SERVICE in signing and issuing certificates to Participating CAs. This CPS is in conformance with the RSA ROOT SIGNING SERVICE Certificate Policy. This document describes how the Certificate Authorities (CAs) in the RSA ROOT SIGNING SERVICE, the RSA CAs, operate. This includes: RSA Root CA (1024v1), known as the ValiCert Class 3 Policy Validation Authority; RSA PUBLIC ROOT CA V1; RSA PUBLIC ROOT CA V2; and, RSA Root CA (2048v3). This document describes the relationships between the RSA Root CAs, the RSA PUBLIC ROOT CA V1 and Participating CAs but does not define how Participating CAs, and their associated RAs and end entities operate. Participating CAs is a term used to describe a CA chained to one of the RSA CAs. The RSA ROOT SIGNING SERVICE CPS generally conforms generally conforms to the IETF PKIX Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework (also known as RFC 3647). This document is divided into eight sections: Section 1 - Provides an overview of the policy and set of provisions, as well as the types of entities and the appropriate applications for certificates. Section 2 - Contains any applicable provisions regarding identification of the entity or entities that operate repositories; responsibility of a PKI participant to publish information regarding its practices, certificates, and the current status; frequency of publication; and access control on published information. Section 3 - Covers the identification and authentication requirements for certificate related activity. Section 4 - Deals with certificate life-cycle management and operational requirements including application for a certificate, revocation, suspension, audit, archival and compromise. Section 5 - Covers facility, management and operational controls (physical and procedural security requirements). Section 6 - Provides the technical controls with regard to cryptographic key requirements. Section 7 - Defines requirements for certificate, Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) formats. This includes information on profiles, versions, and extensions used. Section 8 - Addresses topics covered and methodology used for assessments/audits; frequency of compliance audits or assessments; identity and/or qualifications of the personnel performing the audit or assessment; actions taken as a result of deficiencies found during the assessment; and who is entitled to see results of an assessment. Section 9 - Covers general business and legal matters: the business issues of fees, liabilities, obligations, legal requirements, governing laws, processes, confidentiality, etc. RSA Security Inc. Page 1 6/28/2007
11 THE RSA ROOT SIGNING SERVICE Public Key Infrastructure Hierarchy The RSA Root CA (1024v1 - Valicert CA) and the RSA Public Root CA v1 operate in an off-line mode. The RSA Public Root CA v1 was implemented as an intermediate X.509 version 3 CA to the root and is used to sign Participating CAs. This allows the RSA ROOT SIGNING SERVICE to provide version 3 functionality to Participating CAs. Also, in compromise situations with the RSA Public Root CA v1, the RSA Root CA would be used to revoke the RSA Public Root CA v1 certificate and resign a new working CA to replace the RSA Public Root CA. The RSA Public Root CA v2 operates in an offline mode and has been implemented to sign Participating CAs, including Participating CAs that will issue Extended Validation certificates. The RSA Public Root CA v2 also has a trust relationship established with the RSA Root CA to provide ubiquity to users of earlier application releases. The RSA Root CA (2048v3) also operates in an offline mode, and is used to sign Participating CAs. As it is a X.509 version 3 CA, it was determined that no intermediate CA would be required in its hierarchy. All RSA CAs operating as part of the RSA ROOT SIGNING SERVICE must conform to the RSA ROOT SIGNING SERVICE Certificate Policy. All Participating CAs must have an associated CPS, and must conform to the RSA ROOT SIGNING SERVICE Certificate Policy. This CPS is applicable to the RSA CAs, but does not apply to the Participating CAs. In cases where there are differences in procedures based on CA, the section will specify which CA is being addressed. Otherwise the section applies to the RSA CAs. RSA with this CPS document and the accompanying CP addresses the requirements as set forth by the CA/Browser Forum Guidelines for Extended Validation Certificates (http://www.cabforum.org). RSA complies with the version of the EV Certificate Guidelines adopted by the WebTrust Certification Authorities Advisory Group as the basis for WebTrust EV audit criteria. The Guidelines describe in detail what a CA must do in order to issue EV SSL certificates. Information about the issuing organization is displayed in a compatible browser that provides the end user a trustworthy confirmation of the identity of the entity that controls the website they are accessing. RSA Security Inc. Page 2 6/28/2007
12 1 INTRODUCTION 1.1 Overview CPS SPECIFICATION The RSA ROOT SIGNING SERVICE Certificate Policy (CP) describes the legal, business and technical requirements for the RSA CAs. The Certification Practice Statement (CPS) describes how these requirements are met in issuing certificates to CAs that are to be chained to the RSA ROOT SIGNING SERVICE. This CPS does not provide details on the operation of the RSA CAs; rather it provides an overview of the practices. Details of the operations are found in supporting documents. 1.2 Document name and identification This document is titled the RSA ROOT SIGNING SERVICE Certification Practice Statement for RSA Certificate Authorities or RSA ROOT SIGNING SERVICE CPS The alphanumeric OID for the Certificate Policy is RSAChainingCP2. The object identifier (OID) used for certificates (except for EV certificates) issued under this CPS is: ; the OID for EV SSL certificates issued under this CPS is PKI participants The RSA CAs are operated as a Root CAs with certificates that have a high ubiquity on the Internet. High ubiquity in the context of certificates means that the Root CA certificate appears in most browsers as a Trusted Root Certificate Authority. The Trusted CA is the RSA Root CA (1024v1), with the friendly name ValiCert Class 3 Policy Validation Authority, or the RSA Root CA (2048v3) with the friendly name RSA Security 2048 v3. High ubiquity is good for applications such as and secure web services where interaction with many external organizations and links to a known and trusted root CA certificate is essential. Additional Root CAs may be added to the RSA ROOT SIGNING SERVICE as business requires. The RSA CAs will sign and issue certificates to Participating CAs Certification authorities The RSA Root CAs (1024v1 Valicert) operates under the RSA ROOT SIGNING SERVICE CP and has signed the RSA PUBLIC ROOT CA V1 certificate to bind the RSA PUBLIC ROOT CA V1 to the private key of the RSA Root CA. The RSA PUBLIC ROOT CA V1 operating under the RSA ROOT SIGNING SERVICE CP will sign certificates that bind Participating CAs to the private key of the RSA PUBLIC ROOT CA V1. The RSA PUBLIC ROOT CA V2 operating under the RSA ROOT SIGNING SERVICE CP will sign certificates that bind Participating CAs to the private key of the RSA PUBLIC ROOT CA V2. The RSA Root CA (2048 v3) operates under the RSA ROOT SIGNING SERVICE CP will sign certificates that bind Participating CAs to the private key of the RSA Root CA (2048 v3). Participating CAs may sign Signature and/or Confidential certificates for end entities, devices and applications as well as sign certificates for subordinate CAs. RSA Security Inc. Page 3 6/28/2007
13 1.3.2 Registration authorities There are no Registration Authorities associated with the RSA CAs. All identification and authentication requirements are performed at contract time for any RSA CA that signs a Participating CA. No identification and authentication requirements are required for the RSA Root CA (1024 v1) Subscribers For the purposes of this CPS a Subscriber is a Participating CA and is bound by all terms and conditions in the CP, the RSA Root Signing Agreement and applicable Statements of Work (SOW). Eligibility for a certificate is at the sole discretion of the RSA ROOT SIGNING SERVICE. The RSA CAs may administer any number of subscribers Relying parties A Relying Party is an entity that relies on a certificate or information about the certificate that is issued by the RSA CAs Other participants No stipulation. 1.4 Certificate usage This CPS is applicable to all certificates issued by the RSA CAs. The practices described in this CPS apply to the issuance, use of the certificates and the revocation of certificates of Participating CAs under the one of the RSA Root CAs. There may be a limitation on the chaining length of the Participating CA such that the CA cannot create additional sub-cas unless otherwise described in the RSA Root Signing Agreement. Any limitation of chaining length will be described in contractual obligations not in technical limitations Appropriate certificate uses The RSA CAs will issue certificates to participating CAs which will in-turn allow these participating CAs to issue certificates for one or more of the following uses: Authentication Encryption SSL/TLS EV SSL/TLS S/MIME RSA Security Inc. Page 4 6/28/2007
14 1.4.2 Prohibited certificate uses Certificates issued under this CPS by one of the RSA CAs are prohibited from any other use not specified in Section In the case that Participating CAs will issue EV SSL certificates, the issuing CA must not issue EV Certificates to any person or any organization or entity that does not satisfy the requirements as specified by the CA/Browser Forum Guidelines. 1.5 Policy administration RSA ROOT SIGNING SERVICE Policy Management Authority is the overall administrative authority of this CPS Organization administering the document RSA ROOT SIGNING SERVICE Policy Management Authority is the responsible authority for reviewing and approving changes to the RSA ROOT SIGNING SERVICE CPS. Written and signed comments on proposed changes shall be directed to the RSA ROOT SIGNING SERVICE contact as described in Section Decisions with respect to the proposed changes are at the sole discretion of the RSA ROOT SIGNING SERVICE Policy Management Authority Contact person The following is the primary contact for the RSA ROOT SIGNING Service: RSA ROOT SIGNING SERVICE Manager RSA, The Security Division of EMC Middlesex Turnpike Bedford, MA Telephone: (781) Person determining CPS suitability for the policy RSA ROOT SIGNING SERVICE Policy Management Authority is the administrative entity for determining a CPS s suitability to RSA ROOT SIGNING SERVICE CP CPS approval procedures The RSA ROOT SIGNING SERVICE Policy Management Authority will review any modifications, additions or deletions to this CPS, and determine if modifications, additions or deletions are acceptable and do not jeopardize operations or the security of the RSA ROOT SIGNING SERVICE. 1.6 Definitions and acronyms A list of definitions and acronyms can be found at the end of this document. RSA Security Inc. Page 5 6/28/2007
15 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories The RSA CAs will provide a certificate and a CRL file that is located in the RSA Repository; the availability of the repositories will be defined in the RSA Root Signing Agreement and this CPS. For EV Certificate status checking, the CA will maintain an online 24/7 Repository mechanism whereby clients can automatically check online the current status of all CA certificates. 2.2 Publication of certification information Subscribers shall be notified that a CA may publish information submitted by them to publicly accessible directories in association with certificate status information. The publication of this information will be within the limits of section 9.3 and 9.4. Certificate and CRL publication shall be in accordance with Section 4. RSA ROOT SIGNING SERVICE retains an online repository of documents where it makes certain disclosure about its practices, procedures and the content of certain of its policies including this CPS. RSA ROOT SIGNING SERVICE reserves the right to make available and publish information on its policies by any means it sees fit. Due to their sensitivity, RSA ROOT SIGNING SERVICE may refrain from making publicly available certain subcomponents and elements of such documents including certain security controls and procedures related with the CA functions. RSA ROOT SIGNING SERVICE shall provide full text version of this CPS and RSA ROOT SIGNING SERVICE CP when necessary for the purposes of audit, accreditation or as required by law. 2.3 Time or frequency of publication Certificate information shall be distributed and/or published promptly upon issuance. Maximum time limits and frequency of certificate and CRL publishing are described in section 4 of this CPS. Updates to this CPS are published in accordance with section Access controls on repositories RSA ROOT SIGNING SERVICE keeps access to its public repository available to Relying Parties with the purpose of validating certificates it issued. RSA ROOT SIGNING SERVICE may limit or restrict access to its services such as the publication of status information on third party databases, private directories, etc. Access controls may be instituted at the discretion of the RSA ROOT SIGNING SERVICE with respect to online certificate status. Certificates will be published promptly upon issuance. The RSA CAs will: 1. Provide directly or with agreement with a repository, unrestricted access to certificates and CRLs. CRL publication will be in accordance with Section Include within any certificate it issues the URL of the website maintained by, or on behalf of, the CA, 3. Provide the publication of its CP on a web site maintained by, or on behalf of the CA, the location of which will be indicated in compliance with Section Provide, directly or through agreement with a repository that operating and repository access controls will be configured so that only authorized CA personnel can write or modify the online version of the CP; and RSA Security Inc. Page 6 6/28/2007
16 5. Provide full text version of the CPS when necessary for the purposes of audit, accreditation or cross-certification. RSA Security Inc. Page 7 6/28/2007
17 3 IDENTIFICATION AND AUTHENTICATION A Subscriber (Participating CA) of the RSA ROOT SIGNING SERVICE is an entity issued a certificate signed by one of the RSA CAs. The Subscriber is represented by an employee of the Participating CA specifically authorized to request a certificate in the RSA Root Signing agreement. 3.1 Naming Types of names Each entity will have a clearly distinguishable and unique X.501 Distinguished Name (DN) in the certificate subject name field and in accordance with PKIX Part 1. Each entity may use an alternative name via the SubjectAlternateName field, which also will be in accordance with PKIX Part 1. The DN will be in the form of a X.501 printablestring and will not be blank. For Participating CAs that will issue EV certificates the CA s certificate Subject field should conform to PKIX standard with an ASN.1 OID of , and the field must be the full legal incorporated name. In addition an assumed name or d/b/a name may be used in the Subject field provided the full legal name follows in parenthesis. In such cases the string of characters cannot exceed 64 bytes, as defined by RFC 3280; otherwise only the full legal name shall be used Need for names to be meaningful The contents of each certificate Subject and Issuer name field will have an association with the authenticated name of the entity. The relative distinguished name (RDN) should reflect the authenticated legal name of the entity or in cases where the identity of the subscriber is protected the name could be a combination of alphanumeric characters. In cases regarding the issuance of EV certificates, Distinguished Names will be the full legal name used for incorporation, or an assumed name or d/b/a (doing business as) Anonymity or pseudonymity of subscribers No stipulation; at the discretion of the RSA ROOT SIGNING SERVICE Rules for interpreting various name forms No stipulation; at the discretion of the RSA ROOT SIGNING SERVICE Uniqueness of names Distinguished names will be unique for all Participating CAs. For participating CAs that will issue EV SSL certificates; Distinguished Names (DNs) will be unique within their domain, and not ambiguous Recognition, authentication, and role of trademarks The priority to entity names will be given to registered trademark holders. The use of a Domain Name is restricted to the authenticated legal owner of that Domain Name. The use of an address is restricted to the authenticated legal owner of that address. RSA Security Inc. Page 8 6/28/2007
18 The RSA CAs reserve the right to make all decisions regarding names in all assigned certificates. A party requesting a certificate must demonstrate its right to use a particular name. If a party wishes to dispute the name contained in an existing certificate they must present evidence that they are the owner of that name. In the case of an organization, incorporation papers or legal representation that clearly demonstrates the use of that name must be presented. In the event that the name is used by more than one organization (i.e. the same name is used in different states), the RSA CAs will add the appropriate characters to the new name to distinguish it from the other name. 3.2 Initial Indentity validation Method to prove possession of private key The method to prove possession of a private key shall be PKCS #10, or another cryptographically equivalent request (digitally signed request with private key) Authentication of organization identity An application to be a CA will be made by a person or organization authorized to act on behalf of the prospective CA. The organization applying for a CA certificate will have verified the identity of the individual authorized to act on behalf of the organization. The organization should keep a record of the type and details of identification used. For participating CAs that will issue EV SSL certificates, RSA will authenticate the organizational identity in accordance with the CA/Browser Forum Guidelines for Extended Validation Certificates. RSA will authenticate the applicant s: Legal Existence Identity Organization Name Assumed Name (Optional, only if used by Applicant) Right to use the Domain Name Jurisdiction of Incorporation Incorporating Agency Address RSA Security Inc. Page 9 6/28/2007
19 3.2.3 Authentication of individual identity Individuals authorized to act on behalf of a Subscriber (Participating CA) will be properly identified as a Technical Point of Contact in the RSA Root Signing Agreement or an addendum. The individual s name, title, phone number, address, and location details must be provided. RSA will authenticate the identity of a Technical Point of Contact and verify their employment status with the Subscriber organization. RSA will authenticate the Technical Point of Contact s Legal Existence by validating the following: 1. The Technical Point of Contact is a natural person whose name matches the Technical Point of Contact s name in the RSA Root Signing Agreement 2. A current signed government issued identification document that includes a photo of the Individual such as: A passport A driver s license Military ID 3. A legal opinion confirming their identity and their authority to act on behalf of a Subscriber Individual (Person) Certificate Applicant No stipulation Application Server Certificate Applicant The RSA CAs will not issue certificates to devices or applications, except in the extraordinary circumstance where a certificate may be required for test purposes. Any such certificate shall be approved by the RSA ROOT SIGNING SERVICE Manager CA Administrator and Vettor Applicant A request to acquire a CA administrator or vettor certificate will be made only by designated CA personnel. The request will require access to the CA administrative request URL (Secure SSL connection), which requires a unique identifier provided by an existing CA Administrator. The request will be manually vetted and approved by existing administrators, requiring two administrators to access this function(s) Non-verified subscriber information No stipulation Validation of authority Through the information provided as part of the RSA Root Signing Agreement, the identity of the individual making the application, the validity of that individual, department and/or organization to make a certificate application, and their authority to receive the certificate(s) for that organization is validated Criteria for interoperation Cross certification between external CAs and the RSA CAs will NOT be supported by the RSA ROOT SIGNING SERVICE. RSA Security Inc. Page 10 6/28/2007
20 3.3 Identification and authentication for re-key requests Identification and authentication for routine re-key Re-key requires the replacement of a public key. A new public/private key pair is generated and a new certificate is issued. Re-key is not supported by the RSA ROOT SIGNING SERVICE Identification and authentication for re-key after revocation Re-key is not supported by the RSA ROOT SIGNING SERVICE. 3.4 Identification and authentication for revocation request In the event that a Participating CA requires the revocation of its certificate, the revocation request will be made by an authorized individual from the organization that has ownership of the Participating CA. The revocation request will be in writing and signed by an authorized individual of the organization. A revocation request in writing may be an electronic document such as with a digital signature from an authorized individual from the organization. The RSA ROOT SIGNING SERVICE will verify the revocation request using a telephone to contact the authorized individual and confirm the identity of the individual and the authenticity of the request. A detailed record of the request, confirmation of the request and action taken will be recorded by the RSA ROOT SIGNING SERVICE. The RSA ROOT SIGNING SERVICE will handle all revocation requests by customers. The revocation request will be logged by the RSA ROOT SIGNING SERVICE and all events subsequent to the revocation request will be recorded in this log. RSA Security Inc. Page 11 6/28/2007
21 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 4.1 Certificate Application The procedures and requirements with respect to an application for a certificate are set out in this CPS. An application for a certificate does not oblige the RSA ROOT SIGNING SERVICE to issue a certificate. For this CPS, applications are for only Participating CA certificates. The application will follow the requirements for Sections Who can submit a certificate application An application for a CA certificate will be made by a person authorized to act on behalf of an organization. Technical and administrative contacts will be identified including name, title, address, phone, . The application will follow the requirements for Section Authentication of organization and Authentication of individual. The Participating CA will submit a CPS to the RSA ROOT SIGNING SERVICE for approval. The RSA ROOT SIGNING SERVICE has the right to approve or reject the submitted CPS, or provide recommendations for revising the proposed CPS to comply with the RSA ROOT SIGNING SERVICE CP. The CPS must be approved prior to the Participating CA submitting PKCS #10 Certificate Request for signature by one of the RSA CAs Enrollment process and responsibilities A Subscriber (Participating CA) will enter into an agreement that outlines the terms and conditions of use prior to the RSA CA s signing and issuing a CA certificate to the Subscriber. A Subscriber will: 1. Have an agreed upon RSA Root Signing Agreement 2. Have a CPS that has been approved by the RSA ROOT SIGNING SERVICE 3. Have proper insurance coverage 4. Have agreements with their Subscribers and Relying Parties; and 5. Agree to abide by the RSA ROOT SIGNING SERVICE CP 6. If the participating CA will issue EV certificates, they must comply with the enrollment process and responsibilities as specified in the CA/Browser Forum s Guidelines for EV Certificates. 4.2 Certificate application processing Individuals, as described in section 4.1, applying for certificates will follow the requirements of section 3.2. The Subscriber shall be tightly bound to their public keys and the information submitted. The CA Certificate Signing Process will be performed to sign the Participating CA s certificate. In processing the application for a Participating CA who will issue EV SSL certificates, RSA will verify to the effect that the entity is not considered or known to be a high risk. RSA Security Inc. Page 12 6/28/2007
22 4.2.1 Performing identification and authentication functions The RSA CAs shall perform identification and authentication procedures to validate a certificate application. Following the validation, the CA will either approve or reject the certificate application, based on the criteria outlined in section 3.2. Application for CA administrator or vetting certificates will be submitted by an entity designated by the RSA ROOT SIGNING SERVICE as having a need for and having met the requirements for such a certificate. The appropriate contact information will be identified including name, title, address, phone, and . The application will follow the requirements for Section Approval or rejection of certificate applications The RSA ROOT SIGNING SERVICE shall notify a Subscriber that an RSA CA has created a certificate, and provide the Subscriber with the certificate. The CA may deliver the certificate through manual or automated processes. A Subscriber will be notified in writing or by of a rejected certificate application Time to process certificate applications There is no stipulation for the period between the receipt of an application for a CA certificate and the signing of a CA certificate. Any stipulations will be based on contractual obligations. 4.3 Certificate issuance CA actions during certificate issuance The issuance of a signed CA certificate by one of the RSA CAs indicates a complete and final approval of the certificate application by the CA Notification to subscriber by the CA of issuance of certificate A Subscriber will be notified by the RSA ROOT SIGNING SERVICE that an RSA CA has created a certificate by providing the Subscriber with the certificate. The issuance notification will be in the form of an message to the Subscriber informing of the successful completion of the enrollment process. RSA Security Inc. Page 13 6/28/2007
23 4.4 Certificate acceptance Conduct constituting certificate acceptance The RSA ROOT SIGNING SERVICE will require that an entity acknowledge acceptance of a CA certificate. The signing of the CA certificate by one of the RSA CAs and the acceptance of the signed CA certificate by the organization will constitute acknowledgement and acceptance of the organization Publication of the certificate by the CA No stipulation Notification of certificate issuance by the CA to other entities No notification of issuance or revocation will be provided to any other party when a certificate is issued or revoked except, in the case of revocation, through the issuance of a CRL or online certificate status services. 4.5 Key pair and certificate usage Subscriber private key and certificate usage The Subscriber shall only use certificates, issued by one of the RSA CAs, and their associated key pairs for the purposes identified in the RSA ROOT SIGNING SERVIVE CP, this CPS and in the RSA Root Signing Agreement Relying party public key and certificate usage Prior to using a Subscriber's certificate, a Relying Party shall verify that the certificate is appropriate for the intended use. The rights and obligations of a Relying Party who is a Participating CA in the RSA ROOT SIGNING SERVICE are covered in the RSA ROOT SIGNING SERVICE Certificate Policy. 4.6 Certificate renewal Circumstance for certificate renewal Certificate renewal is the re-issuance of a certificate with a new validity date using the same public key corresponding to the same private key. Certificate renewal will be permitted within a mutually agreed upon time frame prior to certificate expiration Who may request renewal The RSA ROOT SIGNING SERVICE will accept requests for certificate renewal from the authorized technical point of contact from the Subscribing organization. RSA Security Inc. Page 14 6/28/2007
24 4.6.3 Processing certificate renewal requests The RSA ROOT SIGNING SERVICE will authenticate all requests for certificate renewal from a Subscriber. Certificate renewal is bound by contractual obligations and will be defined in the RSA Root Signing Agreement. A Subscriber must present a valid certificate request in order to renew its certificate. If the certificate has expired the Subscriber will be authenticated in the same manner as the initial registration Notification of new certificate issuance to subscriber A Subscriber will be notified by the RSA ROOT SIGNING SERVICE that the RSA CA has renewed a certificate by providing the Subscriber with the certificate. The issuance notification will be in the form of an message to the Subscriber informing of the successful completion of the renewal process Conduct constituting acceptance of a renewal certificate The RSA ROOT SIGNING SERVICE will require that an entity acknowledge acceptance of a CA certificate. The signing of the CA certificate by the RSA CAs and the acceptance of the signed CA certificate by the organization will constitute acknowledgement and acceptance of the organization Publication of the renewal certificate by the CA No stipulation Notification of certificate issuance by the CA to other entities No notification of renewal will be provided to any other party when a certificate is renewed. 4.7 Certificate re-key Circumstance for certificate re-key Re-key is not supported by the RSA ROOT SIGNING SERVICE Who may request certification of a new public key No stipulation Processing certificate re-keying requests No stipulation Notification of new certificate issuance to subscriber No stipulation Conduct constituting acceptance of a re-keyed certificate No stipulation Publication of the re-keyed certificate by the CA No stipulation. RSA Security Inc. Page 15 6/28/2007
25 4.7.7 Notification of certificate issuance by the CA to other entities No stipulation. 4.8 Certificate modification Circumstance for certificate modification A certificate may be modified only at the discretion of the RSA ROOT SIGNING SERVICE Manager. Typically this would be under the following circumstances: When the basis for any information in the certificate changes. A change in the business relationship under which the certificate was issued occurs Who may request certificate modification The authorized technical point of contact from the Participating CA s organization may request certificate modification Processing certificate modification requests All requests for certificate modification shall be submitted in writing. The authenticated modification request and any resulting actions taken by the CA shall be recorded and retained as required Notification of new certificate issuance to subscriber A Subscriber will be notified by the RSA ROOT SIGNING SERVICE that the RSA CA has renewed a certificate by providing the Subscriber with the certificate. The issuance notification will be in the form of an message to the Subscriber informing of the successful completion of the renewal process Conduct constituting acceptance of a renewal certificate The RSA ROOT SIGNING SERVICE will require that an entity acknowledge acceptance of a CA certificate. The signing of the CA certificate by the RSA CAs and the acceptance of the signed CA certificate by the organization will constitute acknowledgement and acceptance of the organization Publication of the modified certificate by the CA No stipulation Notification of certificate issuance by the CA to other entities No stipulation. 4.9 Certificate revocation and suspension Circumstances for revocation A CA certificate will be revoked: When a Participating CA fails to comply with obligations set out in the RSA ROOT SIGNING SERVICE CP, the CPS, any agreement or applicable law. The RSA ROOT SIGNING SERVICE may revoke a certificate at any time if the RSA ROOT SIGNING RSA Security Inc. Page 16 6/28/2007
26 SERVICE suspects that conditions may lead to a compromise of the Participating CA s keys or certificates. When any of the information in the certificate changes Upon suspected or known compromise of the Participating CA's private key Upon suspected or known compromise of media holding Participating CA's private key When the Participating CA fails to comply with obligations set out in their CPS, any agreement or any applicable law If the Participating CA fails a Compliance Audit or fails to submit an annual Compliance Audit report to the RSA ROOT SIGNING SERVICE Upon termination of the contract Who can request revocation The revocation of a CA certificate may only be requested by: The individual or organization which made the application for the certificate on behalf of an organization A duly appointed officer of the organization An authorized representative from the RSA ROOT SIGNING SERVICE Procedure for revocation request For the RSA ROOT SIGNING SERVICE, the revocation of a Participating CA certificate will require a written request from a duly appointed officer of an organization, or from the RSA ROOT SIGNING SERVICE Manager. The request for revocation of a Participating CA certificate will be verified prior to the revocation of the CA certificate. The verification process and contact will be determined in the RSA Root Signing Agreement. Once the CA certificate is revoked it cannot be reinstated. The RSA ROOT SIGNING SERVICE will keep a record of all revocation requests including the requestor's name, contact method, reason for revocation, date and time. A monthly report will be generated on all revocations. All requests for revocation will be written and authenticated. The authenticated revocation request and any resulting actions taken by the RSA ROOT SIGNING SERVICE will be recorded and retained. In the case where a CA certificate is revoked, full justification for the revocation will also be documented. Where a Participating CA certificate is revoked, the revocation will be published in the CRL Revocation request grace period The revocation grace period is the maximum period available, within which the Subscriber must make a revocation request upon suspicion of compromise. Any action taken as a result of a request for revocation will be initiated within seven (7) days of receipt of a revocation request. Any other revocation request grace period will be defined in the RSA Root Signing Agreement; otherwise the provisions in this CPS are in force. RSA Security Inc. Page 17 6/28/2007
TR-GRID CERTIFICATION AUTHORITY CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT Version 2.1 January, 2009 Table of Contents: TABLE OF CONTENTS:...2 1. INTRODUCTION...7 1.1 OVERVIEW...7 1.2 DOCUMENT
TR-GRID CERTIFICATION AUTHORITY CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT Version 2.3 May 15, 2014 Table of Contents TABLE OF CONTENTS:... 2 1. INTRODUCTION... 7 1.1 OVERVIEW... 7 1.2 DOCUMENT
VeriSign Trust Network Certificate Policies Version 2.8.1 Effective Date: February 1, 2009 VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA +1 650.961.7500 http//:www.verisign.com - 1-
Gandi CA Certification Practice Statement Gandi SAS 15 Place de la Nation Paris 75011 France Version 1.0 TABLE OF CONTENTS 1.INTRODUCTION...10 1.1.Overview...10 1.2.Document Name and Identification...10
Globe Hosting Certification Authority Globe Hosting, Inc. 501 Silverside Road, Suite 105, Wilmington, DE 19809, County of New Castle, United States www.globessl.com TABLE OF CONTENTS 1. INTRODUCTION...
THE WALT DISNEY COMPANY PUBLIC KEY INFRASTRUCTURE CERTIFICATE POLICY July 2011 Version 2.0 Copyright 2006-2011, The Walt Disney Company Version Control Version Revision Date Revision Description Revised
Fraunhofer Corporate PKI Certification Practice Statement Version 1.1 Published in June 2012 Object Identifier of this Document: 220.127.116.11.4.1.718.104.22.168.1 Contact: Fraunhofer Competence Center PKI Fraunhofer
Advantage Security Certification Practice Statement Version 3.8.5 Effective Date: 01/01/2012 Advantage Security S. de R.L. de C.V. Prol. Paseo de la Reforma # 625 Int 402, Col Paseo de las Lomas. Del Alvaro
TREND MICRO SSL CERTIFICATION PRACTICE STATEMENT Version 2.0 Effective Date: 14 April 2015 TABLE OF CONTENTS 1. INTRODUCTION 1.1 Overview 1.2 Document name and identification 1.3 PKI participants 1.3.1
SAUDI NATIONAL ROOT-CA CERTIFICATE POLICY Document Classification: Public Version Number: 2.5 Issue Date: June 25, 2015 National Center for Digital Certification Policies and Regulations Department Digitally
Apple Inc. Certificate Policy and Certification Practice Statement Version 2.0 Effective Date: April 10, 2015 Table of Contents 1. Introduction... 4 1.1. Trademarks... 4 1.2. Table of acronyms... 4 1.3.
Apple Inc. Certification Authority Certification Practice Statement Worldwide Developer Relations Version 1.8 Effective Date: June 11, 2012 Table of Contents 1. Introduction... 4 1.1. Trademarks... 4 1.2.
TCS Server and Code Signing Personal CA CPS Version 2.0 (rev 15) Page 1/40 Trusted Certificate Service TCS Server CAs, escience Server CA, and Code Signing CA Certificate Practice Statement Version 2.0
Malaysian Identity Federation and Access Management Certification Authority Certificate Policy and Certification Practice Statement Version 2.2 Document OID: 22.214.171.124.4.1.363126.96.36.199.2 February 2012 Contents
Document no 1/011 01-AZDA 102 213 TeliaSonera Sverige AB Certification Practice Statement Rev A TeliaSonera Public Root CA Certification Practice Statement Revision Date: 2006-11-17 Version: Rev A Published
SwissSign Certificate Policy and Certification Practice Statement for Gold Certificates Version March 2004 Version 2004-03 SwissSign Gold CP/CPS Page 1 of 66 Table of Contents 1. INTRODUCTION...9 1.1 Overview...
(CP) (For SSL, EV SSL, OSC and similar electronic certificates) VERSION : 09 DATE : 01.12.2014 1. INTRODUCTION... 10 1.1. Overview... 10 1.2. Document Name and Identification... 11 1.3. Participants...
Apple Inc. Certification Authority Certification Practice Statement Worldwide Developer Relations Version 1.14 Effective Date: September 9, 2015 Table of Contents 1. Introduction... 5 1.1. Trademarks...
Equens Certificate Policy WebServices and Connectivity Final H.C. van der Wijck 11 March 2015 Classification: Open Version 3.0 Version history Version no. Version date Status Edited by Most important edit(s)
FernUniversität in Hagen: Certification Authority (CA) Certification Practice Statement VERSION 1.1 Ralph Knoche 18.12.2009 Contents 1. Introduction... 4 1.1. Overview... 4 1.2. Scope of the Certification
thawte Certification Practice Statement Version 3.7.5 Effective Date: 4 June, 2012 (All CA/Browser Forum-specific requirements are effective on July 1, 2012) thawte Certification Practice Statement 2012
The Boeing Company Boeing Commercial Airline PKI Basic Assurance CERTIFICATE POLICY Version 1.4 PA Board Approved: 7-19-2013 via e-mal PKI-233 BCA PKI Basic Assurance Certificate Policy Page 1 of 69 Signature
TC TrustCenter GmbH Certification Practice Statement NOTE: The information contained in this document is the property of TC TrustCenter GmbH. This Certification Practice Statement is published in conformance
phicert Direct Certificate Policy and Certification Practices Statement Version 1. 1 Effective Date: March 31, 2014 Copyright 2013-2014 EMR Direct. All rights reserved. [Trademark Notices] phicert is a
DigiCert Certificate Policy and Certification Practice Statement DigiCert, Inc. Version 3.03 March 15, 2007 333 South 520 West Lindon, UT 84042 USA Tel: 1-801-805-1620 Fax: 1-801-705-0481 www.digicert.com
Visa Public Key Infrastructure Certificate Policy (CP) Version 1.7 Effective: 24 January 2013 2010-2013 Visa. All Rights Reserved. Visa Public Important Note on Confidentiality and Copyright The Visa Confidential
Trustwave Holdings, Inc Certificate Policy and Certification Practices Statement Version 2.9 Effective Date: July 13, 2010 This document contains Certification Practices and Certificate Policies applicable
Certification Practice Statement of the Federal Reserve Banks Services Public Key Infrastructure 1.0 INTRODUCTION 1.1 Overview The Federal Reserve Banks operate a public key infrastructure (PKI) that manages
Internet Security Research Group (ISRG) Certificate Policy Version 1.0 Updated May 5, 2015 Approved by ISRG Policy Management Authority ISRG Web Site: https://letsencrypt.org Page 1 of 83 Copyright Notice
X.509 Certificate Policy for India PKI Version 1.4 May 2015 Controller of Certifying Authorities Department of Information Technology Ministry of Communications and Information Technology Document Control
InCommon Certification Practices Statement for Server Certificates 16 August 2010 Version 1.0 Latest version: https://www.incommon.org/cert/repository/cps_ssl.pdf This version: https://www.incommon.org/cert/repository/cps_ssl_20100816.pdf
Certification Practice Statement Date: February 21, 2008 Version: 1.0.1 Table of Contents Document History... 1 Acknowledgments... 1 1. Introduction... 2 1.1 Overview... 3 1.2 Ford Motor Company Certificate
Certification Practice Statement Internet Security Research Group (ISRG) Version 1.0 Updated May 5, 2015 Approved by ISRG Policy Management Authority Web Site: https://letsencrypt.org Page 1 of 11 Copyright
[Draft] Bangladesh Bank Certification Authority (BBCA) Certification Practice Statement (CPS) Version: 1.00 August, 2015 Bangladesh Bank Page 2 of 42 Document Reference Title Document Type Bangladesh Bank
Polish Grid Certification Authority Certificate Policy and Certification Practice Statement version 0.4 (DRAFT ) September 2, 2002 1 1 Introduction 1.1 Overview This document is written according to the
Certificate Policy for the United States Patent and Trademark Office November 26, 2013 Prepared by: United States Patent and Trademark Office Public Key Infrastructure Policy Authority This page is intentionally
Document no 4/011 01-AZDA 102 213 TeliaSonera Sverige AB Certification Practice Statement Rev. 1.0 Telia hardware based e-legitimation v2 Certification Practice Statement Revision Date: 10 th June 2009
InCommon Certification Practices Statement for Client Certificates 14 February 2011 Version 1.0 Latest version: 14 February 2011 This version: 14 February 2011 Table of Contents 1 INTRODUCTION... 4 1.1
Operational Research Consultants, Inc. Non Federal Issuer Certificate Policy Version 1.0.1 Operational Research Consultants, Inc. 11250 Waples Mill Road South Tower, Suite 210 Fairfax, Virginia 22030 June
thawte Certification Practice Statement Version 2.3 Effective Date: July, 2006 thawte Certification Practice Statement 2006 thawte, Inc. All rights reserved. Printed in the United States of America. Revision
ESnet SSL CA service Certificate Policy And Certification Practice Statement Version 1.0 June 30, 2004 Table of Contents Table of Contents...2 1 Introduction...3 1.1 Overview...3 1.1.1 General Definitions...4
TC TrustCenter GmbH Certificate Policy for SAFE NOTE: The information contained in this document is the property of TC TrustCenter GmbH. This Certificate Policy is published in conformance with international
Starfield Technologies, LLC Certificate Policy and Certification Practice Statement (CP/CPS) Version 3.8 April 15, 2016 i Starfield CP-CPS V3.8 Table of Contents 1 Introduction... 1 1.1 Overview... 1 1.2
X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA) Version 2.24 February 25, 2011 Signature Page Chair, Federal Public Key Infrastructure Policy Authority DATE Revision History
CERTIFICATE POLICY KEYNECTIS SSL CA Date: 05/02/2009 KEYNECTIS SSL CA CERTIFICATE POLICY Subject: KEYNECTIS SSL CA Certificate Policy Version number: 1.1 Number of pages: 49 Status of the Project Final
Document history Version Date Remarks 1.0 19-05-2011 finalized 1.01 15-11-2012 URL updated after web page restructuring. 2 Table of Contents 1. Introduction... 4 2. Policy administration... 4 2.1 Overview...
CERTIFICATION PRACTICE STATEMENT UPDATE Reference: IZENPE-CPS UPDATE Version no: v 5.03 Date: 10th March 2015 IZENPE 2015 This document is the property of Izenpe. It may only be reproduced in its entirety.
Certificate Policy KEYNECTIS SSL CA CP Emmanuel Montacutelli 12/11/2014 DMS_CP_KEYNECTIS SSL CA CP_1.2 KEYNECTIS SSL CA CP Version 1.2 Pages 51 Status Draft Final Author Emmanuel Montacutelli OpenTrust
COMPANY INFO 1 (23) Ericsson Group Certificate Value Statement - 2013 COMPANY INFO 2 (23) Contents 1 Ericsson Certificate Value Statement... 3 2 Introduction... 3 2.1 Overview... 3 3 Contact information...
PKI Belgium Government CA Government AA Certification Practice Statement 188.8.131.52.1.1.3 184.108.40.206.220.127.116.11 18.104.22.168.22.214.171.124 126.96.36.199.188.8.131.52 184.108.40.206.1.1.6 220.127.116.11.18.104.22.168 22.214.171.124.1.1.3 126.96.36.199.188.8.131.52
ING Public Key Infrastructure Certificate Practice Statement Version 5.3 - June 2015 Colophon Commissioned by Additional copies ING Corporate PKI Policy Approval Authority Additional copies of this document
SWIFT SWIFT Qualified Certificates Certificate Policy This Certificate Policy applies to Qualified Certificates issued by SWIFT. It indicates the requirements and procedures to be followed, and the responsibilities
X.509 Certification Practice Statement for the Australian Department of Defence Version 5.1 December 2014 Document Management This document is controlled by: Changes are authorised by: Defence Public Key
Metropolitan Police Service Enterprise PKI Root Certificate Authority, Certificate Policy Version 6.1 10 th February 2012 Version Control Issue Release Date Comments A 02/11/07 First draft release of CP
SWITCHaai Metadata CA Certificate Policy and Certification Practice Statement Version 1.0, OID 2.16.7184.108.40.206.7.1.0 July 15, 2008 Table of Contents 1. INTRODUCTION...6 1.1 Overview...6 1.2 Document name
X.509 Certificate Policy for the Australian Department of Defence Individual Software Certificates (Medium Assurance) Version 4.0 May 2014 Notice to all parties seeking to rely Reliance on a Certificate
Comodo Certification Practice Statement Notice: This CPS should be read in conjunction with the following documents:- * LiteSSL addendum to the Certificate Practice Statement * Proposed Amendments to the
National Identity Exchange Federation (NIEF) Trustmark Signing Certificate Policy Version 1.1 February 2, 2016 Copyright 2016, Georgia Tech Research Institute Table of Contents TABLE OF CONTENTS I 1 INTRODUCTION
Certification Practice Statement 1.0 INTRODUCTION 1.1 OVERVIEW The Federal Reserve Banks ( FRBs ), utilizing Public Key Infrastructure ( PKI ) technology and operating as a Certification Authority ( FR-CA
Dexia Root CA Certification Practice Statement Version 1.0 Version History Version Description Date Author 0.1 Initial Draft 17 September 2001 Jan Raes 0.2 Minor adaptation after review PA 16 October 2001
Swiss Government Root CA II CP/CPS End-user Certificates Swiss Government PKI - Root CA II Certificate Policy and Certification Practice Statement (CP/CPS) Document OID: 2.16.7220.127.116.11.21.1 Project Name:
Certification Practice Statement March 2009 1. Overview 1.1 What is a Certification Practice Statement? A certification practice statement is a statement of the practices that a Certification Authority
SYMANTEC NON-FEDERAL SHARED SERVICE PROVIDER PKI SERVICE DESCRIPTION I. DEFINITIONS For the purpose of this Service Description, capitalized terms have the meaning defined herein. All other capitalized
James D. Campbell Digitally signed by James D. Campbell DN: c=us, cn=james D. Campbell Date: 2014.06.18 10:45:03-07'00' RAPIDPIV-I Credential Service Certification Practice Statement Redacted Key Information:
CERTIFICATION PRACTICE STATEMENT Document version: 1.2 Date: 15 September 2007 OID for this CPS: None Information in this document is subject to change without notice. No part of this document may be copied,
Post.Trust Certificate Authority Certification Practice Statement CA Policy and Procedures Document Issue date: 03 April 2014 Version: 18.104.22.168 Release Contents DEFINITIONS... 6 LIST OF ABBREVIATIONS...
Committee on National Security Systems CNSS Instruction No. 1300 October 2009 INSTRUCTION FOR NATIONAL SECURITY SYSTEMS PUBLIC KEY INFRASTRUCTURE X.509 CERTIFICATE POLICY Under CNSS Policy No. 25 National
ENTRUST CERTIFICATE SERVICES Certification Practice Statement Version: 2.13 February 12, 2016 2016 Entrust Limited. All rights reserved. Revision History Issue Date Changes in this Revision 1.0 May 26,
Symantec Trust Network (STN) Certificate Policy Version 2.8.20 May 20, 2016 Symantec Corporation 350 Ellis Street Mountain View, CA 94043 USA +1 650.527.8000 www.symantec.com - i - Symantec Trust Network
DigiCert Certificate Policy DigiCert, Inc. Version 4.03 May 3, 2011 Suite 200 Canopy Building II 355 South 520 West Lindon, UT 84042 USA Tel: 1 801 877 2100 Fax: 1 801 705 0481 www.digicert.com TABLE OF
DigiCert Certification Practice Statement DigiCert, Inc. Version 2.22 June 01, 2005 333 South 520 West Orem, UT 84042 USA Tel: 1-801-805-1620 Fax: 1-801-705-0481 www.digicert.com 1 General...7 1.1 DigiCert,
Your consent to our cookies if you continue to use this website.