On Tue, 7 Feb 1995 Jueneman(_at_)gte(_dot_)com wrote:
OK. How's this for a concrete proposal (subject to management approval, of
course);
[...points deleted...]
It's a nice offer Bob, but I suspect that without the following it will be
yet another non-starter:
8. GTE will write source code for accessing the directory to get
certificates and make the source freely available to PEM implementors
as a reference implementation. Alternatively, GTE will provide pointers
to _freely_ available documentation on how PEM implementators can write
their own access code from scratch.
Gee, talk about looking a gift horse in the mouth! :-)
The original question (from Sead Muftic, as I recall), was what the IPRA
intended to do about resolving name conflicts between PCAs, especially for
residential and persona users. I offered to solve that problem, and threw in
offer to store the certificates as well.
But I do not have the resources, the desire, or the intent to write public
domain source code to access the directory, especially when there are a number
of both commercial and public domain implementations of DUAs already available.
Tim Howes <tim(_at_)umich(_dot_)edu> and Mark Wahl would probably have more and
better
information about public domain DUAs, but MAX500 might well serve your purpose.
Also, as I indicated in the message, I hope to support a web browser interface,
but until I have more details from DEC I can't promise anything.
It's all very well to put the information in the directory Bob, but we also
need a way to get it out. Without that, I cannot get very excited about
your proposal. And don't bother pointing me at QUIPU or any other
full X,500 implementation. I'd rather not have to link in all that and
screw my application up into knots just to get the following functions:
void GetENCertificate (char *emailAddress, X509CERT *certificate);
void GetDNCertificate (X500DN *name, X509CERT *certificate);
QUIPU is a prototype Directory Service Agent. It is not appropriate for use as
a Directory User Agent, and I wouldn't suggest it. I mentioned it initially
when you said that you would prefer to run your own directory server, rather
than rely on anyone else to do all of the dirty work (like setting up access
controls, deciding schemas, worrying about whether your county's data privacy
laws prohibit including such personal attributes as photograph or favorite
drink -- as the Paradise people found out).
But, don't let me discourage you. Set it up. Right now in fact. Load
the RIPEM key database into it for a start. Then get your GTE buddies
onto the source code project. Then worry about all the policy problems,
legal niceties, etc. If it is great, everyone will support it. If it is
hopeless or overly complex to access, it will go nowhere. That's the way
the Internet works. Cest la vie.
I'd like to hear Vint Cerf's reaction first, and perhaps get a sense of some
support from the potential PCAs and CAs before I launch into such an effort.
To show that I'm not all negative, I'm still looking at LDAP for accessing
certificates and will make my source available. But I'm very quickly
coming to the conclusion that LDAP is a dead loss, even if the stringised
certificate problem can be solved. I suppose I'll have to fork over the
A$500+ for the OSI standards after all to figure out how to do DAP. :-(
Unfortunately, "freely available" does not necessarily imply "available for
free." I wholeheartedly concur that the ISO/ITU standards community is doing a
disservice to the technical community by not making their standards available
for electronic access. Maybe you ought to write to the Australian Department of
State or the equivalent to address the ITU issue, and to the official
Australian representative body to ISO, and get them to change their policy. :-)
Your concerns about the utility of LDAP are somewhat more disturbing, however.
Tim has offered you a vehicle to fix any problems in that area as LDAP goes for
standards approval, and I think you should take him up on it by pointing out
the problems you perceive.
Normally, such a discussion would probably be better taken offline, but because
of the interest in the pem community maybe the bandwidth would be well spent.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820