pki 150: pki parts policy & progress jim jokl. university of virginia david wasley university of...
TRANSCRIPT
PKI 150:PKI Parts Policy & Progress
Jim Jokl.
University of Virginia
David Wasley
University of California
2
Agenda
Part 1: Fundamentals
• Components and Contexts
• Policy and Trust
• Missing pieces - in the technology and in the community
Part 2: Current Activities - filling in the missing pieces
• Federal PKI activities
• HIPAA related PKI activities
• Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG, Net@edu, PKI Labs)
» Certificate profiles» Mobility» Interoperability» and more . . .
3
PKI: A few observations
“Think of it as wall jack connectivity, except it’s connectivity for individuals, not for machines, and there’s no wall or jack…But it is that ubiquitous and important.” - Ken Klingenstein
Options breed complexity; managing complexity is essential;The hard part is making it seem simple to the users.
We’ve always known we needed strong authentication and data security but it is hard so we put it off. Unfortunately, now the applications have arrived before the infrastructure, making its development much harder.
4
What is PKI?
Public Key Infrastructure (PKI) is a system to generate and use asymmetric cryptography to secure and validate digital documents.
• asymmetric cryptography uses a pair of large prime numbers such that whatever one encrypts, only the other can decrypt
• data security is achieved by encrypting a document using a “public key” so that only the holder of the other (“private”) key can decrypt it
• a digital signature is achieved by encrypting a document with a “private key”» validation of the signature is done using the corresponding “public key”
A digital credential is formed and signed by a trusted authority
• x.509v3 is the current format for digital credentials
• the contents of the certificate relate in some way to the holder/“Subject”
• it includes a “public key” generated by the holder/“Subject”
See for example “Digital Certificates and Public Key Infrastructure” http://www.iplanet.com/products/iplanet_certificate/whitepaper_2_1_1_3ad.html
5
Why PKI?
Authentication and pseudo-authentication
• What is “identity” anyway??
Digital signing of important documents, e.g. contracts, memos, etc.
Encrypting documents, e.g. email
Validation of digital signatures (non-repudiation)
Secure communication across a network
Authorization rules require trusted attributes re: Users
• Resources are increasingly located off campus
• Reliable inter-institutional trust is essential
and more...
6
PKI Contexts for Usage
Intracampus
• appropriate access management for institutional resources
• scalable distributed authority and responsibility
• auditable paperless transactions
• data security
• verifiable web documents
• reliable digital archiving
Within the Higher Ed community of interest
• sharing of resources among campuses, classes
• working group management
In the Broader World
• e-commerce partners
• Federal agencies
Etc., etc., etc.
7
Some Cert-enabled applications
Browsers
• SSL negotiation
• User authentication
Server Authentication
• Cert must be issued by trusted authority
S/MIME email
IETF IPsec and VPN
Globus
Secure multicast
Future - access to QoS transport, etc.
A goal of Middleware is to allow easy conversion of other apps.
8
PKI Components
X.509 v3 certificate definitions
Certificate Policy and Certification Practices statements (trust)
Cert management - generating key pairs, issuing certs, archiving and escrow, mobility, etc.
Directories - to store certs and public keys, Subject attributes, and maybe private keys
Trust path construction & validation
Certificate Revocation Lists, OCSP
Cert-enabled applications
9
X.509 v3 Certificates
Purpose - to bind a public key to a Subject
• Subject is “identified” by fields in the cert (may be a “group”)
• Other information may be retrieved using these fields
Standard fields
Extension fields
client and server issues
v3 for current work
• v4 being finalized to address some additional cert formats (attributes, etc.)
No meaning should be attached to anything in the cert except as defined in the Certificate Policy and Certification Practices statements
• e.g. a Subject may not be assumed a member of MIT merely because they have a cert issued by MIT - unless the CP/CPS says that is true.
10
Subjects and Identity
Identity is the set of attributes that pertain to an entity; the particular attributes that are important depend on context.
Some attributes are shared:
• gender, name (often), affiliation (student, faculty, staff), etc.
Others are specific to the entity:
• Dean of Physics, employee ID (hopefully!), SSN (well...), DL# (?), etc.
• email address should be pretty good» example of a qualified identifier
The “value” of some attributes changes over time
• credentials should contain long-lived attributes to minimize revocation
What a target application or server needs to know may not be in the credential -
• therefore additional attributes need to be available in directories
11
Certificate Types
Certificates can assert many different types of things• their useful meaning will depend on applications understanding them
Identity Cert - contains something useful about the holder
Pseudonymous Cert - contains only a unique “handle” for the holder
Anonymous Cert - contains only attributes shared by a defined group• e.g. “faculty” or “member of the campus community”
Encryption Cert - used for securing data• may require escrow of the private key - therefore unsuitable for signing
Signature Cert - may be needed to hold additional attributes such as role or authority
• Cert is archived for as long as the signature must be validatable
Function Cert - asserts eligibility without revealing specific identity• e.g. electronic voting
12
Standard Fields in Certs
Cert unique serial number
The Issuer, as x.500 DN
• must be identical to the Subject field in the Issuer’s authority cert
The Subject, as x.500 DN
The Subject’s public key
The validity period
The signing algorithm
The signature info for the cert, created with the issuer’s private key
See IETF RFC 2459 for all the gory details
13
Extension Fields
“Standard” and “private”
Standard extensions include
• issuer/subject altnames, key usage, CRL distribution points, policy and practices pointers, etc.
• Key Usage is very important - for digital signature, non-repudiation, key or data encipherment, etc.
Private extensions - payload that may only have local meaning
• Location of an attribute directory
• should be given unique OIDs to avoid potential conflicts
Certain extensions can be marked critical - if a Relying Party can’t understand it then it shouldn’t use the cert
Certificate profiles document total payload (covered in Part 2)
14
Background on OIDs
Numeric coding to uniquely define many middleware elements, such as directory attributes and certificate policies.
Numbering is only for identification
• are two OIDs equal? If so, the associated objects are the same
• no ordering, search, hierarchy, etc.
OIDs can be associated with:
• abstractions - e.g. “the Level of Assurance of this cert”
• type identifiers - e.g. “the following object is a pointer of type <X>”
• object identifiers - e.g. “this Cert Policy is identified by OID <N>”
Distributed management; each campus typically obtains an “arc”, e.g. 1.3.4.1.16602, and then creates OIDs by extending the arc,e.g 1.3.4.1.16602.1.0, 1.3.4.1.16602.43.10, 1.3.4.1.16.602.10.5.1
• campus should have an OID registrar
15
Getting an OID
apply at IANA at http://www.iana.org/cgi-bin/enterprise.pl
apply at ANSI at http://web.ansi.org/public/services/reg_org.html
more info at http://middleware.internet2.edu/a-brief-guide-to-OIDs.doc
16
Cert Management
Certificate Management Protocol - for the creation, revocation and management of certs
• RA <--> CA
• CA <--> browser
• browser <--> diskette (!)
Revocation Options - CRL, OCSP
Storage - where (device, directory, private cache, etc.) and how - format (DER, BER, etc.)
• related to mobility (covered in Part 2)
Escrow and archive - when, how, and what else needs to be kept
Cert Authority Software or outsource options
Policy Authority and policies
17
Policy - the Establishment of Trust
On what basis does a Relying Party “trust” a CA?
• It has some assurance that it knows how it operates (much like life)
At least 4 documents are needed:
• The institutional business context » what office is the Digital Credential Authority?
• The Certificate Policy» how is a cert issued, what does it mean, how is it managed, etc.
• A (set of) Certification Practices Statement(s)» how is the Policy implemented in practice?
• A Directory Management Policy» how is data entered or changed?» what data can be released, and under what circumstances?
Bridge Policy Management Authorities need to be able to map your CP/CPS to another CA hierarchy’s CP/CPS
• commonality is A Good Thing
18
Certificate Policies Address (CP)
Assurance levels
• levels determined by I/A processes and other operational factors
Legal responsibilities and liabilities (indemnification issues)
Relying Party obligations
• “By making use of [this] certificate, the Relying Party agrees...”
Operations of Certificate Management Systems
Archiving of CMS records
Auditing requirements
Certificate revocation and renewal requirements
Accompanying Certification Practices Statement(s) define specifics
19
Certification Practice Statements (CPS)
Site specific details of operational compliance with a Cert Policy
• Who/what can be a Subject?
• Who is responsible for the physical CA, etc.?
• How is initial identification/authentication of Subjects accomplished?
• Where is the CP stored?
• How is revocation requested?
• etc.
A single Policy might be referenced by a number of Practice Statements
A single Practice Statement can support several Policies (CHIME)
A Policy Management Authority (PMA) determines if a CPS is an appropriate implementation of a given CP.
20
Directories
Directories (typically LDAP accessible) are needed to:• to store issued certs
• to store attributes (eduPerson will be described in Part 2)
• MAYBE to store private keys - for the time being» this raises serious privacy concerns
• to store the CRL
Certain directory information must be protected• institutional policy, FERPA requirements, User preferences
• implement with border directories
• ACLs within the enterprise directory» based on PKI cert authentication!
• Attribute Authority» a new concept for controlled release of User attributes
• proprietary directories
21
PKI Implementation Options
In-source - with public domain or campus unique software
• MIT, Columbia, Virginia
In-source - with commercial product
• Minnesota
In-&-Out-source - with commercial services
• University of California & Verisign
Out-source - a spectrum of services and issues
• Texas, UAB
• Verisign, Digital Trust, Entrust, Baltimore, etc. etc.
What you do depends on when you do it, cost tradeoffs, etc...
22
Public Domain Alternatives
SSLEAY (Open SSL)
• http://www.openssl.org/
Open CA
• http://www.openca.org/docs/mission.shtml
Intel Common Data Security Architecture (CDSA)
• http://developer.intel.com/ial/security/
Mozilla (?)
vandyke and Cygnacom libraries in the public domain for path discovery and validation
23
Trust Chains
Verifying sender-receiver comfort level by finding a common trusted entity
Must traverse perhaps branching paths to establish trust paths
Must then use CRLs etc. to validate certs at each node along path
If policy mapping is indicated by a cert in the path, then validation can be quite complex
Software to discover and validate complex chains is rare (so far)
Current practice avoids this by distributing “trusted authority certs”
24
Inter-organizational trust model components
Certificate Policy and Certificate Practices form the basis for trust
Hierarchies and cross certification form the technical underpinning• Hierarchy starts with a root CA that issues authority certs to other CAs
» subordinate CAs may (or may not) do the same
» policy and practice conformity is enforced from the top
• Certification of a CA by another unrelated CA can link 2 hierarchies» policy and practices must be “mapped” - roughly equivalent
» bi-directional or cross-certification forms a bridge between them
» a “bridge CA” can link may different hierarchies
Hierarchies vs Bridges• a philosopy and an implementation issue
• the concerns are transitivity and delegation
• hierarchies assert a common trust model
• bridges pairwise agree on trust models and policy mappings
25
Cross-certification
“A” certifies “B” so that “1” can trust certs issued under “B”
• however, “3” and “4” can’t establish path to CAs under A
“B” and “C” are cross-certified so all certs in either are trusted
1
2
A
4
B
3
C
56
26
A Bridge CA
A “Bridge CA” serves as a clearing house, mapping policy among cooperating CA hierarchies
Bridge CA
C
564
B
3
1
2
A
27
Trust Chains
Path construction
• to determine a path from the issuing CA to a trusted CA
• heuristics to handle branching that occurs at bridges
Path validation
• uses the path to determine whether trust is appropriate
• should address revocation, key usage, basic constraints, policy mappings, etc.
28
Trust Chains
When and where to construct and validate
• off-line - on a server - at the discretion of the application
• may depend on depth of chain
Some revocations better than others
• major (disaffiliation, key compromise, etc.)
• minor (name change, attribute change)
Sometimes the CRL can’t be found or hasn’t been updated
OCSP will help this
• URI pointer in cert
29
Key issues around “trust”
Trust relationships among autonomous organizations
• Chains, bridges
• Interoperability of profiles and policies
Interactions with J.Q. Public
• People need to learn how to manage these credentials
• This will be non-trivial for most people
• Implementations must make it as easy (intuitive) as possible
International governance issues
• Governmental bodies may get involved
• E.g. release of personally identifiable attributes is restricted in Europe
Case law
• None yet but “digital signatures” may be a hot area soon
30
All the stuff we don’t know…
Policy languages
• automation of policy verification
Mobility - both of certs and Users
• one computer with many users
• one user with many computers
Path construction in complex trust environments
Operating system and token security issues
Scalability of revocation approaches
User interface !!
31
A few words about User Interface
Primary User tool is the browser, both for getting and using certs.
Issues include:
• management of multiple (types of) certs» how can we avoid asking the User to choose which one to offer?
• installing or caching “trusted root” certs» alternative to trust chain, or when chain can’t be found
• support for “dual certs” (signing and encryption)
• ease of use - signing and/or encryption» click here to sign this transaction» click here to check the signature on this page
• “certs on demand” - e.g. anonymous certs for library access
• Portability and standard O/S interface
• Use of “attribute certs” by servers
32
End of Part 1
Refreshment break . . .