Ned, if I have misunderstood your position on this issue, I am delighted to be
corrected. Perhaps I was misreading some of the points that you (most
recently), Jim, and Steve Crocker and a few others have consistantly made
about
their view as to the general unworkability of the PEM certificate
infrastructure, and the necessity of supporting various alternative forms
because PEM is "broke," a "nonstarter", etc.
I only speak for myself and not my coauthors, of course. However, please note
that my coauthors have collectively spent an immense amount of time working on
implementing PEM, and remain committed to PEM development, implementation, and
deployment. They have also put a large amount of time into the MIME/PEM
specification, a specification which still requires that certificates be
supported.
If my coauthors truly believe PEM is "broke", a "nonstarter", and so on, I for
one think they are smart enough people to have directed their energies to other
area that isn't broke and is viable.
Actions speak louder than words here. I believe you are taking statements made
by various people, taking them out of the context in which they are made, and
blowing them up to huge and entirely unwarranted proportions.
You certainly are doing this in my case.
I do not believe that certificates are unworkable. I believe that they are
quite workable. In fact I believe they are essential, and that's why I feel
obliged to support them one way or another.
I am very, very glad to hear this. This is the most positive statement on the
subject that I have yet heard on the subject from the PEM/MIME authors.
I'm afraid that your saying this means your reading has been somewhat selective.
What I do believe is that the present certs-or-nothing scheme is unworkable
in
far too many cases. It raises the point of entry for PEM services to a point
many people cannot reach. This is the problem we're trying to solve.
We do this in MIME/PEM by providing non-cert-based services based on
existing
infrastructure that people can easily set up and use. Once this is in place
and
people are basically familiar with the services (and this is a major step
for
most people) the general utility of certs will become qpparent. If it
doesn't
either we haven't done our job properly or else we have incorrectly assessed
the utility of certs from the outset.
I would have preferred to implement a simpler, direct-trust model using
self-signed certificates, in the interest of parsimony, as Amanda calls it.
Hover, although parsimony may have substantial merit in the assessing the
overall security of the system, to a significant degree it is an implementors
call. If you feel that strongly that it is preferable to implement two
different models rather than use only one, I suppose I should honro those
feelings. I just wish you weren't quite so adament about not even considering
marking thoe controversial sections as implementatation options, in case
future
implementors might not agree with you.
Experience has shown that specifications are seriously weakened by having lots
of implementation options. Part of this is psychological, I think --
implementors see that Chinese menu and just assume that they are OK as long as
there's one appetizer, soup, main course, and dessert in their offering. They
don't bother to explore the higher order consequences of their choices. But
there's a definite technical side to this as well. For one thing, having lots
of optional stuff tends to conflict with interoperability mandates imposed by
the IETF process. This tends to make the IESG grumpy...
There something of a paradox here, however, in that specifications are often
strengthened by having lots of usage options! MIME is like this. You have to
implement the entire framework, all the encodings, and you have to have support
for the most basic types. You have to support nested objects even if, say, your
implementation never generates nested objects and they are meaningless in your
operational context. Part of the problem this addresses is that implementors
are often pretty lousy at figuring out what their code is actually going to be
used for.
This last point is PEM's problem in spades. We all have some ideas, usually
couched in the form of various hypothetical examples, of how PEM services will
be operationally deployed and used. But we're just guessing. We really have no
idea of what is going to happen out there. It is possible that people may flock
to the cert stuff at the outset. It is also possible that viable cert
structures will never develop to any significant degree. The one sure thing,
however, is that there will be uses for these services we have not thought
of at all.
MIME offers excellent examples here as well. When we designed MIME our goal was
to provide multiple parts and typed object support as a service that could ride
inside of RFC822 mail. And that's all we were after. It seems clear now that
this was quite possibly the least important thing we actually did. The
establishment of a general media typing and parameterization system for the
Internet was vastly more important. (I wish we had realized this sooner -- in
particular, I wish we'd insisted on a hierarchical subtyping scheme. We had one
at one point, but people said it was too complex so we took it out. Big
mistake.) And so was something we saw as nothing but a cutsey idea at the time:
The notion of a "pointer part" containing information on how to retrieve the
real thing. These two things have been extracted from MIME and now form the
basis on which the Web operates. (Actually, I believe the notion of a URL was
arrived at independently, and in any case this pointer concept was definitely
an idea whose time had come one way or another.)
Building services where you don't understand all the potential uses is tough.
Its especially tough in the security area, where the nature of the services are
such that unexpected uses can actually compromise the intent of the design.
Nevertheless, these are the sorts of services we tend to build in the IETF.
The only alternative that has been presented is to use self-signed
certificates. But there are two major problems with self-signed
certificates:
(1) All you get rid of is some of the infrastructure requirement, so the
resulting point of entry is still far too high.
I don't think agree at all, but I'm willing to take this particular issue off
the table, at least for the purpose of the present discussion. Either offline
or online I'd like to discuss with you exactly what your views are with regard
to a desirable or acceptable distinguished name, for I simply don't understand
your point of view.
Well, the problem here is that I don't have a particular view. I'm not allowed
to have one! My customers are the ones with views about how they want to name
things. My job in this context consists solely of looking at their goals,
looking at their proposed solutions, and using my knowledge, experience, and
common sense to tell them whether or not their solutions are viable. Since
different people end up having what amount to othogonal if not completely
contradictory goals for DNs it is next to impossible to come up with "one
size fits all" solution to recommend.
My critique of of your email addresses in DNs example was exactly this -- we've
had cases where customers didn't bother to outline their real goals and needs,
they then made design choices in setting up X.500, only to find that the entire
thing was completely unworkable. In effect what I did was assume certain common
goals people often have and object to your example on the basis of those
goals. This does't mean that someone with different goals won't find your
specific approach useful. On the other hand, it may not make any sense at all
for lots of people to use RFC822 addresses in any form in DNs.
(2) Use of self-signed certificates makes the actual benefits of
certificates
very confusing. In the present MIME/PEM scheme certificates and their
associated infrastructure clearly provide a quality of service that
non-cert
schemes do not, and allow implementation of policies that non-cert
schemes cannot support. But if you use certs to provide the lower level
of
service people will not be clear one what the benefits of certificates
really are.
This is a fairly compelling argument. I think what it really comes down to are
the details of the implementation -- what is said in the reference manual and
the help screens, and what kinds of warnings, etc, may be displayed in various
circumstances. I had hoped that a direct trust, self-signed certificate would
have been flagged in such a way as to make these limitations (if any,
depending
on your point of view and who you got the certificate from) perfectly obvious,
but these are implementaton details that perhaps cannot be specified in a
spec.
As you suggest, at least the non-cert schemes should be obvious by their
syntax, etc.
Exactly. And the presentation issues here can be very subtle. For example, you
absolutely must avoid throwing a bunch of nonsense at the user all the time. Do
this and the user will stop reading the nonsense (they tend to do stuff like
iconize the window it appears in...) and when there's a real problem they will
not notice it!
I strongly recommend that anyone interested in these sorts of matters pick up a
copy of Nathaniel Borenstein's "Programming as if People Mattered". I may be
biased since Nathaniel is a friend, but I see this book as nothing short of the
sequel to the classic "The Mythical Man Month" that Brooks never wrote.
I had in fact hoped to provide some advice in this area as part of MIME/PEM,
but this is one of those points where the working group clearly didn't want
to see this sort of thing in the specification. The point is valid --
specifications should be technical descriptions of protocols -- but I worry
a lot about implementors doing terribly wrong things in this area.
On the other hand, we have been learning that there are a number of less than
obvious privacy concerns, etc., that might influence the choice of a DN a
non-monoply X.500 directory service provider environment, and perhaps these
need to be explored. I have recently begun to rethink my postion on what out
to
be in a DN once we get to v3, and would welcome the opportunity to discuss
this
with you in a clamer, longer-term environment.
I would welcome such discussion. Part of what's missing from current X.500
deployment is consideration of what needs to be in a DN to fulfill the needs of
security infrastructure. Most current deployment focuses entirely on providing
white pages services (in fact a lot of it is used to provide distribution and
synchronization facilites while the actual service is delivered via a separate
proprietary system) and it isn't clear to me that the requirements of other
uses are being addressed adequately in current schema designs.
Let me also say that I think there is an excellent chance that MIME/PEM will
fail, although for none of the reasons you have ever mentioned. For one
thing,
we are very very late in this endeavour. There are already other formidable
players in this game that we have to confront, and there is no clear
indication
that we will win. And for another, it is not beyond possibility that I am
wrong
in my assessment that certificates as currently specified are an essential
service that people really need. If they aren't this whole effort is going
to die.
It's not clear to me who those formidable players are, or that we are
necessarily opposed to them.
Clipper is what worries me the most. Like many other people I tend to dismiss
Clipper because of the infamous things it embodies, but you never can tell
about what people will or will not buy, especially when it comes to
computer hardware and software!
X9 and X12 have their constituencies in the
banking and EDI community, but they haven't yet come close to fielding an
effective, broad-based system.
It is going to be interesting to see what the various digital cash services do.
Some of them, like First Virtual, appear to be devising systems where security
can (arguably) be ignored. Others are using rather specialized mechanisms such
as anonymous cash (I worry about the possibility of someone getting a copy of
the bank's private key in these schemes, which would effectively give them the
ability to print as much money as they want). And others are going with PEM and
other (dare I say it) "traditional" security services.
I am beginning to think that there is a real
possibility of PEM and PGP converging, and ultimately I think PEM and PKCS
will
converge as well. DMS has a substantial follwing, in particular because Lotus
and Microsoft cannot afford to ignore those opportunities, but it seems
somewhat unlikely that everyone is going to embrace the Tessera cards after
the
Clipper chip controversy.
Exactly my feelings as well, although I cannot entirely shake the notion that I
(and you and lots of other people) could be wrong about some of this.
I've ben trying to do this kind of stuff for 10 years, and I get a little
frustrated, but I think the gernal public is just beginning to be receptive to
the entire notion. In general, I think that the user community is still
waiting
for that killer application to put encryption and digital signatures on the
map.
Electronic mail, with or without MIME, may or may not be that killer
application -- it's hard to predict. My own view, at least up until November
8th, was that it would be health care benefits and insurance claims filing,
but
now I don't know. Ask Newt or Hillary (Hillary who?)? :-)
My personal take is that email is probably not the killer app here. Some
email-based service may be, but personally I'm betting on whatever the Web
evolves into to be the killer app. (As Dennis Miller says, its just my opinion
-- I could be wrong.)
Ned