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