Johnson & Johnson Enterprise Directory and Security …jjedscps.jnj.com/cp.pdfJohnson & Johnson...

Johnson & Johnson Enterprise Directory and Security (JJEDS)

X.509 Certificate Policy (CP)

Effective Date: November 1, 2013

Version 7.0

Approved:

Trina Sayler Director, Identity and Access Management

Chair, Policy Approval Authority

Johnson & Johnson Services, Inc.

REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0

Effective: November 1, 2013

of 145

Table of Contents

1. INTRODUCTION ................................................................................................................ 12

1.1 OVERVIEW ................................................................................................................................... 12 1.1.1 Certificate Policy (CP) .......................................................................................................... 13 1.1.2 Relationship between the CP and the Certification Practice Statement (CPS) ..................... 13 1.1.3 Scope ..................................................................................................................................... 13 1.1.4 Interaction with PKIs External to Johnson & Johnson .......................................................... 13

1.2 IDENTIFICATION .......................................................................................................................... 14 1.3 PKI PARTICIPANTS ..................................................................................................................... 16

1.3.1 Certification Authorities ........................................................................................................ 16 1.3.2 Registration Authority (RA).................................................................................................. 17 1.3.3 Subscribers ............................................................................................................................ 17 1.3.4 Relying Parties ...................................................................................................................... 18 1.3.5 Other Participants .................................................................................................................. 18

1.4 CERTIFICATE USAGE .................................................................................................................. 19 1.4.1 Appropriate Certificate Uses ................................................................................................. 19 1.4.2 Prohibited Certificate Uses.................................................................................................... 21

1.5 POLICY ADMINISTRATION .......................................................................................................... 21 1.5.1 Organization Administering the Document .......................................................................... 21 1.5.2 Contact Person ...................................................................................................................... 22 1.5.3 Person Determining CPS Suitability for the Policy .............................................................. 22 1.5.4 CPS Approval Procedures ..................................................................................................... 22

2. PUBLICATION & REPOSITORY RESPONSIBILITIES ............................................. 23

2.1 REPOSITORIES ............................................................................................................................. 23 2.1.1 Repository Obligations .......................................................................................................... 23

2.2 PUBLICATION OF CERTIFICATION INFORMATION .................................................................... 23 2.2.1 Publication of Certificates and Certificate Status .................................................................. 23 2.2.2 Publication of CA Information .............................................................................................. 23 2.2.3 Interoperability ...................................................................................................................... 23

2.3 FREQUENCY OF PUBLICATION ................................................................................................... 24 2.4 ACCESS CONTROL ON REPOSITORIES ....................................................................................... 24

3. IDENTIFICATION AND AUTHENTICATION .............................................................. 25

3.1 NAMING ....................................................................................................................................... 25 3.1.1 Types of Names ..................................................................................................................... 25 3.1.2 Need for Names to be Meaningful ........................................................................................ 27 3.1.3 Anonymity or Pseudonymity of Subscribers ........................................................................ 27 3.1.4 Rules for Interpreting Various Name Forms ......................................................................... 27 3.1.5 Uniqueness of Names ............................................................................................................ 27 3.1.6 Recognition, Authentication and Role of Trademarks .......................................................... 28

3.2 INITIAL IDENTITY-PROOFING ..................................................................................................... 28 3.2.1 Method to Prove Possession of Private Key ......................................................................... 28 3.2.2 Identity-proofing of Organization Identity ............................................................................ 28 3.2.3 Identity-proofing of Individual Identity ................................................................................ 29 3.2.4 Non-Verified Subscriber Information ................................................................................... 33 3.2.5 Validation of Authority ......................................................................................................... 33



of 145

3.2.6 Criteria for Interoperation ..................................................................................................... 33 3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS ......................................... 34

3.3.1 Identification and Authentication for Routine Re-key .......................................................... 34 3.3.2 Identification and Authentication for Re-key after Revocation ............................................ 35

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUESTS ................................ 35

4. CERTIFICATE LIFE-CYCLE .......................................................................................... 37

4.1 APPLYING FOR A CERTIFICATE .................................................................................................. 37 4.1.1 Submission of Certificate Application .................................................................................. 37 4.1.2 Enrollment Process and Responsibilities .............................................................................. 38

4.2 CERTIFICATE APPLICATION PROCESSING ................................................................................ 38 4.2.1 Performing Identity-proofing Functions ............................................................................... 38 4.2.2 Approval or Rejection of Certificate Applications ................................................................ 38 4.2.3 Time to Process Certificate Applications .............................................................................. 38

4.3 ISSUANCE ..................................................................................................................................... 38 4.3.1 CA Actions during Certificate Issuance ................................................................................ 38 4.3.2 Notification to Subscriber of Certificate Issuance ................................................................ 39

4.4 ACCEPTANCE ............................................................................................................................... 39 4.4.1 Conduct Constituting Certificate Acceptance ....................................................................... 39 4.4.2 Publication of the Certificate by the CA ............................................................................... 39 4.4.3 Notification of Certificate Issuance by the CA to Other Entities .......................................... 39

4.5 KEY PAIR AND CERTIFICATE USAGE ......................................................................................... 39 4.5.1 Subscriber Private Key and Certificate Usage ...................................................................... 39 4.5.2 Relying Party Public Key and Certificate Usage .................................................................. 39

4.6 CERTIFICATE RENEWAL ............................................................................................................. 40 4.6.1 Circumstance for Certificate Renewal .................................................................................. 40 4.6.2 Who May Request Renewal .................................................................................................. 40 4.6.3 Processing Certificate Renewal Requests ............................................................................. 40 4.6.4 Notification of New Certificate Issuance to Subscriber ........................................................ 40 4.6.5 Conduct Constituting Acceptance of a Renewed Certificate ................................................ 40 4.6.6 Publication of the Renewal Certificate by the CA ................................................................ 40 4.6.7 Notification of Certificate Issuance by the CA to Other Entities .......................................... 40

4.7 CERTIFICATE RE-KEY................................................................................................................. 41 4.7.1 Circumstance for Certificate Re-key ..................................................................................... 41 4.7.2 Who May Request Certification of a New Public Key ......................................................... 41 4.7.3 Processing Certificate Re-keying Requests ........................................................................... 41 4.7.4 Notification of New Certificate Issuance to Subscriber ........................................................ 41 4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate ................................................ 41 4.7.6 Publication of the Re-keyed Certificate by the CA ............................................................... 41 4.7.7 Notification of Certificate Issuance by the CA to Other Entities .......................................... 41

4.8 CERTIFICATE MODIFICATION .................................................................................................... 42 4.8.1 Circumstance for Certificate Modification............................................................................ 42 4.8.2 Who May Request Certificate Modification ......................................................................... 42 4.8.3 Processing Certificate Modification Requests ...................................................................... 42 4.8.4 Notification of New Certificate Issuance to Subscriber ........................................................ 42 4.8.5 Conduct Constituting Acceptance of Modified Certificate ................................................... 42 4.8.6 Publication of the Modified Certificate by the CA ............................................................... 42 4.8.7 Notification of Certificate Issuance by the CA to Other Entities .......................................... 43

4.9 REVOCATION & SUSPENSION ..................................................................................................... 43 4.9.1 Circumstance for Revocation of a Certificate ....................................................................... 43



of 145

4.9.2 Who May Request Revocation of a Certificate ..................................................................... 43 4.9.3 Procedure for Revocation Request ........................................................................................ 44 4.9.4 Revocation Request Grace Period ......................................................................................... 44 4.9.5 Time within Which CA Must Process the Revocation Request ............................................ 45 4.9.6 Revocation Checking Requirements for Relying Parties ...................................................... 45 4.9.7 CRL Issuance Frequency ...................................................................................................... 45 4.9.8 Maximum Latency of CRLs .................................................................................................. 45 4.9.9 Online Revocation Checking Availability ............................................................................ 46 4.9.10 Online Revocation Checking Requirements ......................................................................... 46 4.9.11 Other Forms of Revocation Advertisements Available ........................................................ 46 4.9.12 Special Requirements Related to Key Compromise ............................................................. 46 4.9.13 Circumstances for Suspension .............................................................................................. 46 4.9.14 Who May Request Suspension .............................................................................................. 46 4.9.15 Procedure for Suspension Request ........................................................................................ 46 4.9.16 Limits on Suspension Period ................................................................................................. 46

4.10 CERTIFICATE STATUS SERVICES ............................................................................................ 47 4.10.1 Operational Characteristics ................................................................................................... 47 4.10.2 Service Availability ............................................................................................................... 47 4.10.3 Optional Features .................................................................................................................. 47

4.11 END OF SUBSCRIPTION ............................................................................................................ 47 4.12 KEY ESCROW & RECOVERY ................................................................................................... 47

4.12.1 Key Escrow and Recovery Policy and Practices ................................................................... 47 4.12.2 Session Key Encapsulation and Recovery Policy and Practices ........................................... 47

5. FACILITY MANAGEMENT & OPERATIONS CONTROLS ...................................... 48

5.1 PHYSICAL CONTROLS ................................................................................................................. 48 5.1.1 Site Location & Construction ................................................................................................ 48 5.1.2 Physical Access ..................................................................................................................... 48 5.1.3 Power and Air Conditioning ................................................................................................. 49 5.1.4 Water Exposures ................................................................................................................... 49 5.1.5 Fire Prevention & Protection................................................................................................. 49 5.1.6 Media Storage ....................................................................................................................... 49 5.1.7 Waste Disposal ...................................................................................................................... 49 5.1.8 Off-site Backup ..................................................................................................................... 49

5.2 PROCEDURAL CONTROLS ........................................................................................................... 50 5.2.1 Trusted Roles ........................................................................................................................ 50 5.2.2 Number of Persons Required per Task ................................................................................. 53 5.2.3 Identity-proofing for Each Role ............................................................................................ 54 5.2.4 Separation of Roles ............................................................................................................... 54

5.3 PERSONNEL CONTROLS .............................................................................................................. 54 5.3.1 Background, Qualifications, Experience, and Security Clearance Requirements ................. 54 5.3.2 Background Check Procedures ............................................................................................. 55 5.3.3 Training Requirements .......................................................................................................... 55 5.3.4 Retraining Frequency & Requirements ................................................................................. 55 5.3.5 Job Rotation Frequency & Sequence .................................................................................... 55 5.3.6 Sanctions for Unauthorized Actions ..................................................................................... 55 5.3.7 Contracting Personnel Requirements .................................................................................... 55 5.3.8 Documentation Supplied to Personnel .................................................................................. 55

5.4 AUDIT ........................................................................................................................................... 56 5.4.1 Types of Events Recorded..................................................................................................... 56



of 145

5.4.2 Frequency of Processing Data ............................................................................................... 62 5.4.3 Retention Period for Security Audit Data ............................................................................. 63 5.4.4 Protection of Security Audit Data ......................................................................................... 63 5.4.5 Security Audit Data Backup Procedures ............................................................................... 63 5.4.6 Security Audit Collection System (Internal or External) ...................................................... 63 5.4.7 Notification to Event-causing Subject ................................................................................... 64 5.4.8 Vulnerability Assessments .................................................................................................... 64

5.5 ARCHIVE ...................................................................................................................................... 64 5.5.1 Types of Events Archived ..................................................................................................... 64 5.5.2 Retention Period for Archive ................................................................................................ 65 5.5.3 Protection of Archive ............................................................................................................ 65 5.5.4 Archive Backup Procedures .................................................................................................. 65 5.5.5 Requirements for Time-stamping of Records ....................................................................... 65 5.5.6 Archive Collection System (Internal or External) ................................................................. 66 5.5.7 Procedures to Obtain & Verify Archive Information ............................................................ 66

5.6 KEY CHANGEOVER ..................................................................................................................... 66 5.7 COMPROMISE & DISASTER RECOVERY .................................................................................... 66

5.7.1 Incident and Compromise Handling Procedures ................................................................... 66 5.7.2 Computing Resources, Software, and/or Data are Corrupted ............................................... 67 5.7.3 CA Private Key Compromise Recovery Procedures ............................................................. 67 5.7.4 Business Continuity Capabilities after a Disaster ................................................................. 67

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

6. TECHNICAL SECURITY CONTROLS .......................................................................... 69

6.1 KEY PAIR GENERATION & INSTALLATION ............................................................................... 69 6.1.1 Key Pair Generation .............................................................................................................. 69 6.1.2 Private Key Delivery to Subscriber ....................................................................................... 69 6.1.3 Public Key Delivery to Certificate Issuer.............................................................................. 70 6.1.4 CA Public Key Delivery to Relying Parties .......................................................................... 70 6.1.5 Key Sizes ............................................................................................................................... 71 6.1.6 Public-Key Parameters Generation and Quality Checking ................................................... 71 6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field) ..................................................... 71

6.2 PRIVATE KEY PROTECTION & CRYPTO-MODULE ENGINEERING CONTROLS ....................... 72 6.2.1 Cryptographic Module Standards & Controls ....................................................................... 72 6.2.2 CA Private Key Multi-Person Control .................................................................................. 73 6.2.3 Private Key Escrow ............................................................................................................... 73 6.2.4 Private Key Backup ............................................................................................................... 74 6.2.5 Private Key Archival ............................................................................................................. 75 6.2.6 Private Key Transfer into or from a Cryptographic Module ................................................. 75 6.2.7 Private Key Storage on Cryptographic Module .................................................................... 75 6.2.8 Method of Activating Private Keys ....................................................................................... 75 6.2.9 Methods of Deactivating Private Keys .................................................................................. 75 6.2.10 Method of Destroying Private Keys ...................................................................................... 76 6.2.11 Cryptographic Module Rating ............................................................................................... 76

6.3 OTHER ASPECTS OF KEY MANAGEMENT .................................................................................. 76 6.3.1 Public Key Archive ............................................................................................................... 76 6.3.2 Certificate Operational Periods and Key Usage Periods ....................................................... 76 6.3.3 Subscriber Private Key Usage Environment ......................................................................... 76



of 145

6.4 ACTIVATION DATA ...................................................................................................................... 77 6.4.1 Activation Data Generation & Installation ............................................................................ 77 6.4.2 Activation Data Protection .................................................................................................... 77 6.4.3 Other Aspects of Activation Data ......................................................................................... 77

6.5 COMPUTER SECURITY CONTROLS ............................................................................................. 77 6.5.1 Specific Computer Security Technical Requirements ........................................................... 77 6.5.2 Computer Security Rating ..................................................................................................... 78

6.6 LIFE-CYCLE SECURITY CONTROLS ........................................................................................... 78 6.6.1 System Development Controls .............................................................................................. 78 6.6.2 Security Management Controls ............................................................................................. 79 6.6.3 Life-cycle Security Ratings ................................................................................................... 79

6.7 NETWORK SECURITY CONTROLS .............................................................................................. 79 6.8 TIME STAMPING .......................................................................................................................... 80

7. CERTIFICATE, CRL, AND OCSP PROFILES .............................................................. 81

7.1 CERTIFICATE PROFILE ............................................................................................................... 81 7.1.1 Version Numbers .................................................................................................................. 81 7.1.2 Certificate Extensions ........................................................................................................... 81 7.1.3 Algorithm Object Identifiers ................................................................................................. 81 7.1.4 Name Forms .......................................................................................................................... 82 7.1.5 Name Constraints .................................................................................................................. 82 7.1.6 Certificate Policy Object Identifier ....................................................................................... 82 7.1.7 Usage of Policy Constraints Extension ................................................................................. 82 7.1.8 Policy Qualifiers Syntax and Semantics ............................................................................... 82 7.1.9 Processing Semantics for the Critical Certificate Policy Extension ...................................... 82

7.2 CRL PROFILE .............................................................................................................................. 82 7.2.1 Version Numbers .................................................................................................................. 82 7.2.2 CRL & CRL Entry Extensions .............................................................................................. 82

7.3 OCSP PROFILE ............................................................................................................................ 83

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ............................................... 84

8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENTS ............................................................... 84 8.2 IDENTITY/QUALIFICATIONS OF ASSESSOR ................................................................................ 84 8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY .................................................................. 84 8.4 TOPICS COVERED BY ASSESSMENT ........................................................................................... 84 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ........................................................................ 84 8.6 COMMUNICATION OF RESULTS .................................................................................................. 85

9. OTHER BUSINESS & LEGAL MATTERS ..................................................................... 86

9.1 FEES ............................................................................................................................................. 86 9.1.1 Certificate Issuance/Renewal Fee ......................................................................................... 86 9.1.2 Certificate Access Fees ......................................................................................................... 86 9.1.3 Revocation or Status Information Access Fee ...................................................................... 86 9.1.4 Fees for Other Services ......................................................................................................... 86 9.1.5 Refund Policy ........................................................................................................................ 86

9.2 FINANCIAL RESPONSIBILITY ...................................................................................................... 86 9.2.1 Insurance Coverage ............................................................................................................... 87 9.2.2 Other Assets .......................................................................................................................... 87 9.2.3 Insurance/Warranty Coverage for End-entities ..................................................................... 87

9.3 CONFIDENTIALITY OF BUSINESS INFORMATION ...................................................................... 87



of 145

9.3.1 Scope of Confidential Information ........................................................................................ 87 9.3.2 Information Not Within the Scope of Confidential Information ........................................... 87 9.3.3 Responsibility to Protect Confidential Information .............................................................. 87

9.4 PRIVACY OF PERSONAL INFORMATION ..................................................................................... 87 9.4.1 Privacy Plan .......................................................................................................................... 87 9.4.2 Information Treated as Private .............................................................................................. 87 9.4.3 Information Not Deemed Private .......................................................................................... 88 9.4.4 Responsibility to Protect Private Information ....................................................................... 88 9.4.5 Notice and Consent to Use Private Information .................................................................... 88 9.4.6 Disclosure Pursuant to Judicial/Administrative Process ....................................................... 88 9.4.7 Other Information Disclosure Circumstances ....................................................................... 88

9.5 INTELLECTUAL PROPERTY RIGHTS........................................................................................... 88 9.6 REPRESENTATIONS AND WARRANTIES ..................................................................................... 88

9.6.1 CA Representations and Warranties ..................................................................................... 88 9.6.2 RA Representations and Warranties ..................................................................................... 89 9.6.3 Subscriber Representations and Warranties .......................................................................... 89 9.6.4 Relying Party Representations and Warranties ..................................................................... 90 9.6.5 Representations and Warranties of Other Participants .......................................................... 90

9.7 DISCLAIMERS OF WARRANTIES ................................................................................................. 90 9.8 LIMITATIONS OF LIABILITY ....................................................................................................... 90 9.9 INDEMNITIES ............................................................................................................................... 91 9.10 TERM AND TERMINATION ....................................................................................................... 91

9.10.1 Term ...................................................................................................................................... 91 9.10.2 Termination ........................................................................................................................... 91 9.10.3 Effect of Termination and Survival ....................................................................................... 91

9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS ................................. 91 9.12 AMENDMENTS .......................................................................................................................... 91

9.12.1 Procedure for Amendment .................................................................................................... 91 9.12.2 Notification Mechanism and Period ...................................................................................... 92 9.12.3 Circumstances under Which OID Must Be Changed ............................................................ 92

9.13 DISPUTE RESOLUTION PROVISIONS ....................................................................................... 92 9.14 GOVERNING LAW .................................................................................................................... 92 9.15 COMPLIANCE WITH APPLICABLE LAW .................................................................................. 92 9.16 MISCELLANEOUS PROVISIONS ............................................................................................... 92

9.16.1 Entire Agreement .................................................................................................................. 92 9.16.2 Assignment ............................................................................................................................ 92 9.16.3 Severability ........................................................................................................................... 93 9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights) .......................................................... 93 9.16.5 Force Majeure ....................................................................................................................... 93

9.17 OTHER PROVISIONS ................................................................................................................ 93 9.17.1 Fiduciary Relationships ......................................................................................................... 93 9.17.2 Administrative Processes ...................................................................................................... 93 9.17.3 Waivers ................................................................................................................................. 93

10. DIRECTORY INTEROPERABILITY PROFILE ........................................................ 94

10.1 PROTOCOL ............................................................................................................................... 94 10.1.1 Directory ............................................................................................................................... 94 10.1.2 Certificate and CRL Files ...................................................................................................... 94

10.2 AUTHENTICATION ................................................................................................................... 94 10.2.1 Directory ............................................................................................................................... 94



of 145

10.2.2 Files ....................................................................................................................................... 94 10.3 NAMING .................................................................................................................................... 94

10.3.1 Directory ............................................................................................................................... 94 10.3.2 Files ....................................................................................................................................... 95

10.4 OBJECT CLASS ......................................................................................................................... 95 10.4.1 Directory ............................................................................................................................... 95 10.4.2 Files ....................................................................................................................................... 95

10.5 ATTRIBUTES ............................................................................................................................. 95 10.5.1 Directory ............................................................................................................................... 95 10.5.2 Files ....................................................................................................................................... 95

11. PKI OBJECT IDENTIFIERS ARC ................................................................................ 96

12. CERTIFICATES, CRLS, AND OCSP DETAILS ......................................................... 97

12.1 ORCA CERTIFICATE PROFILES ............................................................................................. 97 12.1.1 1024 Bit ORCA Certificate Profile ....................................................................................... 97 12.1.2 2048 Bit and SHA-256 ORCA Certificate Profile ................................................................ 97

12.2 POLCA CERTIFICATE PROFILES ........................................................................................... 98 12.2.1 1024 Bit POLCA Certificate Profile (No Longer Used) ....................................................... 98 12.2.2 2048 Bit POLCA Certificate Profile ..................................................................................... 99 12.2.3 SHA-256 POLCA Certificate Profile .................................................................................... 99

12.3 HUMAN SUBSCRIBER CERTIFICATES ................................................................................... 100 12.3.1 1024 Bit Human Subscriber Signature Certificate (No Longer Used) ................................ 100 12.3.2 2048 Bit Human Subscriber Signature Certificate .............................................................. 100 12.3.3 SHA-256 Human Subscriber Signature Certificate ............................................................. 101 12.3.4 1024 Bit Human Subscriber Encryption Certificate............................................................ 102 12.3.5 2048 Bit Human Subscriber Encryption Certificate............................................................ 103 12.3.6 SHA-256 Human Subscriber Encryption Certificate .......................................................... 104

12.4 ROLE CERTIFICATES ............................................................................................................. 105 12.4.1 1024 Bit Role Signature Certificate (No Longer Used) ...................................................... 105 12.4.2 2048 Bit Role Signature Certificate .................................................................................... 105 12.4.3 SHA-256 Role Signature Certificate ................................................................................... 106 12.4.4 1024 Bit Role Encryption Certificate (No Longer Used) .................................................... 107 12.4.5 2048 Bit Role Encryption Certificate .................................................................................. 107 12.4.6 SHA-256 Role Encryption Certificate ................................................................................ 108

12.5 TOKEN APPLICANT CERTIFICATES ...................................................................................... 109 12.5.1 Current “Token Applicant” Certificate ............................................................................... 109 12.5.2 Deprecated “Token Applicant” Certificate ......................................................................... 110

12.6 NON-PERSON CERTIFICATES ................................................................................................ 111 12.6.1 1024 Bit Device Certificate (No Longer Used)................................................................... 111 12.6.2 2048 Bit Device Certificate ................................................................................................. 111 12.6.3 SHA-256 Device Certificate ............................................................................................... 112 12.6.4 1024 Bit SSL Certificate (No Longer Used) ....................................................................... 113 12.6.5 2048 Bit SSL Certificate ..................................................................................................... 113 12.6.6 SHA-256 SSL Certificate .................................................................................................... 114 12.6.7 1024 Bit Other Server Certificate (No Longer Used) ......................................................... 115 12.6.8 2048 Bit Other Server Certificate ........................................................................................ 115 12.6.9 SHA-256 Other Server Certificate ...................................................................................... 116

12.7 TIME STAMP AUTHORITY (TSA) CERTIFICATES ................................................................ 117 12.7.1 2048 Bit TSA Certificate..................................................................................................... 117



of 145

12.7.2 SHA-256 TSA Certificate ................................................................................................... 118 12.8 CODE SIGNING CERTIFICATES ............................................................................................. 119

12.8.1 1024 Bit Code Signing Certificate (No Longer Used) ........................................................ 119 12.8.2 2048 Bit Code Signing Certificate ...................................................................................... 119 12.8.3 SHA-256 Code Signing Certificate ..................................................................................... 120

12.9 OCSP RESPONDER CERTIFICATES ...................................................................................... 121 12.9.1 1024 Bit OCSP Responder Certificate (No Longer Used) .................................................. 121 12.9.2 2048 Bit OCSP Responder Certificate ................................................................................ 121 12.9.3 SHA-256 OCSP Responder Certificate ............................................................................... 122

12.10 KEY ESCROW AND RECOVERY CERTIFICATES ................................................................... 123 12.10.1 1024 Bit Key Escrow and Recovery Certificate (No Longer Used) ................................... 123 12.10.2 2048 Bit Key Escrow and Recovery Certificate ................................................................. 123 12.10.3 SHA-256 Key Escrow and Recovery Certificate ................................................................ 124

12.11 CROSS CERTIFICATES ........................................................................................................... 125 12.11.1 1024 Bit Cross Certificate (No Longer Used) ..................................................................... 125 12.11.2 2048 Bit Cross Certificate ................................................................................................... 125 12.11.3 SHA-256 Cross Certificate.................................................................................................. 126

12.12 CRLS ...................................................................................................................................... 127 12.12.1 ORCA CRL ......................................................................................................................... 127 12.12.2 POLCA CRL ....................................................................................................................... 128

12.13 OCSP ...................................................................................................................................... 129 12.13.1 OCSP Request ..................................................................................................................... 129 12.13.2 OCSP Response .................................................................................................................. 129

13. BIBLIOGRAPHY ........................................................................................................... 131

14. ACRONYMS AND ABBREVIATIONS ....................................................................... 133

15. GLOSSARY..................................................................................................................... 136

16. ACKNOWLEDGEMENTS ........................................................................................... 145



of 145

REVISION HISTORY

VERSION DATE AUTHOR CHANGE SUMMARY

3.0 April 24,

2008

Ivy Lyons Added revision history to this version and

going forward according to Lifecycle

Management of Controlled

Documentation, SOP-G-ALL-DCN-001, v.

1.0

Added trusted time stamp capability,

including policy object identifier (OID)

and time stamp authority (TSA) certificate

profile.

Update mapping table for SAFE to include

all the appropriate policies.

Updated identity proofing requirements to

align with SAFE CP.

Updated validity periods for certificates to

align with SAFE CP and new JJEDS

practice.

Updated that CP to accommodate the

SHA-256 relief per SAFE CP.

Added 2048 bit and SHA-256 certificate,

CRL, and OCSP profiles.

Added new/current token applicant

certificate profile.

3.1 July 17,

2008

Ivy Lyons Refined Role Separation requirements in

Section 5.2.4

3.2 October 3,

2008

Ivy Lyons Minor updates to meet SAFE CP

4.0 November

4, 2009

Ivy Lyons Minor update to meet SAFE CP (text for user

notice in OCSP Responder certificate)

5.0 June 29,

2011

Ivy Lyons Minor updates to align the CP with operations

6.0 February

13, 2012

JP Vincenti Section 8.1 updated to change frequency of

compliance audit requirement from annual to

once every two years



of 145

7.0 R Stahl Major update to CP.

References to SAFE removed, except in

the Revision History

CAA and CAO role responsibilities

adjusted

Physical Security controls updated

Clarification of responsibilities between

the VP Worldwide Information Security

and the Director, Identity and Access

Management

Re-key after Revocation process clarified

Training requirements clarified..


Effective: February 24, 2012

of 145

1. INTRODUCTION

This Certificate Policy (CP) defines certificate policies for use within the Johnson &

Johnson Family of Companies.

The word “assurance” used in this CP means how strongly or confidently a Relying Party

can be certain of the identity binding between the public key and the individual whose

subject name is cited in the certificate (in the subject field). In addition, it also reflects

how strongly or confidently the Relying Party can be certain that the individual whose

subject name is cited in the certificate is controlling the use of the private key that

corresponds to the public key in the certificate, and how securely the system which was

used to produce the certificate and (if appropriate) deliver the private key to the

Subscriber (described in detail below) performs its task.

The Johnson & Johnson PKI is a hierarchical design, with a single Off-line Root

Certification Authority (called the Johnson & Johnson Root CA, Root CA, or ORCA)

under which at least one subordinate CA (the Johnson & Johnson Principal Online CA or

POLCA) will operate. The POLCA shall issue certificates only to end-users (called

“Subscribers,” who may be humans, roles1, servers, or other devices). Additional CAs,

subordinate to the ORCA, may also be approved for operation by the Policy Approving

Authority as described later in this CP. Whether the holder of the certificate is another

CA is set forth in one or more of the certificate extensions, also described further below.

Subordinate CAs may also function as Registration Authorities (RA), so wherever the

term “RA” is used in this document, it refers to a CA if the CA/RA function is combined.

This CP is consistent with the Internet Engineering Task Force (IETF) Public Key

Infrastructure X.509 (IETF PKIX) RFC 3647, Certificate Policy and Certification

Practices Framework. The usage of terms "shall", "may", "must", and "should" is

consistent with their definitions in IETF RFC 2119.

The terms and provisions of this CP shall be interpreted under and governed by the laws

of the United States. Johnson & Johnson disclaims any liability that may arise from the

use of this CP.

1.1 OVERVIEW

The policies defined within this CP include three different assurance levels (Cert-

Software, Cert-Hardware, and Cert-Hardware-Biometrics) for public key digital

certificates, plus three assurance levels corresponding to each of those levels, but used

strictly for testing or evaluation purposes (Cert-Evaluation-Software, Cert-Evaluation-

Hardware, and Cert-Evaluation-Hardware-Biometrics). Four other certificate policies are

1 Applications may require certificates also. These certificates will be issued under the “roles”

category.



of 145

defined, one for a certificate to be used solely for Subscriber authentication to obtain a

digital signature identity certificate, one to be used for code-signing purposes, and the

other two to be issued solely to servers and devices. Additionally, for each of the

preceding four certificate policies, a corresponding certificate policy is also established,

strictly for testing or evaluation purposes. All of the testing and evaluation certificates

are collectively called “Evaluation-Cert levels.”

Assurance levels are discussed further in Sections 1.2 and 1.4 below.

1.1.1 Certificate Policy (CP)

Each certificate issued under this CP contains a registered certificate policy object

identifier (OID), which may be used by a Relying Party to decide whether the certificate

is trusted for a particular purpose. The party that registers the OID (in this case, Johnson

& Johnson) also publishes the CP, for examination by Relying Parties.

1.1.2 Relationship between the CP and the Certification Practice Statement (CPS)

The Johnson & Johnson CP states what assurance can be placed in a certificate issued by

the ORCA or any of its subordinate CAs. A Johnson & Johnson CPS states how the

Johnson & Johnson ORCA or subordinate CAs establishes that assurance. There will

generally be a single CPS for each CA, reflecting the unique operating environment and

conditions of that CA. Where the operating environment and conditions are shared,

however, a single CPS may cover more than one CA.

1.1.3 Scope

The Johnson & Johnson subordinate CAs may issue certificates to parties other than

Johnson & Johnson employees, such as to partners and customers, for the convenience of

Johnson & Johnson when those parties have a bona fide need to be the subject of a

Johnson & Johnson issued certificate.

1.1.4 Interaction with PKIs External to Johnson & Johnson

It is Johnson & Johnson’s intention to support interoperability between its PKI and those

of its partners and customers, where such interoperability fulfills a business need.

Effecting interoperability between the Johnson & Johnson PKI and the other entity’s PKI

shall be addressed by contract or in some other similar form between Johnson & Johnson

and the entity, which shall cover at a minimum:

PKI policy interoperability, including where necessary policy mapping between

The Johnson & Johnson CP and the other party’s CP, or simple acceptance of the

other party’s certificates for a specific purpose using a CA “trust-list” model;



of 145

PKI technical interoperability, addressing the technical model (root CA cross-

certification, “trust-list,” or some other approach) and whatever controls or

restrictions should be enforced (e.g., in the nameConstraints extensions of cross-

certificates);

Application software requirements, addressing such things as what certification

path validation and certificate revocation status checking;

Directory interoperability, addressing what Johnson & Johnson directory

information needs to be exposed, if any, to the other party, and vice versa.

Additionally, interoperability with entities external to Johnson & Johnson for purposes of

technical testing may be performed when directed by, and in a fashion determined by, the

Johnson & Johnson Enterprise Directory and Security (JJEDS) Policy Approving

Authority (see Section 1.3.1.1). Such testing may employ one or more of the Evaluation-

Cert levels of assurance.

1.2 IDENTIFICATION

There are three levels of assurance for Subscriber certificates, plus three Evaluation-Cert

levels described in this Certificate Policy; these levels are defined in subsequent sections

and are represented by certificate policy OIDs asserted in the certificate policies

extension. Additionally, certificates are provided for authentication to the Johnson &

Johnson network for a Subscriber to obtain a digital signature identity certificate, for

code-signing purposes, and for servers; and for each of those types of certificates, there is

a corresponding test or evaluation certificate. Each certificate type has a unique OID, to

be asserted in certificates issued by the Johnson & Johnson Root and subordinate CAs.

The OIDs are registered under the Johnson & Johnson id-j&j arc {joint-iso-ccitt(2)

country(16) us(840) organization(1) commercial(113666)} as follows:

J&Jcomputersecurityobjectsregister

OBJECT IDENTIFIER

::= {j&jcsor 3} ::=

{2.16.840.1.113666.3}

J&Jpkiobjects OBJECT IDENTIFIER ::= {id-j&jcsor 2} ::=

{2.16.840.1.113666.3.2}

J&Jcertpolicies OBJECT IDENTIFIER ::= {id-j&jpkiobjects 1} ::=

{2.16.840.1.113666.3.2.1}

id-j&jCA-certpcy-certEvaluationsoftware ::= {id-j&jcertpolicies 0} ::=

{2.16.840.1.113666.3.2.1.0}

id-j&jCA-certpcy-certEvaluationhardware ::= {id-j&jcertpolicies 1} ::=

{2.16.840.1.113666.3.2.1.1}



of 145

id-j&jCA-certpcy-

certEvaluationhardwarebiometric

::= {id-j&jcertpolicies 2} ::=

{2.16.840.1.113666.3.2.1.2}

id-j&jCA-certpcy-certSoftware ::= {id-j&jcertpolicies 3} ::=

{2.16.840.1.113666.3.2.1.3}

id-j&jCA-certpcy-certHardware ::= {id-j&jcertpolicies 4} ::=

{2.16.840.1.113666.3.2.1.4}

id-j&jCA-certpcy-certHardwarebiometrics ::= {id-j&jcertpolicies 5} ::=

{2.16.840.1.113666.3.2.1.5}

id-j&jCA-certpcy-certApplicant ::= {id-j&jcertpolicies 6} ::=

{2.16.840.1.113666.3.2.1.6}

id-j&jCA-certpcy-certEvaluationApplicant ::= {id-j&jcertpolicies 7} ::=

{2.16.840.1.113666.3.2.1.7}

id-j&jCA-certpcy-certCodeSigning ::= {id-j&jcertpolicies 8} ::=

{2.16.840.1.113666.3.2.1.8}

id-j&jCA-certpcy-

certEvaluationCodeSigning


{2.16.840.1.113666.3.2.1.9}

id-j&jCA-certpcy-certServerSoftware ::= {id-j&jcertpolicies 10} ::=

{2.16.840.1.113666.3.2.1.10}

id-j&jCA-certpcy-

certEvaluationServerSoftware


{2.16.840.1.113666.3.2.1.11}

id-j&jCA-certpcy-certServerHardware ::= {id-j&jcertpolicies 12} ::=

{2.16.840.1.113666.3.2.1.12}

id-j&jCA-certpcy-

certEvaluationServerHardware


{2.16.840.1.113666.3.2.1.13}

id-j&jCA-certpcy-certEvaluationRole ::= {id-j&jcertpolicies 14} ::=

{2.16.840.1.113666.3.2.1.14}

id-j&jCA-certpcy-certRoleSoftware ::= {id-j&jcertpolicies 15} ::=

{2.16.840.1.113666.3.2.1.15}

id-j&jCA-certpcy-certRoleHardware ::= {id-j&jcertpolicies 16} ::=

{2.16.840.1.113666.3.2.1.16}



of 145

id-j&jCA-certpcy-

certRoleHardwarebiometrics


{2.16.840.1.113666.3.2.1.17}

id-j&jCA-certpcy-

certTimeStampAuthorityHardware


{2.16.840.1.113666.3.2.1.18}

OIDs reserved for future use ::= {id-j&jcertpolicies i} ::=

{2.16.840.1.113666.3.2.1.i} where i =

19, 20, 21, 22, 23, 24, 25, 26, 27, 28,

and 29.

1.3 PKI PARTICIPANTS

The following are roles relevant to the administration and operation of the Johnson &

Johnson PKI.

1.3.1 Certification Authorities

1.3.1.1 Johnson & Johnson Enterprise Directory and Security (JJEDS) Policy Approving Authority (PAA)

The JJEDS PAA (hereinafter the “PAA,”) provides oversight of JJEDS policies and

practices including those related to the Johnson & Johnson PKI. The PAA (or its

designated representative) is responsible for ensuring proper adherence to policies and

practices, including auditing set forth later in this CP.

1.3.1.2 Johnson & Johnson Certification Authority Administrators (CAAs)

Each Johnson & Johnson CA shall have a CAA plus at least one alternate CAA,

responsible for installing, establishing, and operating a Johnson & Johnson CA. The

CAA role is described in Section. 5.2.

1.3.1.3 Johnson & Johnson Certification Authority Officers (CAOs)

The Johnson & Johnson PKI shall have two or more CAOs who are responsible for

controlling physical access to the CA systems and the smart cards required to administer

Hardware Security Modules. The CAO role is described in Section 5.2.

1.3.1.4 Johnson & Johnson Root and Subordinate CAs

The ORCA is authorized by the PAA to create, sign, and issue public key certificates to

Johnson & Johnson subordinate CAs. CAs immediately subordinate to the ORCA shall

only issue certificates to Subscribers, thus limiting the hierarchical depth of the Johnson

& Johnson PKI to two CAs (the ORCA and its first-tier subordinate CAs). The POLCA

is the only CA authorized under this CP to operate immediately subordinate to the

ORCA.



of 145

Subordinate CAs shall include a backup (“Warm Spare”) (as determined by the PAA),

identical to the operational CA. The backup shall only be constituted and operated if the

primary CA is unable to function. This backup is considered part of the primary CA and

it operates under the same identity and public/private key pair as the Primary CA. Once

constituted, the backup for the Primary CA becomes the Primary CA and thus is subject

to all of the requirements pertaining to the Primary CA. The establishment of any CA

subordinate to the ORCA, requires approval of the PAA. Unless otherwise noted, the

term “Johnson & Johnson subordinate CAs” as used in this document shall include the

POLCA.

1.3.2 Registration Authority (RA)

The RA is the entity that collects and verifies each Subscriber’s identity, and information

that is to be entered into his or her public key certificate, in accordance with the

requirements of this CP. For the Johnson & Johnson PKI, most RA functions are

automated through the use of the JJEDS Enterprise Directory, discussed further below.

1.3.3 Subscribers

A Subscriber is the entity whose name appears as the subject in a certificate (in the

subject field), who asserts that it uses its key and certificate in accordance with the

Certificate Policy asserted in the certificate, and who does not itself issue certificates.

CAs are sometimes technically considered “Subscribers” in a PKI. However, 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.

Subscribers may include:

employees of Johnson & Johnson (ED OU=Employees)

employees of Johnson & Johnson partners (i.e., any public or private entity

with whom Johnson & Johnson conducts business other than a customer) (ED

OU=Partners) ;

Johnson & Johnson customers (i.e., entities to whom Johnson & Johnson sells

its products or services, other than members of the public (members of public

are called “consumers”)) (ED OU=Customers);

servers under the physical, administrative, or contractual control of Johnson &

Johnson (ED OU=Servers);

devices under the physical, administrative, or contractual control of Johnson

& Johnson (ED OU=Devices);

functional identities (such as roles) (ED OU=Employees | Partners | Roles); or



of 145

code signing entities (could be human or computer systems) under the

physical, administrative, or contractual control of Johnson & Johnson (ED

OU= Employees | Partners | Roles).

1.3.4 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. A Relying Party is responsible for deciding whether or how to

check the validity of the certificate by checking the appropriate certificate status

information. A Relying Party can use the certificate to verify the integrity of a digitally

signed document or message, to identify the signatory of a document or message, or to

establish confidential communications with the holder of the certificate. A Relying Party

may use information in the certificate (such as certificate policy identifiers) to determine

the suitability of the certificate for a particular use. Relying parties may include

employees of Johnson & Johnson (called “Johnson & Johnson Relying Parties”), Johnson

& Johnson partners, Johnson & Johnson customers, or government agencies, and may

also include hardware such as devices (which includes medical instruments) or servers.

Johnson & Johnson Relying Parties may accept certificates issued by PKIs other than the

Johnson & Johnson PKI. Such acceptance is outside the scope of this CP, and this CP

does not place any controls or restrictions on such acceptance. Rather, this CP focuses on

the nature of certificates issued by the Johnson & Johnson PKI to ensure that any Relying

Party, within or outside Johnson & Johnson, understands how much reliance they may

comfortably place on the Johnson & Johnson PKI issued certificates. Acceptance of non-

Johnson & Johnson certificates by Johnson & Johnson Relying Parties for any purpose is

at their discretion.

1.3.5 Other Participants

1.3.5.1 Johnson & Johnson Certification Authority Auditors

The Johnson & Johnson PKI shall have CA Auditors responsible for reviewing logs and

CA information to ensure compliance with this CP and the CA’s CPS. The CA Auditor

role is described in Section 5.2, and is distinct and separate from the Compliance Auditor

role separately described in Section 8. Auditors shall be appointed by the Director,

Identity and Access Management within the Johnson & Johnson Worldwide Information

Security organization.

1.3.5.2 Johnson & Johnson Key Recovery Authority Officer (KRAO)

The Johnson & Johnson PKI shall have one or more KRAOs responsible for approving

the requests for recovery of decryption private keys in accordance with this CP. KRAO

roles are described in Section 5.2. The KRAOs shall be appointed by the by the Director,

Identity and Access Management within the Johnson & Johnson Worldwide Information

Security organization.



of 145

1.3.5.3 Johnson & Johnson Directory Authority Officer

The Johnson & Johnson Directory Authority Officer is separately authorized to

administer the JJEDS Enterprise Directory which contains information used in the

process of registering Applicants to receive certificates, revoking Subscriber certificates,

and performing decryption key recovery for Subscribers. Thus, even though the Johnson

& Johnson DAO is not a position that is directly a part of the Johnson & Johnson PKI,

elements of its function are covered in this CP where they relate to the Johnson &

Johnson PKI.

Using the JJEDS Enterprise Directory, each Johnson & Johnson CA is responsible for

proper issuance and management of certificates including:

The certificate manufacturing process,

Publication of certificates,

Revocation of certificates, including publication of revocation information,

Re-key of the CA, and

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 and representations of this CP.

1.3.5.4 Certificate Status Authority (CSA)

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. Johnson & Johnson shall make certificate status information

available through an OCSP responder.

1.4 CERTIFICATE USAGE

1.4.1 Appropriate Certificate Uses

The sensitivity of the information protected using certificates issued under this CP is to

be determined by the organizational unit responsible for that information, employing

Johnson & Johnson Information Asset Protection Policies. The ORCA and POLCA may

issue certificates at each level of assurance. Thus, they shall operate at the most stringent

of the conditions set forth in this CP.

The certificate levels of assurance contained in this CP are set forth below, as well as a

brief and non-binding description of their applicability for applications (see glossary for

definition of “application”).



of 145

Assurance Level Applicability Guidance

Evaluation-Cert

levels

These levels are used for interoperability and other testing and convey no

assurance information.

Cert-Software This level is appropriate for use where the security risks to data (e.g.,

likelihood of unauthorized access or modification), or the need to ensure

strong authentication and non-repudiation for transactions, are low to

moderate. This may include transactions having low to moderate monetary

value or risk of fraud, or involving access to Johnson & Johnson business

critical information where the risk of loss of confidentiality is low to

moderate.

Cert-Hardware This level is appropriate for use where the security risks to data, or the need to

ensure strong authentication and non-repudiation for transactions, are

moderate to high. This may include moderate to high value transactions,

access to Johnson & Johnson business critical information where the impact

from loss of confidentiality is moderate to high, or access to private

personally-identifiable information such as that protected under the Health

Insurance and Portability and Accountability Act (HIPAA). Additionally, this

level may be employed for any applications that accept Cert-Software.

Cert-Hardware-

Biometrics

This level is appropriate for use where the security risks to data, or the need to

ensure strong authentication and non-repudiation for transactions, are high to

very high. This may include high to very high value transactions, access to

Johnson & Johnson business critical information where the impact from loss

of confidentiality could have severe impact on Johnson & Johnson, or access

to private personally-identifiable information such as that protected under the

Healthcare Insurance and Portability Accountability Act (HIPAA).

Additionally, this level may be employed for any applications that accept

Cert-Hardware or Cert-Software.

Cert-Applicant This certificate is only used to authenticate a hardware token to the JJEDS PKI

for the purpose of verifying the acceptability of that token.

Cert-Code-Signing This certificate is only used to support validation of digital signatures on

computer code.

Cert-Server-

Software

This certificate is only issued to servers or devices, where the private key is

held in software. The appropriate use of this certificate is as described above

for Cert-Software.

Cert-Server-

Hardware

This certificate is only issued to servers or devices, where the private key is

held on a hardware device. The appropriate use of this certificate is as



of 145

described above for Cert-Hardware.

Cert-TimeStamp-

Authority-Hardware

This certificate is only issued to trusted time stamp authority to issue RFC

3161 compliant time stamps; the time stamp authority private key is held on a

hardware cryptographic module.

1.4.1.1 Factors in determining usage

The Relying Party must determine the level of assurance required for an application, and

select which type(s) of certificate to accept based on the determined assurance level. All

other types of certificates would be rejected if presented to that application. Assurance

level is represented by the certificate policy OID in the certificatePolicies extension.

The Relying Party must additionally determine whether to accept certificates which have

been issued by organizations other than Johnson & Johnson, which have been mapped to

an assurance level defined in this CP by means of certificate policy mapping. If the

Relying Party chooses not to accept such certificates, it can do this by setting the initial-

policy-mapping-inhibit input to the path validation procedure.

(Note: “application” is defined in the glossary, and it means a specific type of transaction;

one software package may afford many different types of “applications,” each requiring a

different level of assurance for a transaction to consummate.) The necessary level of

assurance will be determined by evaluating various risk factors including the value of the

information, the threat environment, and the existing protection of the information

environment. These determinations are made by the Relying Party in consideration of

Johnson & Johnson security requirements, contractual requirements, business trading

partner relationships, and government regulatory requirements.

1.4.2 Prohibited Certificate Uses

Any certificate with a type that does not match the level of assurance required for a

particular application shall be rejected if presented to that application. Assurance level is

represented by the certificate policy OID in the certificatePolicies extension.

1.5 POLICY ADMINISTRATION

1.5.1 Organization Administering the Document

The PAA is responsible for all aspects of this CP.



of 145

1.5.2 Contact Person

Questions regarding this CP shall be directed to the Director, Identity and Access

Management within the Johnson & Johnson Worldwide Information Security

organization, or his or her staff.

1.5.3 Person Determining CPS Suitability for the Policy

The PAA (or its designated representative) is responsible for determining that the CPSs

prepared for the Johnson & Johnson Root and subordinate CAs meet the requirements of

this CP.

The determination of suitability shall be based on an independent compliance analyst’s

results and recommendations. The compliance analyst either shall be a private firm

which is independent from the entity being audited, or it shall be sufficiently

organizationally separated from that entity to provide an unbiased, independent

evaluation. An example of the latter situation is a company internal auditor whose

reporting chain is distinct from that of the organization responsible for the Johnson &

Johnson CA design and/or operation. The PAA shall determine whether a compliance

analyst meets these requirements.

1.5.4 CPS Approval Procedures

The term Certification Practice Statement (CPS) is defined in the Internet X.509 Public

Key Infrastructure Certificate Policy and Certificate Practices Framework as: "A

statement of the practices, which a Certification Authority employs in issuing

certificates." It is a comprehensive description of such details as the precise

implementation of service offerings and detailed procedures of certificate life-cycle

management. It shall be more detailed than this CP. The CPSs for each Johnson &

Johnson CA, which are contained in one or more separate documents, specify how the CP

requirements will be implemented by that CA to ensure compliance with the provisions

of this CP. Each CPS shall be reviewed and approved by the PAA.



of 145

2. PUBLICATION & REPOSITORY RESPONSIBILITIES

2.1 REPOSITORIES

2.1.1 Repository Obligations

The Johnson & Johnson Root and subordinate CAs shall use at a minimum the following

mechanisms for posting information into a repository as required by this CP:

A directory that is accessible through the Lightweight Directory Access Protocol,

Availability of the information as required by the certificate information posting

and retrieval stipulations of this CP, and

Authentication and access control mechanisms when needed to protect repository

information as described in later sections.

2.2 PUBLICATION OF CERTIFICATION INFORMATION

2.2.1 Publication of Certificates and Certificate Status

Using the JJEDS Enterprise Directory, each Johnson & Johnson CA is responsible for

proper issuance and management of certificates including, in particular, publication of

certificates, and publication of revocation information.

2.2.2 Publication of CA Information

The PAA (or its designated representative) shall publish information concerning the

Johnson & Johnson PKI necessary to support its use and operation. In particular,

information on how to obtain the Johnson & Johnson CP and CPS may be obtained from

the contact person identified in Section 1.5.2. The policy qualifier field in Johnson &

Johnson PKI issued certificates may contain a pointer to the location of the CP.

2.2.3 Interoperability

It is Johnson & Johnson’s intention to support interoperability between its PKI and those

of its partners and customers, where such interoperability fulfills a business need. Such

interoperability shall include directory interoperability, addressing what Johnson &

Johnson directory information needs to be exposed, if any, to the other party, and vice

versa.



of 145

2.3 FREQUENCY OF PUBLICATION

Johnson & Johnson PKI certificates shall be published promptly after generation, and

unless otherwise specified. The certificate status information shall be published as

specified in a later section in this CP.

2.4 ACCESS CONTROL ON REPOSITORIES

Any repository information not intended for public dissemination or modification shall be

protected. Only authorized sources such as the CA shall be permitted to place certificates

and certificate status information into the repository.



of 145

3. IDENTIFICATION AND AUTHENTICATION

3.1 NAMING

In order for an Applicant to apply for and receive a certificate issued by the Johnson &

Johnson PKI, the Applicant must have an entry in the JJEDS Enterprise Directory. That

directory contains information supplied only by authoritative sources. For a human

Johnson & Johnson employee, for example, an entry in the directory can only be created

by a Johnson & Johnson human resources organization. The contents of entries can be

changed by that Johnson & Johnson human resources organization, or by other sources

which are authoritative for the content, specifically, the e-mail directory for e-mail

addresses, and the named entity for content such as business address and telephone

number. Any changes require the authoritative source to authenticate itself before the

change is accepted. Thus, the discussion below concerning Applicant identity proofing,

and namespace control, is premised upon the existence and proper operation and control

of the JJEDS identity master enterprise directory.

3.1.1 Types of Names

Johnson & Johnson Root and subordinate CAs shall generate and sign certificates that

contain a Distinguished Name (DN) that shall be expressed using the X.500 naming

convention for certificates issued to CAs, and using a unique worldwide identifier for a

Subscriber (e.g., a “WWID” corresponding to the human Subscriber, or a unique

identifier (such as the hostname under the Domain Name System) corresponding to a

non-human Subscriber), as set forth in the table below. Certificates may assert more than

one name form subject to requirements set forth below intended to ensure name

uniqueness or facilitate certificate usefulness.

Evaluation-Cert

levels

To be established by the PAA (or its designated representative) to

meet testing circumstances

Cert-Software For Subscribers: Distinguished Name in subject field using at a

minimum the Subscriber’s Legal Name and WWID (if a human) or a

unique identifier such as a Domain Name Service identifier (if a non-

human such as a device or server), and optional non-Distinguished

Name in subjectAltName (marked non-critical);

For CAs: Distinguished Name in subject field using X.500 naming

convention, for certificates issued by the ORCA to Johnson &

Johnson subordinate CAs, and for the self-signed root certificate

Specific strings shall be formed as follows:

For human Subscriber getting individual certificate: E=<Email



of 145

Address>, CN=<common name of Subscriber, expressed in English>,

OU=<WWID>, OU= EmployeesPartnersCustomers, O=JNJ,

C=US

For ORCA: CN=JNJ Root Certification Authority, OU=JNJ Public

Key Authorities, O=JNJ, C=US

For Subordinate CAs: CN=<CA Name>, OU=JNJ Public Key

Authorities, O=JNJ, C=US

Cert-Hardware Same as Cert-Software

Cert-Hardware-

Biometrics

Same as Cert-Software

Cert-Role-Software For any Subscriber getting Role encryption certificate: E=<Role

Email Address>, CN=<Role Name, expressed in English>,

OU=Roles, O=JNJ, C=US

For any Subscriber getting Role signature certificate: E=<Role Email

Address>, CN=<Role Name, expressed in English>, OU=<WWID of

Subscriber>, OU=Employees | Partners | Roles, O=JNJ, C=US2

Cert-Role-Hardware Same as Cert-Role-Software

Cert-Role-

Hardware-

Biometrics

Same as Cert-Role-Software

Cert-Applicant CN=Token Certificate Applicant, OU=Roles, O=JNJ, C=US

Cert-Code-Signing E=<Email Address of Code Signing Entity>, CN=<Code Signing

Entity Name, expressed in English>, OU= Roles, O=JNJ, C=US

Cert-Server-

Software

For Web Servers, Other Servers and Domain Controllers:

CN=<Server DNS hostname>, OU= Servers, O=JNJ, C=US

For Devices: CN=<Unique identifier such as serial number>, OU=

Devices, O=JNJ, C=US

Cert-Server- Same as Cert-Server-Software

2 Please note that each human in a role will have a different signature key pair (and hence a

different signature certificate), but may have the same encryption key pair and the same

encryption certificate.



of 145

Hardware

Cert-TimeStamp-

Authority-Hardware

Same as Cert-Server-Software

3.1.2 Need for Names to be Meaningful

The 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 the person, role or object to which they are assigned in a

meaningful way. This is why Subscriber certificates shall contain common names as well

as the Subscriber’s WWID (or for hardware devices such as servers, the DNS identifier).

The common name and WWID for human subscribers shall be the one assigned in the

J&J Enterprise Directory.

3.1.3 Anonymity or Pseudonymity of Subscribers

A CA shall not issue anonymous certificates. A CA may issue pseudonymous certificates

to internal Subscribers to support its operations. However, CA certificates shall not

contain anonymous identities.

Subject DNs in certificates may contain a pseudonym (such as a large number) as long as

name space uniqueness requirements are met.

3.1.4 Rules for Interpreting Various Name Forms

Rules for interpreting name forms are set forth in this CP. If additional rules are needed,

they shall be established by the PAA (or its designated representative). The rules shall be

in accordance with the applicable standards for the name form. For example, rules for

interpreting Internet e-mail addresses shall be in accordance with RFC-822 and rules for

interpreting DNS identifiers shall be in accordance with applicable Internet RFC.

3.1.5 Uniqueness of Names

Name uniqueness across Johnson & Johnson must be enforced, both for the current time

and for all future time. For the current time, this is accomplished by ensuring that

WWIDs are unique – that is, a WWID shall be assigned only to one entity – and by

relying upon the uniqueness of DNS hostnames or other conventions applied to devices

(such as serial numbers). For future time, uniqueness is ensured because WWIDs shall

never be reused.

Code signing entities’ names shall be unique using means to be published by the PAA (or

its designated representative).



of 145

3.1.6 Recognition, Authentication and Role of Trademarks

The PAA shall resolve any trademark-related name collisions or disputes regarding

Johnson & Johnson certificates brought to their attention.

3.2 INITIAL IDENTITY-PROOFING

3.2.1 Method to Prove Possession of Private Key

In all cases where the Subscriber named in a Certificate generates its own keys, the

Subject shall be required to prove possession of the Private Key that corresponds to the

Public Key in the certificate request.

For Signing Keys, the Subscriber may use its Private Key to sign a value (e.g., a

self-signed PKCS-10 request) and provide that value to the CA issuing the Public

Key Certificate. The CA shall then validate the signature using the Subject’s

Public Key.

For encryption keys, this may consist of either: (1) the Subscriber decrypting a

CA-provided text; (2) the CA performing a pair-wise consistency check (if the

CA performs key escrow); or (3) the CA obtaining conformance of pair-wise

consistency check from a trusted source.

The PAA may allow other mechanisms that are at least as secure as those cited here.

In the case where a key is generated by the CA or RA, proof of possession is not

required.

3.2.2 Identity-proofing of Organization Identity

Requests for certificates in the name of an organization (e.g., for a role certificate) shall

include the unique, meaningful organization name. The requester shall be authenticated

through the means designated by the PAA or PAA designee.

When a subordinate CA requests a certificate from the ORCA, the request shall be

presented to two RCAOs and the ORCA CAA in written (paper) form, signed by a

designated representative of the PAA, and provided by the Administrator which the PAA

(or designated representative) has selected to be responsible for the subordinate CA. The

CAA for the subordinate CA shall prove his or her identity to the satisfaction of each

RCAO and the ORCA CAA, who shall then collaborate to activate the ORCA signature

key to issue the certificate.



of 145

3.2.3 Identity-proofing of Individual Identity

3.2.3.1 Identity-proofing of End User Subscribers

An Applicant’s identity information shall be verified and checked, and the Applicant’s

identity information and public key shall be properly bound. Additionally, the process

that was followed for issuance of each certificate shall be recorded. The process

documentation and authentication requirements shall include the following elements

(note that one or more of these steps may occur in a broader registration context, for

example, when the Applicant is in the process of getting some other Johnson & Johnson

credential, and may be available in the form of auditable information produced by the CA

or the JJEDS Enterprise Directory), and shall be concluded prior to or about the same

time as the Applicant receiving the certificate:

The identity of the person performing the identification;

Date of subscriber signature on the Subscriber Agreement;

A unique identifier – the WWID for humans, a common name for roles, or the

DNS identifier for hardware devices such as servers – of the verifier and of the

Applicant;

For any human, a declaration (also called the “Subscriber Agreement”):

attesting to the identity of the Applicant,

acknowledging the Applicant’s responsibility to comply with this CP and

Johnson & Johnson Information Asset Protection Policies (IAPPs)

acknowledging the Applicant’s responsibility to protect PKI tokens, and to

report promptly the loss, theft, or destruction of the tokens , and

signed by the Applicant either using an electronic signature or using a

handwritten signature.

A record of the signed Subscriber Agreement shall be maintained by the issuing CA.

If an Applicant is unable to perform person-to-person registration (e.g., if the Applicant is

a disabled human, or a network device), the Applicant shall be represented by a human

trusted person who has already been issued a digital signature certificate by a Johnson &

Johnson CA. The trusted person shall present information sufficient for registration for

the Applicant whom the trusted person is representing. If the Applicant is a human, the

Applicant shall sign the attestation cited above or shall indicate consent thereto in some

other legally binding fashion. If the Applicant is not human (e.g., a network device), the

party responsible for ensuring compliance with the requirements for private key

protection and use, described in the attestation above, shall be established and legally

bound as the responsible agent of the Applicant prior to certificate issuance. Note that



of 145

this party may or may not be the human trusted person who represented the Applicant for

purposes of getting the certificate.

The table below summarizes the identification requirements for each level of assurance.

Assurance Level Identification Requirements

Evaluation-Cert levels To be established by the PAA to meet specific testing or evaluation

needs

Cert-Software For digital signature certificate: To obtain a digital signature

certificate, an Applicant must have a means of establishing his or her

identity to his or her Supervisor or Sponsor (to the satisfaction of the

Supervisor or the Sponsor), a valid Johnson & Johnson WWID (which

is unique), a one-time Identity Verification Code (IVC) supplied in a

secure fashion by Johnson & Johnson, and a valid Certificate

Authorization Code (CAC) or a Windows password. The IVC and

CAC can only be used one time. The Supervisor (or for non Johnson

& Johnson employees, the Sponsor) may designate a number of

employees or partners from those listed in the Johnson & Johnson

Enterprise Directory to act as delegates. Also the Supervisor’s

Supervisor may serve in the Supervisor’s stead for identity proofing

purposes. Wherever “Supervisor” or “Sponsor” appears below, his or

her delegate, as well as the Supervisor’s Supervisor, may be

substituted. Normal delivery of a one-time IVC to the Applicant’s

Supervisor, or Sponsor (for non Johnson & Johnson employees), as

identified in the enterprise directory, shall be done using one of the

following two methods (listed in order of preference with the first

being the most preferred).

Encrypted e-mail (Note: This method must be used if the

recipient has a Johnson & Johnson-issued encryption

certificate. This method must be used if the recipient does not

have a Johnson & Johnson e-mail address.)

Intra-Johnson & Johnson unencrypted e-mail (Note: This

method shall be used only if the recipient of the IVC does not

have a Johnson & Johnson-issued encryption certificate)

Delivery of the one-time IVC by the Supervisor or Sponsor to the

Applicant shall be done only upon the Applicant providing

satisfactory evidence of identity to the Supervisor or Sponsor, such as

(for a new Johnson & Johnson employee) a picture ID card issued by

Johnson & Johnson or a government agency, or (for a sponsored non-

Johnson & Johnson employee) a picture ID card issued by that



of 145

employee’s company or a government agency. After verifying the

identity of the Applicant through a person to person communication

(face to face, over the phone, through video conferencing, or other

means as long as they are person to person), the Supervisor shall

convey the one-time IVC to the Applicant. The one-time IVC shall

not be delivered via voice mail or unencrypted electronic mail (those

methods are not considered “person to person”); it may be delivered

using encrypted e-mail since use of an encryption certificate ensures

secure transmission to the person named in the certificate.

Normal delivery of a CAC to the Applicant shall be done via

unencrypted e-mail. In the event that a user does not have an email

address, the CAC is not sent and the Applicant must use their

Windows password in place of the CAC.

Alternative mechanisms providing a level of Applicant identity-

proofing and security comparable to that set forth above may be

employed when approved by the PAA or by the Vice President for

Worldwide Information Security (or designee). In such cases, the

mechanism employed shall be documented and approval for its use

granted in writing.

In special circumstances, and with the approval of the Johnson &

Johnson Vice President of Worldwide Information Security,

Applicants may appear in person before a designated Local

Registration Authority (LRA) who may act as a Supervisor’s or

Sponsor’s designee even if not listed as such. The Applicants may

thus retrieve their one-time IVC and CAC or may receive their Token

or Smart Card pre-populated with their certificates directly from the

LRA after properly proving identity.

For other certificates (such as encryption or role): An encryption

certificate may be obtained at the same time that a signature certificate

is obtained, using the same process as set forth above. Alternatively, a

human Applicant may apply for a certificate other than a signature

certificate by presenting a valid Johnson & Johnson signature

certificate and proving possession of the private key. If the Applicant

is a server or device, the Sponsor of that server or device must present

a valid Johnson & Johnson signature certificate and prove possession

of the private key (see 3.2.3.2 below).

Cert-Hardware Same as Cert-Software and possession of a valid J&J token

Cert-Hardware- Same as Cert-Software



of 145

Biometrics

Cert-Applicant Placed on hardware tokens automatically – no identity proofing

required.

Cert-Code-Signing Same as Cert-Software plus Applicant must be approved by the PAA

to receive.

Cert-Server-Software Same as Cert-Software

Cert-Server-Hardware Same as Cert-Software

Cert-TimeStamp-

Authority-Hardware

Same as the process used to identify-proof a CA representative

Certificates asserting an OID of Cert-Software, Cert-Hardware, Cert-Hardware-

Biometrics, Cert-Server-Software or Cert-Server-Hardware may occasionally be issued to

fictitious identities for testing purposes. This is separate from the issuance of certificates

containing an OID under the Evaluation-Cert levels of assurance. Where a certificate is

issued containing a fictitious identity, the following requirements shall apply:

Any identifier employed in the certificate shall not correspond to an actual person

or any actual entity in the JJEDS Enterprise Directory

The subject name employed in the certificate shall clearly indicate that the

Subscriber is fictitious (e.g., “Test Subscriber 1023” would be an acceptable

subject name in such a certificate)

The certificate shall be issued with a validity period that is the minimum required

for the testing to be consummated

The certificate shall be revoked immediately upon the testing being completed

3.2.3.2 Identity-proofing of Machine Subscribers

Computing and communications components (routers, firewalls, servers, etc.) may be

named as certificate subjects. In such cases, the component shall have a human Sponsor

(called a “trusted person” in Section 3.2.3.1 above). The Sponsor shall be responsible for

providing the following registration information:

Equipment identification

Equipment public keys



of 145

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

certificate)

Contact information for communication with the Sponsor when required

The registration information shall be verified to an assurance level commensurate with

the certificate assurance level being requested. Acceptable methods for performing this

authentication and integrity checking include, but are not limited to:

Verification of a digitally signed message sent from the Sponsor (using

certificates of equivalent or greater assurance than that being requested).

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 Certificates. It is the

responsibility of the RA to verify that Subscriber information is correct and accurate. For

the Johnson & Johnson PKI, this shall be done through use of the JJEDS Enterprise

Directory, the contents of which shall be considered authoritative for certificate issuance.

3.2.5 Validation of Authority

Subscriber attributes asserted, if any, in the certificate shall be obtained from the JJEDS

Enterprise Directory. The contents of JJEDS Enterprise Directory are considered

authoritative.

3.2.6 Criteria for Interoperation

Approval by the PAA (or its authorized representative) for another party to cross certify

with a Johnson & Johnson CA shall be based on successful mapping of the other party’s

CP against this CP.

Effecting interoperability between the Johnson & Johnson PKI and the other entity’s PKI

shall be addressed by contract or in some other similar form between Johnson & Johnson

and the entity, which shall cover at a minimum:

PKI policy interoperability, including where necessary policy mapping between

the Johnson & Johnson CP and the other party’s CP, or simple acceptance of the

other party’s certificates for a specific purpose using a CA “trust-list” model;

PKI technical interoperability, addressing the technical model (root CA cross-

certification, “trust-list,” or some other approach), whatever controls or

restrictions should be enforced (e.g., in the nameConstraints extensions of cross-



of 145

certificates) and compatibility of certificate and CRL profiles between the two

PKIs;

Application software requirements, addressing such things as what certification

path validation and certificate revocation status checking;

Directory interoperability, addressing what Johnson & Johnson directory

information needs to be exposed, if any, to the other party, and vice versa.

3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS

3.3.1 Identification and Authentication for Routine Re-key

The PCA shall perform re-key and identification and authentication for re-key per the

requirements of the cross certified domain.

In the event that a subordinate CA re-keys, authentication shall be done either by:

(a) Performing the initial registration identification process defined in Section

3.2.2, or

(b) Using the currently valid certificate issued to the Johnson & Johnson

subordinate CA if it has been less than nine years since the subordinate CA

was identified as required in Section 3.2.2.

Subscribers of Johnson & Johnson subordinate CAs shall identify and authenticate

themselves for the purpose of re-keying as required in the table below.

Assurance

Level

Routine Re-key Identification and Authentication Requirements for

Subscriber Signature and Encryption Certificates

Evaluation-Cert

levels

To be determined by the PAA

Cert-Software Identification and authentication may be done through the use of current

signature key, except that identity shall be authenticated through initial

registration process at least once every nine years from the time of initial

registration

Cert-Hardware Same as Cert-Software

Cert-Hardware-

Biometrics


Cert-Applicant Not applicable – no re-keying done by Subscriber



of 145

Assurance

Level

Routine Re-key Identification and Authentication Requirements for

Subscriber Signature and Encryption Certificates

Cert-Code-

Signing


Cert-Server-

Software


Cert-Server-

Hardware


Cert-

TimeStamp-

Authority-

Hardware

Same as subordinate CA

3.3.2 Identification and Authentication for Re-key after Revocation

3.3.2.1 Signature Certificate

If the Subscriber, after authenticating using an existing JJEDS credential, revokes his or

her own signature certificate because his/her entry in the Enterprise Directory has

changed or the certificate is about to expired, then the signature certificate is re-issued as

part of the self-revocation process. Otherwise, the subscriber is required to re-

authenticate as set forth in Section 3.2 above.

3.3.2.2 Encryption Certificate

The Subscriber either shall use his or her current, valid digital signature private key to

authenticate to the CA for the purpose of obtaining a new encryption certificate, or shall

obtain an encryption certificate as part of the same process used to get a signature

certificate (that is, contemporaneously with getting the signature certificate).

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUESTS

Revocation requests must be authenticated. Requests to revoke a certificate shall be

authenticated and processed in accordance with Section 4.9 below.



of 145



of 145

4. CERTIFICATE LIFE-CYCLE

4.1 APPLYING FOR A CERTIFICATE

A request for a certificate from a Johnson & Johnson Root or subordinate CA to an entity

within Johnson & Johnson shall be performed as set forth in Section 3.2.3 above.

An entity requesting for a cross-certificate from a Johnson & Johnson CA shall complete

a cross certificate application process as specified by the PAA, which shall include

submitting a copy of the entity’s CP and CPS. The PAA shall review the CP and CPS

and make a determination whether to approve the application. If approved, the PAA shall

enter into an agreement with the entity and shall instruct the CA operator to issue a cross

certificate.

Once the PAA approves issuance of a cross-certificate, the Johnson & Johnson CAA and

CAO and the entity shall perform the following steps:

Establish and record CA information per Section 3.2.3;

Generate a Public/Private Key pair for each certificate when required;

Establish that the Public Key forms a functioning key pair with the Private Key

held by the CA (per Section 3.2.1); and

Provide points of contact for verification of any agent roles or authorizations

requested.

These steps may be performed in any order that is convenient that meets the requirements

of this CP; but all must be completed prior to certificate issuance.

All communications among CA and Subscribers supporting the certificate application and

issuance process shall be authenticated and protected from modification using

mechanisms commensurate with the requirements of the data to be protected by the

certificates being issued (i.e., communications supporting the issuance of Cert-Hardware

certificates shall be protected using Cert-Hardware certificates, or some other mechanism

of equal or greater strength). Any electronic transmission of shared secrets shall be

protected (e.g., encrypted) using means commensurate with the requirements of the data

to be protected by the certificates being issued.

4.1.1 Submission of Certificate Application

A Subscriber shall be required to sign, using an electronic (including digital) signature or

handwritten signature, a document containing the requirements the Subscriber shall meet

respecting protection of the private key and use of the certificate before being issued the

certificate. This is called a Subscriber Agreement and is described further in Section

3.2.3. The subscriber shall apply for a certificate after getting his/her identity verified and

after obtaining the IVC upon identity verification (normally by the subscriber's



of 145

supervisor) and CAC from the JJEDS PKI. The subscriber shall enter their WWID, their

IVC, and their CAC during the certificate application process.

4.1.2 Enrollment Process and Responsibilities

Supervisor shall be responsible for validating the subscriber identity, for obtaining the

subscriber IVC, and for providing the IVC to the subscriber. Subscriber shall be

responsible for obtaining the CAC and carrying out the enrollment process. The RA shall

be responsible for verifying the IVC and CAC provided by the subscriber, and for

obtaining the information for the certificate from the JJEDS PKI Directory. Section 3.2.3

above provides further details.

4.2 CERTIFICATE APPLICATION PROCESSING

4.2.1 Performing Identity-proofing Functions

Subscriber identity is generally verified by the supervisor. See Sections 3.2.2 and 3.2.3

for additional details.

4.2.2 Approval or Rejection of Certificate Applications

The PAA or CA shall reject certificate applications if the subscriber does not provide

correct IVC and CAC. The PAA may additionally reject certificate applications for any

other reason deemed appropriate.

4.2.3 Time to Process Certificate Applications

The CA shall process the certificate application and generate the certificate as soon as

practicable, normally immediately upon the receipt of the request. The only other higher

priority activities for the CA shall be processing of revocation requests and generation of

the CRL.

4.3 ISSUANCE

4.3.1 CA Actions during Certificate Issuance

A CA shall verify the source of a certificate request prior to issuance of the certificate.

Upon receiving a request for a certificate, the process set forth in this CP shall be

followed.

Certificates once created shall be checked to ensure that all fields and extensions are

properly populated. This may be done through software which scans the fields and

extensions looking for any evidence that a certificate was improperly manufactured.



of 145

4.3.2 Notification to Subscriber of Certificate Issuance

Subscriber shall be notified of certificate creation.

4.4 ACCEPTANCE

4.4.1 Conduct Constituting Certificate Acceptance

Subscriber certification application and certificate download shall constitute subscriber

acceptance of the certificate. Failure to object to the certificate or its contents shall

constitute acceptance of the certificate.

4.4.2 Publication of the Certificate by the CA

The CA certificates shall be posted to the JJEDS PKI Directory. Subscriber certificates

may be posted to the JJEDS PKI Directory.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

The PAA shall be notified upon issuance of all CA certificates.

4.5 KEY PAIR AND CERTIFICATE USAGE

4.5.1 Subscriber Private Key and Certificate Usage

Subscribers shall protect their Private Keys from access by any other party. Subscribers

shall use their private keys for only the official Johnson & Johnson business.

4.5.2 Relying Party Public Key and Certificate Usage

Certificates may specify restrictions on use through certificate extensions. Certificates

shall conform to the profiles provided in this CP. A CA shall issue information

specifying the current status of all unexpired certificates. Relying Parties shall first

process certificates and revocation information in accordance with X.509 standard for

certification path validation. Relying parties shall then use the information derived from

end certificate in the certification path for verifying digital signatures, for authentication,

or for encryption. While using the public key, the relying party shall ensure the

following as a minimum:

Use the algorithm identifier and public key from the end certificate;

Use the public key parameters (if applicable) from the path validation engine;

Verify that the public key belongs to the appropriate subscriber of interest to the

relying party as stipulated in the subject DN and subject alternative fields of the

end certificate;



of 145

If key usage extension is present in the end certificate, use the public key for the

cryptographic operations permitted per this extension; and

If extended key usage extension is present in the end certificate, use the public

key for the applications and usage permitted per this extension.

4.6 CERTIFICATE RENEWAL

Renewing a certificate means creating a new certificate with the same name, key, and

other information as the old one, but a new, extended validity period and a new serial

number.

4.6.1 Circumstance for Certificate Renewal

Certificates normally will not be renewed, rather, before a certificate expires, a new one

will be issued with a new key pair; however, the possibility to perform certificate renewal

is preserved in this CP since renewal may be an efficient and appropriate way to proceed

when the issuing CA re-keys. A certificate may be renewed only if the associated private

key has not been compromised, and the Subscriber name and attributes are unchanged.

The certificate validity period must not exceed the associated private key lifetime.

4.6.2 Who May Request Renewal

The certificate subject may request renewal of a certificate.

4.6.3 Processing Certificate Renewal Requests

Identification and authentication may be established through the use of the current

signature private key, except that identity shall be authenticated through initial

registration process at least once every nine years from the time of initial registration.

4.6.4 Notification of New Certificate Issuance to Subscriber

See Section 4.3.2.

4.6.5 Conduct Constituting Acceptance of a Renewed Certificate

See Section 4.4.1.

4.6.6 Publication of the Renewal Certificate by the CA

See Section 4.4.2.


No stipulation.



of 145

4.7 CERTIFICATE RE-KEY

Re-keying a certificate means that a new certificate is created that has the same

characteristics and assurance 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 its own validity period.

4.7.1 Circumstance for Certificate Re-key

The longer and more often a key is used, the more susceptible it is to loss or discovery.

Therefore, it is important that a Subscriber periodically obtain new keys and re-establish

its identity.

A new certificate shall be issued to a Johnson & Johnson subordinate CA by the ORCA,

when that subordinate CA re-keys.

4.7.2 Who May Request Certification of a New Public Key

The certificate subject may request re-key of a certificate.

4.7.3 Processing Certificate Re-keying Requests

A certificate re-key identity-proofing shall be achieved using one of the following

processes:

Initial registration process as described in Section 3.2; or

Identity-proofing for re-key as described in Section 3.3.


See Section 4.3.2.

4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate

See Section 4.4.1.

4.7.6 Publication of the Re-keyed Certificate by the CA

See Section 4.4.2.


Trust anchor re-key information shall be promulgated to Subscribers using secure means

as set forth in the Johnson & Johnson CPS.



of 145

4.8 CERTIFICATE MODIFICATION

Updating a certificate means creating a new certificate that has the same or a different

key and a different serial number, and that differs in one or more other fields, from the

old certificate.

4.8.1 Circumstance for Certificate Modification

For example, a CA may choose to update a certificate of a Subscriber whose

characteristics have changed (e.g., has just received a medical degree). The old

certificate may or may not be revoked, but shall not be further re-keyed, renewed, or

updated.

Further, if an individual’s name changes (e.g., due to marriage), then proof of the name

change must be provided to an authoritative source (such as a Johnson & Johnson human

resources office) to allow the Enterprise Directory to be updated, in order for an updated

certificate having the new name to be issued.

Finally, when a CA updates its private signature key and thus generates a new public key,

the CA shall notify all CAs, RAs, and end-entities that rely on the CA’s certificate that it

has been changed. For self-signed (“root”) certificates, such certificates shall be

conveyed to end-entities in a secure fashion to preclude malicious substitution attacks.

4.8.2 Who May Request Certificate Modification

The certificate subject may request certificate modification.

4.8.3 Processing Certificate Modification Requests

Identification and authentication may be established through the use of the current

signature private key, except that identity shall be authenticated through initial

registration process at least once every nine years from the time of initial registration.


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.



of 145


See Section 4.7.7.

4.9 REVOCATION & SUSPENSION

Johnson & Johnson CAs shall issue Certificate Revocation Lists (CRLs). To the extent

practical, the contents of CRLs shall be checked before issuance to ensure that all

information is correct. This may be done using software which scans the CRLs looking

for any evidence of an improperly manufactured CRL.

4.9.1 Circumstance for Revocation of a Certificate

A certificate shall be revoked when the binding between the subject and the subject’s

public key contained within a certificate is no longer considered valid. Examples of

circumstances that invalidate the binding include:

Identifying information in the certificate has become invalid;

The Subscriber or CA can be shown to have violated, or is strongly suspected of

violating, the requirements of this CP and (for a CA) its CPS;

The private key has been or is suspected of having been compromised, or has

been lost, stolen, or destroyed in a fashion where there is potential for

compromise or loss of control over the use of the private key.

Whenever any of the above circumstances occur, the associated certificate shall be

revoked and placed on the corresponding CRL. Revoked certificates shall be included in

all new publications of the certificate status information until the certificates expire, at

which point they may be removed. However, for long term non-repudiation purposes, a

revoked certificate shall appear on at least one CRL.

The circumstances for revocation of a digital signature certificate may differ from those

that apply to revocation of an encryption certificate. Specifically, if a decryption private

key is destroyed or unavailable (but not lost or compromised), a copy can be recovered

and the certificate need not be revoked.

4.9.2 Who May Request Revocation of a Certificate

The CA that issued the certificate shall honor authenticated requests to revoke the

certificate from the following parties:

The Subscriber who is the holder of the private key or responsible agent for the

private key as set forth in Section 3.2.3.2 above



of 145

The Subscriber’s Supervisor/Sponsor (or designee thereof) or the Subscriber’s

Supervisor’s Supervisor

The entity responsible for that specific CA (i.e., the RCAO or SCAO)

A Role Manager (or designee thereof) (but only for the role certificate(s) for

which the Role Manager is the Sponsor)

The authoritative source for the Subscriber (such as a Johnson & Johnson Human

Resources Office for a human subscriber)

A LRA conducting a group registration (but only for individuals involved with

that group registration)

4.9.3 Procedure for Revocation Request

A request to revoke a certificate shall identify the certificate to be revoked, explain the

reason for revocation, and allow the request to be authenticated (e.g., digitally or

manually signed). Authentication of certificate revocation requests is important to

prevent malicious revocation of certificates by unauthorized parties. If the revocation is

being requested for reason of key compromise or suspected fraudulent use, then the

Subscriber’s Supervisor or Sponsor shall be notified as soon as possible.

Where the private key is held on a hardware token, a Subscriber ceasing its relationship

with Johnson & Johnson shall, prior to departure, surrender to Johnson & Johnson

(through any accountable mechanism) all cryptographic hardware tokens that were issued

by or on behalf of Johnson & Johnson. If a Subscriber leaves Johnson & Johnson and the

hardware tokens cannot be obtained from the Subscriber, then all certificates associated

with the unretrieved tokens shall be immediately revoked for the reason of “key

compromise”. The token shall be zeroized or destroyed prior to, or immediately upon,

surrender in the presence of the Subscriber, or shall be zeroized or destroyed promptly

after surrender and shall be protected from malicious use prior to zeroization or

destruction.

Role Managers shall determine whether certificate revocation is required when a user of a

role certificate is no longer authorized to use the certificate.

4.9.4 Revocation Request Grace Period

There is no revocation grace period.



of 145

4.9.5 Time within Which CA Must Process the Revocation Request

A CA shall process the revocation requests immediately upon receipt. The CA shall

generate and publish CRL in accordance with the requirements stipulated elsewhere in

this CP.

4.9.6 Revocation Checking Requirements for Relying Parties

Improper acceptance by a relying party of a revoked certificate could have damaging or

catastrophic consequences. The matter of how often new revocation data should be

obtained is a determination to be made by the Relying Party in accordance with Johnson

& Johnson security requirements, business partner requirements, and government

regulatory requirements, considering the risk, responsibility, and consequences for using

a certificate whose revocation status cannot be guaranteed.

4.9.7 CRL Issuance Frequency

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. Superseded certificate status information

shall be removed from the repository upon posting of the latest certificate status

information.

Certificate status information shall be published not later than the next scheduled update.

This will facilitate the local caching of certificate status information for off-line or remote

(laptop) operation. Coordination shall be done with repositories to reduce latency

between CRL creation and availability.

The routine issuance period of CRLs by the ORCA shall be no less frequently than once

every 31 days.

The routine issuance period of CRLs by subordinate CAs (SCA) shall be no less

frequently than once every 24 hours.

The ORCA CRL and ORCA issued OCSP Responder certificates may be generated in

advance and kept securely under two-person control. If the ORCA has not been

compromised and there are no changes to the CRL, pre-generated CRL is posted to meet

the issuance frequency requirement. If the ORCA has not been compromised and the

OCSP Responder key is still valid, the OCSP Responder certificate is provided to the

OCSP Responder.

4.9.8 Maximum Latency of CRLs

The maximum delay between the time that a certificate is revoked by a CA and the time

that this revocation information is available to Johnson & Johnson Relying Parties shall

be no greater than 24 hours. This shall be achieved by posting the CRL promptly to the



of 145

CRL Distribution Point URL. Coordination shall be done with repositories to reduce

latency between CRL creation and availability.

4.9.9 Online Revocation Checking Availability

In addition to Internet accessible CRLs, Johnson & Johnson shall support OCSP. Johnson

& Johnson OCSP Responders shall generate OCSP responses using the latest available

CRL from each CA. In order to improve response time, Johnson & Johnson OCSP

Responders may pre-generate and cache responses.

4.9.10 Online Revocation Checking Requirements

Applications may require OCSP checking to accept the validity of a digital signature

made using a Johnson & Johnson private key, at the discretion of the application.

4.9.11 Other Forms of Revocation Advertisements Available

No stipulation.

4.9.11.1 Checking Requirements for Other Forms of Revocation Advertisements

No stipulation.

4.9.12 Special Requirements Related to Key Compromise

If a Johnson & Johnson subordinate CA private key is compromised or stolen, a CRL

shall be immediately published by the ORCA. If a Subscriber private key is

compromised or stolen, a CRL shall be published within six hours of Johnson & Johnson

being notified of the compromise if such emergent action is considered necessary by the

CAO; otherwise publication shall appear on the next regularly scheduled CRL.

4.9.13 Circumstances for Suspension

Suspension shall not be used.

4.9.14 Who May Request Suspension

Not applicable.

4.9.15 Procedure for Suspension Request

Not applicable.

4.9.16 Limits on Suspension Period

Not applicable.



of 145

4.10 CERTIFICATE STATUS SERVICES

Subordinate CA CRLs are automatically published to their CRL Distribution Point URLs

immediately following generation. Except when a Subordinate CA revocation event

necessitates immediate CRL issuance and publication, Root CA CRLs are manually

published on a monthly basis. OCSP Responders reflect the content of the most recently

published CRLs no more than one hour after CRL publication.

4.10.1 Operational Characteristics

No stipulation.

4.10.2 Service Availability

No stipulation.

4.10.3 Optional Features

No stipulation.

4.11 END OF SUBSCRIPTION

Certificates that have expired prior to or upon end of subscription are not required to be

revoked. Unexpired CA certificates shall always be revoked at the end of subscription.

Unexpired Subscriber certificate shall be revoked upon end of subscription.

4.12 KEY ESCROW & RECOVERY

4.12.1 Key Escrow and Recovery Policy and Practices

Private decryption keys shall always be generated by the Johnson & Johnson PKI to

support decryption key escrow. When the private key is not generated on the module,

then the private key must be delivered in a secure fashion to the Subscriber, possibly

including the use of PKCS #12 “privacy” and “integrity” modes. Under no

circumstances shall anyone other than the Subscriber have knowledge of or control over

private signature keys.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.



of 145

5. FACILITY MANAGEMENT & OPERATIONS CONTROLS

5.1 PHYSICAL CONTROLS

CAs and CSAs shall impose physical security requirements specified in Section 5.1.2.

5.1.1 Site Location & 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

The CA and CSA equipment shall always be protected from unauthorized access, and

especially while the cryptographic module is installed and activated. Physical access

controls shall be implemented to reduce the risk of equipment tampering even when the

cryptographic module is not installed and activated.

The physical security measures shall:

Ensure no unauthorized access to the hardware is permitted

Ensure all removable media and paper containing sensitive plain-text information

is stored in secure containers

Ensure the equipment is 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

Removable cryptographic modules shall be inactivated prior to storage. When not in use,

removable cryptographic modules, activation information used to access or enable

cryptographic modules, and CA and CSA equipment shall be placed in secure containers.

Activation data shall either be memorized, or recorded and stored in a manner

commensurate with the security afforded the cryptographic module, and shall not be

stored with the cryptographic module.

A security check of the facility housing the CA and CSA equipment shall be done if the

facility is to be left unattended. At a minimum, the check shall verify the following:



of 145

The equipment is in a state appropriate to the current mode of operation (e.g., that

cryptographic modules are in place when “open”, and secured when “closed”);

Any security containers are properly secured;

Physical security systems (e.g., door locks, vent covers) are functioning properly;

and

The area is secured against unauthorized access.

5.1.3 Power and Air Conditioning

The CA 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. The CA directories (containing CA-issued certificates

and CRLs) shall be provided with Uninterrupted Power sufficient for a minimum of six

hours operation in the absence of commercial power, to support a smooth shutdown of

the CA operations.

5.1.4 Water Exposures

The facility housing the CA shall not be within a 100 year flood plain.

5.1.5 Fire Prevention & Protection

No stipulation.

5.1.6 Media Storage

CA media shall be stored so as to protect it from accidental damage (water, fire,

electromagnetic). Media that contains audit, archive, or backup information shall be

duplicated and stored in a location separate from the CAs. Backup may also be stored in

other appropriate secure locations (e.g., RCAO cases).

5.1.7 Waste Disposal

Sensitive waste material shall be disposed of in a secure fashion.

5.1.8 Off-site Backup

Each subordinate CA shall have full system backups, sufficient to recover from system

failure, performed on a periodic schedule, described in its CPS. Backups are to be

performed and stored off-site not less than once per week. For offline CAs, backups shall

be performed every time the CA is activated, but no more frequently than once per week.

At least one full backup copy shall be stored at an offsite location (separate from the CA



of 145

equipment). Unless required to meet the provisions of other sections of this CP, only the

latest full backup need be retained. The backup shall be stored at a site with physical and

procedural controls commensurate to that of the operational CA.

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 people

selected to fill these roles must be extraordinarily responsible or the integrity of the CA is

weakened. The functions performed in these roles form the basis of trust for all uses of

the CA. Two approaches are taken to increase the likelihood that these roles are

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.

Johnson & Johnson CAs may encompass products from more than one vendor, and each

vendor’s commercial product uses different mechanisms for registering or enrolling

Subscribers and issuing certificates. The requirements of this policy are therefore drawn

in terms of different roles, recited below, which may be filled on a collateral basis (i.e.,

none of which requires a full-time, dedicated individual). One person may fill multiple

roles as long as the role separation requirements specified in Section 5.2.4 are met.

(Note: The information derives from the Certificate Issuing and Management

Components Protection Profile developed by NIST, but modified to account for the

Johnson & Johnson PKI architecture.):

1. CA Administrator – authorized to install and configure the CA; establish and maintain

CA Officer accounts; configure profiles and audit parameters; generate the CA

signature key pair (for signing certificates); perform system maintenance, backup and

recovery; revoke subscriber certificates in response to properly formed requests

pursuant to this CP; and is part of the two person team required to activate the CA

signing key.

2. CA Officer – is part of the multi-person control over the key material required to

activate the ORCA or required to administer the Hardware Security Modules of any

subordinate CA. CAOs also controls physical access to CA systems.

3. CA Auditor – authorized to view and maintain audit logs.

4. CA Operator – authorized to perform system maintenance, backup and recovery.

Within the J&J PKI, the responsibilities of the CA Operator are assumed by the CA

Administrator.

In addition to these roles, there are further roles relevant to the Johnson & Johnson PKI,

specifically:



of 145

5. Key Recovery Authority Officer – authorized to approve requests for decryption

private key recovery for entities other than the requestor.

6. Recovery Agents - authorized to request recovery of decryption private keys for

arbitrary employees and partners.

7. Directory Authority Officer – authorized to administer and make changes to the

JJEDS Enterprise Directory and systems relating to the intake of information from the

Authoritative Sources.

8. CSA Auditor – authorized to view and manage CSA audit logs. Within the J&J PKI,

the responsibilities of the CSA Auditor are fulfilled by the CA Auditor.

9. CSA Administrator – authorized to configure and operate the CSA. Within the J&J

PKI, the responsibilities of the CSA Administrator are fulfilled by the CA

Administrator

The following sections contain a more detailed description of these roles. A roster of

individuals assigned to each role cited above, by name and WWID, shall be established

and maintained by the PAA or delegate of the PAA.

5.2.1.1 CA Administrator

An individual acting in this role is authorized to

Install and configure software on the CA system, including the CA itself;

Establish and maintain trusted CA accounts;

Configure profiles and audit parameters;

Generate the CA signature key pair (for signing certificates), and

Revoke subscriber certificates in response to properly formed and authenticated

requests pursuant to this CP.

The CA Administrator is the sole possessor of administrative rights on the CA servers.

Physical access to the CA for any activity is controlled by a CAO who must concur

before any activity requiring physical access is performed.

Each Johnson & Johnson CA shall have a maximum of five CA Administrators. All CA

Administrators shall be Johnson & Johnson Employees.

5.2.1.2 CA Officer

An individual acting in this role controls physical access to the CA systems, the

smartcards required to administer the HSMs for any CA or CSA and the smart cards

required to place the ORCA into a condition where it is able to issue (sign and

publish)There is no requirement that any individual CAO have all of these

responsibilities over all of the Johnson & Johnson CAs.

The Johnson & Johnson PKI shall have a maximum of six CA Officers. All CA Officers

shall be Johnson & Johnson Employees.



of 145

5.2.1.3 CA Auditor

An individual acting in this role is authorized to view and maintain audit logs. They shall

review a statistically significant portion of the logs on a monthly basis. There may be

multiple CA Auditors. The CA Auditor shall also be responsible for performing or

overseeing internal compliance audits to ensure that the CA is operating in accordance

with its CPS.

As mentioned above, a roster of individuals assigned to each role cited above, by name

and WWID, shall be established and maintained by the Administrator for the affected

Johnson & Johnson CA. This roster shall be used by the CA Auditor during audits to

ensure proper CA operation.

5.2.1.4 CA Operator

An individual acting in this role is authorized to perform system maintenance, backup

and recovery.

Within the Johnson &Johnson PKI, the CA Operator role is subsumed by the CA

Administrator role.

5.2.1.5 Key Recovery Authority Officer (KRAO)

An individual acting in this role is authorized to approve requests for decryption private

key recovery for entities other than the requestor.

The Key Recovery Authority Officer shall approve a request after it has been determined

to the satisfaction of the Key Recovery Authority Officer that there is a legitimate

business, legal, or regulatory requirement for the recovery and that the appropriate local

procedures have been carried out. The normal mode of operation is for a subscriber to

recover their own key and this does not require Key Recovery Authority Officer

approval.

The Johnson & Johnson PKI shall have a maximum of five Key Recovery Authority

Officers responsible for approving the requests for recovery of decryption private keys in

accordance with this CP. All Key Recovery Authority Officers shall be Johnson &

Johnson Employees.

The decryption key recovery function shall only cover encryption certificates, which are

issued only to Subscribers by Subordinate CAs.

5.2.1.6 Recovery Agents

An individual acting in this role is authorized to initiate a request for decryption private

key recovery for a subscriber. The normal mode of operation is for a subscriber to

recover their own key. However, there may be cases where there may be a legal,

regulatory, or business need to recover a private decryption key and the subscriber is not

available; or the need is such that the recovery must be performed without the

subscriber’s knowledge.

There shall be no more five Recovery Agents.



of 145

All Recovery Agents shall be Johnson & Johnson Employees.

Private decryption key recovery requests initiated by recovery agents shall be approved

by a Key Recovery Authority Officer as shall any key recovery request initiated by

someone other than the subscriber.

5.2.1.7 Directory Authority Officer

An individual acting in this role is authorized to administer and make changes to the

JJEDS Enterprise Directory and systems relating to the intake of information from the

Authoritative Sources.

The Johnson & Johnson PKI shall have a maximum of five Directory Authority Officers.

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

Within the Johnson &Johnson PKI, the CSA Auditor role is subsumed by the CA Auditor

role.

5.2.1.9 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;

Generating and backing up CSA keys;

Operation of the CSA equipment; and

System backups and recovery.

All CSA Administrators shall be Johnson & Johnson Employees.

Within the Johnson & Johnson PKI, the CSA Administrator role is subsumed by the CA

Administrator role.

5.2.2 Number of Persons Required per Task

The number of persons required for specific tasks such as CA signature key activation is

set forth in Section 6.2.2.



of 145

5.2.3 Identity-proofing 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 Separation of Roles

Role separation, when required as set forth below, may be enforced by the CA and CSA

equipment, through procedures, or by both means.

No individual in any of these roles shall have more than one identity, which may

allow him or her to serve in more than one role under different identities.

Under no circumstances shall any PKI entity perform its own compliance auditor

function.

Au

dit

or

CA

Off

icer

CA

Ad

min

istr

ato

r

CS

A A

dm

inis

trato

r

Key

Rec

over

y O

ffic

er

Key

Rec

over

y A

gen

t

Auditor OK X X X X X

CA Officer X OK X X OK OK

CA Administrator X X OK OK X X

CSA Administrator X X OK OK X X

Key Recovery Officer X OK X X OK X

Key Recovery Agent X OK X X X OK

5.3 PERSONNEL CONTROLS

5.3.1 Background, Qualifications, Experience, and Security Clearance Requirements

JJEDS PKI shall identify a group responsible and accountable for the operation of each

CA in the JJEDS PKI.

All persons 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 CA and CSA CPS.



of 145

5.3.2 Background Check Procedures

CA personnel shall be J&J Employees and pass a background investigation as required

for their employment.

5.3.3 Training Requirements

All personnel performing duties with respect to the operation of the CA shall receive

appropriate training. :

Documentation shall be maintained identifying all personnel who received training and

the training completed.

5.3.4 Retraining Frequency & Requirements

Individuals responsible for PKI roles shall be aware of changes in the CA operation. Any

significant change to the operations shall have a training (awareness) plan, and the

execution of such plan shall be documented.

5.3.5 Job Rotation Frequency & Sequence

No stipulation.

5.3.6 Sanctions for Unauthorized Actions

Appropriate administrative and disciplinary actions shall be taken against personnel who

have performed actions involving the CSA, CA or CA repository not authorized in this

CP or the CSA or CA CPS, or not in conformance with other Johnson & Johnson security

requirements.

5.3.7 Contracting Personnel Requirements

Contractor personnel employed to perform functions pertaining to the CA and CSA shall

meet applicable requirements set forth in this CP.

5.3.8 Documentation Supplied to Personnel

This CP, along with relevant parts of CA and CSA CPSs, PKI system installation,

configuration, management and operations documents, and any relevant statutes, policies

or contracts, shall be made available to personnel responsible for the Johnson & Johnson

PKI operation.



of 145

5.4 AUDIT

Audit log files shall be generated for all events relating to the security of a Johnson &

Johnson CA and CSA. Keyless OCSP Responders (also known as Repeaters) and their

platform need not audit any events.

Where possible, the security audit logs shall be automatically collected. Where this is not

possible, a logbook, paper form, or other physical mechanism shall be used. 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.5.2.

5.4.1 Types of Events Recorded

Event recording for the ORCA may differ from that for its subordinate CAs reflecting the

difference in its operation. This matter is covered in the following sections. A message

from any source requesting an action by a CA is an auditable event. The audit event shall

include message date and time, source, destination and message contents. 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 when executing the CA’s signing process

A success or failure indicator when performing certificate revocation

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

5.4.1.1 ORCA

The ORCA shall have the following events recorded:

Bringing the CA into operation

Shutting the CA down

Issuing a root (self-signed) certificate

Issuing a certificate to a subordinate CA

Issuing a Certificate Revocation List, regardless of whether it contains nothing or

whether it contains a subordinate CA’s certificate (thus effecting revocation in the

latter case).



of 145

5.4.1.2 Other CAs and CSA

Security auditing capabilities of other CAs and CSAs operating system and PKI

applications required by this CP shall be enabled. As a result, many of the events

identified in the table will be automatically recorded. Other events may be recorded

through alternative means. (Note: the table below derived from the Certificate Issuing

and Management Components Protection Profile developed by the National Institute of

Standards and Technology of the U.S. Government.) Auditing capabilities relevant to

Evaluation-Cert assurance levels shall be set forth by the PAA, and thus are not described

below.

Auditable Event CA CSA

SECURITY AUDIT

Changes to the server or operating system security audit

configuration, e.g., start and stop of audit logging, type of

events audited

X X

Any attempt to delete or modify the Audit logs X X

IDENTIFICATION AND AUTHENTICATION

Successful and unsuccessful attempts to assume any trusted

role as defined in Section 5 X X

The value of maximum authentication attempts is changed X X

Maximum authentication attempts unsuccessful authentication

attempts occur during user login X X

A system administrator unlocks an account that has been

locked as a result of unsuccessful authentication attempts X X

A system administrator changes the type of authenticator, e.g.,

from password to biometrics X X

LOCAL DATA ENTRY

Administrative actions taken on the system X X



of 145


All security-relevant data that is entered in the system X X

REMOTE DATA ENTRY

Security-relevant messages that are received by the system X X

DATA EXPORT AND OUTPUT

Requests for confidential and security-relevant information X X

KEY GENERATION

Whenever the server generates a key. (Not mandatory for

single session or one-time use symmetric keys) X X

PRIVATE KEY LOAD AND STORAGE

The loading of any server private keys X X

Access to Subscriber or CA private decryption keys retained

for data recovery purposes X

TRUSTED PUBLIC KEY ENTRY, DELETION AND

STORAGE

All changes to the trusted (CA or CSA) public keys, including

additions and deletions X X

SECRET KEY STORAGE

The manual entry of secret keys used for authentication X X



of 145


PRIVATE AND SECRET KEY EXPORT

The export of CA or CSA private and secret keys (keys used

for a single session or message are excluded) X X

CERTIFICATE REGISTRATION

Certificate requests X

CERTIFICATE REVOCATION

Certificate revocation requests X

CERTIFICATE STATUS CHANGE APPROVAL

The approval or rejection of a certificate status change request X X3

CA / CSA CONFIGURATION

Security-relevant changes to the configuration of the server X X

ACCOUNT ADMINISTRATION

Addition or deletion of roles or users X X

Modification to access control privileges of a user account or a

role X X

3 If applicable (e.g. when an OCSP responder may be configured to create certificate status

information)



of 145


CERTIFICATE PROFILE MANAGEMENT

Changes to the certificate profile X

REVOCATION PROFILE MANAGEMENT

Changes to the revocation profile X

CERTIFICATE REVOCATION LIST PROFILE

MANAGEMENT

Changes to the certificate revocation list profile X

OCSP PROFILE MANAGEMENT

Changes to the OCSP profile X

MISCELLANEOUS

Installation of the Operating System X X

Installation of the CA or CSA X X

Installing hardware cryptographic modules X X

Removing hardware cryptographic modules X X

Destruction of cryptographic modules X X

System Startup X X

Log-on Attempts to CA or CSA Applications X X



of 145


Receipt of hardware / software X X

Attempts to set passwords X X

Attempts to modify passwords X X

Backing up CA / CSA internal database X X

Restoring CA / CSA internal database X X

File manipulation (e.g., creation, renaming, moving) X X

Posting of any material to a repository X

Access to CA / CSA internal database (for unsigned, security-

relevant objects) X X

Loading tokens with certificates X

Shipment of tokens X

Zeroizing tokens X

Re-key of the CA / CSA X X

Configuration changes to the CA / CSA involving:

Hardware X X

Software X X

Operating System X X

Patches X X

Security Profiles X X

PHYSICAL ACCESS / SITE SECURITY

Personnel Access to room housing CA / CSA X X



of 145


Access to the secured cabinet containing the CA / CSA, or the

CA / CSA itself X X

Known or suspected violations of physical security X X

ANOMALIES

Software Error conditions X X

Software check integrity failures X X

Receipt of improper messages X X

Misrouted messages X X

Network attacks (suspected or confirmed) X X

Equipment failure X X

Electrical power outages X X

Uninterruptible Power Supply (UPS) failure X X

Obvious and significant network service or access failures X X

Violations of Certificate Policy X X

Violations of Certification Practice Statement X X

Resetting Operating System clock X X

5.4.2 Frequency of Processing Data

Audit logs for the ORCA shall be examined every time it is used. Audit logs for other

CAs shall be reviewed at least once per month. Audit logs for CSAs shall be reviewed at

least once every two months. The review shall examine a statistically significant set of

security audit data generated by the server since the last review (where the confidence

intervals for each category of security audit data are determined by the security

ramifications of the category and the availability of tools to perform such a review), as



of 145

well as include a reasonable search for any evidence of malicious activity. For the

ORCA, 100% of security audit data generated since the last review shall be examined.

All significant events shall be explained in an audit log summary. 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.

Actions taken as a result of these reviews shall be documented.

5.4.3 Retention Period for Security Audit Data

Audit logs shall be retained onsite for at least two months as well as being retained in the

manner described below. The individual who removes audit logs from the CA and CSA

system shall be an official different from the individuals who, in combination, command

the CA and CSA signature private key.

5.4.4 Protection of Security Audit Data

The audit processing shall not be done by or under the control of the RCAO or SCAO.

CA and CSA system configuration and procedures must be implemented together to

ensure that:

only authorized people have read access to the logs;

only authorized people shall archive or delete audit logs; and,

audit logs are not modified.

Procedures must be implemented to protect audit data from deletion or destruction prior

to the end of the audit log retention period (note that deletion requires modification

access). While retained at the site, audit logs shall be moved to a safe, secure storage

location separate from the CA and CSA equipment.

5.4.5 Security Audit Data Backup Procedures

For subordinate CAs, audit logs and audit summaries shall be backed up at least monthly.

A copy of the audit log shall be sent off-site in accordance with the CPS on a monthly

basis.

5.4.6 Security Audit Collection System (Internal or External)

The audit log collection system may or may not be external to the CA and CSA system.

Audit processes shall be invoked at system startup, and cease only at system shutdown.

If it becomes 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, then the



of 145

RCAO or SCAO shall determine whether to suspend CA and CSA operation until the

problem is remedied.

5.4.7 Notification to Event-causing Subject

This CP imposes no requirement to provide notice that an event was audited to the

individual, organization, device, or application that caused the event.

5.4.8 Vulnerability Assessments

The CA and CSA Auditors shall perform appropriate vulnerability assessments of

security controls.

5.5 ARCHIVE

5.5.1 Types of Events Archived

CA and CSA archive records shall be sufficiently detailed to establish the proper

operation of the system, or the validity of any certificate (including those revoked or

expired) issued by the CA. At a minimum, the following data shall be recorded:

Data To Be Archived CA CSA

CA accreditation (if applicable) X

Certification Practice Statement X

Contractual obligations 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

Documentation of receipt and acceptance of certificates X

Documentation of receipt of tokens X

All certificates issued or published X



of 145

Data To Be Archived CA CSA

Record of CA / CSA re-key X X

All CRLs issued and/or published X

All Audit Logs X X

Other data or applications to verify archive contents X X

Documentation required by compliance auditors X X

5.5.2 Retention Period for Archive

The minimum retention periods for archive data shall be 10.5 years. 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 established. Applications required to process archive

data shall also be maintained for a period determined by the PAA. Prior to the end of the

archive retention period, the CA and CSA shall provide archived data and the

applications necessary to read the archives to a PAA-approved archival facility, which

shall verify that the applications can read the archived data, and then shall preserve the

applications and the archived data.

5.5.3 Protection of Archive

No unauthorized user shall be permitted to write to, modify, or delete the archive.

Archived records may be moved to another storage medium when authorized by the

RCAO or SCAO. The contents of the archive shall not be released except as determined

by the PAA or as required by law. Records of individual transactions may be released

upon request of any Subscribers involved in the transaction or their legally recognized

agents. Archive media shall be stored in a safe, secure storage facility separate from the

CA or CSA itself.

5.5.4 Archive Backup Procedures

No stipulation.

5.5.5 Requirements for Time-stamping of Records

CA archive records shall be automatically time-stamped as they are created. The CPS

shall describe how system clocks used for time-stamping are maintained in synchrony

with an authoritative time standard.



of 145

5.5.6 Archive Collection System (Internal or External)

No stipulation.

5.5.7 Procedures to Obtain & Verify Archive Information

PAA provided instructions shall be used to create, verify, package, transmit, and store the

archive information.

5.6 KEY CHANGEOVER

To minimize risk from compromise of a CA’s private signature key, that key may be

changed often; from that time on, only the new key shall be used for certificate signing

purposes. This shall not prevent the CA from using the old key to sign OCSP Responder

certificate(s) of short validity period as long as the OCSP Responder certificate validity

period does not extend beyond the validity period of the CA certificate for the old key.

The older, but still valid, certificate shall be available to verify old signatures until all of

the certificates signed using the associated private key have also expired. If the old

private key is used to sign CRLs that contain certificates signed with that key, or to sign

the OCSP Responder certificate, then the old key shall be retained and protected.

The ORCA signature key shall have a validity period of ten years, and its corresponding

certificate shall have a validity period of twenty years. Johnson & Johnson subordinate

CA signature private keys shall have validity periods not to exceed ten years, and their

corresponding certificates shall have validity periods of no more than ten years. Cross

certificates shall be valid for six years or less.

5.7 COMPROMISE & DISASTER RECOVERY

5.7.1 Incident and Compromise Handling Procedures

If a Johnson & Johnson CA becomes unable to produce certificates or CRLs for any

reason, the capability to produce certificates or CRLs shall be restored before a serious

business disruption is encountered. If the CA key is suspected of compromise, the

procedures outlined in Section 5.7.3 shall be followed. Otherwise, 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.

The PAA shall be notified if any of the following cases occur:

suspected or detected compromise of a CA system;

physical or electronic attempts to penetrate a CA system;

denial of service attacks on a CA components;



of 145

any incident preventing a CA from issuing a CRL within 24 hours of the time

specified in the next update field of its currently valid CRL.

5.7.2 Computing Resources, Software, and/or Data are Corrupted

If 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 status information. 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.

5.7.3 CA Private Key Compromise Recovery Procedures

If the CA signature private key is compromised, stolen or lost (such that compromise is

possible even though not certain):

The PAA shall be immediately and securely notified;

If the CA is the ORCA, that CA shall immediately publish a CRL revoking its

own certificate, and shall notify all Relying Parties through other means as set

forth in the ORCA CPS as quickly as practical;

If the CA is a Johnson & Johnson subordinate CA, the ORCA shall immediately

publish a CRL revoking the affected CA’s certificate as set forth above;

A new CA key pair shall be generated in accordance with procedures set forth

in the CA CPS; and

A new certificate shall be issued to the CA by the ORCA in accordance with

this CP.

The PAA shall also investigate and report to the Vice President, Worldwide Information

Security what caused the compromise or loss, and what measures have been taken to

preclude recurrence.

5.7.4 Business Continuity Capabilities after a Disaster

If the CA cannot issue a CRL prior to the time specified in the next update field of its

latest CRL, then the PAA shall be immediately and securely notified. The CA shall

reestablish revocation capabilities as quickly as possible in accordance with procedures

set forth in its CPS.

In the case of a disaster whereby the CA installation is physically damaged and all copies

of the CA signature private key are destroyed as a result, the PAA shall be immediately

and securely notified, and shall take whatever action it deems appropriate. The CA

installation shall then be completely rebuilt, by reestablishing the CA equipment,



of 145

generating new private and public keys, being re-certified, and re-issuing all cross

certificates. Johnson & Johnson Relying Parties may decide of their own volition

whether to continue to use certificates signed with the destroyed private key pending

reestablishment of CA operation with new certificates. Non Johnson & Johnson Relying

Parties shall be governed by the provisions of the contract or similar instrument

concerning reliance on Johnson & Johnson-issued certificates.

For the ORCA, this means that although CRLs need only be produced every 400 days,

the actual production shall occur a reasonable period of time prior to the expiration of the

existing CRL, to allow time for recovery from any problem.

For a Johnson & Johnson subordinate CA, this means that a back-up copy of the CA shall

be created and maintained in a condition where it could be activated in sufficient time to

publish a new CRL before the then-extant CRL expires, using the same CA private

signature key employed in the CA that it is backing up. Section 6.2.4 allows a copy of

the CA private signature key to be made for this purpose.

5.8 CA OR RA TERMINATION

5.8.1 CA Termination

In the event of termination of the CA operation, the CA certificate and certificates signed

by the CA shall be revoked and the CA shall provide archived data to a PAA-approved

archival facility.

5.8.2 RA Termination

No stipulation.



of 145

6. TECHNICAL SECURITY CONTROLS

6.1 KEY PAIR GENERATION & INSTALLATION

6.1.1 Key Pair Generation

Cryptographic keying material used to sign certificates issued by any Johnson & Johnson

CAs shall be generated in FIPS 140 series validated cryptographic modules meeting or

exceeding Security Level 3. Cryptographic keys for CSAs to sign certificate status

responses shall be generated in FIPS 140 series validated cryptographic modules meeting

or exceeding Security Level 3

For Subscribers, software or hardware cryptographic modules shall be used to generate

pseudo-random numbers, key pairs and symmetric keys, as set forth in the table below.

Any pseudo-random numbers used for key generation material shall be generated by a

FIPS approved method.

Keys used for digital signature shall be generated in accordance with FIPS 186-2. For

example RSA prime number and exponents shall be generated in accordance with FIPS

186-2.

6.1.2 Private Key Delivery to Subscriber

The CA generates its own key pair and therefore does not need private key delivery. If

Subscribers generate their own signature keys, the keys will not require delivery; where

signature keys are generated by the CA, they shall be delivered in accordance with the

requirements of this CP and the applicable CPS. For encryption keys, delivery of the

private key to the Subscriber shall be in accordance with the requirements of this CP and

the applicable CPS.

A private signature key may be generated and remain within the cryptographic boundary

of the Subscriber’s cryptographic module (cryptographic module may be a software

module or a hardware token depending upon the certificate level of assurance), in which

case there is no need to deliver the private key. Private decryption keys shall always be

generated by the Johnson & Johnson PKI to support decryption key escrow. When the

private key is not generated on the module, then the private key must be delivered in a

secure fashion to the Subscriber, possibly including the use of PKCS #12 “privacy” and

“integrity” modes. Under no circumstances shall anyone other than the Subscriber have

knowledge of or control over private signature keys. Normally, a certificate shall be

issued to a single Subscriber. For cases where there are several entities acting in one

capacity, and where non-repudiation for transactions is not necessary or desired, a

certificate may be issued that corresponds to a private key that is shared by multiple

Subscribers. Within the Johnson & Johnson PKI, this is called a “role” certificate (“Code

Signing Entity” certificate is an example of a “role” certificate), and it may cover use for

authentication or for encryption, or for both (a “dual-use” certificate described later):



of 145

A Role Manager shall be responsible for ensuring control of the private key,

including maintaining a list of Subscribers who have access to use of the private

key, and accounting for which Subscriber had control of the key at what time;

The list of those having control over the shared private key must be maintained;

and

The procedures for issuing tokens for use in shared key applications must comply

with all other stipulations of this CP (e.g., key generation, private key protection,

and Subscriber obligations) and applicable CPS.

Where a key is generated directly on the Applicant’s or Subscriber’s token, or in a key

generator that securely transfers the key to the Applicant’s or Subscriber’s token, then the

Applicant or Subscriber is deemed to be in possession of the private key at the time of

generation or receipt, respectively. If the Applicant or Subscriber is not in possession of

the token when the key is generated, then the token shall be delivered to the recipient via

an accountable method that ensures that the correct tokens and activation data are

provided to the correct subjects. Acceptance of the token by the recipient shall be

recorded, and the record maintained. When any mechanism that includes a shared secret

(e.g., a password or PIN) is used, the mechanism shall ensure that only the proper parties

receive the shared secret unless otherwise specified.

6.1.3 Public Key Delivery to Certificate Issuer

A public key must be delivered for certificate issuance in a way that binds the

Applicant’s verified identity to the public key. This binding either shall be accomplished

using cryptography at least as strong as that employed in certificate issuance, or it shall

be accomplished using non-cryptographic physical and procedural mechanisms. These

mechanisms may include, but are not limited to, floppy disk (or other storage medium)

sent via registered mail or courier, or by delivery of a token to a certificate issuer for local

key generation at the point of certificate issuance or request. In all cases, the method

used for public key delivery shall be set forth in a CPS.

6.1.4 CA Public Key Delivery to Relying Parties

The public key of the ORCA shall be available for certificate validation. This public key

shall appear in a self-signed root certificate. The self-signed root certificate shall be

conveyed to end-entities (Subscribers and Relying Parties) in a trustworthy fashion. Such

a self-signed root certificate is sometimes called a Trusted Certificate. Acceptable

methods for Trusted Certificate delivery include but are not limited to:

The CA loading a Trusted Certificate onto tokens delivered to Relying Parties via

secure mechanisms;



of 145

Secure distribution of Trusted Certificates through secure out-of-band

mechanisms;

Comparison of certificate hashes or fingerprints against Trusted Certificate hashes

or fingerprints 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); and

Loading certificates from web sites secured with a currently valid certificate of

equal or greater assurance level than the certificate being downloaded.

6.1.5 Key Sizes

All FIPS-approved signature algorithms shall be considered acceptable. If the PAA

determines that the security of a particular algorithm may be compromised, it shall

require the CA to revoke the affected certificates.

All certificates issued shall use at least 1024 bit RSA, with Secure Hash Algorithm

version 1 (SHA-1) in accordance with FIPS 186-2 or equivalent. All certificates that

have “not – after” date beyond 12/31/2010 shall use at least 2048 bit RSA. However,

certificates asserting id-j&jCA-certpcy-certServerSoftware OID only that have “not –

after” date before 1/1/2014 may use 1024 bit RSA.

TLS or another protocol providing similar security to accomplish any of the requirements

of this CP shall use SHA-1 or SHA-2, triple-DES or AES (minimum 128 bit key

strength) for the symmetric key, and at least 2048 bit RSA or equivalent for the

asymmetric keys.

6.1.6 Public-Key Parameters Generation and Quality Checking

Public key parameters shall be generated in accordance with FIPS 186-2.

Parameter quality checking (including primarily testing for prime numbers) shall be

performed in accordance with FIPS 186-2 or equivalent as determined by the PAA.

6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)

Public keys that are bound into certificates shall be certified for use in signing or

encrypting, but not both, except as specified below. The use of a specific key is

determined by the key usage extension in the X.509 certificate. In particular, in the

keyUsage extension, certificates to be used for digital signatures (including

authentication) shall set the digitalSignature and nonRepudiation bits. Certificates to be

used for encryption shall set the keyEncipherment bit if RSA encryption is used, and

keyAgreement if ECDH or DH is used. Certificates issued only for authentication and not

digital signature shall set the digitalSignature bit without setting the nonRepudiation bit.



of 145

Additionally, a certificate issued to any Johnson & Johnson subordinate CA shall set two

key usage bits: cRLSign and certSign. This restriction is not intended to prohibit use of

protocols (like the Secure Sockets Layer) that provide authenticated connections using

key management certificates. Section 7.1.2 contains the full certificate profile to be

employed in all certificates issued by the Johnson & Johnson PKI.

In general, certificates shall be issued either for signature (including authentication) or

encryption use, but not for both purposes. However, when approved by the PAA for

Role-based certificates only, certificates may include a single key for use with

authentication and encryption in support of “smart card log-on” and legacy Secure

Multipurpose Internet Mail Extensions (S/MIME) applications. Such "dual-use"

certificates shall be generated and managed in accordance with their respective signature

certificate requirements, except where otherwise noted in this CP. Such "dual-use"

certificates shall never assert the nonRepudiation key usage bit.

6.2 PRIVATE KEY PROTECTION & CRYPTO-MODULE ENGINEERING

CONTROLS

6.2.1 Cryptographic Module Standards & Controls

The relevant standard for cryptographic modules is Security Requirements for

Cryptographic Modules [latest version of FIPS 140 series]. Cryptographic modules shall

be validated to the latest version of the FIPS 140 series level identified in this section.

The table below summarizes the minimum requirements for cryptographic modules;

higher levels may be used.

Assurance Level Latest version

of FIPS 140

series

CA and CSA Subscriber Registration

Authority

Evaluation-Cert

levels

PAA determines PAA determines PAA determines PAA determines

Cert-Software Required Level 3

(Hardware)

Level 1

(Software)

Level 2

(Hardware)

Cert-Hardware Required Level 3

(Hardware)

Level 2

(Hardware)

Level 2

(Hardware)

Cert-Hardware –

Biometrics

Required Level 3

(Hardware)

Level 2

(Hardware)

Level 2

(Hardware)

Cert-Applicant Required Level 3 Level 2 Level 2



of 145

(Hardware) (Hardware) (Hardware)

Cert-Code-Signing Required Same as Cert-

Hardware

Same as Cert-

Hardware

Same as Cert-

Hardware

Cert-Server-

Software

Required Same as Cert-

Software

Same as Cert-

Software

Same as Cert-

Software

Cert-Server-

Hardware


Hardware

Same as Cert-

Hardware

Same as Cert-

Hardware

Time-Stamp-

Authority-

Hardware


Server-Hardware

Level 3

(Hardware)

Same as Cert-

Server-Hardware

6.2.2 CA Private Key Multi-Person Control

Activation of a CA private signature key shall require action by at least two different

persons. One person shall be a CA Officer and the other person shall be another CA

Officer or a CA Administrator.

6.2.3 Private Key Escrow

Private decryption keys shall always be generated by the Johnson & Johnson PKI to

support decryption key escrow. When the private key is not generated on the module,

then the private key must be delivered in a secure fashion to the Subscriber, possibly

including the use of PKCS #12 “privacy” and “integrity” modes. Under no

circumstances shall anyone other than the Subscriber have knowledge of or control over

private signature keys.

In particular, under no circumstances shall the CA or Subscriber private signature keys be

escrowed by any party. CA or Subscriber private decryption keys may be escrowed to

support the recovery of encrypted data. Recovery of such keys shall be performed:

Upon authenticated request by the Subscriber named in the certificate

corresponding to the private decryption key, to the Johnson & Johnson CA that

issued the certificate. This may be done on an automated basis. Authentication

shall be established through use of the Subscriber’s private signature key. The

Subscriber shall be required to effect certificate revocation if the private

decryption key has been or is suspected of having been compromised. Recovery

response shall be provided through a channel whose security is commensurate

with the security offered by the key being recovered.



of 145

Upon authenticated request by an authorized Johnson & Johnson employee, in

which case the employee shall be authenticated and his or her authorization to

receive the key shall be established; authenticated and validated request shall go

to a KRAO. Authentication shall be done using the requester’s private signature

key or other means offering similar security. The KRAO for the affected Johnson

& Johnson CA, shall effect the private decryption key recovery and shall provide

the private decryption key to the requester over a secure channel whose security is

commensurate with the security offered by the key being recovered.

All requests for private decryption key recovery shall be documented either automatically

by the Johnson & Johnson PKI (where the request is made by the Subscriber) by the

KRAO (for all other requests), along with action taken to effect the key recovery.

It is technically possible to use the same key-pair for both digital signature (including

authentication) and confidentiality. However, this CP only allows that condition for

authentication and confidentiality, and only to support legacy applications as defined in

Section 6.1.7.

A Subscriber’s key-pair that is used for digital signatures shall never be escrowed or

archived, because a Subscriber can repudiate a transaction if there is a copy of his or her

digital signature private key in existence.

For information that is encrypted, the Subscriber shall use his or her private decryption

(confidentiality) key to decrypt the information. If that private key is lost or destroyed, or

if the Subscriber departs Johnson & Johnson without relinquishing the private key, or acts

maliciously, there is no way to decrypt the information. Thus, for business continuity

reasons, Johnson & Johnson must be able to escrow, backup or archive private keys used

for decrypting files and e-mails, while not escrowing, backing up or archiving key-pairs

used for authentication. This means that two separate key pairs need to be employed.

6.2.4 Private Key Backup

6.2.4.1 Backup of CA Signing Private Key

The CA private signature key shall be backed up under the same multi-person control as

the original signature key. One copy of the signing key shall be stored at the CA

location. A second copy shall be kept at the CA backup location. Procedures to effect

this shall be set forth in the CPS.

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 Signing Private Keys

No copy of a Subscriber private signature key shall be made if the private key is held in a

hardware cryptographic module. Subscribers are permitted to make operational copies of



of 145

private keys residing in software cryptographic modules for each of the Subscriber’s

applications or locations that requires the key in a different location or format. All key

transfers shall be done from an approved cryptographic module, and the key shall be

encrypted during the transfer. The Subscriber is responsible for ensuring that all copies

of private keys are protected, including protecting any workstation on which any of its

private keys reside.

6.2.5 Private Key Archival

Private signature keys shall not be archived.

6.2.6 Private Key Transfer into or from a Cryptographic Module

CA private signature keys shall be generated by and remain in a cryptographic module.

The CA and CSA private signature keys shall be backed up in accordance with Section

6.2.4.1.

Subscriber private keys may be copied (for the purpose of backup) from software

cryptographic modules, in accordance with Section 6.2.4.2, but shall not be copied if held

in hardware cryptographic modules.

6.2.7 Private Key Storage on Cryptographic Module

No stipulation beyond Section 6.2.1.

6.2.8 Method of Activating Private Keys

The Subscriber must be authenticated to the cryptographic module before the activation

of any private key(s). Acceptable means of authentication include but are not limited to

pass-phrases, PINs or biometrics. For the Cert-Hardware-Biometrics level of assurance,

the use of biometrics is required. Specific biometric data which is acceptable to be

employed for this purpose shall be established separately by the PAA. Biometrics, if

used, shall provide liveness property to ensure that the user is present. Entry of activation

data shall be protected from disclosure (i.e., the data shall not be displayed while it is

entered).

Exception: non-human Subscribers do not require authentication to their cryptographic

modules for private key activation if their human Sponsor so determines and if the

cryptographic module of the non-human Subscriber is an intrinsic part of the Subscriber

(e.g., hardware within a server or device, or software running on the server or device).

6.2.9 Methods of Deactivating Private Keys

Cryptographic modules holding Subscriber private keys that have been activated shall not

be left unattended or otherwise available to unauthorized access. After use, the



of 145

cryptographic module shall be deactivated, e.g., via a manual logout procedure, when

removed from the device, or automatically after a period of inactivity as defined in the

applicable CPS. Hardware cryptographic modules shall be removed from the device

when not in use; additionally, for CA cryptographic modules, they shall be stored in a

secure container when not in use.

6.2.10 Method of Destroying Private Keys

Subscriber private signature keys shall be destroyed when they are no longer needed, or

when the certificates to which they correspond expire or are revoked. For software

cryptographic modules, this may be done by overwriting the data to ensure its

obscuration. For hardware cryptographic modules, this may be done by executing a

“zeroize” command or physically destroying the module.

6.2.11 Cryptographic Module Rating

See table in Section 6.2.1.

6.3 OTHER ASPECTS OF KEY MANAGEMENT

6.3.1 Public Key Archive

The public key is archived as part of the certificate archival.

6.3.2 Certificate Operational Periods and Key Usage Periods

Certificate validity period shall be no longer than thirty-six (36) months for any

Subscriber. Certificate renewal, update and re-keying requirements are set forth in

Section 4.

The following table provides the maximum certificate validity periods for CSA.

Key Size CSA Private Key CSA Certificate

2048 bit RSA Up to 5 years 45 Days

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 and network security

controls.



of 145

6.4 ACTIVATION DATA

6.4.1 Activation Data Generation & Installation

The activation data used to unlock CA, CSA, or Subscriber private keys, in conjunction

with any other access control, shall have an appropriate level of strength for the keys or

data to be protected. For activation of private keys at the Cert-Software or Cert-

Hardware levels of assurance, PINs and passwords are acceptable; for activation of a

private key at the Cert-Hardware-Biometrics level of assurance, a biometric identifier is

required. (Exception: for CAs issuing certificates at the Cert-Hardware-Biometrics level

of assurance, the mechanism for unlocking the CA private signature key need not use

biometrics if an alternative approach provides sufficient protection as determined by the

PAA.) The PAA shall establish and separately publish which biometric identifiers are

considered acceptable for this purpose. Activation data shall be generated in

conformance with FIPS 140-2 requirements for Level 2 authentication. If the activation

data must be transmitted, it shall be via an appropriately protected channel, 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 shall either be

biometric in nature or memorized, not written down. If written down, it shall be secured

at the level of the data that the associated cryptographic module is used to protect, and

shall not be stored with the cryptographic module. For Cert-Applicant, Cert-Code-

Signing, Cert-Server-Hardware (if determined by the Sponsor), Cert-Hardware and Cert-

Hardware-Biometrics, the protection mechanism shall zeroize all private keys on the

module after no more than ten simultaneous unsuccessful login attempts.

6.4.3 Other Aspects of Activation Data

No stipulation.

6.5 COMPUTER SECURITY CONTROLS

6.5.1 Specific Computer Security Technical Requirements

The following computer security functions shall be provided by the operating system, or

through a combination of operating system, software, and physical safeguards. The CA,

CSA, and their ancillary parts shall include the following functionality:

Require authenticated log-ins



of 145

Provide Discretionary Access Control

Provide a security audit capability

Restrict access control to server services and PKI roles

Enforce separation of duties for PKI roles

Require identification and authentication of PKI roles and associated identities

Prohibit object re-use or require separation for server random access memory

Require use of cryptography for session communication and database security

Archive server history and audit data

Require self-test for security related services

Require a trusted path for identification of PKI roles and associated identities

Require a recovery mechanisms for keys and the server system

Enforce domain integrity boundaries for security critical processes

When CA application is hosted on evaluated platforms in support of computer security

assurance requirements then the system (hardware, software, operating system) shall,

when practical, operate in an evaluated configuration. At a minimum, such platforms

shall use the same version of the computer operating system as received the evaluation

rating.

6.5.2 Computer Security Rating

No Stipulation.

6.6 LIFE-CYCLE SECURITY CONTROLS

6.6.1 System Development Controls

The System Development Controls for the CA are as follows:

Hardware and software procured to operate the CA shall be purchased in a

fashion to reduce the likelihood that any particular component was tampered with

(e.g., by ensuring the equipment was randomly selected at time of purchase).



of 145

The CA hardware and software shall be dedicated to performing one task: the CA.

There shall be no other applications, hardware devices, network connections, or

component software, which are not part of the CA operation.

Proper care shall be taken to prevent malicious software from being loaded onto

the CA and CSA equipment. Only applications required to perform the operation

of the CA and CSA shall be obtained from sources authorized by local policy.

Hardware and software shall be scanned for malicious code on first use and

periodically afterward.

Hardware and software updates shall be purchased or developed in the same

manner as original equipment, and be installed by trusted and trained personnel in

a defined manner.

6.6.2 Security Management Controls

The configuration of the CA system as well as any modifications and upgrades shall be

documented and controlled. There shall be a mechanism for detecting unauthorized

modification to the CA software or configuration. A formal configuration management

methodology shall be used for installation and ongoing maintenance of the CA system.

The CA and CSA software, when first loaded, shall be verified as being that supplied

from the vendor, with no modifications, and be the version intended for use. The

integrity of the CA software shall be verified upon start-up and whenever an update or

modification is made.

6.6.3 Life-cycle Security Ratings

No stipulation.

6.7 NETWORK SECURITY CONTROLS

The CA and CSA shall employ appropriate security measures to ensure it is guarded

against denial of service and intrusion attacks. Such measures include the use of guards,

firewalls and filtering routers. Unused network ports and services shall be turned off.

Any network software present shall be necessary to the functioning of the CA and CSA.

The CPS shall define the network protocols and mechanisms required for the operation of

the CA and CSA. 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.

All certificate resources connected to the Internet shall provide continuous service.

Redundancy shall be employed to ensure continuity of service even during periods of

maintenance or backup. All certificate resources shall use a network guard, firewall or

filtering router to protect against denial of service and intrusion attacks.



of 145

6.8 TIME STAMPING4

The CA and CSA system clock shall be regularly set using an accepted time standard

such as the NIST atomic clock in Boulder, CO. The system clock shall be used for

establishing the time of:

Asserting notBefore field in a Subscriber’s Certificate

Asserting revocationDate in a CRL

Asserting thisUpdate in a CRL

Asserting producedAt in OCSP and other status responses

4 This time stamping requirement is different from trusted time stamp. This section simply deals

with obtaining accurate system clock time.



of 145

7. CERTIFICATE, CRL, AND OCSP PROFILES

7.1 CERTIFICATE PROFILE

This section contains the certificate profiles.

7.1.1 Version Numbers

The 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. Certificate extensions used by Johnson & Johnson CAs shall conform to the

certificate profile established by the Internet Engineering Task Force in RFC 3280,

Internet X.509 Public Key Infrastructure Certificate and CRL Profile [RFC3280]. , which

are also consistent with a similar profile published by NIST for the Federal government,

Federal PKI Version 1 Technical Specifications: Part E – X.509 Certificate and CRL

Extensions Profile [FPKI-E]. Pursuant to [RFC3280] and using the nomenclature

employed in that document, the following fully describes the profile for each certificate

that may be issued under the Johnson & Johnson PKI, covering the basic certificate fields

as well as the extensions. The use of any other extensions (e.g. private extensions

required by specific CA products), or any changes to the criticality of the cited

extensions, shall be approved by the PAA. Optional fields and extensions are identified

by the phrase “if present;” otherwise, the CA must populate the certificates with the fields

and extensions, if the CA creates a certificate of the given type. The actual certificate

profiles are contained in Section 12.

7.1.3 Algorithm Object Identifiers

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

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}

Certificates under this CP shall use the following OIDs for identifying the algorithm for

which the subject key was generated:

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



of 145

7.1.4 Name Forms

Where required as set forth above, the subject and issuer fields of the base certificate

shall be populated with an X.500 Distinguished Name as specified in [RFC3280], with

the attribute type as further constrained by [RFC3280]. Names shall be encoded in

printable string format, if possible. Otherwise names shall be encoded as UTF8 string.

DN shall use the organizational name form with c, o, ou and cn attribute types. Each

attribute value shall be encoded in a separate RDN.

7.1.5 Name Constraints

No stipulation.

7.1.6 Certificate Policy Object Identifier

A certificate issued under this CP shall assert the OID appropriate to the level of

assurance under which it was issued.

7.1.7 Usage of Policy Constraints Extension

No stipulation.

7.1.8 Policy Qualifiers Syntax and Semantics

Certificates may contain fields such as CP Pointer and User Notice for use by human

relying parties.

7.1.9 Processing Semantics for the Critical Certificate Policy Extension

Processing semantics for the critical certificate policy extension shall conform to X.509

certification path processing rules [RFC3280].

7.2 CRL PROFILE

7.2.1 Version Numbers

The Johnson & Johnson Root and subordinate CAs shall issue X.509 version two (2)

CRLs.

7.2.2 CRL & CRL Entry Extensions

Detailed CRL profiles addressing the use of each extension shall conform to [RFC3280],

as set forth in Section 12.12.



of 145

7.3 OCSP PROFILE

Requests sent to OCSP Responders are not required to be signed, but may be at the

discretion of the Relying Party. Johnson & Johnson OCSP Responders shall ignore the

signature. See RFC2560 for detailed syntax. Section 12.13 contains the OCSP request

and response formats.



of 145

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

Each Johnson & Johnson subordinate CA must have a compliance audit mechanism in

place to ensure that the requirements of this CP and its CPS are being implemented and

enforced. The PAA shall have a similar mechanism in place covering the ORCA and

provisions of agreements with cross-certified domains.

8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENTS

The Johnson & Johnson Root and subordinate CAs shall be subject to a periodic

compliance audit which is no less frequent than every two years.

Additionally, the PAA has the right to require aperiodic compliance audits or inspections

of any Johnson & Johnson CA or RA operation to validate that the subordinate entities

are operating in accordance with the security practices and procedures described in their

respective CPS.

8.2 IDENTITY/QUALIFICATIONS OF ASSESSOR

The auditor must demonstrate competence in the field of compliance audits, and must be

thoroughly familiar with requirements which the PAA imposes on the issuance and

management of certificates. The compliance auditor must perform such compliance

audits as a primary responsibility.

8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY

The compliance auditor either shall be a private firm which is independent from the entity

being audited, or it shall be sufficiently organizationally separated from that entity to

provide an unbiased, independent evaluation. An example of the latter situation is a

company internal auditor whose reporting chain is distinct from that of the organization

responsible for the Johnson & Johnson CA design and/or operation.

The PAA 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 an entity subject to the

requirements of this CP is complying with the requirements of this CP and the procedures

specified in the applicable CPS.

8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY

The PAA may determine that a Johnson & Johnson CA is not complying with its

obligations set forth in this CP or its CPS. When such a determination is made, the PAA



of 145

shall suspend operation of the Johnson & Johnson CA, or take other measures it deems

appropriate depending upon the nature of the discrepancy. Procedures for this purpose

shall be established by the PAA.

When the compliance auditor finds a discrepancy between how a Johnson & Johnson CA

is designed or is being operated or maintained, and the requirements of this CP or the

CA’s CPS, the following actions shall be taken:

The compliance auditor shall note the discrepancy and inform the entity

responsible for the CA as well as the PAA.

The party responsible for correcting the discrepancy shall determine what further

notifications or actions are necessary pursuant to the requirements of this CP, and

then proceed to make such notifications and take such actions without delay.

8.6 COMMUNICATION OF RESULTS

An Audit Compliance Report, including identification of corrective measures taken or

being taken, shall be provided to the PAA as set forth in this CP. The report shall

identify the CP and CPS used in the assessment, including their dates and version

numbers. Additionally, where necessary, the results shall be communicated as set forth

in Section 8.5 above.



of 145

9. OTHER BUSINESS & LEGAL MATTERS

9.1 FEES

No stipulation.

9.1.1 Certificate Issuance/Renewal Fee

No stipulation.

9.1.2 Certificate Access Fees

No stipulation.

9.1.3 Revocation or Status Information Access Fee

No stipulation.

9.1.4 Fees for Other Services

No stipulation.

9.1.5 Refund Policy

No stipulation.

9.2 FINANCIAL RESPONSIBILITY

This CP contains no limits on the use of any certificates, issued by the Johnson &

Johnson Root or subordinate CAs. Rather, Johnson & Johnson Relying Parties shall

determine what financial limits, if any, they wish to impose for certificates used to

consummate a transaction. Thus, one Johnson & Johnson organizational unit may be

willing to accept a Cert-Software assurance level certificate for transactions of a financial

value for which another organizational unit would require a Cert-Hardware assurance

level certificate. This is at the discretion of the organizational unit and its interpretation

of Johnson & Johnson financial requirements (e.g., World Wide Finance Procedures) and

other requirements, and is likely to depend upon several factors in addition to the

certificate assurance level (e.g., likelihood of fraud, other procedural controls, and

organizational unit-specific policy).

Relying Parties who are not Johnson & Johnson organizational units – e.g., partners or

customers – shall have responsibility for their use of a Johnson & Johnson-issued

certificate established in the contract, Memorandum of Agreement, or other similar

instrument between them and Johnson & Johnson. Johnson & Johnson disclaims any



of 145

responsibility for such use other than that established in the contract, Memorandum of

Agreement, or other similar instruments between them and Johnson & Johnson.

9.2.1 Insurance Coverage

No stipulation.

9.2.2 Other Assets

No stipulation.

9.2.3 Insurance/Warranty Coverage for End-entities

No stipulation.

9.3 CONFIDENTIALITY OF BUSINESS INFORMATION

Information pertaining to the JJEDS PKI and not requiring protection may be made

publicly available at the discretion of the PAA.

9.3.1 Scope of Confidential Information

No Stipulation.

9.3.2 Information Not Within the Scope of Confidential Information

No stipulation.

9.3.3 Responsibility to Protect Confidential Information

Information shall be protected in accordance with Johnson & Johnson information

assurance and protection policies.

9.4 PRIVACY OF PERSONAL INFORMATION

9.4.1 Privacy Plan

All Subscriber identifying information as defined by local privacy regulations shall be

protected from unauthorized disclosure.

9.4.2 Information Treated as Private

Such information shall include, in particular, personally-identifiable information such as

that protected under the Health Insurance and Portability and Accountability Act

(HIPAA).



of 145

9.4.3 Information Not Deemed Private

Shall include any information not specifically identified under Section 9.4.2. Information

included in the certificates shall be deemed not to be private.

9.4.4 Responsibility to Protect Private Information

Any sensitive information shall be explicitly identified in a CPS. All information stored

electronically on the component equipment and not in the repository, and all physical

records shall be handled as sensitive and shall be in accordance with Johnson & Johnson

IAPP. Access to this information shall be restricted to those with an official need-to-

know in order to perform their official duties. Sensitive information may be released in

accordance with other stipulations in Section 9.4.

9.4.5 Notice and Consent to Use Private Information

Requirements for notice and consent to use private information shall be per applicable

Johnson & Johnson Operating Policies.

9.4.6 Disclosure Pursuant to Judicial/Administrative Process

Any disclosure shall be handled in accordance with applicable Johnson & Johnson

Operating Policies.

9.4.7 Other Information Disclosure Circumstances


9.5 INTELLECTUAL PROPERTY RIGHTS

Johnson & Johnson retains exclusive rights to any products or information developed

under or pursuant to this CP.

9.6 REPRESENTATIONS AND WARRANTIES

The obligations described below pertain to the Johnson & Johnson Root and subordinate

CAs and any certificates they issue.

9.6.1 CA Representations and Warranties

The Johnson & Johnson PKI CAs represent and warrant that they shall conform to the

stipulations of this document, including:

Providing a CPS, as well as any subsequent changes, for conformance

assessment;



of 145

Conforming their practices and procedures to the stipulations of the approved

CPS;

Including only valid and appropriate information in the certificate, and

maintaining evidence that due diligence was exercised in validating the

information contained in the certificate;

Ensuring that obligations are imposed on Subscribers in accordance with Section

9.6.3 and the Subscribers are informed of the consequences of not complying with

those obligations;

Revoking the certificates of Subscribers found to have acted in a manner counter

to those obligations; and

Operating or providing for the services of an on-line repository that satisfies the

obligations under Section 9.6.5, and informing the repository service provider of

those obligations if applicable.

A CA who is found to have acted in a manner inconsistent with these obligations is

subject to action as described in Section 8.5.

9.6.2 RA Representations and Warranties

Any RAs from which the Johnson & Johnson Root or subordinate CAs accept requests

for certificates shall also meet the requirements of this CP and the relevant CA CPS to

which the RA corresponds. An RA who is found to have acted in a manner inconsistent

with these obligations is subject to revocation of RA responsibilities.

9.6.3 Subscriber Representations and Warranties

Before being issued certificates, subscribers shall be required to sign a document

containing the requirements the Subscriber shall meet in order to satisfy their obligations

respecting protection of the private key and use of the certificate.

Subscribers shall represent and warrant that they:

Accurately represent themselves in all communications with the PKI;

Protect their private keys at all times, in accordance with this policy, as stipulated

in their Subscriber 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 CA's CPS;

Abide by all the terms, conditions, and restrictions levied upon the use of their

private keys and certificates;

Use certificates in accordance with this CP.



of 145

Where the subscriber is a machine, the Sponsor shall assume the obligations of the

Subscriber.

9.6.4 Relying Party Representations and Warranties

This CP does not specify what steps a Relying Party must take to determine whether to

rely upon a certificate. The Relying Party decides, pursuant to Johnson & Johnson

security requirements, contractual requirements, business partner relationships, and

government regulatory requirements, what steps to take.

9.6.5 Representations and Warranties of Other Participants

9.6.5.1 Repository Representations and Warranties

See Section 2.1.1.

9.6.5.2 CSA Obligations

A CSA, who provides revocation status and/or complete validation of certificates

represents and warrants that it shall conform to the stipulations of this CP, including:

Providing a CPS, as well as any subsequent changes, for conformance

assessment;

Conforming to the stipulations of this CP and the approved CPS;

Ensuring that certificate and revocation information is accepted only from valid

CAs; and

Including only valid and appropriate response, and to maintain evidence that due

diligence was exercised in validating the certificate status.

A CSA who is found to have acted in a manner inconsistent with these obligations is

subject to action as described in Section 8.5.

9.7 DISCLAIMERS OF WARRANTIES

No stipulation.

9.8 LIMITATIONS OF LIABILITY

Johnson & Johnson disclaims any liability that may arise from use of any certificate

issued by the Johnson & Johnson Root or subordinate CAs, or any determination to

revoke a certificate issued by one of those CAs. In no event will Johnson & Johnson be

liable for any losses, including direct or indirect, incidental, consequential, special, or

punitive damages, arising out of or relating to any certificate issued by the Johnson &

Johnson PKI. J&J may accept liability by contract with relying parties for the use of



of 145

certificates issued under this CP, and if that is done, the terms of the contract shall be

controlling.

9.9 INDEMNITIES

No stipulation.

9.10 TERM AND TERMINATION

9.10.1 Term

No stipulation.

9.10.2 Termination

No stipulation.

9.10.3 Effect of Termination and Survival

No stipulation.

9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS

When designated by the PAA, communication among the PAA, JJEDS PKI, and

subscribers shall be in writing or via digitally signed communication. If in writing, the

communication shall be signed on the appropriate organization letterhead. If electronic, a

Digital Signature shall be made using a Private Key whose companion Public Key is

certified using a Certificate meeting the requirements of this CP.

9.12 AMENDMENTS

9.12.1 Procedure for Amendment

The PAA or its designee shall review this CP at least once every year. The PAA shall

maintain and publish a Certificate Policy Plan that describes anticipated changes to this

CP. Updates to this CP shall be communicated to every Relying Party and Subscriber.

Such communication shall include a description of the change, a change justification, and

contact information.

In evaluating the need for changes to this CP and the Object Identifiers it contains, the

PAA and its designee shall be guided by the language of RFC 3647 which states (in

section 4.9.12):



of 145

It will occasionally be necessary to amend a CP or CPS. Some of these changes

will not materially reduce the assurance that a CP or its implementation provides,

and will be judged by the policy administrator to have an insignificant effect on

the acceptability of certificates. Such changes to a CP or CPS need not require a

change in the CP OID or the CPS pointer (URL). On the other hand, some

changes to a specification will materially change the acceptability of certificates

for specific purposes, and these changes may require corresponding changes to

the CP OID or CPS pointer qualifier (URL).

9.12.2 Notification Mechanism and Period

This CP and any subsequent changes shall be made publicly available within one week of

approval.

9.12.3 Circumstances under Which OID Must Be Changed


9.13 DISPUTE RESOLUTION PROVISIONS

The PAA (or its designated representative) shall resolve any disputes associated with the

use of the Johnson & Johnson PKI.

9.14 GOVERNING LAW

The provisions of this CP shall be interpreted under the laws of the United States of

America and the State of New Jersey.

9.15 COMPLIANCE WITH APPLICABLE LAW

TBD

9.16 MISCELLANEOUS PROVISIONS

9.16.1 Entire Agreement

No stipulation.

9.16.2 Assignment

No stipulation.



of 145

9.16.3 Severability

Should it be determined that one section of this CP is incorrect or invalid, the other

sections of this CP shall remain in effect until the CP is updated. The process for

updating this CP is described in section 9.12.

9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights)

No stipulation.

9.16.5 Force Majeure

No stipulation.

9.17 OTHER PROVISIONS

9.17.1 Fiduciary Relationships

No stipulation.

9.17.2 Administrative Processes

Administrative processes pertaining to this CP shall be determined by the Johnson &

Johnson Vice President, Worldwide Information Security.

9.17.3 Waivers

The PAA reserves the right to grant waivers to this CP, and shall separately develop and

publish procedures pertaining to this area.



of 145

10. DIRECTORY INTEROPERABILITY PROFILE

Johnson & Johnson PKI objects shall be stored in an Internet accessible X.500 or LDAP

compliant directory, and/or in files accessible using HTTP. The following subsections

contain the requirements for directory and files depending on which one is used for

interoperability.

10.1 PROTOCOL

10.1.1 Directory

The directory shall provide an LDAP interface.

10.1.2 Certificate and CRL Files

The certificates (single certificate or p7c certificate bag) and CRL files shall be accessible

using HTTP URL.

10.2 AUTHENTICATION

10.2.1 Directory

The directory shall permits anonymous access to read certificate and CRL information.

Any write, update, add entry, delete entry, add attribute, delete attribute, change schema

etc, shall require password over SSL or equivalent (e.g., password over VPN or IPSEC,

or password over protected closed network) or stronger authentication mechanism.

10.2.2 Files

The HTTP resources shall be accessible using anonymous access to read certificate and

CRL information.

10.3 NAMING

10.3.1 Directory

Certificates shall be stored in the directory in the entry that appears in the certificate

subject name. issuedByThisCA element of crossCrossCertificatePair shall contain the

certificate(s) issued by a CA whose name the entry represents.

CRLs shall be stored in the directory in the entry that appears in the CRL issuer name.



of 145

10.3.2 Files

End entity certificates need not be accessible using HTTP. CA certificates shall be

accessible in a .p7c files ("certs-only" message). A file shall be located in a resources

pointed to by the AIA extension's caIssuers field. The file shall contain a certificate

issued to the CA's same public key that is used to verify the signature on the certificate in

which the AIA extension appears.

A full and complete CRL (without the issuingDistributionPoint extension) shall be stored

in the locations pointed to be the cRLDistributionPoints extension in the certificates

whose status can be verified using the referenced CRL.

10.4 OBJECT CLASS

10.4.1 Directory

Entries that describe CAs shall be defined by the organizationUnit structural object class.

These entries shall also be a member of pkiCA and cPCPS auxiliary object classes.

Entries that describe individuals (human entities) shall be defined by the inetOrgPerson

class, which inherits from other classes: person, and organizationalPerson. These entries

shall also be a member of pkiUser auxiliary object class.

10.4.2 Files

Not Applicable

10.5 ATTRIBUTES

10.5.1 Directory

CA entries shall be populated with the caCertificate, crossCertificatePair,

certificateRevocationList, cPCPS pointer attributes, as applicable. User entries shall be

populated with userCertificate attribute containing encryption certificate. Signature

certificate need not be published to the repository.

10.5.2 Files

Not applicable



of 145

11. PKI OBJECT IDENTIFIERS ARC

Prefix for J&J CSOR: { 2.16.840.1.113666.3}

{joint-iso-ccitt(2) country(16) us(840) organization(1) commercial-J&J(113666) csor(3)}

-- Technical Object Identifiers under id-j&jcsor Reserved ID::={id-j&jcsor 0} Reserved ID::={id-j&jcsor 1} id-j&jpkiobjects ID::={id-j&jcsor 2}

-- Technical Object Identifiers under id-j&jpkiobjects -- Reserved ID ::= {id-j&jpkiobjects 0} id-j&jcertpolicies ID ::= {id-j&jpkiobjects 1}

-- Certificate Policy -- {joint-iso-ccitt(2) country(16) us(840) organization(1) commercial-J&J(113666) csor(3)

j&jpkiobjects(2) j&jcertpolicies(1)}

id-j&jCA-certpcy-certEvaluationsoftware ID ::= {id-j&jcertpolicies 0} id-j&jCA-certpcy-certEvaluationhardware ID ::= {id-j&jcertpolicies 1} id-j&jCA-certpcy-certEvaluationhardwarebiometric ID ::= {id-j&jcertpolicies 2} id-j&jCA-certpcy-certSoftware ID ::= {id-j&jcertpolicies 3} id-j&jCA-certpcy-certHardware ID ::= {id-j&jcertpolicies 4} id-j&jCA-certpcy-certHardwarebiometrics ID ::= {id-j&jcertpolicies 5} id-j&jCA-certpcy-certApplicant ID ::= {id-j&jcertpolicies 6} id-j&jCA-certpcy-certEvaluationApplicant ID ::= {id-j&jcertpolicies 7} id-j&jCA-certpcy-certCodeSigning ID ::= {id-j&jcertpolicies 8} id-j&jCA-certpcy-certEvaluationCodeSigning ID ::= {id-j&jcertpolicies 9} id-j&jCA-certpcy-certServerSoftware ID ::= {id-j&jcertpolicies 10} id-j&jCA-certpcy-certEvaluationServerSoftware ID ::= {id-j&jcertpolicies 11} id-j&jCA-certpcy-certServerHardware ID ::= {id-j&jcertpolicies 12} id-j&jCA-certpcy-certEvaluationServerHardware ID ::= {id-j&jcertpolicies 13} id-j&jCA-certpcy-certEvaluationRole ID ::= {id-j&jcertpolicies 14} id-j&jCA-certpcy-certRoleSoftware ID ::= {id-j&jcertpolicies 15} id-j&jCA-certpcy-certRoleHardware ID ::= {id-j&jcertpolicies 16} id-j&jCA-certpcy-certRoleHardwarebiometrics ID ::= {id-j&jcertpolicies 17} id-j&jCA-certpcy-certTimeStampAuthorityHardware ID ::= {id-j&jcertpolicies 18} Reserved for Future Use ID ::= {id-j&jcertpolicies 19} Reserved for Future Use ID ::= {id-j&jcertpolicies 20} Reserved for Future Use ID ::= {id-j&jcertpolicies 21} Reserved for Future Use ID ::= {id-j&jcertpolicies 22} Reserved for Future Use ID ::= {id-j&jcertpolicies 23} Reserved for Future Use ID ::= {id-j&jcertpolicies 24} Reserved for Future Use ID ::= {id-j&jcertpolicies 25} Reserved for Future Use ID ::= {id-j&jcertpolicies 26} Reserved for Future Use ID ::= {id-j&jcertpolicies 27} Reserved for Future Use ID ::= {id-j&jcertpolicies 28} Reserved for Future Use ID ::= {id-j&jcertpolicies 29}



of 145

12. CERTIFICATES, CRLS, AND OCSP DETAILS

This section contains the certificate CRL and OCSP profiles for the various applicable

types of PKI entities.

All RSA public keys have public exponent 2^16+1 (65537) encoded as 0203010001.

The extensions may appear in any order since the extension identifiers tag the extensions.

Every extension is a 3-tuple: Extension Identifier as registered by ISO or owning

organization, criticality, and extension value. The extension identifiers for the applicable

certificate and CRL extensions are listed below.

Certificate Extension Extension Identifier (OID)

Authority Key Identifier {id-ce 35}

Subject Key Identifier {id-ce 14}

Key Usage {id-ce 15}

Extended Key Usage {id-ce 37}

Certificate Policies {id-ce 32}

Subject Alternate Name {id-ce 17}

Basic Constraints {id-ce 19}

CRL Distribution Point {id-ce 31}

Certificate Template 1.3.6.1.4.1.311.20.2.3

CRL Extension Extension Identifier (OID)

CRL Number {id-ce 20}

Reason Code {id-ce 21}

Authority Key Identifier {id-ce 35}

12.1 ORCA CERTIFICATE PROFILES

12.1.1 1024 Bit ORCA Certificate Profile

This profile is no longer in use and is included here for historical reference. The 1024 bit

POLCA was superseded by the 204 bit POLCA in 200 . It issued a final CRL and was

decommissioned on November 14, 2012. Relying parties should remove the POLCA

certificate from their trust stores.

12.1.2 2048 Bit and SHA-256 ORCA Certificate Profile

The following is the 2048 Bit and SHA-256 ORCA self-signed certificate profile. The

SHA-1 thumbprint (i.e., SHA-1 hash) of this certificate is 28 89 01 b1 ae a4 a9 eb 2e 8e

07 67 9e 01 df 80 c6 c5 e2 57.



of 145

Field Value

Version 2 (version number = 3)

Serial Number Integer

Issuer Signature Algorithm Identifier

sha1WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

Parameters Null

Issuer DN CN=JNJ 2048bit Root Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

Validity Period

Not before Time in Zulu (YYMMDDHHMMSSZ)

Not After Not before + no more than 20 years (YYMMDDHHMMSSZ)

Subject DN CN=JNJ 2048bit Root Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

Subject Public Key Information

Algorithm Identifier rsaEncryption, i.e., {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}

Public Key n, e (2048 bit modulus)

Signature

Algorithm Identifier sha1WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

Signature SHA-1 hash encrypted using issuer private key

Extension Extension Value and Criticality

Subject Key Identifier Not Critical, SHA-1 hash of subject public key and other data

Key Usage Critical, keyCertSign and cRLSign bits set

Basic Constraints Critical, cA = TRUE, pathLength absent

12.2 POLCA CERTIFICATE PROFILES

12.2.1 1024 Bit POLCA Certificate Profile (No Longer Used)

This profile is no longer in use and is included here for historical reference. The 1024 bit

POLCA was superseded by the 204 bit POLCA in 200 . It issued a final CRL and was

decommissioned on November 14, 2012. Relying parties should remove the POLCA

certificate from their trust stores.



of 145

12.2.2 2048 Bit POLCA Certificate Profile

Field Value





Parameters Null


Validity Period



Subject DN CN= JNJ 2048bit Principal OnLine Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US




Signature




Authority Information Access

Not Critical

id-ad-caIssuers: http://jjedsdata.jnj.com/rootca2048bit.p7c

id-ad-ocsp: http://jjedsocsp1.jnj.com/

Authority Key Identifier Not Critical,

Key Identifier = Subject Key Identifier field in the issuer self-signed certificate

Subject Key Identifier Not Critical, SHA-1 hash of the subject public key and other data


Certificate Policies Not Critical, {2.16.840.1.113666.3.2.1.i} with i = 0…29

Basic Constraints Critical, cA = TRUE, path length = 0

CRL Distribution Point Not critical, http://jjedscrl.jnj.com/rootca2048bit.crl

12.2.3 SHA-256 POLCA Certificate Profile

Field Value





Parameters Null



of 145

Issuer DN CN= JNJ 2048bit Root Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

Validity Period



Subject DN CN= JNJ 2048bit Principal OnLine Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US




Signature

Algorithm Identifier Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}




Not Critical

id-ad-caIssuers: http://jjedsdata.jnj.com/rootca2048bit.p7c


Authority Key Identifier Not Critical,

Key Identifier = Subject Key Identifier field in the issuer self-signed certificate

Subject Key Identifier Not Critical, SHA-1 hash of the subject public key and other data


Certificate Policies Not Critical, {2.16.840.1.113666.3.2.1.i} with i = 0…29

Basic Constraints Critical, cA = TRUE, path length = 0


12.3 HUMAN SUBSCRIBER CERTIFICATES

12.3.1 1024 Bit Human Subscriber Signature Certificate (No Longer Used)

This profile is no longer in use.

12.3.2 2048 Bit Human Subscriber Signature Certificate

Field Value





Parameters Null

Issuer DN CN= JNJ 2048bit Principal OnLine Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US



of 145

Field Value

Validity Period


Not After Not before + no more than 36 months (YYMMDDHHMMSSZ)

Subject DN

E=<Email Address>, CN=<common name of Subscriber, expressed

in English>, OU=<WWID>, OU= Employees PartnersCustomers, O=JNJ, C=US




Signature





Not Critical

id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c


Authority Key Identifier Not Critical

Key Identifier = Subject Key Identifier in issuer certificate

Subject Key Identifier Not Critical, SHA-1 hash of this certificate’s public key (n,e) and other data

Key Usage Critical, digital signature and non repudiation bits set

Extended Key Usage Not Critical, Client Authentication {1.3.6.1.5.5.7.3.2}, Secure Email {1.3.6.1.5.5.7.3.4}, and, only for hardware and hardware with biometrics certificates, Smart Card Logon {1.3.6.1.4.1.311.20.2.2}

Certificate Policies

Not Critical, {2.16.840.1.113666.3.2.1.i} i = 0…5 (one or more)

Policy Qualifier: Optional; Fields useful to human relying parties (e.g., CP Pointer and User Notice)

Subject Alternative Name

Not Critical, RFC 822 e mail address = <Subscriber e-mail address>, and OtherName OID = UPN = {1.3.6.1.4.1.311.20.2.3}, UPN Value = <Subscriber’s Domain Login Name>

CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl

12.3.3 SHA-256 Human Subscriber Signature Certificate

Field Value




Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Parameters Null



of 145

Field Value


Validity Period



Subject DN






Signature





Not Critical

id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c






Extended Key Usage Not Critical, Client Authentication {1.3.6.1.5.5.7.3.2}, Secure Email {1.3.6.1.5.5.7.3.4}, and, only for hardware and hardware with biometrics certificates, Smart Card Logon {1.3.6.1.4.1.311.20.2.2}





Not Critical, RFC 822 e mail address = <Subscriber e-mail address>, and OtherName OID = UPN = {1.3.6.1.4.1.311.20.2.3}, UPN Value = <Subscriber’s Domain Login Name>


12.3.4 1024 Bit Human Subscriber Encryption Certificate




of 145

12.3.5 2048 Bit Human Subscriber Encryption Certificate

Field Value





Parameters Null


Validity Period



Subject DN






Signature





Not Critical

id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c





Key Usage Critical, key encipherment and data encipherment bits set

Extended Key Usage Not Critical, Secure Email {1.3.6.1.5.5.7.3.4} and, for software certificates only, Encrypting File System {1.3.6.1.4.1.311.10.3.4}





Not Critical, RFC 822 e mail address = <Subscriber e-mail address>

CRL Distribution Point Not Critical, http://jjedscrl.jnj.com/polca2048bit.crl

http://jjedsdata.jnj.com/polca2048bit.p7c

http://jjedscrl.jnj.com/polca2048bit.crl



of 145

12.3.6 SHA-256 Human Subscriber Encryption Certificate

Field Value





Parameters Null


Validity Period



Subject DN






Signature





Not Critical

id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c






Extended Key Usage Not Critical, Secure Email {1.3.6.1.5.5.7.3.4} and, for software certificates only, Encrypting File System {1.3.6.1.4.1.311.10.3.4}





Not Critical, RFC 822 e mail address = <Subscriber e-mail address>






of 145

12.4 ROLE CERTIFICATES

12.4.1 1024 Bit Role Signature Certificate (No Longer Used)


12.4.2 2048 Bit Role Signature Certificate

Field Value





Parameters Null

Issuer DN CN=JNJ 2048bit Principal OnLine Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

Validity Period



Subject DN E=<Role Email Address

5>, CN=<Role Name, expressed in English>,

OU=<WWID of Subscriber holding the private key>, OU= Employees | Partners | Roles, O=JNJ, C=US




Signature





Not Critical; id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c


Authority Key Identifier Not Critical; Key Identifier = Subject Key Identifier in issuer certificate



Extended Key Usage

Not Critical, Client Authentication {1.3.6.1.5.5.7.3.2}, and Secure Email {1.3.6.1.5.5.7.3.4}. Optionally, only for hardware and hardware with biometrics certificates, Smart Card Logon {1.3.6.1.4.1.311.20.2.2}

5 E-mail address is optional, but must be present if the role has an e-mail address.




of 145





Not Critical, RFC 822 e mail address = <Role e-mail address, if present in the DN>; Optionally, OtherName OID = UPN

6 =

{1.3.6.1.4.1.311.20.2.3}, UPN Value = <Role Domain Login Name>


12.4.3 SHA-256 Role Signature Certificate

Field Value





Parameters Null


Validity Period



Subject DN E=<Role Email Address

7>, CN=<Role Name, expressed in English>,

OU=<WWID of Subscriber holding the private key>, OU= Employees | Partners | Roles, O=JNJ, C=US




Signature





Not Critical; id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c





Extended Key Usage Not Critical, Client Authentication {1.3.6.1.5.5.7.3.2}, and Secure

6 UPN is optional, but must be present if the POLCA is aware that the role has a UPN on JJNET.

7 E-mail address is optional, but must be present if the role has an e-mail address.





of 145

Email {1.3.6.1.5.5.7.3.4}. Optionally, only for hardware and hardware with biometrics certificates, Smart Card Logon {1.3.6.1.4.1.311.20.2.2}





Not Critical, RFC 822 e mail address = <Role e-mail address, if present in the DN>; Optionally, OtherName OID = UPN

8 =

{1.3.6.1.4.1.311.20.2.3}, UPN Value = <Role Domain Login Name>


12.4.4 1024 Bit Role Encryption Certificate (No Longer Used)


12.4.5 2048 Bit Role Encryption Certificate

Field Value





Parameters Null

Issuer DN CN=JNJ 2048bit Principal Online Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

Validity Period



Subject DN E=<Email Address of Role

9>, CN=<Role Name, expressed in

English>, OU= Roles, O=JNJ, C=US




Signature



8 UPN is optional, but must be present if the POLCA is aware that the role has a UPN on JJNET.

9 Optional; must be present if the role has an e-mail address.




of 145



Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c









Not Critical, RFC 822 e-mail address= <Role e-mail address, if present in DN>


12.4.6 SHA-256 Role Encryption Certificate

Field Value





Parameters Null


Validity Period



Subject DN E=<Email Address of Role

10>, CN=<Role Name, expressed in

English>, OU= Roles, O=JNJ, C=US




Signature







10 Optional; must be present if the role has an e-mail address.






of 145








Not Critical, RFC 822 e-mail address= <Role e-mail address, if present in DN>


12.5 TOKEN APPLICANT CERTIFICATES

12.5.1 Current “Token Applicant” Certificate

Field Value





Parameters Null

Issuer DN CN=Token Verification, O=<Token Vendor>

Validity Period


Not After11

Not before + no more than 1 day (YYMMDDHHMMSSZ)

Subject DN CN=DO NOT USE - Token Verification Only, O=<Token Vendor>




Signature12


Signature SHA-1 hash encrypted using subject private key



Key Usage Critical, digital signature

11 The Token Applicant Certificate on Tokens will always be expired

12 The Token Applicant Certificate is self-signed.




of 145

12.5.2 Deprecated “Token Applicant” Certificate

Field Value





Parameters Null

Issuer DN CN= JNJ Principal Online Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

Validity Period



Subject DN CN=Token Certificate Applicant, OU=Roles, O=Johnson & Johnson, C=US or CN= Token Certificate Applicant-<Vendor Name>, OU=Roles, O=Johnson & Johnson, C=US




Signature





Not Critical’; id-ad-caIssuers: http://jjedsdata.jnj.com/polca.p7c




Key Usage Critical, digital signature and key encipherment bit set

Extended Key Usage Not Critical, Client Authentication {1.3.6.1.5.5.7.3.2}, IP security user {1.3.6.1.5.5.7.3.7}, and Smart Card Logon {1.3.6.1.4.1.311.20.2.2}


Not Critical, {2.16.840.1.113666.3.2.1.n} n = 6 or 7



Not Critical, Optional, OtherName OID = UPN = {1.3.6.1.4.1.311.20.2.3}, UPN value = TBD

CRL Distribution Point Not Critical, http://jjedscrl.jnj.com/polca.crl

http://jjedsdata.jnj.com/polca.p7c

http://jjedscrl.jnj.com/polca.crl



of 145

12.6 NON-PERSON CERTIFICATES

12.6.1 1024 Bit Device Certificate (No Longer Used)


12.6.2 2048 Bit Device Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Unique identifier such as serial number>, OU= Devices, O=JNJ, C=US




Signature









Key Usage Critical, digital signature and key encipherment bits set

Extended Key Usage

Not Critical, {id-pkix id-kp(3) id-kp-serverauth (1) }, {id-pkix id-kp(3) id-kp-clientauth (2) }, Secure Email {1.3.6.1.5.5.7.3.4}

id-pkix OBJECT IDENTIFIER ::=

{ iso(1) identified-organization(3) dod(6) internet(1)

security(5) mechanisms(5) pkix(7) }

Certificate Policies Not Critical, {2.16.840.1.113666.3.2.1.n}, n = 10, 11, 12, or 13

Policy Qualifier: Optional; Fields useful to human relying parties (e.g.,


http://jjedsocsp1.jnj.com/



of 145

CP Pointer and User Notice)


Not Critical, RFC 822 email address = <device email address>, if present


12.6.3 SHA-256 Device Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Unique identifier such as serial number>, OU= Devices, O=JNJ, C=US




Signature










Extended Key Usage

Not Critical, {id-pkix id-kp(3) id-kp-serverauth (1) }, {id-pkix id-kp(3) id-kp-clientauth (2) }, Secure Email {1.3.6.1.5.5.7.3.4}





Not Critical, {2.16.840.1.113666.3.2.1.n}, n = 10, 11, 12, or 13


Subject Alternative Not Critical, RFC 822 email address = <device email address>, if






of 145

Name present


12.6.4 1024 Bit SSL Certificate (No Longer Used)


12.6.5 2048 Bit SSL Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Server DNS hostname>, OU= Servers, O=JNJ, C=US




Signature










Extended Key Usage

Not Critical, {id-pkix id-kp(3) id-kp-serverauth (1) }, {id-pkix id-kp(3) id-kp-clientauth (2) }




Certificate Policies Not Critical, {2.16.840.1.113666.3.2.1.n}, n = 10, 11, 12, or 13

Policy Qualifier: Optional; Fields useful to human relying parties (e.g.,






of 145

CP Pointer and User Notice)

Subject Alternate Name Not critical, dnsName = <Server DNS hostname(s)>


12.6.6 SHA-256 SSL Certificate

Field Value





Parameters Null


Validity Period







Signature










Extended Key Usage

Not Critical, {id-pkix id-kp(3) id-kp-serverauth (1) }, {id-pkix id-kp(3) id-kp-clientauth (2) }







Subject Alternate Name Not critical, dnsName = <Server DNS hostname(s)>








of 145

12.6.7 1024 Bit Other Server Certificate (No Longer Used)


12.6.8 2048 Bit Other Server Certificate

Field Value





Parameters Null


Validity Period







Signature










Extended Key Usage

Not Critical, {id-pkix id-kp(3) id-kp-serverauth (1) }, {id-pkix id-kp(3) id-kp-clientauth (2) }, IPSEC {1.3.6.1.5.5.8.2.2}







Subject Alternate Name Not critical, Server URL, IP Address, or DNS Name





of 145


12.6.9 SHA-256 Other Server Certificate

Field Value





Parameters Null


Validity Period







Signature










Extended Key Usage

Not Critical, {id-pkix id-kp(3) id-kp-serverauth (1) }, {id-pkix id-kp(3) id-kp-clientauth (2) }, IPSEC {1.3.6.1.5.5.8.2.2}







Subject Alternate Name Not critical, Server URL, IP Address, or DNS Name








of 145

12.7 TIME STAMP AUTHORITY (TSA) CERTIFICATES

12.7.1 2048 Bit TSA Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Server DNS hostname>, OU=Time Stamp Authority, OU=Servers, O=JNJ, C=US




Signature





Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/rootca2048bit.p7c

id-ad-ocsp : http://jjedsocsp1.jnj.com/




Extended Key Usage

Critical, { id-pkix kp(3) timestamping(8) }




Certificate Policies Not Critical, id-j&jCA-certpcy-certTimeStampAuthorityHardware {2.16.840.1.113666.3.2.1.18}

Subject Alternate Name Not critical, dnsName = <Server DNS hostname>





of 145

12.7.2 SHA-256 TSA Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Server DNS hostname>, OU=Time Stamp Authority, OU=Servers, O=JNJ, C=US




Signature






id-ad-ocsp : http://jjedsocsp1.jnj.com/




Extended Key Usage

Critical, { id-pkix kp(3) timestamping(8) }




Certificate Policies Not Critical, id-j&jCA-certpcy-certTimeStampAuthorityHardware {2.16.840.1.113666.3.2.1.18}

Subject Alternate Name Not critical, dnsName = <Server DNS hostname>





of 145

12.8 CODE SIGNING CERTIFICATES

12.8.1 1024 Bit Code Signing Certificate (No Longer Used)


12.8.2 2048 Bit Code Signing Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Code Signing Entity Name, expressed in English>, OU=<WWID of private key holder | unique organization name>, OU= Employees | Partners | Roles, O=JNJ, C=US




Signature










Extended Key Usage Critical, {id-pkix id-kp(3) id-kp-codesigning (3)}






of 145







12.8.3 SHA-256 Code Signing Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<Code Signing Entity Name, expressed in English>, OU=<WWID of private key holder | unique organization name>, OU= Employees | Partners | Roles, O=JNJ, C=US




Signature










Extended Key Usage Critical, {id-pkix id-kp(3) id-kp-codesigning (3)}






of 145








12.9 OCSP RESPONDER CERTIFICATES

12.9.1 1024 Bit OCSP Responder Certificate (No Longer Used)


12.9.2 2048 Bit OCSP Responder Certificate

Field Value





Parameters Null

Issuer DN Unique X.500 Issuing CA DN

Validity Period


Not After No more than 45 days after the certificate is available (YYMMDDHHMMSSZ)

Subject DN Unique X.500 OCSP Responder (subject) DN as appropriate


Algorithm Identifier rsaEncryption, {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}


Signature




Authority Information Not Critical; id-ad-caIssuers access method entry contains HTTP URL




of 145

Access for .p7c file containing certificates issued to issuing CA;



Key Usage Critical, nonRepudiation, digitalSignature

Extended Key Usage Critical, id-kp-OCSPSigning ::= {1 3 6 1 5 5 7 3 9}

Certificate Policies Not Critical, All policies the CA issues certificates for


Not Critical; HTTP URL for the OCSP Responder

No Check

(id-pkix-ocsp-nocheck; {1 3 6 1 5 5 7 48 1 5})

Not Critical; Null (empty) content

12.9.3 SHA-256 OCSP Responder Certificate

Field Value





Parameters Null

Issuer DN Unique X.500 Issuing CA DN

Validity Period


Not After No more than 45 days after the certificate is available (YYMMDDHHMMSSZ)

Subject DN Unique X.500 OCSP Responder (subject) DN as appropriate




Signature





Not Critical; id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing certificates issued to issuing CA;



of 145



Key Usage Critical, nonRepudiation, digitalSignature

Extended Key Usage Critical, id-kp-OCSPSigning ::= {1 3 6 1 5 5 7 3 9}

Certificate Policies Not Critical, All policies the CA issues certificates for


Not Critical; HTTP URL for the OCSP Responder

No Check

(id-pkix-ocsp-nocheck; {1 3 6 1 5 5 7 48 1 5})

Not Critical; Null (empty) content

12.10 KEY ESCROW AND RECOVERY CERTIFICATES

12.10.1 1024 Bit Key Escrow and Recovery Certificate (No Longer Used)


12.10.2 2048 Bit Key Escrow and Recovery Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<unique identifier of the usage>, OU= Roles, O=JNJ, C=US




Signature





of 145







Key Usage Critical, Key Encipherment

Extended Key Usage Not Critical, Key Recovery Agent(1.3.6.1.4.1.311.21.6)}


12.10.3 SHA-256 Key Escrow and Recovery Certificate

Field Value





Parameters Null


Validity Period



Subject DN CN=<unique identifier of the usage>, OU= Roles, O=JNJ, C=US




Signature









Key Usage Critical, Key Encipherment

Extended Key Usage Not Critical, Key Recovery Agent(1.3.6.1.4.1.311.21.6)}










of 145

12.11 CROSS CERTIFICATES

12.11.1 1024 Bit Cross Certificate (No Longer Used)


12.11.2 2048 Bit Cross Certificate

Field Value





Parameters Null


Validity Period



Subject DN Subject CA DN



Public Key n, e (2048 bit or larger modulus)

Signature




Authority Key Identifier Not Critical; Key Identifier = Subject Key Identifier in issuer self-signed certificate

Subject Key Identifier Not Critical, Provided by the Subject CA


Certificate Policies Not Critical, set by PAA

Certificate Policy Mapping

Not Critical, set by PAA, maps to appropriate subject domain policy




of 145

Name Constraints Critical, excludedSubtrees: O=JNJ, C=US13

Policy Constraints Critical; requireExplicitPolicy skipCerts = 0; inhibitPolicyMapping absent.


Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/rootca2048bit.p7c id-ad-ocsp: http://jjedsocsp1.jnj.com/

CRL Distribution Points Not critical, http://jjedscrl.jnj.com/rootca2048bit.crl

Inhibit anyPolicy Not Critical; skipCerts = 0

12.11.3 SHA-256 Cross Certificate

Field Value





Parameters Null


Validity Period



Subject DN Subject CA DN



Public Key n, e (2048 bit or larger modulus)

Signature




Authority Key Identifier Not Critical; Key Identifier = Subject Key Identifier in issuer self-signed certificate

Subject Key Identifier Not Critical, Provided by the Subject CA


13 The PAA may impose additional permitted and/or excluded subtree constraints.

http://jjedsdata.jnj.com/rootca2048bit.p7c


http://jjedscrl.jnj.com/rootca2048bit.crl



of 145

Certificate Policies Not Critical, set by PAA

Certificate Policy Mapping

Not Critical, set by PAA, maps to appropriate subject domain policy


Name Constraints Critical, excludedSubtrees: O=JNJ, C=US14

Policy Constraints Critical; requireExplicitPolicy skipCerts = 0; inhibitPolicyMapping absent.




CRL Distribution Points Not critical, http://jjedscrl.jnj.com/rootca2048bit.crl

Inhibit anyPolicy Not Critical; skipCerts = 0

12.12 CRLS

12.12.1 ORCA CRL

Field Value


Issuer Algorithm Id

1024 and 2048 bit ORCA: sha1WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

SHA-256 ORCA: sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Parameters Null

Issuer DN

1024 bit ORCA: CN=JNJ Root Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

2048 bit and SHA 256 ORCA: CN= JNJ 2048bit Root Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US for 2048 bit ORCA

This update Time in Zulu (YYMMDDHHMMSSZ)

Next Update This Update + no more than 14 months(YYMMDDHHMMSSZ)

List of revoked certificates

Revoked certificate 1 Serial number

Revocation date for 1 Time in Zulu (YYMMDDHHMMSSZ)

….

Revoked certificate n Serial number

Revocation date for n Time in Zulu (YYMMDDHHMMSSZ)

Signature

14 The PAA may impose additional permitted and/or excluded subtree constraints.

http://jjedsdata.jnj.com/rootca2048bit.p7c


http://jjedscrl.jnj.com/rootca2048bit.crl



of 145

Field Value

Algorithm Identifier

1024 and 2048 bit ORCA: sha1WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

SHA-256 ORCA: sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Signature

1024 and 2048 bit ORCA: SHA-1 hash encrypted using issuer private key

SHA-256 ORCA: SHA-256 hash encrypted using issuer private key

CRL Extension Extension Value and Criticality


Key Identifier = Subject Key Identifier in ORCA self-signed certificate

CRL Number Integer (never repeated)

12.12.2 POLCA CRL

Field Value


Issuer Algorithm Identifier

1024 bit and 2048 bit POLCA: sha1WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

SHA-256 POLCA: sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Parameters Null

Issuer DN

1024 bit POLCA: CN= JNJ Principal Online Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

2048 bit and SHA-256 POLCA: CN=JNJ 2048bit Principal Online Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US

This update Time in Zulu (YYMMDDHHMMSSZ)

Next Update This Update + 7 days (YYMMDDHHMMSSZ)

List of revoked certificates

Revoked certificate 1 Serial number

Revocation date for 1 Time in Zulu (YYMMDDHHMMSSZ)

….

Revoked certificate n Serial number

Revocation date for n Time in Zulu (YYMMDDHHMMSSZ)

Signature

Algorithm Identifier

1024 bit and 2048 bit POLCA: sha1WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

SHA-256 POLCA: sha256WithRSAEncryption, i.e., iso(1) member-



of 145

body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Signature

1024 bit and 2048 bit POLCA: SHA-1 hash encrypted using issuer private key

SHA-256 POLCA: SHA-256 hash encrypted using issuer private key

CRL Extension Extension Value and Criticality

Authority Key Identifier Not Critical, SHA-1 hash of the POLCA public key;

CRL Number Integer (never repeated)

12.13 OCSP

12.13.1 OCSP Request

Field Value

Version V1 (0)

Requester Name DN of the requestor

Request List List of certificates as specified in RFC 2560

Request Extension Value

Nonce Not Critical; Optional

Request Entry Extension

Value

None None

12.13.2 OCSP Response

Field Value

Response Status As specified in RFC 2560

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

Version V1 (0)

Responder ID Octet String (same as subject key identifier in Responder certificate)

Produced At Generalized Time

List of Responses Each response shall contain certificate id; certificate status15

, thisUpdate, nextUpdate,

Responder Signature 1024 and 2048 bit CA: sha1WithRSAEncryption, i.e., iso(1) member-

15 If the certificate is revoked, the OCSP Responder shall provide revocation time and revocation

reason from CRL entry and CRL entry extension.



of 145

Field Value

body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}; SHA-1 hash encrypted using Responder private key

SHA-256 CA: sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}; SHA-256 hash encrypted using Responder private key

Certificates Applicable certificates issued to the OCSP Responder

Request Extension Value

Nonce Not Critical; Value in the nonce field of request (optional)

Response Entry Extension

Value

None None



of 145

13. BIBLIOGRAPHY

The following documents were used in part to develop this CP:

ABADSG Digital Signature Guidelines, 1996-08-01.

http://www.abanet.org/scitech/ec/isc/dsgfree.html

CIMC PP Protection Profile for Certificate Issuing Management Components, Version

1, October 2001.

http://www.csrc.nist.gov/pki/documents/CIMC_PP_20011031.pdf

FIPS 140-1 Security Requirements for Cryptographic Modules, January 1994.

http://csrc.nist.gov/publications/fips/index.html

FIPS 140-2 Security Requirements for Cryptographic Modules, June 2001.


FIPS 186-2 Digital Signature Standard, January 2000.


FPKI-E Federal PKI Certificate and CRL Extensions Profile, April 2000.

http://www.csrc.nist.gov/pki/documents/FPKI_Certificate_Profile_20000418

.xls

ISO9594-8 Information Technology-Open Systems Interconnection-The Directory:

Authentication Framework, 1997.

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBE

R=32210

PKCS#12 Personal Information Exchange Syntax Standard, April 1997.

http://www.rsasecurity.com/rsalabs/node.asp?id=2138

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,

March 1997.

http://www.ietf.org/rfc/rfc2119.txt?number=2119

RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile,

Housley, Ford, Polk and Solo, January 1999.


RFC 2510 Certificate Management Protocol, Adams and Farrell, March 1999.


RFC 3647 Certificate Policy and Certification Practices Framework, Chokhani, Ford,

Sabett, Merrill and Wu, October 2003.

http://www.abanet.org/scitech/ec/isc/dsgfree.html

http://www.csrc.nist.gov/pki/documents/CIMC_PP_20011031.pdf




http://www.csrc.nist.gov/pki/documents/FPKI_Certificate_Profile_20000418.xls

http://www.csrc.nist.gov/pki/documents/FPKI_Certificate_Profile_20000418.xls

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=32210

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=32210

http://www.rsasecurity.com/rsalabs/node.asp?id=2138






of 145


RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile, Housley, Polk, Ford and Solo, April 2002.






of 145

14. ACRONYMS AND ABBREVIATIONS

CA Certification Authority

CAA Certification Authority Administrator

CAC Certificate Authorization Code

CAO Certification Authority Officer

CMM Capability Maturity Model

CN Common Name

CP Certificate Policy

CPS Certification Practice Statement

CRL Certificate Revocation List

CSA Certificate Status Authority

CSOR Computer Security Object Registry

DAO Directory Authority Officer

DES Data Encryption Standard

DH Diffie Hellman

DN Distinguished Name

DNS Domain Name Service

DSA Digital Signature Algorithm

DSS Digital Signature Standard

ECDH Elliptic Curve Diffie Hellman

ERC Enhanced Reliability Check

FED-STD Federal Standard

FIPS PUB (US) Federal Information Processing Standard Publication



of 145

FPKI-E Federal PKI Version 1 Technical Specifications: Part E – X.509 Certificate

and CRL Extensions Profile

HSM Hardware Security Module

IAPP Information asset Protection Policies

IETF Internet Engineering Task Force

ISO International Organization for Standardization

ITU International Telecommunications Union

ITU-T International Telecommunications Union – Telecommunications Sector

ITU-TSS International Telecommunications Union – Telecommunications System

Sector

IVC Identity Verification Code

JJEDS Johnson & Johnson Enterprise Directory and Security

KRAO Key Recovery Authority Officer

LRA Local Registration Authority

NIST National Institute of Standards and Technology

O Organization

OID Object Identifier

ORCA Offline Root Certification Authority

OCSP Online Certificate Status Protocol

OU Organizational Unit

PAA Policy Approving Authority

PIN Personal Identification Number

PKCS Public Key Cryptography Standard

PKI Public Key Infrastructure

PKIX Public Key Infrastructure X.509



of 145

POLCA Principal On-Line Certification Authority

RA Registration Authority

RCAO Root Certification Authority Officer

RFC Request For Comments

RSA Rivest-Shamir-Adleman (encryption algorithm)

SAFE Signatures & Authentication For Everyone

SBCA SAFE Bridge Certification Authority

SHA-1 Secure Hash Algorithm, Version 1

S/MIME Secure Multipurpose Internet Mail Extension

SSE System Security Engineering

SSL Secure Sockets Layer

TSA Time Stamp Authority

UPS Uninterrupted Power Supply

URL Uniform Resource Locator

US United States

WWID Worldwide identifier

WWW World Wide Web



of 145

15. GLOSSARY

Access Ability to make use of any information system (IS) resource.

[NS4009]

Access Control Process of granting access to information system resources only to

authorized users, programs, processes, or other systems. [NS4009]

Accreditation Formal declaration by a Designated Approving Authority that an

Information System is approved to operate in a particular security

mode using a prescribed set of safeguards at an acceptable level of

risk. [NS4009]

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 certification authority for a certificate, but before the

certificate issuance procedure is completed. [ABADSG footnote 32]

Application A specific use of computer software intended to serve a specific

need. For example, software which supports personnel travel needs

may have several different applications, one for the user to file a

request for travel authorization, another to file a request for travel

reimbursement, and still another to change travel preferences. The

level of assurance of a certificate needed for each such application

may vary.

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. [NS4009]

Audit Data Chronological record of system activities to enable the

reconstruction and examination of the sequence of events and

changes in an event. [NS4009, "audit trail"]

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. [NS4009]



of 145

Backup Copy of files and programs made to facilitate recovery if necessary.

[NS4009]

Binding Process of associating two related elements of information.

[NS4009]

Biometric A physical or behavioral characteristic of a human being.

Certificate A digital representation of information which at least (1) identifies

the certification authority 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 certification

authority issuing it. [ABADSG]. As used in this CP, the term

“Certificate” refers to certificates that expressly reference one or

more OIDs of this CP in the certificatePolicies extension 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.

CA Facility The collection of equipment, personnel, procedures and structures

that are used by a Certification Authority to perform certificate

issuance and revocation.

Certificate Management

Authority (CMA)

A Certification Authority, or a Registration Authority, or a

combination of the two.

Certification Authority

Software

Key Management and cryptographic software used to issue and

manage Subscriber certificates.

Certificate Policy (CP) A Certificate Policy is a specialized form of administrative policy

tuned to electronic transactions performed during certificate

management. A Certificate Policy addresses all aspects associated

with the generation, production, distribution, accounting,

compromise recovery and administration of digital certificates.

Indirectly, a certificate policy 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 this CP, or requirements specified in a contract for



of 145

services).

Certificate-Related

Information

Information, such as a Subscriber's postal address, that is not

included in a certificate; may be used by a CA managing certificates.

Certificate Revocation List

(CRL)

A list maintained by a Certification Authority of the certificates

which it has issued that are revoked prior to their stated expiration

date.

Certificate Status Authority A trusted entity that provides on-line 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.

Common Criteria A set of internationally accepted semantic tools and constructs for

describing the security needs of customers and the security attributes

of products.

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. [NS4009]

Computer Security Objects

Registry (CSOR)

Computer Security Objects Registry operated by the National

Institute of Standards and Technology.

Confidentiality Assurance that information is not disclosed to unauthorized entities

or processes. [NS4009]

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

Certification Authorities.

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. [FIPS1401]

Cryptoperiod Time span during which each key setting remains in effect.

[NS4009]

Data Integrity Assurance that the data are unchanged.

Digital Signature The result of a transformation of a message by means of a

cryptographic system using keys such that a Relying Party can



of 145

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.

Directory Authority Officer Individual who is responsible for the operation of the JJEDS

Enterprise Directory.

Dual Use Certificate A certificate that is intended for use with both digital signature and

data encryption services.

Duration A field within a certificate which is composed of two subfields;

“date of issue” and “date of next issue”.

E-commerce The use of network technology (especially the internet) to buy or sell

goods and services.

Electronic Signature 21 CFR Part 11. Electronic signature means a computer data

compilation of any symbol or series of symbols executed, adopted,

or authorized by an individual to be the legally binding equivalent of

the individual’s handwritten signature.

Electronic Signatures in Global and National Commerce Act: “…an

electronic sound, symbol or process attached to or logically

associated with a contract or other record and executed or adopted by

a person with the intent to sign the record.”

Employee Any person employed by the Johnson & Johnson Family of

Companies.

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. [NS4009]

Inside threat An entity with authorized access that has the potential to harm an

information system through destruction, disclosure, modification of

data, and/or denial of service.

Integrity Protection against unauthorized modification or destruction of

information. [NS4009]. A state in which information has remained

unaltered from the point it was produced by a source, during



of 145

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 A deposit of the private key of a Subscriber and other pertinent

information pursuant to an escrow agreement or similar contract

binding upon the Subscriber, the terms of which require one or more

agents to hold the Subscriber's private key for the benefit of the

Subscriber, an employer, or other party, upon provisions set forth in

the agreement. [adapted from ABADSG, "Commercial key escrow

service"] This only refers to the private key of encryption key pairs.

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 is be used to encrypt a message that can only be decrypted using

the other key (or one key is used to validate a signature made using

the other key), and (ii) knowing the public key, it is computationally

infeasible to discover the private key.

Key Recovery Authority

Officer (KRAO)

Trusted individual who is the sole approval authority for requests

involving the recovery of a subscriber’s private decryption key by

someone other than the subscriber

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

authenticate each other (see authentication).

Naming Authority An organizational entity responsible for assigning distinguished

names (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. [NS4009]

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.



of 145

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

the federal government PKI they are used to uniquely identify each

of the four policies and cryptographic algorithms supported.

Out-of-Band Communication between parties utilizing 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 through destruction, disclosure, modification of

data, and/or denial of service.

Physically Isolated Network A network that is not connected to entities or systems outside a

physically controlled space.

PKI Sponsor Fills the role of a Subscriber for non-human system components that

are named as public key certificate subjects, and is responsible for

meeting the obligations of Subscribers as defined throughout this

CP. Also sponsors non-Johnson & Johnson human Applicants, who

then become non-Johnson & Johnson Subscribers and are held

responsible for meeting the obligations defined throughout this CP.

Policy Approval Authority

(PAA)

Body established to oversee the creation and update of Certificate

Policies, review Certification Practice Statements, review the results

of CA audits for policy compliance, evaluate non-domain policies

for acceptance within the domain, and generally oversee and manage

the PKI certificate policies.

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 that is 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 that is used to

encrypt confidential information. In both cases, this key is made

publicly available normally in the form of a digital certificate.

Public Key Cryptography

Standards

Specifications produced by RSA Laboratories in cooperation with

secure systems developers worldwide for the purpose of accelerating



of 145

the use, acceptance, and deployment of public-key cryptography

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 that does not sign or issue certificates (i.e., a

Registration Authority 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.

Responsible Individual A trustworthy person designated by a sponsoring organization to

authenticate individual Applicants seeking certificates on the basis of

their affiliation with the Sponsor.

Revoke a Certificate To prematurely end the operational period of a certificate effective at

a specific date and time.

Risk An expectation of loss expressed as the probability that a particular

threat will exploit a particular vulnerability with a particular harmful

result.

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.



of 145

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 signature key is

certified by another CA, and whose activities are constrained by that

other CA. (See superior 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.

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

key of another CA, and who constrains the activities of that CA. (See

subordinate CA).

System Equipment

Configuration

A comprehensive accounting of all system hardware and software

types and settings.

Technical non-repudiation The demonstration that by using a public key to validate a digital

signature, that the signature must have been made using the

corresponding private key. See also “Non-repudiation.”

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. [NS4009]

Trust List Collection of trusted certificates used by Relying Parties to

authenticate other certificates.

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.

Trustworthy System Computer hardware, software and procedures that: (1) are reasonably

secure from intrusion and misuse; (2) provide a reasonable level of

availability, reliability, and correct operation; (3) are reasonably



of 145

suited to performing their intended functions; and (4) adhere to

generally accepted security procedures.

Two-Person Control Two people are required to concur before an action can be taken.

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.

Validation (when used in

context of "computer

system validation" only)

Establishing documented evidence that provides a high degree of

assurance that a specific process will consistently produce a product

meeting its predetermined specifications and quality attributes.

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.

[FIPS1401]



of 145

16. ACKNOWLEDGEMENTS

Special thanks are due to the following individuals, who contributed substantially to the

development of this CP: Tom Bunt, Rich Guida, Bob Stahl, Ivy Lyons, and Gary Secrest

from Johnson & Johnson Worldwide Information Security; and Santosh Chokhani, Geoff

Beier, Matt Cooper, and Scott Shorter of CygnaCom Solutions, Inc. Thanks also go to

Peter Hesse from Gemini Security Solutions for participating in a review of this CP.

Johnson & Johnson Enterprise Directory and Security …jjedscps.jnj.com/cp.pdfJohnson & Johnson...

Documents

Transcript of Johnson & Johnson Enterprise Directory and Security …jjedscps.jnj.com/cp.pdfJohnson & Johnson...