but as already pointed out in past investigations the banks don't accept a random TTPs issued cert (whether using OCSP or not). They issue relying-party-only certificates .... for privacy and liability reasons. The certificate just contains the account number .... any other information is privacy-invasive. So while the certificate appears like issued from a TTP ... it is in fact, from a business process standpoint issued by the financial institution that is executing the transaction.
ok, have been around the relying-party-only certificate by financial institutions numerous times before .... in much the same way have been around the ssl domain name cert: http://www.garlic.com/~lynn/subtopic.html#rpo so investigating what happens with a relying-party-only-certificate ... the financial institution registers the person's key, stores it in their account record and issues a certificate .... also stored in the account record. Rather than the RPO case ... lets look at vanilla TTP w/OCSP case (possibly 3d secure) a single message comes with A) the ISO8583 transaction ... 50 bytes, B) the digital signature ... 20-40 bytes C) the certificate ... 4kbytes to 12kbytes the bank looks up the account record from the ISO8583 message and checks for open to buy ... it is now ready to reply ... except it has to 1) find the CAs public key, 2) check the trust hierarchy (which could involve large amount of network chatter) 3) validate the certificate key 4) use the public key from the certificate to validate the financial transaction digital signature 5) contact the OCSP (which involves more network chatter) 6) do this in under 350milliseconds (the avg. elapsed time for the original payment gateway roundtrip) previous refernce to the original payment gateway http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 So now .... we examine the RPO case 1) eliminated ... bank is the CA 2) eliminated ... bank is the trust hierarchy 3) bank validates their own certificate signature 4) use the public key from the certificate to validate the financial transaction digital signature 5) eliminated ... bank account is the OCSP now the RPO case still has the bank validating its own signature and the humongous payload bloat caused by the certificate. X9.63 has done a lot of work on certificate compression because of the humongous bloated penalty that certificates place on the financial transaction network. So, compression can use a technique of field elimination if the relying-party already possesses the field. It is possible to show that the relying-party for a financial transaction already possesses all fields of interest that might be in the certificate. As a result it is trivial to show (using X9.63) techniques that the certificate in "C" can be reduced to zero bytes .... significantly reducing the bloat and penalty placed on the financial network. The problem is that there is still this transmitted certificate (even if it is only zero bytes) that needs to have the signature verified. so the RPO case goes to the next level of optimization. In addition to compressing the certificate to zero bytes ... the signature on the certificate is verified when the certificate is original issued and deposited in the account record. Since the bank knows that only valid information is being placed in the account record .... it is not possible for the CA's signature on the certificate to change after it has been deposited in the account record. So it follows, that it is not necessary to perform subsequent checks at every transaction as to the validity of the bank's own key. So in the optimized version we have: A) the ISO8583 transaction ... 50 bytes B) the digital signature ... 20-40 bytes C) the compressed certificate ... 0 bytes And because validation is done at the time the information is entered into the account record, the transaction becomes 1) read the account record from the ISO 8583 transaction 2) use the public key in the account record to validate the signature on the ISO 8583 transaction 3) possibly do the operation in a single network round-trip of avg. 350milliseconds. This is very close to what is defined for ISO8583 X9.59 financial payment standard (including the part of compressing the certificate to zero bytes) http://www.garlic.com/~lynn/index.html#x959 and is also very close to what NACHA implemented for the ISO8583 debit network trials http://www.garlic.com/~lynn/index.html#aadsnacha This is also the KISS principle applied to digital signature infastructures: http://www.garlic.com/~lynn/aadsm10.htm#hackhome Hackers Targeting Home Computers http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE http://www.garlic.com/~lynn/aadsm11.htm#10 Federated Identity Management: Sorting out the possibilities http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA) http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature 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#kiss2 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#kiss3 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#kiss4 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#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#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/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/aadsm3.htm#kiss8 KISS for PKIX http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature http://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation) http://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla... http://www.garlic.com/~lynn/aadsm7.htm#3dsecure 3D Secure Vulnerabilities? http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI http://www.garlic.com/~lynn/aadsmail.htm#comfort AADS & X9.59 performance and algorithm key sizes http://www.garlic.com/~lynn/aepay3.htm#gaping gaping holes in security http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#3dsecure4 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography http://www.garlic.com/~lynn/2001l.html#1 Why is UNIX semi-immune to viral infection? http://www.garlic.com/~lynn/2001l.html#3 SUNW at $8 good buy? http://www.garlic.com/~lynn/2002b.html#22 Infiniband's impact was Re: Intel's 64-bit strategy http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002d.html#0 VAX, M68K complex instructions (was Re: Did Intel Bite Off MoreThan It Can Chew?) http://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc http://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done? http://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done? http://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS? http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations? http://www.garlic.com/~lynn/2002k.html#43 how to build tamper-proof unix server? http://www.garlic.com/~lynn/2002k.html#44 how to build tamper-proof unix server? http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal http://www.garlic.com/~lynn/2002m.html#27 Root certificate definition http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958? http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI [EMAIL PROTECTED] on 12/20/2002 11:30 am wrote: - Using 3D Secure the bank (issuer) would check the TTP-issued cert using OCSP - Then it would check the account - And if it looks OK sign the transaction to the merchant - Privacy is fairly OK unless it is a problem that the bank knows your favorite merchants BTW, I think that 3D, SAML et al will create a market for TTPs that did not exist a year ago.
