PKI 101

1
PKI 101

• Ken Klingenstein
• Project Director, Internet2 Middleware Initiative
• Chief Technologist, University of Colorado at
  Boulder

David Wasley Technology Guru University of
California
2
Agenda

• Fundamentals - Components and Contexts
• The missing pieces - in the technology and in the
  community
• Current Activities - Feds, CHIME, ANX, overseas,
  PKI Forum, etc.
• Higher Ed Activities (CREN, HEPKI-TAG, HEPKI-PAG,
  Net_at_edu, PKI Labs)

3
PKI A few observations

• Think of it as wall jack connectivity, except
  its connectivity for individuals, not for
  machines, and theres no wall or jackBut it is
  that ubiquitous and important
• Does it need to be a single infrastructure? What
  are the costs of multiple solutions? Subnets and
  ITPs...
• Options breed complexity managing complexity is
  essential

4
A few more...

• IP connectivity was a field of dreams. We built
  it and then the applications came.
  Unfortunately, here the applications have arrived
  before the infrastructure, making its development
  much harder.
• No one seems to be working on the solutions for
  the agora.

5
Uses for PKI and Certificates

• authentication and pseudo-authentication
• signing docs
• encrypting docs and mail
• non-repudiation
• secure channels across a network
• authorization and attributes
• and more...

6
A matrix to structure the issues

• Rows PKI Components - hardware, software,
  processes, policies
• Columns Contexts for usage - community of
  interests
• Cells Implementation options (in-source,
  out-source, roll-your-own, etc.)
• Note changes over time...

7
PKI Components

• X.509 v3 certs - profiles and uses
• Validation - Certificate Revocation Lists, OCSP,
  path construction
• Cert management - generating certs, using keys,
  archiving and escrow, mobility, etc.
• Directories - to store certs, and public keys and
  maybe private keys
• Trust models and I/A
• Cert-enabled apps

8
PKI Contexts for Usage

• Intracampus
• Within the Higher Ed community of interest
• In the Broader World

9
PKI Implementation Options

• In-source - with public domain or campus unique
• In-source - with commercial product
• Bring-in-source - with commercial services
• Out-source - a spectrum of services and issues
• what you do depends on when you do it...

10
Cert-enabled applications

• Browsers
• Authentication
• S/MIME email
• IPsec and VPN
• Globus
• Secure multicast

11
X.509 certs

• purpose - bind a public key to a subject
• standard fields
• extended fields
• profiles to capture prototypes
• client and server issues
• v2 for those who started too early, v3 for
  current work, v4 being finalized to address some
  additional cert formats (attributes, etc.)

12
Standard fields in certs

• cert serial number
• the subject, as x.500 DN or
• the subjects public key
• the validity field
• the issuer, as id and common name
• signing algorithm
• signature info for the cert, in the issuers
  private key

13
Extension fields

• Examples - auth/subject subcodes, key usage, LDAP
  URL, CRL distribution points, etc.
• Key usage is very important - for digsig,
  non-rep, key or data encipherment, etc.
• Certain extensions can be marked critical - if an
  app cant understand it, then dont use the cert
• Requires profiles to document, and great care...

14
Certificate Profiles

• per field description of certificate contents -
  both standard and extension fields, including
  criticality flags
• syntax of values permitted per field
• semantics specified
• spreadsheet format by R. Moskowitz, XML and ASN.1
  alternatives for machine use
• centralized repository for higher ed at
  http//www.educause.edu/hepki

15
Early Profile Commonalities and Differences

• Commonalities -
• Signing algs either RSA with MD5 or RSA with
  SHA-1
• Keep the contents simple and generally
  non-volatile no-one is doing CRLs yet
• Inclusion of some domain component information
  within the payload
• Differences -
• Where to put domain information
  (altsubjname,subjname,issuername, etc)
• What fields to mark critical
• How to use constraints

16
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.
• Distributed management each campus typically
  obtains an arc, e.g. 1.3.4.1.16.602.1, and then
  creates oids by extending the arc, e.g
  1.3.4.1.16.602.1.0, 1.3.4.1.16.602.1.1,
  1.3.4.1.16.602.1.1.1)

17
Getting an OID

• apply at IANA at http//www.iana.org/cgi-bin/ente
  rprise.pl
• apply at ANSI at http//web.ansi.org/public/servic
  es/reg_org.html
• more info at http//middleware.internet2.edu/a-bri
  ef-guide-to-OIDs.doc

18
Cert Management

• Certificate Management Protocol - for the
  creation, revocation and management of certs
• Revocation Options - CRL, OCSP
• Storage - where (device, directory, private
  cache, etc.) and how - format (DER,BER, etc.)
• Escrow and archive - when, how, and what else
  needs to be kept
• Cert Authority Software or outsource options
• Authority and policies

19
Certificate Management Systems

• Homebrews
• Open Source - OpenSSL, OpenCA, Oscar
• Third party - Baltimore, Entrust, etc.
• OS-integrated - W2K, Sun/Netscape, etc.

20
Public Domain Alternatives

• Mozilla
• SSLEAY (Open SSL) (www.openssl.org)
• Open CA (http//www.openca.org/docs/mission.shtml)
  
• vandyke and Cygnacom libraries in the public
  domain for path math

21
Directories

• to store certs
• to store CRL
• to store private keys, for the time being
• to store attributes
• implement with border directories, or ACLs within
  the enterprise directory, or proprietary
  directories

22
Certificate Policies Address (CP)

• Legal responsibilities and liabilities
  (indemnification issues)
• Operations of Certificate Management systems
• Best practices for core middleware
• Assurance levels - varies according to I/A
  processes and other operational factors

23
Certificate Practice Statements (CPS)

• Site specific details of operational compliance
  with a Cert Policy
• A single practice statement can support several
  policies (CHIME)
• A Policy Management Authority (PMA) determines if
  a CPS is adequate for a given CP.

24
Inter-organizational trust model components

• Certificate Policy- uses of particular certs,
  assurance levels for I/A, audit and archival
  requirements
• Certificate Practices Statement- the nitty gritty
  operational issues
• 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
Trust Chains

• verifying sender-receiver assurance by finding a
  common trusted entity
• must traverse perhaps branching paths to
  establish trust paths
• must then use CRLs etc. to validate assurance
• if policies are in cert payloads, then validation
  can be quite complex
• delegation makes things even harder

26
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 if trust is
  appropriate
• should address revocation, key usage, basic
  constraints, policy mappings, etc.

27
Trust chains

• When and where to construct and validate
• off-line - on a server - at the discretion of the
  application
• depth of chain
• some revocations better than others - major
  (disaffiliation, key compromise, etc.) and minor
  (name change, attribute change)
• sometimes the CRL cant be found or hasnt been
  updated

28
Mobility Options

• smart cards
• USB dongles
• passwords to download from a store or directory
• proprietary roaming schemes abound - Netscape,
  VeriSign, etc.
• SACRED within IETF recently formed for standards
• Difficulty in integration of certificates from
  multiple stores (hard drive, directory, hardware
  token, etc.)

29
All the stuff we dont know

• Revocation approaches
• Policy languages
• Mobility
• Path construction in complex trusts
• Operating system and token security issues
• User interface

30
Internet2 PKI Labs

• At Dartmouth and Wisconsin in computer science
  departments and IT organizations
• Doing the deep research - two to five years out
• Policy languages, path construction, attribute
  certificates, etc.
• National Advisory Board of leading academic and
  corporate PKI experts provides direction
• Catalyzed by startup funding from ATT

31
Activities in other Communities

• PKIX (http//www.ietf.org/html.charters/pkix-chart
  er.html)
• Federal PKI work (http//csrc.nist.gov/pki/twg/)
• State Govts (http//www.ec3.org/)
• Medical community (Tunitas, CHIME, HIPAA)
• Automobile community (ANX)
• Overseas
• Euro government - qualifying certs
• EuroPKI for Higher Ed (http//www.europki.org/ca/r
  oot/cps/en_index.html)

32
Ah, the public sector

• almost universal community of interests
• cross-agency relationships
• complex privacy and security issues
• limited budgets and implementation options
• sometimes ahead of the crowd and the obligation
  to build a marketplace

33
Activities in Higher Ed community

• Federal - ACES, etc.
• State Governments - Washington, Virginia, Texas,
  etc.
• HEPKI
• the Grid

34
HEPKI

• HEPKI - Technical Activities Group (TAG)
• universities actively working technical issues
• topics include Kerberos-PKI integration, public
  domain CA, profiles
• will sponsor regular conf calls, email archives
• HEPKI - Policy Activities Group (PAG)
• universities actively deploying PKI
• topics include certificate policies, RFP sharing,
  interactions with state governments
• will sponsor regular conf calls, email archives

35
Key issues

• trust relationships among autonomous
  organizations
• interoperability of profiles and policies
• interactions with J.Q. Public
• international governance issues

36
Will it fly?

• Well, it has to
• Scalability
• Performance
• OBE
• With enough thrust, anything can fly

37
Where to watch

• middleware.internet2.edu
• www.educause.edu/hepki
• www.cren.org
• www.pkiforum.org