In discussion a few weeks ago with Bonb Jueneman and Sead
Muftic, and in a more recent conversation with Paul Cook at TIS, I was
reminded that there are some techniques (not discussed in the RFCs)
that can reasonabley be employed to preserve name subordination while
addressing a variety of legitimate certificate management
requirements. These techniques apply to both organizational and
residential certification contexts. The following message describes
some of these techniques.
Consider an organization that is a residential PCA and wishes
to serve a large geogra[hic community, e.g., all of the U.S. or even
multiple countries around the world. The goals are to issue
residential user certificates under a single policy, maintain name
subordination, and to employ additional organizations to effect
"local" user certification in different geographic regions. Let's say
the PCA's DN is: C=US, S=MA, O=BBN, OU=Universal Residential
Certification Authority. Let's say that BBN enters into an agreement
with an organziation in Louisiana to certify users in that state, plus
Mississippi and Alabama, all following the policy established by the
BBN Universal Residential Certification Authority. The folks signing
up to perform this function might be C=US, S=LA, O=Good Ole Boys Inc.
(As a Louisiana native I'm allowed to make up names like that!)
Now if GOBI were to certify users under its DN, and if the DN
subordinatioon rule were followed, these users might get certificates
of the form: C=US, S=LA, O=Good Ole Boys Inc., S=AL, L=Mobile,
CN=Rufus T. Fishbone, Jr. (the street address is omitted to keep
things simple). If I were Rufus, I would not be happy with this DN,
and for good reason. Rufus wants a DN that identifies him in a
geopolitical context, irrespective of the CA that issued it, just as
his telephone numnber didn't change when he switched from AT&T to MCI,
then to Sprint.
We can avoid this problem by recognizing that GOBI is just an
agent for BBN URCA, that is the PCA who sets the policy and who could
ultimately be held liable if GOBI screws up (under terms of the
agreement between BBN URCA and GOBC). Let' say that BBN contracts
with another organization {C=US, S=WY, O=Wild West Services Inc.} to
handle residential user registration in WY, MT, ND, SD and ID. The
fact that WWSI performs this service for folks in these states,
vs. GOBI in the South, should make no difference to someone validating
a residential user certificate for folks from either region! The real
issue is the policy iunder which the users are certified. GOBI and
WWSI are just midelemen and need not appear in the certification path
at all! They can act as what we used to call Organizational Notaries
(ONs), a term dropped in 1422 but which appeard in previous RFCs on
PEM certificate management. We dropped the concept, in part, because
it is a "local matter" and should be invisible to the "external"
population.
In this case, GOBI or WWSI would collect the user ID data
required under the PCA policy established by the BBN Universal
Residential Certification Authority. They can locally store that data
(depending on what the argeement with the PCA requires) and just
forward the residntial user's certificate to BBN for signing. BBN
would operate a set of "captive" CAs, one for each geoploitical region
in which it will certify residential users. BBN would then sign the
certificate under the auspices of that geoploitical authority, and
send it back to the user, either directly or via the local
representative. The result is a certification path that preserves the
name subordination rule, a user who gets a DN appropriate for his
geopolitical location, and a policy that makes the operating policy
clear to anyone who receives a certificate issued under this PCA.
This is somewhat analogous to the way bank credit cards are
issued, though it is an imperfect analogy since credit cards are forms
of authorization and we are talking about identification. A merchant
really cares about the identity of the credit card issuer (Visa or
MC), rather than the identity of the agent of these organizations (the
Bank) who issued the card. The banks are middlemen who abide by some
uniform policy established by the credit card companies. The
merchant, in accepting the card, cares about the credit card company
rather than the specific issuer. (The analogy is imperfect in that
credit cards don't provide globally unique IDs except in the form of
the card number, which DOES imbed the issuer's ID in it, an example of
name subordination. However, these IDs are not very descriptive in
themselves. They are appropriate only in the context of certain types
of financial transactions, which illustrates the concept that
desciptiveness is somehwat context sensitive.)
Note that the same sort of construct can be used effectively
within an organization. BBN is headquartered in Cambridge, but we
have offices in Columbia, MD, Rosslyn, VA and several other sites.
The two sites noted above are the largest and thus might be good
locations where local folks should verify employee IDs and issue
certificates, whereas the smaller offices wil be handled out of HQ.
However, BBN wants to issue certificates for ALL employees where the
employee DN does not indicate an organizational unit affiliation or a
geographic affiliation, because we feel that is an unnecessary amount
of detail to put into a certificate. Thus, for example, we DON'T want
to issue a certificate with a subject DN of the form: C=US, S=MA, O=
Bolt Beranek and Newman, Inc., S=MD, L=Columbia, CN=Joe Cool. Rather,
we might want the subject DN to be: C=US, S=MA, O= Bolt Beranek and
Newman Inc., OU=Employee, CN=Joe Cool.
We can achieve the desired outcome by using the organizational
notary approach described above. A representative employee at each
"remote" site can act as the ON for that site. He would check the
employee ID info locally and forward a certificate request via a
signed message to the CA in Cambridge. The signature on the incoming
message would be verified and the identity of the sender would be
checked against the list of BBN ONs (a kind of ACL). The prototype
certificate would be checked, a unique serial number will be assigned,
the subject DN will be checked to ensure that it is unique throughout
all of BBN, and the BBN CA signature would be affixed. The resulting
certificate would be sent back to the user.
Another option is feasible using the certificate signing unit
hardware (SafeKeyper) that BBN manufactures and which can be used with
the RSA Certificate Issuing System (CIS). (We get a good price on
them so we could afford to use several ;-)) BBN could initialize three
SafeKeypers so that a CA private key generated on any of them can be
transferred among this set in encrypted form. (For details on how
this trick is managed see the paper by Charlie Gardiner in the
proceedings of the 1993 Workshop on Network and Distributed System
Security sponsored by LLNL and the Internet Society.) Then we can
generate the BBN CA key pair in one unit, and transfer the private
component to two other units, each of which will be used by a BBN CA
representative at the Columbia and Rosslyn sites. All of the
SafeKeypers will sign certificates that have the same Issuer DN (C=US,
S=MA, O= Bolt Beranek and Newman Inc.), achieving the same external
appearance as above. Each SafeKeyper will issue certificates with
different serial numbers, but traceable to the specific device that
signed the certificate. The CA private key copies will be protected
from disclosure uniformly at each site. The one task remaining is to
ensure that the Subject DNs are globally unique. One could perform
some form of centralized database co-ordination, or we could make the
last RDN a sequence consisting of the employee common name and
employee ID number, which guarantees uniqueness.
The point of this exercise is to illustrate various ways that
one can provide CA services for distributed sites, using local CA
representatives at each site. Each of these approaches gets the
benefits of a local CA without making that CA a separate, visible
element in the certification path. It is important that all the local
representatives operate under the same policy and are accountable to
the same higher tier CA (or PCA in the case of residential users). It
also is important that the higher tier CA/PCA be able to track each
certificate to the specific representative who issued it, to ensure
the same sort of accountability available from a single CA. However,
so long as the CA/PCA assumes responsibility for ensuring these
requirements, then the means by which it achieves them is really a
local matter and need not be made externally visible by placing the
name of a representative/agent of the CA/PCA in the certification
path. This also permits preservation of name subordination at the CA
tiers, wihtout imposing any other constraints on CA or user DNs.