somewhat total aside .... first time i ran into x.500/x.509 was at an acm sigmod meeting. My wife and i were doing this high availability, no single point of failure, high performance, high integrity, scalable database work as part of the ha/cmp product: http://www.garlic.com/~lynn/subtopic.html#hacmp
any way the person at the sigmod meeting was explaining x.500 as a bunch of network gurus busily re-imventing 1960s database technology. the work that went along with it for x.509 was (extremely privacy invasive) identity certificates (which represented some information supposedly contained in this x.500 1960s-era database entries). There was some reference that these network gurus may have been the same people that brought us OSI. Misc. references to OSI and what went wrong: http://www.garlic.com/~lynn/subtopic.html#xtphsp so one of the distinction often cited about the different between ISO and IETF (besides the difference between OSI and TCP/IP) is it is possible for ISO to pass standards that may never, ever be implemented (and in fact could be such that they aren't actually implementable in any practical since). For some of the IETF standards process description go to: http://www.garlic.com/~lynn/rfcietff.htm and scroll down in the main frame to the description of the standards process and the requirement for two interoperable implementations for standards progress. So about the time we were doing the HA/CMP product stuff with were also doing the hsdt project http://www.garlic.com/~lynn/subtopic.html#hsdt and internet stuff http://www.garlic.com/~lynn/internet.htm and doing some stuff with high speed protocol. Part of the ISO issue of passing standards that might not be implementable ... is that they can also make rulings that additional standards work can't be done unless in conforms to earlier standards activity (which might not be actually implementable). Now ISO is somewhat schizo about this in the area of OSI ... and things like IEEE (ISO chartered group) and LAN standards. LAN standards effectively collapse OSI levels 1, 2, and part of 3 into a single layer .... quite definately violating OSI. So we were doing some stuff on HSP (high speed protocol) which would go directly from level 4 (transport) interfacing directly to the LAN/MAC layer. This would also violate OSI since it jumped the interface betwen layer 3 & 4 ... and went directly to the middle of layer 3 ...... which is where LAN interface sits. One of the more schizo of the ISO organizations is US chartered X3S3.3 ... responsible for network level 3&4 standards .... which had a strong ruling that it was not possible to do HSP as defined .... going directly from transport to LAN/MAC interface. Anothe example of little problems with ISO network related standards activity. In any case, in the HSP work .... it also looked at reliable, high-performance transactions. HTTP (& HTTPS) uses TCP. TCP has a minimum of 7 packets to perform reliable session/transactions. There was some looking at VMTP which accomplishes the same thing in 5 packets. VMTP/RFC1045: http://www.garlic.com/~lynn/rfcidx3.htm#1045 However, with a little more work, HSP came up with a reliable transaction protocol that could be done in three packets. Slight thread drift (which helps me remember VMTP being RFC1045) is that I had done the RFC1044 implementation that shipped in mainframe TCP/IP product: http://www.garlic.com/~lynn/rfcidx3.htm#1044 which had the slight characteristic that the base implementation got about 44kbytes/sec thruput using a full 3090 engine .... while the enhanced 1044 implementation got 1mbyte/sec thruput (hadware media thruput) using about 1/50th as much processing (twenty times the thruput using 1/50th the pathlength). So getting back to the discussion about SSL domain name certificates. In the thread http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#26 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#57 Cirtificate Authorities 'CAs', how curruptable are they as well as several other SSL domain name ceritificate threads: http://www.garlic.com/~lynn/subtopic.html#sslcerts I make the assertion that not only does fixing the integrity of the domain name infrastructure (on behalf of the certification authorities) sows the seads of eliminating the SSL domain name certificates ... but also opens the opportunity for simplifying (KISS) the SSL protocol. So current process is somewhat: 1) contact domain name system to get the ip-address that corresponds to the domain URL 2) minimum 7 packet for reliable TCP for HTTP/HTTPS 3) certificate transmittal 4) ssl protocol chatter 5) hypothetical trust hiearchy network chatter to obtain necessary signing certificates to validate certificate 6) hypothetical OSCP network chatter to check on the status of each of the signing certificates 7) hypothetical OSCP network chatter to check on the status of the domain name certificate 8) the misc. digital signature verifications with all the various public keys 9) once the SSL session has been setup the client transmits the SSL transaction request 10) the server finally gets the SSL transaction requests, does whats needed 11) replies to the SSL transaction request 12) client gets the rsponse and tears down the SSL/TCP session Now, part of improving the domain name infrastructure integrity ... somewhat on behalf of the certification authority industry ... is that when a domain name is registered, the entity also registers a public key. This doesn't include a certificate ... it is just the registration authority part of public key registration that is done at the sametime as registering the domain name (this is akin to when somebody creates an account they supply their mother's maiden name or some other supposed secret, it isn't necessary to have identification ... it is just that the registering entity is the one also providing the authentication material). So the domain name infrastructure already has the ability to serve up all information registered with a domain name .... so the new scenario is 1) contact domain name infrastructure and get ip-address, public key, and whatever else may be registered (possibly including server's preferred SSL parameters if they so desire). 2) client creates a piggybacked xtp transaction packet that has the selected ssl parameters and the session key encrypted with the server's public key, followed by the encrypted transaction session information packet ... all in one transmission 3) server receives the piggybacked xtp transaction packet and unwinds it all and performs the requested transaction 4) server responds with piggbacked xtp transaction containing the (encrypted) response and the session tear-down 5) client response with tear-down acknowledgement So eliminating the SSL domain name certificate not only gets rid of the whole certificate stuff ... but eliminates huge amount of network chatter or nattering on as one reply to the following post suggested: http://www.garlic.com/~lynn/2002p.html#30 Sci Fi again Basically single round trip to get the domain name information followed by single round trip to do the SSL transaction.
