Steve,
You listed several possible "new directions", and I think there is merit
in several of them:
- complete separation of the legal notion of identity from a network
identity based on e-mail names.
This seems to muddle several different notions. I perceive that you
think that setting up the administrative aspects of a CA is too hard,
particularly in view of the name subordination requirement and the
arguable implication of a deep-pockets relationship between the CA
and the user. If that is your concern, why don't you set up a PCA that
similar to the Persona CA, and simply announce that you will allow the
use of DNs within certificates that follow extremely simple naming
conventions, e.g., CN="Stephen D Crocker <crocker(_at_)tis(_dot_)com>".
No country is listed, so by implication this CN is rooted at the ITU root,
above the level of country. This isn't really a problem, because
we can state that it is our intent that the Internet Society register an OID
at the root that would identify this as an Internet address. And until
all of the diplomats make that happen, we can just cheerfully ignore/violate
the implied DN schema, since we now know that the DIT rules (if any) don't
apply to the DN within the certificate in any case. We would also abandon
the name subordination rule, but any PEM application is allowed to do that
as a local or implementation matter in any case. (PEM prescribes certain
things, but doesn't proscribe anything.)
Of course such a common name may not satisfy my electronic commerce criteria
of "where do you send the sheriff", but my assumption is that you don't care
about
such issues while we are still trying to get the basic system up and running.
So such a name might not be admissable within the RSA Commercial
Hierarchy, but that's OK for certain applications.
- separation of the certificate infrastructue from the ability to use
PEM, i.e. the ability to get going without a hierarchy and be
spliced in later.
I agree, and I think we have seen enough discussion to see how this could be
possible. Use RIPEM or PGP with self-signed certificates, then add CAs,
then add a PCA to provide global exposure to your certificates if that is what
you
want to do. Ignoring some valid quibbles about the trustworthyness of a
particular
bit in the certificate store, it appears that TIS-PEM would already support
these
concepts.
- possible abandonment of both X.500 names and ASN.1 encoding.
I don't think this is feasible, unless you are prepared to junk X.509. The use
of separate attributes and ASN.1 provides for easier (not necessarily easy)
extensibility. X.500 DNs can be of almost any format, not just the civil
naming authrotiy structure that is currently most popular. If you can
get someone to even think about supporting a version of PEM without X.509,
supporting a new attribute type should be a piece of cake by comparison.
- reconsideration of the role of CRLs.
I tend to agree here. The more I think about it, I think that the scheme Sead
Muftic
and I came up with is perhaps superior, except that it requires an online
responder.
That idea was to simply send the message in question to the CA, which would
provide
an ex cathedra answer as to whether the user's certificate was valid as of the
time
the message was received. the argument that this would expose the CA's public
key to network attacks is not valid, since a different key could be used for
providing
such assurance. Alternatively RSA provides a voice response unit. You
simply punch in the certificate serial number, and it tells you whether it is
valid or not.
It doesn't solve the problem of nonrepudiation, but so what?
- separation of signature and encryption algorithms
I heartily concur. One of the dumbest design decisions we made was to use the
same
key for both encryption and signature. Just because the RSA algorithm COULD be
used
that way. Other algorithms don't support such capabilities, and multiple
algorithms should
supported for compatibility with other systems such as MSP. And while we are at
it,
let's make sure that we have the ability to sign an document first, then
compress it,
and finally encrypt it.
However, I don't want to be accused of trying to derail the existing PEM
implementations before we have even given them a chance. If and when Lotus
Notes starts using PEM, some of these problems (but not all of them) will go
away because of the large community of users.
Bob