Transcript No Slide Title

PKI:
News from the Front
and views from the Back
Ken Klingenstein,
Project Director, Internet2 Middleware Initiative
Chief Technologist, University of Colorado at Boulder
Agenda
X.509 Certificates
The Technical Infrastructure - CRL’s, CA software, Directories,
Applications, Mobility
The Policy Infrastructure- policies, practices, paths, lifetimes
Authorization - complex, high-payoff
Next steps
Uses for Certificates
authentication and pseudo-authentication
signing docs
encrypting docs and mail
non-repudiation
secure channels across a network
authorization and attributes
and more...
X.509 certs
purpose - bind a public key to a subject
standard fields
extended fields
profiles
client and server cert distinctions
Standard fields in certs
cert serial number
the subject, as x.500 DN or …
the subject’s public key
the validity field
the issuer, as id and common name
signing algorithm
signature info for the cert, in the issuer’s private key
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 can’t
understand it, then don’t use the cert
Requires profiles to document, and great care...
The Technical Infrastructure
Certificate Revocation Lists
Cert management
Directories
Certificate Enabled Applications
Mobility
Certificate Revocation Lists (CRL)
Purpose - to post revoked certs by serial number
Reasons for revocation include major (disaffiliation, key
compromise, etc.) and minor (name change, attribute change)
Path construction - to build the chain of trust from the issuer CA
to a CA trusted by the relying party
Certificate validation - uses path to determine if cert is valid
Application and user responses - what to do if revoked? What to
do if unknown? Does the app or the user decide?
Cert Management
Certificate Management Protocol - for the creation and
management of certs
OCSP - on-line CRL plus….
Storage - where (device, directory, private cache, etc.) and how
- format
escrow and archive - when, how, and what else needs to be
kept
Cert Authority Software
Authority and policies
CA Software
SUN/Netscape
IBM
W2K Certserv
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
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
Cert-enabled applications
Browsers
S/MIME email
IPsec and VPN
Globus
Mobility
smart cards and USB devices
KX.509 for authenticated delivery of certs to users
storing certs - integration of certificate stores
storing and using keys
Trust model components
Client versus Server distinctions
Certificate Profiles - syntax, semantics and uses of specific
types of certificates
Certificate Policy - uses of particular certs, assurance levels for
I/A, audit and archival requirements
Certificate Practice Statements - the nitty gritty operational
issues
Trust Chains and Path Math
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 being set up
Certificate Policies
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
Certificate Practice Statements
operational aspects that allow lawyers to decide who to trust
must cover I/A, Cert Management, underlying operations
Trust Chains
verifying sender-receiver assurance by finding a common
trusted entity
must traverse perhaps branching paths to establish trust paths
must then use CRL’s etc to validate assurance
if policies are in cert payloads, then validation can be quite
complex
delegation makes things even harder
Hierarchies vs Bridges
a philosophy 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
Will it fly?
Well, it has to…
Scalability
Performance
OBE
“With enough thrust, anything can fly”
PKI Activities
DLF: UCOP, Columbia, soon Minnesota
FPKI (http://csrc.nist.gov/pki/twg/welcome.html)
PKI for NGI, Globus
net@edu within EDUCAUSE
CREN CA
In-sources - MIT, Michigan
Out-sources - Pittsburgh, Texas
PKIforum
W2K
Next Steps
PKI Labs
• long-term research agenda, includes path math, open standards
and reference implementations
• ATT catalyst funding with other investments expected
• a national advisory board
• RFP next month
Net@edu
• Fed-ed meetings
• workshops
Next Steps
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