Ownership has been revealed as a flawed misconception believed by the masses as their rights of usage. The ownership of their credit information, private residency, and purchased property is all but a notional concept. Since the dawn of ecommerce the teeth of State Controlled Rights have reared thier ugly head and the consumer at least the US consumer has watched the Supreme Court rule that government is allowed to take property away based on a projected greater good basis rendering property ownership useless. The consumer has no recourse when their information is sold by merchants and unprotected by those same merchants. Freedom has all but vanished and waned to the beneficent dictator. We no longer have representation in elected offices due to the states preference to bow to better funded non-physical entities. Phishing is a symptom of the society serving the elites and rendering the un-empowered to theft and scandal. The online is reflecting the social ills of our society with the credo might makes right. sphere of self interest.

HTTPS traffic has usually been protected by RC4, which is lightning-fast, rather than 3DES which indeed taxes CPUs pretty heavily.
I don't think the porn guys have had any problems with encryption-caused loads.
Actually, I think that RC4 was one of the reasons why SSL-based HTTPS emerged as the winning secure browsing solution when PGP-based SHTTP was already implemented (NCSA httpd server and mosaic browser, later ported to Apache) and based on the most popular and trusted crypto available at the time. OTOH, SHTTP would have allowed encrypting the stuff once with a symmetric key, and only do the asymmetric encryption of that key in real time.
Anyhow, I have been hired to develop a new content-distribution mechanism, so the non-hollywood content industry (which is porbably much more than porn) is not quite happy with SSL.

Two quick comments (because I don't have time for more):

First, I want to correct a misleading statement about Netscape: The amount of total Netscape revenue from the Federal sales group never exceeded ten per cent or so of total Netscape revenues (a ratio in line with enterprise software companies in general), so it's not correct to say that "the Federal sales division of Netscape was reputed to have made most of the revenues". However it was most likely the case that the US government in general was the single largest source of Netscape revenues, in the sense that no other single company/organization accounted for a higher percentage of revenue. (Again, given the size of the US government this is a pretty typical situation for enterprise software companies.)

Second, it's great to know your thoughts on what went wrong, especially in light of your "GP" ideas, which seem worth exploring. But your readers crave more: If you had been in charge, what would you have done differently? What specific security measures would have made sense in your mind, and when? (Maybe this could be another blog post? :-)

Frank, thanks for your correction! FTR, I've changed "Federal sales division of Netscape was reputed to have made most of the revenues" to "US government was the single largest source of Netscape revenies..." in the text above.

(I certainly agree that this situation is in common with many other large enterprise suppliers. And it is similar in other places around the world, more or less. Nothing unusual there, and it would be a surprise if Netscape wasn't under such forces. As a for instance, we see much the same going on today with the big suppliers and the Chinese government - Yahoo, Sun, Cisco, eBay have all been in the press over this sort of influence.)

Frank,

On your second point - "your readers crave more" - you are too kind, I know that my readers crave my head, but I'll try and answer it anyway :-)

Firstly, the point of the historical dive into SSL's beginnings is to identify the genesis about certs, and I conclude that "there is no way [Netscape] could have avoided it. The forces were just too strong." So my first answer is that I couldn't have made any different choices!

But we can get a little deeper. GP's thesis is that there is no value or negative value in putting the security in too early, and my story lays it out with that theme - it was too early. So if we had concluded that there was no value, there was also no point in going up against all those forces. Same answer than as (1) above. If we concluded negative value, then that would have been simple - not deploy it so fast, or deploy it in a more limited fashion.

Third attempt - lets say we recognised all those forces and decided to go up against them. (Yowsa!) The way I'd do that is to set up some meetings and collaborations and standards groups.

Fourth attempt - we have to seriously consider that the goal was money and not security. If that was the case, then the short term tactical goal is control and the long term strategic goal was not the above forces at all but M$, which is strangely absent from that list. If that were the case, then the protocol would have just been wrestled about in a different war, not the one it was in. If one is security minded then one would be equally unsatisfied, so this is another dud answer ;-) But assuming that we were going to use the protocol as a weapon against M$, then there were plenty of directions and some of them even would have been positive for security. For example, I'd have been sorely tempted to do the uber-CA thing because it solves or addresses some of the bugs in the implementation (still there!) and the murky legal situation.

Of course, the deeper we get into this armchaircryptogeneralling, the stickier it gets. I wasn't there - you were. What would you have done (if you'd been in the hot seat) ?

Re your question, "What would you have done (if you'd been in the hot seat)?" I don't really have any better answers than you. If the near-term goal were simply to allay basic fears about eavesdropping on connections (and remember, not just PKI folks were obsessed about that, it was the heyday of crypto paranoia generally) then from a technical point of view an alternative approach would have to go with an SSH-style model for SSL (with or without certs as such), or perhaps a model which nominally used certs but where you got the cert from your web server software vendor as a side effect of installing the software. Basically the approach here would have been to 1) make SSL-enabling connections dead easy and 2) avoid focusing overmuch on "identity" (and the need for CAs to validate such identity). But I agree that the forces around SSL were probably too great to avoid going down the traditional PKI path, especially because of the e-commerce and payment connection.

Where I think a major opportunity was missed was with S/MIME email. Although S/MIME as such was technically tied to X.509v3 certificates, IMO there was no real reason why CAs as such couldn't have been optional in the S/MIME implementations fielded by Netscape and others. Netscape Communicator could have generated self-signed certs automatically upon initialization, and could have easily bootstrapped into automatically and silently doing signing and encryption when sending email to people known to also be using Netscape Communicator (based on previously having received email from them).

I think email would have been a good area to do this sort of alternative approach, for several reasons. Crypto performance would have been much less of an issue than with SSL, because the transactions would not be "real-time", so adopting an "always sign and/or encrypt" policy would be much less of a burden. For the most part S/MIME wasn't tied up in the e-commerce/payment wars as was SSL. Also, self-signed certs could have been used in combination with the user's address book to make a basic distinction between "known" vs. "unknown" (and thus potentially dubious) sources of email, bypassing the whole issue of needing CAs to do this sorting out of potential correspondents. Enterprises would still have wanted to do the PKI thing (since that was still the hot thing at that time), but they could have just turned off the auto-recognition of self-signed certs.

Against this we have to weigh the fact that "overt" use of S/MIME (as opposed to the "covert" use described above) was still driven by large enterprises wedded to the PKI/CA model and driven in large part by e-commerce concerns (e.g., to move EDI-style transactions over to a full digital signature regime). And of course CAs themselves were still operating under the assumption that they could sell millions of certs to random individuals.

But I think the basic ideas of "opportunistic cryptography" (to use your term) in the email context are still worth exploring. (And as I understand it, this is in many respects the strategy that Skype pursued with their VOIP client, basically giving the user crypto without worrying them about how it got done.)

Actually, I still don't understand why do domain name registries not provide certs with the domain name. After all, there's already a hierarchy of trust in place there, why have a different one (and why trust the other one to certify this one?)?
What would be more authoritative certification than that of the registry?

> Actually, I still don't understand why do domain name registries not provide certs with the domain name.

Technically, that makes sense and has been on the IETF agenda for ages. Politically, it's going to upset a hundred committees and vested interests. I've never followed it, but it is frequently brought out in conversation and just as frequently shot down in flames...

I suppose the place to watch is godaddy.com.

On the subject of getting certs with domain names: As Ian mentioned, some companies like Go Daddy are indeed treating certs as basically an add-on to domain name registration. However it is still not treated as a truly bundled service, for a couple of reasons I think:

First, an SSL cert is still perceived by suppliers like Go Daddy as something that they can charge for. Hence from the user's perspective it's an optional purchase, and one without a clear value proposition if you're not doing an online store.

Second, bundling a cert with a domain name registration by default makes most sense if the company in question is selling hosting services too (which Go Daddy and other domain name vendors do), since then all the web server magic in enabling SSL can be done "under the covers" with minimal main to the user. However as Ian well knows there are technical problems with deploying SSL in the virtual host mode used by hosting services for their entry-level offerings. These problems won't go away until SSLv2 support gets dropped by default and the majority of browsers in use implement the TLS extension that supports SSL use in a virtual hosting mode. This will take at least a year or so, maybe longer.

But I do agree that SSL server certs are a natural companion to domain names and hosting services, and ideally would be bundled together in a single service. The role of CAs in such an environment would then move in large part to being back-end suppliers of PKI technology and services to the "web presence" vendors. I discuss this in more depth in my "business of CAs" post.

> Actually, I still don't understand why do domain name
> registries not provide certs with the domain name. After
> l, there's already a hierarchy of trust in place there,
> why have a different one (and why trust the other one to
> certify this one?)? What would be more authoritative
> certification than that of the registry?

one might conjecture that there are some economic forces in play ... if it was done within dns ... there wouldn't have been justification for independent business ... it would simply be part of the existing infrastructure.

the other part is done within the existing dns operation, there would have been no justification for PKI, certification authorities, digital certificates, etc.

basically dns provides real-time authoritative information responses (and structured for generalized information not just binding of ip-address to domain name ... but can and does provide various kinds of other information bound to domain name).

within the dns real-time authoriative information responses, a public key implementation would be bound to a domain name ... in addition to the other information bound to a domain name and provided in a real time response.

the digital certificate model was designed to provide relying party with stale, static binding information in stituations where the relying party had no access to their own local repository of information and/or online, real-time access to some authoritatve agency with the information (aka an offline environment)

there is dnssec effort, somewhat backed by the ssl certification industry to have domain name owners register a public key when a domain name is registered. currently, a certification authority requires some identification information in conjunction with an ssl domain name certificate. the ssl certification authority then can do a real-time retrieval of the identification information onfile with the domain name infrastructure. then the certification authority does the expensive, time-consumer, and error prone task of matching the supplied identification information with the onfile identification information.

dnssec would allow the certification authority to request digital signature on ssl domain name certificate applications. then the certification authority could do a real-time retrival of the onfile public key and verify the digital signature ... replacing a time-consumer, expensive, and error-prone identification matching process with a much simpler, reliable, and less-expensive authentication operation.

the catch-22, is if the ssl certification authority industry can start doing real-time retrivals of onfile public keys ... then the rest of the world could also ... obsoleting the requirement for ssl domain name certificates. lots of past postings on ssl certificates and the ssl certification process
http://www.garlic.com/~lynn/subpubkey.html#sslcert

i've even suggested a drastically simplified and efficient ssl hand-shaking protocol. the client does a call to dns just like they do today ... but if there is any registered public key ... they get back both the ip-address along with any public key and crypto protocol options piggy-backed on the ip-address response.

then in a single communication with the server, they could transmit the random session key (encrypted with the server's public key) and the actual request (encrypted with the random session key) ... no SSL protocol setup chatter is required.

this could even be done as a udp and/or transaction protocol.

note that SSL over HTTP over TCP is quite expensive. the minimum packet exchange for just TCP is seven packets ... and then HTTP and SSL has to ride on top of that ... including all the SSL protocol setup chatter.

an early reliable "transaction" protocol was VMTP ... which reduced the 7-packet minimum TCP to 5-packet minimum.

I did a lot of work on XTP ... which included support for reliable "transaction" protocol in 3-packet minimum exchange. lots of past posts on XTP
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

aka do dns udp in single round-trip, getting ip-address, public key, and any ssl crypto options in single roundtrip. then do ssl-like encrypted request/response transaction with XTP in minimum 3-packet exchange.

while there was an RFC for vmtp ... rfc1045 ... there was never a RFC for XTP ... although we did a forey at ISO (but got hung up in the rule about violating OSI model). there are a couple books written on XTP ... and I've piles of hardcopy and softcopy stuff.

my rfc index
http://www.garlic.com/~lynn/rfcietff.htm

move down to "RFCs listed by" section and select "TERM (term->RFC#)".

in the acryonym fastpath section, select "DNSSEC". this will give you all RFCs associated with DNSSEC ... aka

domain name system security (DNSSEC )
see also domain name system , domain name system extensions , security
4322 4310 4035 4034 4033 3845 3833 3755 3658 3226 3225 3130 3110 3090 3008 3007 2931 2930 2845 2541 2540 2539 2538 2537 2536 2535 2137 2065

if you are in frames mode, selecting any RFC number will bring up the RFC summary in the lower frame. as always, selecting the ".txt=nnnn" field (in an rfc summary) retrieves the actual RFC.

or you could go even further. the prevailing use of SSL is for hiding acocunt numbers in payment transaction.

the long-time vulnerability for payment transactions was attacker evesdropping and/or harvesting account numbers and using them in fraudulent transactions
http://www.garlic.com/~lynn/subpubkey.html#harvest
http://www.garlic.com/~lynn/subpubkey.html#secrets
http://www.garlic.com/~lynn/subpubkey.html#fraud

effectively a form of replay-attack.

the x9a10 standards working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the resulting protocol was x9.59.
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

it had two business rules

1) transactions were strongly authenticated
2) account numbers used in x9.59 transactions would not be valid in non-authenticated transactions

this is effectively traditional countermeasures for attackers attempting replay attacks.

with the elimination of the evesdropping/harvesting vulnerability for replay attacks (fraudulent transactions) the justification for hiding the account number was drastically reduced.

x9.59 transactions had sufficient protection with simple authentication for fraud prevention and no longer needed encrypting and account number hiding to prevent fraud.

customers would register public keys with their accounts (in similar manner suggested for domain name infrastructure) ... similar to registering "mother's maiden name" or other authentication information. the consumer applies their digital signature to the x9.59 transaction and send it on its way. the transaction eventually arrives at the consumer's financial institution, validates the digital signature (with the onfile public key), does their other bit of authentication magic and authorization magic and send off the reply.

no PKI, certification authority and/or digital certificates are required. in addition, it also eliminates the requirement for SSL hiding of the account number; just simple authentication and long understood countermeausures against replay attacks.

the ancillary issue was that there were some payment protocol activities going on concurrent with the x9.59.

we had been involved in much of the work on the original payment gateway with this little client/server startup company that had come up with SSL (and used for hiding payment transactions)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

one of the scenarios that we looked at with respect to some of the PKI/certificate-based payments ... was just the payload size. A PKI infrastructure has the original transaction, an appended digital signature, and one or more appended digital certificates (under the assumption that the receiving party has no prior knowledge of the signer and/or their public key).

A standard ISO8583 payment transactions runs 60-80 bytes. The common appended PKI digital certificate of the period ran 4k-12k bytes. Basically, the PKI-based infrastructure planned on increasing the transaction payload size by two orders of magnitude (100 times increase in payload size) with appended PKI overhead ... solely on the justification that the receiving consumer's financial institution had no prior relationship with the consumer (which appears to be logical contridiction).

the other approach to doing the financial transaction account number vulnerability analysis is using the userid/password metaphor.

bascially an account number is used to select the account, like the functionality provided by userids. also, like userids, account numbers are required to be available and used in a large number of different business processes.

however, the account number is also used to authenticate the transaction ... i.e. knowledge of the account number is sufficient authentication in large number of payment transactions. in that use, the account number is like a password and is vulnerable to evesdropping, skimming, and/or harvesting. thus such account number uses is also like a password.

the use of an account number as both a "userid" and a "passwords" may create an horribly conflicted environment. at post periods, the industry had created countermeasures to account number guessing ... i.e. as fraud prevention in account number role as password.

however, the advent of evesdropping, skimming, and harvesting attacks sidestepped the guessing countermeasures and opened the way for replay attacks (i.e. capturuing a valid value and replaying it).

SSL and various of the PKI-based payment protocols provided countermeasure to account number evesdropping while transactions were in-flight. however, one of the long term (preceeding internet use) attacks against account numbers have been havesting account numbers from stored information. the stored transaction acocunt information was required for a large number of business processes where the account number role is used like a "userid".

this gave rise to my past comments that the planet could be buried under miles of encryption and it still would prevent account number leakages. the problem was the dual-use requirements placed on account numbers for both userid functionality and password functionality and the radically conflicted processing and protection objectives. The account number as userid functionality has to be fairly widely available. The account number as password functionality has to be kept hidden and confidential. This conflicting requirements leads to enormous problems and vulnerabilities that can't be address by simply hiding the account number in transit.

the solution by x9.59 retail payment standard eliminated the dual-use conflict for account numbers. account numbers were solely restricted to use a userid funtionality. digital signatures were introduced for (authentication) password functionlity. x9.59 enabled accounts would no process transactions that didn't have appropriate authentication (many of the PKI-oriented payment protocols solely addressed hiding the account number, but still allowed the account number to be skimmed or harvested and used in non-PKI and non-authenticated transactions).

with the elimination of account number dual use ... it was no longer to hide the account number ... since it was only be used for "userid" functionality.

static data passwords are still subject to evesdropping and replay attacks ... and therefor are required to be hidden. advantage of digital signatures for authentication (over static data passwords) is that they can be evesdropped w/o being vulnerable to replay attacks.

as previously mentioned, a separate issue with some of the PKI-based payment protocols was the enormous payload bloat
(increase in payload size of one hundred times) introduced by requiring stale, static, redundant and superfluous digital certificates to be appended to payment transaction.

going back to fundamental principle of PKI, certification authorities and appended digital certificates ... is that you have digitally signed something and prepared to transmit the transaction and the appended digital signature.

The issue in PKI environment is that the targeted recipient has no prior information about you and/or has no way of doing online operation to obtain information about you.
So digital certificates are created that have been certified by independent, well known parties (where the targeted recipient is believe to have some sort of trusted relationship). The targeted recipient is believe to trust the certification authority and therefor the appended digital certificate with appropriate information about you ... will be trusted.

However, it takes quite a bit of confused thinking to believe that a consumer's financial institution has no prior knowledge about their consumers for which they have created consumer accounts and issued consumer accounts. It is even more unbelievable that the because it is believed that a consumer's financial institution has had absolutely no relationship with the consumer for which there is an account ... that it justifies bloating a payment transaction payload size by a factor of one hundred times.

I suggest that if we had been using an SSH-style security model all these years since the mid 90s, we would have seen just as many problems. Attackers would have tuned their efforts towards the weaknesses in that model if that were the one that was widely deployed. It's crazy to look at the attacks in place today in an SSL world, note that they would not work well against an SSH world, and conclude that if we had an SSH world we'd have no attacks!

The achilles' heel of SSH is the initial connection, when an unverified key is accepted and trusted for future use. If the attacker can get there first and play MITM on that initial connection then security is lost. Who knows what creative methods to accomplish this would be conceived in ten years of intensive efforts by hackers and criminals.

Another obvious effect would be that instead of SSL's "bad/expired certificate" messages which people have been auto-trained to ignore, we would see SSH's "key-changed" messages which would be just as opaque and just as common due to system re- and mis-configurations.

a PKI certificate-based model

1) assumes that the relying-party or recipient has not other source of information (aka the letters of credit/introduction from the sailing ship days)

2) trust in the certifying party

a certificateless-based model
http://www.garlic.com/~lynn/subpubkey.html#certless

1) assumes that the recipient and/or relying party has their own information

2) and/or direct access to certifying party

SSH is one such certificateless implementation.

various of the PKI payment solutions from the mid-90s were relying-party-only scenarios
http://www.garlic.com/~lynn/subpubkey.html#rpo

the relying-party-0only certificate model from the mid-90s were

1) reaction to the x.509 identity certificate standard, realizing that personal information in certificate represented serious privacy and liability issues

2) effectively restricted the "personal" information in the certificate bound to the entity's public key was just an account number.

even at that, the certificate-based appended overhead still represented an enormous payload bloat of 100 times.

the PKI process scenario from the mid90s was a consumer provided a public key (and proof of the private key) that the financial institution could register in the account record (akin to registering mother's maiden name).

in the traditional PKI process, this is frequently referred to as the RA or registration authority.

the financial institution then generated a (replying party only) digital certificate which was returned to the consumer (the certification manufactoring part of the PKI process)

the consumer was then expected to generate a transaction, append a digital signature, and also append the digital certificate (resulting in a 100-times payload bloat).

eventually the digital signed transaction arrived at the financial institution, they pull the account number from the transaction, retrieve the account record, and then can use the public key registered in the account record to validate the digital signature.

any appended digital certificate, in addition to causing a 100-times payload bloat was truely redundant and superluous.

the x9.59 scenario
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

can do the identical public key registration as the PKI scenario. the certificateless process, just eliminates the manufactoring of a redundant and superfluous digital certificate and also eliminates the appending of a redundant and superfluous digital certificate on ever financial transaction sent back to the consumer's financial institution (as well as avoiding the 100-times payload size bloat).

As mentioned before, neither the SSL or the PKI-based acocunt hiding technique actually addressed the major long-term vulnerability of account numbers (dual-user vulnerability representing both the userid functionality as well as the password functionality.

old related posting on security proportional to risk (and the merchant transaction file)
http://www.garlic.com/~lynn/2001h.html#61
and that continue to show that the leading cause of data breaches associated with id/account theft involve insiders
http://www.garlic.com/~lynn/aadsm17.htm#38 ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

similarly, the solution to major SSL domain name certificate vulnerability was the registration of a domain name user's public key. The trust root for SSL domain name certificate then changes from the identification information on file with the domain name infrastructure (and the expensive, error-prone, and time-consumer identification matching process) to the onfile, certificateless public key (and a simpler, more reliable, and less expensive digital signature verification proces).

A certificateless, SSH-style implementation doesn't necessarily mean that there has not been any registration process and/or certification of the public key. It may just mean that there hasn't been the certificate manufactoring (a term we coined when we were doing the original payment gateway and auditing these new operations called certification authorities) process.

the certificate payload bloat was so enormous for payment protocols (factor of 100 times) that X9 financial standard group (with a backing of major PKI forces) started a new work item called digital certificate compression. the idea was to come up with various compression techniques to try and get the appended digital certificate down from several thousand bytes to possibly 300 bytes.

the first thing they talked about doing was eliminating all fields that were common across all certificates by the same institution.

early on i pointed out that there was a couple of different ways of addressing the enormous payload bloat of digital certificates in payment protocols ... aside from eliminating them as being redundant and superfluous.

a perfectly valid information compression technique was to eliminate all fields that were already in possession of the relying-party (not just the fields that were common to all certificates). i quickly showed that this technique easily achieves zero-byte certificates. rather than making the rash statement of not appending stale, static digital certificates to every digitally signed transaction, i suggested that implementations should instead append zero byte certificates to every digitally signed payment transaction.

the other mechanism was to use certificate caching echnology ... if the relying party was known to have previously acquired the consumer's digital certificate and was to known to have saved it ... then it was possible to avoid appending the same digital certificate on subsequent payment transactions ... since it could be shown that the relying party was guaranteed to already have a copy.

since it was a relying party scenario, the institution being the registration authority as well as the certification authority; when the consumer registered their public key with their institution ... the institution would dutifully create a full-fledge digital certificate and save a copy in the consumer's account record. then the institution would return a note to the consumer saying that they were caching the consumer's digital certificate on behalf of the consumer ... and therefor it was not necessary to actually send the consumer a copy of their digital certificate ... since it would just result in the consumer appending the copy to possibly thousands of future payment transactions and returning it to the financial institution. by caching the original, the financial institution was saving the consumer enormous amounts of bandwidth and processing by keeping. if the consumer wanted, they could append a short note to digitally signed payment transactions stating that the digital certificate was already on file (in most cases, the digital certificate on file wouldn't even be a copy, but the original).

numerous past post discussing the enormous benefits of creating zero-byte digital certificates with advanced information compression technology
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?

I like the way webopedia, yes another pedia, describes what SSL is.
"S-HTTP is designed to transmit individual messages securely"
Ha-ha-ha

Helen, I suspect you are confused - that text in full is:

Another protocol for transmitting data securely over the World Wide Web is Secure HTTP (S-HTTP). Whereas SSL creates a secure connection between a client and a server, over which any amount of data can be sent securely, S-HTTP is designed to transmit individual messages securely. SSL and S-HTTP, therefore, can be seen as complementary rather than competing technologies. Both protocols have been approved by the Internet Engineering Task Force (IETF) as a standard.