Rhys,
I also felt that many of these issues had been resolved, but absent any decent
feedback from the last IETF meeting it hard to say what is going to happen to
PEM.
Your point about the difficulty in bootstrapping this effort, even in the
business
community, is perfectly valid. Buying in to the "official" use of the corporate
name
is fraught with educational and other battles, and I can show you some of my
scars
some time. The same is true of those users would be prefer to be relatively
unaffiliated with a particular organization, but just want to converse with
privacy
and/or authentication on their own, personal, authority. Lastly, until some
additional refinements occur on the legal front, there are probably more than a
few
users, including myself, who would like to limit the extent of nonrepudiation,
so
that a moment's carelessness with emerging technology doesn't end up ruining me
financially.
Several, and perhaps most, of these considerations can be met by using common
name
and the rfc822 e-mail name attribute as the primary components of a DN. This
requires breaking the rule in the RFC that insists on name subordination, but
Ford
had a better solution to that problem anyway with his CAname proposal.
The next trick will be to find a CA or PCA that would sign such a certificate. I
thinkt that several have already offered to do so, with a medium-low level of
assurance being implied as is appropriate. If the necessary infrastructure to
support this hasn't been put together in your country or elsewhere, then I would
revert to using a self-signed certificate. Or create three certificates and set
up
your own PCA and CA, if you feel so inclined! But I think that some small
number of
low assurance, confirmed only by returned e-mail PCAs is probably the way to go.
The technical problems that will be encountered will be in writing the code
necessary to generate a certificate containing the rfc822 attribute, but that
shouldn't be too difficult if you can generate any kind of a certificate now.
The
second problem will be to make sure that user's UAs don't blow up when they see
an
attribute they don't know how to handle, but the RFC specified that in such
cases
they were to print it out as best they could. The name subordination check,
like
other checks, should be advisory only, and not disabling.
Assuming that this doesn't preclude the adoption and use, perhaps later, of a
more
formal naming structure for organizations and organizational persons, I would
strongly support such a plan.
In fact (new thought), the more I think about the problems of setting up
directory
service for residential persons, given that there may be multiple e-mail
providers
competing to provide service and no natural monoply within a state, having a
name
component that would be guaranteed to be unique would be nice. Since there is no
penalty for false swearing before a notary in the US in a civil matter (except
in
the state of Florida), even having a notarized application doesn't do much
good. At
least CompuServe knows whether you are still alive or not (assuming that you pay
your monthly bill), which is something the post office occasionally has trouble
with. So until residential persons start buying things electronically using only
their digital signature, and maybe even then, an e-mail address may be almost as
good as a postal address, and maybe more accurate. If all else fails and I want
to
send the sheriff after someone, I guess I could subpoena CompuServe for their
records. (Whether I could do so for a civil matter isn't quite clear to me,
however).
At least it should be reasonably clear that someone who signs a document using
their
e-mail account as part of their DN is not doing so as an authorized agent of
that
particular company, and there are some advantages to that.
I've been trying to write a naming guideline for CAs since before January, and
I can
never find the time to work on it. But I intend to incorporate some of these
concepts in it, as well as providing for DUNS numbers in the DN for EDI
applications.
Valdis Kletnieks wrote:
I think the correct phrase here is "violently in agreement". My point was
exactly that you won't get this stuff to fly until you have all the support
for all this in at least 1 or 2 true "Killer App" UA's. Unfortunately, this>
means you have a pretty nasty chicken-and-egg problem.
It is truly unfortunate that the original PEM reference implementation didn't
include support for an X.500 DUA, which would have been far more important than
the
current MIME extensions, I think.
We also have a chicken and egg problem with X.500 itself. The NADF is limping
along
without any real sponsorship -- it isn't even a formal organization, much less
incorporated, the funds for Paradise have been cut, and so far no one has shown
a
sufficient business case to make peole get excited about offering such a
service.
But there are a number of commercially viable X.500 implementations now
available,
and with products like Lotus Notes moving to be interoperable with them perhaps
it
will pick up some momentum.
I keep asking, "If GTE were to provide a public service for posting X.509
certificates and related information in an X.500 directory, would anyone be
interested?" but I haven't yet gotten a reply from anyone, even when I hinted
that
we might to it for free for a year, just to have something to evaluate!
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM