Pittsburgh Supercomputing Center MyProxy Certificate Authority Short Lived Credential Service (PSC MyProxy CA)

Transcription

1 Pittsburgh Supercomputing Center MyProxy Certificate Authority Short Lived Credential Service (PSC MyProxy CA) Certificate Policy and Certification Practice Statement Version 1.6 Pittsburgh Supercomputing Center 300 South Craig St Pittsburgh, PA April :52 EDT (GMT -4:00)

2 TABLE OF CONTENTS 1. INTRODUCTION Overview Document Name and Identification PKI Participants Certification Authorities Registration Authorities Subscribers (End Entities) 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 Definitions 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 Identity Validation Method to Prove Possession of Private Key Authentication of Organization Identity...20 Last Revision: 12 April :52 EDT (GMT -4:00) 1

3 3.2.3 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 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 Circumstances 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 Circumstances 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 Circumstances for Certificate Modification...27 Last Revision: 12 April :52 EDT (GMT -4:00) 2

4 4.8.2 Who May Request Certificate Modification Processing Certificate Modification Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Modified 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 (if applicable) Maximum Latency for CRLs (if applicable) On-Line Revocation/Status Checking Availability On-Line 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 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 and Construction Physical Access Power and Air Conditioning Water Exposures Fire Prevention and Protection Media Storage Waste Disposal Off-Site Backup Procedural Controls Trusted Roles Number of Persons Required per Task Identification and Authentication for Each Role Roles Requiring Separation of Duties Personnel Controls...33 Last Revision: 12 April :52 EDT (GMT -4:00) 3

5 5.3.1 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 Log 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 Records Archived Retention Period for Archive Protection of Archive Archive Backup Procedures Requirements for Time-Stamping of Records Archive Collection System (Internal or External) Procedures to Obtain and Verify Archive Information Key Changeover Compromise and Disaster Recovery Incident and Compromise Handling Procedures Computing Resources, Software, and/or Data are Corrupted Entity Private Key Compromise Procedures Business Continuity Capabilities after a Disaster CA or RA 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 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...38 Last Revision: 12 April :52 EDT (GMT -4:00) 4

6 6.2.6 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(s) CRL and CRL Entry Extensions OCSP Profile Version Number(s) OCSP Extensions COMPLIANCE AUDIT AND OTHER ASSESSMENTS Frequency or Circumstances of Assessment...44 Last Revision: 12 April :52 EDT (GMT -4:00) 5

7 8.2 Identity/Qualifications of Assessor Assessor's Relationship to Assessed Entity Topics Covered by Assessment Actions Taken as a Result of Deficiency Communication of Results 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...47 Last Revision: 12 April :52 EDT (GMT -4:00) 6

8 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 Governing Law Compliance with Applicable Law Miscellaneous Provisions Entire Agreement Assignment Severability Enforcement (Attorneys' Fees and Waiver of Rights) Force Majeure Other Provisions REFERENCES REVISION HISTORY Last Revision: 12 April :52 EDT (GMT -4:00) 7

9 1. INTRODUCTION 1.1 Overview This document (hereafter Policy ) defines the Certificate Policy and Certification Practice Statement (CP/CPS) for the Pittsburgh Supercomputing Center (PSC) MyProxy Certificate Authority (PSC MyProxy CA) short-lived credential service (SLCS). This Policy is structured as specified in the Internet Engineering Task Force (IETF) document RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [Chokani et al, November 2003]. The PSC MyProxy CA provides short-lived X.509 credentials (keys and certificates with a lifetime up to 168 hours) to authorized and authenticated TeraGrid users, for use in user authentication to TeraGrid 1 resources. The PSC MyProxy CA operates as an independent SLCS to provide a second SLCS for the same TeraGrid community served by the TAGPMA-accredited NCSA SLCS. TeraGrid clients and services configured to use the NCSA SLCS as their default SLCS may use the PSC MyProxy CA as an alternate source for short-lived X.509 certificates if the NCSA SLCS is unavailable. This CP/CPS specifies minimum requirements for issuance and management of user credentials provided by the PSC MyProxy CA and for operation and security of the PSC MyProxy CA.. 1 TeraGrid is a distributed cyberinfrastructure project sponsored by the U.S. National Science Foundation (NSF). TeraGrid links computation resources at 11 partner sites located across the U.S.: Indiana University, the Louisiana Optical Network Initiative (LONI), the National Center for Supercomputing Applications (NCSA), the National Institute for Computational Sciences (NICS), Oak Ridge National Laboratory (ORNL), Pittsburgh Supercomputing Center (PSC), Purdue University, San Diego Supercomputer Center (SDSC), Texas Advanced Computing Center (TACC), the National Center for Atmospheric Research (NCAR), and University of Chicago/Argonne National Laboratory (UC/ANL). Last Revision: 12 April :52 EDT (GMT -4:00) 8

10 Figure 1 illustrates the relationship between the Certificate Authorities (CAs) of the Pittsburgh Supercomputing Center X.509 Public Key Infrastructure (PSC PKI) serving the PSC and TeraGrid communities. The PSC Root CA key signs only its own certificate and the certificates of subordinate PSC certificate authorities, in addition to the PSC Root CA certificate revocation list (PSC Root CA CRL). The PSC Root CA is maintained securely offline with CA operations executed securely by PSC security staff under direct supervision of the PSC Information Security Officer. The PSC Hosts CA, subordinate to the PSC Root CA, issues host credentials only for PSC host systems that require X.509 host keys and certificates for services operated on those hosts. PSC Hosts CA certificates are issued with a maximum lifetime of 365 days. The PSC Hosts CA private key is also used to sign its CRL. The PSC Hosts CA is maintained securely offline with CA operations executed securely by PSC security staff under direct supervision of the PSC Information Security Officer. The PSC Web Services CA, subordinate to the PSC Root CA, issues X.509 credentials for selected web services hosted on PSC systems. PSC Web Services CA certificates are issued with a maximum lifetime of 365 days. The PSC Web Services CA private key is also used to sign its CRL. The PSC Web Services CA is maintained securely offline with CA operations executed securely by PSC security staff under direct supervision of the PSC Information Security Officer. The PSC PKI does not issue long-term user credentials. The PSC MyProxy CA is a separate, online, MyProxy CA 2 short-lived credential service (SLCS) for authorized and authenticated TeraGrid users, operated on secured hosts located in the PSC production high performance computing (HPC) systems facility. Figure 2 illustrates the architecture of the PSC MyProxy CA. The PSC MyProxy CA is integrated with the TeraGrid Central Database (TGCDB) and Kerberos authentication service for identity management. The TeraGrid accounting process enrolls users in the user database, creates a TERAGRID.ORG Kerberos principal for them, and assigns them a distinguished name (DN). User DNs for NCSA SLCS-issued certificates are differentiated from those for PSC MyProxy CAissued certificates by their Organization (O=) field. Figure 2: PSC MyProxy CA functional Architecture 2 MyProxy CA: MyProxy Credential Management System Certificate Authority. National Center for Supercomputing Applications, Board of Trustees of the University of Illinois. Last Revision: 12 April :52 EDT (GMT -4:00) 9

11 To obtain credentials, PSC MyProxy CA subscribers run MyProxy client software on the host where their credentials are to be stored. The MyProxy client software generates the subscriber s private key locally, authenticates the user to the PSC MyProxy CA via Kerberos, submits a signed certificate request to the PSC MyProxy CA, and, if the request is approved, receives a signed certificate back from the PSC MyProxy CA. The PSC MyProxy CA consults data retrieved from the TeraGrid Central Database to determine the distinguished name (DN) that corresponds to the user s authenticated TERAGRID.ORG Kerberos identity and issues a certificate with the appropriate DN accordingly. Further policy and implementation details are provided throughout this document. Last Revision: 12 April :52 EDT (GMT -4:00) 10

12 1.2 Document Name and Identification Title: URL: Version: 1.6 Pittsburgh Supercomputing Center MyProxy Certificate Authority Short-Lived Credential Service (PSC MyProxy CA) Certificate Policy and Certification Practice Statement Revision Date: 12 April :52 Eastern Daylight Time (GMT -4:00) OID: { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) Pittsburgh Supercomputing Center(26703) CA(99) MyProxy CA(7512) SLCS(1) CP/CPS(1) Major Revision(1) Minor Revision(6) } 1.3 PKI Participants Certification Authorities This Policy applies to the PSC MyProxy CA. The PSC MyProxy CA's certificate is signed only by the PSC MyProxy CA itself. The PSC MyProxy CA will otherwise only sign end entity certificates. No CAs are subordinate to the PSC MyProxy CA Registration Authorities TeraGrid users apply for access to TeraGrid resources via a centralized system, POPS, operated at the National Center for Supercomputing Applications (NCSA). TeraGrid Allocations staff at NCSA enroll users into the TeraGrid Central Database (TGCDB) according to the enrollment process described in Section 4.1.2, create accounts in the TERAGRID.ORG Kerberos realm for new users, and assign distinguished names to new users according to Section 3.1. The NCSA SLCS and PSC MyProxy CA retrieve data from the TGCDB to map authenticated users to the correct X.509 distinguished name (DN), and issue X.509 certificates accordingly. NCSA allocations group staff thereby serve as the registration authority for both the NCSA SLCS and the PSC MyProxy CA Subscribers (End Entities) TeraGrid users include TeraGrid staff and all authorized users with active TeraGrid project allocations on TeraGrid production systems, as recorded in the TGCDB. The PSC MyProxy CA will provide X.509 credentials to users successfully authenticated in the TERAGRID.ORG realm via the TeraGrid Kerberos service. These credentials are issued with a PSC distinguished name (see section 3.1.4) specific to the authenticated TeraGrid user and with a unique serial number. Credentials issued by the PSC MyProxy CA may be used for authentication, encryption, and digital signing by the authenticated TeraGrid user Relying Parties PSC places no restrictions on who may accept PSC MyProxy CA certificates Other Participants Last Revision: 12 April :52 EDT (GMT -4:00) 11

13 1.4 Certificate Usage Appropriate Certificate Uses The PSC MyProxy CA issues X.509 credentials to TeraGrid users for the purpose of authentication to TeraGrid production systems and services that support Grid Security Infrastructure (GSI) 3 and/or SSL/TLS authentication. These include TeraGrid web portals, highperformance computing (HPC) systems, storage resources, Grid job submission services and data transfer services Prohibited Certificate Uses Other uses of PSC MyProxy CA certificates are not prohibited, but neither are they endorsed, approved, nor supported by PSC. 1.5 Policy Administration Organization Administering the Document This Policy is administered by the Pittsburgh Supercomputing Center, 300 South Craig Street, Pittsburgh, PA 15213, U.S.A Contact Person The primary contact for this Policy and matters relating to the PSC MyProxy CA is the PSC Information Security Officer: James A. Marsteller, Jr. <jam@psc.edu> Information Security Officer Pittsburgh Supercomputing Center 300 South Craig St Pittsburgh, PA 15213, U.S.A After hours contact information: PSC Hotline: Security issues should be reported to the PSC Hotline or vie to: <security@psc.edu> Inquiries regarding CA operations and certificates issued by the PSC PKI: <ca-admin@psc.edu> Other non-emergency inquiries: <remarks@psc.edu> Registration Authority and TeraGrid user inquiries may be directed to: TeraGrid Help Desk: or via to: <help@teragrid.org> Person Determining CPS Suitability for the Policy The PSC Information Security Officer is the designated authority with responsibility for determining CPS suitability for the Policy. 3 Grid Security Infrastructure (GSI). Last Revision: 12 April :52 EDT (GMT -4:00) 12

14 1.5.4 CPS approval procedures The PSC Information Security Officer determines CPS approval procedures in keeping with requirements of accrediting policy management authorities (PMAs) recognized by PSC and relying parties (e.g., TAGPMA). 1.6 Definitions and Acronyms Definitions This Policy makes use of the following terms and concepts. For terms defined in IETF RFC 3647, the definitions are included here verbatim: Activation Data Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share). Authentication The process of establishing that individuals, organizations, or things are who or what they claim to be. In the context of a PKI, authentication can be the process of establishing that an individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization. This corresponds to the second process involved with identification, as shown in the definition of "identification" below. Authentication can also refer to a security service that provides assurances that individuals, organizations, or things are who or what they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message s sender. Certificate (see Digital Certificate below). Certificate Authority (CA) A service established to digitally sign public digital keys, producing signed digital certificates. Relying parties trust the CA to sign the public digital key of end entities (users, systems, services, etc) only after the CA s registration authority has authenticated certificate requests by end-entities and has verified that applicants and requests meet policy requirements for certificate issuance by the CA. CA-certificate A certificate for one CA s public key issued by another CA. 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 CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range. Certification Path An ordered sequence of certificates that, 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 that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates. CPS Summary (or CPS Abstract) A subset of the provisions of a complete CPS that is made public by a CA. Credential A digital certificate and associated private digital key used in authentication transactions to establish the identity of end entities. Digital Certificate A uniquely defined data structure containing a digital public key and digital signatures of the digital public key provided by certificate authorities. Digital Signature A unique cryptographic checksum calculated for a data structure, which is then encrypted using a private digital key. In the case of digital certificates issued by a CA, the data structure includes an end entity s public key and other data to assure the uniqueness of the resulting digital signature (e.g., timestamp, serial number, attributes, etc.). The CA s private digital Last Revision: 12 April :52 EDT (GMT -4:00) 13

15 key is used to encrypt the cryptographic checksum. Relying parties then use the CA s corresponding public digital key (contained in the CA-certificate) to decrypt the checksum and verify the digital certificate s contents. End Entity a unique user, system, or service whose identity or authenticity can be validated via trusted means. GRID-SEC - A private consortium of information security professionals world-wide, focused on coordinated response to cross-grid security incidents. Identification The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes: 1. Establishing that a given name of an individual or organization corresponds to a realworld identity of an individual or organization, and 2. Establishing that an individual or organization applying for or seeking access to something under that name is, in fact, the named individual or organization. A person seeking identification may be a certificate applicant, an applicant for employment in a trusted position within a PKI participant, or a person seeking access to a network or software application, such as a CA administrator seeking access to CA systems. 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). Kerberos "a secure, single-sign-on, trusted third party, mutual authentication service" [Garman, P.6]. Kerberos is a network authentication protocol developed at the Massachusetts Institute of Technology (MIT), designed to provide strong authentication for client/server applications by using symmetric (i.e., secret-key) cryptography [ The Kerberos Network Authentication Service (version 5, current as of this document) is described in IETF RFC 4120 ( Implementations of Kerberos version 5 are available from MIT ( and from Heimdal ( Kerberos Key Distribution Center (KDC) A KDC contains Kerberos principals and their associated secret-key passwords. A Kerberos realm must have at least one primary KDC, and may have additional secondary KDCs distributed throughout the network. Principals and their passwords are automatically and securely replicated among all KDCs participating in a Kerberos Realm. A KDC provides two services: 1. Authentication Service (AS): When a client (as identified by its principal) wishes to authenticate via Kerberos, it must first contact the Authentication Service to obtain a Ticket Granting Ticket (TGT). The AS generates and encrypts a TGT using the client's password and returns it to the client. Since only the authentic client should know the correct password, it can decrypt the TGT correctly. All subsequent requests for services by the client are submitted using the TGT. The TGT has short-term validity and contains an encrypted session key used for subsequent, secured interactions by the user with the KDC's Ticket Granting Service. This enables single-sign-on: a client who is a user can use the TGT to authenticate to services without having to re-enter his/her password. 2. Ticket Granting Service (TGS): Clients authenticate to services by submitting a request to the Ticket Granting Service along with their TGT. The TGS decrypts the TGT to check its validity..it then generates a new private session key, to be shared between the client and the service. The private session key is encrypted in a service ticket using the service's password. The TGS responds to the client by sending it the service ticket together with another copy of the private session key, all encrypted using the client's password. The client then decrypts the private session key and the service ticket. The client then contacts the service, supplying the encrypted service ticket. The service decrypts the service ticket to authenticate the client and to extract the private session key. Thereafter Last Revision: 12 April :52 EDT (GMT -4:00) 14

16 the client and service establish secure communications using their mutually shared, private session key. Kerberos Principal a unique name identifying a user, host, device, or service participating in a Kerberos Realm. Kerberos Realm a name, representing a single administrative domain, for a collection of users, hosts, devices, and services, managed together for authentication purposes. Legal Name (of user end entities) The user s name as it appears on official government-issued identity credentials, e.g. passport, driver s license, birth certificate. Participant An individual or organization that plays a role within a given PKI as a subscriber, relying party, CA, RA, certificate manufacturing authority, repository service provider, or similar entity. PKI Disclosure Statement (PDS) An instrument that supplements a CP or CPS by disclosing critical information about the policies and practices of a CA/PKI. A PDS is a vehicle for disclosing and emphasizing information normally covered in detail by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS. Policy Qualifier Policy-dependent information that may accompany a CP identifier in an X.509 certificate. Such information can include a pointer to the URL of the applicable CPS or relying party agreement. It may also include text (or number causing the appearance of text) that contains terms of the use of the certificate or other legal information. Private Digital Key (or Private Key) A sequence of bits (typically generated via pseudo-random calculations) to be used privately by the key holder as a digital encryption and decryption key. The key holder must store and use the private key securely to prevent disclosure to unauthorized users. In public key cryptography procedures, the private key is generated together with a corresponding public key; data encrypted with the private key can only be correctly decrypted using the corresponding public key this assures authenticity of the encrypting source and enables digital signatures and nonrepudiation; data encrypted with the public key can only be decrypted using the corresponding private key this assures secrecy of data encrypted by the source and transmitted to the private key holder, which facilitates secure communications including private . Public Digital Key (or Public Key) A sequence of bits (typically generated via cryptographic calculations) generated as a complementary key for a corresponding private digital key. The public key is not secret and may be distributed publicly. The public key is used in public cryptography procedures to encrypt data that can only be decrypted correctly using the corresponding private key, and visa versa; the public key can only correctly decrypt data encrypted using the corresponding private key. Digital certificates contain a public key, digitally signed by one or more CAs, which serve to bind the public key to the identity of a specific end entity. Registration Authority (RA) An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants, the approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke or suspend their certificates, and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do 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 sometimes used in other documents for the same concept.] Relying Party A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably. Last Revision: 12 April :52 EDT (GMT -4:00) 15

17 Relying Party Agreement (RPA) An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those parties regarding the verification of digital signatures or other uses of certificates. Research and Education Networking - Information Sharing and Analysis Center (REN-ISAC). Set Of Provisions A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the approach described in this framework. 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 (see also Issuing certification authority). Subscriber A subject of a certificate who is issued a certificate. Subscriber Agreement An agreement between a CA and a subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates. TeraGrid TeraGrid is a distributed cyberinfrastructure project sponsored by the U.S. National Science Foundation (NSF). TeraGrid links computation resources at 11 partner sites located across the U.S.: Indiana University, the Louisiana Optical Network Initiative (LONI), the National Center for Supercomputing Applications (NCSA), the National Institute for Computational Sciences (NICS), Oak Ridge National Laboratory (ORNL), Pittsburgh Supercomputing Center (PSC), Purdue University, San Diego Supercomputer Center (SDSC), Texas Advanced Computing Center (TACC), the National Center for Atmospheric Research (NCAR), and University of Chicago/Argonne National Laboratory (UC/ANL). TeraGrid User Portal (TGUP) a web portal operated by the TeraGrid to provide user support services and documentation to the TeraGrid user community. Validation The process of identification of certificate applicants. "Validation" is a subset of "identification" and refers to identification in the context of establishing the identity of certificate applicants Acronyms AS Authentication Service (Kerberos) CA Certificate Authority CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List DER Distinguished Encoding Rules (binary file format) DN Distinguished Name (a.k.a. certificate Subject) FIPS (U.S.) Federal Information Processing Standard GSI (Globus) Grid Security Infrastructure HPC High Performance Computing IETF Internet Engineering Task Force IGTF International Grid Trust Federation IPR Intellectual Property Right KDC Key Distribution Center (Kerberos) Last Revision: 12 April :52 EDT (GMT -4:00) 16

18 LONI LRA NCAR NCSA NICS NSF ORNL PDS PEM PKI PMA PSC RA REN-ISAC RFC RP RPA SDSC SSH SSL SLCS TACC TAGPMA TGCDB TGS TGT TGUP TLS UC/ANL Louisiana Optical Network Initiative Local Registration Authority National Center for Atmospheric Research National Center for Supercomputing Applications National Institute for Computational Sciences National Science Foundation (United States) Oak Ridge National Laboratory PKI Disclosure Statement Privacy Enhanced Mail ( -compatible text file format) Public Key Infrastructure Policy Management Authority Pittsburgh Supercomputing Center Registration Authority Research and Education Networking - Information Sharing and Analysis Center Request for Comments (IETF publication) Resource Provider (TeraGrid) Relying Party Agreement San Diego Supercomputer Center Secure Shell (protocol, service and client software) Secure Sockets Layer (protocol) Short-Lived Certificate Service Texas Advanced Computing Center The Americas Grid Policy Management Authority TeraGrid Central Database Ticket Granting Service (Kerberos) Ticket Granting Ticket (Kerberos) TeraGrid User Portal Transport Layer Security (protocol) University of Chicago / Argonne National Laboratory Last Revision: 12 April :52 EDT (GMT -4:00) 17

19 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories The repository for the PSC MyProxy CA is at Publication of Certification Information The PSC MyProxy CA repository will list contact information for PSC CA operations, and will contain: The self-signed PEM-formatted CA-certificate Current signing policy file for the CA, defining subjects of certificates signed by the CA A file containing the URL for the CA s CRL, with a.crl_url file suffix Current DER-formatted CRL for the CA, with a.crl file suffix Current PEM-formatted CRL for the CA, with a.r0 file suffix Public sections of governing policy documents for the CA, including the CA s CP/CPS An example user certificate issued by the PSC MyProxy CA Public announcements issued by the PSC Information Security Officer regarding PSC CAs may also be posted at the repository website. 2.3 Time or Frequency of Publication New CA certificates will be published immediately upon issue, renewal or replacement. New CA Certificate Revocation List Uniform Resource Location (CRL URL) files will be published immediately following changes to the URLs for the locations of the corresponding CRL files. Certificate Revocation Lists (CRLs) for PSC CAs will be published immediately to the repository upon revocation of a certificate, as well as on a regular basis to assure relying parties regarding the currency of each CRL. The date of issue for each CRL will be recorded in the CRL s lastupdate field, and the CRL s nextupdate field will indicate the maximum validity lifetime of the issued CRL. The maximum validity for PSC CA CRLs will be 14 days, although new CRLs will be issued regularly on a more frequent basis. The PSC MyProxy CA will generate and publish its CRL daily, and immediately following revocation of any issued certificates. The signing policy file for the PSC MyProxy CA will be published immediately following any update to the file. New editions of public sections of governing policy documents (including this Policy) will be published immediately following updates and release for publication by the PSC Information Security Officer. 2.4 Access Controls on Repositories No restrictions will be placed on access to public documents and data published on the PSC CA repository. 24x7 availability of the PSC CA repository will be maintained on a best effort basis. PSC grants accrediting PMAs unlimited redistribution of public documents published on the PSC CA repository. Last Revision: 12 April :52 EDT (GMT -4:00) 18

20 3. IDENTIFICATION AND AUTHENTICATION 3.1 Naming Types of Names Subject distinguished names are X.500 names, with component fields defined according to the type of certificate issued Need for Names to be Meaningful Subject DNs for user certificates issued by the PSC MyProxy CA include a Common Name (CN=) field defined using the user s legal name. In the event of name conflicts, an additional number value is permanently assigned and recorded in the TeraGrid Central Database and is included in the Common Name field to distinguish between users Anonymity or Pseudonymity of Subscribers Anonymity and Pseudonymity are not supported Rules for Interpreting Various Name Forms All Subject Distinguished Names (DNs) in certificates issued by PSC CAs are defined with the following initial component fields: Country C=US Organization O=Pittsburgh Supercomputing Center The PSC MyProxy CA certificate subject DN includes an additional Common Name (CN=) field, identifying the CA: C=US, O=Pittsburgh Supercomputing Center, CN=PSC MyProxy CA Subject DNs for end entity certificates issued to authenticated users by the PSC MyProxy CA are defined as follows: Country C=US Organization O=Pittsburgh Supercomputing Center Common Name CN=TeraGrid User Legal Name [#] A TeraGrid user s Common Name component field is defined using the user s legal name field as recorded in the TeraGrid Central Database (TGCDB). This field includes a unique number suffix assigned in the event of name conflicts. Example: "C=US, O=Pittsburgh Supercomputing Center, CN=Jim Marsteller 2" Uniqueness of Names To differentiate certificates issued by PSC CAs in the global namespace, all certificates issued by PSC CAs begin with the following initial component fields: Last Revision: 12 April :52 EDT (GMT -4:00) 19

21 Country C=US Organization O=Pittsburgh Supercomputing Center End entity user certificates issued by the PSC MyProxy CA will have a unique subject DN assigned to only one TeraGrid user. New certificates with the same subject DN may be issued by the PSC MyProxy CA to the same authenticated user, but never to different users. Every certificate issued by the PSC MyProxy CA will have a unique serial number that is never reused. The MyProxy service keeps track of the serial number of the most recently issued certificate. For every new certificate issued, the service increments the current serial number and assigns it to the new certificate. TeraGrid users are identified by unique records in the TGCDB and their corresponding Kerberos principals in the TERAGRID.ORG realm. TeraGrid Allocations Group procedures and database applications check for name conflicts and ensure that applicable field contents are unique by appending, when required, a unique numeric suffix. Every TeraGrid user is assigned a unique TERAGRID.ORG Kerberos principal. The initialization procedure for TERAGRID.ORG Kerberos principals rejects duplicates. New TeraGrid users are required to change their initial TERAGRID.ORG Kerberos password within 30 days. New TERAGRID.ORG Kerberos principals that do not have their initial passwords changed within 30 days are automatically disabled. Affected users must request a new initial password to reinstate their TERAGRID.ORG principal, as described in section User account records may be deactivated but are not deleted from the TGCDB. User account records in the TGCDB are never reassigned to different users. TERAGRID.ORG Kerberos user principals are never reassigned to different users Recognition, Authentication, and Role of Trademarks 3.2 Initial Identity Validation Method to Prove Possession of Private Key Certificate requests must be digitally signed using the private key Authentication of Organization Identity Users are identified as TeraGrid users by their records in the TeraGrid Central Database (TGCDB), and assignment of a unique principal in the TERAGRID.ORG Kerberos realm. Users obtain records in the TGCDB as described in section Users employ their TERAGRID.ORG Kerberos principal and associated private password to authenticate themselves to TeraGrid systems and services Authentication of Individual Identity TeraGrid users employ a MyProxy client to generate a private key and to submit a certificate request (signed using the private key) to the PSC MyProxy CA. Users must provide their TERAGRID.ORG Kerberos principal to identify themselves to the PSC MyProxy CA. The PSC MyProxy CA authenticates users submitting certificate requests via Kerberos. TeraGrid users are prompted by the MyProxy client to enter their TERAGRID.ORG Kerberos password, which is used to decrypt a Kerberos ticket retrieved from a TERAGRID.ORG Kerberos Key Distribution Center (KDC). Successful decryption of the Kerberos ticket serves as proof of the correct password entered by the user. Last Revision: 12 April :52 EDT (GMT -4:00) 20

22 The Kerberos authentication infrastructure for TERAGRID.ORG is distributed among several participating TeraGrid Resource Provider (RP) sites. TeraGrid RP sites are connected to the TeraGrid network and provide high performance computation (HPC), storage, networking, security, and web resources to TeraGrid. The primary TERAGRID.ORG KDC is operated and administered by NCSA. PSC operates and administers a secondary KDC for the TERAGRID.ORG Kerberos realm. The PSC TERAGRID.ORG KDC is physically maintained in the same facility as the PSC MyProxy CA, as described in Section 6.5. The Kerberos authentication infrastructure only provides data to users and services (in this case the PSC MyProxy CA) necessary to perform authentication tasks. Authentication processing and resulting user authorization decisions are executed by the MyProxy service (PSC MyProxy CA) to which the user has submitted a certificate request (via their MyProxy client). Traceability of approved and denied certificate requests thereby lies in the MyProxy service transaction logs. Upon successful authentication, the PSC MyProxy CA maps the user's TERAGRID.ORG principal to a unique certificate subject DN that is based on a unique common name assigned to the user in the TGCDB. The NCSA SLCS and PSC MyProxy CA use the same TeraGrid-maintained Kerberos service to authenticate user requests. The NCSA SLCS and PSC MyProxy CA separately retrieve data from the TGCDB to map the correct distinguished name (DN) for short-term X.509 certificates issued to authenticated requesters. Queries to the TGCDB are executed via SSL-encrypted sessions. DNs for certificates issued by the NCSA SLCS are differentiated from those issued by the PSC MyProxy CA by their Organization (O=) fields, as described in section 3.1. If traceability to a user is lost, i.e., PSC is unable to contact a user based on the data associated with that user in the TGCDB, then the user's TERAGRID.ORG user principal will be disabled via TeraGrid security procedures to prevent further attempts to obtain certificates issued by the PSC MyProxy CA. Disabling the user's TERAGRID.ORG principal also prevents its use for authentication by the user to other TeraGrid services Non-Verified Subscriber Information Subscriber name, organization affiliation, phone number and postal address are verified by the TeraGrid Allocations staff upon creation of the subscriber s user record in the TGCDB and their TERAGRID.ORG Kerberos user principal. Other subscriber information is not verified Validation of Authority Users with an active TERAGRID.ORG principal are permitted to use MyProxy clients together with their TERAGRID.ORG user principal and password to obtain a certificate from the PSC MyProxy CA. TeraGrid users requesting credentials from the PSC MyProxy CA must authenticate successfully via Kerberos (using their TERAGRID.ORG user principal and password) as the user identified in the certificate to be issued Criteria for Interoperation The PSC PKI is intended to interoperate with other CAs within TeraGrid and the International Grid Trust Federation (IGTF). 3.3 Identification and Authentication for Re-Key Requests Identification and Authentication for Routine Re-Key The PSC MyProxy CA certificate will not be re-keyed. Circumstances warranting replacement of the PSC MyProxy CA key will be treated as a Key Changeover, as described in section 5.6. Last Revision: 12 April :52 EDT (GMT -4:00) 21

23 End-entity certificates issued by the PSC MyProxy CA are not re-keyed. Subscribers must request a new certificate as described in section Identification and Authentication for Re-Key after Revocation The PSC MyProxy CA certificate will not be re-keyed after revocation. End-entity certificates will not be re-keyed after revocation. 3.4 Identification and Authentication for Revocation Request Revocation of certificates issued by PSC CAs will only be initiated and executed by PSC security staff under direct supervision of the PSC Information Security Officer. Users may request revocation by contacting the PSC Hotline at or via at security@psc.edu. PSC Information Security Operations may revoke a certificate if evidence of compromise or exposure of the private key is received. PSC Information Security Operations will verify the authenticity of revocation requests by checking digital signatures on the request or by telephone to the requester s registered phone number. Last Revision: 12 April :52 EDT (GMT -4:00) 22