Post on 20-May-2018
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
Page 2 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 3 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 4 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 5 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 6 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 7 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 8 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 9 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 10 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: November 1, 2013
Page 11 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..
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 12 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 13 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;
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 14 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}
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 15 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
::= {id-j&jcertpolicies 9} ::=
{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
::= {id-j&jcertpolicies 11} ::=
{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
::= {id-j&jcertpolicies 13} ::=
{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}
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 16 of 145
id-j&jCA-certpcy-
certRoleHardwarebiometrics
::= {id-j&jcertpolicies 17} ::=
{2.16.840.1.113666.3.2.1.17}
id-j&jCA-certpcy-
certTimeStampAuthorityHardware
::= {id-j&jcertpolicies 18} ::=
{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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 17 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 18 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 19 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”).
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 20 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 21 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 22 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 23 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 24 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 25 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 26 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 27 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).
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 28 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 29 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 30 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 31 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 32 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 33 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-
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 34 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
Same as Cert-Software
Cert-Applicant Not applicable – no re-keying done by Subscriber
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 35 of 145
Assurance
Level
Routine Re-key Identification and Authentication Requirements for
Subscriber Signature and Encryption Certificates
Cert-Code-
Signing
Same as Cert-Software
Cert-Server-
Software
Same as Cert-Software
Cert-Server-
Hardware
Same as Cert-Software
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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 36 of 145
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 37 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 38 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 39 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;
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 40 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.
4.6.7 Notification of Certificate Issuance by the CA to Other Entities
No stipulation.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 41 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.
4.7.4 Notification of New Certificate Issuance to Subscriber
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.
4.7.7 Notification of Certificate Issuance by the CA to Other Entities
Trust anchor re-key information shall be promulgated to Subscribers using secure means
as set forth in the Johnson & Johnson CPS.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 42 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.
4.8.4 Notification of New Certificate Issuance to Subscriber
See Section 4.3.2.
4.8.5 Conduct Constituting Acceptance of Modified Certificate
See Section 4.4.1.
4.8.6 Publication of the Modified Certificate by the CA
See Section 4.4.2.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 43 of 145
4.8.7 Notification of Certificate Issuance by the CA to Other Entities
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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 44 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 45 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 46 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 47 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 48 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:
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 49 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 50 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:
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 51 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 52 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 53 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 54 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 55 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 56 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).
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 57 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 58 of 145
Auditable Event CA CSA
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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 59 of 145
Auditable Event CA CSA
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)
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 60 of 145
Auditable Event CA CSA
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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 61 of 145
Auditable Event CA CSA
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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 62 of 145
Auditable Event CA CSA
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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 63 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 64 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 65 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 66 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;
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 67 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,
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 68 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 69 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):
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 70 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;
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 71 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 72 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 73 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
Required Same as Cert-
Hardware
Same as Cert-
Hardware
Same as Cert-
Hardware
Time-Stamp-
Authority-
Hardware
Required Same as Cert-
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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 74 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 75 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 76 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 77 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 78 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).
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 79 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 80 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 81 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}
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 82 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 83 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 84 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 85 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 86 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 87 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).
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 88 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
No stipulation beyond Section 9.4.6.
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;
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 89 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 90 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 91 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):
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 92 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
No stipulation beyond Section 9.12.1.
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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 93 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 94 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 95 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 96 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}
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 97 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 98 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 99 of 145
12.2.2 2048 Bit POLCA Certificate Profile
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 10 years (YYMMDDHHMMSSZ)
Subject DN CN= JNJ 2048bit Principal OnLine 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
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
Key Usage Critical, keyCertSign and cRLSign bits set
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
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 100 of 145
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 10 years (YYMMDDHHMMSSZ)
Subject DN CN= JNJ 2048bit Principal OnLine 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
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
Key Usage Critical, keyCertSign and cRLSign bits set
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.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
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 Principal OnLine Certification Authority, OU=JNJ Public Key Authorities, O=JNJ, C=US
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 101 of 145
Field Value
Validity Period
Not before Time in Zulu (YYMMDDHHMMSSZ)
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
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
Authority Information Access
Not Critical
id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 102 of 145
Field Value
Issuer DN CN= JNJ 2048bit Principal OnLine 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 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
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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical
id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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.4 1024 Bit Human Subscriber Encryption Certificate
This profile is no longer in use.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 103 of 145
12.3.5 2048 Bit Human Subscriber Encryption Certificate
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 Principal OnLine 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 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
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
Authority Information Access
Not Critical
id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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, 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}
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>
CRL Distribution Point Not Critical, http://jjedscrl.jnj.com/polca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 104 of 145
12.3.6 SHA-256 Human Subscriber Encryption Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN= JNJ 2048bit Principal OnLine 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 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
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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical
id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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, 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}
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>
CRL Distribution Point Not Critical, http://jjedscrl.jnj.com/polca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 105 of 145
12.4 ROLE CERTIFICATES
12.4.1 1024 Bit Role Signature Certificate (No Longer Used)
This profile is no longer in use.
12.4.2 2048 Bit Role Signature Certificate
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 Principal OnLine 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 36 months (YYMMDDHHMMSSZ)
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
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
Authority Information Access
Not Critical; id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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}, 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 106 of 145
Certificate Policies
Not Critical, {2.16.840.1.113666.3.2.1.i} i = 14…17 (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 = <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>
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.4.3 SHA-256 Role Signature Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN= JNJ 2048bit Principal OnLine 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 36 months (YYMMDDHHMMSSZ)
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
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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers; http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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}, 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 107 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}
Certificate Policies
Not Critical, {2.16.840.1.113666.3.2.1.i} i = 14…17 (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 = <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>
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.4.4 1024 Bit Role Encryption Certificate (No Longer Used)
This profile is no longer in use.
12.4.5 2048 Bit Role Encryption Certificate
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 Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN E=<Email Address of Role
9>, CN=<Role Name, expressed in
English>, OU= Roles, 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
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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 108 of 145
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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, key encipherment and data encipherment bits set
Certificate Policies
Not Critical, {2.16.840.1.113666.3.2.1.i} i = 14…17 (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= <Role e-mail address, if present in DN>
CRL Distribution Point Not Critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.4.6 SHA-256 Role Encryption Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN=JNJ 2048bit Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN E=<Email Address of Role
10>, CN=<Role Name, expressed in
English>, OU= Roles, 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
10 Optional; must be present if the role has an e-mail address.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 109 of 145
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, key encipherment and data encipherment bits set
Certificate Policies
Not Critical, {2.16.840.1.113666.3.2.1.i} i = 14…17 (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= <Role e-mail address, if present in DN>
CRL Distribution Point Not Critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.5 TOKEN APPLICANT CERTIFICATES
12.5.1 Current “Token Applicant” Certificate
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=Token Verification, O=<Token Vendor>
Validity Period
Not before Time in Zulu (YYMMDDHHMMSSZ)
Not After11
Not before + no more than 1 day (YYMMDDHHMMSSZ)
Subject DN CN=DO NOT USE - Token Verification Only, O=<Token Vendor>
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 (1024 bit modulus)
Signature12
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 subject private key
Extension Extension Value and Criticality
Subject Key Identifier Not Critical, SHA-1 hash of this certificate’s public key (n,e) and other data
Key Usage Critical, digital signature
11 The Token Applicant Certificate on Tokens will always be expired
12 The Token Applicant Certificate is self-signed.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 110 of 145
12.5.2 Deprecated “Token Applicant” Certificate
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 Principal Online 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=Token Certificate Applicant, OU=Roles, O=Johnson & Johnson, C=US or CN= Token Certificate Applicant-<Vendor Name>, OU=Roles, O=Johnson & Johnson, 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 (1024 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
Authority Information Access
Not Critical’; id-ad-caIssuers: http://jjedsdata.jnj.com/polca.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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}
Certificate Policies
Not Critical, {2.16.840.1.113666.3.2.1.n} n = 6 or 7
Policy Qualifier: Optional; Fields useful to human relying parties (e.g., CP Pointer and User Notice)
Subject Alternative Name
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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 111 of 145
12.6 NON-PERSON CERTIFICATES
12.6.1 1024 Bit Device Certificate (No Longer Used)
This profile is no longer in use.
12.6.2 2048 Bit Device Certificate
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 Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN CN=<Unique identifier such as serial number>, OU= Devices, 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
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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.,
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 112 of 145
CP Pointer and User Notice)
Subject Alternative Name
Not Critical, RFC 822 email address = <device email address>, if present
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.6.3 SHA-256 Device Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN=JNJ 2048bit Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN CN=<Unique identifier such as serial number>, OU= Devices, 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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., CP Pointer and User Notice)
Subject Alternative Not Critical, RFC 822 email address = <device email address>, if
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 113 of 145
Name present
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.6.4 1024 Bit SSL Certificate (No Longer Used)
This profile is no longer in use.
12.6.5 2048 Bit SSL Certificate
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 Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN CN=<Server DNS hostname>, OU= Servers, 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
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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) }
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.,
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 114 of 145
CP Pointer and User Notice)
Subject Alternate Name Not critical, dnsName = <Server DNS hostname(s)>
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.6.6 SHA-256 SSL Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN=JNJ 2048bit Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN CN=<Server DNS hostname>, OU= Servers, 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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) }
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., CP Pointer and User Notice)
Subject Alternate Name Not critical, dnsName = <Server DNS hostname(s)>
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 115 of 145
12.6.7 1024 Bit Other Server Certificate (No Longer Used)
This profile is no longer in use.
12.6.8 2048 Bit Other Server Certificate
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 Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN CN=<Server DNS hostname>, OU= Servers, 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
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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) }, IPSEC {1.3.6.1.5.5.8.2.2}
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., CP Pointer and User Notice)
Subject Alternate Name Not critical, Server URL, IP Address, or DNS Name
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 116 of 145
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.6.9 SHA-256 Other Server Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN=JNJ 2048bit Principal Online 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 36 months (YYMMDDHHMMSSZ)
Subject DN CN=<Server DNS hostname>, OU= Servers, 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 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) }, IPSEC {1.3.6.1.5.5.8.2.2}
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., CP Pointer and User Notice)
Subject Alternate Name Not critical, Server URL, IP Address, or DNS Name
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 117 of 145
12.7 TIME STAMP AUTHORITY (TSA) CERTIFICATES
12.7.1 2048 Bit TSA Certificate
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 10 years (YYMMDDHHMMSSZ)
Subject DN CN=<Server DNS hostname>, OU=Time Stamp Authority, OU=Servers, 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
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 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
Critical, { id-pkix kp(3) timestamping(8) }
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
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>
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/rootca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 118 of 145
12.7.2 SHA-256 TSA Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
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 10 years (YYMMDDHHMMSSZ)
Subject DN CN=<Server DNS hostname>, OU=Time Stamp Authority, OU=Servers, 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
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 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
Critical, { id-pkix kp(3) timestamping(8) }
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
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>
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/rootca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 119 of 145
12.8 CODE SIGNING CERTIFICATES
12.8.1 1024 Bit Code Signing Certificate (No Longer Used)
This profile is no longer in use.
12.8.2 2048 Bit Code Signing Certificate
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 Principal Online 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 36 months (YYMMDDHHMMSSZ)
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
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
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 Critical, {id-pkix id-kp(3) id-kp-codesigning (3)}
id-pkix OBJECT IDENTIFIER ::=
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 120 of 145
{ 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 = 8 or 9
Policy Qualifier: Optional; Fields useful to human relying parties (e.g., CP Pointer and User Notice)
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.8.3 SHA-256 Code Signing Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN=JNJ 2048bit Principal Online 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 36 months (YYMMDDHHMMSSZ)
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
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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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 Critical, {id-pkix id-kp(3) id-kp-codesigning (3)}
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 121 of 145
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 = 8 or 9
Policy Qualifier: Optional; Fields useful to human relying parties (e.g., CP Pointer and User Notice)
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.9 OCSP RESPONDER CERTIFICATES
12.9.1 1024 Bit OCSP Responder Certificate (No Longer Used)
This profile is no longer in use.
12.9.2 2048 Bit OCSP Responder Certificate
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 Unique X.500 Issuing CA DN
Validity Period
Not before Time in Zulu (YYMMDDHHMMSSZ)
Not After No more than 45 days after the certificate is available (YYMMDDHHMMSSZ)
Subject DN Unique X.500 OCSP Responder (subject) DN as appropriate
Subject Public Key Information
Algorithm Identifier rsaEncryption, {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
Authority Information Not Critical; id-ad-caIssuers access method entry contains HTTP URL
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 122 of 145
Access for .p7c file containing certificates issued to issuing CA;
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, 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
Subject Alternative Name
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
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN Unique X.500 Issuing CA DN
Validity Period
Not before Time in Zulu (YYMMDDHHMMSSZ)
Not After No more than 45 days after the certificate is available (YYMMDDHHMMSSZ)
Subject DN Unique X.500 OCSP Responder (subject) DN as appropriate
Subject Public Key Information
Algorithm Identifier rsaEncryption, {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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing certificates issued to issuing CA;
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 123 of 145
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, 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
Subject Alternative Name
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)
This profile is no longer in use.
12.10.2 2048 Bit Key Escrow and Recovery Certificate
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 Principal Online 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 3 years (YYMMDDHHMMSSZ)
Subject DN CN=<unique identifier of the usage>, OU= Roles, 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 124 of 145
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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, Key Encipherment
Extended Key Usage Not Critical, Key Recovery Agent(1.3.6.1.4.1.311.21.6)}
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
12.10.3 SHA-256 Key Escrow and Recovery Certificate
Field Value
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Parameters Null
Issuer DN CN=JNJ 2048bit Principal Online 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 3 years (YYMMDDHHMMSSZ)
Subject DN CN=<unique identifier of the usage>, OU= Roles, 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 Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
Authority Information Access
Not Critical; id-ad-caIssuers: http://jjedsdata.jnj.com/polca2048bit.p7c
id-ad-ocsp: http://jjedsocsp1.jnj.com/
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, Key Encipherment
Extended Key Usage Not Critical, Key Recovery Agent(1.3.6.1.4.1.311.21.6)}
CRL Distribution Point Not critical, http://jjedscrl.jnj.com/polca2048bit.crl
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 125 of 145
12.11 CROSS CERTIFICATES
12.11.1 1024 Bit Cross Certificate (No Longer Used)
This profile is no longer in use.
12.11.2 2048 Bit Cross Certificate
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 6 years (YYMMDDHHMMSSZ)
Subject DN Subject CA DN
Subject Public Key Information
Algorithm Identifier rsaEncryption, {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
Public Key n, e (2048 bit or larger 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
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
Key Usage Critical, keyCertSign and cRLSign bits set
Certificate Policies Not Critical, set by PAA
Certificate Policy Mapping
Not Critical, set by PAA, maps to appropriate subject domain policy
Basic Constraints Critical, cA = TRUE, pathLength absent
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 126 of 145
Name Constraints Critical, excludedSubtrees: O=JNJ, C=US13
Policy Constraints Critical; requireExplicitPolicy skipCerts = 0; inhibitPolicyMapping absent.
Authority Information Access
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
Version 2 (version number = 3)
Serial Number Integer
Issuer Signature Algorithm Identifier
Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
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 6 years (YYMMDDHHMMSSZ)
Subject DN Subject CA DN
Subject Public Key Information
Algorithm Identifier rsaEncryption, {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
Public Key n, e (2048 bit or larger modulus)
Signature
Algorithm Identifier Sha256WithRSAEncryption, i.e., iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}
Signature SHA-256 hash encrypted using issuer private key
Extension Extension Value and Criticality
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
Key Usage Critical, keyCertSign and cRLSign bits set
13 The PAA may impose additional permitted and/or excluded subtree constraints.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 127 of 145
Certificate Policies Not Critical, set by PAA
Certificate Policy Mapping
Not Critical, set by PAA, maps to appropriate subject domain policy
Basic Constraints Critical, cA = TRUE, pathLength absent
Name Constraints Critical, excludedSubtrees: O=JNJ, C=US14
Policy Constraints Critical; requireExplicitPolicy skipCerts = 0; inhibitPolicyMapping absent.
Authority Information Access
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.12 CRLS
12.12.1 ORCA CRL
Field Value
Version 1 (version number = 2)
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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 128 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
Authority Key Identifier Not Critical
Key Identifier = Subject Key Identifier in ORCA self-signed certificate
CRL Number Integer (never repeated)
12.12.2 POLCA CRL
Field Value
Version 1 (version number = 2)
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-
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 129 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 130 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 131 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.
http://csrc.nist.gov/publications/fips/index.html
FIPS 186-2 Digital Signature Standard, January 2000.
http://csrc.nist.gov/publications/fips/index.html
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.
http://www.ietf.org/rfc/rfc2459.txt?number=2459
RFC 2510 Certificate Management Protocol, Adams and Farrell, March 1999.
http://www.ietf.org/rfc/rfc2510.txt?number=2510
RFC 3647 Certificate Policy and Certification Practices Framework, Chokhani, Ford,
Sabett, Merrill and Wu, October 2003.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 132 of 145
http://www.ietf.org/rfc/rfc3647.txt?number=3647
RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, Housley, Polk, Ford and Solo, April 2002.
http://www.ietf.org/rfc/rfc3280.txt?number=3280
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 133 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 134 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 135 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 136 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]
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 137 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 138 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 139 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 140 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 141 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 142 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.
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 143 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
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 144 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]
REC-STND-1872 Johnson & Johnson JJEDS X.509 CP Version 7.0
Effective: February 24, 2012
Page 145 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.