this x.509, pki, etc was outgrowth of the iso x.400/x.50x stuff ... that was, in turn, continuation of the iso osi stuff.
i don't have a lot of references to the x.50x stuff from the 80s. i was involved in trying to get hsp (high-speed protocol) standards work accepted by x3s3.3 (iso chartered us standards group for networking related stuff). remember that this iso osi stuff was being mandated by a number of govs. (including us federal) along with mandates eliminating tcp/ip and the internet. now, i've stumbled across some old email from 85 era discussion public key and digital signature technology ... but can't find any specific on PKI and x.509. however the x3s3.3 stuff with relationship to iso was interesting. iso had some mandate that standards work woujldn't be accepted for stuff that violated the osi model. http://www.garlic.com/~lynn/subnetwork.html#xtphsp unfortunately, hsp 1) went directly from the level4/transport interface directly to the LAN/MAC interface ... bypassing the level4/level3 (transport/network) interface. this violated osi model and so couldn't be considered for iso standards work 2) support internetworking protocol ... aka the stuff that allowed the internetworking of different networks. internetworking doesn't exist in the osi model ... so supporting tcp/ip also violated osi model and couldn't be considered for iso standards work 3) talked directly to the lan/mac interface. lan/mac definition sits approx. in the middle of osi level 3 ... and violates the osi model. so anything that supports lan/mac interface also violate the osi model ... and therefor can't be considered. now i had done some work on the original relational/sql database http://www.garlic.com/subtopic.html#systemr and in the early 90s were producing the ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp which included doing some work on parallel scaleup. minor meeting reference regarding parallel oracle scaleup http://www.garlic.com/~lynn/95.html#13 so i think it was at the (92?) acm sigmod database in san jose ... that somebody was trying to explain the x.500/x.509 stuff that was going on ... as ... a bunch of networking engineers trying to reinvent 1960s database technology. a couple years later were were doing some financial consulting and were asked to work with a small client/server start up in menlo park on doing payment transactions and something called a payment gateway that was going to turn into something that is frequently referred today as e-commerce. who turns up at this startup responsible for this thing called a commerce server ... but a couple of the people that were in the above mentioned meeting looking at parallel scaleup http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 now, one of the things we had to do as part of this stuff that was going to be called e-commerce was go around and do audits of some of these new organizations that were calling themselves certification authorities ... who would be issuing these things called ssl domain name cerver certificates. misc. collected postings on ssl domain name server certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert now x.500/dap has somewhat evaporated ("1960s database technollogy being re-invented by network engineers")... being replaced with something called ldap ... or leight-weight dap. and x.509 ... which was going reference some amount of x.500 has taken on a life of its own. however, the original design point for x.509 is still to provide relying parties with information about the original entity performing a digital signature ... when the relying party has no other recourse to information about the originator (aka the first time communication between complete strangers). however, it can be claimed that the original target market segment for first time communication between two strangers, where the relying-party has no other recourse for information about the other party (because of no previous contact or unable to directly contact some certification authority and/or other authoritative agency about the entity in question) is rapidly disappearing because of the ubiquitous pervasive creep of the internet into all areas of the world. even the no-value market segment ... which some PKIs tried to move into (aka online resources became readily available for relying parties to obtain real time information about the stranger they were interacting with ... there value of the operations couldn't provide cost justification for doing real-time vetting) is also rapidly disappear as the cost of online connectivity rapidly declines. as a result, the market segments where PKIs have some valid justification are rapidly shrinking. pieces of past posts in this thread: http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM it somewhat seemed that x.509 standards work was moving out of ISO and into IETF when it started to appear that the various gov. mandates to eliminate the internet and tcp/ip (and replace them with iso osi, x.400, x.50x, etc) was not going to be succesful. the original pk-init draft for kerberos http://www.garlic.com/~lynn/subpubkey.html#kerberos i.e. allowing public keys to be registered in lieu of passwords and performing digital signature validation for authentication was originally straight-foward, simple authentication process .... http://www.garlic.com/~lynn/subpubkey.html#certless the specification was added later for the use of certificates as part of the digital signature operation ... turning simple, straight-forward authentication operation into a heavy-weight identification operation. if it was a pure x.509 identification implementation, total strangers would be allowed onto every system as long as they were able to present a valid x.509 identity certificate. note that even in a pure x.509 identity certificate environment ... the relying party still needs to have obtained and registered in their trusted public key repository, the public keys for the certification authorities (otherwise the relying parties would not be able to validate the certification authorities digital signatures on the digital certificates ... which is the root operation required for PKI. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list mozilla-crypto@mozilla.org http://mail.mozilla.org/listinfo/mozilla-crypto
