Date: Mon, 15 Nov 93 10:07:37 -0500
From: Steve Kent <kent(_at_)bbn(_dot_)com>
Ray,
I'm puzzled by your statement about a problem with residential
PCAs and CAs with regard to name subordination. I had hoped that one
of the many note I sent a week ago, when I finallly crawled out of my
mail hole, had clarified how residential PCAs were supposed to work.
The "trick" is for a residential PCA to establish placeholder CAs for
appropriate geographical CAs, e.g., states under C=US. That way the
name subordination rule still applies since users can be registered
under a CA with an appropriate name. I reproduced the Paul Revere
example from 1422 to illustrate this point. Is there a residual
problem?
Steve
There's something funky about the UUCA in that it doesn't fit strictly under
the Internet PEM hierarchy (assuming the high assurance Commercial CA
will be a PCA) since it issues certificates to subjects not related to
it DN wise.
That's correct. In the last days before the PEM standards became
final I lobbied hard to remove this restriction or make it a policy
decision. Our decision to break this rule may have some far reaching
consequences, however, we feel that it was the right decision given
the alternatives. For the record (I'm sure we will get asked this
again) I will justify our decision. In order to adhere to the
subordinance rule for residential or unaffiliated users, we would have
had to follow one of these models:
Plan A:
Assume one of the following issuer names:
C=US
-or-
C=US
S=California
-or-
C=US
S=California
L=Belmont
in order to have the subordinance rule work for a name like:
C=US
S=California
L=Belmont
CN=Steve Dusse
One of the most important requirements in our hierarchy is that each
CA shall show proof of the "right to use" their DN. Well, C=US is
already taken (by ANSI). Since we couldn't secure such right from
each of the states and localities (much less even educate them about
the concept) we ruled this out.
Plan B:
Assume an issuer name like:
C=US
O=RSA Data Security, Inc.
OU=Unaffiliated User Certification Authority
and sign up subordinates like:
C=US
O=RSA Data Security, Inc.
OU=Unaffiliated User Certification Authority
S=California
L=Belmont
CN=Steve Dusse
This works with the "right-to-use" rule as well as the subordinate
rule. Unfortunately it breaks the aesthetics rule, looks like an
affiliated certificate (everyone works for RSA) and also makes every
residential user DN look like an advertisement for RSA Data Security
(this works for me but not for our AOCE friends).
So we decided to break the subordinate rule. Strictly speaking, PEM
compliant implementations have every right to complain. This will be
very carefully documented in our COmmercial CA policy statement and
has, in fact, been a major reason for our reluctance to even publish
this statement.
I hope this answers your questions. I apologize for the slow response
on the Commercial CA key and DN, we have been waiting to get the key
holders together to issue the self-signed cert, it sounds like you
already have the info you need.