Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate ...itsec.bms.com/cp.pdfBristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - 2 - ”

COPYRIGHT ©BRISTOL-MYERS SQUIBB. ALL RIGHTS RESERVED. THIS DOCUMENT IS CONFIDENTIAL MATERIAL, AND IS INTENDED FOR USE ONLY BY BRISTOL-MYERS SQUIBB AND ORGANIZATIONS PARTICIPATING IN THE SAFE BIOPHARMA SYSTEM OR THEIR AUTHORIZED AGENTS. THIS DOCUMENT SHALL NOT BE DUPLICATED, USED, OR DISCLOSED IN WHOLE OR IN PART FOR ANY PURPOSES OTHER THAN THOSE APPROVED BY BRISTOL-MYERS SQUIBB.

Bristol-Myers Squibb Company (BMS)

PKI: X.509 Certificate Policy

for

BMS X.509 Certificate Authority

Date: 12/12/2014 Version: 2.17

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - ii - COPYRIGHT © Bristol-Myers Squibb

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - i - COPYRIGHT©Bristol-Myers Squibb

Record of Changes

Document Version

Document Date

Author Description Revision Details

1.0 10/14/05 Cindy Cullen Certificate Policy

2.01 10/29/07 Cindy Cullen Certificate Policy Modified for Safe BioPharma Cross certification

2.02 10/29/07 Cindy Cullen Certificate Policy Modified for Safe BioPharma Cross certification

2.10 12/22/08 Bruce Portz Certificate Policy Modified in response to Gemini Security Solutions Audit

2.10 1/26/09 Cindy Cullen Certificate Policy Minor cleanup (i.e., Safe to Safe BioPharma BioPharma, etc.)

2.11 3/23/09 Cindy Cullen Certificate Policy Section 6.6.1, antivirus software will only be used on Windows servers.

2.12 4/29/09 William Satterfield Certificate Policy Removed tracked changes and markup

2.13 5/19/09 William Satterfield Certificate Policy Section 6.6.2, integrity of the root CA software shall be verified upon start-up and whenever an update or modification is made.

2.14 6/10/10 William Satterfield Certificate Policy Updated the following sections as per the 2009 audit response document: 3.2.3.1, 4.5.1, 5.4.2, 6.1.5, 6.2.2, 6.2.10, 6.6.2, 7.1.10.2, 7.3.3.1, 8.3

2.15 12/3/13 William Satterfield Certificate Policy Removed references to SAFE and SAFE requirements that are not currently implemented

2.16 9/5/14 William Satterfield Certificate Policy Various updates to satisfy review items

2.17 12/12/14 Willaim Satterfield Certificate Policy Changes to align updated CPS with CP

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - ii - COPYRIGHT © Bristol-Myers Squibb

Table of Contents

1. INTRODUCTION .............................................................................................................................................. 1 1.1 OVERVIEW ....................................................................................................................................................... 1

1.1.1 Certificate Policy (CP) .......................................................................................................................... 2 1.2 DOCUMENT NAME AND IDENTIFICATION ......................................................................................................... 2 1.3 PKI PARTICIPANTS ........................................................................................................................................... 3

1.3.1 PKI Authorities ...................................................................................................................................... 3 1.3.1.1 BMS Policy Management Authority ................................................................................................................. 3 1.3.1.2 BMS PKI Program Manager ............................................................................................................................. 3

1.3.2 Certification Authorities ........................................................................................................................ 3 1.3.2.1 Root Certification Authority (CA) .................................................................................................................... 4 1.3.2.2 Subordinate Internal Certification Authority (CA) ............................................................................................ 4

1.3.3 Registration Authorities ......................................................................................................................... 4 1.3.4 Subscribers ............................................................................................................................................ 5 1.3.5 Relying Parties ....................................................................................................................................... 5 1.3.6 Other Participants ................................................................................................................................. 5

1.3.6.1 Certificate Status Authority ............................................................................................................................... 5 1.3.6.2 Trusted Agent (TA) ........................................................................................................................................... 6 1.3.6.3 Local Registration Authority (LRA) ................................................................................................................. 6 1.3.6.4 Machine Operator .............................................................................................................................................. 6 1.3.6.5 BMS PKI Administrator .................................................................................................................................... 6

1.4 CERTIFICATE USAGE ........................................................................................................................................ 6 1.4.1 Appropriate Certificate Uses ................................................................................................................. 6 1.4.2 Prohibited Certificate Uses ................................................................................................................... 7

1.5 POLICY ADMINISTRATION ................................................................................................................................ 7 1.5.1 Organization administering the Document ............................................................................................ 7 1.5.2 Contact Person ...................................................................................................................................... 7 1.5.3 Person determining CP suitability for the Policy .................................................................................. 7 1.5.4 CP Approval Procedures ....................................................................................................................... 7

1.6 DEFINITIONS AND ACRONYMS ......................................................................................................................... 7 1.6.1 Definitions ............................................................................................................................................. 7 1.6.2 Acronyms and Abbreviations ................................................................................................................. 7

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ...................................................................... 8 2.1 REPOSITORIES .................................................................................................................................................. 8 2.2 PUBLICATION OF CERTIFICATION INFORMATION .............................................................................................. 8 2.3 TIME OR FREQUENCY OF PUBLICATION ............................................................................................................ 8 2.4 ACCESS CONTROLS ON REPOSITORIES ............................................................................................................. 9

3. IDENTIFICATION AND AUTHENTICATION .......................................................................................... 10 3.1 NAMING ......................................................................................................................................................... 10

3.1.1 Types of Names .................................................................................................................................... 10 3.1.2 Need for names to be meaningful ......................................................................................................... 11 3.1.3 Anonymity or pseudonymity of subscribers ......................................................................................... 11 3.1.4 Rules for interpreting various name forms .......................................................................................... 11 3.1.5 Uniqueness of names ........................................................................................................................... 11 3.1.6 Recognition, authentication, and role of trademarks ........................................................................... 11

3.2 INITIAL IDENTITY VALIDATION ...................................................................................................................... 12 3.2.1 Method to prove possession of private key .......................................................................................... 12 3.2.2 Authentication of Organization Identity .............................................................................................. 12 3.2.3 Authentication of Individual Identity ................................................................................................... 12

3.2.3.1 In-Person (face-to-face) Registration .............................................................................................................. 12 3.2.3.2 Remote Registration ........................................................................................................................................ 13 3.2.3.3 Machine Subscriber Registration .................................................................................................................... 13

3.2.4 Non-verified Subscriber Information ................................................................................................... 14

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - iii - COPYRIGHT © Bristol-Myers Squibb

3.2.5 Validation of Authority ........................................................................................................................ 14 3.2.6 Criteria for Interoperation ................................................................................................................... 14

3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUEST .................................................................... 14 3.3.1 Identification and Authentication for Routine Re-Key ......................................................................... 14 3.3.2 Identification and Authentication for Re-Key after Revocation ........................................................... 15

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST ........................................................... 15

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ...................................................... 16 4.1 CERTIFICATION APPLICATION ........................................................................................................................ 16

4.1.1 Who can submit a Certificate Application ........................................................................................... 16 4.1.2 Enrollment Process and Responsibilities ............................................................................................. 16

4.2 CERTIFICATE APPLICATION PROCESSING ....................................................................................................... 16 4.2.1 Performing Identification and Authentication functions ...................................................................... 16 4.2.2 Approval or rejection of certificate applications ................................................................................. 17 4.2.3 Time to process Certificate Applications ............................................................................................. 17

4.3 CERTIFICATE ISSUANCE ................................................................................................................................. 17 4.3.1 CA actions during certificate issuance ................................................................................................ 17 4.3.2 Notification to subscriber by the CA of issuance of certificate ............................................................ 17

4.4 CERTIFICATE ACCEPTANCE ............................................................................................................................ 17 4.4.1 Conduct constituting certificate acceptance ........................................................................................ 18 4.4.2 Publication of the certificate by the CA ............................................................................................... 18 4.4.3 Notification of certificate issuance by the CA to other entities ............................................................ 18

4.5 KEY PAIR AND CERTIFICATE USAGE ............................................................................................................... 18 4.5.1 Subscriber private key and certificate usage ....................................................................................... 18 4.5.2 Relying party public key and certificate usage .................................................................................... 19

4.6 CERTIFICATE RENEWAL .................................................................................................................................. 19 4.6.1 Renewing a certificate means creating a new certificate with the same name, key, and other information as the old one, but with a new, extended validity period and a new serial number is permitted. ... 19 4.6.2 Who may request renewal .................................................................................................................... 19 4.6.3 Processing certificate renewal requests .............................................................................................. 19 4.6.4 Notification of new certificate issuance to subscriber ......................................................................... 19 4.6.5 Conduct constituting acceptance of a renewal certificate ................................................................... 19 4.6.6 Publication of the renewal certificate by the CA ................................................................................. 19 4.6.7 Notification of certificate issuance by the CA to other entities ............................................................ 19

4.7 CERTIFICATE RE-KEY .................................................................................................................................... 20 4.7.1 Circumstance for certificate re-key ..................................................................................................... 20 4.7.2 Who may request certification of a new public key .............................................................................. 20 4.7.3 Processing certificate re-keying requests ............................................................................................ 20 4.7.4 Notification of new certificate issuance to subscriber ......................................................................... 20 4.7.5 Conduct constituting acceptance of a re-keyed certificate .................................................................. 20 4.7.6 Publication of the re-keyed certificate by the CA ................................................................................ 20 4.7.7 Notification of certificate issuance by the CA to other entities ............................................................ 21

4.8 CERTIFICATE MODIFICATION .......................................................................................................................... 21 4.8.1 Circumstance for certificate modification ........................................................................................... 21 4.8.2 Who may request certificate modification ........................................................................................... 21 4.8.3 Processing certificate modification requests ....................................................................................... 21 4.8.4 Notification of new certificate issuance to subscriber ......................................................................... 21 4.8.5 Conduct constituting acceptance of modified certificate ..................................................................... 21 4.8.6 Publication of the modified certificate by the CA ................................................................................ 22 4.8.7 Notification of certificate issuance by the CA to other entities ............................................................ 22

4.9 CERTIFICATE REVOCATION AND SUSPENSION ................................................................................................ 22 4.9.1 Circumstances for Revocation ............................................................................................................. 22 4.9.2 Who can request Revocation ................................................................................................................ 22 4.9.3 Procedure for Revocation Request ...................................................................................................... 23 4.9.4 Revocation Request grace period ........................................................................................................ 23 4.9.5 Time within which CA must process the Revocation Request .............................................................. 23

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - iv - COPYRIGHT © Bristol-Myers Squibb

4.9.6 Revocation checking requirement for Relying Parties ......................................................................... 23 4.9.7 CRL issuance frequency (if applicable) ............................................................................................... 23 4.9.8 Maximum latency for CRLs (if applicable) .......................................................................................... 24 4.9.9 On-line revocation/status checking availability ................................................................................... 24 4.9.10 On-line revocation checking requirements ..................................................................................... 24 4.9.11 Other forms of revocation advertisements available ...................................................................... 25 4.9.12 Special requirements related to key compromise ............................................................................ 25 4.9.13 Circumstances for suspension ......................................................................................................... 25 4.9.14 Who can request suspension ........................................................................................................... 25 4.9.15 Procedure for suspension request ................................................................................................... 25 4.9.16 Limits on suspension period ............................................................................................................ 25

4.10 CERTIFICATE STATUS SERVICES ................................................................................................................ 25 4.10.1 Operational characteristics ............................................................................................................ 25 4.10.2 Service availability .......................................................................................................................... 26 4.10.3 Optional features ............................................................................................................................ 26

4.11 END OF SUBSCRIPTION .............................................................................................................................. 26 4.12 KEY ESCROW AND RECOVERY .................................................................................................................. 26

4.12.1 Key escrow and recovery policy and practices ............................................................................... 26 4.12.2 Session key encapsulation and recovery policy and practices ........................................................ 26

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ........................................................ 27 5.1 PHYSICAL CONTROLS ..................................................................................................................................... 27

5.1.1 Site Location and Construction ........................................................................................................... 27 5.1.2 Physical Access .................................................................................................................................... 27 5.1.3 Power and Air-conditioning ................................................................................................................ 28 5.1.4 Water Exposures .................................................................................................................................. 28 5.1.5 Fire Prevention and Protection ........................................................................................................... 28 5.1.6 Media Storage ...................................................................................................................................... 28 5.1.7 Waste Disposal .................................................................................................................................... 28 5.1.8 Off-site Backup .................................................................................................................................... 28

5.2 PROCEDURAL CONTROLS ............................................................................................................................... 29 5.2.1 Trusted roles ........................................................................................................................................ 29

5.2.1.1 Administrator .................................................................................................................................................. 29 5.2.1.2 Agent ............................................................................................................................................................... 29 5.2.1.3 Auditor ............................................................................................................................................................ 29 5.2.1.4 Operator .......................................................................................................................................................... 30 5.2.1.5 CSA Administrator .......................................................................................................................................... 30 5.2.1.6 CSA Auditor ................................................................................................................................................... 30 5.2.1.7 Registration Authority (RA) ............................................................................................................................ 30 5.2.1.8 Local Registration Authority (LRA) ............................................................................................................... 30 5.2.1.9 Trusted Agent (TA) ......................................................................................................................................... 31 5.2.1.10 Machine Operator ...................................................................................................................................... 31

5.2.2 Number of persons required per task ................................................................................................... 31 5.2.3 Identification and authentication for each role ................................................................................... 31 5.2.4 Roles requiring separation of duties .................................................................................................... 31

5.3 PERSONNEL CONTROLS .................................................................................................................................. 31 5.3.1 Qualifications, experience, and clearance requirements ..................................................................... 31 5.3.2 Background check procedures ............................................................................................................. 31 5.3.3 Training Requirements ........................................................................................................................ 32 5.3.4 Retraining Frequency and Requirements ............................................................................................ 32 5.3.5 Job rotation frequency and sequence................................................................................................... 32 5.3.6 Sanctions for unauthorized actions ...................................................................................................... 32 5.3.7 Independent contractor requirements .................................................................................................. 32 5.3.8 Documentation supplied to personnel.................................................................................................. 32

5.4 AUDIT LOGGING PROCEDURES ........................................................................................................................ 32 5.4.1 Types of Events recorded ..................................................................................................................... 33 5.4.2 Frequency of processing log ................................................................................................................ 33

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - v - COPYRIGHT © Bristol-Myers Squibb

5.4.3 Retention period for audit log .............................................................................................................. 33 5.4.4 Protection of audit log ......................................................................................................................... 33 5.4.5 Audit log backup procedures ............................................................................................................... 34 5.4.6 Audit collection system (internal vs. external) ..................................................................................... 34 5.4.7 Notification to event-causing subject ................................................................................................... 34 5.4.8 Self Assessments ................................................................................................................................... 34

5.5 RECORDS ARCHIVAL ...................................................................................................................................... 34 5.5.1 Types of records archived .................................................................................................................... 34 5.5.2 Retention period for archive ................................................................................................................ 35 5.5.3 Protection of archive ........................................................................................................................... 35 5.5.4 Archive backup procedures ................................................................................................................. 35 5.5.5 Requirements for time-stamping of records ......................................................................................... 36 5.5.6 Archive collection system (internal or external) .................................................................................. 36 5.5.7 Procedures to obtain and verify archive information .......................................................................... 36

5.6 KEY CHANGEOVER ........................................................................................................................................ 36 5.7 COMPROMISE AND DISASTER RECOVERY ...................................................................................................... 36

5.7.1 Incident and compromise handling procedures ................................................................................... 36 5.7.2 Computing resources, software, and/or data are corrupted ................................................................ 37 5.7.3 Private key compromise procedures .................................................................................................... 37 5.7.4 Business continuity capabilities after a disaster .................................................................................. 37

5.8 CA OR RA TERMINATION .............................................................................................................................. 38 5.8.1 CA Termination ................................................................................................................................... 38 5.8.2 RA Termination .................................................................................................................................... 38

6. TECHNICAL SECURITY CONTROLS ....................................................................................................... 39 6.1 KEY PAIR GENERATION AND INSTALLATION ................................................................................................. 39

6.1.1 Key Pair Generation ............................................................................................................................ 39 6.1.1.1 CA Key Pair Generation ................................................................................................................................. 39 6.1.1.2 CSA Key Pair Generation ............................................................................................................................... 39 6.1.1.3 Subscriber Key Pair Generation ...................................................................................................................... 39 6.1.1.4 RA, LRA Key Pair Generation ........................................................................................................................ 39

6.1.2 Private Key delivery to Subscriber ...................................................................................................... 39 6.1.3 Public key delivery to certificate issuer ............................................................................................... 40 6.1.4 CA public key delivery to relying parties ............................................................................................. 40 6.1.5 Key Sizes .............................................................................................................................................. 40 6.1.6 Public Key Parameters generation and Quality Checking .................................................................. 41 6.1.7 Key Usage Purposes (as per X.509 v3 key usage field) ....................................................................... 41

6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS ................................. 41 6.2.1 Cryptographic Module Standards and Controls .................................................................................. 41 6.2.2 Private Key (n out of m) multi-person control ..................................................................................... 42 6.2.3 Private Key Escrow ............................................................................................................................. 42 6.2.4 Private Key Backup ............................................................................................................................. 42

6.2.4.1 Backup of Root CA Private Signature Key ..................................................................................................... 42 6.2.4.2 Backup of Subscriber Private Keys ................................................................................................................. 43

6.2.5 Private Key Archival ............................................................................................................................ 43 6.2.6 Private Key transfer into or from a Cryptographic Module ................................................................ 43 6.2.7 Private Key storage on cryptographic module .................................................................................... 43 6.2.8 Method of activating Private Key ........................................................................................................ 43 6.2.9 Method of deactivating Private Key .................................................................................................... 43 6.2.10 Method of destroying Private Key ................................................................................................... 44 6.2.11 Cryptographic Module Rating ........................................................................................................ 44

6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT ................................................................................................ 44 6.3.1 Public key archival .............................................................................................................................. 44 6.3.2 Certificate operational periods and key pair usage periods ................................................................ 44 6.3.3 Subscriber Private Key Usage Environment ....................................................................................... 45

6.4 ACTIVATION DATA ........................................................................................................................................ 45

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - vi - COPYRIGHT © Bristol-Myers Squibb

6.4.1 Activation data generation and installation ......................................................................................... 45 6.4.2 Activation data protection ................................................................................................................... 45 6.4.3 Other aspects of activation data .......................................................................................................... 45

6.5 COMPUTER SECURITY CONTROLS .................................................................................................................. 45 6.5.1 Specific Computer Security technical requirements ............................................................................ 45 6.5.2 Computer Security Rating .................................................................................................................... 46

6.6 LIFECYCLE TECHNICAL CONTROLS ................................................................................................................ 46 6.6.1 System Development Controls ............................................................................................................. 46 6.6.2 Security Management Controls ............................................................................................................ 46 6.6.3 Lifecycle Security Controls .................................................................................................................. 46

6.7 NETWORK SECURITY CONTROLS ................................................................................................................... 46 6.8 TIME-STAMPING ............................................................................................................................................. 47

7. CERTIFICATE, CRL, AND OCSP PROFILES .......................................................................................... 48 7.1 CERTIFICATE PROFILE .................................................................................................................................... 48

7.1.1 Version Number(s) ............................................................................................................................... 48 7.1.2 Certificate Extensions .......................................................................................................................... 48 7.1.3 Algorithm object identifiers ................................................................................................................. 48 7.1.4 Name forms .......................................................................................................................................... 48

7.1.4.1 Root CA Name Form ...................................................................................................................................... 49 7.1.4.2 Subordinate Internal CA Name Form .............................................................................................................. 49 7.1.4.3 End-User Subscriber Name Form ................................................................................................................... 49 7.1.4.4 Machine Subscriber Name Form ..................................................................................................................... 49 7.1.4.5 OCSP Responder Name Form (issued by Root CA) ....................................................................................... 49

7.1.5 Name constraints ................................................................................................................................. 50 7.1.6 Certificate policy object identifier ....................................................................................................... 50 7.1.7 Usage of Policy Constraints extension ................................................................................................ 50 7.1.8 Policy qualifiers syntax and semantics ................................................................................................ 50 7.1.9 Processing semantics for the critical Certificate Policies extension ................................................... 50 7.1.10 BMS Certificate Formats ................................................................................................................ 51

7.1.10.1 Root CA Certificate Profile ........................................................................................................................ 51 7.1.10.2 Internal Subordinate CA Certificate Profile ............................................................................................... 51 7.1.10.3 End-User Subscriber Certificate Profile ..................................................................................................... 52 7.1.10.4 Machine Subscriber Certificate Profile ...................................................................................................... 53 7.1.10.5 OCSP Responder Certificate Profile .......................................................................................................... 54

7.2 CRL PROFILE ................................................................................................................................................. 55 7.2.1 Version number(s) ............................................................................................................................... 55 7.2.2 CRL and CRL entry extensions ............................................................................................................ 55 7.2.3 BMS CRL Format ................................................................................................................................ 55

7.3 OCSP PROFILE ............................................................................................................................................... 56 7.3.1 Version number(s) ............................................................................................................................... 56 7.3.2 OCSP extensions .................................................................................................................................. 56 7.3.3 BMS OCSP Format .............................................................................................................................. 56

7.3.3.1 OCSP Request Profile ..................................................................................................................................... 56 7.3.3.2 OCSP Response Profile ................................................................................................................................... 56

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ............................................................................ 58 8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT ....................................................................................... 58 8.2 IDENTITY/QUALIFICATIONS OF ASSESSOR ...................................................................................................... 58 8.3 ASSESSOR'S RELATIONSHIP TO ASSESSED ENTITY .......................................................................................... 58 8.4 TOPICS COVERED BY ASSESSMENT ................................................................................................................. 58 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ................................................................................................ 58 8.6 COMMUNICATION OF RESULTS ...................................................................................................................... 59

9. OTHER BUSINESS AND LEGAL MATTERS ............................................................................................ 60

10. APPENDIX A: DEFINITIONS...................................................................................................................... 60

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - vii - COPYRIGHT © Bristol-Myers Squibb

11. APPENDIX – B: ACRONYMS ...................................................................................................................... 68

12. APPENDIX – C: REFERENCES ................................................................................................................... 69

List of Tables

TABLE 1 - POLICY OBJECT IDENTIFIER ........................................................................................................................... 3 TABLE 2 – PUBLICATION OBLIGATIONS .......................................................................................................................... 8 TABLE 3 – CRL ISSUANCE FREQUENCY ....................................................................................................................... 24 TABLE 4 – ON-LINE STATUS CHECKING REQUIREMENTS ............................................................................................... 26 TABLE 5 - DATA TO BE ARCHIVED................................................................................................................................ 35 TABLE 6 - KEY SIZES .................................................................................................................................................... 40 TABLE 7 – CRYPTOGRAPHIC MODULE STANDARDS...................................................................................................... 42 TABLE 7 – CRYPTOGRAPHIC MODULE STANDARDS...................................................................................................... 42 TABLE 8 - PRIVATE AND PUBLIC KEY USAGE PERIODS ................................................................................................ 44 TABLE 9 - ALGORITHM OIDS ....................................................................................................................................... 48 TABLE 10 - SUBJECT KEY GENERATION ALGORITHM ................................................................................................... 48 TABLE 11 - ROOT CA NAME FORM .............................................................................................................................. 49 TABLE 12 – SUBORDINATE INTERNAL CA NAME FORM ............................................................................................... 49 TABLE 14 – MACHINE SUBSCRIBER NAME FORM ......................................................................................................... 49 TABLE 15 – OCSP RESPONDER NAME FORM (ISSUED BY ROOT CA) ........................................................................... 50 TABLE 16 – POLICY OBJECT IDENTIFIER ...................................................................................................................... 50 TABLE 17 – ROOT CA CERTIFICATE PROFILE ............................................................................................................... 51 TABLE 18 - SUBORDINATE INTERNAL CA CERTIFICATE PROFILE ................................................................................. 52 TABLE 19 - END-USER SUBSCRIBER AUTHENTICATION CERTIFICATE PROFILE ............................................................ 53 TABLE 20 - MACHINE SUBSCRIBER CERTIFICATE PROFILE ........................................................................................... 54 TABLE 21 - OCSP RESPONDER CERTIFICATE PROFILE ................................................................................................. 55 TABLE 22 - CERTIFICATE REVOCATION LIST (CRL) PROFILE ...................................................................................... 55 TABLE 23 - OCSP REQUEST PROFILE ........................................................................................................................... 56 TABLE 24 - OCSP RESPONSE PROFILE ......................................................................................................................... 57

List of Figures

FIGURE 1 - TYPES OF CERTIFICATION AUTHORITIES ....................................................................................................... 4

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - 1 - COPYRIGHT©Bristol-Myers Squibb

1. INTRODUCTION

The Bristol-Myers Squibb Company (BMS) Public Key Infrastructure (PKI) consists of a set of products and services that provide and manage X.509 standard-based digital certificates1 for public key cryptography. In general, the certificates issued by the BMS PKI identify the individual or device named in the digital certificate, and binds that person or device to a particular public/private key pair. This Certificate Policy (CP) describes the policies and procedures that are used by BMS to verify the binding before certificates are issued, and for the maintenance of that binding. This CP applies to certificates issued to BMS-designated employees, contractors and other affiliated personnel and devices for the purposes of authentication, signature, and confidentiality. The reliability of the BMS public-key cryptography portion of the BMS Strong Authentication, Digital Signature and encryption Programs depends on the secure and trustworthy operation of the BMS PKI, including its equipment, facilities, personnel, and procedures. This policy asserts that the BMS PKI architecture is implemented through a hierarchical PKI. Under this CP, the BMS PKI will provide the following security management services: Key generation/storage

Certificate generation, update, renewal, rekey, and distribution

Certificate revocation list (CRL) generation and distribution

Online Certificate Status Protocol (OCSP) response generation and distribution

Directory management of certificate related items

Certificate token initialization/programming/management

System management functions (e.g., security audit, configuration management, archive.)

This CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) request for comments (RFC) 3647, Certificate Policy (CP) and Certification Practice Statement (CPS) Framework. . 1.1 Overview

The BMS PKI supports multiple purposes: It directly complements the implementation and operational realization of a centralized

BMS Strong Authentication capability for network asset, internal web-site, and application access control by providing a trusted source for identity and authentication certificates.

1 In this document, the terms “digital certificate” and “pubic key certificate” are used interchangeably to connote “public key

certificate”.

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - 2 - COPYRIGHT © Bristol-Myers Squibb

It delivers unique electronic identity credentials for legally enforceable and regulatory compliant digital signatures within BMS for audit purposes and electronic record purposes.

It facilitates the protection of BMS sensitive, proprietary, and privacy-controlled

information by providing encryption certificates for users and devices for protecting this information while it is in transit over the BMS local network, or over public or other external networks.

This document defines the creation and management of Version 3 - X.509 public-key certificates for use in applications requiring communication between various networked computer-based systems. Such applications include, but are not limited to, electronic mail; transmission of sensitive information; authentication of infrastructure components such as web servers, firewalls, directories, and virtual private network connections and digital signatures for the purpose of non-repudiation. BMS Policy Management Authority (PMA) has responsibility for directing and development of this CP, and for approving it and any update to it. A bibliography of related publications is included at the end of this document in APPENDIX C:REFERENCES. These publications contain information that was used in support of the definition of BMS PKI operations. A list of acronyms and definitions of relevant terms can be found in APPENDIX A: Definitions and APPENDIX – B: Acronyms 1.1.1 Certificate Policy (CP)

X.509 certificates shall contain one or more registered certificate policy OIDs in the certificate policy extension that in turn shall be used by a Relying Party to decide whether a Certificate is trusted for a particular purpose. The OIDs correspond to specific levels of assurance established by a CP that should be available to Relying Parties. Certificates issued by a CA shall assert the appropriate assurance level in the certificatePolicies extension by including applicable OID(s). 1.2 Document Name and Identification

The title for this document is “Bristol-Myers Squibb (BMS) PKI: X.509 Certificate Policy”. This document incorporates three specific certificate policies: a policy for human subscribers and devices at a medium assurance level, a policy for human subscribers at a high assurance level, and a policy for machine subscribers at a low assurance level (applies only to certificates used for communications and not appropriate for use for data storage). Each level of assurance has an object identifier (OID), to be asserted in certificates issued by CAs who comply with the policy stipulations herein. Certificates issued to human end-user subscribers may contain id-bms-certpolicy-mediumAssurance, id-bms-certpolicy-mediumSoftware, id-bms-certpolicy-mediumHardware or the id-bms-certpolicy-lowAssurance OID. Certificates issued to devices under this policy shall include the id-bms-certpolicy-lowAssurance OID.


The OIDs registered as follows: {joint-iso-ccitt(2) country(16) us(840) organization(1) BMS(114331)……… }

Object Identifier Value

id-bms-certpolicy-mediumAssurance 2.16.840.1.114331.1.1.3

id-bms-certpolicy-highAssurance 2.16.840.1.114331.1.1.5

id-bms-certpolicy-lowAssurance 2.16.840.1.114331.1.1.6

Id-bms-certpolicy-mediumSoftware 2.16.840.1.114331.1.1.7

Id-bms-certpolicy-mediumHardware 2.16.840.1.114331.1.1.8

Table 1 - Policy Object Identifier

1.3 PKI Participants

1.3.1 PKI Authorities

1.3.1.1 BMS Policy Management Authority

The BMS Policy Management Authority (PMA) is a body established by the BMS to: Oversee the creation and update of certificate policies, including evaluation of changes

requested by any other person or organization, and plans for implementing any accepted changes.

Review and analyze the Certification Practice Statement (CPS) governing BMS CAs to ensure that the practices of these CAs comply with this BMS Certificate Policy.

Review the results of CA compliance audits to determine if a CA adequately meets the stipulations of approved CPS documents, and make recommendations to the CA regarding corrective actions, or other measures that might be appropriate, such as revocation of CA certificates.

1.3.1.2 BMS PKI Program Manager

The Program Manager is the individual who has BMS PMA approval and principal responsibility for overseeing the proper operation of the BMS PKI. 1.3.2 Certification Authorities

The CA is the collection of hardware, software and operating personnel that create, sign, and issue public key certificates to subscribers. The CA is responsible for the issuing and managing certificates including: The certificate manufacturing process

Publication of certificates

Revocation of certificates


Generation and destruction of CA signing keys

Ensuring that all aspects of the CA services, operations, and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP.

CA is an inclusive term, and includes all types of CAs. Any CA requirement expressed in this Policy applies to all CA types unless expressly stated otherwise. The following sub-sections define the types of CAs applicable to this CP.

Figure 1 - Types of Certification Authorities

1.3.2.1 Root Certification Authority (CA)

The Root CA is at the top of the BMS PKI hierarchy and issues a self-signed certificate. The Root CA issues CA certificates and selected end-entity certificates. 1.3.2.2 Subordinate Internal Certification Authority (CA)

A “Subordinate Internal CA” shall encompass any CA that has a certificate issued to it by the Root CA and issues certificates to human and devices within BMS. Certificates issued by a Subordinate Internal CA are used for the purpose of authentication, data integrity and confidentiality. 1.3.3 Registration Authorities

The Registration Authority (RA) is the entity who collects and verifies the subscriber’s identity and information to be included in the subscriber’s public key certificate. The RA performs its function in accordance with a CPS. The RA is responsible for: Control over the registration process

The identity-proofing process

Initiating revocation requests


Approving re-key requests

1.3.4 Subscribers

A subscriber is the entity whose name appears as the subject in a certificate. The subscriber asserts that he or she uses the key and certificate in accordance with the Certificate Policy asserted in the certificate, and does not issue certificates. For this policy, subscribers are limited to BMS-designated employees, contractors and affiliated personnel, and devices. Although CAs are sometimes technically considered to be “subscribers” in a PKI, the term “subscriber” as used in this document refers only to those who request certificates for uses other than signing and issuing certificates or certificate status information. 1.3.5 Relying Parties

A Relying Party is the entity that relies on the validity of the binding of the subscriber’s name to a public key. The relying party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. The relying party can use the certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the holder of the certificate. A relying party may use information in the certificate (such as CP identifiers) to determine the suitability of the certificate for a particular use. For this certificate policy, the relying party can be any entity that wishes to validate the binding of a public key to the name of a BMS-designated employee, contractor, or other affiliated personnel, and devices. 1.3.6 Other Participants

The CAs and RAs operating under this CP may require the services of other security, community, and application authorities, such as compliance auditors, local registration authorities, etc. In addition to those participants listed below, the CPS shall identify any additional parties responsible for providing such services, and the mechanisms used to support these services. 1.3.6.1 Certificate Status Authority

Server based Certificate Status Authorities (CSAs) such as Online Certificate Status Protocol (OCSP) Responders and Simple Certificate Validation Protocol (SCVP) status providers may provide revocation status information or full certification path validation services respectively. In addition to using Certificate Revocation Lists (CRLs) for publishing certificate status information for the certificates it issues, CAs shall make their certificate status information available through the services of OCSP Responders.


1.3.6.2 Trusted Agent (TA)

The TA collects and verifies each subscriber’s identity in support of the Subscriber registration. The TA shall work closely with an RA or LRA to support Subscriber registration. 1.3.6.3 Local Registration Authority (LRA)

The LRA duties are similar to the duties of the RA. LRA may service a limited population as authorized by the RA. LRA collects and verifies each Subscriber’s identity and information for inclusion in the Subscriber’s certificate. 1.3.6.4 Machine Operator

The Machine Operator shall serve as the representative of a Machine Subscriber to an RA or LRA in order to register the Machine Subscriber with the PKI. 1.3.6.5 BMS PKI Administrator

The BMS PKI Administrator is a BMS-designated employee who is vetted by the BMS PMA to maintain, operate and oversee all PKI operations for BMS and under direction from the BMS PMA.

1.4 Certificate Usage

The sensitivity of the information processed or protected using certificates issued by a CA will vary significantly. Organizations must evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity or significance of the information. 1.4.1 Appropriate Certificate Uses

This policy can be used to protect BMS sensitive data carried by the following classes of applications: Secure Web Access: BMS certificates shall be used for authentication and digital

signatures during SSL handshaking.

VPN Access: BMS certificates may be used as the primary authentication mechanism for supporting PKI-enabled Virtual Private Networks (VPNs) that allow secure connectivity to resources on BMS’s internal network.

S/MIME Secure Email: BMS certificates shall enable secure S/MIME mail exchanges between internal and external subscribers.

Business, Legal and Regulated Applications: BMS certificates shall be used for authentication to regulated applications and data, and for the application of digital signatures to electronic records in support of business, legal, and regulated process workflows.


All end-user subscriber certificates have the “Basic Constraints” extension set to “None” and as such, shall not be substituted for CA certificates.

1.4.2 Prohibited Certificate Uses

This policy does not stipulate the prohibited use of BMS issued certificates other than what is outlined in section 4.5.1 of this document 1.5 Policy Administration

1.5.1 Organization administering the Document

BMS PMA is responsible for the definition, revision and promulgation of this policy. 1.5.2 Contact Person

Contact information for questions regarding this Certificate Policy can be found on the web at: http://itsec.bms.com 1.5.3 Person determining CP suitability for the Policy

The BMS PMA is responsible for approving any CS that establishes its conformity to this policy. The CP shall be reviewed annually for conformity. 1.5.4 CP Approval Procedures

The CP to be approved shall be submitted to the BMS PMA for approval. The PMA shall accept or reject the CP. If rejected, the identified discrepancies shall be resolved and the revised CP shall be resubmitted to the PMA for approval. This process shall continue until the CP is approved. 1.6 Definitions and Acronyms

1.6.1 Definitions

See Appendix A for a table of definitions. 1.6.2 Acronyms and Abbreviations

See Appendix B for a table of acronyms and abbreviations.


2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1 Repositories

A variety of mechanisms may be used for posting information into a repository. The information that needs to be posted in the repositories maintained by the CAs is described in Section 2.2. The repository obligations shall include: Directory Server Systems that are also accessible through the Lightweight Directory

Access Protocol (LDAP, version 3) and/or Active Directory, and/or through the Hypertext Transfer Protocol (HTTP). NOTE : Accessibility to LDAP is limited to within BMS intranet.

Availability of the information as required by the certificate information posting and retrieval stipulations of this CP, and

Access control mechanisms when needed to protect repository information as described in Section 2.4.

Posted certificates and CRLs may be replicated in additional repositories for performance enhancement.

2.2 Publication of Certification Information

This BMS CP shall be made available to all BMS Participants and other parties that are deemed appropriate. Information on how to obtain a copy of the BMS CP shall be posted on the BMS website (http://itsec.bms.com). The CAs shall also publish a CPS for the purpose of examination against this policy. The relevant section of CPS shall be made available to Relying Parties on request. The following table lists the different types of CAs and their publication responsibilities.

Type of CA Publication Responsibility

Root CA CA certificates, CRLs

Subordinate Internal CA CA Certificates, CRLs

BMS MediumHardware Assurance CA, BMS MediumSoftware Assurance CA

CA Certificates, CRLs

BMS Basic Assurance CA CA Certificates, CRLs

Table 2 – Publication Obligations

CAs may optionally post subscriber certificates in a directory in accordance with the CPS. 2.3 Time or Frequency of Publication

The CP and CPS and any subsequent changes to these documents shall be made available to BMS participants as set forth in Section 1.5.4, 2.2 and Section 9.12 within one week of approval by the BMS PMA.


Certificates shall be published promptly following proof of possession of private key as specified in Section 3.2.1 and subscriber acceptance as specified in Section 4.4. The CRL shall be published as specified in Section 4.9.7. 2.4 Access Controls on Repositories

The CA shall protect information not intended for public dissemination or modification. CA certificates and CRLs in the repository may be publicly available through the Internet. Updates to the repository shall be subjected to strict access control mechanisms to ensure that only authorized entities are allowed to update the contents of the repository. Access to other information in the CA repositories shall be determined by BMS pursuant to its authorizing and controlling statutes. The CPS shall detail what information in the repository shall be exempt from automatic availability and to whom, and under which conditions the restricted information may be made available.


3. IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of Names

A CA shall only generate and sign certificates that contain a non-null subject DN complying with the X.500 standard. Certificates may also include other name forms in the subject alternative name forms field. This CP does not restrict the types of names that can be used in the subject alternative name forms field, but does require the RFC 822 e-mail address [RFC 822] of the Subject to appear in that field for end-entity subscribers. The distinguished name for the Root CA shall take the following form:

dc=com, dc=BMS, cn=BMS Root CA

However, the distinguished name for all other CAs (Subordinate Internal CA) within the BMS PKI shall take the following form.

dc=com, dc=BMS, cn= CA common name

The organizational unit assurance level2 is used to specify the class of the certificate. The distinguished name of BMS subscriber certificates may include bmsid and uid. BMSID and UID are guaranteed to be unique by internal BMS procedures and used exclusively for BMS internal operations. The distinguished name of the BMS-designated employee subscribers shall take one of the two following forms:

dc=com, dc=BMS, ou=assurance level, e=email, cn= firstname lastname

dc=com, dc=BMS, ou=assurance level, e=email, cn= lastname, firstname

The distinguished name of the BMS contractor subscribers shall take one of the two following forms:



The distinguished name of the BMS affiliate subscribers shall take one of the two following forms:



The distinguished name of the device subscribers shall take the following form: 2 The assurance level may be specified in the certificate common name instead of the certificate subject organizational unit.


dc=com, dc=BMS, cn= unique device common name

OCSP Responder certificates issued by a CA shall take the form as described below:

dc=com, dc=BMS, cn= Responder unique common name

3.1.2 Need for names to be meaningful

The subscriber certificates issued pursuant to this CP are meaningful only if the names that appear in the certificates can be understood and used by relying parties. Names used in the certificates must identify in a meaningful way the subscriber to which they are assigned. For people, this will typically be a legal name, so the preferred common name form is

cn=firstname initial. lastname

For equipment, this may be the type, model name or any other humanly understandable identification. While the issuer name in CA certificates is not generally interpreted by relying parties, this CP still requires use of meaningful names by CAs issuing under this policy. The subject name in CA certificates must match the issuer name in certificates issued by the subject, as required by RFC 3280, even if the subject’s name is not meaningful. 3.1.3 Anonymity or pseudonymity of subscribers

Anonymous certificates shall not be issued under this policy. 3.1.4 Rules for interpreting various name forms

Rules for interpreting name forms are contained in the applicable certificate profile (see Section 7.1), and are established by the CA itself. 3.1.5 Uniqueness of names

Name uniqueness for certificates issued by the root CA to each subordinate CA must be enforced. Each CA and its associated RAs shall have name uniqueness within the X.500 name space. 3.1.6 Recognition, authentication, and role of trademarks

The BMS PMA shall resolve any name collisions brought to its attention. This policy does not stipulate any additional requirements for recognition, authentication and role of trademarks.


3.2 Initial Identity Validation

3.2.1 Method to prove possession of private key

In all cases where the subscriber generates the keys, the subscriber may be required to prove to the CA, possession of the private key, which corresponds to the public key in the certificate request. For signature keys, this may be done by signing a value provided by the CA. For key management keys, i.e. encryption keys, the CA or RA may encrypt the subscriber's certificate in a confirmation request message. The subscriber can then decrypt and return the certificate to the CA or RA in a confirmation message. In the case where key generation is performed under the CA or RA’s direct control, proof of possession is not required. 3.2.2 Authentication of Organization Identity

Requests for a BMS CA certificate shall include the CA name, location, the need for and documentation of the existence of the CA. The BMS PMA shall verify the information, in addition to the authenticity of the requesting BMS representative and the representative’s authorization to act in the name of the CA. The BMS PMA authorized representative or external entity authorized representative shall verify the information, the authenticity of the requesting representative and the representative’s authorization to act in the name of the organization for cross certification requests. 3.2.3 Authentication of Individual Identity

Procedures used by Registration Authorities (RAs) for authenticating individuals prior to issuance of PKI credentials to BMS personnel and affiliates may be more stringent than that set forth below. When this is the case, the procedures for authentication of personnel shall apply in addition to the guidance in this section. 3.2.3.1 In-Person (face-to-face) Registration

The RA (either CA, RA, LRA or TA) shall record the process that was followed for issuance of each certificate. The process documentation and authentication requirements shall include the following: The identity of the RA performing the identification.

A signed declaration by the RA that he or she verified the identity of the Subscriber. This declaration may use the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable format under non-US law.

A unique identifier(s) from the ID(s) of the subscriber (or some other trusted source of information on the Subscriber).

The date and time of the verification, and

A declaration of identity signed by the subscriber using a handwritten signature and in the presence of the RA. This declaration may use the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable format under non-US law.


For BMS employees, the authentication procedures must include the following steps: Applicant’s identity shall be established by in-person proofing before the Registration Authority, based on the following process: Submission of the BMS picture badge and antecedent3 data including a national

government issued ID or two state issued IDs, one being a photo ID, which is maintained by HR

For BMS contractors and other affiliated personnel, the authentication procedures must include the following steps: Applicant’s identity shall be established by in-person proofing before the RA by: Submission of the BMS picture badge and antecedent data including a national

government issued ID or two state issued IDs, one being a photo ID, which is maintained by HR

3.2.3.2 Remote Registration

BMS High Assurance certificates will not be issued to BMS employees, contractors and affiliated personnel on the basis of being remotely authenticated i.e. without face-to-face identity proofing. The applicant’s identity shall be established based on successful login into the BMS Intranet using the applicant’s BMS username and password. Identity-proofing requirements for Medium and Low Assurance certificates include the RA to record the following: The identity of the RA performing the identification.

A unique identifier(s) from the ID(s) of the subscriber or some other trusted source of information on the Subscriber, such as BMS antecedent data, and

The date and time of the verification. 3.2.3.3 Machine Subscriber Registration

Some computing and communications devices (e.g. routers, firewalls, servers etc), will be named as certificate subjects. In such cases, these devices must have a human sponsor (Machine Operator). This sponsor is responsible for providing the following registration information: Equipment identification (e.g., serial number) or service name (e.g., DNS name)

3 The antecedent data is collected and maintained by BMS or a BMS designated agency for employee hiring. Since the BMS

identification badge proof that this data has been collected, it is not necessary to present this data for certificate registration.


Equipment public keys

Equipment authorizations and attributes (if any are to be included in the certificate)

Contact information to enable the CA or RA to communicate with the sponsor when required

The identity of the sponsor shall be authenticated by: Verification of digitally signed messages sent from the sponsor using a certificate issued

under this policy with equal or greater assurance than the certificate being requested; or

In-person registration by the sponsor, with the identity of the sponsor confirmed in accordance with the requirements of Section 3.2.3.1.

3.2.4 Non-verified Subscriber Information

Information that is not verified shall not be included in any medium assurance or high assurance certificates issued by the BMS PKI. 3.2.5 Validation of Authority

The BMS PMA is responsible for authorizing cross-certification with any external PKI. 3.2.6 Criteria for Interoperation

External PKIs with whom BMS cross-certifies shall

• Operate a PKI as per Agreements with BMS.

• Issue certificates compliant with the profiles described in this CP,

• Make certificate status information available as per the agreements with BMS. BMS shall make its CRL (or archived CRL) and certificate status information available to the external PKIs as per the agreements between the BMS and the external PKI. 3.3 Identification and Authentication for Re-Key Request

3.3.1 Identification and Authentication for Routine Re-Key

The longer and more often a key is used, the more susceptible it is to loss or discovery. This results in less assurance in its binding. Therefore, it is important to periodically obtain new keys and re-establish the subject’s identity. Section 6.3.2 establishes usage periods for private keys for both CAs and subscribers. To facilitate re-key, a new certificate can be obtained while the old one is valid. This can be done in-band using a signed re-key request, where the existing (old) key is used to sign the request. Re-keying a certificate means that a new certificate is created that has the same characteristics and level as the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key) and a different serial number, and it may be


assigned a different validity period. Signature key shall be used to establish identity for a new signature, confidentiality or authentication key or by using the initial identity-proofing process as described above. The Principal CAs shall identify themselves through the use of their current Signing Key or by using the initial identity-proofing process as described above. Subscribers and CAs shall identify themselves through the use of their current Signing Key or by using the initial identity-proofing process as described above. 3.3.2 Identification and Authentication for Re-Key after Revocation

For all levels of assurance, subscribers and CAs requesting certificates after revocation must meet initial registration requirements as described in Section 3.2. 3.4 Identification and Authentication for Revocation Request

All revocation requests must be authenticated; see Section 4.9.2 and 4.9.3. Requests to revoke a certificate may be authenticated using that certificate public key, regardless of whether or not the private key has been compromised.


4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1 Certification Application

4.1.1 Who can submit a Certificate Application

The BMS PMA authorized representative of BMS PKI shall submit the application for cross-certification with external PKIs. The authorized representative of BMS PKI shall also process the cross certification request from external PKIs upon approval from the BMS PMA. BMS-designated employees are eligible to apply for a certificate from the BMS CAs. Depending on their location, attributes of their job function and identity-proofing requirements, the BMS employees shall be entitled to certificates with different assurance levels. The Machine Operator is responsible for submitting a certificate application for computing and communication device certificates and for all other equipment that require the need for public and private key pairs (e.g. SSL Web Server). 4.1.2 Enrollment Process and Responsibilities

This Policy does not specify any additional requirements on the enrollment process and the responsibilities of the various BMS PKI entities other than those mentioned in Section 3.2.3. All communications among the CAs, RAs, LRAs and TAs supporting the certificate application and issuance process shall be authenticated and protected from modification; any electronic transmission of shared secrets shall be protected. Communications may be electronic or out-of-band. Where electronic communications are used, cryptographic mechanisms commensurate with the strength of the public/private key pair shall be used. Out-of-band communications shall protect the confidentiality and integrity of the data. 4.2 Certificate Application processing

It is the responsibility of the CA and RA to verify that the information in certificate applications is accurate. 4.2.1 Performing Identification and Authentication functions

In general, the BMS PKI Authorities must perform the following steps when an applicant applies for a certificate: Establish the applicant’s authorization to obtain a certificate (as per Section 3.2.3 and

4.1.1).

Establish identity of the applicant (as per Section 3.2.3)

Obtain the applicant’s public key and verify the applicant’s possession of the private key for each certificate required (per Section 3.2.1)


Verify any role or authorization information requested for inclusion in the certificate (if required).

All the above-mentioned steps can be performed in any order by the BMS PKI Authorities before certificate issuance in a manner that does not defeat security at any stage of the process. 4.2.2 Approval or rejection of certificate applications

On successful completion of the steps outlined in Section 3.2.3 and 4.2.1, the Registration Authority shall approve the certificate application for issuance of a certificate with the desired level of assurance. Certificates shall be issued as described in Section 4.3. A BMS Registration Authority may reject a certificate application due to incompleteness or inaccuracy of information provided or in the event that the subscriber is not permitted to receive a certificate at the desired assurance level. The BMS Registration Authority shall inform the applicant as to the reason why the application has been rejected. 4.2.3 Time to process Certificate Applications

This policy makes no stipulation other than mentioned in Section 3. 4.3 Certificate Issuance

4.3.1 CA actions during certificate issuance

The CA shall verify the source of a certificate request before issuance. Certificates shall be checked to ensure that all fields and extensions are properly populated. After generation, verification, and acceptance, a CA shall post the certificate as per Section 2.3. 4.3.2 Notification to subscriber by the CA of issuance of certificate

After approval of the certificate application and generation of the subscriber certificate by the CA, the CA shall inform the subscriber of the issuance of its certificate and the method for obtaining this certificate. The steps involved in the process for notifying the subscriber shall be detailed in the CPS. External entities with whom BMS PKI cross-certifies shall be notified as per the agreements between BMS and the cross-certified entity. 4.4 Certificate Acceptance

Before a BMS CA allows a subscriber to make effective use of its private key, a Registration Authority will need to complete the issuance procedures that are outlined in Section 4.4 of the BMS CPS.


Explain to the subscriber its responsibilities as defined in subscriber agreement4 framework ;

Inform the subscriber of the creation of a certificate and the contents of the certificate;

Require the subscriber to indicate acceptance of its obligations and its certificate,

Document the subscriber's acceptance of its responsibilities and its certificate.

4.4.1 Conduct constituting certificate acceptance

An issued BMS certificate shall be deemed accepted by the subscriber when any of the following conditions apply: Acceptance of Certificate, or

Successful download of certificate by subscriber from the CA using a web-browser.

4.4.2 Publication of the certificate by the CA

This policy does not specify any additional requirements on the publication of certificates by the CA in addition to those described in Sections 2.2 and 2.3. This CP makes no stipulation regarding publication of Subscribers Certificates. 4.4.3 Notification of certificate issuance by the CA to other entities

External entities with whom BMS PKI cross-certifies shall be notified as per the agreements between BMS and the cross-certified entity. 4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

Subscribers shall: Accurately represent themselves in all communications with the BMS PKI;

Protect their private keys at all times, in accordance with this Policy, as stipulated in their certificate acceptance agreements, and local procedures;

Notify, in a timely manner, the CA that issued their certificates of suspicion that their private keys are compromised or lost. Such notification shall be made directly, or indirectly through mechanisms consistent with the CPS;

Abide by all the terms, conditions, and restrictions levied upon the use of their private keys and certificates;

Use certificates provided by the BMS PKI only for lawful purposes.

4 Signing a subscriber agreement is not required for basic assurance certificate registration.


4.5.2 Relying party public key and certificate usage

There are currently no relying party agreements in place. An outline of the basic requirements for relying party agreements is located in the BMS CPS.

4.6 Certificate renewal

4.6.1 Renewing a certificate means creating a new certificate with the same name, key, and other information as the old one, but with a new, extended validity period and a new serial number is permitted.

A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been compromised, and the Subscriber name and attributes are unchanged. In addition, the validity period of the certificate must not exceed the remaining lifetime of the Private Key. 4.6.2 Who may request renewal

A CA may request renewal of its certificate. For Subscribers, the Subscriber itself, Machine Operator for the Machine Subscriber (as applicable), and LRAs/RAs may request renewal of Subscriber Certificates. 4.6.3 Processing certificate renewal requests

For an Issuer PKI, the issuing CA system or Issuer Agent shall approve certificate renewal In all cases, the certificate renewal identity-proofing shall be achieved using one of the following processes:

• Initial registration process as described in Section 3.2; or

• Identification & Authentication for Re-key as described in Section 3.3, except the old key can also be used as the new key.

4.6.4 Notification of new certificate issuance to subscriber

See Section 4.3.2 4.6.5 Conduct constituting acceptance of a renewal certificate

See Section 4.4.1 4.6.6 Publication of the renewal certificate by the CA

See Section 4.4.2 4.6.7 Notification of certificate issuance by the CA to other entities

See Section 4.4.3.


4.7 Certificate Re-Key

Re-keying a certificate means that a new certificate is created that has the same characteristics and level as the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key) and a different serial number, and it may be assigned a different validity period, key identifiers, specify a different CRL distribution point and/or be signed with a different signer key. 4.7.1 Circumstance for certificate re-key

A CA may issue a new certificate to the subscriber, when the subscriber has generated a new key pair and is entitled to a certificate. Certificate re-keying is permitted only while the attributes of the subscriber have not changed since the last issuance of the certificate (see Section 3.3.1). BMS CA certificates shall be re-keyed as per Section 5.6. 4.7.2 Who may request certification of a new public key

The end-entity subscriber or a Registration Authority may request re-key of subscriber certificates. Machine Operators shall be responsible for requesting re-keying of the devices under their control. However, a CA or RA may request re-key of their certificate. 4.7.3 Processing certificate re-keying requests

Re-key requests from end-entities will be processed as long as they meet the requirements as described in Section 4.7.1 and in accordance with Section 3.3.1. For cross certificates issued to and by the BMS PKI, the validity period shall not extend beyond the period of the applicable Issuer Agreement or MOA. 4.7.4 Notification of new certificate issuance to subscriber

Notification of a certificate issuance to a subscriber for a re-key shall be similar to that for a new certificate (see Section 4.3.2). 4.7.5 Conduct constituting acceptance of a re-keyed certificate

Conduct constituting acceptance of a re-keyed certificate shall be similar to that for accepting a new certificate (see Section 4.4.1). 4.7.6 Publication of the re-keyed certificate by the CA

This policy does not specify any additional requirements on the publication of certificates by the CA in addition to those described in Sections 2.2 and 2.3.


4.7.7 Notification of certificate issuance by the CA to other entities

This policy does not specify any additional requirements on the notification of certificate issuance by the CA to other entities in addition to those described in Section 4.4.3. 4.8 Certificate modification

Modifying a certificate means creating a new certificate that has the same or a different subject Public Key and a different serial number, and the new certificate differs in one or more other fields related to the subject (e.g., Subject e-mail address in the subject alternative name field), from the old certificate. The old certificate shall not be further re-keyed, renewed, or updated. The old certificate shall be revoked if the Subscriber no longer holds one or more of any authorizations explicitly stated in the old certificate. The RA or other designated agent (as set forth previously) shall verify the new updated information in the certificate. For example, if an individual’s name changes (e.g., due to marriage), then proof of the name change shall be validated by an LRA/RA or TA. The agent shall securely notify the CA and confirm the validation result prior to the issuance of the certificate. 4.8.1 Circumstance for certificate modification

A CA may issue a new certificate to the Subject when some of the Subject information has changed, e.g., name change due to change in marital status, change in subject attributes, etc., and the Subject continues to be entitled to a certificate in accordance with the CP. For external entities with whom BMS PKI cross-certifies a valid and unexpired Agreement must exist between BMS and the external entity, and the term of the Agreement must be beyond the expiry period of the certificate being sought. 4.8.2 Who may request certificate modification

A CA may request issuance of a modified certificate. For Subscribers, the End-User Subscriber, Machine Operator for the Machine Subscriber (as applicable), and LRAs/RAs may request issuance of modified certificates. 4.8.3 Processing certificate modification requests

A certificate modification request identity-proofing shall be achieved as per initial identity-proofing process 4.8.4 Notification of new certificate issuance to subscriber

See Section 4.3.2. 4.8.5 Conduct constituting acceptance of modified certificate

See Section 4.4.1


4.8.6 Publication of the modified certificate by the CA

See Section 4.4.2. 4.8.7 Notification of certificate issuance by the CA to other entities

This policy does not specify any additional requirements on the notification of certificate issuance by the CA to other entities in addition to those described in Section 4.4.3. 4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

An issued BMS certificate shall be revoked when the binding between the subject and the subject’s public key defined within the certificate is no longer considered valid. Examples of circumstances that invalidate the binding are: Identifying information or affiliation components of any names in the certificate becomes

invalid.

Privilege attributes asserted in the subscriber’s certificate are reduced.

The subscriber can be shown to have violated the stipulations of its subscriber agreement.

There is reason to believe the private key has been compromised.

The BMS PMA or CA suspects or determines that revocation of a certificate is in the best interest of the CA.

The subscriber or other authorized party (as defined in the CPS) asks for his/her certificate to be revoked.

The subscriber or other authorized party’s association with BMS has been terminated.

Whenever any of the above circumstances occur, the associated certificate shall be revoked and placed on the CRL. In addition, if it is determined subsequent to issuance of new certificates that a private key used to sign requests for one or more additional certificates may have been compromised at the time the requests for additional certificates were made, all certificates authorized by directly or indirectly chaining back to that compromised key shall be revoked. Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire. Revoked certificates shall appear on at least one CRL. 4.9.2 Who can request Revocation

Within the BMS PKI, a CA may revoke certificates within its domain. The Registration Authority, who initially approved the certificate application, can also request the revocation of a subscriber’s certificate. A subscriber can also request that its own certificate be revoked. An authorized party (e.g., Human Resources, a person in the supervisory chain) can request revocation of a subscriber certificate. Machine operator or a person in the operator’s supervisory chain can request revocation of a device certificate.


4.9.3 Procedure for Revocation Request

Any format that is used to request a revocation shall identify the certificate to be revoked, the reason for revocation, and allow the request to be authenticated (e.g., digitally or manually signed). A CA action is required for revocation. Authentication of certificate revocation requests is important to prevent malicious revocation of certificates by unauthorized parties. The CA or RA shall authenticate the request as well as the authorization of the requester per Section 4.9.2. The steps involved in the process of requesting a certification revocation shall be detailed in the CPS. Subscriber hardware token retrieval procedures have been detailed in the CPS. 4.9.4 Revocation Request grace period

There is no specific time line stipulated for revocation requests under this policy. CAs shall be provided with a revocation request by the Subscriber or the RA as soon as practically possible following the need for revoking a particular certificate. 4.9.5 Time within which CA must process the Revocation Request

CAs shall revoke certificates within twenty-four (24) hours of the receipt of a proper revocation request. 4.9.6 Revocation checking requirement for Relying Parties

Use of revoked certificates could have damaging or catastrophic consequences in certain applications. The matter of how often new revocation data should be obtained is a determination to be made by the Relying Party. If it is temporarily infeasible to obtain revocation information, then the Relying Party must either reject use of the certificate, or make an informed decision to accept the risk, responsibility, and consequences for using a certificate. Such use may occasionally be necessary to meet urgent operational requirements. Whenever Relying parties perform revocation checking, they must check the latest full CRL for each certificate being validated. The validity of the CRL and the signature on the CRL must also be verified. In the event that the Relying party uses an online status checking mechanism, the validity of the response along with the signature on the response must also be verified. In addition the Relying parties should follow the RFC 3280 for revocation checking using CRL and RFC 2560 for using online status checking. 4.9.7 CRL issuance frequency (if applicable)

Since Relying Parties may operate in some environments that cannot accommodate on-line communications, all CAs shall be required to support CRLs. Relying Parties using on-line revocation checking mechanisms may not need to obtain or process CRLs.


CRLs shall be issued periodically, even if there are no changes to be made, to ensure timeliness of information. Certificate status information may be issued more frequently than the issuance frequency described below. The circumstances under which a CA will post early updates shall be spelled out in its CPS. Certificate status information shall be published prior to the next advertised update. i.e before the nextUpdate time in the CRL. For example, in the case of the Root CA, the nextUpdate time in the CRL shall be no later than 3 months after issuance time (i.e. the thisUpdate time).

Type of CA CRL Issuance Frequency

Root CA 90 Days

Subordinate Internal CA 24 hours

Table 3 – CRL Issuance Frequency

When any BMS CA certificate is revoked because of compromise, or key compromise, an emergency CRL must be issued within 24 hours of notification. Additionally external PKIs with whom BMS has cross certified as well as Relying Parties must be notified as per the Issuer Agreement or MOA with that External entity. 4.9.8 Maximum latency for CRLs (if applicable)

The maximum delay between the time that a BMS subscriber’s certificate is revoked by a BMS CA and the time that this revocation information is available to the relying parties shall be no greater than 24 hours. 4.9.9 On-line revocation/status checking availability

Online status checking shall be supported by BMS CAs as described in Section 4.10.1. Relying party client software may optionally support online status checking. The mechanism for providing online revocation status information along with any other pertinent information (e.g. URI) shall be provided in the CPS. However, the latency of certificate status information distributed on-line by the BMS CAs or their delegated status responders must meet or exceed the requirements for CRL issuance stated in Section 4.9.7. 4.9.10 On-line revocation checking requirements

In order for on-line revocation checking to be possible, subscriber certificates needs to be issued with the Authority Info Access (AIA) extension (see Section 7.1.2). OCSP requests and responses shall comply with the profiles specified later in this CP. Relying Party client software capable of performing online revocation checks must be capable of sending valid requests (optionally should be capable of being authenticated i.e. signed requests), and receiving the valid response. The Relying Party should also be capable of verifying the validity and the signature on the response.


4.9.11 Other forms of revocation advertisements available

This policy makes no requirements or prohibitions on other forms of revocation advertisement. A CA may use other methods to publicize the certificates it has revoked. However at a minimum, the alternative method must meet the following requirements: The alternative method must be described in the CA’s approved CPS;

The alternative method must provide authentication and integrity services commensurate with the assurance level of the certificate being verified.

The alternative method must meet or exceed the requirements stated for CRL in Section 4.9.7.

4.9.12 Special requirements related to key compromise

In the event of a CA private key compromise or loss, a CRL shall be published at the earliest feasible time in accordance with the publication time specified in Section 4.9.7. As identified in Section 4.9.7, if applicable, BMS will make reasonable efforts to notify any Relying Parties if BMS discovers, or has reason to believe, that there has been a compromise of the private key of any BMS CA. This policy does not stipulate any special requirements apart from those mentioned in Section 4.9.7 and 5.7. 4.9.13 Circumstances for suspension

Certificates issued under this policy shall not be suspended. 4.9.14 Who can request suspension

Certificates issued under this policy shall not be suspended. 4.9.15 Procedure for suspension request

Certificates issued under this policy shall not be suspended. 4.9.16 Limits on suspension period

Certificates issued under this policy shall not be suspended. 4.10 Certificate Status Services

4.10.1 Operational characteristics

The following table lists the requirements for the capability of performing on-line certificate status checks for certificates issued by the various CAs within the BMS PKI.

Certification Authority CSA Requirement

Root CA Mandatory

Subordinate Internal CAs Optional


Table 4 – On-line status checking requirements

The online certificate status services deployed by the CAs strive to provide 24-hour, 365-day availability, however off hours support is “best effort”. The mechanism for providing online revocation status information (e.g. OCSP, SCVP) along with any other pertinent information (e.g. URI, signed or unsigned request etc.) shall be provided in the CPS. 4.10.2 Service availability

For high level of assurance, the online revocation mechanisms associated with this policy shall be provided with uninterruptible power supplies and backup power generation as described in Section 5.1.3 in the absence of commercial power. 4.10.3 Optional features

This policy makes no requirements or prohibitions on any optional features for the certificate status services. 4.11 End of Subscription

Certificates that have expired prior to or upon end of subscription are not required to be revoked. Subscriber end of subscription details are outlined in the BMS CPS. 4.12 Key Escrow and Recovery

4.12.1 Key escrow and recovery policy and practices

CAs may escrow end-user subscriber keys. However under no circumstance shall signature private keys be escrowed. Key recovery procedures are outlined in the CPS. This policy does not stipulate any additional requirements for key escrow and recovery policies and practices. 4.12.2 Session key encapsulation and recovery policy and practices

This policy prohibits session key encapsulation and recovery.


5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

5.1 Physical Controls

The CA equipment comprises of a set of special purpose devices dedicated to the CA function. Unauthorized use of the CA equipment is forbidden. As such, physical security controls shall be implemented that protect the CA hardware and software from misuse and modification. In addition, the Authority and user cryptographic modules shall be protected against theft, loss and unauthorized use. CSA, RA and LRA equipment shall be protected from unauthorized access while the cryptographic module is installed and activated. The CSA, RA and LRA shall implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated. These security mechanisms shall be commensurate with the level of threat in the CSA, LRA/RA environment. 5.1.1 Site Location and Construction

The location and construction of the facility housing the CA and CSA equipment shall be consistent with facilities used to house high-value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards and intrusion sensors, shall provide robust protection against unauthorized access to the CA and CSA equipment and records. 5.1.2 Physical Access

At a minimum, the physical access controls to CA, CSA shall:

Ensure that no unauthorized access to the hardware is permitted.

Ensure that all removable media and paper containing sensitive plain-text information is stored in secure containers.

Be manually or electronically monitored for unauthorized intrusion at all times.

Ensure an access log is maintained and inspected periodically.

Require two-person physical access control to both the cryptographic module and computer system for equipment supporting high assurance certificate issuance

Details related to securing removable cryptographic modules and access controls employed can be found in Section 5.1.2 of the BMS CPS.

Periodic security checks of the facility shall be completed if the facility is to be left unattended. Verification steps related to the security checks can also be found in Section 5.1.2 of the BMS CPS. A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time, and asserts that all necessary physical protection mechanisms are in place and activated.


5.1.3 Power and Air-conditioning

The facility, which houses the CA equipment, shall be supplied with power and air conditioning sufficient to create a reliable operating environment. In addition, personnel areas within the facility must be supplied with sufficient utilities to satisfy operational, health, and safety needs. Any BMS on-line server (e.g., those hosting directories, OCSP services etc.) shall be provided with uninterrupted power sufficient for a minimum of one (1) week in the absence of commercial power to provide a high level of reliability of the BMS PKI service. The CA equipment shall have backup capability sufficient to automatically lockout input, finish any pending actions, and record the state of the equipment before lack of power or air conditioning causes a shutdown. 5.1.4 Water Exposures

BMS has taken reasonable precautions to minimize the impact of water exposure to BMS PKI systems. 5.1.5 Fire Prevention and Protection

BMS has taken reasonable precautions to prevent and extinguish fires or other damaging exposure to flame or smoke. BMS’s fire prevention and protection measures have been designed to comply with local fire safety regulations. The CA shall have a disaster recovery plan that accounts for damage by fire as well as business continuity capabilities after a disaster as required by Section 5.7.4. 5.1.6 Media Storage

Media shall be stored so as to protect it from accidental damage (water, fire, electromagnetic). Media that contains security audit, archive, or backup information shall be stored in a location separate from the CA equipment. 5.1.7 Waste Disposal

Normal office waste shall be removed or destroyed in accordance with local policy. Sensitive media and documentation that are no longer needed for operations shall be destroyed such that the information is rendered unrecoverable, prior to disposal. For example, sensitive paper documentation may be shredded or burned. In addition, Cryptographic devices shall be physically destroyed or zeroized prior to disposal. 5.1.8 Off-site Backup

Standard BMS Data Center processes will be implemented. .


5.2 Procedural Controls

5.2.1 Trusted roles

A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The functions performed in these roles form the basis of trust for the entire BMS PKI. Two important criteria are taken into consideration in order to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion, and any one individual cannot cause much damage. The primary trusted roles defined this policy are Administrator, Agent, Auditor, Operator, . These four, somewhat abstract, roles are derived from roles identified in the Certificate Issuing Management Components (CIMC) Protection Profile (PP) developed by NIST shall be employed at both CA and RA locations as appropriate. 5.2.1.1 Administrator

The administrator role is responsible for:

Installation, configuration, and maintenance of the CA hardware and software

Establishing and maintaining CA system accounts

Configuring certificate profiles or templates and audit parameters

Generating and backing up CA keys

Individuals assuming the administrator role shall not issue certificates. 5.2.1.2 Agent

The agent’s responsibility is to ensure the following functions occur according to the stipulations of this policy, that is:

Registering new subscribers and requesting the issuance of certificates

Verifying the identity of subscribers and the accuracy of information included in certificates

Approving and executing the issuance of certificates

Requesting, approving, and executing the revocation of certificates.

5.2.1.3 Auditor

The auditor role is responsible for:

Reviewing, maintaining, and archiving audit logs

Performing or overseeing internal compliance audits to ensure that the CA and associated RAs are operating in accordance with its CPS.


5.2.1.4 Operator

The operator role is responsible for the routine operation of the CA equipment and operations such as system backups and recovery, or changing recording media. In addition to the four primary trusted CA roles listed above, the BMS PKI may also have the following six roles, which are: CSA Administrator, CSA Auditor, Registration Authority, Local Registration Authority, Trusted Agent and Machine Operator.

5.2.1.5 CSA Administrator The CSA Administrator role is responsible for: Installation, configuration, and maintenance of the CSA;

Establishing and maintaining CSA system accounts;

Configuring audit parameters, and;

Generating and backing up CSA keys.

Operation of the CSA equipment; and

System backups and recovery.

5.2.1.6 CSA Auditor The CSA Auditor role is responsible for: Reviewing, maintaining, and archiving CSA audit logs; and

Performing or overseeing internal compliance audits to ensure that the CSA is operating in accordance with its CPS.

5.2.1.7 Registration Authority (RA) The RA responsibilities are: Verifying identity, either through personal contact, or via LRA or Trusted Agents;

Entering Subscriber information, and verifying its correctness;

Securely communicating requests to and responses from the CA; and

Receiving and distributing Subscriber certificates.

5.2.1.8 Local Registration Authority (LRA) The LRA responsibilities are: Verifying identity, either through personal contact, or via Trusted Agents;

Entering Subscriber information, and verifying correctness;

Securely communicating requests to and responses from the CA and RA; and

Receiving and distributing Subscriber certificates.


While the LRA performs functions similar to RA, an LRA generally is authorized to serve a limited population of Subscribers, based on logical or geographical organization.

5.2.1.9 Trusted Agent (TA)

A Trusted Agent is a person authorized to act as a representative of an LRA or RA in providing Subscriber identity verification during the registration process. Trusted Agents do not have automated interfaces with CAs; they act on the behalf of the LRA/RA only to verify the identity of the Subscriber.

5.2.1.10 Machine Operator

A Machine Operator represents a Machine Subscriber that is named as Certificate subject. The Machine Operator works with the LRA, RA or TA to register Machine Subscribers. 5.2.2 Number of persons required per task

A single person may be sufficient to perform tasks associated with a role, except for the activation of the root CA certificate signing private key. Generation, backup, and activation of the root CA certificate signing private key shall require actions by at least two individuals. All participants shall serve in a trusted role as defined in Section 5.2.1. Where multiparty control is required, at least one of the participants shall be an Administrator. Multiparty control shall not be achieved using personnel that serve in the Auditor Trusted Role. 5.2.3 Identification and authentication for each role

An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity. 5.2.4 Roles requiring separation of duties

Role separation, when required as set forth in the CPS, may be enforced either by the CA, CSA equipment. BMS PKI personnel shall be specifically designated to the four primary roles defined in Section 5.2.1. 5.3 Personnel Controls

5.3.1 Qualifications, experience, and clearance requirements

All personnel filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity. The requirements governing the qualifications, selection and oversight of individuals who operate, manage, oversee, and audit the CA and CSA shall be set forth in the CPS. 5.3.2 Background check procedures

BMS hiring practices and procedures include background checks. Obtaining a certificate is predicated upon having completed the BMS hiring process. Background check procedures and the minimum requirements can be found in Section 5.3.2 of the BMS CPS.


5.3.3 Training Requirements

All personnel involved in the BMS CA operation shall be appropriately trained. Details of this training can be found in Section 5.3.3 of the BMS CPS. 5.3.4 Retraining Frequency and Requirements

All individuals responsible for PKI roles shall be aware of changes in the BMS CA operation. Any significant change to the CA operation shall have a training (awareness) plan. Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of CA equipment. 5.3.5 Job rotation frequency and sequence

This policy makes no stipulation regarding frequency or sequence of job rotation. Policies that do impose requirements shall provide for continuity and integrity of the PKI service. 5.3.6 Sanctions for unauthorized actions

The CA, CSA, BMS PMA shall take appropriate administrative and disciplinary actions up to and including termination against personnel who have performed actions involving the CSA, CA, repositories or its RAs that are not authorized in this CP, the CPS, or any other published procedures. 5.3.7 Independent contractor requirements

Independent contractors or consultants may be used to fill trusted roles within the BMS PKI. Any such contractor or consultant is held to the same functional and security criteria that apply to a BMS employee in a comparable position. Independent contractors and consultants who have not completed the background check procedures specified in CPS are permitted access to BMS data-center facilities only to the extent they are escorted and directly supervised by authorized BMS PKI personnel. 5.3.8 Documentation supplied to personnel

Documentation sufficient to define duties and procedures for each trusted role shall be provided to the personnel filling that role. 5.4 Audit logging procedures

Audit log files shall be generated for all events relating to the security of the CA, CSA, RA and LRA. Where possible, the security audit logs shall be automatically collected. All security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Section 5.4.3.


5.4.1 Types of Events recorded

All security auditing capabilities of CA, CSA, RA, LRA operating system and PKI CA applications shall be enabled. At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): The type of event

The date and time the event occurred

A success or failure indicator for the event, and

The identity of the entity and/or operator that caused the event

The PKI entities shall record specific auditable events. The auditable events apply to all assurance levels within the BMS PKI. Where these events cannot be electronically logged, the PKI entity shall supplement electronic audit logs with physical logs as necessary. The specific auditable events can be found in Table 12, Section 5.4.1 of the BMS CPS. Additionally, a message from any source requesting certificate management action(s) by the CA is an auditable event; the message must include message date and time, source, destination, and contents. As indicated in Table 12 in Section 5.4.1 of the CPS, BMS does not use 3rd party timestamping, but rather uses internal timestamp servers in conjunction with an external time synchronization and audit service. 5.4.2 Frequency of processing log

Review of the audit log from the CA, CSA, RA and LRA shall be performed as needed. Such reviews involve verifying that the log has not been tampered with and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. A statistically significant portion of the security audit data generated by the CA since the last review shall be examined. This amount shall be described in the CPS. All significant events shall be explained in an audit log summary. Actions taken as a result of these reviews shall be documented. 5.4.3 Retention period for audit log

Security audit data shall be available on-site for at least two months or until reviewed, then off-site as archive records in accordance with Section 5.5.2. The individual who removes audit logs from the PKI component shall comply with the role separation requirements of Section 5.2.4. 5.4.4 Protection of audit log

The security audit data shall not be open for reading or modification by any human, or by any automated process, other than those that perform security audit processing. Component system


configuration and procedures must be implemented together to ensure that only authorized people archive or delete security audit data. Procedures must be implemented to protect archived data from deletion or destruction before the end of the security audit data retention period. Security audit data shall be moved to a safe, secure storage location separate from the PKI component equipment. 5.4.5 Audit log backup procedures

Audit logs and audit summaries shall be backed up at least monthly. A copy of the audit log shall be sent offsite in accordance with the CPS, on a monthly basis. 5.4.6 Audit collection system (internal vs. external)

The audit log collection system may or may not be external to the CA system. Automated audit processes shall be invoked at system or application startup, and cease only at system or application shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, the BMS PMA shall be notified, and a determination shall be made whether to suspend the Component operation (except for revocation processing) until the problem is remedied and the security audit capability can be restored. 5.4.7 Notification to event-causing subject

There is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor prohibited by this policy. 5.4.8 Self Assessments

All PKI operating personnel shall be watchful for attempts to violate the integrity of the certificate management system, including the equipment, physical location, and personnel. Additionally, the CA shall perform routine self-assessments of security controls. The security audit data shall be reviewed by the security auditor for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. Security auditors shall also check for continuity of the security audit data. 5.5 Records Archival

5.5.1 Types of records archived

CA archive records shall be sufficiently detailed to determine the proper operation of the CA and the validity of any certificate (including those revoked or expired) issued by the CA. At a minimum, the following data shall be recorded for archive:

Data To Be Archived CA CSA RA/LRA

Certificate Policy X - -


Data To Be Archived CA CSA RA/LRA

Certification Practice Statement X X X

Contractual obligations X X X

System and equipment configuration X X -

Modifications and updates to system or configuration X X -

Certificate requests X - -

Revocation requests X - -

Subscriber identity authentication data (as per Section 3.2.3) X N/A X

Documentation of receipt and acceptance of certificates X N/A X

Documentation of receipt of Tokens X N/A X

Record of Re-key X X X

All Certificates issued or published X N/A N/A

All CRLs and CRLs issued and/or published X N/A N/A

All Audit Logs (as per Section 5.4) X X X

Other data or applications to verify archive contents X X X

Documentation required by compliance auditors X X X

Table 5 - Data to be Archived

5.5.2 Retention period for archive

Archive records shall be kept, without any loss of data, for the retention periods that have been outlined in the BMS CPS.

If the original media cannot retain the data for the required period, a mechanism to periodically transfer the archived data to new media shall be defined by the archive site. Applications needed to process the archive data shall also be maintained for the archival retention period. 5.5.3 Protection of archive

No unauthorized user shall be permitted to write to, modify, or delete the archive. The contents of the archive shall not be released except (1) in accordance with BMS local policy, or (2) as required by law. Archived information of BMS Transactions shall be made available upon request to any Subscribers involved in the transaction or their legally recognized agents. This information shall be available beyond the end of the validity period of the associated BMS Subscriber’s certificate, up to the retention period indicated in Section 5.5.2. Archive media shall be stored in a safe, secure storage facility separate from the CA, CSA, RA or LRA. 5.5.4 Archive backup procedures

The CPS or a referenced document shall describe how archive records are backed up, and how the archive backups are managed.


5.5.5 Requirements for time-stamping of records

Records are exported (refer to Section 5.5.4) into secure document storage, which are automatically time-stamped upon initial creation and additionally are both time-stamped and versioned for any insert, delete and/or modify operations. 5.5.6 Archive collection system (internal or external)

Archive data may be collected in any expedient manner. 5.5.7 Procedures to obtain and verify archive information

Procedures detailing how to create, verify, package, transmit, and store the archive information, shall be published in the CPS. 5.6 Key Changeover

To minimize risk from compromise of a CA’s signing private key, that key shall be changed as needed. Once changed, only the new key shall be used for certificate signing purposes. The older, but still valid, certificate will be available to verify old signatures until all of the certificates signed using the associated private key have also expired. The old private key shall be used to sign CRLs until all certificates signed with that key have expired. The old private key may also be used to sign OCSP Responder certificate until all certificates signed with that key have expired. The old private key shall be retained and protected just as the new key. The CA’s signing key shall have a validity period as described in Section 6.3.2. 5.7 Compromise and Disaster Recovery

5.7.1 Incident and compromise handling procedures

If BMS detects a potential hacking attempt or other form of compromise to any of its CA, it shall perform an investigation in order to determine the nature and the degree of damage. The scope of potential damage shall be assessed in order to determine if the CA needs to be rebuilt, only some certificates need to be revoked, and/or the CA key needs to be declared compromised. In case of a CA key compromise, a superior CA shall revoke that CA’s certificate, and the revocation information shall be published immediately in the most expedient manner. Subsequently, the CA installation shall be reestablished as described in the CPS. If the CA distributes a trusted certificate for use as a trust anchor, the trusted certificate must be removed from each Relying Party application and the new self-signed certificate must be distributed via secure out-of-band mechanisms. The Issuer CAs shall provide notice to all other CAs as required by the applicable Issuer Agreement or Memorandum of Agreement (MOA).


5.7.2 Computing resources, software, and/or data are corrupted

CAs shall maintain backup copies of hardware, system, databases, and private keys in order to rebuild the CA capability in case of software and/or data corruption. If the CA equipment is damaged or rendered inoperative, but the CA signature keys are not destroyed, CA operation shall be reestablished as quickly as possible, giving priority to the ability to generate certificate revocation status information. If the CA signature keys are destroyed, CA operation shall be reestablished as quickly as possible, giving priority to the generation of a new CA key pair. 5.7.3 Private key compromise procedures

In case of a CA key compromise, the CA shall request revocation of its certificates from all other CAs who have issued it a certificate. The CAs shall immediately publish the revocation information in the most expedient manner. Subsequently, the CA installation shall be re-established as above. In case of the Root CA key compromise, the trusted self-signed certificate shall be removed from each subscriber, and a new one distributed via secure out-of-band mechanisms, which are described in the BMS CPS. The BMS PMA shall be notified and also investigate as to what caused the compromise or loss. Upon notification of an end-entity key compromise, the CA shall revoke the subscriber’s certificate. Certificate revocation procedures shall be carried out as described in Section 4.9. Additionally, if the subscriber certificates are to be generated under the new key pair, they are required to repeat the initial certificate issuance process. (See Section 3.2.3) 5.7.4 Business continuity capabilities after a disaster

In the case of a disaster in which the CA equipment is damaged and inoperative, the CA operations shall be reestablished as quickly as possible, giving priority to the ability to revoke subscriber's certificates and generate and provide certificate status information. If an OCSP Responder associated with a CA is not available for any reason, then the external entities shall be securely and promptly notified in a fashion set forth in the respective Agreements. This will allow Issuers and those contracted with the Issuers to protect their interests as Relying Parties. In the case of a disaster whereby the Root CA installation is physically damaged and all copies of the CA Signing Key are destroyed as a result, the CA shall request that its certificates be revoked, and shall apprise the BMS PMA of actions they intend to take to reestablish the CA and request all new cross-certificates with whom it has Cross-certified, and will follow whatever processes have been set forth in the respective Agreement for that purpose. The CA shall at the earliest feasible time securely advise the BMS PMA and all of its member entities in the event of


a disaster where the CA installation is physically damaged and all copies of the CA signature keys are destroyed. In the case of a disaster whereby the CA (Other than Root CA) installation is physically damaged and all copies of the CA signature key are destroyed as a result, the CA shall request that its certificates be revoked. The CA installation shall then be completely rebuilt, by reestablishing the CA equipment, generating new private and public keys, being recertified, and re-issuing all cross certificates. Finally, all subscriber certificates shall be re-issued. At their own risk, Relying Parties may make a judgment to continue to use certificates signed with the destroyed private key in order to meet urgent operational requirements. 5.8 CA or RA Termination

5.8.1 CA Termination

In the event of termination of the CA operation, CA certificate shall be revoked. Prior to CA termination, the CA shall provide archived data to an archive facility for preservation. Additionally, as soon as possible, the CA shall advise all organizations to which it has issued certificates of the CA’s termination and that the CA trust list should be removed, using an agreed-upon method of communication specified in the CPS. Cross certified PKIs shall be given as much advance notice as circumstances permit, and attempts to provide alternative sources of interoperation will be sought in the event the Root CA is terminated. 5.8.2 RA Termination

Upon termination of the RA, the RA certificate shall be revoked and the RA shall provide archived data to the BMS approved archival facility.


6. TECHNICAL SECURITY CONTROLS

When FIPS 140-1/2 module is used, the module shall be validated and shall be used in FIPS approved mode. 6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

6.1.1.1 CA Key Pair Generation

Medium Assurance CAs shall generate their key pairs in hardware. Cryptographic module requirements for CA signing keys are described in Section 6.2.1. The table in Section 6.1.1.1 of the BMS CPS identifies the levels of FIPS 140-2 validation for the cryptographic modules used within the BMS CA operations. Multiparty control is required for root CA key pair generation, as specified in Section 6.2.2. CA key pair generation must create a verifiable audit trail that the security requirements for procedures were followed. The audit trail must identify and document any failures or anomalies in the key generation process, and any corrective actions taken. The documentation of the procedure must be detailed enough to show that appropriate role separation was used. 6.1.1.2 CSA Key Pair Generation

Key generation shall be performed using a FIPS approved method. Cryptographic module requirements for CSA signing keys for the various BMS CAs are described in Section 6.2.1. 6.1.1.3 Subscriber Key Pair Generation

Subscriber key pair generation may be performed by the Subscriber, CA, RA, or LRA. If the CA or RA generates subscriber key pairs, the requirements for key pair delivery specified in Section 6.1.2 must also be met. Key generation shall be performed using a FIPS approved method. Cryptographic module requirements for subscriber signing keys at different assurance levels are described in Section 6.2.1. 6.1.1.4 RA, LRA Key Pair Generation

Key generation shall be performed using a FIPS approved method. Cryptographic module requirements for RA and LRA signing keys for the various BMS CAs are described in Section 6.2.1. 6.1.2 Private Key delivery to Subscriber

Basic Assurance: Automatic Delivery to the subscriber.


If subscribers generate their own key pairs, then there is no need to deliver private keys, and this section does not apply. Medium Assurance: RA/LRA will be involved for identity vetting and delivery. If a CA or RA/LRA generates keys on behalf of the subscriber, the delivery process outlined in Section 6.1.2 of the BMS CPS contains specific requirements that must be met. 6.1.3 Public key delivery to certificate issuer

Applicant public keys must be delivered for certificate issuance in a way that binds the applicant’s verified identity to the public key. The strength of binding and assurance level shall be commensurate with that of the public key being submitted for certificate issuance. 6.1.4 CA public key delivery to relying parties

CAs shall ensure that its subscribers receive and maintain its trust anchor(s) in a trustworthy fashion. Acceptable methods for trust anchor delivery include but are not limited to:

A trusted role loading the trust anchor onto tokens delivered to subscribers via secure mechanisms;

Distribution of trust anchor through secure out-of-band mechanisms;

Calculation and comparison of trust anchor hash or fingerprint against the hash made available via authenticated out-of-band sources (note that fingerprints or hashes posted in-band along with the certificate are not acceptable as an authentication mechanism); or

Downloading trust anchor from trusted web sites.

6.1.5 Key Sizes

The table below shows the minimum key sizes that shall be used within the BMS PKI.

PKI Entities Key Size

Root CA 2048 bit RSA with SHA-1/SHA256

Subordinate Internal CA 2048 bit RSA with SHA-1/SHA256

Certificate Status Authorities 1024 or 2048 bit RSA with SHA-1/SHA256

Registration Authorities 1024 or 2048 bit RSA with SHA-1/SHA256

Subscribers (at BMS Low Assurance) 1024 or 2048 bit RSA with SHA-1/SHA256

Subscribers (at BMS Medium Assurance) 1024 or 2048 bit RSA with SHA-1/SHA256

Subscribers (at BMS High Assurance) Not Applicable, BMS does not provision high assurance certificates.

Table 6 - Key Sizes

Additionally, all FIPS-approved signature algorithms shall be considered acceptable. SSL , TLS or another protocol providing similar security to accomplish any of the requirements of this CP


shall use SHA-1, SHA-256, triple-DES, or AES (minimum 128 bit key strength) for the symmetric key, and at least 1024 bit RSA or equivalent for the asymmetric keys. 6.1.6 Public Key Parameters generation and Quality Checking

Public key parameters shall always be generated and checked (including primality testing for prime numbers) in accordance with the standard that defines the cryptographic algorithm in which the parameters are to be used. For example, public key parameters prescribed in the Digital Signature Standard (DSS) shall be generated in accordance with FIPS 186-2. Public key parameters for use with the RSA algorithm defined in PKCS-1 shall be generated and checked (including primality testing for prime numbers) in accordance with [PKCS-1], and so on. 6.1.7 Key Usage Purposes (as per X.509 v3 key usage field)

The use of a specific key is constrained by the key usage extension in the X.509 certificate. Subscriber certificates to be used for digital signatures (including authentication) shall assert the digitalSignature bits. Certificates to be used for key transport shall assert the keyEncipherment bit. Public keys that are bound into CA certificates shall be used only for signing certificates and status information (e.g., CRLs). CA certificates whose subject public key is to be used to verify other certificates shall assert the keyCertSign bit. CA certificates whose subject public key is to be used to verify CRLs shall assert the cRLSign bit. If the CA certificate is to be used to verify both certificate and CRLs, both the keyCertSign and cRLSign bits shall be asserted. Public keys that are bound into device certificates may be used for signing, encrypting, or both. Device certificates to be used for digital signatures (including authentication) shall assert the digitalSignature bit. Device certificates to be used for key transport shall assert the keyEncipherment bit. 6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [FIPS 140 1/2]. The BMS PMA may determine that other comparable qualification, certification, or verification standards are sufficient. The BMS PMA shall identify these standards. The table below illustrates the minimum requirements for cryptographic modules for various PKI Entities at different assurance levels; higher levels may be used.

PKI Entities FIPS 140-1/2 Level

Root CA Level 3 (Hardware)

Subordinate Internal CA


o Low Assurance Sub CA Level 1 (Hardware or Software)

o Medium Assurance Sub CA Level 3 (Hardware)

o High Assurance Sub CA Level 3 (Hardware)

Certificate Status Authorities (CSA)

o For Root CA Level 3 (Hardware)

o For Internal Sub CA Level 3 (Hardware)

o Medium Assurance Sub CA Level 3 (Hardware)

Registration Authorities Level 2 (Hardware)

Subscribers (at BMS Basic Assurance) Level 1 (Software) for private key protection

Subscribers (at BMS Medium Assurance) Level 2 (Hardware) or comparable Level 1 (Software) for private key protection

Subscribers (at BMS High Assurance) Level 2 (Hardware)

Table 7 – Cryptographic Module Standards

Signature keys for all parties shall be always generated in the cryptographic module to be used for the purpose of generating digital signatures. 6.2.2 Private Key (n out of m) multi-person control

A single person shall not be permitted to invoke the complete root CA signature process or access any crypto-module containing the complete root CA private signing key. Root CA signature keys may be backed up only under two-person control. Access to root CA signing keys backed up for disaster recovery shall be under at least two-person control. The names of the parties used for two-person control shall be maintained on a list that shall be made available for inspection during compliance audits. 6.2.3 Private Key Escrow

CA private keys shall never be escrowed. Subscriber key management keys may be escrowed to provide for key recovery. Under no circumstances shall any signature key be held in trust by a third party. 6.2.4 Private Key Backup

6.2.4.1 Backup of Root CA Private Signature Key

The root CA private signature keys shall be backed up under the same multi-person control as the original signature key. A copy of the signing key shall be kept at an offsite CA backup location. The copy of the root CA private signature key shall be accountable material, and protected in the same manner as the original. CSA Private Keys may be backed up on a hardware cryptographic module approved for CSA. The backup shall be performed under the same control as the CSA key activation.


6.2.4.2 Backup of Subscriber Private Keys

RA and LRA signing Private Keys shall not be backed up. Backup or copying of subscriber private signature keys is strongly discouraged and shall not be performed. Backup of subscriber private encryption keys may be performed for key recovery purposes. Subscriber software private keys may be backed up or copied as long as they remain under the subscriber’s control and meet all the protection and usage requirements for the subscriber private keys. 6.2.5 Private Key Archival

Subscriber private signatures keys shall not be escrowed or archived. 6.2.6 Private Key transfer into or from a Cryptographic Module

CA Private Keys and all hardware signing keys shall be generated in and remain in the same hardware cryptographic module. The CA and CSA private keys may be backed up in accordance with Section 6.2.4.1. RA, LRA, and subscriber Safe BioPharma MediumHardware signing keys shall not be transferred from the module they are generated in. 6.2.7 Private Key storage on cryptographic module

All BMS CAs, CSAs, RAs and end-user subscribers allow access to the private key with an appropriate FIPS 140-1/2 authentication mechanism as specified in the BMS CPS. 6.2.8 Method of activating Private Key

The subscriber must be authenticated to the cryptographic token before the activation of any private key(s). Acceptable means of authentication include but are not limited to pass-phrases, Personal Identification Numbers (PINs) or biometrics. Activation data generation requirements are specified in Section 6.4. Entry of activation data shall be protected from disclosure (i.e., the data should not be displayed while it is entered). Biometrics, if used, shall provide liveness property to ensure that the user is present. 6.2.9 Method of deactivating Private Key

Cryptographic modules that have been activated shall not be left unattended or otherwise available to unauthorized access. After use, the cryptographic module shall be deactivated, e.g., via a manual logout procedure or automatically after a period of inactivity as defined in the applicable CPS. Hardware cryptographic modules shall be removed and stored in a secure container when not in use.


6.2.10 Method of destroying Private Key

Signing Private Keys shall be destroyed when they are no longer needed, or when the certificates to which they correspond expire or are revoked. This may be achieved by executing a “zeroize” command. Physical destruction of module is not required. CA, CSA, and RA private keys shall be destroyed by individuals in a trusted role. 6.2.11 Cryptographic Module Rating

This policy does not stipulate any requirements in addition to those described in Section 6.2.1. 6.3 Other aspects of Key pair Management

6.3.1 Public key archival

The public key is archived as part of the certificate archival. 6.3.2 Certificate operational periods and key pair usage periods

The following table provides the maximum private and public key validity periods for the different types of CA, CSA and subscribers:

PKI Entity Public Key Usage Period

Private Key Usage Period

Root CA 30 years 30 years (Three Month for CRLs)

BMS Subordinate CAs 15 years 15 years (24 hours for CRLs)

End-Entity (Users, Devices, Web Servers etc.)

Digital Signature 3 years 3 years

Key Management 2 years Unrestricted

Authentication 2 years 2 years

Encryption 3 years 3 years

Device 5 years Unrestricted

End-Entity (CSA,RA, LRA)

For BMS MediumHardware 3 years 3 years

For BMS MediumSoftware 3 years 3 years

Basic Assurance 3 years 3 years

OCSP Responders 3 month Unrestricted

Table 9 - Private and Public Key Usage Periods


6.3.3 Subscriber Private Key Usage Environment

The subscribers shall use their private keys only from the machines that are protected and managed using commercial best practices for computer security as well as network security controls. 6.4 Activation Data

6.4.1 Activation data generation and installation

A pass-phrase, PIN, biometric data, or other mechanisms of equivalent authentication robustness shall be used to protect access to use of a private key. The activation data (pass-phrase or PIN) may be subscriber selected. Activation data shall meet the requirements of FIPS 140-2 Level 2. If the activation data must be transmitted, it shall be via a channel of appropriate protection, and distinct in time and place from the associated cryptographic module. Where a CA uses passwords as activation data for the CA signing key, at a minimum the activation data shall be changed upon CA re-key. 6.4.2 Activation data protection

Data used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical access control mechanisms. Activation data should be either biometric in nature or memorized (not written down). If written down, activation data shall be physically secured or encrypted under a FIPS approved cryptographic algorithm, and shall not be stored with the cryptographic module. Activation data for private keys associated with certificates asserting individual identities shall never be shared. The protection mechanism shall include a facility to temporarily lock the account, or terminate the application, after a predetermined number of failed login attempts as set forth in the CPS. 6.4.3 Other aspects of activation data

This policy makes no stipulation on the life of activation data; however, when possible it should be changed periodically to decrease the likelihood that it can be discovered. 6.5 Computer Security Controls

6.5.1 Specific Computer Security technical requirements

Computer security controls are required to ensure CA/RA/CSA/LRA operations are performed as specified in this policy. The following computer security functions shall be provided by the operating system: Authenticated logins

Discretionary Access Control


Security audit capability

Access control restrictions to CA services based on authenticated identity

Residual information protection

Trusted path for user identification and authentication

Domain separation enforcement

Operating system self-protection.

6.5.2 Computer Security Rating

This policy does not specify any requirements on computer security ratings. 6.6 Lifecycle Technical Controls

6.6.1 System Development Controls

The System Development Controls for the BMS PKI Systems are as follows:

The BMS CA software is commercial-off-the-shelf software.

The BMS CA software has been ordered and installed by “certified engineers” under the direction and control of the BMS PKI Administrator and authorized BMS operation personnel. Hardware and software updates are purchased in the same manner as the original equipment are installed by trusted and trained personnel.

Proper care is taken to prevent malicious software from being loaded onto the BMS equipment. From the time the software is received, it remains under continuous control. For Windows servers, antivirus software will be used to scan all applications and files for malicious code, initially, periodically, and any time a new file is introduced to the system.

6.6.2 Security Management Controls

The configuration of the CA/CSA system as well as any modifications and upgrades shall be documented and controlled. A configuration management methodology shall be used for installation and ongoing maintenance of CA/CSA system. 6.6.3 Lifecycle Security Controls

This policy does not stipulate any requirements on life cycle security controls. 6.7 Network Security Controls

Root CA shall not be connected to any network. Information to be transferred from the Root CA to directories or databases shall be done through “out of band” means (e.g., removable media).


CAs, CSAs, RAs ,LRAs and repositories shall employ appropriate security measures to ensure they are guarded against denial of service and intrusion attacks. Such measures include the use of guards, firewalls and filtering routers. Any network software present shall be necessary to the functioning of the CA or the CSA. The BMS CPS shall define the network protocols and mechanisms required for the operation of the PKI Component. Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the necessary services to the PKI equipment even if those services are enabled for other devices on the network. 6.8 Time-stamping

Time-stamp will be derived from a trusted BMS internal time source, which maintains synchronization with a trusted, external time source once every 12 hours. The time-stamp information is used to establish the time of several components, which are outlined in the BMS CPS.


7. CERTIFICATE, CRL, AND OCSP PROFILES

Certificates issued by a CA under this policy shall conform to the Bristol-Myers Squibb Public Key Infrastructure X.509 certificate, CRL and OCSP profiles as indicated in this Section. 7.1 Certificate Profile

7.1.1 Version Number(s)

BMS CA shall issue X.509 v3 certificates (populate version field with integer ‘2’) 7.1.2 Certificate Extensions

Rules for the inclusion, assignment of value, and processing of extensions are defined in profiles. These profiles are written to prescribe an appropriate amount of control over an infrastructure yet be flexible enough to meet the needs of the various CAs. CA and subscriber certificates may include any extensions as specified by RFC 3280 in a certificate, but must include those extensions required by this CP. Whenever private extensions are used; they shall be interoperable in their intended community of use. 7.1.3 Algorithm object identifiers

Certificates issued under this CP shall use the following OIDs for signatures:

Algorithm OID

sha1WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

Sha256WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Table 10 - Algorithm OIDs

Certificates issued under this CP shall use the following OID to identify the algorithm associated with the subject key:

Algorithm OID

RsaEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}

Table 11 - Subject Key Generation Algorithm

7.1.4 Name forms

The subject and issuer fields of the certificate shall be populated with an X.500 Distinguished Name, with the attribute type as further constrained by RFC 3280. Subject and issuer fields shall include attributes as detailed in the tables below:


7.1.4.1 Root CA Name Form

Usage Attribute Required

Count Content

Required CN 1 Descriptive name for CA, e.g. “CN=BMS Root CA”

Required DC 1 Domain Component, e.g. “dc=BMS”

Required DC 1 Domain Component e.g. “dc=com”

Table 12 - Root CA Name Form

7.1.4.2 Subordinate Internal CA Name Form


Count Content

Required CN 1 Descriptive name for CA, e.g. “CN=BMS Sub CA”



Table 13 – Subordinate Internal CA Name Form

7.1.4.3 End-User Subscriber Name Form


Count Content

Required CN 1 Descriptive name for the subscriber, e.g., “firstname middlename lastname” or ”firstname initial. lastname”.

Required E 1 Email address for the subscriber

Table 13 – End-User Subscriber Name Form

7.1.4.4 Machine Subscriber Name Form


Count Content

Required CN 1 Descriptive name for the device for uniquely identifying it (can possibly include serial number, department code etc).

Table 14 – Machine Subscriber Name Form

7.1.4.5 OCSP Responder Name Form (issued by Root CA)


Count Content

Required CN 1 Descriptive name for the OCSP Responder for uniquely identifying it.



Count Content

Required OU 1 Assurance Level used to specify the class of the Responder certificate e.g. “OU=High Assurance”



Table 15 – OCSP Responder Name Form (issued by Root CA)

7.1.5 Name constraints

BMS CAs may assert name constraints in CA certificates. 7.1.6 Certificate policy object identifier

Certificates issued under this CP shall assert one or more of the following OID in the certificate policies extension, as appropriate:

Object Identifier Value

id-bms-certpolicy-mediumAssurance 2.16.840.1.114331.1.1.3

id-bms-certpolicy-highAssurance 2.16.840.1.114331.1.1.5

id-bms-certpolicy-lowAssurance 2.16.840.1.114331.1.1.6

Id-bms-certpolicy-mediumSoftware 2.16.840.1.114331.1.1.7

Id-bms-certpolicy-mediumHardware 2.16.840.1.114331.1.1.8

Table 16 – Policy Object Identifier

7.1.7 Usage of Policy Constraints extension

The CAs may assert policy constraints in CA certificates. 7.1.8 Policy qualifiers syntax and semantics

Certificates issued under this CP may contain policy qualifiers such as user notice, policy name, and CP and CPS pointers. 7.1.9 Processing semantics for the critical Certificate Policies extension

Processing semantics for the critical certificate policy extension shall conform to X.509 certification path processing rules.


7.1.10 BMS Certificate Formats

7.1.10.1 Root CA Certificate Profile

Field Value

Version V3 (2)

Serial Number Must be unique

Issuer Signature Algorithm

sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11}

Issuer Distinguished Name CN=Bristol-Myers Squibb Internal Root CA, dc=BMS, dc=com

Validity Period 30 years as specified in Section 6.3.2; expressed in UTC

Subject Distinguished Name CN= Bristol-Myers Squibb Internal Root CA, dc=BMS, dc=com

Subject Public Key Information 2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}

Issuer’s Signature


Extension Value Critical

Authority Key Identifier Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of issuing CA (excluding the tag, length, and number of unused bits))

No

Subject Key Identifier Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of subject CA (excluding the tag, length, and number of unused bits))

No

Key Usage Digital Signature, Nonrepudiation,keyCertSign, cRLSign

Yes

Certificate Policies Not present -

Basic Constraints cA=True; path length constraint=None Yes

Policy Constraints Not present -

Authority Information Access Not present -

CRL Distribution Points5 Not present -

Inhibit anyPolicy Not present -

Table 17 – Root CA Certificate Profile

7.1.10.2 Internal Subordinate CA Certificate Profile

Field Value

Version V3 (2)


5 The CRL distribution point extension shall only populate the distributionPoint field. The field shall only contain the URI name form. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL only (i.e., a CRL that does NOT contain the issuer distribution point extension).


Issuer Signature Algorithm sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11}

Issuer Distinguished Name CN= Bristol-Myers Squibb Internal Root CA, dc=BMS, dc=com

Validity Period 15 years as specified in Section 6.3.2; expressed in UTC.

Subject Distinguished Name CN=<Common Name for the CA>, dc=BMS, dc=com

Subject Public Key Information 2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}

Issuer’s Signature sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11}



No

Subject Key Identifier Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of subject CA (excluding the tag, length, and number of unused bits))

No

Key Usage Digital Signature,Certificate Signing, CRL Signing, Off-line CRL Signing

No

Certificate Policies { <BMS CP OID(s)> } One or more certificate policies as described from within section 1.2 may be asserted

No

Basic Constraints cA=True; path length constraint = None (or 1) No

Policy Constraints Not Present No

Authority Information Access HTTP URI to Root CA certificate and HTTP URI to OCSP

No

CRL Distribution Points6 URI to CRL No

Inhibit anyPolicy Not Present No

Table 14 - Subordinate Internal CA Certificate Profile

7.1.10.3 End-User Subscriber Certificate Profile

Field Value

Version V3 (2)




Issuer Distinguished Name CN=<Common Name for the CA>, dc=BMS, dc=com

Validity Period See Section 6.3.2 for applicable validity periods; expressed in UTC.



Subject Distinguished Name CN=<Common Name for the Subscriber>, E=<Email address for the Subscriber>, dc=BMS, dc=com

Subject Public Key Information 1024 or 2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}





No

Subject Key Identifier Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of subject (excluding the tag, length, and number of unused bits))

No

Key Usage No Stipulation No

Enhanced Key Usage No Stipulation No

Subject Alternative Name always present; RFC822 email address (required); others optional

No

Certificate Policies { <BMS CP OID> } multiple certificate policies as described from within section 1.2 may be asserted

No

Authority Information Access HTTP URI to Issuing CA certificate (Optional) HTTP URI to OCSP (Optional)

No

CRL Distribution Points7 URI to CRL. No

Table 15 - End-User Subscriber Authentication Certificate Profile

7.1.10.4 Machine Subscriber Certificate Profile

Field Value

Version V3 (2)




Issuer Distinguished Name CN=<Common Name for the CA>, dc=BMS, dc=com

Validity Period 5 years as specified in Section 6.3.2; expressed in UTC.

Subject Distinguished Name CN=<FQDN for the Device Subscriber>








No

Subject Key Identifier Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of subject (excluding the tag, length, and number of unused bits))

No

Key Usage Key Encipherment, Digital Signature No

Certificate Policies { <BMS CP OID(s)> } One or more certificate policies as described from within section 1.2 may be asserted

No

Authority Information Access No Stipulation No

CRL Distribution Points10 URI to CRL. No

Table 20 - Machine Subscriber Certificate Profile

7.1.10.5 OCSP Responder Certificate Profile

Field Value

Version V3 (2)




Issuer Distinguished Name uniqué X.500 Issuing CA DN as specified in Section 7.1.4

Validity Period No longer than three months from date of issue

Subject Distinguished Name Unique X.500 OCSP Responder (subject) DN as specified in section 7.1.4




No Check OID=Id-pkix-ocsp-nocheck; {1 3 6 1 5 5 7 48 1 5}



No

Subject Key Identifier Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of OCSP Responder (excluding the tag, length, and number of unused bits))

No

Key Usage digital Signature No



Certificate Policies { <BMS CP OID> } Certificate policy OID as described in section 1.2 will be asserted . For external PKI entities any user notices will be put as per the agreements with the External entities.

No

Authority Information Access No Stipulation No

Extended Key Usage Id-kp-OCSPSigning {1 3 6 1 5 5 7 3 9} No

Table 21 - OCSP Responder Certificate Profile

7.2 CRL Profile

7.2.1 Version number(s)

BMS CA shall issue X.509 v2 CRLs (populate version field with integer ‘1’) 7.2.2 CRL and CRL entry extensions

See Section 7.2.3. 7.2.3 BMS CRL Format

Field Value

Version V2 (1)



Issuer Distinguished Name CN=<Common Name for CA>, dc=BMS, dc=com

thisUpdate UTC format if date is 12/31/2049 or earlier, else Generalized Time Format

nextUpdate UTC format if date is 12/31/2049 or earlier, else Generalized Time Format (>= thisUpdate + CRL issuance frequency); (CRL issuance frequency as specified in Section 4.9.7)

Revoked Certificate List 0 or more 2-tuple of certificate serial number and revocation date (in UTC format if date is 12/31/2049 or earlier, else Generalized Time)

Issuer’s Signature sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11}


CRL Number monotonically increasing integer (never repeated) No


No

CRL Entry Extension Value Critical

Invalidity Date Optional No

Reason Code Optional No

Table 22 - Certificate Revocation List (CRL) Profile


7.3 OCSP Profile

7.3.1 Version number(s)

BMS OCSP Responders shall receive OCSP requests and reply with OCSP responses of v1 (populate version field with integer ‘0’). OCSP Requests and Responses will be as specified in RFC 2560. 7.3.2 OCSP extensions

See Section 7.3.3

7.3.3 BMS OCSP Format

7.3.3.1 OCSP Request Profile

Field Value

Version V1 (0)

Requester Name DN of the requestor (optional)

Request List List of certificates as specified in RFC 2560


(Optional) sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11}

Request Extension Value Critical

Nonce Optional No

Request Entry Extension Value Critical

None None -

Table 23 - OCSP Request Profile

7.3.3.2 OCSP Response Profile

Field Value

Version V1 (0)

Response Status As specified in RFC 2560

Response Type Id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1}

Responder ID Octet String (160-bit SHA-1 hash of the value of the BIT STRING Subject Public Key Information of OCSP responder (excluding the tag, length, and number of unused bits))

Produced At Generalized Time Format

List of Responses Each response will contain certificate id; certificate status11, thisUpdate, nextUpdate12,

11 If the certificate is revoked, the OCSP Responder shall provide revocation time and revocation reason from CRL entry and CRL entry extension. 12 The OCSP Responder shall use thisUpdate and nextUpdate from CA CRL.


Responder Signature


Certificates Applicable certificates issued to the OCSP Responder

Response Extension Value Critical

Nonce Value in the nonce field of request (required, if present in request)

No

Response Entry Extension Value Critical

None None -

Table 24 - OCSP Response Profile


8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1 Frequency or Circumstances of Assessment

CAs have the right to require inspections of subordinate CA ,CSA or RA operations to validate that the subordinate is operating in accordance with the security practices and procedures described in the CPS. The CA shall state the reason for any inspection. 8.2 Identity/Qualifications of Assessor

The auditor must demonstrate competence in the field of compliance audits., and must be thoroughly familiar with the BMS CPS The compliance auditor must perform Information System compliance audits as a primary responsibility. The auditor must also demonstrate expertise in security and PKI audit. 8.3 Assessor's relationship to Assessed Entity

The compliance auditor and CA shall have a contractual relationship for the performance of the compliance audit, or be sufficiently organizationally separated from the audited CA to provide an unbiased, independent evaluation. The compliance auditor may not be the author of a CPS subject to audit assessment. The auditor may not have served BMS in maintaining BMS’s CA facility. The BMS PMA shall determine whether a compliance auditor meets this requirement. 8.4 Topics covered by Assessment

The purpose of a compliance audit shall be to verify that a BMS PKI component has in place a system to assure the quality of the services that it provides, and that it complies with all of the requirements of this CP and its CPS. All aspects of the BMS PKI operations related to this CP shall be subject to compliance audit inspections. 8.5 Actions taken as a result of deficiency

When the compliance auditor finds a discrepancy between the requirements of this CP or the stipulations in the CPS and the design, operation, or maintenance of the PKI components, the following actions shall be performed: The compliance auditor shall note the discrepancy;

The compliance auditor shall notify the parties identified in Section 8.6 of the discrepancy;

The party responsible for correcting the discrepancy shall propose a remedy, including expected time for completion.

Any remedy may include permanent or temporary CA cessation, but several factors must be considered in this decision, including the severity of the discrepancy and the risks it imposes, and the disruption to the certificate using community.


8.6 Communication of Results

An Audit Compliance Report shall be provided by the Auditor to the PKI component Authority (CA, CSA or RA) and to the BMS PMA. This report shall identify:

The CP and CPS used in the audit The CP and CPS dates The CP and CPS document version numbers

Results of the compliance audit of BMS’s operations may be released to the public at the discretion of BMS Management. A special compliance audit may be required to confirm the implementation and effectiveness of the remedy.


9. OTHER BUSINESS AND LEGAL MATTERS

Chapter 9 is available in a separate document: Bristol Myers Squibb Co. (BMS) PKI: X.509 Certificate Policy for BMS Internal Root Certificate Authority Certificate Policy, Chapter 9 Other Business and Legal Matters. 10. APPENDIX A: Definitions

Access Ability to make use of any information system (IS) resource. Access Control Process of granting access to IS resources only to authorized users,

programs, processes, or other systems. Activation Data Private data, other than keys, that are required to access cryptographic

modules (i.e., unlock private keys for signing or decryption events). Applicant The subscriber is sometimes also called an “applicant” after applying

to a CA for a certificate, but before the certificate issuance procedure is completed.

Archive Long-term, physically separate storage. Audit Independent review and examination of records and activities to

assess the adequacy of system controls; to ensure compliance with established policies and operational procedures; and to recommend necessary changes in controls, policies, or procedures.

Audit Data Chronological record of system activities to enable the reconstruction and examination of the sequence of events and changes in an event.

Authenticate To confirm the identity of an entity when that identity is presented.

Authentication Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual’s authorization to receive specific categories of information.

Backup Process in which data is copied to a backup medium.

Binding Process of associating two related elements of information.


Biometric A method of verifying an individual’s identity based on measurement of the individual’s physical feature(s) or repeatable action(s) where those features and/or actions are both unique to that individual and measurable. Examples of biometrics include fingerprints, palm prints, retina eye scans, voiceprints, and face recognitions. Repetitive actions alone, such as typing a UserID and password, are not considered biometric in nature. Entering a password or writing a signature on an electric pad with a stylus is not biometric in nature. In order for the signature to be biometric, additional characteristics of the signature (e.g., speed, angle, and pressure) also need to be captured.

Certificate A digital representation of information which at least (1) identifies the CA issuing it, (2) names or identifies its subscriber, (3) contains the subscriber’s public key, (4) identifies its operational period, and (5) is digitally signed by the CA issuing it. As used in this CP, the term “Certificate” refers to certificates that expressly reference the OID of this CP in the “Certificate Policies” field of an X.509 v.3 certificate.

Certification Authority (CA)

An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs.

Certification Authority Revocation List (CARL)

A signed, time-stamped list of serial numbers of CA public key certificates, including cross-certificates that have been revoked.

Certification Authority Software

Key Management and cryptographic software used to manage certificates issued to subscribers.

Certificate Policy (CP) A specialized form of administrative policy tuned to electronic

transactions performed during certificate management. A CP addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery, and administration of digital certificates. Indirectly, a CP can also govern the transactions conducted using a communications system protected by a certificate-based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications.

Certification Practice Statement (CPS)

A statement of the practices that a CA employs in issuing, suspending, revoking, and renewing certificates and providing access to them, in accordance with specific requirements (i.e., requirements specified in the CP or requirements specified in a contract for services).

Certificate Revocation List (CRL)

A list maintained by a CA of the certificates it has issued that are revoked prior to their stated expiration date.


Certificate Status Authority

A trusted entity that provides online verification to a relying party of a subject certificate’s trustworthiness and may also provide additional attribute information for the subject certificate.

Client (application) A system entity, usually a computer process acting on behalf of a

human user, that makes use of a service provided by a server. Compromise Disclosure of information to unauthorized persons, or a violation of

the security policy of a system in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object may have occurred.

Components, PKI Components

Collective name for Certification Authorities, Certificate Status Authorities (CSAs), Registration Authorities (RAs) and Trusted Agents

Confidentiality Assurance that information is not disclosed to unauthorized entities or

processes.

Cross-Certificate A certificate used to establish a trust relationship between two CAs.

Cryptographic Module The set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the cryptographic boundary of the module.

Crypto-period Time span during which each key setting remains in effect.

Data Integrity Assurance that the data are unchanged from creation to reception.

Digital Signature The result of a transformation of a message by means of a cryptographic system using keys such that a relying party can determine (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate and (2) whether the message has been altered since the transformation was made.

Duration A field within a certificate that is composed of two subfields: “date of issue” and “date of next issue.”

Employee Any person employed by BMS. Encryption Certificate A certificate containing a public key that is used to encrypt electronic

messages, files, documents, or data transmissions or to establish or exchange a session key for these same purposes.

End Entity Relying parties and subscribers.


Firewall Gateway that limits access between networks in accordance with local security policy.

Inside Threat An entity with authorized access that has the potential to harm an IS through destruction, disclosure, modification of data, and/or denial of service.

Integrity Protection against unauthorized modification or destruction of information. A state in which information has remained unaltered from the point it was produced by a source, during transmission, storage, and eventual receipt by the destination.

Intellectual Property Useful artistic, technical, and/or industrial information, knowledge, or ideas that convey ownership and control of tangible or virtual usage and/or representation.

Key Escrow The process of having a third party hold onto encryption keys for the purpose of Key Recovery.

Key Exchange The process of exchanging public keys in order to establish secure

communications. Key Generation Material Random numbers, pseudo-random numbers, and cryptographic

parameters used in generating cryptographic keys. Key Pair Two mathematically related keys having the properties that (1) one

key can be used to encrypt a message that can only be decrypted using the other key and (2) even knowing one key, it is computationally infeasible to discover the other key.

Key Recovery A special feature of a key management scheme that allows messages

to be decrypted even if the original key is lost. Local Registration Authority (LRA)

An RA with responsibility for a local community.

Mutual Authentication Authentication when parties at both ends of a communication activity

authenticate each other (see “Authentication”). Naming Authority An organizational entity responsible for assigning DNs and for

assuring that each DN is meaningful and unique within its domain.


Non-repudiation Assurance that the sender is provided with proof of delivery and that the recipient is provided with proof of the sender’s identity so that neither can later deny having processed the data. Technical non-repudiation refers to the assurance a relying party has that if a public key is used to validate a digital signature, that signature had to have been made by the corresponding private signature key. Legal non-repudiation refers to how well possession or control of the private signature key can be established.

Object Identifier (OID) A specialized formatted number that is registered with an

internationally recognized standards organization; the unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class.

Out-of-Band Communication between parties using a means or method that differs

from the current method of communication (e.g., one party uses U.S. Postal Service mail to communicate with another party where current communication is occurring online).

Outside Threat An unauthorized entity from outside the domain perimeter that has the

potential to harm an IS through destruction, disclosure, modification of data, and/or denial of service.

PKI Sponsor Fills the role of a subscriber for nonhuman system components that

are named as public key certificate subjects and is responsible for meeting the obligations of subscribers as defined throughout this CP.

Principal CA The Principal CA is a CA designated by an Issuer to interoperate with

the SBCA. An Issuer may designate multiple Principal CAs to interoperate with the SBCA.

Privacy Restricting access to subscriber or relying party information in

accordance with Federal law and Agency policy. Private Key (1) The key of a signature key pair used to create a digital signature.

(2) The key of an encryption key pair used to decrypt confidential information. In both cases, this key must be kept secret.

Public Key (1) The key of a signature key pair used to validate a digital signature.

(2) The key of an encryption key pair used to encrypt confidential information. In both cases, this key is made publicly available, normally in the form of a digital certificate.


Public Key Infrastructure (PKI)

A set of policies, processes, server platforms, software, and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

Registration Authority (RA)

An entity that is responsible for identification and authentication of certificate subjects but does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of an authorized CA).

Re-key (a certificate) To change the value of a cryptographic key that is being used in a

cryptographic system application; this normally entails issuing a new certificate on the new public key.

Relying Party A person or Agency who has received information that includes a

certificate and a digital signature verifiable with reference to a public key listed in the certificate and is in a position to rely on them.

Renew (a certificate) The act or process of extending the validity of the data binding

asserted by a public key certificate by issuing a new certificate. Repository A database containing information and data relating to certificates as

specified in this CP; may also be referred to as a directory. Revoke a Certificate To prematurely end the operational period of a certificate effective at

a specific date and time. Risk Probable rate of occurrence of a hazard and the degree of its severity. Risk Tolerance The level of risk an entity is willing to assume in order to achieve a

potential desired result. Root CA In a hierarchical PKI, the CA whose public key serves as the most

trusted datum (i.e., the beginning of trust paths) for a security domain. Secret Key A “shared secret” used in symmetric cryptography, wherein users are

authenticated based on a password, PIN, or other information shared between the user and the remote host or server. A single key is shared between two parties: the sender, to encrypt a transmission, and the recipient, to decrypt the transmission, with the shared key being generated with an algorithm agreed to beforehand by the transacting parties.

Server A system entity that provides a service in response to requests from clients.


Signature Certificate A public key certificate that contains a public key intended for verifying digital signatures rather than encrypting data or performing any other cryptographic functions.

Subordinate CA In a hierarchical PKI, a CA whose certificate Signing Key is certified by another CA, and whose activities are constrained by that other CA (see superior CA).

Superior CA In a hierarchical PKI, a CA who has certified the certificate Signing

Key of another CA, and who constrains the activities of that CA. (See subordinate CA).

Subscriber A subscriber is an entity that (1) is the subject named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party. This includes, but is not limited to, an individual or network device.

Threat Any circumstance or event with the potential to cause harm to an

information system in the form of destruction, disclosure, adverse modification of data, and/or denial of service.

Trusted Agent Entity authorized to act as a representative of an Agency in

confirming subscriber identification during the registration process. Trusted Agents do not have automated interfaces with CAs.

Trusted Certificate A certificate that is trusted by the relying party on the basis of secure

and authenticated delivery. The public keys included in trusted certificates are used to start certification paths. Also known as a “trust anchor.”

Trusted Timestamp A digitally signed assertion by a trusted authority that a specific

digital object existed at a particular time. Two-Person Control Continuous surveillance and control of positive control material at all

times by a minimum of two authorized individuals, each capable of detecting incorrect and/or unauthorized procedures with respect to the task being performed and each familiar with established security and safety requirements.

Update (a certificate) The act or process by which data items bound in an existing public

key certificate, especially authorizations granted to the subject, are changed by issuing a new certificate.

Zeroize A method of erasing electronically stored data by altering the contents

of the data storage so as to prevent the recovery of the data.



11. APPENDIX – B: Acronyms

BMS Bristol-Myers Squibb CA Certification Authority CARL Certification Authority Revocation List CP Certificate Policy CPS Certification Practice Statement CSA Certificate Status Authorities CRL Certificate Revocation List DN Distinguished Name DNS Domain Name Service DSA Designated Sponsoring Agent DSS Digital Signature Standard FIPS Federal Information Processing Standard IETF Internet Engineering Task Force ISO International Organization for Standardization MOA Memorandum Of Agreement NIST National Institute of Standards and Technology NSA National Security Agency OCSP Online Certificate Status Protocol OID Object Identifier PIN Personal Identification Number PKCS Public Key Certificate Standard PKI Public Key Infrastructure PKIX Public Key Infrastructure X.509 RA Registration Authority RFC Request For Comments RP Relying Party RSA Rivest-Shamir-Adleman SBCA Safe BioPharma Bridge Certification Authority SHA Secure Hash Algorithm S/MIME Secure Multipurpose Internet Mail Extension SSL Secure Sockets Layer SCVP Simple Certificate Validation Protocol VPN Virtual Private Network


12. APPENDIX – C: REFERENCES

The following documents were used in part to develop this CP: FIPS 140 Security Requirements for Cryptographic Modules, May 2001

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf FIPS 186 Digital Signature Standard, 1994-05-19

http://csrs.nist.gov/fips/fips186.pdf FIPS 112 Password Usage, 1985-05-30

http://csrc.nist.gov/publications/fips/fips112/fip112-1.pdf Federal PKI X.509 Certificate and CRL Extension Profile, April 2002

http://csrc.nist.gov/pki/twg/y2002/papers/twg-02-10.pdf RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile, April 2002 RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification

Practices Framework, November 2003 RFC 2650 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol –

OCSP, June 1999 United States Department of Defense X.509 Certificate Policy, Version 7.0,

December 2002 X.509 Certificate Policy for the U.S. Federal PKI Common Policy

Framework, November 2004

Documents

Bristol-Myers Squibb Company (BMS) PKI: X.509 Certificate ...itsec.bms.com/cp.pdfBristol-Myers Squibb Company (BMS) PKI: X.509 Certificate Policy - 2 - ”