Steve,
Welcome back to Locality=Cyberspace, and congratulations
on an outstanding summary of the reasons why we are here.
I only wish you had digitally signed it -- its length might have
lead someone to think it was from me. :-)
I agree almost entirely with the general thrust, but would like
to offer a few comments:
1. Support key management for confidentiality (encryption).
I think you should have included a stronger statement, along the
lines you have spoken to in the past, of clearly and unabigouously
identifying the intended recipient of a confidential message
before spilling your innermost secrets to the wrong person. A
simple Diffie-Helman key exchange will allow any two people to
exhange mail that no one else will be able to read, but
how do you know that the person on the other end is who
he claims to be?
2. Support key management for data origin authentication,
integrity, and non-repudiation (digital signature).
I agree that full non-repudiation is much more difficult than it
might first appear, in particular because it involves issues of
trust and evidence that are eventually resolved by courts and
juries, not computer programs.
Protection against modification (integrity), authentication of data
origin (attribution), and ultimately the "provenance" of complex
objects is extremely important. PEM is addressing some of these
issues now, and other extensions will be required to handle the
more general problems. But it is of paramount importance to
establish a national or international public key infrastructure
that can support the basic capabilities, without requiring a new
structure for every new application that comes along.
3. Scale to accommodate hundreds of millions of end users, and
millions of organizations.
You could have added words like "mutually suspicious," or at
least a multiplicity of trust relationships, with no single
being sufficiently trusted by all parties as to act as a common
guarantor.
4. Provide descriptive naming or a wide range of entities as part
of the authentication facility.
The fundamental prupose of a public-key certificate is to
bind a name to a public key.
Actually, I think that Marshall Rose contributed a valuable insight
in this area. The purpose of having a CA sign a certificate, as
opposed to the user signing it himself, is to reliably bind the
public key to the ENTITY whose name appears in the certificate.
Most people, upon reflection, agree that names in certificates
should be globally unique and that the names should be
capable of identifying a wide range of entities.
The NAMES should be globally unique. The ENTITIES identified
by those names should be globally unambiguous. Even without
considering the metaphysics of roles, different addresses, etc.,
people can validly have different names and contexts --
Mrs John Jones vs. Judy Jones, for example. But the person
is the same. The difference is that we can use an unambigous
identity certificate to grant access (or some other capability)
to someone, but we can't reliably use such a certificate
to _deny_ a particular individual access, unless we identify
the entity in a manner that really is globally unique (e.g., tied
to birth records, fingerprints, DNA encoding, or the like).
Moreover, to suport the rapidly-growing Internet community,
the globally unique, flexible names in certificates should be
capable of being assigned in a distributed manner.
The creation and/or registration of names has to be carried
out in a distributed manner in order to satisfy the scaling
requirements. This isn't a problem if names are created, assigned,
and/or registered by organizations which include their own
name in order to meet the uniqueness criterial (fully-qualified).
It is a considerably more difficult problem if names can be
registered by competing name registration authorities, i.e.,
using a state and locality qualification can reduce the
probability of a collision in the name space, but unless the
name registration authorities (e.g., X.500 directory service
providors) collaborate to protect against duplicates, this
cannot be guaranteed. Hence the use of the IPRA Residential
person database, and hence the use of the CAN facility
within the NADF to provide the knowledge of which DSA actually
contains knowledge about a particular name/entity.
To avoid ambiguity, and to minimize the likelihood that a
user or a system administrator will accidentially confuse two
names, names appearing in certificates should be "descriptive,"
but the descriptiveness of a name is context sensitive.
This is not without its problems. The mapping of directory listing
names to certificates can be many to one, and the mapping of
distinguished names in certificates to the public/private key
pair can also be many to one. The problem becomes even worse
if we insist on incorporating message routing/addressing
information in this process.
For example, a person
whose name indicates affiliation with an organization may be
accorded explicit access privileges based on that affiliation,
i.e., being viewed as a member of the "group" defined by the
organizational name. For some applications, it would be very
simple and convenient to establish access control list entries
that grant privileges to groups of users based on certified name
syntax and "wildcards," as well as individual user entries. So,
in some sense, one cannot help but embody some degree of
authorization information in a descriptive name.
True, and well said.
However, not all access control is best based on identity,
and there are practical limits to how much authorization
information should be bound into a certificate that is designed
primarly for identification. Specifically, there is a limit to
the scope of authority of any individual certificate issuer and
this constrains what should be certified by that issuer. Also,
including more attributes in a certificate generally increases the
likelihood that the certificate will have to be revoked prior to
its (planned) expiration. It is especially inappropriate to
include attributes that vary widely in their expected validity
duration, unless the overall certificate validity is set to the
minimum of any of the attributes (because of the likelihood of
creating circumstances that will result in revocation). A
certificate, whether used for authentication or authorization,
should have a validity interval commensurate with the expected
validity of the attributes it binds together.
I agree, probably to some people's surprise.
5. Accommodate anonymous, but authenticated, email exchange,
signed object posting, etc.
However, it is also important to prevent digital signature facilities
from being abused in a fashion that could erroneously indicate
authorship by someone who did NOT wish to be declared an
author.
I agree, and I am sometimes concerned that we may not
sufficiently differentiate Persona certificates from "real ones".
Perhaps we should review the name subordination requirements
here?
<<To be continued. This message is getting too long. >>
Bob