Bob,
Thanks for your reply. You focused on several points...
Reply-To: Jueneman(_at_)GTE(_dot_)COM
From: jueneman%wotan(_at_)gte(_dot_)com
To: Stephen D Crocker <crocker(_at_)tis(_dot_)com>
cc: pem-dev(_at_)tis(_dot_)com
Date: Tue, 22 Feb 94 19:33:02 EST
Subject: New directions (was: Re; FYI)
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>".
Well, there are indeed multiple issues here.
1. Irrespective of all issues of civil authoriites, etc., the
mechanics of setting up and using a parallel naming structure is an
overwhelming burden. Each of us already has a user name which we
use for e-mail. I send mail to you as jueneman(_at_)gte(_dot_)com; you send
mail to me as crocker(_at_)tis(_dot_)com(_dot_) (There are some messy
technical
details that I don't want to minimize but which are subordinate to
the main point. For example, another e-mail name for you appears
to be jueneman%wotan(_at_)gte(_dot_)com, and another name for me is
crocker(_at_)happy(_dot_)tis(_dot_)com(_dot_) These can be dealt with.)
Introducing names like Stephen D. Crocker of Trusted Information
Systems has a number of consequences. The creation and maintenance
of a separate database at each site has a cost, but that's not the
reason we're having trouble. Far more important, in my opinion, is
the difficulty of building a coherent, trustable mail system. How
do we relieve the user of having to specify the intended addressee
twice, once by his DN for encryption, and separately by e-mail name
(EN hereafter) for delivery? A directory, you say? Aside from the
added burden of building the additional mechanism, what assurance
is provided that the correspondence between DN and EN is accurate?
It's this problem that has convinced me that we have a very serious
problem, not easily remedied with better user interfaces.
2. So why was PEM ever designed with DNs in the first place? I'm not
entrely sure, but one justification I've heard frequently is that
DNs are necessary in order to provide legally binding
identification of the party sending the message.
There may be times when it's important to have such assurance, but
I don't think it's inherently necessary. In an awful lot of cases,
it's entirely adequate for the sender to know that no one can
impersonate him. Non-repudiation and/or identification in the
civil world is a separate matter, and I think we've erred in biting
off too large a step forward.
3. So why not simply permit the use of ENs? A very good idea. We've
already said we'd do this. But then a funny thing happened. The
X.DN structure is a tad too restrictive. I'm told that some of the
normal EN special characters aren't permitted in ordinary text
values. Also, it's not clear what OID to use.
Solve these two "minor" technical glitches, and we're a long way
toward a solution that retains the current structure but would
permit incorporating ENs.
(You actually suggested something a bit different, viz combining
the EN into the CN attribute of the DN. Plausible, but not trivial
to get right. There are trust issues, e.g. who owns the EN space
and how do we know the EN is correct. There are interoperability
issues, e.g. what do you do when there's no EN in the CN?)
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.
There are some other stumbling blocks before this works for EC. If
you're planning to use forms within an EDI context, presumably there
will be slots for the buyer's name, etc. What naming system is
planned for such names? Is it related to the X.509 DNs? Does a
PEM signature on the outside of the message convey any meaning about
the authority, obligation or other attribute of any of the people or
roles named in the body of the EDI transaction?
- 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.
Well, I'm certainly in a mood to junk X.509, but your point is well
taken. We have plenty of ugly protocols around. Ugliness doesn't
hurt us very much. Infeasibility, lack of a transition path,
inability to start small.... those are the killers.
- 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?
Alternatively, use the timeout scheme that DNS uses.
- 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.
Our proposed integration of MIME and PEM separates encryption and
signature; watch this space.
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.
Well, it will be interesting to see if Notes has solution to the dual
name space problem.
Steve