Raytheon Company Public Key Infrastructure (PKI) Certificate … · 2020. 3. 30. · Raytheon Company Public Key Infrastructure (PKI) Certification Policy Root Certification Authority

Raytheon Company Public Key Infrastructure (PKI) Certification Policy Root Certification Authority

Approved for Public Release

March 13, 2020 i Version 2.1

3209B

3210BRaytheon Company Public Key Infrastructure (PKI)

Certificate Policy

3208BVersion 2.1

0BMarch 13, 2020



March 13, 2020 ii Version 2.1

492BSignature Page

3212B_____________________________________________ 493BJeffrey C Brown 494BRaytheon Chief Information Security Officer

3213B_____________________________________________ 495BLaura A Kohler 496BRaytheon Policy Management Authority Chair



March 13, 2020 iii Version 2.1

3211BTable of Contents 3214B1 INTRODUCTION ............................................................................................................ 1

3228B1.1 Overview ......................................................................................................................... 2 3321B1.1.1 Certificate Policy (CP) ............................................................................................... 2

3322B1.1.2 Relationship between this CP & the Raytheon CPS ................................................. 3

3323B1.1.3 Scope ........................................................................................................................ 3

3229B1.2 Document Identification ................................................................................................ 6 3230B1.3 PKI Participants ............................................................................................................. 9

3324B1.3.1 PKI Authorities ........................................................................................................... 9

3325B1.3.2 Registration Authority (RA) ...................................................................................... 12

3326B1.3.3 Subscribers ............................................................................................................. 12

3327B1.3.4 Relying Parties ........................................................................................................ 12

3328B1.3.5 Other Participants .................................................................................................... 12

3329B1.3.6 Applicability ............................................................................................................. 13

3231B1.4 Certificate Usage .......................................................................................................... 14 3330B1.4.1 Appropriate Certificate Uses ................................................................................... 14

3331B1.4.2 Prohibited Certificate Uses ...................................................................................... 14

3232B1.5 Policy Administration .................................................................................................. 14 3332B1.5.1 Organization administering the document ............................................................... 14

3333B1.5.2 Contact Person ........................................................................................................ 14

3334B1.5.3 Person Determining Certification Practice Statement Suitability for the Policy ....... 14

3335B1.5.4 CPS Approval Procedures ...................................................................................... 15

3336B1.5.5 Waivers ................................................................................................................... 15

3215B2 PUBLICATION & PKI REPOSITORY RESPONSIBILITIES ................................................... 16

3233B2.1 PKI Repositories .......................................................................................................... 16 3337B2.1.1 Repository Obligations ............................................................................................ 16

3234B2.2 Publication of Certificate Information ........................................................................ 16 3338B2.2.1 Publication of CA Information .................................................................................. 16

3339B2.2.2 Interoperability ......................................................................................................... 16

3235B2.3 Time or Frequency of Publication .............................................................................. 16 3236B2.4 Access Controls on PKI Repositories ....................................................................... 16

3216B3 IDENTIFICATION & AUTHENTICATION ........................................................................... 17

3237B3.1 Naming .......................................................................................................................... 17 3340B3.1.1 Types of Names ...................................................................................................... 17

3341B3.1.2 Need for Names to be Meaningful ........................................................................... 17



March 13, 2020 iv Version 2.1

3342B3.1.3 Anonymity or Pseudonymity of Subscribers ............................................................ 17

3343B3.1.4 Rules for Interpreting Various Name Forms ............................................................ 17

3344B3.1.5 Uniqueness of Names ............................................................................................. 18

3345B3.1.6 Recognition, Authentication & Role of Trademarks ................................................. 18

3346B3.1.7 Name Claim Dispute Resolution Procedure ............................................................ 18

3238B3.2 Initial Identity Validation .............................................................................................. 18 3347B3.2.1 Method to Prove Possession of Private Key ........................................................... 18

3348B3.2.2 Authentication of Organization Identity .................................................................... 18

3349B3.2.3 Authentication of Individual Identity ......................................................................... 19

3350B3.2.4 Non-verified Subscriber Information ........................................................................ 23

3351B3.2.5 Validation of Authority ............................................................................................. 23

3352B3.2.6 Criteria for Interoperation ........................................................................................ 23

3239B3.3 Identification and Authentication for Re-Key Requests ........................................... 23 3353B3.3.1 Identification and Authentication for Routine Re-key .............................................. 24

3354B3.3.2 Identification and Authentication for Re-key after Revocation ................................. 24

3240B3.4 Identification and Authentication for Revocation Request ...................................... 24 3217B4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ............................................ 25

3241B4.1 Certificate Application ................................................................................................. 25 3355B4.1.1 Submission of Certificate Application ...................................................................... 26

3356B4.1.2 Enrollment Process and Responsibilities ................................................................ 26

3242B4.2 Certificate Application Processing ............................................................................ 27 3357B4.2.1 Performing Identification and Authentication Functions .......................................... 27

3358B4.2.2 Approval or Rejection of Certificate Applications .................................................... 27

3359B4.2.3 Time to Process Certificate Applications ................................................................. 27

3243B4.3 Certificate Issuance ..................................................................................................... 27 3360B4.3.1 CA Actions during Certificate Issuance ................................................................... 28

3361B4.3.2 Notification to Subscriber of Certificate Issuance .................................................... 28

3244B4.4 Certificate Acceptance ................................................................................................ 28 3362B4.4.1 Conduct Constituting Certificate Acceptance .......................................................... 28

3363B4.4.2 Publication of the Certificate by the CA ................................................................... 28

3364B4.4.3 Notification of Certificate Issuance by the CA to Other Entities .............................. 28

3245B4.5 Key Pair and Certificate Usage ................................................................................... 29 3365B4.5.1 Subscriber Private Key and Certificate Usage ........................................................ 29

3366B4.5.2 Relying Party Public Key and Certificate Usage ..................................................... 29

3246B4.6 Certificate Renewal ...................................................................................................... 29



March 13, 2020 v Version 2.1

3367B4.6.1 Circumstance for Certificate Renewal ..................................................................... 29

3368B4.6.2 Who may Request Renewal .................................................................................... 29

3369B4.6.3 Processing Certificate Renewal Requests .............................................................. 29

3370B4.6.4 Notification of New Certificate Issuance to Subscriber ............................................ 29

3371B4.6.5 Conduct Constituting Acceptance of a Renewal Certificate .................................... 29

3372B4.6.6 Publication of the Renewal Certificate by the CA .................................................... 29


3247B4.7 Certificate Re-Key ........................................................................................................ 29 3374B4.7.1 Circumstance for Certificate Re-key ........................................................................ 30

3375B4.7.2 Who may Request Certification of a New Public Key .............................................. 30

3376B4.7.3 Processing Certificate Re-keying Requests ............................................................ 30


3378B4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate ................................... 30

3379B4.7.6 Publication of the Re-keyed Certificate by the CA .................................................. 30


3248B4.8 Certificate Modification ............................................................................................... 30 3381B4.8.1 Circumstance for Certificate Modification ................................................................ 31

3382B4.8.2 Who may Request Certificate Modification ............................................................. 31

3383B4.8.3 Processing Certificate Modification Requests ......................................................... 31


3385B4.8.5 Conduct Constituting Acceptance of Modified Certificate ....................................... 31

3386B4.8.6 Publication of the Modified Certificate by the CA .................................................... 31


3249B4.9 Certificate Revocation and Suspension .................................................................... 31 3388B4.9.1 Circumstance for Revocation of a Certificate .......................................................... 32

3389B4.9.2 Who Can Request Revocation of a Certificate ........................................................ 32

3390B4.9.3 Procedure for Revocation Request ......................................................................... 32

3391B4.9.4 Revocation Request Grace Period .......................................................................... 33

3392B4.9.5 Time within which CA must Process the Revocation Request ................................ 33

3393B4.9.6 Revocation Checking Requirements for Relying Parties ......................................... 33

3394B4.9.7 CRL Issuance Frequency ........................................................................................ 34

3395B4.9.8 Maximum Latency for CRLs .................................................................................... 35

3396B4.9.9 Online Revocation Checking Availability ................................................................. 35



March 13, 2020 vi Version 2.1

3397B4.9.10 Online Revocation Checking Requirements ............................................................ 35

3398B4.9.11 Other Forms of Revocation Advertisements Available ............................................ 35

3399B4.9.12 Special Requirements Related To Key Compromise .............................................. 35

3400B4.9.13 Circumstances for Suspension ................................................................................ 36

3401B4.9.14 Who can Request Suspension ................................................................................ 36

3402B4.9.15 Procedure for Suspension Request ........................................................................ 36

3403B4.9.16 Limits on Suspension Period ................................................................................... 36

3250B4.10 Certificate Status Services .......................................................................................... 36 3404B4.10.1 Operational Characteristics ..................................................................................... 36

3405B4.10.2 Service Availability .................................................................................................. 36

3406B4.10.3 Optional Features .................................................................................................... 36

3251B4.11 End Of Subscription .................................................................................................... 36 3252B4.12 Key Escrow and Recovery .......................................................................................... 37

3407B4.12.1 Key Escrow and Recovery Policy and Practices ..................................................... 37

3408B4.12.2 Session Key Encapsulation and Recovery Policy and Practices ............................ 37

3218B5 FACILITY MANAGEMENT & OPERATIONAL CONTROLS .................................................. 38

3253B5.1 Physical Controls ......................................................................................................... 38 3409B5.1.1 Site Location & Construction ................................................................................... 38

3410B5.1.2 Physical Access ...................................................................................................... 38

3411B5.1.3 Power and Air Conditioning ..................................................................................... 39

3412B5.1.4 Water Exposures ..................................................................................................... 39

3413B5.1.5 Fire Prevention & Protection ................................................................................... 39

3414B5.1.6 Media Storage ......................................................................................................... 39

3415B5.1.7 Waste Disposal ....................................................................................................... 39

3416B5.1.8 Off-Site backup ........................................................................................................ 40

3254B5.2 Procedural Controls .................................................................................................... 41 3417B5.2.1 Trusted Roles .......................................................................................................... 41

3418B5.2.2 Number of Persons Required per Task ................................................................... 43

3419B5.2.3 Identification and Authentication for Each Role ....................................................... 43

3420B5.2.4 Roles Requiring Separation of Duties ..................................................................... 43

3255B5.3 Personnel Controls ...................................................................................................... 44 3421B5.3.1 Qualifications, Experience, and Clearance Requirements ...................................... 44

3422B5.3.2 Background Check Procedures ............................................................................... 45

3423B5.3.3 Training Requirements ............................................................................................ 45



March 13, 2020 vii Version 2.1

3424B5.3.4 Retraining Frequency and Requirements ................................................................ 46

3425B5.3.5 Job Rotation Frequency and Sequence .................................................................. 46

3426B5.3.6 Sanctions for Unauthorized Actions ........................................................................ 46

3427B5.3.7 Independent Contractor Requirements ................................................................... 46

3428B5.3.8 Documentation Supplied To Personnel ................................................................... 46

3256B5.4 Audit Logging Procedures .......................................................................................... 46 3429B5.4.1 Types of Events Recorded ...................................................................................... 46

3430B5.4.2 Frequency of Processing Audit Logs ....................................................................... 50

3431B5.4.3 Retention Period for Audit Logs .............................................................................. 50

3432B5.4.4 Protection of Audit Logs .......................................................................................... 50

3433B5.4.5 Audit Log Backup Procedures ................................................................................. 51

3434B5.4.6 Audit Collection System (internal vs. external) ........................................................ 51

3435B5.4.7 Notification to Event-Causing Subject ..................................................................... 51

3436B5.4.8 Vulnerability Assessments ...................................................................................... 51

3257B5.5 Records Archival ......................................................................................................... 51 3437B5.5.1 Types of Records Archived ..................................................................................... 51

3438B5.5.2 Retention Period for Archive ................................................................................... 52

3439B5.5.3 Protection of Archive ............................................................................................... 52

3440B5.5.4 Archive Backup Procedures .................................................................................... 52

3441B5.5.5 Requirements for Time-Stamping of Records ......................................................... 52

3442B5.5.6 Archive Collection System (internal or external) ..................................................... 53

3443B5.5.7 Procedures to Obtain & Verify Archive Information ................................................. 53

3258B5.6 Key Changeover ........................................................................................................... 54 3259B5.7 Compromise and Disaster Recovery ......................................................................... 54

3444B5.7.1 Incident and Compromise Handling Procedures ..................................................... 54

3445B5.7.2 Computing Resources, Software, and/or Data Corruption ...................................... 55

3446B5.7.3 Private Key Compromise Procedures ..................................................................... 56

3447B5.7.4 Business Continuity Capabilities after a Disaster .................................................... 57

3260B5.8 CA, CSA, and RA Termination .................................................................................... 57 3219B6 TECHNICAL SECURITY CONTROLS ............................................................................... 58

3261B6.1 Key Pair Generation and Installation ......................................................................... 58 3448B6.1.1 Key Pair Generation ................................................................................................ 58

3449B6.1.2 Private Key Delivery to Subscriber .......................................................................... 59

3450B6.1.3 Public Key Delivery to Certificate Issuer ................................................................. 59



March 13, 2020 viii Version 2.1

3451B6.1.4 CA Public Key Delivery to Relying Parties .............................................................. 59

3452B6.1.5 Key Sizes ................................................................................................................ 60

3453B6.1.6 Public Key Parameters Generation and Quality Checking ...................................... 61

3454B6.1.7 Key Usage Purposes (as per X.509 v3 key usage field) ......................................... 62

3262B6.2 Private Key Protection and Cryptographic Module Engineering Controls ............ 63 3455B6.2.1 Cryptographic Module Standards and Controls ...................................................... 63

3456B6.2.2 Private Key Multi-Person Control ............................................................................ 63

3457B6.2.3 Private Key Escrow ................................................................................................. 63

3458B6.2.4 Private Key Backup ................................................................................................. 63

3459B6.2.5 Private Key Archival ................................................................................................ 64

3460B6.2.6 Private Key Transfer into or from a Cryptographic Module ..................................... 64

3461B6.2.7 Private Key Storage on Cryptographic Module ....................................................... 64

3462B6.2.8 Method of Activating Private Key ............................................................................ 64

3463B6.2.9 Methods of Deactivating Private Key ...................................................................... 65

3464B6.2.10 Method of Destroying Private Key ........................................................................... 65

3465B6.2.11 Cryptographic Module Rating .................................................................................. 65

3263B6.3 Other Aspects of Key Management ........................................................................... 66 3466B6.3.1 Public Key Archival .................................................................................................. 66

3467B6.3.2 Certificate Operational Periods/Key Usage Periods ................................................ 66

3264B6.4 Activation Data ............................................................................................................. 66 3468B6.4.1 Activation Data Generation and Installation ............................................................ 66

3469B6.4.2 Activation Data Protection ....................................................................................... 66

3470B6.4.3 Other Aspects of Activation Data ............................................................................ 66

3265B6.5 Computer Security Controls ....................................................................................... 67 3471B6.5.1 Specific Computer Security Technical Requirements ............................................. 67

3472B6.5.2 Computer Security Rating ....................................................................................... 67

3266B6.6 Life-Cycle Technical Controls .................................................................................... 67 3473B6.6.1 System Development Controls ................................................................................ 67

3474B6.6.2 Security Management Controls ............................................................................... 68

3475B6.6.3 Life Cycle Security Controls .................................................................................... 68

3267B6.7 Network Security Controls .......................................................................................... 68 3268B6.8 Time Stamping ............................................................................................................. 69

3220B7 CERTIFICATE, CRL AND OCSP PROFILES................................................................... 70

3269B7.1 Certificate Profile ......................................................................................................... 70 3476B7.1.1 Version Numbers ..................................................................................................... 70



March 13, 2020 ix Version 2.1

3477B7.1.2 Certificate Extensions .............................................................................................. 70

3478B7.1.3 Algorithm Object Identifiers ..................................................................................... 70

3479B7.1.4 Name Forms ............................................................................................................ 70

3480B7.1.5 Name Constraints .................................................................................................... 72

3481B7.1.6 Certificate Policy Object Identifier ........................................................................... 72

3482B7.1.7 Usage of Policy Constraints Extension ................................................................... 72

3483B7.1.8 Policy Qualifiers Syntax and Semantics .................................................................. 73

3484B7.1.9 Processing Semantics for the Critical Certificate Policy Extension ......................... 73

3270B7.2 CRL Profile ................................................................................................................... 74 3485B7.2.1 Version Numbers ..................................................................................................... 74

3486B7.2.2 CRL and CRL Entry Extensions .............................................................................. 74

3271B7.3 OCSP Profile ................................................................................................................. 74 3487B7.3.1 Version Number ...................................................................................................... 74

3488B7.3.2 OCSP Extensions .................................................................................................... 74

3221B8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS .......................................................... 75

3272B8.1 Frequency or Circumstances of Assessments ......................................................... 75 3273B8.2 Identity and Qualifications of Assessor .................................................................... 75 3274B8.3 Assessor’s Relationship To Assessed Entity ........................................................... 75 3275B8.4 Topics Covered by Assessment ................................................................................. 75 3276B8.5 Actions Taken as a Result of Deficiency ................................................................... 75 3277B8.6 Communication of Results ......................................................................................... 76

3222B9 OTHER BUSINESS AND LEGAL MATTERS ..................................................................... 77

3278B9.1 Fees ............................................................................................................................... 77 3489B9.1.1 Certificate Issuance and Renewal Fees .................................................................. 77

3490B9.1.2 Certificate Access Fees ........................................................................................... 77

3491B9.1.3 Revocation or Status Information Access Fees ...................................................... 77

3492B9.1.4 Fees for Other Services .......................................................................................... 77

3493B9.1.5 Refund Policy .......................................................................................................... 77

3279B9.2 Financial Responsibility .............................................................................................. 77 3494B9.2.1 Insurance Coverage ................................................................................................ 77

3495B9.2.2 Other Assets ............................................................................................................ 77

3496B9.2.3 Insurance or Warranty Coverage for End-Entities ................................................... 77

3280B9.3 Confidentiality of Business Information .................................................................... 77 3281B9.4 Privacy of Personal Information ................................................................................. 78 3282B9.5 Intellectual Property Rights ........................................................................................ 78

3497B9.5.1 Property Rights in Certificates and Revocation Information .................................... 78



March 13, 2020 x Version 2.1

3498B9.5.2 Property Rights in the CPS ..................................................................................... 78

3499B9.5.3 Property Rights in Names ....................................................................................... 78

3500B9.5.4 Property Rights in Keys ........................................................................................... 78

3283B9.6 Representations and Warranties ................................................................................ 78 3501B9.6.1 CA Representations and Warranties ....................................................................... 79

3502B9.6.2 Subscriber ............................................................................................................... 80

3503B9.6.3 Relying Party ........................................................................................................... 80

3504B9.6.4 Registration Authority .............................................................................................. 80

3505B9.6.5 Representations and Warranties of Other Participants ........................................... 81

3284B9.7 Disclaimers of Warranties ........................................................................................... 81 3285B9.8 Limitations of Liabilities .............................................................................................. 82 3286B9.9 Indemnities ................................................................................................................... 82

3506B9.9.1 Indemnification by Cross Certified CAs ................................................................... 82

3507B9.9.2 Indemnification by Relying Parties .......................................................................... 82

3287B9.10 Term and Termination ................................................................................................. 83 3508B9.10.1 Term ........................................................................................................................ 83

3509B9.10.2 Termination ............................................................................................................. 83

3510B9.10.3 Effect of Termination and Survival .......................................................................... 83

3288B9.11 Individual Notices and Communications with Participants ..................................... 83 3289B9.12 Amendments ................................................................................................................ 84

3511B9.12.1 Procedure for Amendment ...................................................................................... 84

3512B9.12.2 Notification Mechanism and Period ......................................................................... 84

3513B9.12.3 Circumstances under Which OID Must be Changed ............................................... 85

3290B9.13 Dispute Resolution Provisions ................................................................................... 85 3514B9.13.1 Disputes among Raytheon and Customers ............................................................. 85

3515B9.13.2 Alternate Dispute Resolution Provisions ................................................................. 85

3291B9.14 Governing Law ............................................................................................................. 85 3292B9.15 Compliance with Applicable Law ............................................................................... 86 3293B9.16 Miscellaneous Provisions ........................................................................................... 86

3516B9.16.1 Entire Agreement .................................................................................................... 86

3517B9.16.2 Assignment .............................................................................................................. 86

3518B9.16.3 Severability .............................................................................................................. 86

3519B9.16.4 Waiver of Rights ...................................................................................................... 86

3520B9.16.5 Force Majeure ......................................................................................................... 86

3294B9.17 Other Provisions .......................................................................................................... 86 3223B10 CERTIFICATE, CRL, AND OCSP FORMATS ............................................................... 88



March 13, 2020 xi Version 2.1

3295B10.1 Raytheon Root CA CBCA Cross-Certificate ......................................................... 89 3296B10.2 PKCS 10 Request ......................................................................................................... 91 3297B10.3 Raytheon Root CA Certificate (RRCA) ....................................................................... 92 3298B10.4 High Assurance Subscriber Signature Certificate .................................................... 93 3299B10.5 High Assurance Subscriber Encryption Certificate ................................................. 95 3300B10.6 Medium Assurance Signing CA Certificate (MASCA) .............................................. 96 3301B10.7 Medium Assurance Subscriber Signature Certificate .............................................. 98 3302B10.8 Medium Assurance Subscriber Encryption Certificate .......................................... 100 3303B10.9 Medium Assurance Subscriber Authentication Certificate ................................... 102 3304B10.10 ...................................................................... Medium Assurance Code Signing Certificate 103 3305B10.11 .......................................................................... Medium Assurance Application Certificate 105 3306B10.12 ................................................................ Medium Assurance Device or Server Certificate 107 3307B10.13 ............................................................. Medium Assurance Domain Controller Certificate 109 3308B10.14 .................................................................... Medium Assurance Role Signature Certificate 111 3309B10.15 ................................................................. Medium Assurance Role Encryption Certificate 112 3310B10.16 .................................................................................................... OCSP Responder Certificate 114 3311B10.17 ............................................................................................... Raytheon Root CA CRL Format 117 3312B10.18 ....................................................................................... Medium Assurance CA CRL Format 118 3313B10.19 ............................................................................................................... OCSP Request Format 119 3314B10.20 ............................................................................................................ OCSP Response Format 119 3315B10.21 ................................................................................................................... Extended Key Usage 120

3224B11 PKI REPOSITORY INTEROPERABILITY PROFILE ....................................................... 123

3316B11.1 Protocol ...................................................................................................................... 123 3317B11.2 Authentication ............................................................................................................ 123 3318B11.3 Naming ........................................................................................................................ 123 3319B11.4 Object Class ............................................................................................................... 123 3320B11.5 Attributes .................................................................................................................... 124

3225B12 BIBLIOGRAPHY ................................................................................................ 125

3226B13 ACRONYMS & ABBREVIATIONS ..................................................................... 127

3227B14 GLOSSARY ....................................................................................................... 130



March 8, 2019 1 Version 2.1

1 114BINTRODUCTION 497BThis Certificate Policy (CP) governs the operation of a Public Key Infrastructure (PKI) consisting of products and services that provide and manage X.509 certificates for public-key cryptography. Certificates identify the individual named in the certificate, and bind that person to a particular public/private key pair. 498BThis CP defines several certificate policies that represent the test, low-software, low-hardware, medium-software, medium-CBP-software0F

1, medium-device-software, medium-hardware, medium-CBP-hardware, medium-device-hardware, and high-hardware assurance levels for public key certificates. The word “assurance” used in this CP means how well 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 addition, it also reflects how well 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 performs its task. 499BTo assist in the transition from SHA 1 based signatures to SHA 2 based signatures, this CP covers a set of SHA2- policy OIDs for the medium-CBP-software, medium-CBP-hardware, medium-software, medium-hardware, and high levels of assurance. 500BRaytheon plans to operate a Certification Authority (CA) based on the policies in this CP to facilitate cross-certification with the CertiPath Bridge Certification Authority (CBCA) for interoperation among Aerospace PKIs. 501BRaytheon programs require services such as authentication, confidentiality, technical non-repudiation, and access control. These services are met with an array of network security devices such as users, workstations, firewalls, routers, network encryptors, and trusted database servers. The operation of these devices is supported and completed by use of public-key cryptography. As a system solution, the devices share the burden of the total system security. The use of public key certificates does not add any security services in a poorly designed or implemented system. 502BSecurity management services provided by the PKI include:

• 503BKey Generation/Storage/Recovery

• 504BCertificate Generation, Update, Renewal, Re-key, and Distribution

• 505BCertificate Revocation List (CRL) Generation and Distribute

• 506BDirectory Management of Certificate Related Items

• 507BCertificate Update, Renewal, Re-key, and Recovery

• 508BCertificate token initialization/programming/management

• 509BSystem Management functions (e.g. security audit, configuration management, archive, etc.)

1 Note: CBP stands for Commercial Best Practices




510BThe security of these services is ensured by defining requirements on PKI activities, including the following:

• 511BSubscriber identification and authorization verification

• 512BControl of computer and cryptographic systems

• 513BOperation of computer and cryptographic systems

• 514BUsage of keys and public-key certificates by Subscribers and Relying Parties

• 515BDefinition of rules to limit liability and to provide a high degree of certainty that the stipulations of the policies in this CP are being met

516BThe reliability of the public-key cryptography portion of the security solution is a direct result of the secure and trustworthy operation of an established PKI, including equipment, facilities, personnel, and procedures. 517BElectronic commerce is one important PKI application. The use of public key cryptography for electronic commerce applications should be determined on the basis of a review of the security services provided by the public key certificates, the value of the electronic commerce applications, and the risk associated with the applications. The applicability statements in one or more of the policies in this CP shall be considered minimum requirements; application accreditors may require higher levels of assurance than specified in this CP for the stated applications. 518BThis CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework.

1.1 128BOVERVIEW 519BThe Raytheon Certificate Policy (CP) is the unified policy under which all Certification Authorities (CA) operated by Raytheon are established and operate. This document shall be reviewed and updated as described in section 9.12, based on operational experience, changing threats, new technology, and further analysis. 520BThis document defines the creation and management of Version 3 X.509 public-key certificates for use in applications requiring communication between networked computer-based systems. Such applications include, but are not limited to, electronic mail; secure transmission of data; signature of electronic forms; contract formation signatures’ and authentication of infrastructure devices such as web servers, firewalls, and desktops. The intended network backbone for these network security products is the Internet.

1.1.1 221BCertificate Policy (CP) 521BCertificates contain one or more registered certificate policy object identifiers (OID), which may be used by a Relying Party to decide whether a certificate is trusted for a particular purpose. The party that registers the OIDs (in this case, Raytheon Company) also publishes the CP, for examination by Relying Parties. Each OID corresponds to a specific level of assurance established by this Certificate Policy (CP) which shall be available to Relying Parties. 522BEach certificate issued by a Raytheon CA shall assert the appropriate level of assurance in the certificatePolicies extension. Cross certificates issued by the Raytheon Root CA shall, in the




policyMappings extension and in whatever other fashion is determined by the Raytheon Policy Management Authority (described in Section 1.3.1.1) to be necessary for interoperability, reflect what mappings exist between this CP and the cross certified PKI CP.

1.1.2 222BRelationship between this CP & the Raytheon CPS 523BThis Certificate Policy (CP) states what assurance can be placed in a certificate issued by the Raytheon certificate servers. The Certification Practice Statement (CPS) states how the respective certification authorities establish that assurance.

1.1.3 223BScope 524BThe following diagram represents the scope of the Raytheon PKI. The Raytheon Root CA shall cross-certify with the CertiPath Bridge CA. Subscriber certificates shall be issued by the Raytheon Signing CA.




525B

98BFigure 1 – Scope of Raytheon PKI Architecture

526BThis CP imposes requirements on the following Raytheon CAs involved in Signing certificates:

• 2BRaytheon Root Certification Authority (RRCA)




• 3BRaytheon Signing CAs 4BThe Raytheon Root CA shall issue CA certificates only to the following:

• 5BRaytheon CAs approved by the RPMA to issue certificates to subscribers

• 6BExternal CAs approved by the RPMA to cross-certify to the Raytheon PKI 527BThe RRCA may also issue certificates to PKI Trusted Roles who operate the CA. 528BThe scope of this CP in terms of subscriber (i.e., end entity) certificate types is limited to those listed in Section 10 and repeated here: identity, signature, encryption, web server, code signing, role signature, and role encryption. 529BWithin this document, the term CA, when used without qualifier, shall refer to any certification authority subject to the requirements of this certificate policy, including the RRCA and Signing CAs. Requirements that apply to a specific CA type shall be denoted by specify the CA type, e.g., RRCA or Signing CA.




1.2 129BDOCUMENT IDENTIFICATION 530BThere are multiple levels of assurance in this Certificate Policy, which are defined in subsequent sections. Each level of assurance has an OID, to be asserted in certificates issued by the RRCA and the CAs subordinate to the RRCA, which comply with the policy stipulations herein. 531BThe OIDs are registered under the id-infosec arc as follows: 532B{iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) Raytheon(1569) pki(10) certificate-policy(1)}

533Bid-raytheon 534B::= 1.3.6.1.4.1.1569

535Bid-pki 536B::= { id-Raytheon - 10}

537Bid-certificate-policy 538B::= { id-pki - 1}

539Bid-raytheon-high 540B::= {Raytheon-certificate-policy - 1}

541Bid-raytheon-mediumHardware 542B::= {Raytheon-certificate-policy - 2}

543Bid-raytheon-mediumSoftware 544B::= {Raytheon-certificate-policy - 3}

545Bid-raytheon-mediumCBPHardware 546B::= {Raytheon-certificate-policy - 4}

547Bid-raytheon-mediumCBPSoftware 548B::= {Raytheon-certificate-policy - 5}

549Bid-raytheon-lowHardware 550B::= {Raytheon-certificate-policy - 6}

551Bid-raytheon-lowSoftware 552B::= {Raytheon-certificate-policy - 7}

553Bid-raytheon-medium-device-Hardware 554B::= {Raytheon-certificate-policy - 8}

555Bid-raytheon-medium-device-Software 556B::= {Raytheon-certificate-policy - 9}

557Bid-raytheon-SHA2-high 558B::= {Raytheon-certificate-policy - 11}

559Bid-raytheon-SHA2-mediumHardware 560B::= {Raytheon-certificate-policy - 12}

561Bid-raytheon-SHA2-mediumSoftware 562B::= {Raytheon-certificate-policy - 13}

563Bid-raytheon-SHA2-mediumCBPHardware 564B::= {Raytheon-certificate-policy - 14}

565Bid-raytheon-SHA2-mediumCBPSoftware 566B::= {Raytheon-certificate-policy - 15}




567Bid-raytheon-SHA2-lowHardware 568B::= {Raytheon-certificate-policy - 16}

569Bid-raytheon-SHA2-lowSoftware 570B::= {Raytheon-certificate-policy - 17}

571Bid-raytheon-SHA2-medium-device-Hardware 572B::= {Raytheon-certificate-policy - 18}

573Bid-raytheon-SHA2-medium-device-Software 574B::= {Raytheon-certificate-policy - 19}

575Bid-raytheon-test 576B::= {Raytheon-certificate-policy 20}

577BUnless otherwise stated, a requirement stated in this CP applies to all assurance levels. 578BThe requirements associated with CBP (commercial best practice) assurance levels are identical to the corresponding non-CBP assurance level with the exception of trusted role personnel citizenship requirements (see section 5.3.1). 579BAll of the requirements for “id-raytheon-SHA2…..” are the same as those for the corresponding certificate policy OID without “SHA2-” in it except that the CAs not asserting “id-raytheon-SHA2…..” may use SHA-1 for generation of PKI objects such as certificates, Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses after December 31, 2010. For example:

1. 488BThe CAs asserting id-raytheon-SHA2-highHardware must meet all the highHardware requirements stipulated in this CP;

2. 489BThe CAs asserting id-raytheon-SHA2-mediumHardware must meet all the mediumHardware requirements stipulated in this CP;

3. 490BThe CAs asserting id-raytheon-SHA2-mediumHardware use at least SHA-256 for end entity certificates issued after December 31, 2010; and

4. 491BThe CAs asserting id-raytheon-mediumHardware may use SHA-1 for end entity certificates issued after December 31, 2010.

580BThe requirements associated with the “id-raytheon-medium-device. . .” and “id-raytheon-SHA2-medium-device. . .” policies are identical to those defined for other medium assurance policies with the exception of identity proofing, backup and activation data. The use of these policies is restricted to devices and systems (e.g. software applications and hardware devices). Certificates issued to end-entity devices after October 1, 2016 shall assert one or more of the following policies: id-raytheon-SHA2-medium-device-Hardware, id-raytheon-SHA2-medium-device-Software, id-raytheon-medium-device-Hardware, or id-raytheon- medium-deviceSoftware. Other devices (such as content signers, OCSP responders, etc.) may assert appropriate policy OIDs. 581BThe requirements associated with the Medium CBP Software (commercial best practice) Assurance policy are identical to those defined for the Medium Software Assurance policy; with the exception of personnel security requirements (see Section 5.3.1).




582BThe requirements associated with the Medium CBP Hardware Assurance policy are identical to those defined for the Medium Hardware Assurance policy; with the exception of personnel security requirements (see Section 5.3.1). 583BThe Raytheon Root CA may issue certificates to other subordinate CAs, but the subordinate CAs must assert one of the certificate policies listed above.. 584BThe low assurance policy is for internal Raytheon company use only. This certificate shall not be trusted by any external entity. The low assurance certificate registration process will not be via In Person Authentication, but rather uses the Raytheon Corporate Directory Services for authentication per corporate policy. 585BThe test assurance policy is for issuance of test certificates that shall not be trusted by any relying party.




1.3 130BPKI PARTICIPANTS 586BThis section contains a description of the roles relevant to the administration and operation of the RRCA and Signing CAs.

1.3.1 224BPKI Authorities

1.3.1.1 421BRaytheon Policy Management Authority (RPMA) 587BThe Raytheon PMA is responsible for:

• 7BOverseeing the creation and update of the Raytheon Certificate Policies, including evaluation of changes requested by Raytheon businesses and/or programs, and oversee plans for implementing any accepted changes;

• 8BProviding timely and responsive coordination to approved Raytheon CAs;

• 9BReviewing the Certification Practice Statements (CPS) of Raytheon operated CAs that provide services meeting the stipulations of this CP;

• 10BReviewing the results of CA compliance audits to determine if the CAs are adequately meeting the stipulations of this CP and associated approved CPS documents, and make recommendations to the CAs regarding corrective actions, or other measures that might be appropriate, such as revocation of CA certificates or changes to this CP;

• 11BAccepting applications from CAs desiring to interoperate with the Raytheon PKI;

• 12BAccepting applications from Subject CAs desiring to cross certify with the Raytheon PKI;

• 13BDetermining the mappings between certificates issued by applicant CAs and the levels of assurance set forth in this CP (which shall include objective and subjective evaluation of the respective CP contents and any other facts deemed relevant by the RPMA);

• 588BProviding notification of changes that have the potential to affect their operational environments to cross certified entities at least two (2) weeks prior to implementation, and;

• 14BEnsuring continued conformance of all CAs approved by the RPMA for interoperation with the RRCA.

589BIn addition to the responsibilities listed above, the RPMA provides recommendations regarding the oversight and policy compliance of the Raytheon PKI to the Raytheon Chief Information Security Officer (CISO). The final authority for the Raytheon PKI resides with the CISO as described in the RPMA Charter. 590BA complete description of RPMA roles and responsibilities are provided in the RPMA Charter. 591BIn the event the RRCA cross-certifies with another Entity CA, Raytheon shall enter into a Memorandum of Agreement (MOA), or equivalent agreement with an organization, setting forth the respective responsibilities and obligations of both parties, and the mappings between the certificate levels of assurance contained in this CP and those in the Entity CP. The Raytheon PMA shall consult Raytheon Supply Chain prior to entering into a MOA. The term “MOA” as used in this CP shall always refer to the Agreement cited in this paragraph.




1.3.1.2 422BRaytheon Operational Authority (ROA) 592BThe Raytheon Operational Authority is the organization that operates the RRCA and the Signing CAs, including issuing certificates when directed by the RPMA Chair, posting those certificates, Certificate Revocation Lists (CRLs) into the Raytheon PKI Repository, and ensuring the continued availability of the PKI Repository to all users. The Operational Authority acts upon approval of the PMA. The ROA activities are subject to review by the RPMA in order to ensure compliance with this CP and applicable CPS.

1.3.1.3 Raytheon Operational Authority Manager 593BThe Raytheon Operational Authority Manager is the individual within the Raytheon corporate management who has principal responsibility for overseeing the proper operation of the Raytheon CAs including the Raytheon PKI Repository, and who oversees the appointment of the Operational Authority staff. The Manager is a voting member of the RPMA and participates in oversight of the Raytheon PKI.

1.3.1.4 424BRaytheon Operational Authority Officers 594BThese officers are the individuals within the Operational Authority, selected by the Manager, who operate the Raytheon CAs and the Raytheon PKI Repository including executing the RPMA direction to issue and revoke certificates to CAs1F

2 or taking other action to effect interoperability between the RRCA and CBCA. The Operational Authority roles include the Administrator, Officer, Auditor, and Operator, are all described in Section 5.2.1 of this CP.

1.3.1.5 425BCertification Authority (CA) 595BA Certification Authority is an entity authorized by the RPMA to create, sign, and issue public key certificates. A CA is responsible for all aspects of the issuance and management of a certificate, including control over the registration process, the identification and authentication process, the certificate manufacturing process, publication of certificates, revocation of certificates, and re-key; and for ensuring that all aspects of the CA services and CA operations and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP. CA is an inclusive term, and includes all types of CAs. Any CA requirement expressed in this CP applies to all CA types unless expressly stated otherwise.

1.3.1.5.1 452BPrincipal CA (PCA) 596BThe Principal CA (PCA) is a CA within a PKI that has been designated to interoperate directly with the CBCA (e.g., through the exchange of cross-certificates). It should be noted that an Entity may request that the CBCA interoperate with more than one CA within the Entity; that is, an Entity may have more than one Principal CA. A PCA may or may not be a Root CA (trust anchor) for its PKI Enterprise.

1.3.1.5.2 453BRoot CA

2 RRCA issues cross certificates to the PCAs. RRCA issues Signing CA certificates to the Enterprise CAs who want to operate under the Raytheon Root CA.




597BA Root CA is a trust anchor for subscribers of a PKI domain when the subscribers act as a relying party. In the Raytheon PKI, the Root CA acts as the PCA and trust anchor for the Raytheon relying parties. The Raytheon Root CA shall be an offline CA.

1.3.1.5.3 454BIntermediate CA 598BAn Intermediate CA is a CA that is not a Root CA and whose primary function is to issue certificates to other CAs. Intermediate CAs may or may not issue some end entity certificates. In the Raytheon PKI, there is no Intermediate CA.

1.3.1.5.4 455BSigning CA 599BA Signing CA is a CA whose primary function is to issue certificates to the end entities. A Signing CA does not issue certificates to other CAs.

1.3.1.5.5 456BCross Certified CA 600BA Cross Certified CA is an organization that is operating a CA that has cross-certified with Raytheon through the Raytheon Root CA (RRCA).

1.3.1.6 426BCertificate Status Authority (CSA) 601BA CSA is an authority that provides status of certificates or certification paths. A CSA can be operated in conjunction with the CAs or independent of the CAs. Examples of CSA are:

• 602BOnline Certificate Status Protocol (OCSP) Responders that provide revocation status of certificates.

• 603BSimple Certificate Validation Protocol (SCVP) Servers that validate certifications paths or provide revocation status checking services2F

3. 604BOCSP Responders that are keyless and simply repeat responses signed by other Responders and SCVP Servers that do not provide certificate validation services adhere to the same security requirements as repositories.

1.3.1.7 427BCertificate Management Authorities (CMA) 605BBoth Certification Authorities and Registration Authorities (RA) are “Certificate Management Authorities” (CMAs). This CP shall use the term CMA when a function may be assigned to either a CA or a RA, or when a requirement applies to both CAs and RAs. The term Registration Authority includes entities such as Local Registration Authorities. The division of Subscriber registration responsibilities between the CA and RA may vary among implementations of this certificate policy. This division of responsibilities shall be described in the applicable CPS. 606BCSAs operated by Raytheon or issued certificates by Raytheon PKI are also considered CMAs.

3 There are three types of SCVP Servers: path development, path validation with revocation checking, and path validation without revocation checking. The path development servers are not considered within the scope of this policy since the corruption of these servers does not adversely impact security and hence they need not be subject of a CP.




1.3.2 225BRegistration Authority (RA) 607BA Registration Authority (RA) is the entity that collects and verifies each Subscribers’ identity and the information that is to be entered into his or her public key certificates. An RA interacts with the CA to enter and approve the subscriber certificate request information. The Raytheon Operational Authority acts as the RA for the Raytheon CAs. The RA performs its function in accordance with a CPS approved by the RPMA.

1.3.3 226BSubscribers 608BA Subscriber is the entity whose name appears as the subject in an end-entity certificate, and who agrees to use its key and certificate in accordance with the certificate policy asserted in the certificate, and does not itself issue certificates. The targeted Raytheon PKI Subscribers include, but are not limited to, the following categories of entities that may wish to communicate securely and have demonstrated a bona fide need for a PKI certificate:

• 15BRaytheon employees and eligible contractors;

• 16BRaytheon business partners – customer, partner, supplier;

• 17BNon-US personnel and eligible contractors; and

• 18BWorkstations, applications, firewalls, routers, and network encryptors, trusted servers (e.g., database, FTP, and WWW), and other infrastructure devices. These devices must be under the cognizance of humans, to accept the certificate and are responsible for the correct protection and use of the associated private key.

19BCAs 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.

1.3.4 227BRelying Parties 609BA Relying Party is the entity that relies on the validity of the binding of the Subscriber's name to a public key. The Relying Party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. The Relying Party can use the certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the holder of the certificate. A Relying Party may use information in the certificate (such as certificate policy identifiers) to determine the suitability of the certificate for a particular use.

1.3.5 228BOther Participants

1.3.5.1 428BRelated Authorities 610BThe Raytheon Root CA and Signing CAs operating under this CP shall require the services of other security, community, and application authorities, such as compliance auditors and attribute authorities. 611BThe Root CPS shall identify the parties responsible for providing such services and the mechanisms used to support these services. 612BThe Signing CA CPS shall identify the parties responsible for providing such services to the Root CA, and the mechanisms used to support these services.




1.3.5.2 429BTrusted Agent 613BA Trusted Agent is the entity that collects and verifies each Subscriber’s identity and information on behalf of an RA. A Trusted Agent does not have privileged access to the CA to enter or approve subscriber information.

1.3.6 229BApplicability 614BThe sensitivity of the information processed or protected using certificates issued by Raytheon CAs shall vary significantly. Relying Party Entities must evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity or significance of the information. This evaluation is performed by each Entity for each application and is not controlled by this CP. 615BTo provide sufficient granularity, this CP specifies security requirements for the assurance levels listed in Section 1.2. 616BThe certificate levels of assurance contained in this CP are set forth below, as well as a brief and non-binding description of the applicability for applications suited to each level.

617BAssurance Level 618BApplicability

619BMedium-software or Medium-CBP-software

620BThis level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial. Subscriber private keys are stored in software at this assurance level.

621BMedium-hardware or Medium-CBP-hardware

622BThis level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial. Subscriber private keys are stored in hardware at this assurance level.

623BHigh-hardware 624BThis level is relevant to environments where risks and consequences of data compromise are high. This may include transactions having high monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is high. Subscriber private keys are stored in hardware at this assurance level.

1.3.6.1 430BFactors in Determining Usage 625BThe Relying Party must first determine the level of assurance required for an application, and then select the certificate appropriate for meeting the needs of that application. This shall 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 and are not controlled by the RPMA or the Raytheon Operational Authority. Nonetheless, this CP contains some helpful guidance, set forth herein, which Relying Parties may consider in making their decisions.

1.3.6.2 431BObtaining Certificates 626BThis CP requires publication and access to CA certificates and CRLs. This CP imposes no requirements in terms of publication and access to end entity (i.e., subscriber) certificates. The relying party applications must make their own agreements for obtaining the subscriber certificates. This could be trivially done for signature applications by including the signer certificate in the application protocol. For encryption applications, the relying party must develop a means to access subscriber certificates. Use of X.500 and LDAP Repositories is one way to achieve this, but this CP does not mandate which mechanism a Relying Party must use.

1.4 131BCERTIFICATE USAGE

1.4.1 230BAppropriate Certificate Uses 627BCertificates asserting a Policy OID defined in this document shall only be used for transactions related to Raytheon business in accordance with Raytheon policy. CAs must state this requirement in their CPS and impose a requirement on Subscribers to abide by this limitation.

1.4.2 231BProhibited Certificate Uses 628BSee section 1.4.1 above.

1.5 132BPOLICY ADMINISTRATION

1.5.1 232BOrganization administering the document 629BThe Raytheon PMA shall review and provide recommendations to the Raytheon CISO for this CP. The Raytheon CISO is responsible for all aspects of this CP.

1.5.2 233BContact Person 2476BQuestions regarding this CP shall be directed to the Chair of the RPMA. The current RPMA Chair can be found at: 2477Bhttp://www.raytheon.com/pki/rpma/ or via email at [email protected].

1.5.3 234BPerson Determining Certification Practice Statement Suitability for the Policy

630BThe RPMA shall approve the Raytheon CPS. The Raytheon CPS must conform to the corresponding Certificate Policy. 631BThe determination of suitability shall be based on an independent compliance assessor’s results and recommendations. The compliance assessor shall be from a firm, which is independent from the entity being audited. The compliance assessor may not be the author of this CP or the subject CPS. The RPMA shall determine whether a compliance assessor meets these requirements. (See Section 8 for complete assessor requirements).

http://www.raytheon.com/pki/rpma/




1.5.4 235BCPS Approval Procedures 632BThe term CPS is defined in the Internet RFC 3647, 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. The Raytheon CPS which is contained in a separate document published by the Raytheon Operational Authority and approved by the RPMA, specifies how this CP and any Agreements that the RPMA has approved shall be implemented to ensure compliance with their provisions.

1.5.5 236BWaivers 633BThere shall be no waivers to this CP.




2 115BPUBLICATION & PKI REPOSITORY RESPONSIBILITIES

2.1 133BPKI REPOSITORIES 634BThe Raytheon PKI repository shall be available over the Internet to the CertiPath relying parties. The PKI Repositories shall contain the information necessary to support interoperation of the Entity PKI domains that employ the CertiPath CAs for this purpose.

2.1.1 237BRepository Obligations 635BThe Raytheon Operational Authority may use a variety of mechanisms for posting information into PKI repositories as required by this CP. These mechanisms at a minimum shall include:

• 20BAvailability of the information as required by the certificate information posting and retrieval stipulations of this CP;

• 21BAccess control mechanisms sufficient to protect repository information as described in later Sections.

• 22BContain the information necessary to support interoperation of the Raytheon PKI with the CBCA.

2.2 134BPUBLICATION OF CERTIFICATE INFORMATION

2.2.1 238BPublication of CA Information 636BAll Raytheon CAs, at a minimum, shall post CA certificates and CRLs. 637BThe PKI Repositories containing certificates and certificate status information shall be deployed so as to provide 24 hour per day / 365 day per year availability. Raytheon shall implement features to provide high levels of PKI Repository reliability (99% availability or better).

2.2.2 239BInteroperability 638BNo Stipulation beyond Section 2.1.

2.3 135BTIME OR FREQUENCY OF PUBLICATION 639BCertificates and certificate status information shall be published as specified in this CP in Section 4.4.2 and Section 4.9.7.

2.4 136BACCESS CONTROLS ON PKI REPOSITORIES 640BAny PKI Repository information not intended for public dissemination or modification shall be protected. Public keys and certificate status information in the Raytheon PKI Repository shall be publicly available through the Internet.




3 116BIDENTIFICATION & AUTHENTICATION

3.1 137BNAMING

3.1.1 240BTypes of Names 641BThe CAs shall generate and sign certificates containing an X.500 Distinguished Name (DN) in the Issuer and in Subject fields; the X.500 DN may contain domain component elements. Alternative Subject Name may be used, if marked non-critical.

3.1.2 241BNeed for Names to be Meaningful 642BThe 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 or object to which they are assigned in a meaningful way. 643BAll DNs shall accurately reflect organizational structures. When User Principal Name (UPN) is used, it shall be unique and accurately reflect organizational structure. 644BWhen DNs are used, it is preferable that the common name represents the subscriber in a way that is easily understandable for humans. For people, this will typically be a legal name. For equipment, this may be a model name and serial number, or an application process. The CA shall use DNs in certificates it issues. When DNs are used, the common name must respect name space uniqueness requirements and must not be misleading. This does not preclude the use of pseudonymous certificates as defined in Section 3.1.3. 645BThe CAs asserting one or more of the policies in this CP shall only sign certificates with subject names from within a name-space approved by the RPMA. In the case where one CA certifies another CA, the certifying CA must impose restrictions on the name space authorized in the subordinate CA, which are at least as restrictive as its own name constraints. 646BRaytheon reserves the right to assert name constraints in CA certificates issued by the Raytheon CA in order to limit the name space of the subject CAs to name spaces that are appropriate for subject CA domains.

3.1.3 242BAnonymity or Pseudonymity of Subscribers 647BA Raytheon CA shall not issue anonymous certificates. Raytheon CA certificates shall not contain anonymous or pseudonymous identities. 648BDNs in certificates issued to end entities may contain a pseudonym to meet local privacy regulations as long as name space uniqueness requirements are met and as long as such name is unique and traceable to the actual entity.

3.1.4 243BRules for Interpreting Various Name Forms 649BRules for interpreting name forms are contained in the applicable certificate profile. The Raytheon Operational Authority (ROA) shall be the authority responsible for CA name control space.




3.1.5 244BUniqueness of Names 650BName uniqueness across the Raytheon domains, including cross-certified domains shall be enforced. The CAs and RAs shall enforce name uniqueness within the X.500 name space, which they have been authorized. 651BThe ROA shall be responsible for ensuring name uniqueness in certificates issued by the Raytheon CAs. 652BRaytheon CAs shall include the following information in their CPS:

• 23BWhat name forms shall be used, and • 24BHow they will allocate names within the Subscriber community to guarantee name

uniqueness among current and past Subscribers (e.g., if “Joe Smith” leaves a CA’s community of Subscribers, and a new, different “Joe Smith” enters the community of Subscribers, how will these two people be provided unique names?).

3.1.6 245BRecognition, Authentication & Role of Trademarks 653BA Raytheon CMA is not required to issue a name that contains a requested trademark. A CMA shall not knowingly issue a certificate including a name and may withdraw an issued name, where a court of competent jurisdiction has determined the name in question infringes the trademark of another. A CMA is not subsequently required to issue a name containing a trademark if the CMA has already issued a name sufficient for identification within Raytheon. A CMA is not obligated to research trademarks or resolve trademark disputes.

3.1.7 246BName Claim Dispute Resolution Procedure 654BThe ROA shall resolve any name collisions brought to its attention that may affect interoperability.

3.2 138BINITIAL IDENTITY VALIDATION

3.2.1 247BMethod to Prove Possession of Private Key 655BIn all cases where the Subscriber generates keys, the Subscriber shall be required to prove possession of the private key that corresponds to the public key in the certificate request. For signature keys, this proof of possession may be done by signing the request. For encryption keys, the CA or RA may encrypt the Subscriber’s certificate in a confirmation request message. The Subscriber can then decrypt and return the certificate to the CA or RA in a confirmation message. The RPMA may allow other mechanisms that are at least as secure as those cited here to be acceptable.

3.2.2 248BAuthentication of Organization Identity 656BRequests for cross certificates in the name of an organization shall include the CA name, address, and documentation of the existence of the CA. Before issuing cross certificates, the issuing CA shall verify the information provided, in addition to the authenticity of the requesting representative, and that representative's authorization to act in the name of the CA.




3.2.3 249BAuthentication of Individual Identity 657BThe Raytheon CA or an RA shall ensure that the applicant’s identity information is verified and checked in accordance with this CP and the applicable CPS. The CA or RA shall ensure that the applicant’s identity information and public key are properly bound. Additionally, the CA or RA shall record the process that was followed for issuance of each certificate. Process information shall depend upon the certificate level of assurance and shall be addressed in the applicable CPS. The process documentation and authentication requirements shall include the following:

• 25BThe identity of the person performing the identity verification;

• 26BA signed declaration by that person that he or she verified the identity of the applicant as required by the applicable certificate policy which may be met by establishing how the applicant is known to the verifier as required by this certificate policy, using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law; The signature on the declaration may be either a handwritten or digital signature using a certificate that is of equal or higher level of assurance as the credential being issued;

• 27BThe applicant shall present one valid National Government-issued photo ID (e.g. passport), or two valid non-National Government IDs, one of which shall be a recent photo ID (e.g., Drivers License).

• 28BUnique identifying numbers from the ID of the verifier and from an ID of the applicant;

• 29BThe date and time of the verification, and;

• 30BA declaration of identity signed by the applicant using a handwritten signature or appropriate digital signature and performed in the presence of the person performing the identity authentication, using the format set forth at 28 U.S.C 1746 (declaration under penalty of perjury) or comparable procedure under local law. 31BPractice Note: For example: signatures equivalent to a handwritten signature include a good fingerprint or other adequate biometric that can be linked to the individual identity or a digital signature that can be verified using a certificate provided to the same identity. In the latter case, the certificate must not be the same certificate for whose issuance the identity proofing is being performed.

32BIn the event an applicant is denied a credential based on the results of the identity proofing process, the applicant shall be given an opportunity to provide additional identity documentation prior to final rejection. 658BIdentity shall be established by in-person or supervised remote3F

4 identity proofing before the RA or Trusted Agent; information provided shall be verified to ensure legitimacy. Requirements for authentication of individual identity using an in-person antecedent are listed in Section 3.2.3.3.

4 Supervised Remote Identity proofing must be implemented in a manner that conforms to Section 5.3.3.2 of NIST SP 800-63A Digital Identity Guidelines: Enrollment and Identity Proofing, dated June 2017. Future changes to NIST SP 800-63A will be reviewed for consideration by the PMA.




3.2.3.1 432BAuthentication of Device Identities 659BSome computing and communications devices (applications, routers, firewalls, servers, etc.) shall be named as certificate subjects. In such cases, the device shall have a human PKI Sponsor. The human PKI Sponsor should have been issued a credential that is equal to or higher assurance level than the credential being sponsored. The human PKI sponsor shall be responsible for providing the following registration information:

• 33BEquipment identification (e.g., serial number) or service name (e.g., DNS name)

• 34BEquipment public keys

• 35BEquipment authorizations and attributes (if any are to be included in the certificate)

• 36BContact information to enable the CA or RA to communicate with the sponsor when required

• 37BThe registration information provided by the human PKI sponsor 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: o 38BVerification of digitally signed messages sent from the sponsor (using certificates

of equivalent or greater assurance than that being requested). o 39BIn person registration by the sponsor, with the identity of the sponsor confirmed

in accordance with the requirements of Section 3.2.3. 40BIn the event a human sponsor is changed, the new sponsor shall review the status of each device under his/her sponsorship to ensure it is still authorized to receive certificates. The CPS shall describe procedures to ensure that certificate accountability is maintained.

3.2.3.2 433BHuman Subscriber Re-Authentication following loss, damage, or key compromise

660BIf a human subscriber credentials containing the private keys associated with the public key certificates are lost, damaged, or stolen, the subscriber may be issued new certificates using the process described in this section. However, the validity period of the certificates issued using this process shall not exceed the identity-reproofing requirements in Section 3.3.1. Alternatively, the subscriber can undergo an initial identity proofing process described in Section 3.2.3. 661BThe CA or RA shall ensure that the subscriber’s identity information and public key are properly bound. Additionally, the CA or RA shall record the process that was followed for issuance of each certificate. Process information shall depend upon the certificate level of assurance and shall be addressed in the applicable CPS. The process documentation and authentication requirements shall include the following:

• 662BThe identity of the person performing the identity verification;

• 663BA signed declaration by that person that he or she verified the identity of the subscriber as required by the applicable certificate policy which may be met by establishing how the subscriber is known to the verifier as required by this certificate policy;




• 664BThe subscriber shall present one valid National Government-issued photo ID (e.g. passport) or valid non-National Government issued photo ID (e.g., Drivers License).

• 665BUnique identifying numbers from the Identifier (ID) of the verifier and from the ID of the subscriber;

• 666BMatch a good fingerprint or other adequate biometric from the subscriber with the biometric stored in an authoritative trusted database. This database shall be protected as stipulated in Section 4.3 of this CP.

• 667BThe date and time of the verification; and

• 668BA declaration of identity signed by the applicant using a handwritten signature or appropriate digital signature equivalent and performed in the presence of the person performing the identity authentication, using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law.

669BIn addition, if the credentials are lost, stolen or otherwise unaccounted for, all certificates associated with the private keys on the credentials shall be revoked for the reason of key compromise. This CP also requires that when a certificate is revoked for the reason of key compromise, the derivative certificates (i.e., certificates issued on the basis of the compromised certificate) also be revoked.

3.2.3.3 434BHuman Subscriber Initial Identity Proofing Via Antecedent Relationship

670BThe following requirements shall apply when human subscriber identity is verified using antecedent relationship with the Sponsor:

1. 671BCertificate Applicant shall personally appear before an RA or a Trusted agent; 2. 672BThe Certificate Applicant and the Identity Verifier (i.e., RA and Trusted Agent) shall have

an established working4F

5 relationship with the Certificate Sponsor (i.e. Raytheon Company). The relationship shall be sufficient enough to enable the Identity Verifier to, with a high degree of certainty, verify that the Certificate Applicant is the same person that was identity proofed. An example to meet this requirement is when the Certificate Applicant, RA, and Trusted Agents are employed by the same company and the company badge forms the basis for the Certificate Applicant authentication;

3. 673BThe Certificate Applicant shall present a valid Raytheon Company issued badge. This photo ID shall have been issued on the basis of in-person identity proofing using one valid Federal Government-issued Picture I.D. (e.g. Passport), or two valid Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Drivers License);

4. 674BThe Identity Verifier shall record the following: a) 675BHis/her own identity;

5 An example of “established working relationship” is the person is employed by the Certificate Sponsor (i.e. Raytheon Company). Another example of an “established working relationship” is the person is employed as a contractor of the Certificate Sponsor (i.e. Raytheon Company).




b) 676BUnique identifying number from the Identifier (ID) of the Identity Verifier; c) 677BUnique identifying number from the Certificate Sponsor-issued photo ID to the

Certificate Applicant; d) 678BDate and time of the identity verification; and e) 679BDate and time of Sponsor-issued photo ID, if applicable.

5. 680BThe Identity Verifier shall sign a declaration that he or she verified the identity of the Certificate Applicant as required by the applicable certificate policy which may be met by establishing how the Certificate Applicant is known to the Identity Verifier as required by this certificate policy; and

6. 681BThe Certificate Applicant shall sign a declaration of identity using a handwritten signature or appropriate digital signature using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law. This declaration shall be signed in the presence of the Identity Verifier.

3.2.3.4 435BAuthentication of Human Subscriber for Role Certificates 682BSubscribers may be issued role certificates. A role certificate shall identify a specific role title on behalf of which the subscriber is authorized to act rather than the subscriber’s name. A role certificate can be used in situations where non-repudiation is desired. A role certificate shall not be a substitute for an individual subscriber certificate. Multiple subscribers can be assigned to a role at the same time, however, the signature key pair shall be unique to each role certificate issued to each individual; the encryption key pair and encryption certificate may be shared by the individuals assigned the role. 683BSubscribers issued role certificates shall protect the corresponding role credentials in the same manner as individual credentials. 684BThe procedures for issuing role certificates shall comply with all other stipulations of this CP (e.g., subscriber identity proofing, validation of organization affiliation, key generation, private key protection, and Subscriber obligations). For the role signature certificate, the individual assigned the role or the role sponsor may act on behalf of the certificate subject for certificate management activities such as renewal, re-key and revocation. Issuance and modification of role signature certificate shall require the approval of the role sponsor. Rekey and renewal of role signature certificate shall require the approval of the role sponsor if the validity period is extended beyond that already approved by the role sponsor. For the role encryption certificate, only the role sponsor may act on behalf of the certificate subject for certificate management activities such as issuance, renewal, re-key, modification, and revocation. 685BThe CA or RA shall record the information identified in Section 3.2.3 for a sponsor associated with the role before issuing a role certificate. The sponsor shall hold an individual certificate in his/her own name issued by the same CA at the same or higher assurance level as the role certificate. The CA or RA shall validate from the role sponsor that the individual subscriber has been approved for the role certificate. 686BThe role sponsor (which is not a trusted role) shall be responsible for:

1. 687BAuthorizing individuals for a role certificate; 2. 688BRecovery of the private decryption key




3. 689BRevocation of individual role certificates; 4. 690BAlways maintaining a current up-to-date list of individuals who are assigned the role;

and 5. 691BAlways maintaining a current up-to-date list of individuals who have been provided the

decryption private key for the role. 692BPractice Note: When determining whether a role certificate is warranted, consider whether the role carries inherent authority beyond the job title. Role certificates may also be used for individuals on temporary assignment, where the temporary assignment carries an authority not shared by the individuals in their usual occupation, for example: “Chair PKI Process Action Team”.

3.2.4 250BNon-verified Subscriber Information 693BInformation that is not verified shall not be included in Certificates.

3.2.5 251BValidation of Authority 694BAn Issuer CA shall validate the subject CA certificate requestor's authorization to act in the name of the Subject CA prior to issuing a cross certificate or subordinate certificate. In addition, Raytheon CAs shall obtain the RPMA approval prior to issuing CA certificates. In the case of the RRCA, the certificate issuance shall be based on successful mapping of the Subject CA CP with this CP. In the case of the Signing CA, certificate issuance shall be based upon a successful CPS compliance analysis and the RPMA approval. 695BCertificates that contain explicit or implicit organization affiliations shall be issued only after ascertaining the applicant has the authorizations to act on behalf of the organization in the asserted capacity.

3.2.6 252BCriteria for Interoperation 696BRaytheon CAs implementing this CP shall certify other CAs (including cross-certification) only as authorized by the Raytheon CISO. An Entity CA shall adhere to the following requirements before being reviewed by the RPMA and recommended for cross-certification to the Raytheon CISO:

• 41BHave a CP mapped to, and determined by the RPMA to be in conformance with this CP;

• 42BOperate a PKI that has undergone a successful compliance audit pursuant to Section 8 of this CP and as set forth in the Subject CA CP;

• 43BIssue certificates compliant with the profiles described in this CP, and make certificate status information available in compliance with this CP; and

• 44BProvide CA certificate and certificate status information available to the relying parties.

3.3 139BIDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS 697BThe longer and more often a key is used, the more susceptible it is to loss or discovery. This weakens the assurance provided to a Relying Party that the unique binding between a key and its named Subscriber is valid. Therefore, it is important that a Subscriber periodically obtains




new keys and re-establishes its identity. Re-keying a certificate means that a new certificate is created that is identical to the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key); a different serial number; and may be assigned a different validity period.

3.3.1 253BIdentification and Authentication for Routine Re-key 698BThe CA and subscribers shall be authenticated through use of their current public Key certificates or by using the initial identity-proofing process as described in Section 3.2. For high-hardware and high-CBP-hardware assurance certificates, identity shall be established through the initial identity-proofing process at least once every three (3) years. For end entities with medium-software, medium-device-software, medium-CBP-software, medium hardware, medium-device-hardware, and medium-CBP-hardware assurance certificates, identity shall be established through the initial identity-proofing process at least once every nine (9) years only. 699BIf it has been more than three years since a CA was identified as required in Section 3.2, identity shall be re-established through the initial registration process. 700BWhen a current Signing key is used for identification and authentication purposes, the expiration date of the new certificate shall not cause the certificate subject to exceed the initial identity-proofing time frames specified in the paragraph above, and the assurance level of the new certificate shall not exceed the assurance level of the certificate being used for identification and authentication purposes.

3.3.2 254BIdentification and Authentication for Re-key after Revocation 701BIf a certificate has been revoked, the certificate subject shall be authenticated using the initial identity-proofing process as described in Section 3.2, unless he/she can be authenticated through the use of a valid public key certificate of equal or higher assurance, as specified in Section 3.3.1.

3.4 140BIDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST 702BRevocation requests shall be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated public key, regardless of whether or not the private key has been compromised.




4 117BCERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 703BCommunication among the CA, RA, Trusted Agent, other parties confirming identities, and subscribers shall have requisite security services (i.e., source authentication, integrity, non-repudiation, or confidentiality) applied to them commensurate with the assurance level of the certificate being managed. For example, packages secured and transported in a tamper-evident manner by a certified mail carrier meet the integrity and confidentiality requirements for the High Hardware assurance level. When cryptography is used, the mechanism shall be at least as strong as the certificates being managed. For example, a web site secured using a SSL certificate issued under medium-software policy and set up with appropriate algorithms and key sizes satisfies integrity and confidentiality requirements for medium-software certificate management. 704BThe content of the communication shall dictate if some, all, or none of the security services are required.

4.1 141BCERTIFICATE APPLICATION 705BIt is the intent of this section to identify the minimum requirements and procedures that are necessary to support trust in the PKI, and to minimize imposition of specific implementation requirements on CAs, RAs, Subscribers, and relying parties. 706BThis paragraph applies to entities seeking cross certificates from the Raytheon Root CA. The RPMA establishes procedures for entities to use in applying for a certificate from the RRCA and shall publish those procedures. Additional requirements for the enrollment process for cross-certified CAs shall be discussed in an MOA signed with Raytheon. 707BRequests by Raytheon CAs for a CA certificate shall be submitted to the RPMA using the contact provided in Section 1.5. The application shall be accompanied by a CP and/or CPS written to the format of the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [RFC 3647]. Additionally, the application shall propose a mapping between the levels of assurance expressed in the Entity’s CP and those in this CP. 708BThe RPMA shall evaluate the submitted application for acceptability; make a determination whether or not to issue the requested certificate, and what policy mappings to express in the certificate. The RPMA may require an initial compliance audit, performed by parties of the RPMA’s choosing, to ensure that the CA is prepared to implement all aspects of the CPS, prior to the RPMA authorizing the CA to issue and manage certificates asserting the Raytheon CP. 709BUpon RPMA approval, Raytheon shall enter into a MOA with the applicant organization setting forth their respective responsibilities. The RPMA Chair shall instruct the Raytheon Operational Authority to issue the certificate to the applicant CA. Upon issuance, each certificate issued by the ROA shall be manually checked to ensure each field and extension is properly populated with the correct information, before the certificate is delivered to the Subject CA. The applicant CA shall have a distinguished name that shall be placed in the Subject field of the certificate with the common name as the official name of the CA. 710BRaytheon CAs asserting one or more policy OIDs from this CP shall certify other Raytheon CAs only as authorized by the RPMA. This authorization shall be based on the Subject CA submitting a CPS that complies with this CP.




711BFor subscriber certificates, the CA, RA or Trusted Agent must perform the following steps when the subscriber applies for a certificate:

• 45BEstablish and record identity of Subscriber (per Section 3.2), and;

• 46BEstablish that the public key forms a functioning key pair with the private key held by the Subscriber (per Section 3.2.1).

712BFor subscriber certificates, the prospective subscriber must perform the following steps when the subscriber applies for a certificate:

• 47BObtain a public/private key pair for each certificate required, and;

• 48BProvide a point of contact for verification of any roles or authorizations requested. 713BThese steps may be performed in any order that is convenient for the CA, RAs, Trusted Agent and Subscribers, and that do not defeat security, but all must be completed prior to certificate issuance. All communications among CAs 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 Medium Assurance certificates shall be protected using Medium Assurance certificates, or some other mechanism of equivalent 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 255BSubmission of Certificate Application 714BFor certificate applications to a Raytheon CA, an authorized representative of the Subject CA shall submit the application to the RPMA. 715BFor subscriber certificates, the application shall be submitted by an authorized prospective subscriber in the case of human subscribers, or an authorized PKI sponsor in the case of components.

4.1.2 256BEnrollment Process and Responsibilities 716BCAs external to the Raytheon policy domain applying for cross certification with the Raytheon PKI shall submit a request for cross-certification to the Raytheon PMA accompanied by their CP. The Raytheon PMA shall require a CP/CPS compliance audit, from a third-party auditor, as described in section 8. The Raytheon PMA shall perform a certificate policy mapping to validate policy assurance levels are equivalent. Upon issuance, each cross-certificate issued by the Raytheon PKI shall be manually checked to ensure each field and extension is properly populated with the correct information, before the certificate is delivered to the Subject CA.

49BRaytheon CAs shall submit a request to the Raytheon PMA, accompanied by their CPS. The Raytheon PMA shall evaluate the submitted CPS for acceptability. The Raytheon PMA may require an initial compliance audit, performed by parties of the Raytheon PMA’s choosing, to ensure that the CA is in compliance with this CP, prior to the PMA authorizing the Raytheon Root CA to issue a certificate to the applying CA and authorizing the CA to issue and manage certificates asserting a policy OID from this CP.




50BThe RRCA shall only issue certificates to subordinate CAs upon receipt of written authorization from the Raytheon PMA.

51BCAs shall issue certificates asserting a policy OID from this CP only upon receipt of written authorization from the Raytheon PMA, and then may do so only within the constraints imposed by the Raytheon PMA or its designated representatives.

52BFor applications by end-entities, the Trusted Agent or Registration Authority must verify all subscriber information, in accordance with section 3.2.3. In addition, the Trusted Agent or Registration Authority shall sign the Subscriber Agreement. Subscribers are expected to present proof of identity to Trusted Agents or Registration Authorities, to agree to the Subscriber Agreement, and to sign it with a handwritten signature.

4.2 142BCERTIFICATE APPLICATION PROCESSING 717BIt is the responsibility of the CA and RA to verify that the information in certificate applications is accurate. The CPS shall specify procedures to verify information in certificate applications.

4.2.1 257BPerforming Identification and Authentication Functions 718BFor the cross-certificate issued by the RRCA, the identification and authentication of the applicant representing the Entity CA shall be performed by the Raytheon Operational Authority. 719BFor the Raytheon CAs, the identification and authentication of the applicant representing the Raytheon CA shall be performed by the Raytheon Operational Authority. 720BFor end entity certificates issued by the Raytheon Signing CA, the identification and authentication of the Subscriber must meet the requirements specified for Subscriber authentication as specified in Sections 3.2 and 3.3 of this CP. 721BPrior to certificate issuance, a Subscriber shall be required to sign a document detailing Subscriber responsibility, which must include the requirement that the Subscriber shall protect the private key and use the certificate and private key for authorized purposes only.

4.2.2 258BApproval or Rejection of Certificate Applications 722BFor a CA certificate application, the RPMA may approve or reject a certificate application. 723BFor subscriber certificates, the Trusted Agent, RA or CA may approve or reject a certificate application.

4.2.3 259BTime to Process Certificate Applications 724BThe entire subscriber registration process (i.e., from initial application to identity proofing to certificate issuance) shall not exceed 30 days. 725BNo stipulation for the CA application registration process.

4.3 143BCERTIFICATE ISSUANCE 726BUpon receiving a request for a certificate, the CA or RA shall respond in accordance with the requirements set forth in this CP and the applicable CPS. 727BThe certificate request may contain an already built ("to-be-signed") certificate. This certificate shall not be signed until the process set forth in this CP and the applicable CPS has been met.




728BWhile the Subscriber may do most of the data entry for a certificate, it is still the responsibility of the CA and the RA to verify that the information is correct and accurate. This may be accomplished through a system approach linking trusted databases containing personnel information, other equivalent authenticated mechanisms, or through personal contact with the Subscriber’s sponsoring organization. If databases are used to confirm Subscriber information, then these databases must be protected from unauthorized modification to a level commensurate with the level of assurance of the certificate being sought. Specifically, the databases shall be protected using physical security controls, personnel security controls, cryptographic security controls, computer security controls, and network security controls specified for the RA elsewhere in this CP.

4.3.1 260BCA Actions during Certificate Issuance 729BA CA verifies the source of a certificate request before issuance. Certificates shall be checked to ensure that all fields and extensions are properly populated. After generation, verification, and acceptance, a CA shall post the certificate as set forth in this CP.

4.3.2 261BNotification to Subscriber of Certificate Issuance 730BThe CA shall notify the subject (CA or Subscriber) of certificate issuance.

4.4 144BCERTIFICATE ACCEPTANCE 731BThe Agreement shall be executed setting forth the responsibilities of all parties before the RPMA Chair authorizes issuance of a cross certificate by a Raytheon CA. Once a CA certificate has been issued, its acceptance by the subject shall trigger the Subject CA's obligations under the Agreement (if any) and this CP.

4.4.1 262BConduct Constituting Certificate Acceptance 732BFor CAs cross certified with Raytheon, certificate acceptance shall be governed by the Agreement between Raytheon and the representatives of the Cross-certified CA. 733BFor Raytheon CAs operating under this policy, notification to the CA shall constitute acceptance, unless the CA objects. In the case of objection, the certificate shall be revoked. 734BFor end-entities, downloading of the certificate shall constitute acceptance of the issued certificate.

4.4.2 263BPublication of the Certificate by the CA 735BCA certificates and Subscriber certificates shall be published to the appropriate repositories.

4.4.3 264BNotification of Certificate Issuance by the CA to Other Entities 736BThe ROA shall inform the RPMA of any CA certificate issued by the Raytheon PKI. 737BWhen the Raytheon Root CA issues a CA certification, the RPMA shall inform the CertiPath PMA of successful certification issuance. 738BNotification of cross certificate issuance by the Raytheon Root CA shall be provided to all cross-certified entities. 739BFor Entity CAs, the RPMA shall be notified upon issuance of new CA certificates. In addition, the new CA certificate(s) shall be provided to the RPMA.




4.5 145BKEY PAIR AND CERTIFICATE USAGE

4.5.1 265BSubscriber Private Key and Certificate Usage 740BSubscribers and CAs shall protect their private keys from access by any other party. 741BSubscribers and CAs shall use their private keys for the intended purposes as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates issued to them.

4.5.2 266BRelying Party Public Key and Certificate Usage 742BRelying parties shall accept public key certificates and associated public keys for the purposes intended as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates.

4.6 146BCERTIFICATE RENEWAL 743BRaytheon does not support certificate renewal.

4.6.1 267BCircumstance for Certificate Renewal 744BNot applicable.

4.6.2 268BWho may Request Renewal 745BNot applicable.

4.6.3 269BProcessing Certificate Renewal Requests 53BNot applicable.

4.6.4 270BNotification of New Certificate Issuance to Subscriber 746BNot applicable.

4.6.5 271BConduct Constituting Acceptance of a Renewal Certificate 747BNot applicable.

4.6.6 272BPublication of the Renewal Certificate by the CA 748BNot applicable.

4.6.7 273BNotification of Certificate Issuance by the CA to Other Entities 749BNot applicable.

4.7 147BCERTIFICATE RE-KEY 750BThe 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 obtains new keys and reestablishes its identity. Re-keying a certificate means that a new certificate is created that has the same characteristics and level as the old one, except that the new certificate has a new, different public key (corresponding to a new, different private key) and a different serial number, and it




may be assigned a different validity period. After certificate rekey, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

4.7.1 274BCircumstance for Certificate Re-key 751BA CA may issue a new certificate to the Subject when the Subject has generated a new key pair and is entitled to a certificate.

4.7.2 275BWho may Request Certification of a New Public Key 752BA Subject may request the re-key of its certificate. 753BA PKI Sponsor may request re-key of a component certificate.

4.7.3 276BProcessing Certificate Re-keying Requests 754BA certificate re-key shall be achieved using one of the following processes:

• 755BInitial registration process as described in Section 3.2; or

• 756BIdentification & Authentication for Re-key as described in Section 3.3. 757BFor cross certificates issued by a Raytheon CA, certificate re-key also requires that a valid Agreement exists between Raytheon and the cross certified PKI, and the term of the Agreement is beyond the expiry period for the new certificate.

4.7.4 277BNotification of New Certificate Issuance to Subscriber 758BSee Section 4.3.2.

4.7.5 278BConduct Constituting Acceptance of a Re-keyed Certificate 759BSee Section 4.4.1.

4.7.6 279BPublication of the Re-keyed Certificate by the CA 760BSee Section 4.4.2.

4.7.7 280BNotification of Certificate Issuance by the CA to Other Entities 761BSee Section 4.4.3.

4.8 148BCERTIFICATE MODIFICATION 762BUpdating a certificate means creating a new certificate that has the same or a different key and a different serial number, and that it differs in one or more other fields, from the old certificate. 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 must not be further re-keyed, renewed, or updated. 763BFurther, if an individual’s name changes (e.g., due to marriage), then proof of the name change must be provided to the Registration Authority or Trusted Agent in order for an updated certificate having the new name to be issued.




4.8.1 281BCircumstance for Certificate Modification 764BA CA may issue a new certificate to the Subject when some of the Subject information has changed, e.g., name change due to change in marital status, change in subject attributes, etc., and the Subject continues to be entitled to a certificate.

4.8.2 282BWho may Request Certificate Modification 765BA Subject may request modification of its certificate. 766BA PKI Sponsor may request modification of a device certificate.

4.8.3 283BProcessing Certificate Modification Requests 767BA certificate modification shall be achieved using one of the following processes:

• 768BInitial registration process as described in Section 3.2; or

• 769BIdentification & Authentication for Re-key as described in Section 3.3. In addition, the validation of the changed subject information shall be in accordance with the initial identity-proofing process as described in Section 3.2.

770BFor cross certificates issued by a Raytheon CA, certificate re-key also requires that a valid Agreement exists between Raytheon and the cross certified PKI, and the term of the Agreement is beyond the expiry period for the new certificate.

4.8.4 284BNotification of New Certificate Issuance to Subscriber 771BSee Section 4.3.2.

4.8.5 285BConduct Constituting Acceptance of Modified Certificate 772BSee Section 4.4.1.

4.8.6 286BPublication of the Modified Certificate by the CA 773BSee Section 4.4.2.

4.8.7 287BNotification of Certificate Issuance by the CA to Other Entities 774BSee Section 4.4.3.

4.9 149BCERTIFICATE REVOCATION AND SUSPENSION 775BRevocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated public key, regardless of whether or not the private key has been compromised.

776BRaytheon shall notify all cross certified entities at least two weeks prior to the revocation of a CA certificate, whenever possible. 777BFor Entity CAs, the RPMA shall be notified at least two weeks prior to the revocation of a CA certificate, whenever possible. 778BFor emergency revocation, CAs shall follow the notification procedures in Section 5.7.




4.9.1 288BCircumstance for Revocation of a Certificate 779BA certificate shall be revoked when the binding between the subject and the subject’s public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding are:

• 54BIdentifying information or affiliation components of any names in the certificate become invalid;

• 55BPrivilege attributes asserted in the Subject's certificate are reduced;

• 56BThe Subject can be shown to have violated the stipulations of its agreement;

• 57BThe private key is suspected of compromise; or

• 58BThe Subject or other authorized party (as defined in the applicable CP or CPS) asks for his/her certificate to be revoked.

780BWhenever any of the above circumstances occur, the associated certificate shall be revoked and placed on the CRL. Revoked certificates shall be included on all new publications of the certificate status information until at least the certificates expire. 781BIn addition, if it is determined subsequent to issuance of new certificates that a private key used to sign requests for one or more additional certificates may have been compromised at the time the requests for additional certificates were made, all certificates authorized by directly or indirectly chaining back to that compromised key shall be revoked. 782BThe Raytheon PKI shall request the CBCA revoke their cross-certificate if it does not meet the stipulations of the certificate policies listed in the cross certificate, including all OIDs asserted in this CP.

4.9.2 289BWho Can Request Revocation of a Certificate 783BA certificate subject, human supervisor of a human subject, Human Resources (HR) representative for the human subject, security officer for the human subject, PKI Sponsor for a device, Signing CA, or RA may request revocation of a certificate. 784BIn the case of certificates issued by a Raytheon CA, the RPMA may request revocation of a certificate in accordance with its charter. 785BFor CA certificates, authorized individuals representing the CA operations may request revocation of certificates.

4.9.3 290BProcedure for Revocation Request 786BA 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). 787BAny CA may unilaterally revoke another CA certificate it has issued. However, the ROA for a Raytheon CA shall revoke an Entity CA cross certificate only in the case of an emergency. Generally, a certificate shall be revoked based on the subject request, authorized representative of subject request, or RPMA request. 788BUpon receipt of a revocation request, a CA shall authenticate the request and then revoke the certificate. In the case of a CA certificate issued by a Raytheon CA, the ROA shall seek




guidance from the RPMA before revocation of the certificate except when the RPMA is not available and there is an emergency situation such as:

• 59BRequest from the Signing CA for reason of key compromise;

• 60BDetermination by the Raytheon Operational Authority that a Subject CA key is compromised; or

• 61BDetermination by the Raytheon Operational Authority that a Subject CA is in violation of the CP or CPS to a degree that threatens the integrity of the Raytheon PKI.

789BAt the medium-hardware, medium-CBP-hardware, and high-hardware assurance levels, a Subscriber ceasing its relationship with an organization that sponsored the certificate shall, prior to departure, surrender to the organization (through an accountable mechanism) all cryptographic hardware tokens that were issued by or on behalf of the sponsoring organization. The token shall be zeroized or destroyed promptly upon surrender and shall be protected from malicious use between surrender and zeroization or destruction. 790BIf a Subscriber leaves an organization and the hardware tokens cannot be obtained from the Subscriber, then all Subscriber certificates associated with the unretrieved tokens shall be revoked immediately for the reason of key compromise.

4.9.4 291BRevocation Request Grace Period 791BThere is no revocation grace period. Responsible parties must request revocation as soon as they identify the need for revocation.

4.9.5 292BTime within which CA must Process the Revocation Request 792BThe RRCA shall process all revocation requests within six hours of receipt of request. 793BFor Signing CAs, revocation request processing time shall be as specified below:

794BAssurance Level 795BProcessing Time for Revocation Requests

796BMedium Software and 797BMedium CBP Software

798BBefore next CRL is generated unless request is received within 2 hours of CRL generation

799BMedium Hardware and Medium CBP Hardware

800BBefore next CRL is generated unless request is received within 2 hours of CRL generation

801BHigh Hardware 802BWithin six hours of receipt of request

4.9.6 293BRevocation Checking Requirements for Relying Parties 803BUse of revoked certificates could have damaging or catastrophic consequences in certain applications. The matter of how often new revocation data should be obtained is a determination to be made by the Relying Party and the system accreditor. If it is temporarily infeasible to obtain revocation information, then the Relying Party must either reject use of the certificate, or make an informed decision to accept the risk, responsibility, and consequences for




using a certificate whose authenticity cannot be guaranteed to the standards of this CP. Such use may occasionally be necessary to meet urgent operational requirements.

4.9.7 294BCRL Issuance Frequency 804BCRLs 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. A CA shall ensure that superseded certificate status information is removed from the PKI Repository upon posting of the latest certificate status information. 805BCertificate 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. PKI participants shall coordinate with the PKI Repositories to which they post certificate status information to reduce latency between creation and availability. 806BThe following table provides CRL issuance frequency requirements for medium-software, medium-CBP-software, medium-hardware, and medium-CBP-hardware assurance certificates.

807BCRL Issuance Frequency

808BRoutine 809BCAs that are off line and do not issue end-entity certificates except for internal operations must issue CRLs at least monthly; At least once every 24 hours for all others

810BLoss or Compromise of Private Key

811BWithin 18 Hours of Notification

812BCA Compromise 813BImmediately, but no later than 18 hours after notification

814BThe following table provides CRL issuance frequency requirements for the high-hardware assurance certificates.

815BCRL Issuance Frequency

816BRoutine 817BAt least monthly for Off-line Roots; At Least once every 24 hours for all others

818BLoss or Compromise of Private Key

819BWithin 6 Hours of Notification

820BCA Compromise 821BImmediately, but no later than six hours after notification

822BPractice note: The monthly CRL issuance occurs within the same general timeframe month to month.




823BThe CAs that issue routine CRLs less frequently than the requirement for Emergency CRL issuance (i.e., CRL issuance for loss or compromise of key or for compromise of CA) shall meet the requirements specified above for issuing Emergency CRLs. Such CAs shall also be required to notify the Raytheon PMA upon Emergency CRL issuance. The Raytheon PMA shall in turn notify the CertiPath Operational Authority and all cross certified CAs of revocation. 824BFor off line Root and Bridge CAs that do not issue end-entity certificates except for internal operations, the nextUpdate shall be less than or equal to thisUpdate plus 45 days. 825BFor all other CAs, the nextUpdate shall be less than or equal to thisUpdate plus 168 hours.

4.9.8 295BMaximum Latency for CRLs 826BThe maximum delay between the time a Subscriber certificate is revoked by a CA and the time that this revocation information is available to Relying Parties shall be no greater than 24 hours.

4.9.9 296BOnline Revocation Checking Availability 827BIn addition to CRLs, CAs and Relying Party client software may optionally support online status checking. Client software using online status checking need not obtain or process CRLs. 828BCSAs shall function in a manner that ensures that:

• 62BAccurate and up-to-date information from the authorized CA is used to provide the revocation status;

• 63BRevocation status responses provide authentication and integrity services commensurate with the assurance level of the certificate being checked.

829BIf online revocation/status checking is supported by a CA, the latency of certificate status information distributed online by the CA or its delegated status responders shall meet or exceed the requirements for CRL issuance as stated in 4.9.7.

4.9.10 297BOnline Revocation Checking Requirements

4.9.11 298BRelying Parties are not required to utilize OCSP. If a Relying Party relies on OCSP, it should do so in accordance with the requirements in RFC 6960.Other Forms of Revocation Advertisements Available

830BAny alternate forms used to disseminate revocation information shall be implemented in a manner consistent with the security and latency requirements for the implementation of CRLs and online revocation and status checking.

4.9.11.1 436BChecking Requirements for Other Forms of Revocation Advertisements

831BNo stipulation.

4.9.12 299BSpecial Requirements Related To Key Compromise 832BNone beyond those stipulated in Section 4.9.7.




4.9.13 Circumstances for Suspension 833BSuspension may be permitted for certificates issued under the medium-hardware or medium-CBP-hardware policies only, in the event that a user’s token is temporarily unavailable to them.

4.9.14 Who can Request Suspension 834BA human subscriber, human supervisor of a human subscriber, HR person for the human subscriber, issuing CA, or RA may request suspension of a certificate.

4.9.15 Procedure for Suspension Request 835BA request to suspend a certificate shall identify the certificate to be suspended, explain the reason for suspension, and allow the request to be authenticated (e.g., digitally or manually signed). 836BThe reason code CRL entry extension shall be populated with “certificateHold”.

4.9.16 Limits on Suspension Period 837BA certificate may only be suspended for up to 14 days. If the subscriber has not removed the certificate from hold (suspension) within that period, the certificate shall be revoked for reason of “Key Compromise”. 838BIn order to mitigate the threat of unauthorized person removing the certificate from hold, the subscriber identity shall be authenticated in person using initial identity proofing process described in Section 3.2.3 or using the Human Subscriber Re-Authentication process described in Section 3.2.3.2.

4.10 150BCERTIFICATE STATUS SERVICES 839BThe Raytheon PKI is not required to support certificate status services such as SCVP.

4.10.1 304BOperational Characteristics 840BAny operational characteristics of a CSA shall be described in the CSA’s CPS.

4.10.2 Service Availability 841BRelying Parties are bound to their obligations and the stipulations of this CP irrespective of the availability of the certificate status service.

4.10.3 Optional Features 842BNo stipulation.

4.11 151BEND OF SUBSCRIPTION 843BSubscription is synonymous with the certificate validity period. The subscription ends when the certificate is revoked or expired. 844BFor certificates that have expired prior to or upon end of subscription revocation is not required. Unexpired CA certificates shall always be revoked at the end of the subscription.




4.12 152BKEY ESCROW AND RECOVERY

4.12.1 307BKey Escrow and Recovery Policy and Practices 845BUnder no circumstances shall a CA or end entity signature key be escrowed by a third party. 846BRaytheon’s key escrow and recovery capability shall be governed by the CertiPath Key Recovery Policy (KRP). The method, procedures and controls which will apply to the storage, request for extraction and/or retrieval, delivery protection and destruction of the requested copy of an escrowed key shall be described in the Raytheon Key Recovery Practice Statement (KRPS).

4.12.2 Session Key Encapsulation and Recovery Policy and Practices 847BThis CP neither requires nor prohibits the Raytheon PKI having the capability to recover session keys. If session keys are recoverable, a Key Recovery Policy (KRP) and a Key Recovery Practices Statement (KRPS) shall be developed.




5 118BFACILITY MANAGEMENT & OPERATIONAL CONTROLS

5.1 153BPHYSICAL CONTROLS

5.1.1 309BSite Location & Construction 848BThe location and construction of the facility housing CA 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 equipment and records.

5.1.2 310BPhysical Access

5.1.2.1 437BCA Physical Access 849BCA and CSA equipment shall always be protected from unauthorized access. The physical security requirements pertaining to CA and CSA equipment are:

• 850BEnsure no unauthorized access to the hardware is permitted

• 851BEnsure all removable media and paper containing sensitive plain-text information is stored in secure containers

• 852BEnsure manual or electronic monitoring for unauthorized intrusion at all times

• 853BEnsure an access log is maintained and inspected periodically

• 854BProvide at least three layers of increasing security such as perimeter, building, and CA enclosure

• 855BRequire two person physical access control to both the cryptographic module and computer system.

856BRemovable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic modules, and the activation information used to access or enable cryptographic modules 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. 857BA security check of the facility housing the CA equipment shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following:

• 858BThe 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”);

• 859BFor off-line CAs, all equipment other than the PKI Repository, is shut down;

• 860BAny security containers are properly secured;

• 861BPhysical security systems (e.g., door locks, vent covers) are functioning properly; and

• 862BThe area is secured against unauthorized access.




863BA person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time, and asserts that all necessary physical protection mechanisms are in place and activated.

5.1.2.2 438BRA Physical Access 864BRA equipment shall be protected from unauthorized access while the RA cryptographic module is installed and activated. The RA shall implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated. These security mechanisms shall be commensurate with the level of threat in the RA equipment environment.

5.1.3 311BPower and Air Conditioning 865BThe facility, which houses the CA equipment, shall be supplied with power and air conditioning sufficient to create a reliable operating environment. 866BCA equipment shall have or be provided with sufficient back-up power to execute a standard shutdown (including locking out input, finishing any pending actions, and recording the state of the equipment) before lack of primary power or air conditioning causes the CA equipment to cease functioning. PKI Repositories shall be provided with Uninterrupted Power sufficient for a minimum of six hours operation in the absence of commercial power, to support continuity of operations.

5.1.4 312BWater Exposures 2478BCA equipment shall be installed such that it is not in danger of exposure to water (e.g., on tables or elevated floors). Water exposure from fire prevention and protection measures (e.g. sprinkler systems) are excluded from this requirement. A description of the CA and RA approach for recovery from an exposure to water shall be included in the Disaster Recovery Plan required by Section 5.7.4.

5.1.5 313BFire Prevention & Protection 867BA description of the CA and RA approach for recovery from a fire disaster shall be included in the Disaster Recovery Plan required by Section 5.7.4.

5.1.6 314BMedia Storage 868BCA media shall be stored so as to protect it from accidental damage (water, fire, electromagnetic), theft, and unauthorized access. Media that contains audit, archive, or backup information shall be duplicated and stored in a location separate from the CA equipment.

5.1.7 315BWaste Disposal 869BSensitive waste material shall be disposed off in a secure fashion. 870BMedia used to collect or transmit information discussed in Section 9.4 shall be destroyed, such that the information is unrecoverable, prior to disposal.




5.1.8 316BOff-Site backup 871BFull system backups of the CAs, sufficient to recover from system failure, shall be made on a periodic schedule, described in the respective CPS. Full backups shall be performed and stored off-site not less than once every 7 days, unless the CA is off-line, in which case, it shall be backed up whenever it is activated or every 7 days, whichever is later. At least one full backup copy shall be stored at an offsite location (at a location separate from the CA equipment). Only the latest full backup need be retained. The backup shall be stored at a site with physical and procedural controls commensurate with that of the operational CA.




5.2 154BPROCEDURAL CONTROLS

5.2.1 317BTrusted Roles 872BA 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 can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion. 873BThe requirements of this policy are drawn in terms of four roles (Note: the information derives from the Certificate Issuing and Management Components (CIMC) Protection Profile):

1. 874BAdministrator – authorized to install, configure, and maintain the CA; establish and maintain user accounts; configure profiles and audit parameters; and generate component keys.

2. 875BOfficer – authorized to request or approve certificates or certificate revocations. 3. 876BAudit Administrator – authorized to view and maintain audit logs. 4. 877BOperator – authorized to perform system backup and recovery.

878BThe following sections define these and other trusted roles.

5.2.1.1 439BAdministrator 460BThe Administrator shall be responsible for:

• 461BInstallation, configuration, and maintenance of the CA;

• 462BEstablishing and maintaining CA system accounts;

• 463BConfiguring certificate profiles or templates and audit parameters, and;

• 464BGenerating and backing up CA keys.

• 465BAdministrators shall not issue certificates to subscribers.

5.2.1.2 440BOfficer 466BThe Officer shall be responsible for issuing certificates, that is:

• 467BRegistering new subscribers and requesting the issuance of certificates;

• 468BVerifying the identity of subscribers and accuracy of information included in certificates;

• 469BApproving and executing the issuance of certificates, and;

• 470BRequesting, approving and executing the revocation of certificates.

5.2.1.3 441BAudit Administrator 471BThe Audit Administrator shall be responsible for:

• 472BReviewing, maintaining, and archiving audit logs;




• 473BPerforming or overseeing internal compliance audits to ensure that the CA is operating in accordance with its CPS;

5.2.1.4 442BOperator 879BThe operator shall be responsible for the routine operation of the CA equipment and operations such as system backups and recovery or changing recording media.

5.2.1.5 443BRegistration Authority (RA) 474BAn RA’s responsibilities are:

• 880BVerifying identity, pursuant to Section 3.2;

• 881BEntering Subscriber information, and verifying correctness;

• 882BSecurely communicating requests to and responses from the CA;

• 883BReceiving and distributing Subscriber certificates. 884BThe RA role is highly dependent on public key infrastructure implementations and local requirements. The responsibilities and controls for RAs shall be explicitly described in the CPS of a CA if the CA uses an RA.

5.2.1.6 444BCertificate Status Authority (CSA) Roles 885BA CSA shall require at least the following roles. 475BThe CSA administrator shall be responsible for:

• 476BInstallation, configuration, and maintenance of the CSA;

• 477BEstablishing and maintaining CSA system accounts;

• 478BConfiguring CSA application and audit parameters, and;

• 479BGenerating and backing up CSA keys. 480BThe CSA Audit Administrator shall be responsible for:

• 481BReviewing, maintaining, and archiving audit logs;

• 482BPerforming or overseeing internal compliance audits to ensure that the CSA is operating in accordance with its CPS;

886BThe operator shall be responsible for the routine operation of the CSA equipment and operations such as system backups and recovery or changing recording media.

5.2.1.7 445BPKI Sponsor 887BA PKI Sponsor fills the role of a Subscriber for non-human system devices that are named as public key certificate subjects. The PKI Sponsor works with the RAs to register devices (applications, routers, firewalls, etc.) in accordance with Section 3.2.3.3, and is responsible for meeting the obligations of Subscribers as defined throughout this document. 888BA PKI Sponsor need not be a Trusted Role, but should have been issued a credential that is equal to or higher assurance level than the credential that they are sponsoring.




5.2.1.8 446BTrusted Agent 889BA Trusted Agent is responsible for:

• 890BVerifying identity, pursuant to Section 3.2; and

• 891BSecurity communicating subscriber information to the RA.

5.2.2 318BNumber of Persons Required per Task 892BTwo or more persons shall be required to perform the following tasks:

• 893BCA,CSA key generation;

• 894BCA,CSA signing key activation;

• 895BCA,CSA private key backup. 896BWhere multiparty control is required, at least one of the participants shall be an Administrator. All participants shall serve in a trusted role as defined in Section 5.2.1. 897BMultiparty control shall not be achieved using personnel that serve in the Audit Administrator Role. 898BIt is recommended that multiple persons are assigned to all roles in order to support continuity of operations.

5.2.3 319BIdentification and Authentication for Each Role 899BAn individual in a trusted role shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity. 900BAn individual in a trusted role shall authenticate to remote components of the PKI using a method commensurate with the strength of the PKI.

5.2.4 320BRoles Requiring Separation of Duties 901BRole separation, when required as set forth below, may be enforced either by the CA equipment, or procedurally, or by both means. 902BIndividual CA and CSA personnel shall be specifically designated to the four roles defined in Section 5.2.1 above, as applicable. Individuals may assume more than one role, except:

• 903BIndividuals who assume an Officer role may not assume an Administrator or Audit Administrator role;

• 904BIndividuals who assume an Audit Administrator role shall not assume any other role; and

• 905BUnder no circumstances shall any of the four roles perform its own compliance auditor function.

906BNo individual in a trusted role shall be assigned more than one identity.




5.3 155BPERSONNEL CONTROLS

5.3.1 321BQualifications, Experience, and Clearance Requirements 907BA group of individuals responsible and accountable for the operation of each CA and CSA shall be identified and assigned to trusted roles per Section 5.2.1. 908BAll persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity, and shall be subject to a background investigation. Personnel appointed to trusted roles (including CA trusted roles, CSA trusted roles, Trusted Agent, and RA role) shall:

• 909BHave successfully completed an appropriate training program;

• 910BHave demonstrated the ability to perform their duties;

• 911BBe trustworthy;

• 912BHave no other duties that would interfere or conflict with their duties for the trusted role;

• 913BHave not been previously relieved of duties for reasons of negligence or non-performance of duties;

• 914BHave not been denied a security clearance, nor had a security clearance revoked for cause;

• 915BHave not been convicted of a felony offense; and

• 916BBe appointed in writing by an approving authority. 917BPractice Note: In order to make the determination if a person was denied clearance or had clearance revoked for cause, it is sufficient to rely on the local Facility Security Officer (FSO) database, Joint Personnel Adjudication System (JPAS), and assertions by the person on security clearance forms. 918BFor PKIs operated at medium-software, medium-hardware, and/or high-hardware, each person filling a trusted role shall satisfy at least one of the following requirements:

• 919BThe person shall be a citizen of the country where the CA is located; or

• 920BFor PKIs operated on behalf of multinational governmental organizations, the person shall be a citizen of one of the member countries; or

• 921BFor PKIs located within the European Union, the person shall be a citizen of one of the member states of the European Union; or

• 922BThe person shall have a security clearance equivalent to U.S. Secret or higher issued by a NATO member nation or major non-NATO ally as defined by the International Traffic in Arms Regulation (ITAR) – 22 CFR 120.32.

923BFor RAs, Trusted Agents, and personnel appointed to the trusted roles for the CSAs, in addition to the above, the person may be a citizen of the country where the function is located. 924BFor PKIs operated at any of the Commercial Best Practice (CBP) assurance levels, there is no citizenship requirement or security clearance specified 925B.




5.3.2 322BBackground Check Procedures 926BAll persons filling trusted roles (including CA trusted roles, CSA trusted roles, Trusted Agent, and RA role), shall have completed a favorable background investigation. The scope of the background check shall include the following areas covering the past five years and should be refreshed every five years:

• 109BEmployment;

• 110BEducation (Regardless of the date of award, the highest educational degree shall be verified);

• 111BPlace of residence (past 3 years);

• 112BLaw Enforcement; and

• 113BFinancial / Credit 927BAdjudication of the background investigation shall be performed by a competent adjudication authority using a process consistent with United States Executive Order 12968 August 1995, or equivalent. 928BThe results of these checks shall not be released except as required in Sections 9.3 and 9.4. 929BBackground check procedures shall be described in the CPS. 930BIf a formal clearance or other check is the basis for background check, the background refresh shall be in accordance with the corresponding formal clearance or other check. Otherwise, the background check shall be refreshed every ten years. 931BOne way to meet the requirements of this section is to have a national agency security clearance that is based on a five year background investigation. As an example, a successfully adjudicated United States National Agency Check with Written Inquires (NACI) or United States National Agency Check with Law Enforcement Check (NACLC) on record is deemed to have met the requirements of this section. 932BPractice Note: Interim clearance is not sufficient because the Raytheon PKI shall not assume risk in the event the interim clearance may be revoked. 933BPractice Note: If the person has been in the work-force less than five years, the employment verification shall consist of the periods during which the person has been in the work-force.

5.3.3 323BTraining Requirements 934BAll personnel performing duties with respect to the operation of a CA, CSA or a RA shall receive comprehensive training. Training shall be conducted in the following areas:

• 935BCA/CSA/RA security principles and mechanisms

• 936BAll PKI software versions in use on the CA system

• 937BAll PKI duties they are expected to perform

• 458BDisaster recovery and business continuity procedures.




5.3.4 324BRetraining Frequency and Requirements 938BAll personnel performing duties with respect to the operation of a CA, CSA or a RA shall be aware of changes in the CA, CSA, or RA operations, as applicable. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are CA software or hardware upgrade, RA software upgrades, changes in automated security systems, and relocation of equipment.

5.3.5 325BJob Rotation Frequency and Sequence 939BNo stipulation.

5.3.6 326BSanctions for Unauthorized Actions 940BThe RPMA shall take appropriate administrative and disciplinary actions against personnel who violate one or more of the policies in this CP.

5.3.7 327BIndependent Contractor Requirements 941BContractors shall not be allowed to perform functions on the Raytheon CAs. All administrators, officers, and audit administrators must be Raytheon employees. Contractors shall be allowed to perform RA and Trusted Agent roles. Contractor personnel employed to perform functions pertaining to the Raytheon PKI shall meet applicable requirements set forth in this CP (e.g., all requirements of Section 5.3).

5.3.8 328BDocumentation Supplied To Personnel 942BThe CA and CSA shall make the certificate policies they support, the CPS, and any relevant statutes, policies or contracts available to its personnel. Other technical, operations, and administrative documents (e.g., Administrator Manual, User Manual, etc.) shall be provided in order for the trusted personnel to perform their duties. 943BDocumentation shall be maintained identifying all personnel who received training and the level of training completed.

5.4 156BAUDIT LOGGING PROCEDURES 944BAudit log files shall be generated for all events relating to the security of the CAs, CSAs, and RAs. 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 329BTypes of Events Recorded 945BAll security auditing capabilities of the CA, CSA, and RA operating system and the CA, CSA, and RA applications required by this CP shall be enabled. As a result, most of the events identified in the table shall be automatically recorded. At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event):

• 483BThe type of event,

• 484BThe date the event occurred




• 1BThe time the event occurred where applicable or appropriate

• 485BA success or failure where appropriate,

• 486BThe identity of the entity and/or operator that caused the event,

• 487BA message from any source requesting an action by a CA is an auditable event. The message must include message date and time, source, destination and contents.

946BThe following events shall be audited:

947BAuditable Event 948BCA 949BCSA 950BRA 951BVM

952BSECURITY AUDIT 953BAny changes to the Audit parameters, e.g., audit frequency,

type of event audited 954BX 955BX 956BX 957BX

958BAny attempt to delete or modify the Audit logs 959BX 960BX 961BX 962BX

963BObtaining a third-party time-stamp 964BX 965BX 966BX 967BN/A

968BIDENTITY-PROOFING

969BSuccessful and unsuccessful attempts to assume a role 970BX 971BX 972BX 973BX

974BThe value of maximum number of authentication attempts is changed

975BX 976BX 977BX 978BX

979BMaximum number of authentication attempts occur during user login

980BX 981BX 982BX 983BX

984BAn Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts

985BX 986BX 987BX 988BX

989BAn Administrator changes the type of authenticator, e.g., from a password to a biometric

990BX 991BX 992BX 993BX

994BLOCAL DATA ENTRY

995BAll security-relevant data that is entered in the system 996BX 997BX 998BX 999BN/A

1000BREMOTE DATA ENTRY

1001BAll security-relevant messages that are received by the system

1002BX 1003BX 1004BX 1005BN/A

1006BDATA EXPORT AND OUTPUT

1007BAll successful and unsuccessful requests for confidential and security-relevant information

1008BX 1009BX 1010BX 1011BN/A

1012BKEY GENERATION

1013BWhenever the component generates a key (not mandatory for single session or one-time use symmetric keys)

1014BX 1015BX 1016BX 1017BN/A

1018BPRIVATE KEY LOAD AND STORAGE

1019BThe loading of component private keys 1020BX 1021BX 1022BX 1023BN/A

1024BAll access to certificate subject Private Keys retained within the CA for key recovery purposes

1025BX 1026BN/A 1027BN/A 1028BN/A





1029BTRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE

1030BAll changes to the trusted component Public Keys, including additions and deletions

1031BX 1032BX 1033BX 1034BN/A

1035BSECRET KEY STORAGE

1036BThe manual entry of secret keys used for authentication 1037BX 1038BX 1039BX 1040BN/A

1041BPRIVATE AND SECRET KEY EXPORT

1042BThe export of private and secret keys (keys used for a single session or message are excluded)

1043BX 1044BX 1045BX 1046BN/A

1047BCERTIFICATE REGISTRATION

1048BAll certificate requests 1049BX 1050BN/A 1051BX 1052BN/A

1053BCERTIFICATE REVOCATION

1054BAll certificate revocation requests 1055BX 1056BN/A 1057BX 1058BN/A

1059BCERTIFICATE STATUS CHANGE APPROVAL

1060BThe approval or rejection of a certificate status change request

1061BX 1062BN/A 1063BN/A 1064BN/A

1065BCA CONFIGURATION

1066BAny security-relevant changes to the configuration of the component

1067BX 1068BX 1069BX 1070BX

1071BACCOUNT ADMINISTRATION

1072BRoles and users are added or deleted 1073BX 1074B- 1075B- 1076BX

1077BThe access control privileges of a user account or a role are modified

1078BX 1079B- 1080B- 1081BX

1082BCERTIFICATE PROFILE MANAGEMENT

1083BAll changes to the certificate profile 1084BX 1085BN/A 1086BN/A 1087BN/A

1088BCERTIFICATE STATUS AUTHORITY MANAGEMENT

1089BAll changes to the CSA profile (e.g. OCSP profile) 1090BN/A 1091BX 1092BN/A 1093BN/A

1094BREVOCATION PROFILE MANAGEMENT

1095BAll changes to the revocation profile 1096BX 1097BN/A 1098BN/A 1099BN/A

1100BCERTIFICATE REVOCATION LIST PROFILE MANAGEMENT

1101BAll changes to the certificate revocation list profile 1102BX 1103BN/A 1104BN/A 1105BN/A

1106BMISCELLANEOUS

1107BInstallation of the Operating System 1108BX 1109BX 1110BX 1111BX

1112BInstallation of the PKI Application 1113BX 1114BX 1115BX 1116BX

1117BInstallation of hardware cryptographic modules 1118BX 1119BX 1120BX 1121BN/A





1122BRemoval of hardware cryptographic modules 1123BX 1124BX 1125BX 1126BN/A

1127BDestruction of cryptographic modules 1128BX 1129BX 1130BX 1131BN/A

1132BSystem Startup 1133BX 1134BX 1135BX 1136BX

1137BLogon attempts to PKI Application 1138BX 1139BX 1140BX 1141BN/A

1142BReceipt of hardware / software 1143BX 1144BX 1145BX 1146BX

1147BAttempts to set passwords 1148BX 1149BX 1150BX 1151BX

1152BAttempts to modify passwords 1153BX 1154BX 1155BX 1156BX

1157BBack up of the internal CA database 1158BX 1159B- 1160B- 1161B-

1162BRestoration from back up of the internal CA database 1163BX 1164B- 1165B- 1166B-

1167BFile manipulation (e.g., creation, renaming, moving) 1168BX 1169B- 1170B- 1171BX

1172BPosting of any material to a PKI Repository 1173BX 1174B- 1175B- 1176B-

1177BAccess to the internal CA database 1178BX 1179BX 1180B- 1181B-

1182BAll certificate compromise notification requests 1183BX 1184BN/A 1185BX 1186BN/A

1187BLoading tokens with certificates 1188BX 1189BN/A 1190BX 1191BN/A

1192BShipment of Tokens 1193BX 1194BN/A 1195BX 1196BN/A

1197BZeroizing Tokens 1198BX 1199BN/A 1200BX 1201BN/A

1202BRe-key of the component 1203BX 1204BX 1205BX 1206BN/A

1207BCONFIGURATION CHANGES

1208BHardware 1209BX 1210BX 1211B- 1212BX

1213BSoftware 1214BX 1215BX 1216BX 1217BX

2479BOperating System 1218BX 1219BX 1220BX 1221BX

1222BPatches 1223BX 1224BX 1225B- 1226BX

1227BSecurity Profiles 1228BX 1229BX 1230BX 1231BX

1232BPHYSICAL ACCESS / SITE SECURITY

1233BPersonnel Access to room housing component 1234BX 1235B- 1236B- 1237BX

1238BAccess to the component 1239BX 1240BX 1241B- 1242BX

1243BKnown or suspected violations of physical security 1244BX 1245BX 1246BX 1247BX

1248BANOMALIES

1249BSoftware error conditions 1250BX 1251BX 1252BX 1253BX

1254BSoftware check integrity failures 1255BX 1256BX 1257BX 1258BX

1259BReceipt of improper messages 1260BX 1261BX 1262BX 1263BX

1264BMisrouted messages 1265BX 1266BX 1267BX 1268BX





1269BNetwork attacks (suspected or confirmed) 1270BX 1271BX 1272BX 1273BX

1274BEquipment failure 1275BX 1276B- 1277B- 1278BX

1279BElectrical power outages 1280BX 1281B- 1282B- 1283BX

1284BUninterruptible Power Supply (UPS) failure 1285BX 1286B- 1287B- 1288BX

1289BObvious and significant network service or access failures 1290BX 1291B- 1292B- 1293BX

1294BViolations of Certificate Policy 1295BX 1296BX 1297BX 1298BX

1299BViolations of Certification Practice Statement 1300BX 1301BX 1302BX 1303BX

1304BResetting Operating System clock 1305BX 1306BX 1307BX 1308BX

5.4.2 330BFrequency of Processing Audit Logs 1309BAudit logs shall be reviewed at least monthly, unless the CA is off-line, in which case the audit logs shall be reviewed when the system is activated or every month, whichever is later. A statistically significant sample of security audit data generated by the CA, CSA, or RA since the last review shall be examined (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 well as a reasonable search for any evidence of malicious activity. The Audit Administrator shall explain all significant events in an audit log summary. Such reviews involve verifying that the log has not been tampered with, there is no discontinuity or other loss of audit data, 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 331BRetention Period for Audit Logs 1310BAudit logs shall be retained onsite for at least sixty days and must be retained in the manner described below. For the CA and CSA, the Audit Administrator shall be the only person managing the audit log (e.g., review, backup, rotate, delete, etc.). For the RA System, a System Administrator other than the RA shall be responsible for managing the audit log.

5.4.4 332BProtection of Audit Logs 1311BSystem configuration and operational procedures shall be implemented together to ensure that:

• 1312BOnly authorized people5F

6have read access to the logs;

• 1313BOnly authorized people may archive audit logs; and,

• 1314BAudit logs are not modified. 1315BThe person performing audit log archive need not have modify access, and procedures are implemented to protect archived data from destruction prior to the end of the audit log retention period (note that deletion requires modification access). Audit logs shall be moved to a safe, secure storage location separate from the CA equipment. 6 For the CA and CSA, the authorized individual shall be the Audit Administrator. For the RA system, the authorized individual shall be a system administrator other than the RA.




1316BIt is acceptable for the system to over-write audit logs after they have been backed up and archived.

5.4.5 333BAudit Log Backup Procedures 1317BAudit logs and audit summaries shall be backed up at least monthly, unless the CA is offline, in which case audit logs and audit summaries shall be backed up when the system is activated or every month, whichever is later. A copy of the audit log shall be sent off-site in accordance with the CPS following review.

5.4.6 334BAudit Collection System (internal vs. external) 1318BThe audit log collection system may or may not be external to the CA, CSA, or RA. Audit processes shall be invoked at system startup, and cease only at system shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, the CA shall determine whether to suspend CA operation until the problem is remedied.

5.4.7 335BNotification to Event-Causing Subject 1319BThis 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 336BVulnerability Assessments 1320BThe CA, system administrator, and other operating personnel shall be watchful for attempts to violate the integrity of the certificate management system, including the equipment, physical location, and personnel. The security audit data shall be reviewed by the audit administrator for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. Security auditors shall check for continuity of the security audit data. The audit administrator shall document the summary results of the period review of the audit logs.

5.5 157BRECORDS ARCHIVAL

5.5.1 337BTypes of Records Archived 1321BCA, CSA, and RA archive records shall be sufficiently detailed to establish the proper operation of the PKI or the validity of any certificate (including those revoked or expired) issued by the CA.

1322BData To Be Archived 1323BCA 1324BCSA 1325BRA 1326BVM

1327BCertification Practice Statement 1328BX 1329BX 1330BX 1331BN/A

1332BCertificate Policy 1333BX 1334BX 1335BX 1336BN/A

1337BContractual obligations 1338BX 1339BX 1340BX 1341BN/A

1342BSystem and equipment configuration 1343BX 1344BX 1345B- 1346BN/A

1347BModifications and updates to system or configuration 1348BX 1349BX 1350B- 1351BN/A

1352BCertificate requests 1353BX 1354B- 1355B- 1356BN/A




1322BData To Be Archived 1323BCA 1324BCSA 1325BRA 1326BVM

1357BRevocation requests 1358BX 1359B- 1360B- 1361BN/A

1362BSubscriber identity authentication data as per Section 3.2.3 1363BX 1364BN/A 1365BX 1366BN/A

1367BDocumentation of receipt and acceptance of certificates, including subscriber agreements

1368BX 1369BN/A 1370BX 1371BN/A

1372BDocumentation of receipt of Tokens 1373BX 1374BN/A 1375BX 1376BN/A

1377BAll certificates issued or published 1378BX 1379BN/A 1380BN/A 1381BN/A

1382BRecord of component CA Re-key 1383BX 1384BX 1385BX 1386BN/A

1387BAll CRLs and CRLs issued and/or published 1388BX 1389BN/A 1390BN/A 1391BN/A

1392BAll Audit Logs 1393BX 1394BX 1395BX 1396BX

1397BOther data or applications to verify archive contents 1398BX 1399BX 1400BX 1401BX

1402BDocumentation required by compliance auditors 1403BX 1404BX 1405BX 1406BX

1407BCompliance Audit Reports 1408BX 1409BX 1410BX 1411BX

5.5.2 338BRetention Period for Archive 1412BThe minimum retention period for archive data is 10 years and 6 months for Medium Assurance levels. The minimum retention period for archive data is 20 years and 6 months for High-hardware assurance level. 1413BIf the original media cannot retain the data for the required period, a mechanism to periodically transfer the archived data to new media shall be defined by the archive site. Applications required to process the archive data shall also be maintained for the minimum retention period specified above.

5.5.3 339BProtection of Archive 1414BNo unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA, RA and CSA, the authorized individuals are Audit Administrators. The contents of the archive shall not be released except as determined by the RPMA for the Raytheon PKI 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 PKI components (CA, CSA, or RA) with physical and procedural security controls equivalent or better than those of the PKI.

5.5.4 340BArchive Backup Procedures 1415BThe CPS or a referenced document shall describe how archive records are backed up, and how the archive backups are managed.

5.5.5 341BRequirements for Time-Stamping of Records 1416BCA 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.




5.5.6 342BArchive Collection System (internal or external) 1417BNo stipulation.

5.5.7 343BProcedures to Obtain & Verify Archive Information 1418BProcedures detailing how to create, verify, package, transmit and store archive information shall be described in the applicable CPS. Only authorized personnel shall be allowed to access the archive.




5.6 158BKEY CHANGEOVER 1419BA CA uses a signing (private) key for creating certificates; however, relying parties employ the CA certificate for the life of the Subscriber certificate beyond that signing. Therefore, CAs must not issue Subscriber certificates that extend beyond the expiration dates of their own certificates and public keys, and the CA certificate validity period must extend one Subscriber certificate validity period (listed in Section 3.3) past the last use of the CA private key. 1420BTo minimize risk to the PKI through compromise of a CAs key, the private signing key shall be changed more frequently, and only the new key shall be used for certificate signing purposes from that time. The older, but still valid, certificate shall be available to verify old signatures until all of the Subscriber certificates signed under it have also expired. If the old private key is used to sign CRLs that contain certificates signed with that key, then the old key must be retained and protected. Raytheon Entities shall describe their key changeover processes in the applicable CPS. For a thorough discussion of key changeover, see Certificate Management Protocol [RFC2510]. 1421BThe following table provides the life times for certificates and associated private keys.

1422BKey 1423B2048 Bit Keys 1424BPrivate Key 1425BCertificate

1426BSelf-signed Root CA 1427B20 years 1428B20 years 1429BSigning CA 1430B10 years 1431B10 years* 1432BSubscriber Identity or Signature

1433B3 years 1434B3 years

1435BSubscriber Encryption 1436BUnrestricted 1437B3 years 1438BCode Signer 1439B3 years 1440B8years 1441BDevice 1442B3 years 1443B3 years 1444BOCSP Responder 1445B3 years 1446B45 days

1447B*For Signing CAs operating at SHA 2 with at least 3072 bit key length, certificate lifetime may be extended to 13 years. 1448BNo CA, including a Bridge CA, shall have a private key that is valid for longer than 20 years. Cross certificates issued by or to a Bridge CA shall not be valid for more than 10 years. 1449BCAs must not issue subscriber certificates that extend beyond the expiration date of their own certificates and public keys. 1450BNotwithstanding the above table, in all cases the CA private key may be used to sign OCSP certificates and CRLs until the CA certificate expires. 1451BFor additional constraints on certificate life and key sizes, see Section 6.1.5.

5.7 159BCOMPROMISE AND DISASTER RECOVERY

5.7.1 344BIncident and Compromise Handling Procedures 1452BEach organization operating an Entity PKI shall have a formal disaster recovery plan. 1453BIf a CA or CSA detects a potential hacking attempt or other form of compromise, it shall perform an investigation in order to determine the nature and the degree of damage. If the CA or CSA




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 or CSA needs to be rebuilt, only some certificates need to be revoked, and/or the CA or CSA key needs to be declared compromised. If it is determined that an incident has occurred with the potential to affect the operations and/or security environments, the RPMA and CPMA shall be notified within 24 hours of determination and provided a preliminary remediation analysis. 1454BWithin 10 business days of incident resolution, the CA or CMS owner shall post a notice on its public web page identifying the incident and notify CertiPath that the notice has been posted. The public notice shall include the following:

• 1455BWhich CA components were affected by the incident

• 1456BThe CA’s interpretation of the incident

• 1457BWho is impacted by the incident

• 1458BWhen the incident was discovered

• 1459BA statement that the incident has been fully remediated. 1460BRaytheon shall follow the process identified above to post a notice of the incident to its public web page and notify all cross-certified entities that the notice has been posted. 1461BThe RPMA members shall be notified if any of the following cases occur:

• 1462BSuspected or detected compromise of the Raytheon PKI system;

• 1463BPhysical or electronic attempts to penetrate the Raytheon PKI system;

• 1464BDenial of service attacks on a Raytheon PKI component; or

• 1465BAny incident preventing the Raytheon PKI from issuing a CRL within 24 hours of the time specified in the next update field of its currently valid CRL.

1466BThe RPMA, CPMA and all cross certified PKIs shall be notified if any of the following cases occur:

• 1467BA CA certificate revocation is planned; or

• 1468BAny 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.

1469BThe ROA shall reestablish operational capabilities as quickly as possible in accordance with procedures set forth in the respective CPS. 1470BWhen Raytheon has detected an incident or compromise of the RRCA and/or Raytheon signing CA, and upon approval by the Raytheon CISO, the Raytheon PMA shall notify the CertiPath PMA. 1471BThe above measures will allow member entities to protect their interests as Relying Parties.

5.7.2 345BComputing Resources, Software, and/or Data Corruption 1472BThe CA shall maintain backup copies of system, databases, and private keys in order to rebuild the CA capability in case of software and/or data corruption.




1473BIf a CA or CSA equipment is damaged or rendered inoperative, but the signature keys are not destroyed; the operation shall be reestablished as quickly as possible, giving priority to the ability to generate certificate status information. Before returning to operation, ensure that the system’s integrity has been restored. 1474BIf a CA cannot issue a CRL prior to the time specified in the next update field of its currently valid CRL, then all CAs that have been issued certificates by the CA shall be securely6F

7 notified immediately. This will allow other CAs to protect their subscribers' interests as Relying Parties. 1475BIf the ability to revoke certificates is inoperative or damaged, the CA shall reestablish revocation capabilities as quickly as possible in accordance with procedures set forth in the respective CPS. If the CA’s revocation capability cannot be established in a reasonable time-frame, the CA shall determine whether to request revocation of its certificate(s). If the CA is a Root CA, the CA shall determine whether to notify all subscribers that use the CA as a trust anchor to delete the trust anchor. 1476BThe ROA shall post a notice on its web page identifying the incident and notify the RPMA and CPMA. See Section 5.7.1 for the contents of the notice.

5.7.3 346BPrivate Key Compromise Procedures 1477BIf a CA’s signature keys are compromised, lost, or suspected of compromise:

1. 1478BAll cross certified CAs shall be securely notified at the earliest feasible time (so that entities may issue CRLs revoking any cross-certificates issued to the CA);

2. 1479BA new CA key pair shall be generated by the CA in accordance with procedures set forth in the applicable CPS;

3. 1480BNew CA certificates shall be requested in accordance with the initial registration process as described in section 3.2.;

4. 1481BAll Subscribers shall be notified and requested to register in accordance with the initial registration process as described in section 3.2; and

5. 1482BIf the CA is a Root CA, it shall provide the Subscribers the new trust anchor using secure means.

1483BThe ROA shall also investigate what caused the compromise or loss, and what measures must be taken to preclude recurrence. 1484BIf a CSA key is compromised, all certificates issued to the CSA shall be revoked, if applicable. The CSA shall generate a new key pair and request new certificate(s), if applicable. If the CSA is a trust anchor, the relying parties shall be provided the new trust anchor in a secure manner (so that the trust anchor integrity is maintained) to replace the compromised trust anchor. 1485BIf RA signature keys are compromised, lost, or suspected of compromise:

1. 1486BThe RA certificate shall be revoked immediately;

7 With confidentiality, source authentication, and integrity security services applied.




2. 1487BA new RA key pair shall be generated in accordance with procedures described in the applicable CPS;

3. 1488BNew RA certificate shall be requested in accordance with the initial registration process as described in section 3.2;

4. 1489BAll certificate registration requests approved by the RA since the date of the suspected compromise shall be reviewed to determine which are legitimate;

5. 1490BFor those certificate requests or approval whose legitimacy cannot be ascertained, the resultant certificates shall be revoked and their subjects (i.e., subscribers) shall be notified of revocation.

1491BIn the event of any of the above, the ROA shall post a notice on its web page identifying the incident and notify the RPMA and CPMA. See Section 5.7.1 for the contents of the notice.

5.7.4 347BBusiness Continuity Capabilities after a Disaster 1492BIn the case of a disaster whereby a CA installation is physically damaged and all copies of the CA Signing Key are destroyed as a result, the CA shall request revocation of its certificates. Further, the CA shall re-establish operations by following the procedures for CA key loss or compromise detailed in Section 5.7.3 above.

5.8 160BCA, CSA, AND RA TERMINATION 1493BIn the event of termination of a CA, the CA shall request all certificates issued to it be revoked. 1494BIn the event of a CA termination, Raytheon shall provide as much advance notice as circumstances permit notice to all cross certified CAs prior to the termination.

• 1495BThe CA, CSA, and RA shall archive all audit logs and other records prior to termination.

• 1496BThe CA, CSA, and RA shall destroy all its private keys upon termination.

• 1497BThe CA, CSA, and RA archive records shall be transferred to an appropriate authority such as the RPMA responsible for the entity.

• 1498BIf a Root CA is terminated, the Root CA shall use secure means to notify the subscribers to delete all trust anchors representing the terminated CA.

1499BWhenever possible, notification of termination will be provided at least two weeks prior to the CA termination.




6 119BTECHNICAL SECURITY CONTROLS

6.1 161BKEY PAIR GENERATION AND INSTALLATION

6.1.1 348BKey Pair Generation 1500BThe following table provides the requirements for key pair generation for the various entities.

1501BEntity 1502BFIPS 140-1/2 Level

1503BHardware or Software

1504BKey Storage Restricted To

The Module on Which The Key Was Generated

1505BCA 1506B3 1507BHardware 1508BYes

1509BRA 1510B2 1511BHardware 1512BYes

1513BCSA 1514B2 1515BHardware 1516BYes

1517BCode Signing 1518B2 1519BHardware 1520BYes

1521BEnd Entity Signature or Authentication (medium-software and medium- 1522BCBP-software)

1523B1 1524BSoftware 1525BNo Requirement

1526BEnd Entity Encryption (medium-software and medium-CBP-software)

1527B1 1528BSoftware 1529BNo Requirement

1530BEnd Entity Signature or Authentication (medium-hardware, medium- 1531BCBP-hardware and high-hardware)

1532B2 1533BHardware 1534BYes

1535BEnd Entity Encryption (medium-hardware, medium-CBP-hardware and high-hardware)

1536B2 1537BHardware 1538BNo Requirement

1539BServer (medium-software 1540Band medium-CBP-software)

1541B1 1542BSoftware

1543BNo Requirement

1544BServer (medium-hardware, 1545Bmedium-CBP-hardware, 1546Band high-hardware)

1547B2 1548BHardware

1549BYes

1550BRandom numbers for medium-hardware, medium-CBP-hardware, and high-hardware assurance level keys shall be generated in FIPS 140 Level 2 validated hardware cryptographic modules.




1551BWhen private keys are not generated on the token to be used, originally generated private keys shall be destroyed after they have been transferred to the token. This does not prohibit the key generating modules to act as the key escrow module also. 1552BMultiparty control shall be used for CA key pair generation, as specified in Section 5.2.2. 1553BThe CA key pair generation process shall create a verifiable audit trail that the security requirements for the process were followed. The documentation of the process shall be detailed enough to show that appropriate role separation was used. The process shall be validated by an independent third party.

6.1.2 349BPrivate Key Delivery to Subscriber 1554BA CA shall generate its own key pair and therefore does not need private key delivery. 1555BIf subscribers generate their own key pairs, then there is no need to deliver private keys, and this section does not apply. 1556BWhen CAs or RAs generate keys on behalf of the Subscriber, then the private key shall be delivered securely to the Subscriber. Private keys may be delivered electronically or may be delivered on a hardware cryptographic module. In all cases, the following requirements shall be met:

• 1557BAnyone who generates a private signing key for a Subscriber shall not retain any copy of the key after delivery of the private signing key to the Subscriber.

• 1558BThe private key shall be protected from activation, compromise, or modification during the delivery process.

• 1559BThe Subscriber shall acknowledge receipt of the private key(s).

• 1560BDelivery shall be accomplished in a way that ensures that the correct tokens and activation data are provided to the correct Subscribers.

o 1561BFor hardware modules, accountability for the location and state of the module shall be maintained until the Subscriber accepts possession of it.

o 1562BFor electronic delivery of private keys, the key material shall be encrypted using a cryptographic algorithm and key size at least as strong as the private key being delivered. Activation data shall be delivered using a separate secure channel.

1563BThe CA or the RA shall maintain a record of the subscriber acknowledgement of receipt of the token.

6.1.3 350BPublic Key Delivery to Certificate Issuer 1564BWhere key pairs are generated by the Subscriber or RA, the public key and the Subscriber’s identity shall be delivered securely to the CA for certificate issuance. The delivery mechanism shall bind the Subscriber’s verified identity to the public key. If cryptography is used to achieve this binding, it shall be at least as strong as the CA keys used to sign the certificate.

6.1.4 351BCA Public Key Delivery to Relying Parties 1565BThe public key of a trust anchor shall be provided to the subscribers acting as relying parties in a secure manner so that the trust anchor is not vulnerable to modification or substitution. Acceptable methods for delivery of a trust anchor include but are not limited to:




• 1566BThe CA loading a trust anchor onto tokens delivered to subscribers via secure mechanisms;

• 1567BSecure distribution of a trust anchor through secure out-of-band mechanisms;

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

• 1569BDownloading a trust anchor from a web site secured with a currently valid certificate of equal or greater assurance level than the certificate being downloaded provided the trust anchor is not in the certification chain for the web site certificate.

1570BSystems using high-hardware assurance certificates shall store Trust Anchor Certificates such that unauthorized alteration or replacement is readily detectable.

6.1.5 352BKey Sizes 1571BIf the RPMA determines that the security of a particular algorithm may be compromised, it may require the CAs to revoke the affected certificates. 1572BAll public keys placed in newly generated certificates (including self-signed certificates) and uses of public key cryptography by PKI components for signature and/or key agreement/encryption operations shall use the following algorithm suites for the time periods indicated:

1573BPublic Key Algorithm

1574BSunset Date

1575BSignature 1576B2048 bit RSA, 224 bit ECDSA in prime

field, or 233 bit ECDSA in binary

field

1577B12/31/2030

1578B3072 bit RSA, 256 bit ECDSA in prime

field, or 283 bit ECDSA in binary

field

1579BNo stipulation

1580BEncryption 1581B2048 bit RSA, 224 bit ECDH in prime

field, or 233 bit ECDH in binary

field

1582B12/31/2030

1583B3072 bit RSA, 256 bit ECDH in prime

field, or 283 bit ECDH in binary

field

1584BNo stipulation




1585BAll data encryption (including network protocols) used by or in connection with PKI components for administration, communications, and protection of keys or other sensitive data shall use the following symmetric algorithms for the time periods indicated:

1586BSymmetric Algorithm 1587BSunset Date

1588B3 Key TDES 1589BDeprecated. 1590BMay be used until 12/31/2023 only for data blocks that are 8 MB or less per unique key bundle. 7F

8

1591BAES 1592BNo stipulation

1593BAll certificates (excluding self-signed certificates), CRLs, and OCSP Responses, with the exception of those associated with the SHA1 certificate policy OID(s), shall use one of the following hash algorithms for the time periods indicated:

1594BIssued before 12/31/2030

1595BIssued after 12/31/2030

1596BHash Algorithm for Certificates, CRLs and OCSP Responses

1597BSHA-224 or SHA-256 1598BSHA-256

1599BCSAs shall use the same signature algorithms, key sizes, and hash algorithms as used by the CA to sign the certificate in question. 1600BAll PKI components that use hash algorithms for security relevant functions, such as key generation or agreement, communication protocols (e.g. TLS), or password protection, shall use the same or larger bit versions of the hash algorithm(s) used by the CA to sign certificates. 1601BAs an exception to all of the other assertions in this section, CAs not asserting “id-raytheon-SHA2-…..” series certificate policy OID(s) may continue to use SHA-1 for issuing end entity certificates and CRLs after 12/31/2010. OCSP Responders that only provide “certificate revocation status” of certificates that do not possess “id-raytheon-SHA2-…..” certificate policy OIDs, may use SHA-1 for all OCSP response types.

6.1.6 353BPublic Key Parameters Generation and Quality Checking 1602BRSA keys shall be generated in accordance with FIPS 186-3. Prime numbers for RSA shall be generated or tested for primality in accordance with FIPS 186-3. 1603BECDSA and ECDH keys shall be generated in accordance with FIPS 186-3. Curves from FIPS 186-3 shall be used.

8 See NIST SP 800-131 regarding the deprecation of 3 Key TDES




6.1.7 354BKey Usage Purposes (as per X.509 v3 key usage field) 1604BThe use of a specific key is determined by the key usage and extended key usage extensions in the X.509 certificate. For key usage, the following constraints shall apply:

• 1605BCertificates to be used solely for authentication shall set only the digitalsignature bit

• 1606BCertificates to be used for digital signatures shall set the digitalsignature and nonrepudiation bits.

• 1607BCertificates that have the nonrepudiation bit set, shall not have the keyEncipherment bit or keyAgreement bit set.

• 1608BCertificates to be used for encryption shall set the keyEncipherment bit. • 1609BCertificates to be used for key agreement shall set the keyAgreement bit.

• 1610BCA certificates shall set cRLSign and keyCertSign bits. 1611BPublic keys that are bound into certificates shall be certified for use in signing or encrypting, but not both. This restriction is not intended to prohibit use of protocols (like the Secure Sockets Layer) that provide authenticated connections using key management certificates and require setting both digitalsignature and keyEncipherment bits to be set. 1612BFor End Entity certificates the Extended Key Usage extension shall always be present and shall not contain anyExtendedKeyUsage {2.5.29.37.0}. 1613BThe extended key usage shall meet the requirements stated in Section 10-20. Extended Key Usage OIDs shall be consistent with key usage bits asserted.




6.2 162BPRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS

6.2.1 355BCryptographic Module Standards and Controls 1614BThe relevant standard for cryptographic modules is FIPS PUB 140-2, Security Requirements for Cryptographic Modules. The RPMA may determine that other comparable validation, certification, or verification standards are also sufficient. These standards shall be published by the RPMA. Cryptographic modules shall be validated to the FIPS 140-2 level identified in this section, or validated, certified, or verified to requirements published by the RPMA. Additionally, the RPMA reserves the right to review technical documentation associated with any cryptographic modules under consideration for use by the CAs. 1615BThe table in Section 6.1.1 summarizes the minimum requirements for cryptographic modules; higher levels may be used. In addition, private keys shall not exist outside the cryptographic module in plaintext form.

6.2.2 356BPrivate Key Multi-Person Control 1616BUse of a CA private signing key and an OSCP responder private signing key shall require action by at least two persons.

6.2.3 357BPrivate Key Escrow 1617BUnder no circumstances shall signature keys be escrowed by a third party. 1618BEnd entity private keys issued to human beings and used for decryption shall be escrowed. For end entity private keys issued to non-human entities and used for decryption, escrow is mandatory unless the data protected by these keys will never require recovery. This escrow shall take place prior to the generation of the corresponding certificates. 1619BFor some purposes (such as data recovery) it shall be necessary to provide key retrieval for the private component of the encryption certificate key pair. To facilitate this, the PKI shall provide a key escrow capability. The method, procedures and controls which shall apply to the storage, request for, extraction and/or retrieval, delivery, protection and destruction of the requested copy of an escrowed key shall be described in the Raytheon Key Recovery Practice Statement (KRPS) which shall become an integral component of this CP.

6.2.4 Private Key Backup

6.2.4.1 447BBackup of CA Private Signature Key 1620BThe CA private signature keys shall be backed up under the same multi-person control as used to generate and protect the original signature key. A single backup copy of the signature key shall be stored at or near the CA location. A second backup copy shall be kept at the CA backup location. Procedures for CA private signature key backup shall be included in the appropriate CPS and shall meet the multiparty control requirement of Section 5.2.2.

6.2.4.2 448BBackup of Subscriber Private Signature Key 1621BSubscriber private signature keys whose corresponding public key is contained in a certificate asserting the medium-software may be backed up or copied, but must be held in the Subscriber’s control. Storage must ensure security controls consistent with the protection provided by the subscriber’s cryptographic module.




1622BDevice private signature keys whose corresponding public key is contained in a certificate asserting medium-device-software may be backed up or copied but must be held in the control of the device’s human sponsor or other authorized administrator. 1623BSubscriber private signature keys whose corresponding public key is contained in a certificate asserting the medium-hardware, medium-device-hardware, and/or high-hardware shall not be backed up or copied.

6.2.4.3 449BCSA Private Key Backup 1624BIf backed up, the CSA private signature keys shall be backed up under the same multi-person control as used to generate the CSA private signature keys, and shall be accounted for and protected in the same manner as the original. A single backup copy of the CSA private signature key may be stored at or near the CSA location. A second backup copy may be kept at the CSA backup location. Procedures for CSA private signature key backup shall be included in the appropriate CPS.

6.2.5 359BPrivate Key Archival 1625BPrivate signature keys shall not be archived.

6.2.6 360BPrivate Key Transfer into or from a Cryptographic Module 1626BCA and CSA private keys shall be generated by and remain in an approved cryptographic module. The CA and CSA private keys may be backed up in accordance with Section 6.2.4.1. 1627BPrivate or symmetric keys used to encrypt other private keys for transport must be protected from disclosure.

6.2.7 361BPrivate Key Storage on Cryptographic Module 1628BThe cryptographic module may store Private Keys in any form as long as the keys are not accessible without the use of an authentication mechanism that is in compliance with the FIPS 140-1/2 rating of the cryptographic module.

6.2.8 362BMethod of Activating Private Key 1629BThe user must be authenticated to the cryptographic module before the activation of any private key(s), except as indicated below. Acceptable means of authentication include but are not limited to pass-phrases, PINs or biometrics. When pass-phrases or PINs are used, they shall be a minimum of six (6) characters. Entry of activation data shall be protected from disclosure (i.e., the data should not be displayed while it is entered). 1630BFor certificates issued under any of the four medium-device policies, the device may be configured to activate its private key without requiring its human sponsor or authorized administrator to authenticate to the cryptographic token, provided that appropriate physical and logical access controls are implemented for the device and its cryptographic token. The strength of the security controls shall be commensurate with the level of threat in the device’s environment, and shall protect the device’s hardware, software, and the cryptographic token and its activation data from compromise.




6.2.9 363BMethods of Deactivating Private Key 1631BCryptographic modules that have been activated shall not be left unattended or otherwise available to unauthorized access. After use, a cryptographic module shall be deactivated, e.g., via a manual logout procedure, or automatically after a period of inactivity as defined in the applicable CPS. CA and CSA hardware cryptographic modules shall be removed and stored in a secure container when not in use.

6.2.10 364BMethod of Destroying Private Key 1632BPrivate 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 can be accomplished by overwriting the data. For hardware cryptographic modules, this will usually require executing a “zeroize” command. Physical destruction of hardware is generally not required.

6.2.11 365BCryptographic Module Rating 1633BSee Section 6.2.1.




6.3 163BOTHER ASPECTS OF KEY MANAGEMENT

6.3.1 366BPublic Key Archival 1634BThe public key is archived as part of the certificate archival.

6.3.2 367BCertificate Operational Periods/Key Usage Periods 1635BSee Section 5.6.

6.4 164BACTIVATION DATA

6.4.1 368BActivation Data Generation and Installation 1636BFor id-raytheon-SHA2-medium-device-Hardware, id-raytheon-SHA2-medium-device-Software, id-raytheon-medium-device-Hardware, or id-raytheon- medium-deviceSoftware, private keys may be activated without entry of activation data. 1637BFor all other policies governed by this CP, the activation data used to unlock private keys, in conjunction with any other access control procedure, shall have an appropriate level of strength for the keys or data to be protected and shall meet the applicable security policy requirements of the cryptographic module used to store the keys. Subscriber activation data may be user selected. For CAs, activation data shall either entail the use of biometric data or satisfy the policy-enforced at/by the cryptographic module. 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.

6.4.2 369BActivation Data Protection 1638BData used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical access control mechanisms. Activation data should be either biometric in nature or memorized. 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. In all cases, the protection mechanism shall include a facility to temporarily lock the account, or terminate the application, after a predetermined number of failed login attempts as set forth in the respective CPS. 1639BActivation data for private keys associated with certificates asserting individual identities shall never be shared. Activation data for private keys associated with certificates for devices and code signing certificates shall be restricted to the PKI sponsor authorized to use the private keys.

6.4.3 370BOther Aspects of Activation Data 1640BCAs, CSAs, and RAs shall change the activation data whenever the token is re-keyed or returned from maintenance.




6.5 165BCOMPUTER SECURITY CONTROLS

6.5.1 371BSpecific Computer Security Technical Requirements 1641BThe following computer security functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards. The CA, CSA, hypervisor and RA shall include the following functionality:

• 64BRequire authenticated logins

• 65BProvide Discretionary Access Control, including managing privileges of users to limit users to their assigned roles

• 66BProvide a security audit capability (See Section 5.4)

• 67BProhibit object re-use

• 68BRequire use of cryptography for session communication and database security

• 69BRequire a trusted path for identification and authentication

• 70BProvide domain isolation for processes

• 71BProvide self-protection for the operating system • 72BRequire self-test security related CA services (e.g., check the integrity of the audit

logs)

• 1642BSupport recovery from key or system failure 1643BWhen CA equipment is hosted on evaluated platforms in support of computer security assurance requirements the system (hardware, software, operating system) shall, where possible, operate in an evaluated configuration. At a minimum, such platforms shall use the same version of the computer operating system as that which received the evaluation rating. 1644BThe computer system shall be configured with the minimum of the required accounts and network services, and shall not permit remote login.

6.5.2 372BComputer Security Rating 1645BSee section 6.5.1.

6.6 166BLIFE-CYCLE TECHNICAL CONTROLS

6.6.1 373BSystem Development Controls 1646BThe System Development Controls for the CA, CSA, and Hypervisor are as follows:

• 73BUse software that has been designed and developed under a formal, documented development methodology.

• 74BProcured hardware and software shall be purchased in a fashion to reduce the likelihood that any particular device was tampered with (e.g., by ensuring the equipment was randomly selected at time of purchase).




• 75BSpecially developed hardware and software shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off-the-shelf hardware or software.

• 76BAll hardware must be shipped or delivered via controlled methods that provide a continuous chain of accountability, from the purchase location to the operations location.

• 77BThe hardware and software shall be dedicated to performing PKI activities. There shall be no other applications; hardware devices, network connections, or device software installed which is not part of the PKI operation.

• 78BProper care shall be taken to prevent malicious software from being loaded onto the RA equipment. RA hardware and software shall be scanned for malicious code on first use and periodically thereafter.

• 79BHardware and software updates shall be purchased or developed in the same manner as original equipment, and shall be installed by trusted and trained personnel in a defined manner.

6.6.2 374BSecurity Management Controls 1647BThe configuration of the CA and CSA systems as well as any modifications and upgrades shall be documented and controlled. There shall be a mechanism for detecting unauthorized modification to the CA and CSA 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 that supplied by the vendor, with no modifications, and as the version intended for use. 1648BIn addition, only applications required to perform the organization's mission shall be loaded on the RA workstation, and all such software shall be obtained from sources authorized by local policy.

6.6.3 375BLife Cycle Security Controls 1649BNo stipulation.

6.7 167BNETWORK SECURITY CONTROLS 1650BThe Raytheon Root CA and its internal PKI Repository shall be off-line. Information shall be transported from the Internal PKI Repository to the external PKI Repositories using manual mechanisms. 1651BSigning CAs, CSAs, and RAs and associated PKI Repositories shall employ appropriate security measures to ensure they are guarded against denial of service and intrusion attacks. Such measures include the use of firewalls, intrusion detection software 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. 1652BAny boundary control devices used to protect the network on which the PKI equipment is hosted shall deny all but the necessary services to the PKI equipment even if those services are enabled for other devices on the network.




6.8 168BTIME STAMPING 1653BAll CA and CSA components shall regularly synchronize with a time service such as the National Institute of Standards and Technology (NIST) Atomic Clock or the NIST Network Time Protocol (NTP) Service. Time derived from the time service shall be used for establishing the time of:

• 80BInitial validity time of a Subscriber’s Certificate

• 81BRevocation of a Subscriber’s Certificate

• 82BPosting of CRL updates

• 83BCSA responses 1654BAsserted times shall be accurate to within three minutes. Electronic or manual procedures may be used to maintain system time. Clock adjustments are auditable events as listed in Section 5.4.1.




7 120BCERTIFICATE, CRL AND OCSP PROFILES

7.1 169BCERTIFICATE PROFILE

7.1.1 376BVersion Numbers 1655BCAs shall issue X.509 v3 certificates (populate version field with integer "2").

7.1.2 377BCertificate Extensions 1656BRaytheon CA critical private extensions shall be interoperable in their intended community of use. 1657BIssuer CA and Subscriber certificates may include any extensions as specified by RFC 5280 in a certificate, but must include those extensions required by this CP. Any optional or additional extensions shall be non-critical and shall not conflict with the certificate and CRL profiles defined in this CP. Section 10 contains the certificate formats. 1658BAny optional certificate extension requests must be submitted by the ROA to the RPMA for approval and must be documented in the applicable CPS.

7.1.3 378BAlgorithm Object Identifiers 1659BCertificates issued under this CP shall use one of the following OIDs for signatures:

2480Bsha-1WithRSAEncryption 457B{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

1660Bsha256WithRSAEncryption 1661B{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

1662Becdsa-with-Sha1 1663B{iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) sha1(1)}

1664Becdsa-with-Sha256 1665B{iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) specified(3) sha256(2)}

1666BCertificates under this CP shall use one of the following OIDs for identifying the subject public key information:

1667BrSAEncryption 2481B{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}

1668Bid-ecPublicKey 2482B{iso(1) member-body(2) us(840) ansi-X9-62(10045) public-key-type(2) 1} 1669BThe Raytheon PKI shall certify only public keys associated with the cryptoalgorithms identified above, and shall only use the signature cryptoalgorithms described above to sign certificates, certificate revocation lists and any other PKI product.

7.1.4 379BName Forms 1670BThe subject and issuer fields of the certificate shall be populated with a unique Distinguished Name in accordance with one or more of the X.500 series standards, with the attribute type as further constrained by RFC5280. Subject and issuer fields shall include attributes as detailed in the table below.




1671BUse of alternate name forms shall be defined in the applicable CPS, including criticality, types, and name constraints.

1672BOPTION 1673BUSAGE 1674BATTRIBUT

E 1675BREQUIRED

COUNT 1676BCONTENT

1677B1 1678BRecommended

1679BCN 1680B0…1 1681BDescriptive name for CA, e.g., “CN=XYZ Inc CA”

1682BOptional 1683BOU 2483B0…N 1684BAs needed

1685BRecommended

1686BOU 1687B0…1 1688B“Certification Authorities” or similar text

1689BRequired 1690BO 1691B1 1692BIssuer name, e.g., “O=XYZ Inc”

1693BRequired 1694BC 1695B1 1696BCountry name, e.g., “C=US”

1697B2 1698BRecommended

1699BCN 1700B0…1 1701BDescriptive name for CA, e.g., “CN=XYZ Inc CA”


1706BRecommended

1707BOU 1708B0…1 1709B“Certification Authorities” or similar text

1710BOptional 1711BO 1712B0…1 1713BIssuer name, e.g., “O=XYZ Inc”

1714BOptional 1715BC 1716B0…1 1717BCountry name, e.g., “C=US”

1718BRequired 1719BDC 1720B1 1721BDomain name, e.g., “DC=xyzinc”

1722BRequired 1723BDC 1724B1…N 1725BDomain root label(s), e.g., “DC=com” or, “DC=com, DC=au”, etc.

1726BSubject Name Form (Non-CAs)


E 1730BREQUIRED

COUNT 1731BCONTENT

1732B1 1733BRequired 1734BSee Content

description

2484B1…N 2485BAdditional naming attributes for uniquely identifying the subject including common name, serialNumber, email, employeeNumber, etc.


1739BRequired 1740BO 1741B1 1742BIssuer name, e.g., “O=XYZ Inc” exactly as it appears in the CA certificate(s)

1743BRequired 1744BC 1745B1 1746BCountry name, e.g., “C=US” exactly as it appears in the CA certificate(s)





E 1730BREQUIRED

COUNT 1731BCONTENT

1747B2 1748BRequired 1749BSee Content

description

1750B1…N 1751BAdditional naming attributes for uniquely identifying the subject including common name, serialNumber, email, employeeNumber, etc.


1756BOptional 1757BO 1758B0…1 1759BIssuer name, e.g., “O=XYZ Inc”

1760BRequired 1761BDC 1762B1 1763BDomain name, e.g., “DC=xyzinc” exactly as it appears in the CA certificate(s)

1764BRequired 1765BDC 1766B1…N 1767BDomain root label(s), e.g., “DC=com” or, “DC=com, DC=au”, etc. exactly as it appears in the CA certificate(s)

1768BWhen multiple values exist for an attribute in a DN, the DN shall be encoded so that each attribute value is encoded in a separate relative distinguished name.

7.1.5 380BName Constraints 1769BRaytheon CAs may assert critical or non-critical name constraints beyond those specified in the Certificate Formats in Section 10 subject to the requirements above. 1770BThe Issuer CA may establish a pseudonymous Subscriber Subject name to meet local privacy regulations as long as such name is unique and traceable to a specific subscriber name. Issuer names may not be pseudonymous. Issuer CAs may assert critical or non-critical name constraints beyond those specified in the Certificate Formats.

7.1.6 381BCertificate Policy Object Identifier 1771BCA and Subscriber Certificates issued under this CP shall assert one or more of the certificate policy OIDs listed in Section 1.2 of this document. This CP document assumes a strict ordering among these policies, with high-hardware being the highest assurance. When a CA asserts a policy OID, it shall also assert all lower assurance policy OIDs. For example:

1. 1772BIf a CA issues a high-hardware certificate, it shall assert all other policy OIDs in the certificate.

2. 1773BIf a CA issues a medium-software certificate, only medium-CBP-software policy OIDs shall also be asserted in the certificate.

3. 1774BIf a CA issues a medium-CBP-software certificate, no other policy OID from Section 1.2 of this document shall be asserted in the certificate.

4. 1775BIf a CA issues SHA-1 end entity certificates after 12/31/2010, the CA may not use “id-raytheon-SHA2-…..” certificate policy OIDs in the end entity certificates.

7.1.7 382BUsage of Policy Constraints Extension 1776BRaytheon CAs shall adhere to the certificate formats described in this CP since inhibiting policy mapping may limit interoperability.




7.1.8 383BPolicy Qualifiers Syntax and Semantics 1777BCertificates issued under the Raytheon CP may contain the following policy qualifiers such as user notice, policy name, and CP and CPS pointers.

7.1.9 384BProcessing Semantics for the Critical Certificate Policy Extension 1778BProcessing semantics for the critical certificate policy extension shall conform to X.509 certification path processing rules.




7.2 170BCRL PROFILE

7.2.1 385BVersion Numbers 1779BCAs shall issue X.509 version two (v2) CRLs (populate version field with integer "1").

7.2.2 386BCRL and CRL Entry Extensions 1780BCritical private extensions shall be interoperable in their intended community of use. 1781BSection 10 shall contain the CRL formats.

7.3 171BOCSP PROFILE 1782BOCSP requests and responses shall be in accordance with RFC 2560. Section 10 contains the OCSP request and response formats.

7.3.1 387BVersion Number 1783BThe version number for request and responses shall be v1.

7.3.2 388BOCSP Extensions 1784BResponses should support the nonce extension. 1785BPractice Note: OCSP Responders that choose not to respond with a nonce to a nonced request may encounter OCSP clients that cannot process the response. This should result in a failover to CRL checking, however there is some question as to whether all clients will process this successfully.




8 121BCOMPLIANCE AUDIT AND OTHER ASSESSMENTS 1786BThe Raytheon Policy Management Authority, working with the Raytheon Operational Authority shall have a compliance audit mechanism in place to ensure that the requirements of applicable Agreements, this CP and applicable CPS are being implemented and enforced.

8.1 172BFREQUENCY OR CIRCUMSTANCES OF ASSESSMENTS 1787BThe CAs, RAs, and CSAs shall be subject to a periodic compliance audit at least once per year. 1788BThe CAs have the right to require periodic and aperiodic compliance audits or inspections of subordinate CA or RA operations to validate that the subordinate entities are operating in accordance with the security practices and procedures described in their respective CPS. Further, the RPMA has the right to require aperiodic compliance audit of the RRCA (and, when needed, their subordinate CAs) and Raytheon Signing CAs that interoperate with the Raytheon CAs under this CP. The RPMA shall state the reason for any aperiodic compliance audit.

8.2 173BIDENTITY AND QUALIFICATIONS OF ASSESSOR 1789BThe compliance auditor shall demonstrate competence in the field of compliance audits, and shall be thoroughly familiar with requirements of this CP. The compliance auditor must perform such compliance audits as a primary responsibility. The applicable CPS shall identify the compliance auditor and justify the compliance auditor's qualifications.

8.3 174BASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY 1790BThe compliance auditor shall either represent 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 may be an organizational audit department provided it can demonstrate organizational separation and independence. To further ensure independence and objectivity, the compliance auditor may not have served the entity in developing or maintaining the entity’s PKI Facility, associated IT and network systems, or certificate practices statement. 1791BIn the event an entity chooses to engage compliance auditor services internal to its parent organization, it shall undergo an audit from an external third party audit firm every third year, at a minimum.

8.4 175BTOPICS COVERED BY ASSESSMENT 1792BThe purpose of a compliance audit shall be to verify that a component operates in accordance with this CP, applicable CPS, and the applicable Agreements between the Raytheon PKI, CertiPath, and other Entities. The compliance audit must include an assessment of the applicable CPS against this CP, to determine that the CPS adequately addresses and implements the requirements of this CP.

8.5 176BACTIONS TAKEN AS A RESULT OF DEFICIENCY 1793BThe RPMA may determine that a CA is not complying with its obligations, as set forth in this CP, CPS or Agreement. When such a determination is made, the RPMA may suspend operation of the affected CA until a remediation has been performed. When such a determination is made, the RPMA may direct the Raytheon Operational Authority to cease




interoperating with the affected CA (e.g., by revoking the cross or subordinate certificate issued to the CA), or may direct that other corrective actions be taken which allow interoperation to continue. If the compliance auditor finds a discrepancy between how the CA is designed or is being operated or maintained, and the requirements of this CP, the applicable CPS, or applicable Agreement, the following actions shall be performed:

• 1794BThe compliance auditor shall note the discrepancy;

• 459BThe compliance auditor shall notify the CA of the discrepancy. The CA shall notify the RPMA promptly and communicate the discrepancy mitigation plan;

• 1795BThe party responsible for correcting the discrepancy shall determine what further notifications or actions are necessary pursuant to the requirements of this CP and the Agreement, and then proceed to make such notifications and take such actions without delay.

1796BDepending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the RPMA may decide to halt temporarily operation of a Raytheon CA, to revoke a certificate issued by a Raytheon CA, or take other actions it deems appropriate. The RPMA shall develop procedures for making and implementing such determinations.

8.6 177BCOMMUNICATION OF RESULTS 1797BAn Audit Compliance Report package, including identification of corrective measures taken or being taken by the Raytheon PKI, shall be provided to the CertiPath PMA as set forth in Section 8.1. This package shall be prepared in accordance with the “Compliance Audit Reference Documents” and must include an assertion from the Raytheon PMA that all PKI components have been audited - including any components that may be separately managed and operated. The package shall identify the versions of the CP and CPS used in the assessment. Additionally, where necessary, the results shall be communicated as set forth in 8.5 above.




9 122BOTHER BUSINESS AND LEGAL MATTERS

9.1 178BFEES

9.1.1 389BCertificate Issuance and Renewal Fees 1798BRaytheon may set any reasonable certificate issuance and renewal fees.

9.1.2 390BCertificate Access Fees 1799BRaytheon does not charge for access to certificates.

9.1.3 391BRevocation or Status Information Access Fees 1800BRaytheon does not charge for access to revocation or status information.

9.1.4 392BFees for Other Services 1801BRaytheon may set any reasonable fees for any other services a Raytheon CA may offer.

9.1.5 393BRefund Policy 1802BNo stipulation.

9.2 179BFINANCIAL RESPONSIBILITY 1803BOrganizations acting as relying parties shall determine the financial risk, if any; they undertake when accepting certificates to consummate any transaction. Acceptance of Raytheon issued certificates is entirely at the discretion of the organization acting as a relying party. Other factors that may influence the relying party’s acceptance, in addition to the certificate assurance level, are the likelihood of fraud, other procedural controls in place, organizational-specific policy, or statutorily imposed constraints.

9.2.1 394BInsurance Coverage 1804BRaytheon maintains reasonable levels of insurance coverage.

9.2.2 395BOther Assets 1805BRaytheon maintains sufficient financial resources to maintain operations and fulfill duties.

9.2.3 396BInsurance or Warranty Coverage for End-Entities 1806BRaytheon does not offer insurance or warranty coverage to end entities.

9.3 180BCONFIDENTIALITY OF BUSINESS INFORMATION 1807BThe treatment of confidential business information provided to the RPMA in the context of submitting an application for cross certification shall be in accordance with the terms of the agreements entered into between Raytheon and the entity CA. 1808BThe Raytheon CA shall maintain the confidentiality of confidential business information that is clearly marked or labeled as confidential, or by its nature should reasonably be understood to be confidential, and shall treat such information with the same degree of care and security as Raytheon treats its own most confidential information.




9.4 181BPRIVACY OF PERSONAL INFORMATION 99BRaytheon collects, stores, processes and discloses personally identifiable information in accordance with the Raytheon Privacy Policy, located at http://www.raytheon.com/legal/, except that the storage of PII shall be limited to the minimum necessary to validate the identity of the Subscriber. This may include attributes that correlate identity evidence to authoritative sources. The RA shall provide explicit notice to the Subscriber regarding the purpose for storing a record of the PII necessary for identity proofing and the consequences for not providing the information. PII stored for identity proofing purposes shall not be used for any other purpose.

9.5 182BINTELLECTUAL PROPERTY RIGHTS 1809BRaytheon shall retain ownership and all intellectual property rights for any public key certificates and private keys that it issues.

9.5.1 397BProperty Rights in Certificates and Revocation Information 1810BRaytheon CAs retain all Intellectual Property Rights in and to the Certificates and revocation information that they issue. Raytheon grants permission to reproduce and distribute Certificates on a nonexclusive royalty-free basis, provided that they are reproduced in full and that use of Certificates is subject to a Relying Party Agreement with relevant CA where applicable. Raytheon shall grant permission to use revocation information to perform Relying Party functions, subject to applicable contractual agreements.

9.5.2 398BProperty Rights in the CPS 1811BAll Intellectual Property Rights in this CP are owned by Raytheon and/or its licensors. All Intellectual Property Rights in any CP or CPS of a Raytheon CA or subordinate CA are owned by the Raytheon CA and/or its licensors.

9.5.3 399BProperty Rights in Names 1812BAs between Raytheon and a Certificate Applicant, the Certificate Applicant retains all rights, if any, in any trademark, service mark, or trade name of the Certificate Applicant contained in any Customer Application.

9.5.4 400BProperty Rights in Keys 1813BKey pairs corresponding to Certificates issued by Raytheon CAs are the property of Raytheon Company.

9.6 183BREPRESENTATIONS AND WARRANTIES 1814BRepresentations and warranties contained in commercial agreements between Raytheon and other parties are contained in the following documents:

• 1815BPolicy Mapping Services Agreement between Raytheon and CertiPath

• 1816BMaster Services Agreement between Raytheon and CertiPath

• 1817BApplicable Memorandums of Agreement 1818BThe above listed documents may contain additional and/or supplemental representations and warranties between the parties.




9.6.1 401BCA Representations and Warranties 1819BRaytheon certificates are issued at the sole discretion of the Raytheon PKI PMA. In the event a Raytheon CA issues a cross certificate to a non-Raytheon CA, it does so for the convenience of Raytheon.

9.6.1.1 Raytheon Root CA 1820BRaytheon represents and warrants that, to its knowledge:

• 1821BThere are no material misrepresentations of fact in the Cross Certificates known to or originating from the ROA approving the Cross Certification Applications or issuing the Cross Certificates.

• 1822BThere are no errors in the information in the Cross Certificates that were introduced by the ROA approving the Cross Certification Application or issuing the Cross Certificate as a result of a failure to exercise reasonable care in managing the Certificate Application or creating the Certificate.

• 1823BIts Certificates meet all material requirements of this CP.

• 1824BRevocation services and use of a repository conform to the applicable CPS in all material respects.

• 1825BThe CA signing private key is protected and that no unauthorized person has ever had access to the private key;

• 1826BAll representations made by the Raytheon CA in any applicable agreements are true and accurate in all material respects;

• 1827BAll information supplied by the Subscribers and CA subjects in connection with, and/or contained in the Certificate is true and accurate in all material respects.

• 1828BThe Certificates are being used by the CA exclusively for authorized and legal purposes, consistent with this CP and applicable CPS.

1829BThe applicable contractual agreements may include additional representations and warranties.

9.6.1.2 451BRaytheon Subordinate or Cross-Certified CA 1830BRaytheon represents and warrants that, to its knowledge:

• 84BThe CA signing key is protected and that no unauthorized person has ever had access to that private key.

• 85BAll representations made with respect to a Raytheon CA in the applicable agreements are true and accurate, in all material respects.

• 86BAll information supplied by the Subscribers and Subject CAs in connection with, and/or contained in the Certificate is true and accurate in all material respects;

• 87BThe Certificates are being used by the CA exclusively for authorized and legal purposes, consistent with this CP or applicable CPS.




9.6.2 402BSubscriber 1831BA Subscriber shall be required to sign a document (e.g., a subscriber agreement) requiring that the Subscriber satisfy certain obligations including, but not limited to:

• 1832BSubscriber shall accurately represent itself in all communications with the issuing PKI authorities.

• 1833BSubscriber shall promptly notify the appropriate CA upon suspicion of loss or compromise of its private keys. Such notification shall be made directly or indirectly through mechanisms consistent with the issuing CA’s CPS

1834BIn signing the document described above, each Subscriber shall represent and warrant that:

• 1835BThe data contained in any certificates issued to the Subscriber is accurate;

• 1836BThe Subscriber lawfully holds the private key corresponding to the public key identified in the Subscriber’s certificate;

• 1837BThe Subscriber will protect its private keys at all times, in accordance with this policy, as stipulated in the certificate acceptance agreements, and local procedures; and

• 1838BThe Subscriber will abide by all the terms, conditions, and restrictions levied on the use of the private keys and certificates.

1839BPKI Sponsors (as described in Section 5.2.1.4) assume the obligations of Subscribers for the certificates associated with their devices.

9.6.3 403BRelying Party 1840BParties who rely upon the certificates issued under a policy defined in this document shall:

• 88BUse the certificate for the purpose for which it was issued, as indicated in the certificate information (e.g., the key usage extension);

• 89BCheck each certificate for validity, using procedures described in the X.509 standard [ISO 9594-8], prior to reliance;

• 90BEstablish trust in the CA that issued the certificate by verifying the certificate path in accordance with the guidelines set by the X.509 Version 3 Amendment;

• 91BPreserve original signed data, the applications necessary to read and process that data, and the cryptographic applications needed to verify the digital signatures on that data for as long as it may be necessary to verify the signature on that data. Note: data format changes associated with application upgrades will often invalidate digital signatures and shall be avoided.

9.6.4 404BRegistration Authority 1841BA Raytheon Registration Authority (RA) who performs registration functions as described in one or more of the policies in this CP shall comply with the stipulations of this CP and comply with the respective CPS approved by the RPMA for use with this CP. An RA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of RA responsibilities. RAs shall protect Subscriber personally identifiable information in accordance with the Raytheon Privacy Policy.




9.6.5 405BRepresentations and Warranties of Other Participants 1842BRepositories that support a Raytheon CA in posting information as required by one or more of the policies in this CP shall:

• 92BMaintain availability of the information as required by the certificate information posting and retrieval stipulations of one or more of the policies in this CP;

• 93BProvide access control mechanisms sufficient to protect repository information as described in Section 2.4.

1843BA CSA that has been issued a Raytheon PKI Certificate shall conform to the stipulations of this document including operating under a CPS that has been approved by the RPMA. Such CSAs who are found to have acted in a manner inconsistent with these obligations are subject to action as described in Section 8.5. 1844BAll CSAs that provide Raytheon relying parties with revocation status for certificates that assert a policy defined in this document shall conform to the following:

• 94BProvide to the RPMA a CPS, as well as any subsequent changes;

• 95BConform to the stipulations of the submitted CPS;

• 96BEnsure that certificate and revocation information is accepted only from valid Raytheon approved CAs; and

• 97BMaintain evidence that due diligence was exercised in validating the certificate status.

9.7 184BDISCLAIMERS OF WARRANTIES 1845BTo the extent permitted by applicable law, Policy Mapping Agreements, Cross Certificates Agreements, and any other related agreements may contain disclaimers of all warranties, other than any express warranties contained in such agreements or set forth in this CP, whether express, implied or statutory, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement of third party rights. 1846BTO THE EXTENT PERMITTED BY APPLICABLE LAW, RAYTHEON CAS MAY DISCLAIM ANY EXPRESS OR IMPLIED WARRANTIES, OTHER THAN THOSE EXPRESS WARRANTIES CONTAINED IN THIS CP. EXCEPT FOR THE EXPLICIT REPRESENTATIONS, WARRANTIES, AND CONDITIONS PROVIDED IN THIS CP OR THOSE BETWEEN RAYTHEON AND ITS CUSTOMERS UNDER SEPARATE AGREEMENTS, (A) CERTIFICATES ISSUED BY RAYTHEON ARE PROVIDED "AS IS", AND RAYTHEON, ITS EMPLOYEES, OFFICERS, AGENTS, REPRESENTATIVES, AND DIRECTORS DISCLAIM ALL OTHER WARRANTIES, CONDITIONS AND OBLIGATIONS OF EVERY TYPE (INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, TITLE, SECURITY, SATISFACTORY QUALITY, OR FITNESS FOR A PARTICULAR PURPOSE, OR ACCURACY AND COMPLETENESS OF INFORMATION PROVIDED), AND FURTHER DISCLAIM ANY AND ALL LIABILITY FOR NEGLIGENCE, FAILURE TO WARN, OR LACK OF REASONABLE CARE AND (B) THE ENTIRE RISK OF THE USE OF ANY CERTIPATH CERTIFICATES, ANY SERVICES PROVIDED BY CERTIPATH, OR THE VALIDATION OF ANY DIGITAL SIGNATURES LIES WITH THE APPLICABLE PARTICIPANT.




9.8 185BLIMITATIONS OF LIABILITIES 1847BA non-Raytheon Subscriber or entity shall have no claim against Raytheon arising from or relating to any certificate issued by a Raytheon CA or a CA's determination to terminate a certificate. Raytheon is not liable for any losses, including direct or indirect, incidental, consequential, special, or punitive damages. 1848BOTHER THAN THE ABOVE DESCRIBED LIMITATIONS OF LIABILITY, TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL RAYTHEON BE LIABLE FOR ANY INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER ARISING OUT OF OR RELATED TO THIS CP, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE TOTAL, AGGREGATE LIABILITY ARISING OUT OF OR RELATED TO IMPROPER ACTIONS SHALL BE LIMITED TO ONE THOUSAND DOLLARS ($1,000 USD) PER TRANSACTION AND ONE MILLION DOLLARS ($1 MILLION USD) PER INCIDENT).

9.9 186BINDEMNITIES

9.9.1 406BIndemnification by Cross Certified CAs 1849BTo the extent permitted by applicable law with respect to certificates issued by Cross Certified CAs, Cross Certified CAs are required to indemnify Raytheon for:

• 1850BFalsehood or misrepresentation of fact by the Cross Certified CA in the applicable contractual agreements.

• 1851BFailure by the Cross Certified CA to disclose a material fact in any applicable contractual agreement, if the misrepresentation or mission was made negligently or with intent to deceive any party.

• 1852BThe Cross Certified CA failure to protect the Cross Certified CA private key, to use a Trustworthy System, or to otherwise take the precautions necessary to prevent the compromise, loss, disclosure, modification, or unauthorized use of the Cross Certified CA private key, or;

• 1853BThe Cross Certified CA use of a name (including without limitation within a common name, domain name, or e-mail address) that infringes upon the Intellectual Property Rights of a third party.

1854BAny applicable contractual agreement may include additional indemnity obligations.

9.9.2 407BIndemnification by Relying Parties 1855BTo the extent permitted by applicable law, each Relying Party shall indemnify Raytheon and its contractors, agents, assigns, employees, officers, and directors from and against any third party claims, liabilities, damages, costs and expenses (including reasonable attorney’s fees), relating to or arising out of the use of or reliance by the Relying Party on any certificates issued by Raytheon, including, without limitation:

• 1856BThe Relying Party’s improper, illegal, or unauthorized use of a Certificate (including use of any expired, revoked, or unvalidated Certificate);

• 1857BThe Relying Party’s unreasonable reliance on a Certificate, given the circumstances, or;




• 1858BThe Relying Party’s failure to check the status of a Certificate on which it relies to determine if he Certificate is expired or revoked.

1859BAny applicable contractual agreement between Raytheon and a Relying Party with respect to the Raytheon PKI may include additional indemnity obligations, but these obligations would not apply to relying parties that are not customers of Raytheon.

9.10 187BTERM AND TERMINATION

9.10.1 408BTerm 1860BThe CP becomes effective upon recommendation of the RPMA, approval of the Raytheon Chief Information Security Officer (CISO), and publication in the Raytheon Repository as a PDF document. Amendments to this CP become effective upon recommendation of the RPMA, approval of the Raytheon CISO, and publication at: 1861Bhttp://www.raytheon.com/pki/library/ 1862BThere is no specified term for this CP.

9.10.2 409BTermination 1863BWhile this CP may be amended from time to time, it shall remain in force until replaced by a newer version or terminated by recommendation of the RPMA and approval of the Raytheon CISO. For purposes of clarity, termination of any Agreement shall not operate as a termination of this CP unless this CP is explicitly terminated by a separate resolution of the Raytheon CISO. 1864BThis CP shall survive any termination of a Raytheon CA issuing certificates in accordance with policies set forth in this CP. The requirements of this CP remain in effect through the end of the archive period for the last certificate issued.

9.10.3 410BEffect of Termination and Survival 1865BUpon termination of this CP, CAs cross certified with or subordinate to Raytheon are nevertheless bound by its terms for all Certificates issued for the remainder of the validity periods of such Certificates. The following sections of this CP shall survive the termination of this CP: 2.1.1, 2.2, 5.4, 5.5, 6.2-6.4, 6.8, 9.2-9.4, 9.7-9.10, 9.13-9.16. 1866BThe responsibilities for protecting business confidential and personal information and Raytheon’s intellectual property rights shall survive termination of this CP. 1867BRaytheon’s right, title, and interest in all of its intellectual property rights, including owernship of any public key certificates and private keys issued pursuant to this CP shall survive termination of this CP.

9.11 188BINDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS 1868BUnless otherwise specified by agreement between the parties, Raytheon shall use commercially reasonable methods to communicate with cross-certified or subordinate CAs, taking into account the criticality and subject matter of the communication. 1869BThe CA Operational Authority, RA or TA may be removed from their duties by their supervisor and/or an authorized individual. Notice is effective when given; oral notification shall be confirmed in writing.

http://www.raytheon.com/pki/library/




1870BIf the termination is for convenience, contract expiration, re-organization, or other non-security related reason, and provisions have been made to continue compromise recovery within the timeframes specified in the Raytheon Disaster Recovery Plan (including destruction or continued protection of signing key), compliance and security audit, archive, and data recovery services, then neither the terminated CAs certificate, nor certificates signed by that CA, need to be revoked. 1871BIf provisions for maintaining these services cannot be made, then the CA termination shall be handled as a CA compromise in accordance with Sections 5.7.3 and 5.7.4 above. 1872BPrior to CA termination, CAs shall provide archived data to a RPMA approved Raytheon archival facility. 1873BAny planned change to the infrastructure of a CA that has the potential to affect the CertiPath operational environment shall be communicated to the CertiPath PMA at least two weeks prior to implementation, and any new CA certificates produced as a result of the change provided to the CPMA within 24 hours following implementation.

9.12 189BAMENDMENTS

9.12.1 411BProcedure for Amendment 1874BThe Raytheon PMA shall review the CP and CPS at least once every year. Additional reviews may be enacted at any time at the discretion of the RPMA or at the request of the Raytheon CISO. 1875BIf the RPMA wishes to recommend amendments or corrections to the CP or CPS, such modifications shall be voted on by members of the RPMA following procedures documented in the Raytheon PKI PMA Charter for Operations. Following approval of any modifications, public notification of amendments shall be made. 1876BThe RPMA shall use commercially reasonable efforts to immediately notify Subordinate and Cross Certified CAs of Certificate Policy changes. CAs shall notify Subscribers of any changes to the certificate policy via a mechanism described in its CPS. 1877BNotwithstanding the foregoing, if the Raytheon PMA believes that material amendments to the CP are necessary immediately to stop or prevent a breach of the security of Raytheon, Raytheon shall be entitle to make such amendments effective immediately upon publication in the Raytheon Repository.

9.12.2 412BNotification Mechanism and Period 1878BChanges to the CP resulting from reviews are published online internally. In addition, changes are communicated to every Raytheon PMA member and cross-certifying partners, including a description of the change. 1879BThis CP and any subsequent changes shall be made publicly available within 7 days of approval.




9.12.3 413BCircumstances under Which OID Must be Changed 1880BCertificate Policy OIDs shall be changed if the RPMA determines that a change in the CP reduces the level of assurance provided.

9.13 190BDISPUTE RESOLUTION PROVISIONS

9.13.1 414BDisputes among Raytheon and Customers 1881BProvisions for resolving disputes between Raytheon and its Customers shall be set forth in the applicable agreements between the parties.

9.13.2 415BAlternate Dispute Resolution Provisions 1882BExcept as otherwise agreed (e.g., under an agreement described in Section 9.13.1 above), any dispute under this CP shall be resolved by binding arbitration in accordance with the commercial rules (or international rules, if the other party to the dispute is a non-US entity) of the American Arbitration Association then in effect. The arbitration panel shall consist of one (1) neutral arbitrator if the amount in controversy is less than $10,000, otherwise the panel shall consist of three (3) neutral arbitrators, each an attorney with five (5) or more years of experience in computer and technology law and/or the primary area of law as to which the dispute relates. The arbitrator(s) shall have never been employed (either as an employee or as an independent consultant) by either of the Parties, or any parent, subsidiary or affiliate thereof. The Parties shall have the right to take discovery of the other Party by any or all methods provided in the Federal Rules of Civil Procedure. The arbitrator(s) may upon request exclude from being used in the arbitration proceeding any evidence not make available to the other Party pursuant to a proper discovery request. The arbitrator(s) shall apply federal law of the United States and/or the law of the State of Massachusetts, and the arbitration proceeding shall be held in Massachusetts, USA or in such other location as is mutually agreed upon. The cost of the arbitration shall be borne equally by the Parties, unless the arbitrator(s) awards costs and attorneys fees to the prevailing Party. Notwithstanding the choice of law provision in this Agreement, the Federal Arbitration Act, except as modified herein, shall govern the interpretation and enforcement of this provision. All arbitration proceedings shall be conducted in English. Any claim, dispute and controversy shall be arbitrated on an individual basis and not aggregated with the claims of any third party. Class action arbitration is prohibited. The arbitrator(s) shall have no discretion to award punitive damages. Notwithstanding the foregoing dispute resolution procedures, either Party may apply to any court having jurisdiction to (i) enforce the agreement to arbitrate, (ii) seek provisional injunctive relief so as to maintain the status quo until the arbitration award is rendered or the dispute is otherwise resolved, or to otherwise prevent irreparable harm, (iii) avoid the expiration of any applicable limitation period, (iv) preserve a superior position with respect to creditors, or (v) challenge or vacate any final decision or award of the arbitration panel that does not comport with the express provisions of this CP.

9.14 191BGOVERNING LAW 1883BThe laws of the Commonwealth of Massachusetts and the federal laws of the United States shall govern the enforceability, construction, interpretation, and validity of this CP, without regard to its rules on choice of law. Agreements incorporating the CP by reference may have their own governing law provisions, provided that this Section 9.14 governs the enforceability,




construction, interpretation, and validity of the terms of the CP separate and apart from the terms of such other agreements.

9.15 192BCOMPLIANCE WITH APPLICABLE LAW 1884BThis CP and any confidential business and personal information that may be shared pursuant to its terms is subject to applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions on exporting or importing software, hardware, or technical information. In no event will any information made available pursuant to this CP be disclosed in any manner to the national of any country where such disclosure is prohibited by applicable United States law or regulation or to any Foreign Person (as defined in Section 120.16 of the International Traffic in Arms Regulations) without Raytheon’s express written consent and after obtaining necessary export licenses.

9.16 193BMISCELLANEOUS PROVISIONS

9.16.1 416BEntire Agreement 1885BNo stipulation.

9.16.2 417BAssignment 1886BExcept where specified by other contracts, no party may assign or delegate this CP or any of its rights or duties under this CP, without the prior written consent of the other party (such consent not to be unreasonably withheld, except that Raytheon may assign and delegate this CP to any party of its choosing.

9.16.3 418BSeverability 1887BIf any provision of this CP is held to be invalid by a court of competent jurisdiction, then the remaining provisions will nevertheless remain in full force and effect until the CP is updated. The process for updating this CP is described in section 9.12.

9.16.4 419BWaiver of Rights 1888BNo waiver of any breach or default or any failure to exercise any right hereunder shall be construed as a waiver of any subsequent breach or default or relinquishment of any future right to exercise such right. The headings in this CP are for convenience only and cannot be used in interpreting this CP.

9.16.5 420BForce Majeure 1889BRaytheon shall not be liable for any failure or delay in its performance under this CP due to causes that are beyond its reasonable control, including, but not limited to, an act of God, act of civil or military authority, fire, epidemic, flood, earthquake, riot, war, failure of equipment, failure of telecommunications lines, lack of Internet access, sabotage, and governmental action. RAYTHEON HAS NO LIABILITY FOR ANY DELAYS, NON-DELIVERIES, NON-PAYMENTS, MIS-DELIVERIES OR SERVICE INTERRUPTIONS CAUSED BY ANY THIRD PARTY ACTS OR THE INTERNET INFRASTRUCTURE OR ANY NETWORK EXTERNAL TO RAYTHEON.

9.17 194BOTHER PROVISIONS 1890BNo stipulation.







10 123BCERTIFICATE, CRL, AND OCSP FORMATS 1891BThis section contains the formats for the various PKI objects such as certificates, CRLs, and OCSP requests and responses. It only contains certificate profiles based on RSA. For algorithm identifiers, parameter encoding, public key encoding, and signature encoding for ECDSA and ECDH, RFC3279 shall be used. 1892BCertificates and CRLs issued under a policy OID of this CP may contain extensions not listed in the profiles in this section only upon RPMA approval. 1893BFirst entries in the caIssuers field of the AIA extension and CRL DP shall point to a resource that is publicly available using HTTP. If LDAP pointers are used, they shall appear only after the HTTP pointers. 1894BFor attribute values other than dc: All CA Distinguished Names (in various fields such as Issuer, Subject, Subject Alternative Name, Name constraints, etc.) shall be encoded as a printable string. All subscriber DN portions to which name constraints apply, shall be encoded as a printable string. Other portions of the subscriber DN shall be encoded as a printable string if possible. If a portion cannot be encoded as a printable string, then and only then shall it be encoded using a different format and that format shall be UTF8. 1895BFor dc and email address attribute values: All dc attribute values shall be encoded as IA5 string. 1896BCAs may issue partitioned CRLs as long as the CRLs are not indirect CRLs, are not partitioned by reason code, and the CRL DP and Issuing Distribution Point do not assert a name relative to the issuer. If the Entity PKI provides OCSP services for a CA, that CA must also issue a full and complete CRL (i.e., a CRL without Issuing Distribution Point extension) for use by the OCSP Responder.




10.1 195BRAYTHEON ROOT CA CBCA CROSS-CERTIFICATE 2486BField 2487BValue 2488BVersion 2489BV3 (2) 2490BSerial Number 2491BMust be unique 2492BIssuer Signature Algorithm 2493Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2494Bsha-256 WithRSAEncryption {1 2 840 113549 1 1 11} per Section Error! Reference source not found.

2495BIssuer Distinguished Name 2496Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or, 100Bcn=Raytheon Root CA,ou=RaytheonRoot-g2,o=CAs,dc=raytheon,dc=com

2497BValidity Period 2498BUp to one year for SHA-1 using compensating controls or 5 years for SHA-256 expressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

2499BSubject Distinguished Name 2500Bcn=CertiPath Bridge CA, ou=Certification Authorities, o=CertiPath LLC, c=us or, 2501BCN=CertiPath Bridge CA - G2, OU=Certification Authorities, O=CertiPath LLC, C=US

2502BSubject Public Key Information

2503B2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}

2504BIssuer’s Signature 2505Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or 2506Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11}

2507BExtension 2508BValue 2509BAuthority Key Identifier 2510Bc=no; Octet String (same as in RRCA PKCS-10 request to the CBCA) 2511BSubject Key Identifier 2512Bc=no; Octet String (same as in PKCS-10 request from the CBCA) 2513BKey Usage 2514Bc=yes; keyCertSign, cRLSign ,DigitalSignature (optional),

nonRepudiation (optional)




2515BCertificate Policies 2516Bc=no; 2517BSHA-1: {1.3.6.1.4.1.1569.10.1.1} {1.3.6.1.4.1.1569.10.1.2} {1.3.6.1.4.1.1569.10.1.3} {1.3.6.1.4.1.1569.10.1.4} {1.3.6.1.4.1.1569.10.1.5} {1.3.6.1.4.1.1569.10.1.8} {1.3.6.1.4.1.1569.10.1.9} or 2518BSHA-256: {1.3.6.1.4.1.1569.10.1.11} {1.3.6.1.4.1.1569.10.1.12} {1.3.6.1.4.1.1569.10.1.13} {1.3.6.1.4.1.1569.10.1.14} {1.3.6.1.4.1.1569.10.1.15} {1.3.6.1.4.1.1569.10.1.18} {1.3.6.1.4.1.1569.10.1.19}

2519BPolicy Mapping 1897BFor SHA-1 signed certificates: 2520Bc=no; [{1.3.6.1.4.1.1569.10.1.3} {1.3.6.1.4.1.24019.1.1.1.17}] 2521B[{1.3.6.1.4.1.1569.10.1.2} {1.3.6.1.4.1.24019.1.1.1.18}] 2522B[{1.3.6.1.4.1.1569.10.1.1} {1.3.6.1.4.1.24019.1.1.1.19}] 2523B[{1.3.6.1.4.1.1569.10.1.5} {1.3.6.1.4.1.24019.1.1.1.20}] 2524B[{1.3.6.1.4.1.1569.10.1.4} {1.3.6.1.4.1.24019.1.1.1.21}] 2525B[{1.3.6.1.4.1.1569.10.1.3} {1.3.6.1.4.1.24019.1.1.1.18}] 2526B[{1.3.6.1.4.1.1569.10.1.9} {1.3.6.1.4.1.24019.1.1.1.25}] 2527B[{1.3.6.1.4.1.1569.10.1.8} {1.3.6.1.4.1.24019.1.1.1.26}] 1898BFor SHA-256 signed certificates: 2528Bc=no; [{1.3.6.1.4.1.1569.10.1.13} {1.3.6.1.4.1.24019.1.1.1.1}] 2529B[{1.3.6.1.4.1.1569.10.1.12} {1.3.6.1.4.1.24019.1.1.1.2}] 2530B[{1.3.6.1.4.1.1569.10.1.11} {1.3.6.1.4.1.24019.1.1.1.3}] 2531B[{1.3.6.1.4.1.1569.10.1.15} {1.3.6.1.4.1.24019.1.1.1.4}] 2532B[{1.3.6.1.4.1.1569.10.1.14} {1.3.6.1.4.1.24019.1.1.1.5}] [{1.3.6.1.4.1.1569.10.1.19} {1.3.6.1.4.1.24019.1.1.1.23}] 2533B[{1.3.6.1.4.1.1569.10.1.18} {1.3.6.1.4.1.24019.1.1.1.24}]

2534BBasic Constraints 2535Bc=yes; cA=True; path length constraint = Absent 2536BName Constraints 2537Bc=yes; excluded subtrees:

2538BRFC822Name Mail: .raytheon.com 2539BRFC822Name Mail: raytheon.com 2540BDNSName: raytheon.com 2541BDirectoryName: o=Raytheon.com, c=us 2542BDirectoryName: dc=raytheon, dc=com

2543BCRL Distribution Points8F

9 2544Bc=no 2545BInhibit anyPolicy 2546Bc=no; skipCerts = 0

9 The CRL distribution point extension shall only populate the distributionPoint field. The distributionPoint field shall contain HTTP (i.e., of the form http://…) URI. The distributionPoint field may contain LDAP (i.e., of the form ldap://…) URI. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL or a Distribution Point based partitioned CRL. The Distribution Point field shall contain a full name (i.e, the Distribution Point field shall not contain nameRelativetoCRLIssuer).




10.2 196BPKCS 10 REQUEST 2547BField 2548BValue 2549BVersion 2550BV1 (0) 2551BSubject Distinguished Name 2552BUnique X.500 subject DN within the namespace dc=raytheon, dc=com

as specified in Section 7.1.4 of the Raytheon CP. 2553BSubject Public Key Information

2554B2048 bit modulus, rsaEncryption {1 2 840 113549 1 1 1}

2555BSubject’s Signature 2556Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or 2557Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11}

2558BExtension (encoded in extension request attribute)

2559BValue

2560BSubject Key Identifier 2561Bc=no; Octet String 2562BKey Usage 2563Bc=yes; optional; keyCertSign, cRLSign, DigitalSignature,

nonRepudiation 2564BBasic Constraints 2565Bc=yes; optional; cA=True; path length constraint=1 2566BName Constraints 2567Bc=yes; optional; permitted subtrees for DN, RFC-822, and DNS name

forms




10.3 197BRAYTHEON ROOT CA CERTIFICATE (RRCA) 2568BField 2569BValue 2570BVersion 2571BV3 2572BSerial Number 2573BMust be unique 2574BIssuer Signature Algorithm 2575Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2576Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} 2577BIssuer Distinguished Name 2578Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or,

101Bcn=Raytheon Root CA,ou=RaytheonRoot-g2,o=CAs,dc=raytheon,dc=com

2579BValidity Period9F

10 2580BExpressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

2581BSubject Distinguished Name 2582Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or, 102Bcn=Raytheon Root CA,ou=RaytheonRoot-g2,o=CAs,dc=raytheon,dc=com

2583BPublic Key 2584B2048 or 3072 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}


2588BExtension 2589BValue 2590BKey Usage 2591Bc=yes; keyCertSign, cRLSign 2592BSubject Key Identifier 2593Bc=no; Octet String (same as in PKCS#10 request from the RRCA) 2594BBasic Constraints 2595Bc=yes; CA=True; path length constraint absent

10 The Root certificate will be generated with SHA-1. The Generation 2 Root will be updated to utilize SHA-256. This certificate will have a lifetime of 20 years.




10.4 HIGH ASSURANCE SUBSCRIBER SIGNATURE CERTIFICATE 1899BNote: These certificates are only issued to Trusted PKI Operators.

2596BField 2597BValue 2598BVersion 2599BV3

2600BSerial Number 2601BMust be unique

2602BIssuer Signature Algorithm 2603Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or 2604Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} as specified in Section 6.1.5 of the Raytheon CP

2605BIssuer Distinguished Name 2606Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or, 103Bcn=Raytheon Root CA,ou=RaytheonRoot-g2,o=CAs,dc=raytheon,dc=com

2607BValidity Period 2608BNo longer than 3 years from date of issue; Expressed in UTC Time until 2049 and GeneralizedTime for dates thereafter

2609BSubject Distinguished Name 2610BUnique X.500 subject DN within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP


2612B2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1}


2616BExtension 2617BValue 2618BKey Usage 2619Bc=yes; digitalSignature,nonRepudiation

2620BExtended Key Usage 2621Bc=no; Per Section 10.21

2622BSubject Alternative Name 2623Bc=no; RFC822 email address (required); others optional

2624BSubject Directory Attributes 2625Bc=no; Entrust User Role= integer, where integer is a numeric role identifier


11 2627Bc=no

2628BAuthority Key Identifier 2629Bc=no; Octet String (same as subject key identifier in the Issuing CA certificate)

2630BSubject Key Identifier 2631Bc=no; Octet String (same as in PKCS#10 request or calculated by the Signing CA per RFC 3280 method 1 or other method)

2632BCertificate Policies 2633Bc=no; 2634BSHA-1: {1.3.6.1.4.1.1569.10.1.1} or 2635BSHA-256: {1.3.6.1.4.1.1569.10.1.11}





2596BField 2597BValue 2636BAuthority Information Access 2637Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c

file containing certificates issued to Issuing CA or LDAP URL pointer to the caCertificate attribute of the Issuing CA; id-ad-ocsp access method entry contains HTTP URL for the Issuing CA OCSP Responder




10.5 199BHIGH ASSURANCE SUBSCRIBER ENCRYPTION CERTIFICATE 1900BNote: These certificates are only issued to Trusted PKI Operators

2638BField 2639BValue 2640BVersion 2641BV3 (2) 2642BSerial Number 2643BMust be unique 2644BIssuer Signature Algorithm 2645Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2646Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} 2647BIssuer Distinguished Name 2648Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or,


2649BValidity Period 2650BNo longer than 3 years from date of issue; Expressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

2651BSubject 2652BUnique X.500 subject DN within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP

2653BPublic Key 2654B2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1} 2655BIssuer’s Signature 2656Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2657Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} 2658BExtension 2659BValue 2660BKey Usage 2661Bc=yes; keyEncipherment 2662BExtended Key Usage 2663Bc=no; Per Section 10.21 2664BSubject Alternative Name 2665Bc=no; RFC822 email address (required); others optional 2666BSubject Directory Attributes 2667Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier 2668BCRL Distribution Points11F

12 2669Bc=no 2670BAuthority Key Identifier 2671Bc=no; Octet String (same as subject key identifier in the Issuing CA

certificate) 2672BSubject Key Identifier 2673Bc=no; Octet String (same as in PKCS-10 request or calculated by the

Signing CA per RFC 3280 method 1 or other method) 2674BCertificate Policies 2675Bc=no;

2676BSHA-1: {1.3.6.1.4.1.1569.10.1.1} or 2677BSHA-256: {1.3.6.1.4.1.1569.10.1.11}

2678BAuthority Information Access 2679Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing certificates issued to Issuing CA or LDAP URL pointer to the caCertificate attribute of the Issuing CA; id-ad-ocsp access method entry contains HTTP URL for the Issuing CA OCSP Responder





10.6 200BMEDIUM ASSURANCE SIGNING CA CERTIFICATE (MASCA) 2680BField 2681BValue 2682BVersion 2683BV3 2684BSerial Number 2685BMust be unique 2686BIssuer Signature Algorithm 2687Bsha-1 WithRSAEncryption {1 2 840 113549 1 1 5} or sha-256

WithRSAEncryption {1 2 840 113549 1 1 11} per Section 6.1.5. 2688BIssuer Distinguished Name 2689Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or,

2690BCN = Raytheon Root CA, OU = RaytheonRoot-g2, O = CAs, DC = Raytheon, DC = com

2691BValidity Period12F

13 2692B10 years expressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

2693BSubject 2694Bou=class3, o=CAs, dc=raytheon, dc=com or, 2695Bcn=Raytheon Class 3 MASCA, ou=Class3-g2, o=CAs, dc=raytheon, dc=com

2696BPublic Key 2697B2048 bit RSA key modulus, rsaEncryption {1 2 840 113549 1 1 1} 2698BIssuer’s Signature 2699Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2700Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} 2701BExtension 2702BValue 2703BAuthority Key Identifier 2704Bc=no; Octet String (same as subject key identifier in RRCA certificate) 2705BSubject Key Identifier 2706Bc=no; Octet String (same as in PKCS-10 request from the subject 2707BKey Usage 2708Bc=yes; keyCertSign, cRLSign 2709BCertificate Policies 2710Bc=no;

2711BSHA-1: {1.3.6.1.4.1.1569.10.1.2} {1.3.6.1.4.1.1569.10.1.3} {1.3.6.1.4.1.1569.10.1.4} {1.3.6.1.4.1.1569.10.1.5} or 2712BSHA-256: {1.3.6.1.4.1.1569.10.1.12} {1.3.6.1.4.1.1569.10.1.13} {1.3.6.1.4.1.1569.10.1.14} {1.3.6.1.4.1.1569.10.1.15}

2713BBasic Constraints 2714Bc=yes; CA=True; path length=0 2715BAuthority Information Access

2716Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing certificates issued to RRCA or LDAP URL pointer to the caCertificate attribute of the RRCA; id-ad-ocsp access method entry contains HTTP URL for the RRCA OCSP Responder


14 2718Bc=no

13 The initial CA certificate will be generated using SHA-1. This certificate will be replaced prior to the end of 2010 with a certificate signed utilizing SHA-256. 14 The CRL distribution point extension shall only populate the distributionPoint field. The distributionPoint field shall contain HTTP (i.e., of the form http://…) URI. The distributionPoint field may contain LDAP (i.e., of the form ldap://…) URI. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL or a Distribution Point based partitioned CRL. The Distribution Point field shall contain a full name (i.e, the Distribution Point field shall not contain nameRelativetoCRLIssuer).







10.7 201BMEDIUM ASSURANCE SUBSCRIBER SIGNATURE CERTIFICATE 2719BField 2720BValue 2721BVersion 2722BV3 2723BSerial Number 2724BMust be unique 2725BIssuer Signature Algorithm 2726Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2727Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per Section Error! Reference source not found.

2728BIssuer Distinguished Name 2729Bou=class3, o=CAs, dc=raytheon, dc=com or, 2730Bcn=Raytheon Class 3 MASCA, ou=Class3-g2, o=CAs, dc=raytheon, dc=com

2731BValidity Period 2732BNo longer than 3 years from date of issue expressed in UTC Time until 2049 and GeneralizedTime for dates thereafter



2736B2048 bit RSA key modulus, rsaEncryption


2740BExtension 2741BValue 2742BAuthority Key Identifier 2743Bc=no; Octet String (same as subject key identifier in MASCA certificate) 2744BSubject Key Identifier 2745Bc=no; Octet String (same as in PKCS-10 request or calculated by the

MASCA per RFC 3280 method 1 or other method) 2746BKey Usage 2747Bc=yes; digitalSignature; nonRepudiation 2748BCertificate Policies14F

15 2749Bc=no; 2750BSHA-1: {1.3.6.1.4.1.1569.10.1.2} or {1.3.6.1.4.1.1569.10.1.3} or {1.3.6.1.4.1.1569.10.1.4} or {1.3.6.1.4.1.1569.10.1.5} or 2751BSHA-256: {1.3.6.1.4.1.1569.10.1.12} or {1.3.6.1.4.1.1569.10.1.13} or {1.3.6.1.4.1.1569.10.1.14} or {1.3.6.1.4.1.1569.10.1.15}

2752BExtended Key Usage 2753Bc=no; Per Section 10.21 2754BSubject Alternative Name 2755Bc=no; RFC822 email address (required); UPN; others optional 2756BSubject Directory Attributes 2757Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier

15 Certificate Policies will be asserted such that all lower assurance policies will also be asserted. (For example if 10.4 is asserted 10.5 will also be asserted).




2758BAuthority Information Access 2759Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing certificates issued to MASCA or LDAP URL pointer to the caCertificate attribute of the MASCA; id-ad-ocsp access method entry contains HTTP URL for the MASCA OCSP Responder


16 2761Bc=no





10.8 202BMEDIUM ASSURANCE SUBSCRIBER ENCRYPTION CERTIFICATE 2762BField 2763BValue 2764BVersion 2765BV3 (2) 2766BSerial Number 2767BMust be unique 2768BIssuer Signature Algorithm 2769Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2770Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per 6.1.5. 2771BIssuer Distinguished Name 2772Bou=class3, o=CAs, dc=raytheon, dc=com or,

2773Bcn=Raytheon Class 3 MASCA, ou=Class3-g2, o=CAs, dc=raytheon, dc=com

2774BValidity Period 2775BNo longer than 3 years from date of issue expressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

2776BSubject 2777BUnique X.500 subject DN within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP

2778BPublic Key 2779B2048 bit RSA key modulus, rsaEncryption 2780BIssuer’s Signature 2781Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2782Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} 2783BExtension 2784BValue 2785BAuthority Key Identifier 2786Bc=no; Octet String (same as subject key identifier in MASCA certificate) 2787BSubject Key Identifier 2788Bc=no; Octet String (same as in PKCS#10 request or calculated by the

MASCA ) 2789BKey Usage 2790Bc=yes; keyEncipherment 2791BExtended Key Usage 2792Bc=no; per Section 10.21 2793BCertificate Policies16F

17 2794Bc=no; 2795BSHA-1: {1.3.6.1.4.1.1569.10.1.2} or {1.3.6.1.4.1.1569.10.1.3} or {1.3.6.1.4.1.1569.10.1.4} or {1.3.6.1.4.1.1569.10.1.5} or 2796BSHA-256: {1.3.6.1.4.1.1569.10.1.12} or {1.3.6.1.4.1.1569.10.1.13} or {1.3.6.1.4.1.1569.10.1.14} or {1.3.6.1.4.1.1569.10.1.15}

2797BSubject Alternative Name 2798Bc=no; RFC822 email address (required); others optional 2799BSubject Directory Attributes 2800Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier 2801BAuthority Information Access 2802Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c

file containing certificates issued to MASCA or LDAP URL pointer to the caCertificate attribute of the MASCA; id-ad-ocsp access method entry contains HTTP URL for the MASCA OCSP Responder






18 2804Bc=no





10.9 203BMEDIUM ASSURANCE SUBSCRIBER AUTHENTICATION CERTIFICATE 1901BField 1902BValue 1903BVersion 1904BV3 1905BSerial Number 1906BMust be unique 1907BIssuer Signature Algorithm 1908Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per Section 6.1.5 1909BIssuer Distinguished Name 1910Bcn=Raytheon Class 3 MASCA, ou=Class3-g2, o=CAs, dc=raytheon,

dc=com 1911BValidity Period 1912BNo longer than 3 years from date of issue expressed in UTC Time until

2049 and GeneralizedTime for dates thereafter 1913BSubject Distinguished Name 1914BUnique X.500 subject DN within the namespace dc=raytheon, dc=com

as specified in Section 7.1.4 of the Raytheon CP 1915BSubject Public Key Information


1917BIssuer’s Signature 1918Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} 1919BExtension 1920BValue 1921BAuthority Key Identifier 1922Bc=no; Octet String (same as subject key identifier in Issuing CA

certificate) 1923BSubject Key Identifier 1924Bc=no; Octet String (same as in PKCS-10 request or calculated by the

Issuing CA per RFC 3280 method 1 or other method) 1925BKey Usage 1926Bc=yes; digitalSignature 1927BCertificate Policies18F

19 1928Bc=no {1.3.6.1.4.1.1569.10.1.12} or {1.3.6.1.4.1.1569.10.1.13} or {1.3.6.1.4.1.1569.10.1.14} or {1.3.6.1.4.1.1569.10.1.15}

1929BExtended Key Usage 1930Bc=no; Per Section 10.21 1931BSubject Alternative Name 1932Bc=no; RFC822 email address; UPN; others optional 1933BSubject Directory Attributes 1934Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier 1935BAuthority Information Access 1936Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c

file containing certificates issued to Issuing CA; id-ad-ocsp access method entry contains HTTP URL for the Issuing CA OCSP Responder


20 1938Bc=no

19 Certificate Policies will be asserted such that all lower assurance policies will also be asserted. (For example if 10.4 is asserted 10.5 will also be asserted). 20 The CRL distribution point extension shall only populate the distributionPoint field. The distributionPoint field shall contain HTTP (i.e., of the form http://…) URI. The distributionPoint field may contain LDAP (i.e., of the form ldap://…) URI. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL or a Distribution Point based partitioned CRL. The Distribution Point field shall contain a full name (i.e, the Distribution Point field shall not contain nameRelativetoCRLIssuer).




10.10 MEDIUM ASSURANCE CODE SIGNING CERTIFICATE 2805BField 2806BValue 2807BVersion 2808BV3 (2) 2809BSerial Number 2810BMust be unique 2811BIssuer Signature Algorithm 2812Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or








2826BExtension 2827BValue 2828BAuthority Key Identifier 2829Bc=no; Octet String (same as subject key identifier in MASCA certificate ) 2830BSubject Key Identifier 2831Bc=no; Octet String (same as in PKCS#10 request or calculated by the

MASCA) 2832BKey Usage 2833Bc=yes; digitalSignature; nonRepudiation 2834BExtended key usage 2835Bc=yes; Per Section 10.21 2836BCertificate Policies20F

21 2837Bc=no; 2838BSHA1: {1.3.6.1.4.1.1569.10.1.2} or {1.3.6.1.4.1.1569.10.1.4} or 2839BSHA256: {1.3.6.1.4.1.1569.10.1.12} or {1.3.6.1.4.1.1569.10.1.14}


2842BSubject Alternative Name 2843BDN of the person controlling the code signing private key; RFC822 email address of role (optional)







22 2847Bc=no





10.11 205BMEDIUM ASSURANCE APPLICATION CERTIFICATE 2848BField 2849BValue 2850BVersion 2851BV3 (2) 2852BSerial Number 2853BMust be unique 2854BIssuer Signature Algorithm 2855Bsha-1 WithRSAEncryption {1 2 840 113549 1 1 5} or









MASCA) 2875BKey Usage 2876Bc=yes; digitalSignature; keyEncipherment 2877BExtended key usage 2878Bc=no; Per Section 10.21 2879BCertificate Policies22F

23 2880Bc=no; 2881BSHA1: {1.3.6.1.4.1.1569.10.1.9} or 2882BSHA256: {1.3.6.1.4.1.1569.10.1.19}


2885BSubject Alternative Name 2886Balways present, DNS Host Name; RFC822 email address of administrative organization (optional)







24 2890Bc=no





10.12 206BMEDIUM ASSURANCE DEVICE OR SERVER CERTIFICATE 2891BField 2892BValue 2893BVersion 2894BV3 (2) 2895BSerial Number 2896BMust be unique 2897BIssuer Signature Algorithm 2898Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or




2905BSubject Distinguished Name 2906BUnique X.500 subject DN within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP. Structure will include cn={ Host URL | Host IP Address | Host Name }





MASCA) 2918BKey Usage 2919Bc=yes; digitalSignature; keyEncipherment 2920BExtended key usage 2921Bc=no; Per Section 10.21 2922BCertificate Policies24F

25 2923Bc=no; 2924BSHA1: {1.3.6.1.4.1.1569.10.1.9} or 2925BSHA256: {1.3.6.1.4.1.1569.10.1.19}


2928BSubject Alternative Name 2929Bc=no; always present, Host URL | IP Address | Host Name






26 2931Bc=no 2932BSubject Directory Attributes 2933Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier





10.13 207BMEDIUM ASSURANCE DOMAIN CONTROLLER CERTIFICATE 2934BField 2935BValue 2936BVersion 2937BV3 (2) 2938BSerial Number 2939BMust be unique 2940BIssuer Signature Algorithm 2941Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or




2948BSubject Distinguished Name 2949BUnique X.500 subject DN within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP. Structure will include cn={ Host URL | Host IP Address | Host Name }





MASCA) 2961BKey Usage 2962Bc=yes; digitalSignature; keyEncipherment 2963BExtended Key Usage 2964Bc=no; Per Section 10.21 2965BCertificate Policies26F

27 2966Bc=no; 2967BSHA1: {1.3.6.1.4.1.1569.10.1.9} or 2968BSHA256: {1.3.6.1.4.1.1569.10.1.19}


2971BSubject Alternative Name 2972Bc=no; always present, dnsName; otherName <OID ={1.3.6.1.4.1.311.25.1}, value <GUID>


28 2974Bc=no

27 Certificate Policies will be asserted such that all lower assurance policies will also be asserted. (For example if 10.4 is asserted 10.5 will also be asserted). 28 The CRL distribution point extension shall only populate the distributionPoint field. The distributionPoint field shall contain HTTP (i.e., of the form http://…) URI. The distributionPoint field may contain LDAP (i.e., of the form ldap://…) URI. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL or a Distribution Point based partitioned CRL. The




2934BField 2935BValue 2975BSubject Directory Attributes 2976Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier 2977BCertificate Template Name 2978B{1.3.6.1.4.1.311.20.2}

2979Bc=no; DomainController

Distribution Point field shall contain a full name (i.e, the Distribution Point field shall not contain nameRelativetoCRLIssuer).




10.14 208BMEDIUM ASSURANCE ROLE SIGNATURE CERTIFICATE 2980BField 2981BValue 2982BVersion 2983BV3 (2) 2984BSerial Number 2985BMust be unique 2986BIssuer Signature Algorithm 2987Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

2988Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per 6.1.5 2989BIssuer Distinguished Name 2990Bou=class3, o=CAs, dc=raytheon, dc=com or,


2992BValidity Period 2993BNo longer than 3 years from date of issue expressed in UTC Time until 2049 and GeneralizedTime for dates thereafter

2994BSubject Distinguished Name 2995BUnique X.500 subject DN for role within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP




3001BExtension 3002BValue 3003BAuthority Key Identifier 3004Bc=no; Octet String (same as subject key identifier in MASCA certificate ) 3005BSubject Key Identifier 3006Bc=no; Octet String (same as in PKCS-10 request or calculated by the

MASCA) 3007BKey Usage 3008Bc=yes; nonRepudiation, digitalSignature 3009BExtended Key Usage 3010Bc=no; per Section 10.21 3011BCertificate Policies 3012Bc=no;

3013BSHA-1: {1.3.6.1.4.1.1569.10.1.2} or {1.3.6.1.4.1.1569.10.1.4} or 3014BSHA-256: {1.3.6.1.4.1.1569.10.1.12} or {1.3.6.1.4.1.1569.10.1.14}

3015BSubject Alternative Name 3016Bc = no; DN of the person controlling the role signing private key; RFC822 email address of role (optional)



29 3020Bc = no; 3021BAuthority Information Access 3022Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c


29 The CRL distribution point extension shall only populate the distributionPoint field. The distributionPoint field shall contain HTTP (i.e., of the form http://…) URI. The distributionPoint field may contain LDAP (i.e., of the form ldap://…) URI. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL or a Distribution Point based partitioned CRL. The Distribution Point field shall contain a full name (i.e., the Distribution Point field shall not contain nameRelativetoCRLIssuer).




10.15 209BMEDIUM ASSURANCE ROLE ENCRYPTION CERTIFICATE 3023BField 3024BValue 3025BVersion 3026BV3 (2) 3027BSerial Number 3028BMust be unique 3029BIssuer Signature Algorithm 3030Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or




3037BSubject Distinguished Name 3038BUnique X.500 subject DN for role within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of this CP




3044BExtension 3045BValue 3046BAuthority Key Identifier 3047Bc=no; Octet String (same as subject key identifier in MASCA certificate ) 3048BSubject Key Identifier 3049Bc=no; Octet String (same as in PKCS-10 request or calculated by the

MASCA) 3050BKey Usage 3051Bc=yes; keyEncipherment 3052BExtended Key Usage 3053Bc=no; per Section 10.21 3054BCertificate Policies 3055Bc=no;

3056BSHA-1: {1.3.6.1.4.1.1569.10.1.2} or {1.3.6.1.4.1.1569.10.1.4} or 3057BSHA-256: {1.3.6.1.4.1.1569.10.1.12} or {1.3.6.1.4.1.1569.10.1.14}

3058BSubject Alternative Name 3059Bc=no; RFC822 email address of role (required); others optional 3060BSubject Directory Attributes 3061Bc=no; Entrust User Role= integer, where integer is a numeric role

identifier 3062BCRL Distribution Points29F

30 3063Bc = no;

30 The CRL distribution point extension shall only populate the distributionPoint field. The distributionPoint field shall contain HTTP (i.e., of the form http://…) URI. The distributionPoint field may contain LDAP (i.e., of the form ldap://…) URI. The reasons and cRLIssuer fields shall not be populated. The CRL shall point to a full and complete CRL or a Distribution Point based partitioned CRL. The Distribution Point field shall contain a full name (i.e., the Distribution Point field shall not contain nameRelativetoCRLIssuer).




3023BField 3024BValue 3064BAuthority Information Access 3065Bc=no; id-ad-caIssuers access method entry contains HTTP URL for .p7c





10.16 210BOCSP RESPONDER CERTIFICATE 1939BThe following table contains the OCSP Responder certificate profile assuming that the OCSP Responder certificate is issued by the same CA using the same key as the Subscriber Certificate. Alternative trust models such as OCSP Responder as trust anchor may be acceptable to the RPMA.




3066BField 3067BValue 3068BVersion 3069BV3 (2) 3070BSerial Number 3071BMust be unique 3072BIssuer Signature Algorithm 3073Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

3074Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per Section 6.1.5. 3075BIssuer Distinguished Name 3076BUnique X.500 Issuing CA DN as specified in Section 7.1.4 of this CP 3077BValidity Period 3078BIssued monthly or more frequently with a validity period no longer than

45 days from date of issue; Expressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

3079B1Subject Distinguished Name 3080BUnique X.500 subject DN within the namespace dc=raytheon, dc=com as specified in Section 7.1.4 of the Raytheon CP




3086BExtension 3087BValue 3088BAuthority Key Identifier 3089Bc=no; Octet String (same as subject key identifier in Issuing CA

certificate ) 3090BSubject Key Identifier 3091Bc=no; Octet String (same as in PKCS#10 request or calculated by the

Issuing CA) 3092BKey Usage 3093Bc=yes; digitalSignature (required), nonRepudiation (optional) 3094BExtended key usage 3095Bc=yes; Per Section 10.21 3096BCertificate Policies30F

31 3097Bc=no; 3098BSHA-1: { 1.3.6.1.4.1.1569.10.1.1} { 1.3.6.1.4.1.1569.10.1.2} {1.3.6.1.4.1.1569.10.1.3} {1.3.6.1.4.1.1569.10.1.4} {1.3.6.1.4.1.1569.10.1.5} {1.3.6.1.4.1.1569.10.1.6} {1.3.6.1.4.1.1569.10.1.7} {1.3.6.1.4.1.1569.10.1.8} {1.3.6.1.4.1.1569.10.1.9} or 3099BSHA-256: { 1.3.6.1.4.1.1569.10.1.11} { 1.3.6.1.4.1.1569.10.1.12} {1.3.6.1.4.1.1569.10.1.13} {1.3.6.1.4.1.1569.10.1.14} {1.3.6.1.4.1.1569.10.1.15} {1.3.6.1.4.1.1569.10.1.16} {1.3.6.1.4.1.1569.10.1.17} {1.3.6.1.4.1.1569.10.1.18} {1.3.6.1.4.1.1569.10.1.19}

3100BSubject Alternative Name 3101BHTTP URL for the OCSP Responder (preferred); and/or 105BDNS: Fully qualified domain name of the OCSP Responder

3102BNo Check id-pkix-ocsp-nocheck; {1 3 6 1 5 5 7 48 1 5}

3103Bc=no; Null

31 This field shall contain all of the certificate policy OIDs for which the CA issues certificates.




3066BField 3067BValue 3104BAuthority Information Access 3105Bc=no; optional; id-ad-caIssuers access method entry contains HTTP

URL for .p7c file containing certificates issued to Issuing CA or LDAP URL pointer to the caCertificate attribute of the Issuing CA




10.17 RAYTHEON ROOT CA CRL FORMAT 3106BField 3107BValue 3108BVersion 3109BV2 3110BIssuer Signature Algorithm 3111Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

3112Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per 6.1.5. 3113BIssuer Distinguished Name 3114Bou=RaytheonRoot, o=CAs, dc=raytheon, dc=com or,


3115BEffective date 3116BExpressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

3117BNext update 3118BExpressed in UTCTime until 2049 and GeneralizedTime for dates thereafter (>= thisUpdate + CRL issuance frequency)

3119BRevoked certificates list 3120B0 or more 2-tuple of certificate serial number and revocation date (in Generalized Time)


3124BCRL Extension 3125BValue 3126BCRL Number 3127Bc=no; monotonically increasing integer (never repeated) 3128BAuthority Key Identifier 3129Bc=no; Octet String (same as in Authority Key Identifier field in

certificates issued by the CA) 3130BCRL Entry Extension 3131BValue 3132BReason Code 3133Bc=no; optional, must be included when reason code = key compromise

or CA compromise




10.18 212BMEDIUM ASSURANCE CA CRL FORMAT 3134BField 3135BValue 3136BVersion 3137BV2 3138BIssuer Signature Algorithm 3139Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

3140Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per Section 6.1.5. 3141BIssuer Distinguished Name 3142Bou=class3, o=CAs, dc=raytheon, dc=com or,


3144BEffective date 3145BExpressed in UTCTime until 2049 and GeneralizedTime for dates thereafter

3146BNext update 3147BExpressed in UTCTime until 2049 and GeneralizedTime for dates thereafter (>= thisUpdate + CRL issuance frequency)

3148BRevoked certificates list 3149B0 or more 2-tuple of certificate serial number and revocation date (in Generalized Time)


3153BCRL Extension 3154BValue 3155BCRL Number 3156Bc=no; monotonically increasing integer (never repeated) 3157BAuthority Key Identifier 3158Bc=no; Octet String (same as in Authority Key Identifier field in

certificates issued by the CA) 3159BCRL Entry Extension 3160BValue 3161BReason Code 3162Bc=no; ; optional, must be included when reason code = key compromise

or CA compromise 3163BHold Instruction 3164Bc=no; optional, id-holdinstruction-reject31F

32

32 may be present only if reason code = certificateHold




10.19 213BOCSP REQUEST FORMAT 1940BRequests sent to Issuer PKI OCSP Responders are not required to be signed, but may be at the discretion of the Issuer PKI. See RFC2560 for detailed syntax. The following table lists the fields that are expected by the OCSP Responder.

3165BField 3166BValue 3167BVersion 3168BV1 (0) 3169BRequester Name 3170BDN of the requestor (required) 3171BRequest List 3172BList of certificates as specified in RFC 2560 3173BRequest Extension 3174BValue 3175BNone 3176BNone 3177BRequest Entry Extension 3178BValue 3179BNone 3180BNone

10.20 214BOCSP RESPONSE FORMAT 1941BSee RFC2560 for detailed syntax. The following table lists which fields are populated by the OCSP Responder.

3181BField 3182BValue 3183BResponse Status 3184BAs specified in RFC 2560 3185BResponse Type 3186Bid-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1} 3187BVersion 3188BV1 (0) 3189BResponder ID 3190BOctet String (same as subject key identifier in Responder certificate) 3191BProduced At 3192BGeneralized Time 3193BList of Responses 3194BEach response shall contain certificate id; certificate status32F

33, thisUpdate, nextUpdate33F

34 3195BResponder Signature 3196Bsha-1WithRSAEncryption {1 2 840 113549 1 1 5} or

3197Bsha256 WithRSAEncryption {1 2 840 113549 1 1 11} per Section 6.1.5. 3198BCertificates 3199BApplicable certificates issued to the OCSP Responder 3200BResponse Extension 3201BValue 3202BNonce 3203Bc=no; Value in the nonce field of request (required, if present in request) 3204BResponse Entry Extension 3205BValue 3206BNone 3207BNone

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




10.21 215BEXTENDED KEY USAGE 1942BCertificate Type 1943BRequired EKU 1944BOptional EKU 1945BProhibited EKU

1946BCA34F

35 1947BNone 1948BNone 1949BAll

1950BCode Signing 1951Bid-kp-codesigning 1952B{1 3 6 1 5 5 7 3 3}

1953BLife-time Signing {1.3.6.1.4.1.311.10.3.13}35F

36 1954BAll Others

1955BDomain Controller 1956Bid-kp-serverAuth 1957B{1 3 6 1 5 5 7 3 1};

1958Bid-kp-clientAuth {1.3.6.1.5.5.7.3.2};

1959Bid-pkinit-KPKdc 1960B{1 3 6 1 5 2 3 5};

1961BsmartCardLogon {1.3.6.1.4.1.311.20.2.2}

1962BNone 1963BAll Others

1964BTrusted Role Authentication and Signature Certificate

1965Bid-kp-clientAuth {1.3.6.1.5.5.7.3.2}; 1966BsmartCardLogon

{1.3.6.1.4.1.311.20.2.2}; 1967Bid-pkinit-KPClientAuth

1968B{1 3 6 1 5 2 3 4}36F

37;

1969Bid-kp-emailProtection {1.3.6.1.5.5.7.3.4}

1970BAny EKU that is consistent with Key Usage

1971BAny EKU that is not consistent with Key

Usage

1972BanyExtendedKeyUsage {2.5.29.37.0}

1973BTrusted Role Encryption Certificate

1974BSee Subscriber Group, Role, Encryption Certificate

1975BSee Subscriber Group, Role, Encryption

Certificate

1976BSee Subscriber Group, Role, Encryption

Certificate

1977BOCSP Responder 1978Bid-kp-OCSPSigning 1979B{1 3 6 1 5 5 7 3 9}


1982BSubscriber Group, Role, Encryption Certificate37F

38

1983Bid-kp-emailProtection

1984B{1.3.6.1.5.5.7.3.4};

1985BAny EKU that is consistent with Key

Usage, e.g., Encrypting File System

{1.3.6.1.4.1.311.10.3.4}


Usage


35 CA certificate includes self-signed Root, cross certificates, subordinate CA certificates, and self-issued key rollover certificates. 36 It is recommended that this EKU be included so that MSFT platforms will not verify signed code using an expired certificate. 37 The last two only if the private key is in hardware. 38 This certificate is defined as the one that has only the key encipherment or key agreement bit set and optionally data encipherment bit set.




1942BCertificate Type 1943BRequired EKU 1944BOptional EKU 1945BProhibited EKU

1988BSubscriber, Group, Role, Signature Certificate

1989B(Three Certificate Solution)

1990Bid-kp-emailProtection 1991B{1.3.6.1.5.5.7.3.4};

1992BMSFT Document Signing 1993B{1.3.6.1.4.1.311.10.3.12};

1994BAdobe Certified Document Signing

1995B{1.2.840.113583.1.1.5};



Usage


1999BSubscriber, Group, Role Authentication Certificate (Three Certificate Solution)

2000Bid-kp-clientAuth 2001B{1.3.6.1.5.5.7.3.2};

2002BsmartCardLogon 2003B{1.3.6.1.4.1.311.20.2.2};

2004Bid-pkinit-KPClientAuth 2005B{1 3 6 1 5 2 3 4}



Usage


2009BSubscriber, Group, Role Authentication and Signature Certificate (Two Certificate Solution)

2010Bid-kp-clientAuth 2011B{1.3.6.1.5.5.7.3.2};

2012BsmartCardLogon 2013B{1.3.6.1.4.1.311.20.2.2};

2014Bid-pkinit-KPClientAuth 2015B{1 3 6 1 5 2 3 4};

2016Bid-kp-emailProtection 2017B{1.3.6.1.5.5.7.3.4};

2018BMSFT Document Signing 2019B{1.3.6.1.4.1.311.10.3.12};

2020BAdobe Certified Document Signing

2021B{1.2.840.113583.1.1.5};

2022BAny EKU that is not consistent with Key Usage


Usage


2025BTime Stamp Authority

2026Bid-kp-timestamping 2027B{1 3 6 1 5 5 7 3 8}


2030BVPN Client 2031Bid-kp-clientAuth {1.3.6.1.5.5.7.3.2}; 2032BiKEIntermediate {1.3.6.1.5.5.8.2.2};

2033Bid-kp-ipsecIKE 2034B{1 3 6 1 5 5 7 3 17}


2037BVPN Server 2038Bid-kp-serverAuth 2039B{1 3 6 1 5 5 7 3 1};

2040Bid-kp-clientAuth {1.3.6.1.5.5.7417.3.2};

2041BiKEIntermediate {1.3.6.1.5.5.8.2.2};

2042Bid-kp-ipsecIKE 2043B{1 3 6 1 5 5 7 3 17}





1942BCertificate Type 1943BRequired EKU 1944BOptional EKU 1945BProhibited EKU

2046BWeb Client 2047Bid-kp-clientAuth {1.3.6.1.5.5.7.3.2}


2050BWeb Server 2051Bid-kp-serverAuth 2052B{1 3 6 1 5 5 7 3 1}

2053Bid-kp-clientAuth {1.3.6.1.5.5.7.3.2}


2056BWorkstation 2057Bid-kp-clientAuth {1.3.6.1.5.5.7.3.2}; 2058BiKEIntermediate {1.3.6.1.5.5.8.2.2};

2059Bid-kp-ipsecIKE 2060B{1 3 6 1 5 5 7 3 17}





11 124BPKI REPOSITORY INTEROPERABILITY PROFILE 2063BThis section provides an overview of the PKI Repository interoperability profiles. The following topics are discussed:

• 2064BProtocol

• 2065BAuthentication

• 2066BNaming

• 2067BObject Class

• 2068BAttributes 2069BEach of these items is described below.

11.1 216BPROTOCOL 2070BThe Raytheon PKI Repository shall provide HTTP protocol access to certificates and CRLs.

11.2 217BAUTHENTICATION 2071BThe Raytheon PKI Repository shall permit “none” (anonymous) authentication to read certificate and CRL information. 2072BRaytheon shall be free to implement authentication mechanisms of its choice for browse and list operations. 2073BFor the external PKI Directory used for interoperability, any write, update, add entry, delete entry, add attribute, delete attribute, change schema etc, shall require password over SSL or stronger authentication mechanism.

11.3 218BNAMING 2074BThis CP has defined the naming convention. 2075BWhen a LDAP repository is used:

1. 2076BCertificates shall be stored in the Raytheon LDAP Repository in the entry that appears in the certificate subject name.

2. 2077BissuedByThisCA element of crossCrossCertificatePair shall contain the certificate(s) issued by a CA whose name the entry represents; and

3. 2078BCRLs shall be stored in the Raytheon PKI Repository in the entry that appears in the CRL issuer name.

11.4 219BOBJECT CLASS 2079BWhen a LDAP repository is used:

1. 2080BEntries that describe CAs shall be defined by organizationUnit structural object class. These entries shall also be a member of pkiCA cpCPS auxiliary object classes; and




2. 2081BEntries 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.

11.5 220BATTRIBUTES 2082BWhen a LDAP repository is used:

1. 2083BCA entries shall be populated with the caCertificate, crossCertificatePair, certificateRevocationList, and cPCPS attributes, as applicable; and

2. 2084BUser entries shall be populated with userCertificate attribute containing encryption certificate. Signature certificate need not be published to the LDAP Repository.




12 125BBIBLIOGRAPHY 2085BThe following documents are sources and/or references for this CP:

2086BABADSG 2087BDigital Signature Guidelines, 1996-08-01. http://www.abanet.org/scitech/ec/isc/dsgfree.html

2088BANSI X9.62: 2089B2005

2090BPublic Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005-11-15

2091BANSI X9.63 – 2092B2011

2093BPublic Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography, 2001-11-20

2094BCHARTER 2095BRaytheon PMA Charter 2096BFIPS 140-2 2097BSecurity Requirements for Cryptographic Modules, May 25, 2001

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf 2098BFIPS 186-4 2099BDigital Signature Standard, July 2013

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf 2100BFIPS 201-2 2101BPersonal Identity and Verification (PIV) for Federal Employees and

Contractors, August 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-2.pdf

2102BPKCS #12 2103Bv1.1

2104BPersonal Information Exchange Syntax Standard, October 27, 2012. http://www.emc.com/collateral/white-papers/h11301-pkcs-12v1-1-personal-information-exchange-syntax-wp.pdf

2105BRFC 4210 2106BCertificate Management Protocol, Adams and Farrell, et. al., September 2005. http://www.ietf.org/rfc/rfc4210.txt

2107BRFC 6960 2108BX.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, Santesson, Myers et al, June 2013. http://www.ietf.org/rfc/rfc6960.txt

2109BRFC 3647 2110BCertificate Policy and Certificate Practices Framework, Chokhani, Ford, Sabett, Merrill, and Wu. November 2003. http://www.ietf.org/rfc/rfc3647.txt

2111BRFC 4122 2112BA Universally Unique Identifier (UUID) URN Namespace, Leach, Mealling, and Salz, July 2005 http://www.ietf.org/rfc/rfc4122.txt

2113BRFC 5280 2114BInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Cooper et. al., May 2008 http://www.ietf.org/rfc/rfc5280.txt

2115BSP800-73-3 2116BInterfaces for Personal Identity Verification (4 parts), Chandramouli et. al., February 2010 2117BPart 1: End-Point PIV Card Application, http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART1_piv-card-applic-namespace-date-model-rep.pdf 2118BPart 2: End-Point PIV Card Application Card Command Interface,

http://www.abanet.org/scitech/ec/isc/dsgfree.html

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-2.pdf

http://www.emc.com/collateral/white-papers/h11301-pkcs-12v1-1-personal-information-exchange-syntax-wp.pdf

http://www.emc.com/collateral/white-papers/h11301-pkcs-12v1-1-personal-information-exchange-syntax-wp.pdf

http://www.ietf.org/rfc/rfc4210.txt





http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART1_piv-card-applic-namespace-date-model-rep.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART1_piv-card-applic-namespace-date-model-rep.pdf




2119Bhttp://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART2_piv-card-applic-card-common-interface.pdf 2120BPart 3: End-Point PIV Client Application Programming Interface, 2121Bhttp://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART3_piv-client-applic-programming-interface.pdf 2122BPart 4: The PIV Transitional Interfaces and Data Model Specification, 2123Bhttp://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART4_piv-transitional-interface-data-model-spec.pdf

2124BSP800-76-2 2125BBiometric Data Specifications for Personal Identity Verification, July 2013. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-76-2.pdf

2126BSP800-78-3 2127BCryptographic Algorithms and Key Sizes for Personal Identity Verification, Polk, Dodson, et. al. December 2010. http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART2_piv-card-applic-card-common-interface.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART2_piv-card-applic-card-common-interface.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART3_piv-client-applic-programming-interface.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART3_piv-client-applic-programming-interface.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART4_piv-transitional-interface-data-model-spec.pdf

http://csrc.nist.gov/publications/nistpubs/800-73-3/sp800-73-3_PART4_piv-transitional-interface-data-model-spec.pdf

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-76-2.pdf

http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf




13 126BACRONYMS & ABBREVIATIONS

2128BAES 2129BAdvanced Encryption Standard

2130BANSI 2131BAmerican National Standards Institute

2132BC 2133BCountry

2134BCA 2135BCertification Authority

2136BCBCA 2137BCertiPath Bridge Certification Authority

2138BCBP 2139BCommercial Best Practices

2140BCISO 2141BRaytheon Chief Information Security Officer

2142BCMA 2143BCertificate Management Authority

2144BCN 2145BCommon Name

2146BCP 2147BCertificate Policy

2148BCPS 2149BCertification Practice Statement

2150BCRL 2151BCertificate Revocation List

2152BCSA 2153BCertificate Status Authority

2154BDC 2155BDomain Component

2156BDN 2157BDistinguished Name

2158BDNS 2159BDomain Name Service

2160BDP 2161BDistribution Point

2162BECDH 2163BElliptic Curve Diffie Hellman

2164BECDSA 2165BElliptic Curve Digital Signature Algorithm

2166BEE 2167BEnd Entity

2168BEKU 2169BExtended Key Usage

2170BFBCA 2171BFederal Bridge Certification Authority




2172BFIPS 2173B(US) Federal Information Processing Standard

2174BFIPS PUB 2175B(US) Federal Information Processing Standard Publication

2176BFSO 2177BFacility Security Officer

2178BHR 2179BHuman Resources

2180BHTTP 2181BHypertext Transfer Protocol

2182BIAO 2183BInformation Assurance Officer

2184BID 2185BIdentifier

2186BIETF 2187BInternet Engineering Task Force

2188BISO 2189BInternational Organization for Standardization

2190BJPAS 2191BJoint Personnel Adjudication System

2192BKRP 2193BKey Recovery Policy

2194BKRPS 2195BKey Recovery Practices Statement

2196BLDAP 2197BLightweight Directory Access Protocol

2198BMASCA 2199BMedium Assurance Signing Certificate Authority

2200BMOA 2201BMemorandum of Agreement (as used in the context of this CP, between an Entity and Raytheon allowing interoperation between the Raytheon Root CA and Entity Principal CA). Raytheon Supply Chain consults RPMA through the RPMA Chair on the MOA.

2202BNIST 2203BNational Institute of Standards and Technology

2204BNTP 2205BNetwork Time Protocol

2206BO 2207BOrganization

2208BOA 2209BOperational Authority

2210BOCSP 2211BOnline Certificate Status Protocol

2212BOID 2213BObject Identifier

2214BOU 2215BOrganizational Unit




2216BPII 2217BPersonally Identifiable Information

2218BPIN 2219BPersonal Identification Number

2220BPKCS 2221BPublic Key Certificate Standard

2222BPKI 2223BPublic Key Infrastructure

2224BPKIX 2225BPublic Key Infrastructure X.509

2226BPMA 2227BPolicy Management Authority

2228BPMSA 2229BPolicy Mapping Service Agreement

2230BRA 2231BRegistration Authority

2232BRFC 2233BRequest For Comments

2234BRPMA 2235BRaytheon Policy Management Authority

2236BRRCA 2237BRaytheon Root Certification Authority

2238BRSA 2239BRivest-Shamir-Adleman (encryption algorithm)

2240BSCVP 2241BSimple Certificate Validation Protocol

2242BSHA-1 2243BSecure Hash Algorithm, Version 1

2244BSHA-2 2245BSecure Hash Algorithm, Version 2

2246BSSL 2247BSecure Sockets Layer

2248BTDES 2249BTriple Data Encryption Standard

2250BTLS 2251BTransport Layer Security

2252BUPS 2253BUninterrupted Power Supply

2254BURI 2255BUniform Resource Identifier

2256BURL 2257BUniform Resource Locator




14 127BGLOSSARY 2258BAccess 2259BAbility to make use of any information system (IS) resource. 2260BAccess Control 2261BProcess of granting access to information system resources only to

authorized users, programs, processes, or other systems. 2262BAccreditation 2263BFormal 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.

2264BActivation Data 2265BPrivate data, other than keys, that are required to access cryptographic modules (i.e., unlock private keys for signing or decryption events).

2266BAgreement 2267BAgreement (as used in the context of this CP, between an Entity and Raytheon allowing interoperation between the Raytheon Root CA and Entity Principal CA). The Agreement will generally take the form of a Memorandum of Agreement and is binding on both parties.

2268BApplicant 2269BThe 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]

2270BArchive 2271BLong-term, physically separate storage. 2272BAudit 2273BIndependent 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.

2274BAudit Data 2275BChronological record of system activities to enable the reconstruction and examination of the sequence of events and changes in an event.

2276BAuthenticate 2277BTo confirm the identity of an entity when that identity is presented. 2278BAuthentication 2279BSecurity 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.

2280BBackup 2281BCopy of files and programs made to facilitate recovery if necessary. 2282BBinding 2283BProcess of associating two related elements of information. 2284BBiometric 2285BA physical or behavioral characteristic of a human being. 2286BBridge Certification Authority Membrane

2287BThe Bridge Certification Authority Membrane consists of a collection of Public Key Infrastructure devices including a variety of Certification Authority PKI products, Databases, CA specific PKI




Repositories, Border PKI Repository, Firewalls, Routers, Randomizers, etc.

2288BCA Facility 2289BThe collection of equipment, personnel, procedures and structures that are used by a Certification Authority to perform certificate issuance and revocation.

2290BCertificate 2291BA digital representation of information which at least (1) identifies the certification authority Signing 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 Signing it. [ABADSG]. As used in this CP, the term “Certificate” refers to certificates that expressly reference the OID of this CP in the “Certificate Policies” field of an X.509 v.3 certificate.

2292BCertificate 2293BA digital representation of information which at least (1) identifies the certification authority Signing 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 Signing it. [ABADSG]

2294BCertificate Management Authority (CMA)

2295BA Certification Authority or a Registration Authority.

2296BCertificate Policy (CP) 2297BA 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.

2298BCertificate Revocation List (CRL)

2299BA list maintained by a Certification Authority of the certificates which it has issued that are revoked prior to their stated expiration date.

2300BCertificate Status Authority 2301BA trusted entity that provides online verification to a Relying Party of a subject certificate's trustworthiness, and may also provide additional attribute information for the subject certificate.

2302BCertificate-Related Information

2303BInformation, such as a subscriber's postal address, that is not included in a certificate. May be used by a CA managing certificates.

2304BCertification Authority (CA) 2305BAn authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CRLs.

2306BCertification Authority Software

2307BKey Management and cryptographic software used to manage certificates issued to subscribers.




2308BCertification Practice Statement (CPS)

2309BA statement of the practices that a CA employs in Signing, 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 services).

2310BCertificate Sponsor 2311BRaytheon Company is the certificate sponsor for all certificates issued by the Raytheon PKI.

2312BCertiPath Bridge Certification Authority (CBCA)

2313BThe CertiPath Bridge Certification Authority consists of a collection of Public Key Infrastructure devices (Certificate Authorities, PKI Repositories, Certificate Policies and Certificate Practice Statements) that are used to provide peer to peer interoperability among Entity Principal Certification Authorities.

2314BClient (application) 2315BA system entity, usually a computer process acting on behalf of a human user, that makes use of a service provided by a server.

2316BCommon Criteria 2317BA set of internationally accepted semantic tools and constructs for describing the security needs of customers and the security attributes of products.

2318BComponent 2319BA system element offering a predefined service and able to communicate with other components. A constituent element, as of a system.

2320BCompromise 2321BDisclosure 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.

2322BComputer Security Objects Registry (CSOR)

2323BComputer Security Objects Registry operated by the National Institute of Standards and Technology.

2324BConfidentiality 2325BAssurance that information is not disclosed to unauthorized entities or processes.

2326BCredential 2327BEvidence attesting to one’s right to credit or authority; in this CP, it is any software- or hardware-based artifact and data elements associated with an individual that authoritatively binds an identity (and, optionally, additional attributes) to that individual.

2328BCross-Certificate 2329BA certificate used to establish a trust relationship between two Certification Authorities.

2330BCryptographic Module 2331BThe 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. [FIPS1402]

2332BCryptoperiod 2333BTime span during which each key setting remains in effect.




2334BData Integrity 2335BAssurance that the data are unchanged from creation to reception. 2336BDevices 2337BNon-human entities that may be issued a certificate. Examples are

server, network router, firewall, etc. 2338BDigital Signature 2339BThe result of a transformation of a message by means of a

cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.

2340BDual Use Certificate 2341BA certificate that is intended for use with both digital signature and data encryption services.

2342BDuration 2343BA field within a certificate which is composed of two subfields; “date of issue” and “date of next issue”.

2344BE-commerce 2345BThe use of network technology (especially the internet) to buy or sell goods and services.

2346BEmployee 2347BAny person employed by an Entity as defined above. 2348BEncryption Certificate 2349BA 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.

2350BEnd Entity 2351BRelying Parties and Subscribers. 2352BEntity 2353BAn organization with operational control of a CA that will

interoperate with a Raytheon CA. 2354BEntity CA 2355BA CA that acts on behalf of an Entity, and is under the operational

control of an Entity. 2356BExtended Key Usage 2357BA certificate extension to further restrict the applications for which

the public key in the certificate can be used. 2358BFirewall 2359BGateway that limits access between networks in accordance with

local security policy. 2360BInside threat 2361BAn entity with authorized access that has the potential to harm an

information system through destruction, disclosure, modification of data, and/or denial of service.

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

2364BIntellectual Property 2365BUseful artistic, technical, and/or industrial information, knowledge or ideas that convey ownership and control of tangible or virtual usage and/or representation.




2366BIntermediate CA 2367BA CA that is subordinate to another CA, and has a CA subordinate to itself.

2368BKey Escrow 2369BA 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"]

2370BKey Exchange 2371BThe process of exchanging public keys in order to establish secure communications.

2372BKey Generation Material 2373BRandom numbers, pseudo-random numbers, and cryptographic parameters used in generating cryptographic keys.

2374BKey Pair 2375BTwo mathematically related keys having the properties that (1) one key can be used to encrypt a message that can only be decrypted using the other key, and (ii) even knowing one key, it is computationally infeasible to discover the other key.

2376BLocal Registration Authority (LRA)

2377BA Registration Authority with responsibility for a local community.

2378BMission Support Information 2379BInformation that is important to the support of deployed and contingency forces.

2380BMutual Authentication 2381BOccurs when parties at both ends of a communication activity authenticate each other (see authentication).

2382BNaming Authority 2383BAn organizational entity responsible for assigning distinguished names (DNs) and for assuring that each DN is meaningful and unique within its domain.

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

2386BObject Identifier (OID) 2387BA 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.

2388BOut-of-Band 2389BCommunication 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).

2390BOutside Threat 2391BAn unauthorized entity from outside the domain perimeter that has the potential to harm an Information System through destruction, disclosure, modification of data, and/or denial of service.

107BPersonally Identifiable Information

108BInformation that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual.

2392BPhysically Isolated Network 2393BA network that is not connected to entities or systems outside a physically controlled space.

2394BPKI Repository 2395BSee Repository 2396BPKI Sponsor 2397BFills the role of a Subscriber for non-human system devices that are

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

2398BPolicy Management Authority (PMA)

2399BBody 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.

2400BPrivacy 2401BRestricting access to subscriber or Relying Party information in accordance with Federal law and Entity policy.

2402BPrivate Key 2403B(1) The key of a signature key pair used to create a digital signature. 2404B(2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret.

2405BPublic Key 2406B(1) The key of a signature key pair used to validate a digital signature. 2407B(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.

2408BPublic Key Infrastructure (PKI)

2409BA 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.

2410BRaytheon Medium Assurance Signing Certification Authority (MASCA)

2411BThe Raytheon Medium Assurance Signing Certification Authority is a subordinate signing CA that issues certificates to users, components, applications and devices.




2412BRaytheon Operational Authority (Raytheon OA)

2413BThe Raytheon Operational Authority is the organization selected by the Raytheon PMA (RPMA) to be responsible for operating the Raytheon PKI.

2414BRaytheon PMA (RPMA) 2415BThe Raytheon PMA (RPMA) is a body responsible for setting, implementing, and administering policy decisions regarding PKI interoperability that uses the Raytheon.

2416BRaytheon Root Certification Authority (RRCA)

2417BThe Raytheon Root Certification Authority is the top-level, self-signed CA that is used to issue cross-certificates and subordinate certificates.

2418BRegistration Authority (RA) 2419BAn entity that issues certificates to users and devices. 2420BRe-key (a certificate) 2421BTo change the value of a cryptographic key that is being used in a

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

2422BRelying Party 2423BA person or Entity 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.

2424BRenew (a certificate) 2425BThe act or process of extending the validity of the data binding asserted by a public key certificate by Signing a new certificate.

2426BRepository 2427BA database containing information and data relating to certificates as specified in this CP; may also be referred to as a directory. In this CP, Repository refers to PKI Repository.

2428BResponsible Individual 2429BA trustworthy person designated by a sponsoring organization to authenticate individual applicants seeking certificates on the basis of their affiliation with the sponsor.

2430BRevoke a Certificate 2431BTo prematurely end the operational period of a certificate effective at a specific date and time.

2432BRisk 2433BAn expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result.

2434BRisk Tolerance 2435BThe level of risk an entity is willing to assume in order to achieve a potential desired result.

2436BRoot CA 2437BIn 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.

2438BServer 2439BA system entity that provides a service in response to requests from clients.

2440BSignature Certificate 2441BA public key certificate that contains a public key intended for verifying digital signatures rather than encrypting data or performing any other cryptographic functions.




2442BSubordinate CA 2443BIn 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).

2444BSubscriber 2445BA 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

2446BSuperior CA 2447BIn 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).

2448BSupervised Remote Identity Proofing

2449BA real-time identity proofing event where the RA/Trusted Agent is not in the same physical location as the applicant/subscriber. The RA/Trusted Agent controls the device utilized by the applicant/subscriber during the remote identity proofing process. The remote identity proofing process employs physical, technical and procedural measures that provide sufficient confidence that the remote session can be considered equivalent to a physical, in-person identity proofing process. Supervised Remote Identity Proofing must meet the criteria specified in Section 5.3.3 of NIST SP 800-63A, dated June 2017; and must have the capacity to capture an approved biometric when utilized for PIV-I credential issuance.

2450BSystem Equipment Configuration

2451BA comprehensive accounting of all system hardware and software types and settings.

2452BTechnical non-repudiation 2453BThe contribution public key mechanisms to the provision of technical evidence supporting a non-repudiation security service.

2454BThreat 2455BAny 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.

2456BTrust List 2457BCollection of trusted certificates used by Relying Parties to authenticate other certificates.

2458BTrusted Agent 2459BEntity authorized to act as a representative of an Entity in confirming Subscriber identification during the registration process. Trusted Agents do not have automated interfaces with Certification Authorities.

2460BTrusted Certificate 2461BA 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".

2462BTrusted Timestamp 2463BA digitally signed assertion by a trusted authority that a specific digital object existed at a particular time.




2464BTrustworthy System 2465BComputer 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 suited to performing their intended functions; and (4) adhere to generally accepted security procedures.

2466BTwo-Person Control 2467BContinuous surveillance and control of positive control material at all times by a minimum of two authorized individuals, each capable of detecting incorrect and/or unauthorized procedures with respect to the task being performed, and each familiar with established security and safety requirements.

2468BUpdate (a certificate) 2469BThe act or process by which data items bound in an existing public key certificate, especially authorizations granted to the subject, are changed by Signing a new certificate.

2470BUpdate (in reference to significant change)

2471BAlterations to Licensed Software, including code and/or error corrections and minor code enhancements or modifications, that may be developed and generally released from time to time by the Software Vendor and made available to the customer (licensee). Software Updates do not include: (i) Software Upgrades of the Licensed Software that may be developed and generally released from time to time by the software vendor

2472BUpgrade (in reference to significant change)

2473BEnhancements to the Licensed Software providing a new program feature or function that may be developed and generally released from time to time by the software vendor and made available to customer (licensee). Software Upgrades do not include: (i) Software Updates of the Licensed Software that may be developed and generally released from time to time by the software updates

2474BZeroize 2475BA method of erasing electronically stored data by altering the contents of the data storage so as to prevent the recovery of the data. [FIPS1402]