I think it worthwhile my summarizing what I believe were the main shortcomings
in X.509/RFC1422 which troubled early would-be PEM implementors and users, and
point out how I believe X.509 v3 and the standard extensions have solved these
problems.
In providing this summary, let me reiterate that I am not opposed to
integrating
MIME and PEM, nor in having a PGP-based key management option proceeding for
MIME-PEM and other applications, provided the X.509-based option continues to
develop in parallel. I believe that the latter will prove by far the more
important in the long term, because it is scalable, it has the ability to
support the long-term needs of electronic commerce, and it is quickly building
the commercial product base to make it a reality.
The following is not an exhaustive list of the requirements addressed by the
latest X.509 extension work. I am simply trying to address the most troubling
issues raised on pem-dev in the past year or so.
Problem: X.500 naming does not map easily to e-mail names which are what PEM
needs to use as the basis of identification.
Solution: The SubjectAltName extension provides for alternative name forms for
subjects including RFC822Name, DNSName, and PrivateName (can be any privately
registered name form). PEM can work entirely with the RFC822 name if desired,
and only use the X.500 name if it wants to make use of an X.500 directory.
Problem: X.500 directories are not sufficiently ubiquitous to provide the
support needed for PEM.
Solution: As well as SubjectAltName, there is also now an IssuerAltName field
supporting the same types of name forms. Hence, there are now many easy ways
to
operate PEM without needing an X.500 directory, if one wishes. For example, a
certificate can convey the CAs RFC822Name, allowing CRLs to be readily
requested
and returned by e-mail. Meanwhile, X.500 deployment is rapidly gaining
momentum
and users can easily migrate to X.500 direcories *when the time is right for
them*.
Problem: X.500 DNs do not convey sufficient information to uniquely identify a
subject for digital signature purposes, and attempts to push more semantics
into
these DNs have proved unsuccessful.
Solution: The attributes to adequately identify a subject for digital
signature
purposes need to be in a certifcate, but not in the DN. The DN itself need
imply NO semantics. The required attributes can be conveyed in the
DirectoryAttributes extension. For example, Bob has pointed out various times
in the past how a certificate user needs to know the postal address of the
signer (to know where to send the bailiff). OK - put postal address in the
DirectoryAttributes extension.
Problem: The RFC1422 trust hierarchy is too rigid for everyone. User
communities want to be able to build up their own trust structures, e.g.,
simple
cross-certification between friendly organizations.
Solution: The policies and constraints extensions allow for complete
flexibility in defining trust structures. Any CA can declare, right in the
certificate, which other CAs it trusts, for what policies, and what constraints
(e.g., name subordination) are to apply. The RFC1422 structure continues to be
available as one trust hierarchy option.
Problem: The RFC1422 name subordination rule proved difficult to map onto
existing X.500 DN structures in organizations.
Solution: There is now a NameConstraints extension which allows down-chain
certification to be restricted to specified name domains of any desired form.
Name subordination can be turned on flexibly where required.
Problem: Requiring policies to be administered via PCAs is too unwieldy and
inflexible (e.g., do we need a different PCA for every different dollar
liability declaration?)
Solution: The CertificatePolicies extension, which includes policy
identifier(s) and qualifier value(s) gives the required flexibility. The PCA
approach may still be used as one option.
Problem: Because CAs and users update their key pairs, it is difficult to find
the right certificate to check a signature (especially a certificate signature).
Solution: Explicit key identifiers are added via the AuthorityKeyIdentifier
and
PrimaryKeyAttributes field.
I would like to foreshadow a proposal to update RFC1422 in light of these
extensions, as the basis of an (optional) public-key infrastructure to support
MIME-PEM and other Internet applications.
Warwick