-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV
zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,1D
MIC-Info: RSA-MD5,RSA,BxQ/dthO69g3j6k9mVuabAb89Pu4rF33wIFwxaVi0/j
sqY9Z4inNyjfpOFzqo2EaCuX6C1A7Npz/GNufZDnhJQ==
In the latest draft of part II of the PEM specs, Certificate-Based Key
Management ("RFC 1114F"), there is a clear statement that only a
single certificate hierarchy will exist, and it will be rooted with
the ICA's public key. This is the Platonic ideal for the Internet,
but not completely tuned to the dynamics of the (public) Internet or
private internets.
Here are some situations which are bound to occur.
1. The ICA's key will change. How or why is unpredictable, but
nothing is immutable. An implementation must provide a means for
updating its knowledge of the ICA's key.
2. Separate hierarchies, however "undesirable", are likely to occur.
The community's effort is focused on establishing an all-embracing
hierarchy which invites everyone to join in, but it seems like a
bad gamble to depend that only a single hierarchy will emerge.
How should a PEM user implementation accommodate disjoint
hierarchies?
3. PEM will be used in private internets separate from the Internet.
Several companies have licenses from RSADSI which permit them to
sell mail systems which do not have to be tied into the Internet
certificate hierarchy.
The current draft of 1114F appears to prohibit a conforming PEM
implementation from accommodating any of these situations.
We believe it's important to accommodate these situations. In our
implementation (TIS/PEM), we are using a scheme to check the validity
of certificates which is a bit more general. The checking algorithm
implied by 1114F is:
check_certificate(cert) =
(If issuer_cert(cert).dname = ICA then TRUE
elseif in a loop, then return FALSE
else check_certificate(issuer(cert))) AND
check_signature(cert, issuer_cert(cert).pubkey)
(The full algorithm also requires checking of the validity period and
revocation.)
To accommodate the situation listed above, we have generalized this
algorithm a bit. The change also provides a hook for notifying the
user when a certificate is encountered that has been issued under a
policy different from the user's own.
We have replaced ICA with a list, RR, of certificates. If this list
is instantiated with only the ICA_root_cert, the behavior is the same.
The revised algorithm is:
check_certificate(cert) =
(If issuer_cert(cert).dname is on RR then TRUE
elseif in a loop, then return FALSE
else check_certificate(issuer(cert))) AND
check_signature(cert, issuer_cert(cert).pubkey)
The existence of RR permits a variety options. A change of ICA can be
accommodated by distributing the new key for everyone to add to RR so
both the old and new keys are valid. After a suitable period,
everyone could remove the old key from RR.
Interaction across disjoint hierarchies can be accommodated locally by
simply adding the top of the other guy's hierarchy to RR. (And he'll
presumably add yours to his RR.)
Cross-certification within the overall hierarchy is also just a matter
of adding additional certificates to RR.
Private PEM hierarchies are effected by putting the appropriate root
on RR. The ability to transition root keys makes it possible to move
a private hierarchy into the Internet hierarchy at a later time,
assuming the naming conventions haven't been violated.
Unstated in the above treatment is what mechanism is to be used to add
or deleted items on RR. This is a separate matter with several useful
possibilities, including:
a. Fixed forever. No changes possible. This implements the current
scheme.
b. Manual change. Changes are distributed out of band and installed
at local option. This is probably the most likely mode at the
outset.
c. Automatically controlled updates to RR based on a list, PP, of
acceptable "publishers"
A server could accept authenticated messages from an approved list
PP of "publishers". Publishers on PP would send messages to their
clients announcing changes to be made in RR. For example, suppose
there are various consortia that refuse to have their hierarchies
be part of any larger hierarchy, yet it is desirable to be able to
interact with them. For example, the U.S. Treasury Dept, the
Confederation of Swiss Banks and OPEC might all insist on having
their own hierarchies yet all wish to correspond. Businesses which
wish to interact with any of these hierarchies must find out what
the root keys are for each hierarchy and add them to the local RR.
(And conversely, members of those hierarchies which wish to
correspond with businesses or agencies outside their own hierarchy
must also add the "outside" roots to their local RR.)
To facilitate keeping track of the root keys of these hierarchies,
a reputable third party can offer a service of announcing the
changes. For the sake of illustration, McGraw-Hill could provide
such a service as part of its data and business publication
services. If I choose to listen to McGraw-Hill, I'd put
McGraw-Hill on my copy of PP, and McGraw-Hill would send mail
messages that cause the roots of the U.S. Treasury, the
Confederation of Swiss Banks and OPEC to be installed on my RR.
d. Automatic updates to RR controlled within my organization
Same mechanism as above except PP contains the certificate of the
company office responsible for vetting RR elements.
e. Explicit treatment of policy boundaries within the Internet
hierarchy.
Populate RR with the certificates of PCAs instead of the ICA, and
include each PCA's policy. When the checking algorithm reaches a
certificate on RR, the associated policy can be checked and/or
returned to the user.
In this model, the ICA becomes a type of publisher and any new
certificates signed by it can be added to RR. Similarly, the ICA's
CRL causes deletion from RR. Alternatively the ICA may provide an
alternate means of advertising the certificates of PCAs in which it
includes the policy statements associated with that PCA. Ideally,
these messages will be signed by the ICA.
We invite comment on this matter.
-----END PRIVACY-ENHANCED MESSAGE-----