2.6.2 Easy-to-Use Certificates (easycert)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-11-02


Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>

Security Area Advisor:

Steven Bellovin <smb@research.att.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Public key technology -- certificates, the associated private keys,
PKIs, etc. -- are hard to use and hard to deploy.  Some of that is
merely perception, of course, but some of it is reality.  The question
for this BoF, and a possible future working group is this:  what can
the IETF do to make life easier?  Some hardware technologies may help,
but of course the IETF doesn't develop such things. On the other hand,
if we think they're part of the solution, some BCP we write can say so.

We assume that we're not missing any crucial over-the-wire protocols --
though if we are, they'd be prime candidates for IETF work. 
Accordingly, an easycert working group would be charged with writing a
few BCPs and possibly Informational RFCs.  So -- what are the titles
of some such RFCs?  If you're a service provider (for any sort of
service -- ISP, web site, ecommerce, etc.), what sort of advice should
the IETF give you?  The vendors you buy from? Software developers?

The specific goal of the BoF is to figure out what the IETF can do. 
The desired outcome is a set of major charter points, including the
titles of some RFCs we'd produce.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

EasyCert BOF
Notes combined from Paul Hoffman and Lakshminath Dondeti

Unlike many BOF sessions, this one is not intended to result in an IETF working group. Rather, this is an educational session. The hope is that everyone can learn from the people who have had successful PKI deployments. We have prepared presentations from two organizations that have successfully deployed PKI: MIT and Johnson & Johnson. We also we have some informal comments from a third organization: the US Department of Defense.


Jeff Schiller, MIT
The MIT CA Experience

Notes are matched to slides (approximately), and are meant to be
read at the same time as looking at the slides. See easycertjis.pdf.

Built in 1996
About 40,000 people
Issued 1.6 million certs issued since inception
Started with v1 certs, now doing v3
Major app: web authentication
LDAP is not an authentication mechanism
Allows MIT to let non-MIT systems use MIT's authentication

(Buy vs. Build)
MIT didn't like the $-per-cert model
Notion of charge per certificate: skews the value
Built their own system
Fixed cost of development
Allows many certificates per user with the same name

(Technology Requirements)
Easy to use; cost effective; incrementally deployable

(Easy to
MIT is slave to the browser vendors
Biggest problem: exporting certificate and associated keys to import into another system
Cannot expect users to have just one cert
Exporting/importing is just too hard
Why not just give people one cert
Doesn't use smart cards due to cost
Works only because web authentication is used

(Cost Effective)
Have 1000 new people each year
About 10-20 support calls
Web form wording is very important
The problem is reduced to getting it from a website

(Incremental Deployment)
99.9% of students have certificates
Students must have a client certificate to get registered
66% faculty have certificates
Java and cryptix
Version 1: servlet
Version 2: jsp
Version 3: about to be deployed

(MIT CA Implementation)
Now on version 3
Version 1 and 2 were in Java
Now using Python; glue will be available later
Acts as a front end to Openssl

(Registration Procedure)
Certs obtained by authenticating to CA website with Kerberos name,
password and MIT ID number
Hand out coupon with six-word SKEY phrase for initial creation
Can only be used once
Can get another coupon if they lose it
Bootstrapped with a shared secret to get a Kerberos identity
Uses the Kerberos identity and password to get more certs

Revocation is rarely asked for, so they have never implemented it
Big challenge is getting the CRLs out

(Certificate Lifetimes)
All certs expire in the middle of summer
Good for an academic environment
Can specify a shorter lifetime
A "0-day" cert is good for 1-hour :-)
Valid date is actually a day in the past due problems with UTC
Certs issued to freshmen from off-campus expire on Sept 1
Some hacks around UTC to get things to work
Their Python code is available

(Services Offered)
Web authentication
Student registration
Employee HR "self service"
Have a separate CA for server certs
Jeff issues these by hand after doing human verification
Has to rewrite the DN to correct spelling and so on before issuing

(What We Do Not Have)
A cert practice statement
A cert policy statement
In "practice" no one seems to care (they are not the government)

Problem: have to have one cert only
What about key escrow?
Implementations store encrypted messages encrypted
Encrypted mail is more important than signed mail
Funny stories about signed mail

(Questions from the floor)

Perry Metzger notes that this in "ideal mode"
No revocation, with only simple authentication
At some point, a cert might be stolen
Revocation might be an issue
Jeff answers that the real-world has many checks and balances

Have a CRL, but it's empty
Don't have a CRLDP, but they add that later

Bob Morgan mentioned KX509 that does similar things
Code is available from University of Michigan

Stefan Santesson brought up systems that work by having a central authority

Need to have Kerberos as a central layer in order to allow people to get multiple certificates over time

Steve Bellovin asks if all web based applications for this, right?
Does this works because of the Kerberos database at MIT?
Jeff answers that if they didn't have Kerberos, it could still work, but details would have to be worked out
Anything that could be used as a PSK might be used for the same purpose

Jeff's closing:
Nothing in PKIX makes his life hard
Subject Alt name is a problem, but Kerberos subject alt name is finally being defined


Bob Stahl, Johnson & Johnson
Johnson & Johnson's Public Key Infrastructure

Notes are matched to slides (approximately), and are meant to be
read at the same time as looking at the slides. See JJEDS.IETF.ppt.

(Johnson & Johnson)
Big, big manufacturing company
Has 200 operating companies
109K employees
175 countries

(Baseline PKI Architecture)
Have an offline root and an online root
Have an enterprise directory, feed by all 100+ HR groups
CRL is bigger than 2.2 megabytes: yikes!
HR feeds the employee status into the directory

(JJEDS PKI Principles)
Directory-driven, no passwords
Built and operated themselves
Use only open standards
Web-based self-service model
Strong identity proofing
Issue separate signing and encryption keys
Use USB tokens, not smartcards
Smartcards don't work: not many laptop models have smartcard readers
They escrow the private encryption keys

(Standards Based)
Use LDAP load-balanced around the world
Nine instances
In operation for two years
Have a cert policy and cert practice statement
Have a CRL of the online root
generated once per year for the root CA (for the subordinate CAs)
Online CRL generates once a day (24-hours)

(Self-Service Registration)
See the diagram in the slides!
Branding this as "digital identity"
Each person as a world-wide ID
Send a message to new employee and to the boss
Has to get the second part from the boss
When names changes or leaves, must revoke
Boss can revoke
Alice's certs are generated on her client and provide only her ID not her access privileges
Alice's certs are publishes to the Enterprise directory and from there to the email directory
Alice's signature key is never duplicated her decryption key is escrowed for contingencies
Michael Richardson notes that one-time codes emailed to Alice and her supervisor in the clear
Bob answers: there is a "in the clear" and "a secret" portion that the supervisor delivers

(Security Vision)
A very major issue is regulation
Want to issue certificates to machines to allow internal net access
JJEDS is going the PKI way to get rid of passwords
Legal and regulatory compliant
SOX, HIPAA in the US
European privacy requirements
Paul Hoffman asks if the different countries' laws are impacting things differently
Bob says, not yet!

Directory became popular by itself
More than 150k active entries
WWID-based login
Workflow routing
Phonebook replacement
Online org charts
Compliance tracking/training
Email lookups for apps
Working on a guaranteed-to-be-unique identifier

(PKI Applications)
Killer app: remote access
More than 60K users
Seeing an increase in request for secure email
Many industry-competitive parts use encryption now
Within a few years, most applications will go to certificate-only
New CRL every day with a lifetime of 7 days
Big apps are SAP, Oracle, and Windows Logon
No problems enabling in the web space with cert format
Use eCertify for CA now, will switch to Microsoft next year
The big CRL is not a problem for them
Major reason for CRL size is people locking or losing their tokens
Users take up to seven days to realize their cert has expired
Certs have five-year lifetime
Rich Graveman asks if there are any instances of certs that work for one app that don't work for others
Bob answer that they carry fields that work with all sorts of apps
Marcus Leech said that one of the problems that caused Nortel to drop certs is interoperability. Some apps required weird fields that other apps didn't like.
Bob says they are using Windows on desktops everywhere
Switching to the Microsoft CA sometime soon
Microsoft IE has some problems with the CRL
Flushing the cache fixed it
Separation between the encryption and signature key helps in revocation (sign key) vs. recovery (encr key) when something is lost
Nicolas Williams asked whether OCSP would help for revocation
Bob says the problem with OCSP is you have to be online

(Next Leap - SAFE)
Mostly used for authentication
SAFE - industry consortium for facilitating e-transactions
Cute acronym for "secure access for everyone"
Mostly for digital signatures
Run by big biopharma companies
Biopharma industry consortium aimed at facilitating e-transactions through SAFE-wide digital credentials
Will have a bridge model for signing credentials

(SAFE Value Potential)
Identity management high for clinical trial researchers
Moving towards "digital originals" for documents
Less paper
Digital signatures
Clinical testers have multiple laptops from each company they work
Must include OCSP response when things are signed
Separate company from SAFE will issue credentials to researchers

(Questions from the floor)

Steve Bellovin notes the reliance on existing authentication database
Bob says they created that database
Hardest problem was getting the internal HR folks to agree to doing this
Also hard to describe this to everyone in the company to get their buy-in
For enrollment, have an ActiveX widget to ship certificate requests over SSL
Must use FIPS-validated tokens
Gregory M Lebovitz asks what is the mechanism between the desktop and CA
Bob says it is ActiveX based
CP and CPS were created by a consultant
Built with the federal bridge in mind
Send out roots with software update, initially loaded in standard desktop loads


Sandi Roddy, US Department of Defense

DOD PKI started as part of the defense travel service
Now an identity management system (IDMS)
There is a directory that serves as the authoritative source
for their bootstrapping.
Now has 23 million DOD in the database
Have a strong need for portable private keys
Cannot have private keys stored on people's workstations
They have to be mobile - something that people can carry
Big challenges are political issues
Different services already had different PKIs in place
Convergence was a big problem
Using smartcards
Workstations for creating ID cards are custom-built the whole way
Has a logistics system to keep cards flowing to RA systems
Registration kiosks; some cases mobile on a tractor-trailer
Legal: relied on PKIX CP and CPS
On version 9 of their CP
Big challenge: new personnel given signing and encrypting key but
didn't get email keys
CRL is about 40 megabytes; hoping for reduction
Contains every registration mistake
Users forgetting their passwords is common
3-year certs
Rolling out OCSP now, has problems with some of the current apps
About 20 subordinate CAs, mostly custom code
Root CA is mostly offline
Global directory service that they rely on is not functional enough
LDAP replication hasn't worked as well as they hoped
PKIX work is wonderful, wish some of it came out sooner
Next big challenge is devices with PKI
Really, really want better, fuller standards
Using PKCS7


Open Mic

Eric Rescorla
The stories today are about systems where the user is forced
How do we get people to do this voluntarily?
Russ Housley
ISPs could issue certs with a new email mailbox
AOL is issuing a hardware device, but you need to pay money for it
Michael Richardson
PKI scales up, but not down
This doesn't work for small (50-person) organizations
Small orgs cannot afford full-time support to handle lost passwords
Bob Moskowitz
IETF maybe can use PGP to request and validate PKIX certificates
Steve Bellovin replies that here is not enough there in PGP to issue certificates based on that.
Stefan Santesson
Big problem is that IETF creates protocols not applications
In-field problems are interop and getting enrollment to work
IETF should try not to require anything heavy-weight
Thinks PKIX scales down OK
We need servers to help clients pick the right certificate if given multiple keys
Love Åstrand
Big problem is having several roots with no bridge
The problem is access
Jeff Schiller
Would the IESG be interested in issuing a cert to anyone who can read at an address
Also has a version of Mailman that uses PKIX certs
Hannes Tschofenig
If we had more apps using them, it will help bootstrap
We have ways to bootstrap symmetric keys, why not asymm keys?
David Nelson
Layer 8: the problem is getting an ROI and showing it
Need to think about costs of issuing and revocation
Steve Bellovin
Maybe phishing is the driving force for this
Sam Hartman
Why is the web access problem a PKI and not a PK problem?
Marcus Leech
Biggest problem is lack of interop between big vendors
Operational issues such as storage of all keys on a single smartcard
Uri Blumenthal
We have all we need in protocol and application suites
Whenever there was the power of force, it pretty much worked
What is lacking is force


The MIT CA Experience
Johnson & Johnson’s Public Key Infrastructure