ACT2%SUDI%CACertification PracticeStatement · act2!sudi!cacertificationpractice!statement!...

ACT2 SUDI CA Certification Practice Statement

Cisco Systems Certification Practice Statement

Cisco Systems has implemented Certificate Authorities (CAs) to provide device identity for ACT2-‐enabled Cisco products. The CAs consist of systems, products, and services that both protect the CAs' private keys and manage the x.509v3 certificates issued from the CAs. These CAs, ACT2 SUDI CA and ACT2 ECC SUDI CA, are subordinate CAs signed by Cisco Root CA 2048 and the Cisco ECC Root CA respectively. These CAs are henceforth referred to as “ACT2 SUDI CAs” or “ACT2 SubCAs.” The purpose of this document is to describe the practices that Cisco Systems (“Cisco”) follows for the operation and management of the ACT2 Sub CAs within Cisco Systems Inc., and the practices governing the issuance and life cycle of certificates issued from the ACT2 Sub CAs, for the benefit of relying users.

ACT2 SUDI CA Certification Practice Statement • • •

Table of Contents � 1

ACT2 SUDI CA Certification Practice Statement Cisco Systems Certification Practice Statement

Table of Contents

TABLE OF CONTENTS 1

DOCUMENT METADATA 5

VERSION HISTORY 5 APPROVALS 6

1 INTRODUCTION 7

1.1 OVERVIEW 7 1.2 DOCUMENT NAME AND POLICY IDENTIFICATION 7 1.3 PKI PARTICIPANTS 7 1.3.1 CERTIFICATION AUTHORITIES 7 1.3.2 REGISTRATION AUTHORITIES 8 1.3.3 SUBSCRIBERS 8 1.3.4 RELYING PARTIES 8 1.3.5 OTHER PARTICIPANTS 8 1.4 CERTIFICATE USAGE 8 1.4.1 APPROPRIATE CERTIFICATE USES 8 1.4.2 PROHIBITED CERTIFICATE USES 8 1.5 POLICY ADMINISTRATION 8 1.5.1 ORGANIZATION ADMINISTERING THE DOCUMENT 8 1.5.2 CONTACT PERSON 8 1.5.3 CPS APPROVAL PROCEDURES 9

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 9

2.1 REPOSITORIES 9 2.2 PUBLICATION OF CERTIFICATION INFORMATION 10 2.3 TIME OR FREQUENCY OF PUBLICATION 10 2.4 ACCESS CONTROLS ON REPOSITORIES 10

3 IDENTIFICATION AND AUTHENTICATION 10

3.1 NAMING 10 3.1.1 TYPES OF NAMES 10 3.1.2 NEED FOR NAMES TO BE MEANINGFUL 11 3.1.3 ANONYMITY OR PSEUDONYMITY OF SUBSCRIBERS 11



3.1.4 RULES FOR INTERPRETING VARIOUS NAME FORMS 11 3.1.5 UNIQUENESS OF NAMES 11 3.2 INITIAL IDENTITY VALIDATION 11 3.2.1 METHOD TO PROVE POSSESSION OF THE PRIVATE KEY 11 3.2.2 AUTHENTICATION OF ORGANIZATION IDENTITY 11 3.2.3 AUTHENTICATION OF INDIVIDUAL IDENTITY 11 3.2.4 NON-‐VERIFIED SUBSCRIBER INFORMATION 11 3.2.5 VALIDATION OF AUTHORITY 11 3.2.6 CRITERIA FOR INTEROPERATION 12 3.3 IDENTIFICATION AND AUTHENTICATION FOR CERTIFICATE RE-‐KEY 12

4 CERTIFICATE LIFE-‐CYCLE OPERATIONAL REQUIREMENTS 12

4.1 CERTIFICATE APPLICATION 12 4.1.1 WHO CAN SUBMIT A CERTIFICATE APPLICATION 12 4.1.2 ENROLLMENT PROCESS AND RESPONSIBILITIES 12 4.2 CERTIFICATE APPLICATION PROCESSING 12 4.2.1 PERFORMING IDENTIFICATION AND AUTHENTICATION FUNCTIONS 12 4.2.2 APPROVAL OR REJECTION OF CERTIFICATE APPLICATIONS 12 4.2.3 TIME TO PROCESS CERTIFICATE APPLICATIONS 13 4.3 CERTIFICATE ISSUANCE 13 4.3.1 CA ACTIONS DURING CERTIFICATE ISSUANCE 13 4.3.2 NOTIFICATION TO SUBSCRIBER BY THE CA OF ISSUANCE OF CERTIFICATE 13 4.4 CERTIFICATE ACCEPTANCE 13 4.4.1 CONDUCT CONSTITUTING CERTIFICATE ACCEPTANCE 13 4.4.2 PUBLICATION OF THE CERTIFICATE BY THE CA 13 4.4.3 NOTIFICATION OF CERTIFICATE ISSUANCE BY THE CA TO OTHER ENTITIES 13 4.5 KEY PAIR AND CERTIFICATE USAGE 13 4.5.1 SUBSCRIBER PRIVATE KEY AND CERTIFICATE USAGE 13 4.5.2 RELYING PARTY PUBLIC KEY AND CERTIFICATE USAGE 13 4.6 CERTIFICATE RENEWAL 14 4.7 CERTIFICATE RE-‐KEY 14 4.8 CERTIFICATE MODIFICATION 14 4.9 CERTIFICATE REVOCATION AND SUSPENSION 14 4.9.1 CIRCUMSTANCES FOR REVOCATION 14 4.9.2 WHO CAN REQUEST REVOCATION 14 4.9.3 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST 14 4.9.4 PROCEDURE FOR REVOCATION REQUEST 15 4.9.5 REVOCATION REQUEST GRACE PERIOD 15 4.9.6 TIME WITHIN WHICH CA MUST PROCESS THE REVOCATION REQUEST 15 4.9.7 REVOCATION CHECKING REQUIREMENT FOR RELYING PARTIES 15 4.9.8 CRL ISSUANCE FREQUENCY 15



4.9.9 MAXIMUM LATENCY FOR CRLS AND ONLINE STATUS CHECKING MECHANISMS 15 4.9.10 CERTIFICATE STATUS SERVICES 15

5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 15

5.1 PHYSICAL CONTROLS 15 5.1.1 SITE LOCATION AND CONSTRUCTION 15 5.1.2 PHYSICAL ACCESS 15 5.1.3 POWER AND AIR CONDITIONING 16 5.1.4 WATER EXPOSURES 16 5.1.5 FIRE PREVENTION AND PROTECTION 16 5.1.6 MEDIA STORAGE 16 5.1.7 WASTE DISPOSAL 16 5.1.8 OFF-‐SITE BACKUP 17 5.2 PROCEDURAL CONTROLS 17 5.2.1 TRUSTED ROLES 17 5.2.2 NUMBER OF PERSONS REQUIRED PER TASK 17 5.2.3 IDENTIFICATION AND AUTHENTICATION FOR EACH ROLE 17 5.2.4 ROLES REQUIRING SEPARATION OF DUTIES 17 5.3 PERSONNEL CONTROLS 18 5.3.1 BACKGROUND AND QUALIFICATIONS 18 5.3.2 BACKGROUND INVESTIGATION 18 5.3.3 TRAINING REQUIREMENTS 18 5.3.4 DOCUMENTATION SUPPLIED TO PERSONNEL 18 5.4 AUDIT LOGGING PROCEDURES 18 5.4.1 TYPES OF EVENTS RECORDED 18 5.4.2 FREQUENCY OF PROCESSING LOG 18 5.4.3 RETENTION PERIOD FOR AUDIT LOG 18 5.4.4 PROTECTION OF AUDIT LOG 19 5.4.5 AUDIT LOG BACKUP PROCEDURES 19 5.4.6 VULNERABILITY ASSESSMENTS 19 5.5 CA OR RA TERMINATION 19

6 TECHNICAL SECURITY CONTROLS 19

6.1 KEY PAIR GENERATION AND INSTALLATION 19 6.1.1 KEY PAIR GENERATION 19 6.1.2 PRIVATE KEY DELIVERY TO SUBSCRIBER 19 6.1.3 PUBLIC KEY DELIVERY TO CERTIFICATE ISSUER 20 6.1.4 CA PUBLIC KEY DELIVERY TO RELYING PARTIES 20 6.1.5 KEY SIZES 20 6.1.6 PUBLIC KEY PARAMETERS GENERATION AND QUALITY CHECKING 20 6.1.7 KEY USAGE PURPOSES (AS PER X.509 V3 KEY USAGE FIELD) 21



6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS 21 6.2.1 CRYPTOGRAPHIC MODULE STANDARDS AND CONTROLS 21 6.2.2 PRIVATE KEY (N OUT OF M) MULTI-‐PERSON CONTROL 21 6.2.3 PRIVATE KEY ESCROW 21 6.2.4 PRIVATE KEY BACKUP, ARCHIVAL, AND RESTORATION 21 6.2.5 PRIVATE KEY TRANSFER INTO OR FROM A CRYPTOGRAPHIC MODULE 21 6.2.6 PRIVATE KEY STORAGE ON CRYPTOGRAPHIC MODULE 22 6.2.7 METHOD OF ACTIVATING A PRIVATE KEY 22 6.2.8 METHOD OF DEACTIVATING A PRIVATE KEY 22 6.2.9 METHOD OF DESTROYING A PRIVATE KEY 22 6.2.10 CRYPTOGRAPHIC MODULE RATING 22 6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT 22 6.3.1 PUBLIC KEY ARCHIVAL 22 6.3.2 CERTIFICATE OPERATIONAL PERIODS AND KEY PAIR USAGE PERIODS 22 6.4 ACTIVATION DATA 22 6.5 COMPUTER SECURITY CONTROLS 23 6.6 LIFE-‐CYCLE TECHNICAL CONTROLS 23 6.6.1 SYSTEM DEVELOPMENT CONTROLS 23 6.6.2 SECURITY MANAGEMENT CONTROLS 23 6.6.3 LIFE-‐CYCLE SECURITY CONTROLS 23 6.7 NETWORK SECURITY CONTROLS 23 6.8 TIMESTAMPING 24

7 CERTIFICATE AND CRL PROFILES 24

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS 24

8.1 ASSESSMENT OF COMPLIANCE 24 8.2 QUALIFICATIONS OF AUDITOR 24 8.3 AUDITOR'S RELATIONSHIP TO AUDITED ENTITY 24 8.4 CONTENT OF AUDIT 24 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY 24 8.6 COMMUNICATION OF AUDIT RESULTS 24

9 OTHER BUSINESS AND LEGAL MATTERS 25

9.1 FEES 25 9.2 FINANCIAL RESPONSIBILITY 25 9.3 CONFIDENTIALITY OF BUSINESS INFORMATION 25 9.4 PRIVACY OF PERSONAL INFORMATION 25 9.5 INTELLECTUAL PROPERTY RIGHTS 25 9.6 REPRESENTATIONS AND WARRANTIES 25 9.6.1 CA OBLIGATIONS 25


Document Metadata � 5

9.6.2 CA REPRESENTATIONS 25 9.6.3 BENEFITING PARTY WARRANTIES 26 9.6.4 WARRANTY LIMITATIONS 26 9.6.5 END ENTITY AGREEMENTS 27 9.6.6 REGISTRATION AUTHORITY (RA) OBLIGATIONS 27 9.6.7 CERTIFICATE STATUS VALIDATION OBLIGATIONS 28 9.6.8 SUBSCRIBER OBLIGATIONS 28 9.6.9 BENEFITING PARTY OBLIGATIONS 28 9.7 LIABILITY 28 9.8 INTERPRETATION & ENFORCEMENT 29 9.8.1 GOVERNING LAW 29 9.8.2 DISPUTE RESOLUTION PROCEDURES 29 9.8.3 SEVERABILITY 29 9.8.4 SURVIVAL 29 9.8.5 MERGER/INTEGRATION 29 9.8.6 NOTICE 29 9.9 AMENDMENTS 29 9.9.1 PROCEDURE FOR AMENDMENT 29 9.9.2 NOTIFICATION MECHANISM AND PERIOD 29 9.9.3 CIRCUMSTANCES UNDER WHICH OID MUST BE CHANGED 29

10 REFERENCES 30

10.1 NORMATIVE REFERENCES 30 10.2 INFORMATIVE REFERENCES 30

APPENDIX A -‐ DEFINITIONS AND ACRONYMS 31

Document Metadata Version History

Version No. Issue Date Significant Changes 1.0 2013-‐May-‐10 First version of document 2.0 2014-‐Jan-‐31 Document structure updated to align with RFC 3647 and similar

documents.


Document Metadata � 6

Approvals Version Reviewer Title Date 1.0 J.P. Hamilton

Alex Wight Jos Purvis

Identity Assurance Services – Manager Identity Assurance Services – Architect Identity Assurance Services – Compliance Lead

2013-‐05-‐10 2013-‐05-‐10 2013-‐05-‐10

2.0 J.P. Hamilton Alex Wight Jos Purvis Bill Friedman

Identity Assurance Services – Manager Identity Assurance Services – Architect Identity Assurance Services – Compliance Lead Cisco Legal Counsel

2014-‐01-‐31 2014-‐01-‐31 2014-‐01-‐31 2014-‐01-‐30


Introduction � 7

1 Introduction 1.1 Overview Cisco Systems has implemented Certificate Authorities (CAs) to provide device identity for ACT2-‐enabled Cisco products. The CAs consist of systems, products, and services that both protect the CAs' private keys and manage the x.509v3 certificates issued from the CAs. These CAs, ACT2 SUDI CA and ACT2 ECC SUDI CA, are subordinate CAs signed by Cisco Root CA 2048 and the Cisco ECC Root CA respectively. These CAs are henceforth referred to as “ACT2 SUDI CAs” or “ACT2 SubCAs.”

The purpose of this document is to describe the practices that Cisco Systems (“Cisco”) follows for the operation and management of the ACT2 Sub CAs within Cisco Systems Inc., and the practices governing the issuance and life cycle of certificates issued from the ACT2 Sub CAs, for the benefit of relying users.

1.2 Document Name and Policy Identification The IANA-‐assigned OID for the Cisco private enterprise is

cisco OID :: = {iso(1) identified-‐organization(3) dod(6) internet(1) private(4) enterprise(1) cisco(9)} (1.3.6.1.4.1.9)

Under this OID arc, Cisco has defined the following PKI-‐specific OID for ACT2 SUDI CA:

cisco-‐pki OID ::= { cisco 21 } (1.3.6.1.4.1.9.21)

cisco-‐pki-‐policies OID ::= { cisco-‐pki 1 } (...9.21.1)

cisco-‐pki-‐policies-‐act2-‐sudi OID ::= { cisco-‐pki-‐policies 12 } (...9.21.1.12)

cisco-‐pki-‐policies-‐act2-‐sudi-‐version OID ::= { cisco-‐pki-‐policies-‐act2-‐sudi 0 } (...9.21.1.12.0)

And the following OID for ACT2 ECC SUDI CA:

cisco-‐pki OID ::= { cisco 21 } (1.3.6.1.4.1.9.21)

cisco-‐pki-‐policies OID ::= { cisco-‐pki 1 } (...9.21.1)

cisco-‐pki-‐policies-‐act2-‐sudi-‐ecc OID ::= { cisco-‐pki-‐policies 19} (...9.21.1.19)

cisco-‐pki-‐policies-‐act2-‐ecc-‐sudi-‐version OID ::= { cisco-‐pki-‐policies-‐act2-‐ecc-‐sudi 0 } (...9.21.1.19.0)

Thus, the OIDs representing this version of the Certificate Policy are 1.3.6.1.4.1.9.21.1.12.0 for the ACT2 SUDI CA and 1.3.6.1.4.1.9.21.1.19.0 for the ACT2 ECC SUDI CA. Any changes to this Certificate Policy will result in an increment of the cisco-‐pki-‐policies-‐act2-‐sudi-‐version and cisco-‐pki-‐policies-‐act2-‐ecc-‐sudi-‐version OIDs. For example, the next version of this policy statement (v3.0) would change the CP OIDs to 1.3.6.1.4.1.9.21.1.12.1 and 1.3.6.1.4.1.9.21.1.19.1, respectively.

1.3 PKI Participants 1.3.1 Certification Authorities The ACT2 Subordinate CAs ("ACT2 SubCAs") owned by Cisco Systems, Inc. and operated by Cisco Systems Corporate Information Security group, are the only CAs authorized to issue certificates under this policy. This practice statement governs the issuance activities of the ACT2 Subordinate Certificate Authorities ("the ACT2 SubCAs," henceforth) owned by Cisco Systems and operated by Cisco Systems Corporate Information Security


Introduction � 8

group. No further subordinate certificate authorities or registration authorities have been created from the ACT2 SubCAs.

1.3.2 Registration Authorities See section 1.3.1.

1.3.3 Subscribers The ACT2 SubCAs only issue digital certificates to ACT2-‐enabled software and hardware products manufactured for or on behalf of Cisco Systems. These subscribers are referred to as "ACT2 Subscribing Products" from here onward.

1.3.4 Relying Parties This Practice Statement is intended for the benefit of the following persons who may rely on certificates that reference this Policy ("Benefiting Parties"):

• Cisco agencies and businesses that contractually agree to the ACT2 SUDI Certificate Policy (q.v.) with the Cisco Systems Information Security group and/or with the CA;

• Individuals that contractually agree to the ACT2 SUDI Certificate Policy with the Cisco Systems Information Security group and/or with the CA;

• Entities that have entered into a Certificate Trust Agreement with Cisco Systems wherein the ACT2 SUDI Certificate Policy is specifically referenced.

1.3.5 Other Participants No other participants are defined under this practice statement.

1.4 Certificate Usage 1.4.1 Appropriate Certificate Uses Certificates issued under this Policy may be used for the secure authentication of software and hardware products manufactured by or on behalf of Cisco Systems Inc., or for the encryption or digital signature of information transmitted to or from the subscribing product.

1.4.2 Prohibited Certificate Uses No specific prohibitions of usage are made under this Policy; however, no other use of certificates issued under this Practice Statement is warranted or specifically provided for under this Practice Statement.

1.5 Policy Administration 1.5.1 Organization Administering the Document This Policy is administered by the Corporate Information Security group of Cisco Systems, Inc.:

Corporate Headquarters Cisco Systems Inc. 170 West Tasman San Jose, CA 95134

1.5.2 Contact Person Please send PKI-‐based correspondence to:

Cisco Systems Inc. Attn: J.P. Hamilton 7025 Kit Creek Road P.O. Box 14987


Publication and Repository Responsibilities � 9

Research Triangle Park, NC 27709-‐4987 Phone number: 919-‐392-‐1481 E-‐mail address: ciscopki-‐[email protected]

CA Policy Authority:

Cisco Systems Inc. Attn: J.P. Hamilton 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709-‐4987 E-‐mail address: ciscopki-‐[email protected]

1.5.3 CPS Approval Procedures Changes to this CPS are made by the Cisco's Policy Management Authority (PMA), which includes Cisco’s Corporate Security Programs Office and Legal department. Changes are proposed by members of the Policy Management Authority, reviewed by the entire group, formally approved individually, and then incorporated into an updated document that is assigned a subsequent version number. Approved versions of this document shall be published to the main Cisco PKI Policies page located at

http://www.cisco.com/security/pki/policies/index.html.

The updated version of the document shall be considered binding on all Issuing CAs and relevant subscribers within 30 days of issuance.

1.5.3.1 CPS Approvals The Cisco Systems Information Security Policy Management Authority shall be responsible for reviewing and approving the compliance of relevant CPS documents for any certificate authorities subordinated to the ACT2 SubCAs.

1.5.3.2 Notifications of Changes Notifications of changes to this document will not be published unless the changes affect the material content or issuing practices for certificates from the ACT2 SubCAs. In the event that a notification is required, the Cisco Systems Information Security group operating the ACT2 SubCAs will publish a notification to identified contacts for device certificate management associated with these SubCAs.

1.5.3.3 Version Management and Changes The ACT2 SubCA CPS complies with CP requirements for version management, numbering, and change tracking by publishing a version history table for this document that indicates changes and publication dates across revisions, assigning version numbers according to the CP change requirements.

2 Publication and Repository Responsibilities 2.1 Repositories Cisco Systems maintains a public repository of CA information and policy documents, available at http://www.cisco.com/security/pki/policies/index.html. A copy of the latest version of this document shall be


Identification and Authentication � 10

made publicly available at that URL. The ACT2 SubCAs publish this document, a copy of the ACT2 SubCAs' public keys and digital certificates, and certificate revocation lists, to that URL. No other repository of this information is maintained.

2.2 Publication of Certification Information The ACT2 SubCAs contribute to a secure on-‐line repository operated by the Cisco Systems Information Security group that is available to Benefiting Parties and that contains: (1) issued certificates for the ACT2 SubCAs; (2) a Certificate Revocation List ("CRL"); (3) the ACT2 SubCAs' certificates for their signing keys; and (4) past and current versions of the CA's public CPS.

2.3 Time or Frequency of Publication All information authorized to be published in a repository shall be published promptly after such information is authorized and available to the ACT2 SubCAs. Certificates issued by the ACT2 SubCAs will be published promptly upon acceptance of such certificate by the subscriber, and when publication is authorized by the subscriber. Information relating to the revocation of a certificate will be published in accordance with section 2.2.

2.4 Access Controls on Repositories The ACT2 SubCAs contribute to a repository (http://www.cisco.com/security/pki/policies/index.html) that is available to Benefiting Parties and subscribers 24 hours per day, 7 days per week, subject to reasonable scheduled maintenance and the CA's then current terms of access. The ACT2 SubCAs do not impose any access controls on this Policy, the certificates for their signing keys, and past and current versions of the CP and CPS documents contained there. Subscriber certificates are not published to this repository; no access controls are maintained around any certificates, certificate status information, or CRLs available at that site.

3 Identification and Authentication 3.1 Naming Per the requirements specified in the ACT2 SUDI Certificate Policy (q.v.), the information specified below is transmitted to and from the subscriber exclusively using an electronic channel utilizing TLS encryption between the CA, the proxy transmitter nodes, and the ACT2 Subscribing Product.

3.1.1 Types of Names

3.1.1.1 Subject Distinguished Name The Subject Distinguished Name field of certificates issued by the ACT2 SubCAs consists of a fixed "Organization" element set to "Cisco", a fixed "Organizational Unit" value of "ACT-‐2 Lite SUDI", and then two unique identifier elements. The "Common Name" element is set to the Product Identifier (PID) for the ACT2 Subscribing Product; the "serialNumber" element is set to the value "PID:xxxxxx SN:yyyyyy", where "xxxxxx" is the PID of the ACT2 Subscribing Product and "yyyyyy" is the unique Cisco Manufacturing product serial number. The combination of PID and serial number is validated as unique across all certificates issued by the ACT2 SubCAs.

3.1.1.2 Subject Alternate Name The Subject Alternate Name (or subjectAltName) field is an X.509v3 extension which consists of a single “GeneralName” of “OtherName [0]” type with a type-‐id OID of 1.3.6.1.4.1.9.21.2.3 and a value of the PrintableString “ChipID=<chipSN>”, where “chipSN” is the BASE64-‐encoded ACT2 Chip Serial Number. This


Identification and Authentication � 11

ChipSN is validated as unique across all certificates issued by the ACT2 SubCAs, and the ChipSN must match a pre-‐registered ACT2 chip serial number in the ACT2 SubCAs’ database prior to issuance.

3.1.2 Need for Names to Be Meaningful The ACT2 SubCAs validate that the ACT2 chip serial number listed in the certificate signing request matches the serial number of an ACT2 chip pre-‐registered by the chip manufacturer as valid. This ensures that the request originates from a legitimate ACT2 chip, and that the serial number in question is valid.

3.1.3 Anonymity or Pseudonymity of Subscribers The ACT2 SubCAs do not permit anonymous or pseudonymous certificate requests. In devices requesting a SUDI certificate from the ACT2 SubCAs, the ACT2 chip shall complete the generation of a Chip-‐Specific Key Material Package (CSKMP), encrypted to the public key of the Cisco ACT2 Back-‐End (CBE). The ACT2 system then creates a Chip-‐Level Identifying Information Package (CLIIP); the ACT2 chip requests and installs this package, which includes its SUDI public/private key pair, during product manufacture. Only devices with a CLIIP on record matching the serial number of the ACT2 chip on the device shall be issued an ACT2 SUDI certificate from these CAs.

3.1.4 Rules for Interpreting Various Name Forms No provision.

3.1.5 Uniqueness of Names The "Common Name" (CN) and “serialNumber" elements in the certificate subjectDN combined with the "OtherName” “ChipID=<ChipSN>” value in the certificate Subject Alternative Name extension is unique and unambiguous for all ACT2 certificates issued from the ACT2 SubCAs.

3.2 Initial Identity Validation 3.2.1 Method to Prove Possession of the Private Key The ACT2 SubCAs validate that the ACT2 Subscribing Product is in possession of the private key corresponding to the public key in the received certificate request message by verifying the digital signature on the message against the ACT2 Chip Identity.

3.2.2 Authentication of Organization Identity The ACT2 SubCAs validate the Organization identity of certificates by setting this to a fixed value during the certificate issuance process.

3.2.3 Authentication of Individual Identity The ACT2 SubCAs have implemented technical controls on the certificate review and issuance software elements to ensure that the identity of the subscriber is valid, follows name format and content rules for both the X.509v3 and IEEE 802.13AR standards, and matches a known subscriber device or entity.

3.2.4 Non-‐Verified Subscriber Information The ACT2 SUDI CAs employ technical controls in the certificate issuance process that verify the attributes in a SUDI certificate or replace them with fixed values, ensuring that no unverified information is incorporated into a certificate.

3.2.5 Validation of Authority In devices requesting a SUDI certificate from the ACT2 SubCAs, the ACT2 chip shall complete the generation of a Chip-‐Specific Key Material Package (CSKMP), encrypted to the public key of the Cisco ACT2 Back-‐End (CBE). The


Certificate Life-‐Cycle Operational Requirements � 12

ACT2 system then creates a Chip-‐Level Identifying Information Package (CLIIP); the ACT2 chip requests and installs this package, which includes its SUDI public/private key pair, during product manufacture. Only devices with a CLIIP on record matching the serial number of the ACT2 chip on the device shall be issued an ACT2 SUDI certificate from these CAs.

3.2.6 Criteria for Interoperation No provision.

3.3 Identification and Authentication for Certificate Re-‐Key The ACT2 SubCAs do not support certificate re-‐key requests.

4 Certificate Life-‐Cycle Operational Requirements 4.1 Certificate Application 4.1.1 Who Can Submit a Certificate Application Under this policy, Subscribers and Requesters are limited to software and hardware products manufacturing by or on direct behalf of Cisco Systems. The ACT2 SubCAs validate that the ACT2 chip serial number listed in the certificate signing request matches the serial number of an ACT2 chip pre-‐registered by the chip manufacturer as valid. This ensures that the request originates from a legitimate ACT2 chip, and that the serial number in question is valid.

4.1.2 Enrollment Process and Responsibilities The ACT2 SubCAs have implemented technical and procedural controls that verify the identifying information of applying subscribers. Applying subscribers should present sufficient information with their certificate signing request to ensure the ACT2 SubCAs can perform this verification. The ACT2 SubCAs have implemented technical and procedural controls such as encrypted communications channels and encrypted data storage that protect communications with applying subscribers and that adequately protect and store information presented to the CA by the applicant.

4.2 Certificate Application Processing 4.2.1 Performing Identification and Authentication Functions The ACT2 SubCAs authenticate the certificate signing request for an ACT2 Subscribing Product by validating that the serial number and PID information in the certificate signing request match valid value templates, and that the PID matches a pre-‐registered PID for a legitimately manufactured ACT2 Subscribing Product. The ACT2 SubCAs also verify the signature on the request using the ACT2 chip’s identity. This process is performed automatically upon receipt of a certificate signing request, but may be performed manually by administrators for troubleshooting or testing purposes.

4.2.2 Approval or Rejection of Certificate Applications Following the processing decision to grant or deny a certificate signing request, the ACT2 SubCAs return either a valid certificate with a success indicator value, or an error code and message. This information is transmitted automatically over the encrypted, authenticated channel back to the ACT2 Subscribing Product that made the request.



4.2.3 Time to Process Certificate Applications The ACT2 SubCAs render their certificate processing decision and return a result promptly, but no specific service level agreement exists for the time in which a result must be returned.

4.3 Certificate Issuance 4.3.1 CA Actions during Certificate Issuance During the certificate issuance process, the ACT2 SubCAs communicate with the communications proxy for the traffic from the ACT2 Subscribing Product over an encrypted, authenticated channel that uses TLS and mutual certificate authentication for security.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate Receipt of the certificate shall be considered sufficient notification to the Subscriber of certificate issuance; the ACT2 SubCAs supply a success/failure error code along with the transaction, but this is not required.

4.4 Certificate Acceptance 4.4.1 Conduct Constituting Certificate Acceptance Successful reception of the certificate across an authenticated communications channel shall be considered sufficient to constitute acceptance of the certificate.

4.4.2 Publication of the Certificate by the CA The ACT2 SubCAs do not publish successfully issued certificates to any publicly available repository.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities The ACT2 SubCAs do not issue notifications of certificate issuance to entities other than the ACT2 Subscribing Product.

4.5 Key Pair and Certificate Usage 4.5.1 Subscriber Private Key and Certificate Usage ACT2 Subscribing Products currently utilize a hardware chip for generation and storage of the public/private keypair for ACT2 SUDI certificates, which is FIPS 140-‐2 Level 3 certified as a secure hardware container for the keypair and certificate. Information stored in this chip is, by design, not replicable without using a FIPS 140-‐2 Level 3 certified backup and archival protocol.

4.5.2 Relying Party Public Key and Certificate Usage

4.5.2.1 Reliance on, and Usage of, Issued Certificates Issued ACT2 SUDI certificates may be used and relied upon for authentication of the ACT2 Subscribing Product possessing them, and for encryption and/or digital signature of information transmitted to or from the ACT2 Subscribing Product.

4.5.2.2 Verification of the Public Key of the CA Relying Parties may validate the public key of the CA by downloading a copy from the public repository maintained by Cisco Systems Information Security group and comparing it to the key used to sign ACT2 SUDI certificates. ACT2 SUDI certificates may be validated using the mechanisms defined in IETF X.509 digital certificate standards such as RFC 5280 and RFC 3280.



4.6 Certificate Renewal The ACT2 SubCAs do not support certificate renewal.

4.7 Certificate Re-‐Key The ACT2 SubCAs do not support certificate re-‐key requests.

4.8 Certificate Modification The ACT2 SubCAs do not support the modification of existing ACT2 SUDI certificates. If a certificate must be modified, it shall be re-‐issued instead with new values.

4.9 Certificate Revocation and Suspension 4.9.1 Circumstances for Revocation The ACT2 SubCAs shall revoke a certificate:

• Upon request of the subscriber; • Upon failure of the subscriber to meet its material obligations under this Certificate Policy, any applicable

CPS, or any other agreement, regulation, or law applicable to the certificate that may be in force; • If knowledge or reasonable suspicion of compromise is obtained; • If the CA determines that the certificate was not properly issued in accordance with this Policy and/or any

applicable CPS.

In the event that the ACT2 SubCAs cease operations, all certificates issued by the ACT2 SubCAs shall be revoked prior to the date that the CA ceases operations. The ACT2 SubCAs shall provide subscribers adequate notice to provide them the opportunity to address any business impacting issues.

4.9.1.1 Permissive Revocation A subscriber may request revocation of its certificate at any time for any reason. The ACT2 SubCAs may also revoke a certificate upon failure of the subscriber to meet its obligations under this Certificate Policy, the applicable CPS, or any other agreement, regulation, or law applicable to the certificate that may be in force.

4.9.1.2 Required Revocation A subscriber shall promptly request revocation of a certificate whenever any of the information on the certificate changes or becomes obsolete, or whenever the private key associated with the certificate, or the media holding the private key associated with the certificate is compromised or is suspected of having been compromised.

4.9.2 Who Can Request Revocation Only the subscriber and the ACT2 SubCAs are permitted to request revocation of a certificate issued pursuant to this Policy.

4.9.3 Identification and Authentication for Revocation Request The ACT2 SubCAs shall authenticate a request for revocation using the same controls used to identify and authenticate the original certificate request. Should automated request, submission, and validation of the subscriber information not be available for any reason, manual validation of that information shall be performed by a member of the Issuing CA administrative team operating in a Trusted Role, per section 5.2.1.


Facility, Management, and Operational Controls � 15

4.9.4 Procedure for Revocation Request A certificate revocation request should be promptly communicated to the ACT2 SubCAs directly. A certificate revocation request may be communicated electronically if it is digitally signed with the private key corresponding to the certificate to be revoked. Alternatively, the subscriber may request revocation by contacting the ACT2 SubCAs' administrative team in person and providing adequate proof of identification in accordance with this Policy.

4.9.5 Revocation Request Grace Period Manual requests for revocation shall be processed within one month of the request.

4.9.6 Time within which CA Must Process the Revocation Request Following revocation, the ACT2 SubCA Certificate Revocation List shall be updated in accordance with the provisions of this document within two hours of the revocation being successfully completed. All revocation requests and the resulting actions taken by the ACT2 SubCAs shall be archived for a period of at least seven years past the final termination of the ACT2 SubCAs' functionality.

4.9.7 Revocation Checking Requirement for Relying Parties The ACT2 SubCAs do not require revocation checking by relying parties.

4.9.8 CRL Issuance Frequency The ACT2 SubCAs issue Certificate Revocation Lists annually, whether or not new additions have been made. Upon a new revocation, a new CRL will be issued and published within two hours. The ACT2 SubCAs administrative team ensures that superseded CRLs are removed from the CRL Distribution Point location upon posting of the latest CRL.

4.9.9 Maximum Latency for CRLs and Online Status Checking Mechanisms No stipulation.

4.9.10 Certificate Status Services No stipulation.

5 Facility, Management, and Operational Controls 5.1 Physical Controls 5.1.1 Site Location and Construction The ACT2 SubCA infrastructure, including all hosts and cryptographic devices directly involved in the ACT2 SUDI certificate issuance system, are housed in two redundant secure storage facilities (SSFs) owned by Cisco Systems and operated by the Cisco Systems Information Security group. The SSFs restrict physical access at all times to only the administrative team designated to act in a Trusted Role for the ACT2 SubCAs and specifically designated other administrative personnel.

5.1.2 Physical Access The Secure Storage Facility (SSF) housing the ACT2 SubCA infrastructure uses a combination of physical access barriers and authentication/authorization token controls to restrict access only to members of the administrative team designated to act in a Trusted Role for the ACT2 SubCAs and specifically designated other administrative personnel. The ACT2 SubCAs administrative team retains sole control over the authentication controls protecting the SSF, and are solely responsible for granting or revoking access to that area. Access lists



for the SSF are reviewed by the ACT2 SubCA administrative team on at least an annual basis to ensure no unauthorized additions have been made to the access lists.

Access to the SSF is controlled by a dual-‐factor badge reader that requires both possession of a physical proximity badge and the fingerprint registered on that badge for entry. All physical access to the SSF is logged and recorded by Cisco Systems Safety and Security group, which keeps a log of each time the physical door is opened into the room.

5.1.3 Power and Air Conditioning In addition to the redundancy provided by maintaining two online, functional SSFs for the ACT2 SUDI CA service, the ACT2 SUDI CA service uses a global service selector that automatically funnels traffic to online servers and disregards those offline, so that power or cooling failures that result in an SSF going offline or becoming degraded will naturally result in the site being taken offline in favor of the other site.

In addition, the SSFs are supplied with redundant power and cooling through the data center facilities in the building, at sufficient levels to provide for a graceful transition of services to the other data center in the event of maintenance or accidental shutdown.

5.1.4 Water Exposures The Secure Storage Facilities housing the ACT2 SubCA infrastructure are supplied with leak detection and flood prevention mechanisms that include flood cording around significant appliances and leak detection mechanisms beneath the raised floors to detect any leakage from water systems. The fire suppression system in the building is a "dry-‐pipe" system that maintains no standing water; this is checked and verified at least annually by the data center maintenance team.

5.1.5 Fire Prevention and Protection The data center facilities housing the SSFs maintain thorough fire and smoke detection systems sufficient to conform to local, state, and federal fire detection ordinances. Fire and smoke detection measures are tested by the data center maintenance team on at least an annual basis, and are maintained according to the manufacturer's guidelines.

5.1.6 Media Storage Sensitive information involved in the operation and administration of the ACT2 SubCAs are stored on physical media that offers basic resistance to water, electrical, and magnetic damage. In addition, duplicate copies of all sensitive archival and operational data are maintained in two physical, secure, and proximally separate locations.

5.1.7 Waste Disposal Sensitive documentation generated as a part of the operational functions of the ACT2 SubCAs is shredded using an industrial micro-‐perforation shredder once the documents are no longer needed. Hardware security modules that are no longer in operation are zeroed according to the manufacturer's FIPS 140-‐2 Level 3 zeroization procedures. Storage media that contained sensitive information at any point are retained in secure storage until they can be safely disposed of using multi-‐pass erasure systems or commercial degaussing.



5.1.8 Off-‐Site Backup The ACT2 SubCA administrative team maintains backups of key material and CA issuance software sufficient to create a new, fully functional ACT2 SubCA issuance system. These backups are stored in the SSF and material storage safe at each of the two primary operations sites for the ACT2 SubCAs.

5.2 Procedural Controls 5.2.1 Trusted Roles All employees, contractors, and consultants of the ACT2 SubCAs (collectively "personnel") that have access to or control over cryptographic operations that may materially affect the CA's issuance, use, suspension, or revocation of certificates, including access to restricted operations of the CA's repository, shall, for purposes of this Policy, be considered as serving in a trusted role. Such personnel include, but are not limited to, system administration personnel, operators, engineering personnel, and executives who are designated to oversee the CA's operations.

5.2.2 Number of Persons Required per Task In order to ensure that one person acting alone may not circumvent CA safeguards, the ACT2 SubCAs store all key materials in hardware security modules (HSMs) that do not permit export of the key material in an unwrapped, accessible state. Activation materials for the HSMs are stored in physical safes that are kept under guard at all times, and that require two different combinations in order to open-‐-‐the ACT2 SubCA administrative team ensures that no single administrator knows both combinations to open the safe. Keys for the ACT2 SubCAs were generated using a witnessed, scripted key generation ceremony that required at least two administrators present.

Audits of the CA function and of specific sensitive activities are performed by designated members of the ACT2 SubCA administrative team that act specifically in an audit role, to provide for oversight of activity and prevent any administrator from auditing his own work.

5.2.3 Identification and Authentication for Each Role All ACT2 SubCA administrative personnel are given thorough background checks and identity verification checks prior to being hired by Cisco Systems, and are thoroughly trained prior to being added to the physical and logical access lists for the ACT2 SubCAs. Actions on the ACT2 SubCAs, whether physical or logical, are logged using individual authentication and attribution, are limited to a specific individual, and are limited in their authorization on the system using all available logical and physical controls. Access to the ACT2 SubCA systems over remote connections is performed exclusively over secured HTTP (HTTPS) and Secure Shell (SSH), both of which provide an encrypted channel for communications.

5.2.4 Roles Requiring Separation of Duties Where procedures require separation of duties, the ACT2 SubCAs enforce separation of duties through technological controls, procedures, or both. Specifically, the ACT2 SubCAs ensure that individual CA personnel may not operate in the capacity of an operator/developer and an auditor simultaneously, using controls such as multiple-‐key access controls and witnessed scripts. ACT2 SUDI CA personnel may occupy more than one role separately depending on the context (an operator may later act as an auditor in another operation, e.g.).



5.3 Personnel Controls 5.3.1 Background and Qualifications CAs, RAs, and VSPs shall formulate and follow personnel and management policies sufficient to provide reasonable assurance of the trustworthiness and competence of their employees and of the satisfactory performance of their duties in manner consistent with this Policy.

Cisco Systems maintains strict background checks on all employees hired into Trusted Roles, and conducts annual performance reviews to ensure personnel continue to meet performance standards in a manner consistent with the dictates of this CPS.

5.3.2 Background Investigation As a Certification Authority, Cisco's goal is to provide a trustworthy infrastructure to ensure the reliability of Digital Certificates.

In furtherance of this goal, Cisco only hires "Operative Personnel" who are trustworthy. Operative Personnel are Cisco employees who operate the systems used to issue certificates, create the ACT2 Sub CAs’ private keys, and administer the ACT2 Sub CA’s computing facilities. Cisco takes special steps to assure that these persons are qualified to act as Operative Personnel. Cisco performs background checks on all of its Operative Personnel responsible for the ACT2 Sub CAs. The ACT2 Sub CAs’ Operative Personnel must also have sufficient knowledge of Public Key Infrastructures, asymmetric cryptosystems, and the laws applicable to Certification Authorities.

5.3.3 Training Requirements All ACT2 SubCA administrative personnel possess sufficient knowledge of Public Key Infrastructures, asymmetric cryptosystems, and the laws applicable to Certification Authorities; this knowledge is tested annually along with periodic training on updated information.

5.3.4 Documentation Supplied to Personnel The ACT2 SubCA administrative team maintains an online set of operational documentation that details the procedures for standard administrative processes and actions on the ACT2 SubCAs.

5.4 Audit Logging Procedures 5.4.1 Types of Events Recorded The ACT2 SubCAs automatically generate audit log files for all certificate processing, issuance, and revocation events on the CA, as well as for logical access, super-‐user access, and security-‐related events such as failed/successful logons and system reboots. Physical records are also maintained of access to the SSFs and the key material safes, along with checkin/checkout records for key materials in the safes.

5.4.2 Frequency of Processing Log Where possible, security event logs are generated automatically by the ACT2 SubCAs at the time of the event. Where this is not possible, such as for physical access to key material, a manual log is kept and verified at time of creation by at least two members of the ACT2 SubCA administrative team.

5.4.3 Retention Period for Audit Log All security audit logs for the ACT2 SubCAs shall be retained for a period of seven years past the dissolution of the CA and shall be made available during compliance audits.


Technical Security Controls � 19

5.4.4 Protection of Audit Log Electronic security event audit logs generated on the ACT2 SubCA hosts are protected from tampering by copying them automatically at the time of log generation to a separate, protected log archival system that does not permit deletion or alteration of the records. Physical security audit logs are created using ink and are inspected at least annually to reconcile access logs with one another, which helps detect tampering with the records.

5.4.5 Audit Log Backup Procedures Backups of electronic security audit logs are made by using the on-‐write log archival server, which maintains a copy of the log information indefinitely. Backups are not made of physical security event logs.

5.4.6 Vulnerability Assessments No provision.

5.5 CA or RA Termination In the event that the ACT2 SubCAs cease operation, the Subscribers, RAs, VSPs, and Benefiting Parties will be promptly notified of the termination at the time of termination, and (where possible) at least two weeks prior to termination. In addition, all CAs with which cross-‐certification agreements are current at the time of cessation will be promptly informed of the termination. All certificates issued by the ACT2 SubCAs that reference this Policy will be revoked no later than the time of termination.

6 Technical Security Controls 6.1 Key Pair Generation and Installation 6.1.1 Key Pair Generation Cryptographic key material used for the ACT2 SUDI Sub CAs is generated inside a FIPS140-‐2 Level 3 hardware security module (HSM), stored in a Secure Storage Facility (SSF) inside a Cisco datacenter. Keypair generation occurs as part of a scripted, witnessed key generation ceremony videotaped for assurance purposes conducted by employees of Cisco Systems, Inc. operating in Trusted Roles. The scripts and video materials generated during these key generation ceremonies are available for review by auditors as a part of regular audit and certification activities.

SUDI certificate key material is generated by Cisco's ACT2 Back-‐End (CBE) infrastructure on behalf of a device requesting a SUDI certificate. SUDI keypair generation occurs inside a FIPS140-‐2 Level 3 hardware security module (HSM), housed in a Secure Storage Facility (SSF) inside a Cisco datacenter.

6.1.2 Private Key Delivery to Subscriber During the manufacture of an ACT2 chip, the chip generates a unique 256-‐bit AES key using its own secure microprocessor. This key and the serial number of the chip are then encrypted with the public key of the Cisco ACT2 Back End service (CBE), and transmitted over a secure hardware channel to a test server connected to the chip. The test server aggregates these secure data packages (known as "Chip-‐Specific Keying Material Packages" or CSKMPs) into a block associated with the manufactured lot of chips. Each lot's worth of CSKMPs is then transmitted to the CBE from the chip manufacturing vendor.

Upon receipt of a block of CSKMPs, the CBE opens the block and parses each CSKMP. The unique AES key from the CSKMP is unwrapped inside a FIPS140-‐2 Level 3 HSM. The CBE then automatically generates the SUDI



keypair, along with any other necessary ACT2 keypairs on behalf of the ACT2 chip, as specified in section 4.1.1 above, which includes a unique chip-‐level keypair known as the ACT2 chip keypair. Once generated, SUDI keypairs are stored along with the rest of the ACT2 identity package in a data blob known as a Chip-‐Level Identity Insertion Package (CLIIP). Each CLIIP is then encrypted using the unique AES-‐256 key associated with its ACT2 chip, and then stored in a secure database record associated with the serial number of the ACT2 chip supplied with the CSKMP.

During manufacture of the ACT2-‐enabled device, the ACT2 chip sends an authenticated request along a mutually authenticated SSL/TLS session to the CBE, requested its CLIIP. The CBE transmits the CLIIP along the SSL/TLS session, and the chip decrypts the package inside its secure microprocessor and installs the SUDI keypair in secure memory.

Further specifics about the ACT2 chip system are available on a need-‐to-‐know basis in Cisco's EDCS866559 document, “ACT2 List System Functional Specification.”

6.1.3 Public Key Delivery to Certificate Issuer Once the ACT2 chip has installed its SUDI keypair, it transmits a SUDI certificate request to the ACT2 Cisco Back-‐End Infrastructure (CBE), containing the ACT2 chip serial number and the ACT2-‐enabled device serial number and product identification number (PID). The request is signed by the ACT2 chip's private key, and is transmitted along a mutually authenticated SSL/TLS session to the CBE. The CBE then looks up the ACT2 chip serial number from the request, extracts the ACT2 public key from a database record associated with that serial number, and validates that the request is genuine and that the chip is in possession of the relevant private key. The validation of this key possession shall be deemed sufficient identity verification and evidence that the device in question is authorized to request an ACT2 SUDI certificate per the requirements of the CP for "Cisco Systems Subscriber Identification and Authentication (I&A)" (q.v.) and "ACT2 SUDI Certificate Identification and Authentication (I&A)" (q.v.).

6.1.4 CA Public Key Delivery to Relying Parties The public key of the CA signing key pair is inserted into the ACT2 chip during the initial manufacture of the chip, creating a trusted root store inside the chip to be used for secure communications with Cisco. The public key of the ACT2 SubCAs is made available to relying parties through the Cisco Systems Information Security group's online repository of CA keys and data (http://www.cisco.com/security/pki/policies/index.html).

6.1.5 Key Sizes The ACT2 SUDI CA utilizes a 2048-‐bit RSA key pair; The ACT2 ECC SUDI CA utilizes a secp384r1 ECC key pair. The ACT2 SubCA certificate processing software has controls and checks in place that will prevent the issuance of a certificate for a keypair that is not either a 2048-‐bit RSA keypair, a secp384r1 ECC keypair, a prime256v1 ECC keypair, or a secp521r1 ECC keypair.

6.1.6 Public Key Parameters Generation and Quality Checking The ACT2 SubCA key generation software is written with controls in place to ensure generated keys meet the cryptographic standards for their relevant algorithms. For RSA keypairs, this means that keys generated must have a modulus of 65537 and use properly random values for p and q; for ECC keypairs, this means that keys generated utilize the prime256v1, secp384r1, or secp521r1 curve and use properly generated random numbers for inputs.



6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field) ACT2 SUDI certificates issued from the ACT2 SubCA systems have their X.509 Key Usage field set to permit the following usages: "Digital Signature", "Non Repudiation", "Key Encipherment".

6.2 Private Key Protection and Cryptographic Module Engineering Controls The ACT2 Sub CAs protect their signing keys by generating and storing them at all times in a FIPS 140-‐2 Level 3 Hardware Security Module (HSM). All cryptographic operations by the certificate authority involving the private key of the signing keypair take place inside this HSM.

6.2.1 Cryptographic Module Standards and Controls The ACT2 Sub CAs protect their signing keys by generating and storing them at all times in a FIPS 140-‐2 Level 3 Hardware Security Module (HSM). All cryptographic operations by the certificate authority involving the private key of the signing keypair take place inside this HSM.

6.2.2 Private Key (N out of M) Multi-‐Person Control Multi-‐person control is a security mechanism that requires multiple authorizations for access to the CA Private Signing Key. All CA key material for the ACT2 CAs, when not online and in use, is kept in a locked safe under 24x7 surveillance; access to the safe requires two Cisco operators acting in Trusted Roles, each of which must supply part of the combination to open the safe. HSMs containing backups of the key materials, as well as the activation hardware for the key material, are also kept inside this safe with the same two-‐person control requirements.

6.2.3 Private Key Escrow The AES-‐256 chip-‐level keys are encrypted using the public key of the Cisco Back-‐End Infrastructure (CBE) for transmission. The generated keypairs for each CLIIP are encrypted to the individual AES-‐256 chip-‐level key. As such, they are protected for storage without requiring further encryption. The private key of the CBE keypair is stored in a FIPS 140-‐2 Level 3 hardware security module at all times for operation and is never exposed.

6.2.4 Private Key Backup, Archival, and Restoration The private keys for the ACT2 SUDI Sub CAs are only backed up and archived into another FIPS 140-‐2 Level 3 Hardware Security Module or FIPS140-‐2 Level 3 secure USB token. The keys are thus never exposed in plaintext anywhere outside the working memory of the hardware security module.

Hardware security modules and tokens containing backups of the ACT2 SUDI Sub CA key material are kept in a locked safe under 24x7 guard surveillance; one safe exists near the primary Cisco IAS data center while another with the same security controls is near the secondary Cisco IAS data center. Hardware security modules are shipped between the two data centers using a secure shipping method that uses tamper-‐evident/tamper-‐resistant shipping containers with two-‐person access control procedures; with the exception of HSM backup devices, all HSMs are shipped between sites without key material present.

6.2.5 Private Key Transfer into or from a Cryptographic Module The private keys for the ACT2 SUDI Sub CAs are only backed up and archived into another FIPS 140-‐2 Level 3 Hardware Security Module or FIPS140-‐2 Level 3 secure USB token. Should there be a need to transfer the keys from one token to another, the keys are transferred directly without "unwrapping" them from their NIST-‐approved key wrapping container.



6.2.6 Private Key Storage on Cryptographic Module Private keys for the ACT2 SubCAs are kept in a FIPS140-‐2 Level 3 certified Hardware Security Module (HSM) or a FIPS140-‐2 Level 3 secure USB token. While in use, the keys are stored only in secure memory inside the FIPS140-‐2 Level 3 certified HSM physically attached to each ACT2 SubCA processing server.

6.2.7 Method of Activating a Private Key The activation hardware for the ACT2 SUDI Sub CA private keys consists of a pair of cryptographic tokens. When not actively in use, the tokens are stored in a safe under 24x7 guard; access to the safe requires two Cisco operators acting in Trusted Roles, each of which must supply part of the combination to open the safe. The activation tokens are removed only for as long as required to activate the ACT2 SUDI Sub CA keypairs, and then are returned to the safe for storage. The activation tokens are inserted one at a time by a pair of Cisco operators acting in Trusted Roles, each of which must insert and activate one token, which is used by the hardware security module to initialize and activate the CA key material into the security module in accordance with FIPS 140-‐2 Level 3 standards and practices.

6.2.8 Method of Deactivating a Private Key Upon power loss or tamper detection, the hardware security module containing the ACT2 SUDI Sub CA key material will clear and zeroize all working memory containing key material, in accordance with FIPS 140-‐2 Level 3 standards and practices.

6.2.9 Method of Destroying a Private Key Upon expiration or revocation of the certificate for an ACT2 SUDI Sub CA, the private key for creating signatures shall be destroyed using the FIPS140-‐2 Level 3-‐approved method available through the hardware security module in which the keypair is stored.

6.2.10 Cryptographic Module Rating All hardware security modules (HSMs) used by the ACT2 SubCAs and ACT2 Subscribing Products conform to the FIPS 140-‐2 hardware standard at Level 3 or higher.

6.3 Other Aspects of Key Pair Management 6.3.1 Public Key Archival The public keys of the ACT2 SubCAs are archived in the regular backups of the Repository where the digital certificates are published.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods ACT2 SUDI certificates are issued with a fixed, ten-‐year operational period. No requirements are placed around the operational period for ACT2 SUDI keypairs.

6.4 Activation Data ACT2 SubCA issuing key pairs are wrapped using a NIST-‐approved key wrapping algorithm supplied by the vendor and certified for compliance with the FIPS140-‐2 Level 3 standard. Sensitive data transmitted between ACT2 SubCA hosts is encrypted using transport layer security (TLS) that employs RSA-‐2048 and AES-‐256 keys to protect information transmitted.

When not actively in use, the tokens containing the activation materials for the ACT2 SubCAs are stored in a safe under 24x7 guard; access to the safe requires two Cisco operators acting in Trusted Roles, each of which must



supply part of the combination to open the safe. The activation tokens are removed only for as long as required to activate the ACT2 SubCA keypairs, and then are returned to the safe for storage.

6.5 Computer Security Controls Each ACT2 Issuing CA server has been hardened according to the standard IAS Linux server configuration guide, which specifies the set of services to deactivate, patches to apply, and configuration changes to make in order to secure the system. ACT2 Issuing CA systems are patched by administrators at least monthly to the latest security patch levels, and are centrally monitored for signs of malicious activity.

6.6 Life-‐Cycle Technical Controls 6.6.1 System Development Controls Software written for the ACT2 SubCAs is developed by designated developers on the ACT2 SubCA administrative team. The ACT2 SubCA administrative team maintains a software change control system that tracks changes to all custom software for the ACT2 systems; this server requires individual authentication for submission of changes, and logs all submissions, ensuring that changes to the software are individually accountable.

New versions of the software must be submitted to the change control system, which then requires that a second developer review all new changes and approve or deny them. Denied changes are returned to the author for improvement; once a branch of the code has completed review successfully with no further issues, it is approved for testing and migration to production. Code tagged for production is rolled into an archive, tested by a developer separate from the primary author of the code, and then a change ticket is opened to request a window for installing the new code. If the ticket is approved, a designated ACT2 SubCA administrator will roll up the code and deploy it over an authenticated, encrypted channel using Secure Shell (SSH) to each of the ACT2 SubCA operational systems, which are then monitored for any issues with the new code. Once the rollout is complete, the ticket is marked complete and is closed.

Should an emergency software fix be required, an ACT2 SubCA developer may submit the change through an emergency submission process: the change is submitted to the production branch of the code, which then must have a deployment ticket opened and a deployment completed by an ACT2 SubCA administrator. In the case of an emergency code fix, review of the code change is not required prior to production rollout, but must be completed within one week of the production rollout by a second developer.

6.6.2 Security Management Controls Issuing CAs shall ensure that software elements considered in production are protected from unauthorized modification, and periodically verified to ensure their integrity.

6.6.3 Life-‐Cycle Security Controls The Issuing CA shall instantiate documented procedures for the lifecycle management of hardware and software components of the CA.

6.7 Network Security Controls The ACT2 Issuing CAs are situated behind multiple layers of firewalls that block access to the CA systems from outside Cisco's networks, and limit access to CA issuance services and remote management software to specific IP addresses. Application proxies are not used in the ACT2 Issuing CA ecosystem.


Certificate and CRL Profiles � 24

6.8 Timestamping ACT2 CA systems are synchronized automatically with Cisco's standard network time servers. This time value is used for timestamps on all relevant Issuing CA functions. NTP synchronizations and adjustments are logged automatically in the server system logs.

7 Certificate and CRL Profiles The ACT2 SubCAs issue certificates and certificate revocation lists that conform to the standards established in the ACT2 SUDI Certificate Policy.

8 Compliance Audit and Other Assessments The ACT2 SubCAs undergo routine compliance reviews as part of their system lifecycle management within the Cisco Systems Information Security group. In addition, the ACT2 SubCAs are reviewed by a third party, independent auditor for compliance with the AICPA WebTrust for Certificate Authorities guidelines on at least an annual basis.The ACT2 SubCAs employ a combination of technical and policy controls to ensure their continued compliance with this policy with regards to their certification, issuance, revocation, and certificate lifecycle security practices, as set forth in this Certification Practice Statement.

8.1 Assessment of Compliance The ACT2 SubCAs are reviewed on at least an annual basis by an independent auditor. This review, conducted against the AICPA WebTrust for Certificate Authorities guidelines, covers the ACT2 SubCAs' infrastructure, policies, and practices, to measure their compliance with these guidelines.

8.2 Qualifications of Auditor The ACT2 SubCAs employ a Qualified Auditor to perform all annual compliance audits, ensuring prior to engagement that the auditor conforms with the required qualification standards as laid out in Section 8.2 of the ACT2 Certificate Policy (q.v.).

8.3 Auditor's Relationship to Audited Entity The ACT2 SubCAs employ a Qualified Auditor employed by a company completely independent of Cisco Systems and its subsidiary companies.

8.4 Content of Audit Annual compliance audits of the ACT2 SubCAs are conducted against the guidelines contained in the AICPA/CICA WebTrust for Certification Authorities, v2.0.

8.5 Actions Taken as a Result of Deficiency Should the compliance audit identify material discrepancies between the ACT2 SubCAs' controls and the qualifying audit guidelines as established in section 8.4, the Cisco Systems Information Security group shall establish a corrective action plan and track it through planning, review, initiation, and completion.

8.6 Communication of Audit Results The results of each annual compliance audit are communicated to the ACT2 SubCAs' administrative team and to their management.


Other Business and Legal Matters � 25

9 Other Business and Legal Matters 9.1 Fees No stipulation.

9.2 Financial Responsibility The financial responsibility of managing and maintaining the certificate authority and relevant Issuing CAs shall be the sole responsibility of Cisco Systems, Inc.

9.3 Confidentiality of Business Information The ACT2 SubCAs maintain compliance with the data protection policies of Cisco Systems with regards to any business information they collect in the course of certificate issuance.

9.4 Privacy of Personal Information The ACT2 SubCAs do not collect Personally Identifiable Information of any kind for natural persons or organizations during the course of certificate issuance.

9.5 Intellectual Property Rights The intellectual property rights of the information collected and processed by the ACT2 SubCAs during their certificate issuance process is the sole property of Cisco Systems and its subsidiary companies, unless specifically stated otherwise in an agreement.

9.6 Representations and Warranties 9.6.1 CA Obligations The ACT2 SubCAs are responsible for all aspects of the issuance and management of their issued certificates, including control over the application/enrollment process, the identification and authentication process, the certificate manufacturing process, publication of the certificate (if required), suspension and/or revocation of the certificate, renewal of the certificate, validation services, and for ensuring that all aspects of the CA Services and CA operations and infrastructure related to certificates issued under this Certification Practice Statement are performed in accordance with the requirements and representations of the ACT2 SUDI Certificate Policy and of this Certification Practice Statement.

9.6.2 CA Representations By issuing a certificate that references the ACT2 SUDI Certificate Policy, the ACT2 SubCAs certify to Benefiting Parties who reasonably and in good faith rely on the information contained in the certificate during its operational period and in accordance with the ACT2 SUDI Certificate Policy, that:

• The CA has issued, and will manage, the certificate in accordance with the ACT2 SUDI Certificate Policy; • The CA has complied with the requirements of the ACT2 SUDI Certificate Policy and of this Certification

Practice Statement when authenticating the subscriber and issuing the certificate; • There are no misrepresentations of fact in the certificate known to the CA, and the CA has taken reasonable

steps to verify additional information in the certificate unless otherwise noted in this Certification Practice Statement;

• Information provided by the subscriber in the certificate application for inclusion in the certificate has been accurately transcribed to the certificate;

• The certificate meets all material requirements of this Policy and was processed according to this Certification Practice Statement.



9.6.3 Benefiting Party Warranties Unless an explicit contractual agreement exists between Cisco Systems and a Benefiting Party, Cisco Systems is not representing any warranty to a Benefiting Party that exercises reliance on certificates issued by the ACT2 Sub CAs. In such instances where an explicit and separate Certificate Warranty agreement exists between the Benefiting Party and Cisco Systems, Cisco Systems may warrant that:

• The ACT2 SubCAs have issued and managed the Certificate in accordance with the ACT2 SUDI Certificate Policy;

• The ACT2 SubCAs complied with the requirements of the ACT2 SUDI Certificate Policy and of this CPS when authenticating requests for subordinate CA certificates;

• There are no material misrepresentations of fact in the Certificate known to the ACT2 SubCAs, and the ACT2 SubCAs have taken steps as required under this Policy to verify the information contained in the Certificate;

• The ACT2 SubCAs have taken the steps required by the ACT2 SUDI Certificate Policy to ensure that the Certificate Holder's submitted information has been accurately transcribed to the Certificate;

• Information provided by the ACT2 SubCAs concerning the current validity of the Certificate is accurate and that validity has not been diminished by the ACT2 SubCAs’ failure to promptly revoke the Certificate in accordance with this Certificate Policy; and

• The issued Certificate meets all material requirements of the ACT2 SUDI Certificate Policy and of this CPS.

These warranties may be applied to any Benefiting Party who: (i) enters into a separately executed warranty agreement with Cisco Systems; (ii) relies on the issued Certificate in an electronic transaction in which the issued Certificate played a material role in verifying the identity of one or more persons or devices; (iii) exercises Reasonable Reliance on that Certificate; and (iv) follows all procedures required by this Policy and by the applicable Benefiting Party Agreement for verifying the status of the issued Certificate. These warranties are made to the Benefiting Party as of the time the CA's certificate validation mechanism is utilized to determine Certificate validity, and only if the Certificate relied upon is valid and not revoked at that time.

9.6.4 Warranty Limitations The warranties offered to both Certificate Holders and Benefiting Parties will be subject to the limitations set forth in this Policy. Cisco Systems may provide further limitations and exclusions on these warranties as deemed appropriate, relating to: (i) failure to comply with the provisions of the ACT2 SUDI Certificate Policy or of any agreement with the ACT2 SubCAs; (ii) other actions giving rise to any loss; (iii) events beyond the reasonable control of the CA; and (iv) time limitations for the filing of claims. However, such limitations and exclusions may not, in any event, be less than those provided for in Section 9.6.4.

9.6.4.1 Time between Certificate Request and Issuance There is no stipulation for the period between the receipt of an application for a Certificate and the issuance of a Certificate, but the ACT2 SubCAs will make reasonable efforts to ensure prompt issuance.

9.6.4.2 Certificate Revocation and Renewal The ACT2 SubCAs ensure that any procedures for the expiration, revocation and renewal of an issued Certificate conform to the relevant provisions of the ACT2 SUDI Certificate Policy and will be expressly stated in a Certificate Agreement and any other applicable document outlining the terms and conditions of certificate use, including ensuring that: (i) Key Changeover Procedures are in accordance with this Policy; (ii) notice of revocation of a Certificate will be posted to an online certificate status database and/or a certificate revocation



list (CRL), as applicable, within the time limits stated in this Policy; and (iii) the address of the online certificate status database and/or CRL is defined in the issued certificate.

9.6.5 End Entity Agreements The ACT2 SubCAs may enter into agreements with End Entities governing the provision of Certificate and Repository services and delineating the parties’ respective rights and obligations.

The ACT2 SubCAs will ensure that any Certificate Agreements incorporate by reference the provisions of this Policy regarding the ACT2 SubCAs’ and the Certificate Holder's rights and obligations. In the alternative, the ACT2 SubCAs may ensure that any Certificate Agreements, by their terms, provide the respective rights and obligations of the ACT2 SubCAs and the Certificate Holders as set forth in this Policy, including without limitation the parties’ rights and responsibilities concerning the following:

• Procedures, rights and responsibilities governing (i) application for an issued Certificate, (ii) the enrollment process, (iii) Certificate issuance, and (iv) Certificate Acceptance;

• The Certificate Holder’s duties to provide accurate information during the application process; • The Certificate Holder's duties with respect to generating and protecting its Keys; • Procedures, rights and responsibilities with respect to Identification and Authentication (I&A); • Any restrictions on the use of issued Certificates and the corresponding Keys; • Procedures, rights and responsibilities governing (a) notification of changes in Certificate information, and (b)

revocation of issued Certificates; • Procedures, rights and responsibilities governing renewal of issued Certificates; • Any obligation of the Certificate Holder to indemnify any other Participant; • Provisions regarding fees; • The rights and responsibilities of any RA that is party to the agreement; • Any warranties made by the ACT2 SubCAs and any limitations on warranties or liability of the ACT2 SubCAs

and/or an RA; • Provisions regarding the protection of privacy and confidential information; and • Provisions regarding Alternative Dispute Resolution.

Nothing in any Certificate Agreement may waive or otherwise lessen the obligations of the Certificate Holder as provided in section 9.6.8 of this Policy.

The ACT2 SubCAs will ensure that any Benefiting Party Agreement incorporates by reference the provisions of the ACT2 SUDI Certificate Policy regarding the ACT2 SubCAs’ and the Benefiting Party’s rights and obligations. Nothing in a Benefiting Party Agreement may waive or otherwise lessen the obligations of the Benefiting Party as provided in the ACT2 SUDI Certificate Policy.

9.6.5.1 Ensuring Compliance The ACT2 SubCAs employ technical and procedural controls to ensure that: (i) they only accept information from entities that understand and are obligated to comply with the ACT2 SUDI Certificate Policy; (ii) they comply with the provisions of the ACT2 SUDI Certificate Policy in their certification and Repository services, issuance and revocation of Certificates and issuance of CRLs; (iii) they make reasonable efforts to ensure adherence to the ACT2 SUDI Certificate Policy with regard to any Certificates issued under it; and (iv) any identification and authentication procedures are implemented as set forth in Section 3.

9.6.6 Registration Authority (RA) Obligations No stipulation, as no Registration Authorities are authorized under this Certification Practice Statement.



9.6.7 Certificate Status Validation Obligations In addition to the publication of a Certificate Revocation List as specified in section 2.2, the ACT2 SubCAs support the verification of certificate status through manual verification: relying parties in need of verification of current validity may contact the ACT2 SubCAs’ administrative team via the contact information in section 1.5.2.

9.6.8 Subscriber Obligations In all cases, the subscriber is obligated to:

• Generate a key pair using a trustworthy system, and take reasonable precautions to prevent any loss, disclosure, or unauthorized use of the private key;

• Warrant that all information and representations made by the subscriber that are included in the certificate are true;

• Use the certificate exclusively for authorized and legal purposes, consistent with this Policy; • Instruct the CA to revoke the certificate promptly upon any actual or suspected loss, disclosure, or other

compromise of the subscriber’s private key.

A Subscriber who is found to have acted in a manner counter to these obligations will have its certificate revoked, and will forfeit all claims it may have against the ACT2 SubCAs.

9.6.9 Benefiting Party Obligations A Benefiting Party has a right to rely on a certificate that references this Policy only if the certificate was used and relied upon for lawful purposes and under circumstances where:

• The Benefiting Party entered into a Benefiting Party Agreement which incorporates by reference the provisions of this Policy regarding the ACT2 SubCAs’ and the Benefiting Party’s rights and obligations;

• The reliance was reasonable and in good faith in light of all the circumstances known to the benefiting party at the time of reliance;

• The purpose for which the certificate was used was appropriate under this Policy; • The benefiting party checked the status of the certificate prior to reliance.

A Benefiting Party found to have acted in a manner counter to these obligations would forfeit all claims he, she or it may have against the ACT2 SubCAs.

9.7 Liability The ACT2 SubCAs assume limited liability only to Benefiting Parties who have entered into a Benefiting Party Agreement. The ACT2 SubCAs may be responsible for direct damages suffered by benefiting parties who have executed a Benefiting Party Agreement that are caused by the failure of the ACT2 SubCAs to comply with the terms of the ACT2 SUDI Certificate Policy (except when waived by contract), and sustained by such benefiting parties as a result of reliance on a certificate in accordance with this Certification Practice Statement. The liability of the ACT2 SubCAs is limited to these conditions and to conditions set forth in the terms of specific Benefiting Party Agreements.

Except as expressly provided in the ACT2 SUDI Certificate Policy and this Certification Practice Statement, the ACT2 SubCAs disclaim all other warranties and obligations of any type, including any warranty of merchantability, any warranty of fitness for a particular purpose, and any warranty of accuracy of information provided.

The liability of the ACT2 SubCAs under this Policy to Benefiting Parties who have executed a Benefiting Party agreement shall be limited to direct damages, and shall not exceed $1000.00, except when waived by contract. The ACT2 SubCAs shall have no liability for consequential damages. Under no circumstances will the ACT2



SubCAs be responsible for direct or consequential damages to benefiting parties who have not entered into a Benefiting Party Agreement with Cisco Systems, Inc.

9.8 Interpretation & Enforcement Each provision of this Policy has been subject to mutual consultation, negotiation, and agreement, and shall not be construed for or against any party.

9.8.1 Governing Law This Certification Practice Statement shall be construed, and any legal relations between the parties hereto shall be determined, in accordance with the laws of the United States and the State of California, without regard to any conflict of law provisions thereof.

9.8.2 Dispute Resolution Procedures Disputes among Cisco Systems and a Benefiting Party will be resolved pursuant to provisions in the applicable Certificate Trust Agreements between Cisco and the Benefiting Party. Disputes between entities who are not Benefiting Parties and Cisco Systems carry no stipulation.

9.8.3 Severability If any portion or term of this Policy is held unenforceable by a court of competent jurisdiction, the remainder of this Certification Practice Statement shall not be affected and shall remain fully in force and enforceable.

9.8.4 Survival No stipulation unless parties have entered into a Benefiting Party Agreement with Cisco Systems.

9.8.5 Merger/Integration No stipulation unless parties have entered into a Benefiting Party Agreement with Cisco Systems.

9.8.6 Notice All notices and other communications hereunder shall be in writing and shall be deemed given (a) on the same day if delivered personally, (b) three business days after being mailed by registered or certified mail (return receipt requested), or (c) on the same day if sent by telecopy, confirmed by telephone, to each of the contacts listed in section 1.5.2 above.

9.9 Amendments 9.9.1 Procedure for Amendment This document shall be amended in accordance with practices detailed in section 1.5.3.

9.9.2 Notification Mechanism and Period Changes to this document will be in the form of an updated document file with changes reflected in the version section. The updated version of the document will be linked to from the main Cisco PKI Policies page located at http://www.cisco.com/security/pki/policies/index.html.

9.9.3 Circumstances Under Which OID Must Be Changed Should the policy document be updated with changes considered “major changes” per section 1.5.3.3, the OID for the policy must be changed as well. Other changes or revisions to documentation do not require an OID change.


References � 30

10 References 10.1 Normative References This document attempts to address control elements enumerated in RFC 3647, RFC 2527, and the WebTrust for Certification Authorities versions 1 and 2.

10.2 Informative References Controls detailed in this document were informed by perusal of publicly available PKI policies and standards. Any similarity to other documents is entirely unintentional.


Appendix A -‐ Definitions and Acronyms � 31

Appendix A -‐ Definitions and Acronyms Affiliated Individual -‐ An affiliated individual is the subject of a certificate that is affiliated with a sponsor approved by the CA (such as an employee affiliated with an employer). Certificates issued to affiliated individuals are intended to be associated with the sponsor and the responsibility for authentication lies with the sponsor.

Authorized CA -‐ A certification authority that has been authorized by the Certificate Policy Management Authority to issue certificates that reference this policy.

Benefiting Party -‐ A recipient of a digitally signed message who relies on a certificate to verify the integrity of a digital signature on the message (through the use of the public key contained in the certificate), and the identity of the individual that created said digital signature.

CA -‐ Certification Authority

Certificate -‐ A record that, at a minimum: (a) identifies the certification authority issuing it; (b) names or otherwise identifies its subscriber; (c) contains a public key that corresponds to a private key under the sole control of the subscriber; (d) identifies its operational period; and (e) contains a certificate serial number and is digitally signed by the certification authority issuing it. As used in this Policy, the term of "Certificate" refers to certificates that expressly reference this Policy in the "Certificate Policies" field of an X.509 v.3 certificate.

Certificate Revocation List (CRL) -‐ A time-‐stamped list of revoked certificates that has been digitally signed by a certification authority.

Certification Authority -‐ A certification authority is an entity that is responsible for authorizing and causing the issuance of a certificate. A certification authority can perform the functions of a registration authority (RA) and a certificate manufacturing authority (CMA), or it can delegate either of these functions to separate entities.

A certification authority performs two essential functions. First, it is responsible for identifying and authenticating the intended subscriber to be named in a certificate, and verifying that such subscriber possesses the private key that corresponds to the public key that will be listed in the certificate. Second, the certification authority actually creates (or manufactures) and digitally signs the certificate. The certificate issued by the certification authority then represents that certification authority's statement as to the identity of the device named in the certificate and the binding of that device to a particular public-‐private key pair.

Certification Practice Statement (CPS) -‐ A "certification practice statement" is a statement of the practices that a certification authority employs in issuing, suspending, and revoking certificates and providing access to same. It is recognized that some certification practice details constitute business sensitive information that may not be publicly available, but which provided to certificate management authorities under non-‐disclosure agreement.

CPS -‐ See Certification Practice Statement.

CRL -‐ See Certificate Revocation List.

FIPS (Federal Information Processing Standards) -‐ These are Federal standards that prescribe specific performance requirements, practices, formats, communications protocols, etc. for hardware, software, data,



telecommunications operation, etc. Federal agencies are expected to apply these standards as specified unless a waiver has been granted in accordance with FIPS waiver procedures.

IETF (Internet Engineering Task Force) -‐ The Internet Engineering Task Force is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of Internet architecture and the efficient and robust operation of the Internet.

Key Pair -‐ Two mathematically related keys, having the properties that (a) one key can be used to encrypt a message that can only be decrypted using the other key, and (b) even knowing one key, it is computationally infeasible to discover the other key.

Object Identifier -‐ An object identifier is a specially formatted number that is registered with an internationally recognized standards organization.

OID -‐ See Object Identifier.

Operational Period of a Certificate -‐ The operational period of a certificate is the period of its validity. It would typically begin on the date the certificate is issued (or such later date as specified in the certificate), and end on the date and time it expires (as noted in the certificate) unless previously revoked or suspended.

PIN -‐ Personal Identification Number

PKI -‐ Public Key Infrastructure

PKIX -‐ An IETF Working Group developing technical specifications for a PKI components based on X.509 Version 3 certificates.

Policy -‐ This Certificate Policy document.

Policy Administering Organization -‐ The entity specified in section 1.5.1.

Private Key -‐ The key of a key pair used to create a digital signature. This key must be kept secret, and under the sole control of the individual or entity whose identity is associated with that digital signature.

Public Key -‐ The key of a key pair used to verify a digital signature. The public key is made freely available to anyone who will receive digitally signed messages from the holder of the key pair. The public key is usually provided via delivery of a certificate issued by a certification authority and might also be obtained by accessing a repository. A public key is used to verify the digital signature of a message purportedly sent by the holder of the corresponding private key.

RA -‐ See Registration Authority.

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

Repository -‐ A trustworthy system for storing validity and other information relating to certificates.

Responsible Individual -‐ A person designated by a sponsor to authenticate individual applicants seeking certificates on the basis of their affiliation with the sponsor.

Revocation (Revoke) -‐ To prematurely end the operational period of a certificate from a specified time forward.



Sponsor -‐ An organization with which a subscriber is affiliated (e.g., as an employee, user of a service, business partner, customer, etc.).

Subject -‐ A person or device whose public key is certified in a certificate. Also referred to as a "subscriber".

Subscriber -‐ A subscriber is an entity who: (a) is the subject named or identified in a certificate issued to such person or device; (b) holds a private key that corresponds to a public key listed in that certificate; and (c) the entity to whom digitally signed messages verified by reference to such certificates are to be attributed. See "subject."

Suspension (suspend) – To temporarily halt the operational validity of a certificate for a specified time period or from a specified time forward.

Trustworthy System -‐ Computer hardware, software, and procedures that: (a) are reasonably secure from intrusion and misuse; (b) provide a reasonable level of availability, reliability, and correct operation; (c) are reasonably suited to performing their intended functions; and (d) adhere to generally accepted security procedures.

Valid Certificate / Validity – A certificate is only valid when (a) a certification authority has signed/issued it; (b) the subscriber listed in it has accepted it; (c) it has not yet expired; and (d) has not been revoked.

Validation Services Provider (VSP) -‐ An entity that maintains a repository accessible to the public (or at least to benefiting parties) for purposes of obtaining copies of certificates or an entity that provides an alternative method for verifying the status of such certificates.

VSP -‐ See Validation Services Provider.

ACT2%SUDI%CACertification PracticeStatement · act2!sudi!cacertificationpractice!statement!...

Documents

Transcript of ACT2%SUDI%CACertification PracticeStatement · act2!sudi!cacertificationpractice!statement!...