Lynn, Some TTP CAs actually *do* require RP contracts.
The "only" problem with that is that this is usually also connected to RP authentication to OSCP services for payment purposes. So even if the certs are stale the information is dynamically verified. Unfortunately this kind of PKI has scalability issues and their promoters (banks) are only losing money. Therefore VeriSign's model in spite of its contractual weaknesses still seems to reign. Maybe you are exaggerating the need to sue CAs for huge sums? That DNSSEC could kill the SSL CA is probably true but it seems that DNSSEC suffers from a dysfunctional business model. The SSL PKI has a working business model. Anders ----- Original Message ----- From: <[EMAIL PROTECTED]> Newsgroups: netscape.public.mozilla.crypto To: <[email protected]> Sent: Wednesday, June 22, 2005 18:45 Subject: Re: The Worth of Verisign's Brand Anders Rundgren wrote: > If you have a scheme that with limited amount of money and user inconvenince > allows a citizen to access potentially thousands of e-gov sites, without using > TTPs I (and all e-govs in the World), would like to hear about it. > > Replacing the _indeed_ stale cert info with a stale signed account claim > would not > have any major impact this scenario except for a few saved CPU cycles. > > SSL is by no means perfect but frankly; Nobody have come up with a > scalable solution that can replace it. To use no-name certs is not > so great as it gives user hassles The issue isn't about TTPs specifically ... it is about PKIs and certificates which have a design point of addressing specific issues involving offline environments; aka the offline email environment of the early 80s where somebody dialed up their local (electronic) post office, exchange email and then hung up. They then possibly had some first-time email from somebody that they had never communicated with before ... and needed some method of finding out some information about the sender. This is somewhat analogous to the "letters of credit" from the sailing ship days. The issue isn't about TTPs ... it is about trying to apply a solution designed to compensate for being in an offline environment and not having any recourse to the real information (including direct access to the TTPs with the real informationn) to the emerging online environment. The contention is that in a real online environment, resorting to stale, static information (designed to compensate for lack of access to real online information in an offline enviornment) ... that the stale, static information is of lot fundamentally flawed given timely access to the current real information. Somewhat as the online environment has become more and more pervasive ... the stale, stale, offline PKI paradigm has attempted to find market niches in the low/no value areas where the relying party can't justify the possible incremental cost of having access to real, timely information. For instance a PKI certificate issued at some point in the past year ... might claim that an individual has a specific bank account. ALl other things being equal, would a relying party (about to execute a high value transaction) prefer to have 1) stale, static information possibly a year old regarding the other party having a specific bank account or 2) timely, real-time response from the other party's financial institution that the other party not only still has an active account ... but also that the account has sufficient funds to cover the indicated transactions and furthermore the other party's financial institution will stand behind the transfer of those fund. One of the passing issues for PKI infrastructures moving into the low/no value market segments ... they are less & less likely able to charge any significant amounts for stale, static certificates in support of no/low value operations. The other issue is that the typical TTP PKI business model is contrary to most standard business practices. In most standard business practices, the relying party contracts directly with a TTP for timely information ... creating some legal obligation on the part of TTP to perform in specific manner. In the TTP PKI certificate-push model, the key owner is contracting with the TTP agency (buying a certificate) which creates various kinds of legal obligation between the TTP agency and the key owner. The key owner then pushes that certificate to a relying party .... where there has been no legal established relationship between the relying party and the TTP agency. another issue is that in the early 90s, you somewhat found TTPs considering grossly overloading X.509 identity certificates with enormous amounts of privacy information. the problem was that many of the TTPs had no idea what purposes the X.509 identity certificates might be put to use and/or with which relying parties (and what possibly information requirements might unknown and unpredictable relying parties might want). then as you moved into the mid-90s, some institutions were starting to come to the realization the x.509 identity certificates grossly overloaded with personal information represented significant privacy and liability issues. the result was somewhat retrenching to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo however, where a replying party registers a key-owner's public key in some sort of database ... and then issues a stale, static, relying-party-only certificate effectively only containing some sort of account number (or other form of database lookup value) bound to the public key. The key-owner was then to append such certificates in all communication with the relying party. However, it is trivial to demonstrate that the appending of such stale, static, relying-party-only certificates to communication with the relying party is redundant and superfluous i.e. the relying party already is in possession of a superset of the information in the stale, static, relying-party-only certificate. specifically with respect to SSL certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert the issue is that there were concerns about the integriy of the domain name "TTP" providing real-time responses for real-time domain name requests thru-out the world. the browsers would validate the certificate and then compare that the domain name that the user typed in matched the domain name in the certificate. the problem for the CA SSL PKIs is that they had to validate the information for a requested ssl domain name certificate with the actual authoritative agency (aka TTP) for domain names ... the domain name infrastructure. The CA SSL PKIs had to get various kinds of identification information from the SSL domain name certificate applicant and then perform the time-consuming, expensive and error-prone task of attempting to match it with the identification information on file with the domain name infrastructure as to the owner of the specific domain name. This, then also put the CA SSL PKIs vulnerable to possible integrity problems with the domain name infrastructure. Somewhat from the CA SSL PKI industry is a proposal to improve the integrity of the domain name infrastructure by having domain name owners register public keys for their domains. Future communication is then digital signed and can be verified with the on-file public key .... not a certificateless public key operation http://www.garlic.com/~lynn/subpubkey.html#certless The other advantage for the CA SSL PKIs is that they can also require that SSL domain name certificates also be digital signed. Then they can use the onfile (certificateless) public key to change from the time-consuming, expensive and error-prone identification process to a much simpler, less expensive and reliable authentication process (by retrieving the onfile public key for validation of the digital signature on the SSL domain name certificate request). This however represents something of a catch-22 for the CA SSL PKI industry. If they are able to retrieve trusted onfile public keys from the domain name infrastructure for validating digital signatures (as the root of the trust chain for SSL domain name certificates) ... then it would be technically possible for everybody in the world to also retrieve trusted onfile public keys in their real-time, online domain name resolution requests. If everybody in the world could do real-time retrieval of onfile public keys from the domain name TTP ... for verifying digital signature in communication with servers that they are contacting ... then it obsoletes the requirement for having SSL domain name certificates. _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
