San Diego Supercomputer Center (SDSC) Certificate Policy and Practice Statement     Version 1.0.1 April, 2005                                 Table of Contents 1. Introduction .............................................. 1.1. Overview................................................... 1.2. Identification ............................................ 1.3. Community and applicability ............................... 1.4. Contact Details ........................................... 2. General provisions........................................ 2.1. Obligations............................................... 2.2. Liability................................................. 2.3. Financial responsibility ................................. 2.4. Interpretation and Enforcement ........................... 2.5. Fees ..................................................... 2.6. Publication and Repository ............................... 2.7. Compliance audit ......................................... 2.8. Confidentiality .......................................... 2.9. Intellectual Property Rights ............................. 3. Identification and authentication ........................ 3.1. Initial Registration ..................................... 3.2. Routine rekey............................................. 3.3. Rekey after revocation ................................... 3.4. Revocation request ....................................... 4. Operational requirements.................................. 4.1. Certificate Application .................................. 4.2. Certificate Issuance ..................................... 4.3. Certificate Acceptance ................................... 4.4. Certificate Suspension and Revocation .................... 4.5. Security Audit Procedures ................................ 4.6. Records Archival ......................................... 4.7. Key changeover ........................................... 4.8. Compromise and Disaster Recovery.......................... 4.9. CA Termination ........................................... 5. Physical, procedural, and personnel security controls .............................................. 5.1. Physical Controls ........................................ 5.2. Procedural controls ...................................... 5.3. Personnel controls ....................................... 6. Technical security controls .............................. 6.1. Key Pair Generation and Installation...................... 7. CA Certificates .......................................... 7.1. Private Key Protection ................................... 7.2. Other aspects of key pair management...................... 7.3. Activation data .......................................... 7.4. Computer security controls ............................... 7.5. Life cycle technical controls ............................ 7.6. Network security controls ................................ 7.7. Cryptographic module engineering controls ................ 8. Certificate and CRL profiles ............................. 8.1. Certificate Profile ...................................... 8.2. CRL Profile............................................... 9. Specification administration ............................. 9.1. Specification change procedures .......................... 9.2. Publication and notification policies .................... 9.3. CPS approval procedures .................................. 10. References .................................................... APPENDIX 1 ......................................................... 1. Introduction 1.1. Overview This Certificate Policy and Practice Statement (herein referred to as the "Policy") specifies minimum requirements for the issuance and management of digital certificates that shall be used in authenticating users accessing San Diego Supercomputer Center (herein referred to as "SDSC") resources and the resources of other entities (relying parties) which accept those ceritficates. The Policy is issued and administered under the authority of the SDSC Policy Management Authority (herein referred to as the "PMA"; see Section 1.4.2 for contact details). This document is based upon the framework provided by the Global Grid Forum Certificate Policy Model (draft-gridforum-CP.txt v.6, September, 2001 - http://caops.es.net/Documents/Draft-GGF-CP-06.pdf). The structure and content of that document was derived from the Internet Engineering Task Force RFC 2527 (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, http://www.ietf.org/rfc/rfc2527.txt) 1.2. Identification This Policy is published at http://www.sdsc.edu/CA/SDSC_CP+PS. 1.3. Community and applicability The certificate authority, CA, operating under this Policy will serve the needs of the SDSC community by providing individual computer account holders at SDSC with x509v3 digital certificates. These certificates may be used for the purpose of authentication, encryption, and digital signing by those individuals to whom the certificates have been issued. The CA may also issue server and service certificates to computers operating within the SDSC administrative domain and to computer systems from other domains which are providing services in support of SDSC projects. 1.3.1. Certification Authority (CA). This Policy is binding on each authorized Certificate Authority (CA) that issues certificates identifying this Policy as its authority, and governs its performance with respect to all certificates it issues that reference this Policy. A CA may issue certificates that reference this Policy (as identified in section 1.2) only if such CA first qualifies as an Authorized CA by: . agreeing to be bound by, and comply with this Policy . undergoing and successfully completing the compliance audit specified in Section 2.7 . being approved by the PMA 1.3.2. Registration authorities The function of a Registration Authority (RA) will be performed by the SDSC CA system's CA daemon for the authentication of individuals requesting user certificates. In the case of server and service certificate requests the function of an RA will be performed by the CA system's administrators. 1.3.3. End entities The end entities to be certified in accordance with this policy are: a natural person (individual or representing an organization) or a computer entity (e.g. a computer, a router or an application), capable of performing cryptographic operations. 1.3.4. Applicability One of the purposes of this policy is to promote a wide use of public-key certificates in many different applications. These applications may include, but are not limited to, login authentication, job submission authentication, encrypted e-mail, and SSL/TLS encryption for applications capable of making use of these technologies. 1.4. Contact Details 1.4.1. Specification administration organization This policy was developed and is maintained by the San Diego Supercomputer Center. It is based on a model policy document created by the Global Grid Forum. 1.4.2. Contact person This Policy is administered by the SDSC PMA: SDSC Manager, Security Technologies Currently: Victor Hazlewood Phone number: (858) 534-8390 or Operations: 534-5090 E-mail address: victor@sdsc.edu The contact point for questions related to this policy and its implementation is: William J. Link, CA Administrator Phone: (858) 822-0851 E-mail address: bill@sdsc.edu 1.4.3. Person determining CPS suitability for the policy It is the responsibility of conforming CAs have to establish their own Policy Management Authority (PMA) that will oversee the CA. The PMA is responsible for setting policy, approving the CP/CPS (Certificate Policy/Certificate Practice Statement), determination of compliance with the CP/CPS, and oversight of activities related to the development and enforcement of policy as specified in the CP/CPS. 2. General provisions This chapter describes obligations of relevant parties and makes statements on liability and financial issues. Moreover there's a section about confidentiality that classifies information into confidential information and publicly available and distributable information. Auditing statements are also located there. 2.1. Obligations 2.1.1. CA obligations The Certificate Authorities are responsible for all aspects of the issuance and management of a certificate referencing this Policy and Practice Statement including: * Publication of CA contact information * Certificate application/enrollment process * Verification of the identity of the applicant * Certificate creation process * Posting of the certificate in a public repository * Revocation of the certificate * Ensuring that all aspects of the CA services and CA operations and CA infrastructure related to certificates issued in accordance with this Policy are performed in accordance with the requirements, representations, and warranties of this Policy By issuing a certificate that references this Certificate Policy, the CA certifies to the subscriber, and to all Qualified Relying Parties who reasonably and in good faith rely on the information contained in the certificate during its operational period, that: * The CA has issued, and will manage, the certificate in accordance with this Policy * There are no misrepresentations of fact in the certificate known to the CA, and the CA has taken reasonable steps to verify additional information in the certificate unless otherwise noted * The certificate meets all material requirements of this Certificate Policy and Practice Statement 2.1.2. RA obligations Not applicable (see section 1.3.2). 2.1.3. Subscriber obligations Subscribers, those for whom certificates are issued, will be expected to: * Generate a key pair using a trustworthy method * Review and verify accuracy of their representations included in the published certificate * Use the certificate exclusively for authorized and legal purposes, consistent with this Policy * Instruct the CA to revoke the certificate promptly upon any actual or suspected loss, disclosure, or other compromise of the subscribers private key * Take reasonable precautions to prevent any loss, disclosure, or unauthorized use of the private key associated with the certificate, such as: 1) Selecting a pass phrase that is a minimum 8 characters 2) Using upper and lower case characters or special characters in the pass phrase 3) Protecting the private key from others 2.1.4. Relying party obligations Qualified Relying Parties are expected to rely on certificates that reference this Policy as appropriate authentication of the subscriber if: * The relying party is familiar with the Policy and Practice Statement of the CA that generated the certificate before drawing any conclusion on trust of a certificate issued from a conforming CA * The reliance is reasonable and in good faith in light of all the circumstances known to the relying party at the time of reliance * The purpose for which the certificate was used was appropriate in accordance with this Policy * The relying party checked the status of the certificate prior to reliance * The reliance is for lawful purposes 2.1.5. Repository obligations Each conforming CA should use a publicly accessible repository to store certificates and Certificate Revocation Lists (CRLs). The repository should attempt continuous, uninterrupted operation.. 2.2. Liability 2.2.1. CA liability The San Diego Supercomputer Center assumes no liability for any direct or indirect damages suffered by relying parties caused by the failure of the CA to comply with either its Policy or resulting from the reliance of a relying party on a certificate issued by the CA. 2.2.2. RA liability No stipulation. 2.3. Financial responsibility With regard to what is stated in subsection 1.3.4, 2.2.1 and section 2.5, no financial responsibility is accepted for certificates issued in accordance with this certificate policy. 2.3.1. Indemnification by relying parties No stipulation. 2.3.2. Fiduciary relationships No stipulation. 2.3.3. Administrative processes Certificate Authority administrative processes are defined in this Policy. 2.4. Interpretation and Enforcement 2.4.1. Governing law Interpretation of this policy is according to the laws of the United States of America and the State of California, where the conforming CA is established. 2.4.2. Severability, survival, merger, notice No stipulation. 2.4.3. Dispute resolution procedures No stipulation. 2.5. Fees 2.5.1. Certificate issuance or renewal fees No fees will be charged by CAs complying with this Policy for the issuance of certificates. 2.5.2. Certificate access fees No fees will be charged by CA's complying with this Policy for certificate access. 2.5.3. Revocation or status information access fees No fees will be charged by CA's complying with this Policy for certificate revocation or status information. 2.5.4. Fees for other services, e.g. policy information No fees will be charged by CAs complying with this Policy for other certificate related services. 2.5.5. Refund policy No refunds of any kind will be provided under the terms of this Policy. 2.6. Publication and Repository 2.6.1. Publication of CA information Each Authorized CA shall operate a secure on-line repository that is available to Qualified Relying Parties and that contains: * Certificates issued that reference this Policy * A signed Certificate Revocation List (CRL) and an on-line certificate status file for certificates issued referencing this Policy * All issued certificates except those certificates of subscribers that explicitly requested that their certificate shall not be made publicly available * The CA's certificate containing its public key corresponding to its signing key * A copy of this Policy * Other relevant information relating to certificates that reference this Policy 2.6.2. Frequency of publication Certificates must be published i.e., made available in a public repository, as soon as they are issued. The frequency of CRL publication is specified in 4.4.9. Also, the Policy shall be published as soon as it is updated. 2.6.3. Access control No stipulation. 2.6.4. Repositories There must exist at least one repository for publishing the information mentioned above. 2.7. Compliance audit 2.7.1. Frequency of entity compliance audit Audits will be done before initial approval as an Authorized CA, and thereafter on an as needed basis. 2.7.2. Identity/qualifications of auditor No stipulation. 2.7.3. Auditor's relationship to audited party No stipulation. 2.7.4. Topics covered by audit The audit will verify the quality of the services provided by the CA and that the CA complies with all of the requirements of this Policy. 2.7.5. Actions taken as a result of deficiency No stipulation. 2.7.6. Communication of results No stipulation. 2.8. Confidentiality The CA collects personal information about the subscribers (e.g. full name, organization, and user account name). These data must be processed in a way that ensures privacy protection according to the laws of the country where the CA is established. 2.8.1. Types of information to be kept confidential All subscribers' information that is not present in the certificate and CRL issued by a conforming CA is considered confidential and shall not be released outside if there is no explicit subscriber's authorization. 2.8.2. Types of information not considered confidential Information included in public certificates and CRLs issued by a conforming CA is not considered confidential. 2.8.3. Disclosure of certificate revocation/suspension information No stipulation. 2.8.4. Release to law enforcement officials No stipulation. 2.8.5. Release as part of civil discovery No stipulation. 2.8.6. Disclosure upon owner's request No stipulation. 2.8.7. Other information release circumstances No stipulation. 2.9. Intellectual Property Rights No stipulation. 3. Identification and authentication 3.1. Initial Registration 3.1.1. Types of names The naming attributes of the subscriber to be requested to identify and authenticate the requester depend on the type of certificate that the subscriber requires. 3.1.2. Need for names to be meaningful The Subject and Issuer name contained in a certificate must be meaningful in the sense that the issuing CA has proper evidence of the existent association between these names and the entities to which they belong. 3.1.3. Rules for interpreting various name forms The Common Name portion of certificates issued under this Policy will, in the case of user certificates, contain the name of the owner of the certificate which is contained within the the GECOS field of the /etc/passwd entry of the user's SDSC computer account from which the certificate request originated. In the case of server certificates the CN field will contain the fully qualified domain name (FQDN). In the case of service certificates the CN will contain the name of the service and the FDQN of the server from which the service will be provided. 3.1.4. Uniqueness of names The Distinguished Name will be unique for each subject entity certified by the CA. 3.1.5. Name claim dispute resolution procedure No stipulation. 3.1.6. Recognition, authentication and role of trademarks No stipulation. 3.1.7. Method to prove possession of private key In the case of user certificates the public/private key pair is generated at the time the PKCS#10 certificate request is created, thus the private key is in the possession of the certificate requester at the time the request is generated. 3.1.8. Authentication of organization identity No stipulation. 3.1.9. Authentication of individual identity The SDSC CA system shall authenticate SDSC system users who apply for certificates to the same level of certainty that ordinary user account login provides. This will be done through automated means by making use of a standard SDSC system login authentication method. 3.2. Routine rekey The SDSC CA will not reuse keys (rekey) of certificates it issues. 3.3. Rekey after revocation No rekeying will be done. 3.4. Revocation request No stipulation. 4. Operational requirements 4.1. Certificate Application See section 3.1.9 above. 4.2. Certificate Issuance The SDSC CA will issue certificates to eligible applicants whose identities have been authenticated by the method described in section 3.1.9. The CA will refuse certificate applications when the user authentication fails or in cases where a still-valid certificate issued to the user by the CA exists. The CA may issue system/service certificates only to entities within the control of SDSC or its affiliates. 4.3. Certificate Acceptance No stipulation. 4.4. Certificate Suspension and Revocation 4.4.1. Circumstances for revocation A certificate will be revoked in situations where: * A certificate is no longer usable to the user because the the private key password has been forgotten or the private key is lost or otherwise unavailable to the subscriber * The subscriber's private key is compromised or is suspected to have been compromised * The subscriber's information in the certificate is suspected to be inaccurate * The subscriber is known to have violated his obligations 4.4.2. Who can request revocation Conforming CAs must accept a revocation request made by the holder of the certificate to be revoked. The revocation request may also come from the CA that issued the certificate or from other entities. 4.4.3. Procedure for revocation request The CA system administrator(s) or CA daemon must be contacted in order to request the revocation of a certificate. 4.4.4. Revocation request grace period No stipulation. 4.4.5. Circumstances for suspension The SDSC CA will not suspend certificates which it has issued. 4.4.6. Who can request suspension No stipulation, see section 4.4.5. 4.4.7. Procedure for suspension request No stipulation. 4.4.8. Limits on suspension period No stipulation. 4.4.9. CRL issuance frequency (if applicable) The SDSC CA will update its publicly published CRL immediately after a certificate has been revoked. The current CRL will also be resigned and published on a daily basis in order to provide verification of its timeliness. 4.4.10. CRL checking requirements Relying parties must verify a certificate against the most recent CRL issued from a conforming CA in order to validate the use of the certificate. 4.4.11. On-line revocation/status checking availability The SDSC CA will support on-line revocation/status checking through the publishing of its CRL and certificate index files at: http://www.sdsc.edu/CA web site. 4.4.12. On-line revocation checking requirements No stipulation. 4.4.13. Other forms of revocation advertisements available No stipulation. 4.4.14. Checking requirements for other forms of revocation advertisements No stipulation. 4.5. Security Audit Procedures 4.5.1. Types of event recorded No stipulation. 4.5.2. Frequency of processing log No stipulation. 4.5.3. Retention period for audit log No stipulation. 4.5.4. Protection of audit log No stipulation. 4.5.5. Audit log backup procedures No stipulation. 4.5.6. Audit collection system (internal vs external) No stipulation. 4.5.7. Notification to event-causing subject No stipulation. 4.5.8. Vulnerability assessments No stipulation. 4.6. Records Archival 4.6.1. Types of event recorded The SDSC CA will archive: * Issued certificates * Issued CRLs * A log of certificate requests * A log of certificate revocation requests 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 No stipulation. 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 No stipulation. 4.8. Compromise and Disaster Recovery If the SDSC CA's private key is compromised the CA must at least: * Inform subscribers, cross-certifying CAs and relying parties * Terminate the certificates and CRLs distribution service for certificates/CRLs issued using the compromised private key 4.8.1. Computing resources, software, and/or data are corrupted No stipulation. 4.8.2. Entity public key is revoked No stipulation. 4.8.3. Entity key is compromised No stipulation. 4.8.4. Secure facility after a natural or other type of disaster No stipulation. 4.9. CA Termination Termination of a CA is regarded as the situation where all service associated with a logical CA is terminated permanently. Before the CA terminates its services the following procedures MUST be completed as a minimum: * Inform all subscribers, cross certifying CAs, higher level CAs, and relying parties with which the CA has agreements or other form of established relations * Make publicly available information of its termination * Stop distributing certificates and CRLs 5. Physical, procedural, and personnel security controls 5.1. Physical Controls 5.1.1. Site locations and construction The SDSC CA system will be operated from a dedicated computer located within the SDSC machine room. 5.1.2. Physical access Physical access to the CA system is subject to the access restrictions for the SDSC machine room. 5.1.3. Power and air conditioning No stipulation. 5.1.4. Water exposures No stipulation. 5.1.5. Fire prevention and protection No stipulation. 5.1.6. Media storage No stipulation. 5.1.7. Waste disposal No stipulation. 5.1.8. Off-site backup No stipulation 5.2. Procedural controls 5.2.1. Trusted roles No stipulation. 5.2.2. Number of person required per task No stipulation. 5.2.3. Identification and authentication for each role No stipulation. 5.3. Personnel controls 5.3.1. Background, qualifications, experience, and clearance requirements The personnel operating the CA must be technically and professionally competent. 5.3.2. Background check procedures No stipulation. 5.3.3. Training requirements No stipulation. 5.3.4. Retraining frequency and requirements No stipulation. 5.3.5. Job rotation frequency and sequence No stipulation. 5.3.6. Sanctions for unauthorized actions No stipulation. 5.3.7. Contracting personnel requirements No stipulation. 5.3.8. Documentation supplied to personnel No stipulation. 6. Technical security controls 6.1. Key Pair Generation and Installation This component is used to define the provisions for key management and the corresponding technical security controls. 6.1.1. Key pair generation Conforming CA's cryptographic keys are generated by the package chosen for certificate handling. End entities' cryptographic keys are locally generated by the CA client program during the requesting process or by the CA during the server/service certificate creation process. 6.1.2. Private key delivery to entity The SDSC CA shall generate key pairs only for server or service certificates. The issued certificate and associated private key will be delivered to the certificate requester in a secure manner. User certificate private keys are generated by the CA client program and written into the user's home directory. 6.1.3. Public key delivery to certificate issuer For individual certification, the entity must submit a PKCS#10 certification request containing the public key to the CA. 6.1.4. CA public key delivery to users The SDSC CA public key will be made publicly available through the http://www.sdsc.edu/CA web page. 6.1.5. Key sizes The minimum key size for RSA key pair certificates for users and servers shall be 1024 bits. 6.1.6. Public key parameters generation No stipulation. 6.1.7. Parameter quality checking No stipulation. 6.1.8. Hardware/software key generation The keys can be generated in software or in hardware (e.g. on a cryptodevice) depending on the various tools available to the entities. 6.1.9. Key usage purposes (as per X.509v3 key usage field) User certificates: * client * e-mail * objsign * nonRepudiation * digitalSignature * keyEncipherment Server/service certificates: * server * objsign * nonRepudiation * digitalSignature * keyEncipherment 7. CA Certificates 7.1. Private Key Protection 7.1.1. Standards for cryptographic module No stipulation. 7.1.2. Private key (n out of m) multi-person control No stipulation. 7.1.3. Private key escrow No stipulation. 7.1.4. Private key backup The SDSC CA will store the private key of individual certificate holders only in encrypted form, in which case the encryption pass phrase is selected by the certificate holder and unknown to the CA. The private keys for server/service certificates may be held in either encrypted or unencrypted form in a secure location by the CA system. 7.1.5. Private key archival Private keys for SDSC CA issued certificates will be archived as indicated in section 7.1.4. 7.1.6. Private key entry into cryptographic module No stipulation. 7.1.7. Method of activating private key No stipulation. 7.1.8. Method of deactivating private key No stipulation. 7.1.9. Method of destroying private key No stipulation. 7.2. Other aspects of key pair management 7.2.1. Public key archival The SDSC CA will archive all issued certificates. Mechanisms to provide integrity controls other than digital signatures may be also be implemented. 7.2.2. Usage periods for the public and private keys User and server/service certificates issued by the SDSC CA will have a lifetime of four years. The SDSC CA certificate will have a lifetime of ten years. 7.3. Activation data 7.3.1. Activation data generation and installation Pass phrases or PINs must be selected according to "best practice". This means that it is necessary to enforce a suitable minimum length for the pass phrases and to suggest mechanisms to ensure that pass phrases show enough entropy. 7.3.2. Activation data protection Pass phrases protecting private keys of user certificates must be accessible only to the holders of those certificates. Pass phrases for server/service certificates generated by the CA administrators may be retained by the administrators. 7.3.3. Other aspects of activation data No stipulation. 7.4. Computer security controls 7.4.1. Specific computer security technical requirements No stipulation. 7.4.2. Computer security rating No stipulation. 7.5. Life cycle technical controls 7.5.1. System development controls No stipulation. 7.5.2. Security management controls No stipulation. 7.5.3. Life cycle security rating No stipulation. 7.6. Network security controls Login access to the SDSC CA computer will be limited to CA administrators and system administrators. 7.7. Cryptographic module engineering controls No stipulation. 8. Certificate and CRL profiles 8.1. Certificate Profile In order to promote interoperability with other PKI systems the SDSC CA will issue certificates profiling them accordingly to [3]. 8.1.1. Version number(s) The version field in certificates issued by the SDSC CA will contain "2", indicating X.509v3 certificates. 8.1.2. Certificate extensions In compliance with [3], the inclusion of the following certificate extensions is recommended: X509v3 Basic Constraints Netscape Cert Type Netscape Comment Netscape CA Revocation Url Netscape CA Policy Url X509v3 Subject Key Identifier X509v3 Authority Key Identifier 8.1.3. Algorithm object identifiers No stipulation. 8.1.4. Name forms No stipulation. 8.1.5. Name constraints No stipulation. 8.1.6. Certificate policy Object Identifier No stipulation. 8.1.7. Usage of policy constrains extension No stipulation. 8.1.8. Policy qualifiers syntax and semantics No stipulation. 8.2. CRL Profile 8.2.1. Version number(s) The version field in CRL certificates must state 1, indicating X.509v2 CRL. 8.2.2. CRL and CRL entry extensions No stipulation. 9. Specification administration 9.1. Specification change procedures SDSC reserves the right to modify this certificate policy without prior notice of an impending change. 9.2. Publication and notification policies This policy will be published and made available on line at SDSC. 9.3. CPS approval procedures No stipulation. 10. References [1] RFC 2527, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", March 1999 [2] RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997 [3] RFC 2459, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", January 1999 [4] RFC 2560, "Internet X.509 Public Key Infrastructure: Online Certificate Status Protocol - OCSP", June 1999 [5] NCSA, "NCSA Certificate Policy, June 1999 [6] EuroPKI, "EuroPKI Certificate Policy version 1.1", October 2000 [7] Federal Bridge Certificate Authority "X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA) Version 1.9", May 27, 2000 [8] INFN CA "Certificate Policy and Certification Practice Statement version 0.3 (Draft)", March 2001 APPENDIX 1 Certification Authority (CA) - An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the user's keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. CA-certificate - A certificate for one CA's public key issued by another CA or self signed. Certificate policy (CP) - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. Certification path - An ordered sequence of certificates which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path. Certification Practice Statement (CPS) - A statement of the practices, which a certification authority employs in issuing certificates. Certificate revocation list (CRL) - A CRL is a time stamped list identifying revoked certificates, which is signed by a CA and made freely available in a public repository. Issuing certification authority (issuing CA) - In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority). Public Key Certificate (PKC) - A data structure containing the public key of an end entity and some other information, which is digitally signed with the private key of the CA which issued it. Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography. Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is used elsewhere for the same concept.] Relying party - A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably. Subject certification authority (subject CA) - In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate. IPR ­ Intellectual Property Rights