(Continued from the previous message, responding to Seve Kent's.)
6. Accommodate different levels of user and organization
authentication, and related security procedures.
While accommodating this diverse range of certification
rigor, it is necessary to make explicit the context in which each
certificate is issued, to avoid surprises for users. Schemes that
fail to include explicit declaration of certification policies and
procedeures, so that users can engage in informed evaluation of
the semantics of certification, create the potential for users to
be confused, if not duped.
Of all of the various contributions made by the PEM community,
I think one that we can be the most proud of is the notion
of a Policy Certification Authority, with a published policy. It is
my hope that eventually the various PCAs will each form the
nucleus of a user's group or even consortium, where all of the
user's within that group agree to be bound by a common policy.
Unfortunately, some implementations of digital signatures came
into being prior to this concept being elaborated, notably
the Apple AOCE software. Although RSA has signed and is
signing agreements with the CA's (and more or less implicitly
with the user's registered by those CAs, in that they impose
certain requirements on naming an didentification), at the present
time there is no mechanism to tell the RECIPIENTS of an AOCE-
signed document what the policy was that governed that
signing.
I am therefore in the process of discussing with Jim Bidzos and
George Parsons some minor changes to the "RSA Requirements"
section of the contract they have signed with their CAs, which
will require they they notify their users of the existance of
the Commercial Hierarchy PCA, and in particular the existance
of the policy and hwo to obtain it.
7. Operate across national boundaries
The Internet is international in scope. Any certification
system that is intended to serve the entire Internet population
must, therefore, operate on an international basis. This implies,
for example, that more than just Latin character sets must be
supported in certified names. Semantics associated with the
structure of names should not be encoded using words from any
individual language, e.g., English. Thus, for example, an entity
that is a PCA should be identifiable through structural or
syntactic rules, but should not require interpreting the name in a
specific language.
I agree strongly, both with the requirement to support more than
just the English-centric PrintableString set for DNs (it isn't even
good enough for English, much less other languages), and with
the notion of capturing the semantics of a PCA through
structural or syntactic rules, not just a PCA name. Unfortunately,
some of the more reasonable proposals for doing that, such
as creating a caName attribute that could be included in the
X.509 certificate structure have fallen afoul of the natural desire
not to change anything, and especially not something as
arduous to change as a CCITT spec.
8. Provide a certification structure that is easy for end users
to understand.
Aye, there's the rub!
If a user has to evaluate a certificate (or a certification
path) directly, the semantics of the evaluation must be clear to
even naive users, in keeping with the growth in the Internet user
population. The amount of data displayed for a user must be kept
to a minimum, so as to avoid overloading the user with information
that will likely be ignored.
If there was an error made in the development of the PEM RFCs, I
would say that it was in the area of focussing too much on the
issue of syntactic validation of the signature chain up to, and then
back down from the IPRA root; and not enough on undertanding
the TRUST implications of that chain. In addition to some of the
ease of use issues, systems like PGP have taken off, IMHO, because
the users have a clearer conceptual model of what it means to
trust someone, and a cleaner way of expressing that trust, than
in the PEM RFCs. In part, this is because of a reluctance to
specify implementation criteria and features, such as how to control
the user's cache of trusted keys.
PARTICULARLY if we believe that the user will soon grow complacent
with the validation of signed messages, we need to insist on two
implementation requirements:
1. That the normal or default case should be to validate a signature
before presenting a message, even if it is MIC-CLEAR format, so long
as it is signed. The user's won't click on a key to get confirmation
of the message's integrity.
2. The user should be permitted to control which users, CAs, and PCAs
are normally accepted without question or comment, highlighted for
further review, or rejected as probably insufficiently trustworthy.
These setting should all be subjected to override, of course, but
we are talking about _routine_ actions. The user is simply not going to
validate a message's integrity every time, unless we make it as painless
as possible.
9. Support distributed name assignment
The names that appear in certificates should be capable of
being generated in a distributed fashion, i.e., with minimal
centralized coordination. Some centralized coordination is essential
to avoid name conflicts, but hierarchic structuring of names minimizes
the need for such coordination. This is easily accomplished using
schemes like the DNS as well as distinguished names.
We discussed the need for distributed name registration earlier.
But I disagree with the use of the Domain Name Server for this
purpose, for I believe that it unnecessarily confuses the issue
of addressing and routing of mail with the authentication of
the user.
One of the great things about PEM is that it is not dependent
upon the form or even the existance of a network. I can sign
a file on a floppy disk and send it snail mail, and the signature
can be validated just fine. Now granted, the DNS may have a role to
play in _distributing_ the certificates, depending on your view
of the viability of X.500, but I think it would be a serious mistake to
insist on the use of DNS names as the the names contained in the
certificate.
10. Minimize management overhead.
Each CA (in a generic sense,
i>ncluding PCAs) in a system has to deal with the entities it
certifies, and with with any entities from which it seeks
certification. The former category is under the control of the CA,
i.e., it decides how many users or organizations it will certify, and
is a natural function of the scope of the CA. However, in order for
the users certified by the CA to have connectivity to a larger
context, the CA must seek certification by other CAs. Each other CA
with whom the CA must enter into some sort of certification (or
cross-certification) agreement, whether formal or informal, increases
the management overhead for the CAs involved. Hierarchic systems seek
to leverage that management overhead by minimizing the number of other
CAs with whom certification arrangements must be executed.
I agree. That's why I would like to see the evolution of some relatively
small number of PCAs serving as the nucleus of a user's group of users
who agree to follow a ocmmon set of policies, not just when
signing somethng, but when validing such document as well.
If the PCAs are unable to articulate such mutually beneficial
arrangements for their clients, we will have to move toward the use
of central clearinghouse arrangements, where customers are bound
by the clearinghouse to accept each other's signature as binding.
Bob