Slow down a bit, John. Take a deep breath, and read
what I said again.
Your certificate syntax fails on several counts, it surely fails to
act as an extension to 1992 certificates by leaving out the UIDs
which other more mature specifications (X9.30 for example) make
use of !
Not so. I specifically replaced the UID from the '93 version with a
SEQUENCE of attributes, and mentioned that one of those attributes could
certainly be the existing UIDs.
1) You continue to allow DNs for identification purposes but suggest
that perhaps they be kept "minimal". I don't understand, do
you want to retain DNs or not ?
Yes, I propose to retain DNs. But now, by virtue of having some other
place to hang useful attributes, we don't have to overspecify the DIT
with leaves that don't really add qualification. In other words, many
of the hacks that have been proposed to be added to the DN can now
be mere attributes, and the DN can be limited to the more or less "pure"
civil naming authority rules. (I say more or less, simply because I am not sure
to what extent the NADF and others have agreed upon those rules as yet.)
2) You specify an extension to the certificate syntax without
consideration of the purpose or semantics.
a) Why are arbitrary attributes being BOUND IN with
a key certificate ? Why can't they exist as
separate (dare I say MIME-like or X9.30) objects ?
b) Who assigns them and why should the recipient believe
them ? Who assigns the CA's attributes, ad infinitum
... ?
c) How are these things revoked ? What is the mechanism ?
Do they expire ? What if the authority of the issuer
is revoked or expires ?
On the contrary, I have thought about it a lot. You have the right to disagree
with me, but please don't say that I haven't thought about something.
I am binding in those arbitrary attributes that come under the auspices of the
CA that is issuing the certificate, so that the CA and/or the user can provide
necessary information that won't fit elsewhere. to my way of thinking, the
problem with the X9.30 types of attributes is that they provide no way of
EXCLUDING certain types of operations -- no jokingly named caveatEmptor
attribute if you will. If you lose or never receive the X9.30 certificate,
who would know?
I think it would be obvious from the syntax that SIGNED applies to the entire
certificate. So I don't care who assigns them -- only that the CA is willing to
endorse them. Same as the user's name and other attributes presently carried
in the DN. the recipient should believe them for the same reason he believe
anything else the CA signs -- because he has decided to accept the trust model
implied by the PCA's policy. A CA that is reasonably prudent is not going to
sign
something that he might be liable for that is not under his control.
The CAs attributes, if any, are signed by the PCA. Who _assigns_ them is not
particularly important, unless I am missing your point.
The certificate revocation mechanisms would continue to operate exactly as they
do today (or at least they way they are supposed to work today.) The
certificates
would expire in exactly the same manner, as implied by the validity dates. If
the
authority of the issuer is revoked or expires, obviously the certificates issued
by that authority can no longer be considered valid, but as is the case today,
messages signed prior to the revocation would still be considered to be valid,
assuming that a relaible timestamp or other nonrepudiation mechanism was
in place.
3) You can't really think that the "end-to-end" certificate
discovery process is going to scale well ? (Then again ...)
Talk about cumbersome ?! How is it going to be managed ?
Actually, I do think that it will scale pretty well, because most users have a
very
limited set of people that they correspond with. Long before I ever get to the
point
where I want to send something encrypted to someone, I have corresponded
with them or been introduced by a mutual friend. At that time we can exchange
certificates. Of course, if I were concerned that someone out in the Internet
was trying to spoof or alter my messages, I could have signed all of my messages
and thereby provided the necessary certificates to my (potential)
correspondents.
But I would rather not be flagellated for positing the basic PEM certificate
distribution that is to be used prior to X.500 becoming available. I didn't
invent
it, nor am I saying that an X.500 scheme (if it is ever deployed and works well)
wouldn't be a far better solution. By the time they get through with all of the
various inquirys and synchronizations, it might even use less bandwidth and
provide faster response time, but I am not holding my breath.
4) Why are you suggesting a new syntax without (admittedly !) studying
other existing works ? Surely you don't think you are the first
to encounter these problems or that this problem is so unique
that other architectures have nothing to suggest or offer ?
I'll bite my tongue and try to be polite in responding to that. I'm sure that
you
don't care, but my efforts in this arena are a labor of love because I think it
is
important. It is not my primary assignment. That wouldn't excuse my being a
diletante, yacking about something I know nothing about, of course, but I hardly
think that is the case. I just don't have the time to go off and do a Ph.D.
thesis
comparing all of the various standards and pointing out how all of them could
be
improved.
I am frank to admit that I haven't the time to read all of the other works in
this
area, but I do talk frequently to several people who are involved in X9F1, I
have
attended EDI conferences on and off for a number of years, and I try to at
least
keep my finger on the pulse of what is going on. I am also trying to come up
with a pragmatic solution to these problems, instead of suggesting that we
throw everything away and start all over (or quit.)
I don't know whether I was the first to encounter these problems, but it does go
back aways. I would certainly not be so arrogant as to suggest that we all
couldn't
learn from other architectures, and that is the point of making such
contributions.
In particular, I have raised the point a number of times that all of the various
standards organizations tend to go off and solve their own individual problems
with a certain amount of disdain for what other groups may be doing. I think
that the Internet group is as guilty of that as anyone, and the PEM group in
particular. Unfortunately, there is no one with a sufficent amount of clout
at the national level to force these various standards efforts to converge.
I would be happy for you or anyone else to suggest substantive, definitive
changes to address the basic problem that has been repeatedly discussed
on this list, that being how to build up the utilization of PEM and solve a
number of the real life problems that a variety of people have pointed out,
without totally wrecking X.500, X.509, PEM, or various other system. I
believe that my proposal is serious, well crafted, and a reasonable extension
that will solve those problems, but I am always willing to listen.
As far as I know, X.509 '93 is on the table, and although it has not yet been
ballotted, it is already too late to propose any further changes. I am not
certain
of the official status of X9.30, but so far no one in the PEM community has
made a serious proposal to adopt it, in toto or in part. If you would like to
make some recommendations along those lines I would be happy to review them.
Bob