1. PKE PP Mike Henry
Jean Petty
Entrust CygnaCom
Santosh Chokhani

2. Briefing Contents Common Criteria Background Goals of PKE PP
Assumptions
Approach in Constructing the PP
Summary of Packages
Planned Enhancements

3. Common Criteria: Sponsors
Common to Various Nations: Only charter members shown

4. Common Criteria: Key Concepts
Protection Profile (PP)
Specification of Security Requirements at what level
Implementation and product neutral
Security Target (ST)
Specification of Security Features at what and how level
Implementation and product specific
Target of Evaluation (TOE)
Products
Evaluated against ST

5. Common Criteria Standard: Specification
Part 1
Introduction
PP and ST Contents and Formats
Part 2: Security Functional Requirements
Select from these for PP and/or ST
Can extend the requirements
Part 3: Security Assurance Requirements
Select from these for PP and/or ST
Can extend the requirements

6. Common Criteria Standards: Other Documents
Common Evaluation Methodology (CEM)
PP Evaluation Standard
ST Evaluation Standard
TOE Evaluation Standard
Guide to Writing PP and ST

7. Common Criteria: Part 2 & Part 3 Hierarchy
Part 2 or 3 …… ….
Class
……....
Family
Component
……....
……....
Element

8. Common Criteria: Part 2 (functional) Classes
Audit
Crypto
User
Data Protection
TSF
Protection
I&A
Security
Management
Privacy
TOE
Access
Trusted
Path
Resource
Utilization

9. Common Criteria: Part 3 (assurance) Classes
Delivery &
Operation
Configuration
Management
Development
Guidance
Documents
Vulnerability
Assessments
Life-Cycle
Support
Tests
Note: CC also packages assurance requirements in 7 hierarchical
packages called Evaluation Assurance Levels (EAL)

10. Common Criteria: PP Contents
Introduction
TOE Description
Assumptions
Threats
Organizational Security Policies
Security Environment
drives
Security objectives for TOE
Security objectives for environment
Security Objectives
drives
Functional
Assurance
Security Requirements
Rationale

11. Common Criteria: Functional Package Contents
Security objectives
drives
Functional Security Requirements
Rationale

12. Common Criteria: Evaluation Model
PP Evaluation (Internal)
ST Evaluation
(Internal; Against PP
Optional)
TOE Evaluation
(against ST)

13. Project Goals
Develop a tool for security evaluation of broad range (all possible!!!) PKE applications in Marine Corps
PKI based cryptographic services vary from application to application
PKE toolkits have varying degree of functionality for certification path validation logic
Accommodate a variety of algorithms
DoD Class 3
Fortezza Class 4
KMI
Future enhancements

14. Assumptions
Need to accommodate COTS products with varying degree of path validation capability
PKI based security mechanisms will vary from application to application
Provide ability to evaluate OCSP and CRL
Extend the CC for certification path validation and other items
Access control components are not appropriate for certification path validation
Existing CC components not appropriate for CRL and OCSP response processing

15. Challenge: Balancing Act
Product Realities
Current Implementations
Variety of Solutions
Planned Enhancements
Security
Optional Features

16. Challenge: Requirements and Capability
Increasing Security, Functionality, etc.
Examples:
No trust anchor processing……………………….Full trust anchor processing
No policy processing……………………………….Full policy processing

17. Solutions Use functional packages as needed
Example: Policy processing
Use “assignment” operation for SFR to provide
additional granularity (Example: trust anchor processing)

18. Approach
Use functional packages to permit ST author to select appropriate:
PKI based cryptographic mechanisms
Certification path validation capability
Revocation checking
Certification path validation rules
Non-procedural
Attempt to preserve X.509 input, processing, output
Policy calculation all in “output”

19. Approach: Environmental Assumptions
Secure Computing and OS
Protects keys and data
Provides audit capability
Protects audit logs
Optional
Cryptographic Module
Protects private keys
May protect trust anchors
Performs cryptography

20. Approach Use mandatory functional package for PKI Credentials
Required to accommodate cases where cryptographic module does not manage trust anchors
Can be met by
application, or
environment
OS, or
Cryptographic module

21. PKI Cryptographic Functional Packages
Approach
Public Key Based Cryptographic Services
Encryption
Authentication
Integrity
Association
Path Validation Engine
Need for
PKI Cryptographic Functional Packages

22. Approach: Handling Lack of Current Revocation Information
Ability to specify acceptance of certification path in case of no revocation information or old revocation information
Past experience shows that flexibility may be needed to provide:
Configurability
User interaction

23. Functional Packages: Certificate and CRL
Full
Full Policy
Basic Policy
CRL Processing
Basic
OCSP Response Processing
Path Validation
Select one from four hierarchical
Selection based on product capability

24. Functional Packages: Cryptography Related
PKI Credential
Management
Key Transfer Encryption
Key Agreement
Encryption
Key Transfer Decryption
Sign
Key Agreement
Decryption
PKI Based Entity
Authentication
Verify

25. Enhancements (made or being made)
PKI Based Entity Authentication Functional Package
Clean up some language and CC dependencies
Add trust anchor processing as optional
Neither X.509 nor PKIX require it
Match issuer and subject DN
Verify signature using subject public key and parameters (if applicable)
Verify validity period
EKU application note may go away when MS makes changes

26. Enhancements (made or being made)
Optional audit functional package
Optional because many applications may not support auditing, e.g., client
Will cover only PKE specific event
Will also cover audit review and protection
Some or all of the requirements may be satisfied by the environment

27. Enhancements (future)
Delta CRL
Partitioned CRL (??)
Support for SCVP and/or OCSP v2 (??)

28. Questions