"Anders Rundgren" <[EMAIL PROTECTED]> writes: > 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.
we were asked to work with this small client/server startup in menlo park that wanted to do payment transactions on their server ... and they had this stuff called SSL http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 in the year we worked with them ... the moved and changed their name. trivia question ... who had owned the rights to their new name? as part of the effort on doing the thing called a payment gateway and allowing servers to do payment transactions ... we also had to perform business due dilligence on most of these operations that produced these things called SSL domain name certificates. At the time we coined the term "certificate manufacturing" ... to differentiate what most of them were doing from this thing called PKI (aka that don't actually really have any operational business process for doing much more than pushing the certificates out the door). It was also when we coined the term "merchant comfort certificates" (since it made the relying parties ... aka the consumers ... feel better). we also originated the comparision between PKI CRLs and the paper booklet invalidation model used by the payment card industry in the 60s. when some number of people would comment that it was time to move payment card transactions into the modern world using digital certificates ... would pointed out to them ... rather than modernizing the activity ... it was regressing the operations by 20-30 years. Another analogy for certificates is the offline payment card world of the 50s & 60s ... which had to mail out invalid account booklets on a monthly basis ... and then as the number of merchants, card holders and risks increased ... they started going to humongous weekly mailings. At least they had a record of all the relying parties (aka merchants) ... which typical PKI operation has no idea what-so-ever who the relying parties are. It was sometime after we started pointing out that PKIs really had a business model oriented at offline business environment ... which would result in regressing many business operations decades if it was force fit on them ... that you saw OCSP come on the scene. OCSP doesn't actually validate any information ... it is just there to validate whether any information that might be in a certificate is actually still valid. The CRL model is known to not scale ... as found out in the payment card industry going into the 70s. PKIs imply the administration and management of the trust information. In the offline certificate model ... either they have to have a list of all possible relying parties and regularly push invalidation lists out to them ... or they provide an online service which allows relying parties to check for still valid. However, as you point out that the PKI administration and management of any kind doesn't really scale ... which resulted in actual deployments being simple "certificate manufacturing" (instead of real PKI). The payment card industry also demonstrated the lack of scaling of the certificate-like offline model scalling model in the 70s when they converted to an online model for the actual information. Part of the problem with the online OCSP model is that has all the overhead of an online model with all the downside of the offline implementation aka not providing the relying party access to real online, timely actual information ... things like timely aggregation information (current account balance) or timely sequences of events (saw for fraud detection). part of the viability for no/low-value market segment is to stick with simple certificate manufacturing and don't actually try to manage and administrate the associated information trust. random past certificate manufacturing posts http://www.garlic.com/~lynn/aepay2.htm#fed Federal CP model and financial transactions http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates http://www.garlic.com/~lynn/aadsm2.htm#scale Scale (and the SRV record) http://www.garlic.com/~lynn/aadsm2.htm#inetpki A PKI for the Internet (was RE: Scale (and the SRV http://www.garlic.com/~lynn/aadsm3.htm#kiss7 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/aadsm5.htm#pkimort2 problem with the death of X.509 PKI http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda) http://www.garlic.com/~lynn/aadsm11.htm#34 ALARMED ... Only Mostly Dead ... RIP PKI http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form) http://www.garlic.com/~lynn/aadsm13.htm#37 How effective is open source crypto? http://www.garlic.com/~lynn/aadsm14.htm#19 Payments as an answer to spam (addenda) http://www.garlic.com/~lynn/aadsm14.htm#37 Keyservers and Spam http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug? http://www.garlic.com/~lynn/98.html#0 Account Authority Digital Signature model http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site. http://www.garlic.com/~lynn/2001d.html#16 Verisign and Microsoft - oops http://www.garlic.com/~lynn/2001d.html#20 What is PKI? http://www.garlic.com/~lynn/2001g.html#2 Root certificates http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001j.html#8 PKI (Public Key Infrastructure) http://www.garlic.com/~lynn/2003.html#41 InfiniBand Group Sharply, Evenly Divided http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#46 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2004m.html#12 How can I act as a Certificate Authority (CA) with openssl ?? random past comfort certificate postings: http://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature http://www.garlic.com/~lynn/aadsm2.htm#mcomf3 Human Nature http://www.garlic.com/~lynn/aadsm2.htm#useire2 U.S. & Ireland use digital signature http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: 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/aadsm3.htm#kiss7 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/aadsmail.htm#comfort AADS & X9.59 performance and algorithm key sizes http://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert6 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert7 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert8 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert9 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert10 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert11 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert12 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert13 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert15 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#comcert17 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay6.htm#dspki use of digital signatures and PKI http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/2000c.html#32 Request for review of "secure" storage scheme http://www.garlic.com/~lynn/2001c.html#62 SSL weaknesses http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2004b.html#39 SSL certificates http://www.garlic.com/~lynn/2004c.html#43 why and how VeriSign, thawte became a trusted CA? http://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated Public Key Exchange without Digital Certificates -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
