there are periodic comments that OCSP fixes the offline characteristics of digital certificate credentials.
some recent postings related to the subject: http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no SSL being used basically around the time we were involved with this small client/server startup that wanted to do payments and had this technology called SSL ... http://www.garlic.com/~lynn/subpubkey.html#sslcert some number of the PKI afficionados were claiming that credit card transactions could be modernized by upgrading the transactions with PKI (adding a digital certificate to every credit card transaction). our somewhat off-hand response was that would involved setting the credit card transactions back 20-30 years. in the 60s, credit card transactions had offline credentials and revokation lists ... monthly booklets that were sent out to every merchant once a month. as credit cards became more widely adapted ... the booklets got larger (since the number of cards in play was dramatically increasing), the number sent out dramatically increased (since the number of merchants were increasing), and they were being sent out more frequently (since the absolute number of invalid cards was reaching a risk threshold faster ... even if the percentage remained constant). the approach was on its way to having to distribute tens of millions of booklets with hundreds of thousands of entries, every couple hrs. the introduction of online, electronic in the 70s allowed that untenable paradigm to be eliminated. in theory, the online, electronic approach could have taken the OCSP approach, preserving the offline credential paradigm and simply upgrading the revokation business process with a indication of whether the offline credential was still valid or not. however, they actually transitioned to a real online, electronic paradigm ... but changing the paradigm from offline credential to an online transaction that actually told the merchant whether they would get paid or not. so everytime somebody would make the claim that PKI would make credit card transactions more modern, we would started the refrain that PKI would represent a 20-30 year regression in the business process. when OCSP was introduced (could somewhat be considered as the result of our heckling the revokation list process), we also heckled OCSP as going to all the trouble of doing an online transactions ... but didn't actually leverage the possible business process benefits of doing online transactions ... but continued to preserve the offline credential paradigm of PKI. part of the issue was confusing the digital signature technology with the PKI business process. While digital signature technology for transaction authentication would represent a modernization effort, reverting to an offline credential paradigm represented by the offline PKI model would be a 20-30 year regression in the business model and doing real online transactions. This was also during the period that you found PKI aficionados making statements about modernization driver's licenses with the PKI model. However, in this period ... most infrastructure operations that made serious reference to a driver's license was also migrating to real online transactions; aka going to all the trouble of having a real online transaction wasn't going to be crippled by following the OCSP model and just checking to see simply whether the credential was still valid or not ... if you are going to the trouble of doing a real online transaction ... lets make it worth the trouble and respond with all facts that might be of interest related to the official doing their business. While driver's licenses can still work as an offline credential ... they are more & more being used as part of a real online transactions ... as opposed to trivially checking as to whether the offline credential is still valid or not. the other story from the period of possibly some interest with regard to modernizing online, real-time credit card by appending stale, static digital certificates ... was that even relying-party-only digital certificates from the period http://www.garlic.com/~lynn/subpubkey.html#rpo could represent a 4k-12k byte payload burden. the nominal iso8583 payment transaction is on the order of 60-80 bytes. the appending of a redudant and superfluous, stale, static digital certificate to a payment transaction represents an enormous payload bloat on the order of two orders of magnitude ... serving no useful purpose. now in the x9 financial standards body, the x9a10 working group was given the task of preserving the integrity of the financial infrastructure for all retail payments. the result was x9.59 standard http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 which would just need the inclusion of a digital signature as part of an iso8583 payment transactions w/o requiring that digital certificate payload bloat also be included (since the consumer would already have an established relationship with their financial institutions). this also had the characteristic of being a simple authentication operation (using digital signature technology) w/o trying to convert it into a heavy-weight identification operation with inclusion of digital certificates. there was some activity in some of the financial standards body to do compressed certificates (because of the enormous payload bloat that PKI would cause to payment transaction infrastructure) ... even the limited relying-party-only certificates ... where all personal information had been moved out of the certificate itself http://www.garlic.com/~lynn/subpubkey.html#rpo as an alternative to doing x9.59 w/o certificates http://www.garlic.com/~lynn/subpubkey.html#certless we pointed out that a highly effective mechanism for compression was to eliminate fields known to be in possession of the relying-party. for payment transactions, we could show that the relying-party would have all possible digital certificate fields and therefor we could compress the certificates to zero bytes. so instead of doing certificateless digital signature payment transactions, we could do digital signature payment transactions with zero byte appended digital certificates. a few past posts mentioning the technique of compressing digital certificates to zero bytes 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/aadsmore.htm#client4 Client-side revocation checking capability 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/aadsm3.htm#kiss6 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/aadsm4.htm#6 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification? http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda) 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/aadsm14.htm#41 certificates & the alternative view http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication misc. past postings mentioning the enormous payload bloat represented by appending digital certificates to payment transactions: http://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed) http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...) http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug? http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning http://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ? http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates http://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate http://www.garlic.com/~lynn/2004g.html#5 Adding Certificates http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates 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/2004j.html#9 Smart card Authentification http://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role http://www.garlic.com/~lynn/2005e.html#22 PKI: the end http://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate? http://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards http://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely http://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates http://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ? http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation? http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
