Subject: Inconsistency in certificate extension profiles leads to deployment nightmares

From: "L Williams" <[email-masked]>
Date: Tue, 16 Apr 2002 11:38:56 -0700

I've spent the last few years heavily involved in the architecture and
deployment of PKI in a wide variety of environments. Recently, I've been
running into more and more problems with trying to define certificate
profiles that meet the current needs and have a modicum of a chance of
being useful for the foreseeable future.

I wanted to share some of the issues I'm running into and get people's
thoughts and opinions on how we can perhaps standardize a few extension
profiles for general end entity use.

Most of the customers want to use certificates for some combination of
the following:
- digital signature
- encryption
- authentication

There is a degenerative case, but it is rare (was asked about it a few
times):
- non-repudiation certificates

This means that if they want a single end-entity profile, it should
cover all of these uses. This ends up being the simplest case, although
there can be issues with encoding types (e.g., MS requires the UPN value
in the subject alternative name field be encoded as UTF8, if you want to
be compatible with some of their features).

Dual certificates are where we begin to see problems. Something as
simple as key usage can be complicated. Take this example:
- Certificate 1, Encryption - Should key usage be keyEncipherment, or
both keyEncipherment and dataEncipherment? I realize in most
implementations keyEncipherment is fine, but I've begun to see eCommerce
implementations where database field-level encryption is done using the
public key directly.
-Certificate 2, Signature verification and Authentication - Since some
authentication implementations encrypt keys, should key usage be
digitalSignature and keyEncipherment? In a dual certificate environment
this can cause applications to break (two certificates with
keyEncipherment set)

There are many other similar issues. I keep finding that every time I
think I have this ironed out, something gets proven wrong. Simply using
a "PKIX compliant" profile is usually not enough.

So here is the challenge. What do you recommend? Any thoughts on
extension profiles that meet the following common business requirements:
- Can be generally used for encryption, digital signature and
authentication
- Since most companies use MS desktops, add support for EFS, AD name
mapping (include the UPN value, etc), and potentially PKINIT (MS
compatible or not)
- Full S/MIME support
- Full support as a client-side SSL certificate
- Forward looking and future compatible

Thanks for any thoughts or input.

-Laudon Williams