Basic beginning security 101 is that anytime that you fail to have
end-to-end security and integrity of the operation ..... you open things to
failure and fraud (this can because that the security and integrity
mechnaims doesn't follow the complete end-to-end operation of the
transaction and/or the integrity and authentication mechanisms are
separated from the actual transaction and/or both).. financial industry
x9.59 standard (to preserve the integrity of the financial infrastructure
for all electronic retail payments in all environments) X9.59 has
end-to-end transaction authentication and integrity operation. I think that
you've confused authentication, integrity and reliable signatures again.
Note that the X9.59 standard defines the necessary transaction fields for a
reliable end-to-end signed transaction. The actual standard doesn't define
the signing mechanism.
The appendix of the X9.59 standard contains a mappings of the X9.59
standard to existing payment infrastructures and signing mechanisms. One
such example mapping is:
http://www.garlic.com/~lynn/8583flow.htm
lots more references to X9.59 (including pointer to how to obtain the
actual X9.59 standard document):
http://www.garlic.com/~lynn/index.html#x959
The X9.59 does define the fields in terms of ASN.1 encoding .... but there
is also work on defining the fields in terms of XML encoding. The issue of
ASN.1 encoding vis-a-vis XML encoding, is that the end-points needed to
establish and verify the integrity of the transaction, but also allow the
actual data fields to be carried in various formats defined by the actual
payment network (w/o unnecessary duplication of information and the
associated inefficiency). At the time of the standard, ASN.1 provided for
deterministic encoding of values i.e. given that the originating end-point
and the terminating end-point were going to encode the same values, they
had to come up with the same bit-representation (aka the objective was to
allow that the originating end-point and the terminating end-point arrive
at the identical encoded bit-representation to prove values had not been
altered during transmission and/or processing). There was work in FSTC (the
organization sponsoring this mailing list) on FSML which provided an
extension to XML for deterministic bit encoding of values for the same
reason done by X9.59 .... that the originating end-point and the
terminating end-point could arrive at the same bit-representation (w/o
mandating the format of the values during transmission). The FSML work has
since been encorporated into XML signature work for supporting
deterministic encoding rules. An example tagged encoding is included in the
above appendex URL reference mapping. There is proposal that X9.59 standard
now be updated to include both ASN.1 encoding and XML encoding (with the
enhanced deterministic encoding rules from FSML).
random past authentication and/or end-to-end transaction threads that you
participated in:
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm4.htm#10 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards?
(addenda)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#pcards5 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate?
(addenda)
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment
question
http://www.garlic.com/~lynn/aadsm11.htm#20 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D
Secure
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D
Secure
http://www.garlic.com/~lynn/aadsm11.htm#31 Proposal: A replacement for 3D
Secure
http://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead ...
RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ...
RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#7 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security
Issues
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment
Transaction?
http://www.garlic.com/~lynn/aadsm12.htm#41 I-D
ACTION:draft-ietf-pkix-sim-00.txt
http://www.garlic.com/~lynn/aadsm12.htm#42
draft-ietf-pkix-warranty-extn-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's
Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit
Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit
Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#56 TTPs & AADS Was: First Data Unit
Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#6 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards
(slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook
to SET Standard
http://www.garlic.com/~lynn/aepay6.htm#gaopki3 GAO: Government faces
obstacles in PKI security adoption
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces
obstacles in PKI security adoption
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark
Debate
http://www.garlic.com/~lynn/aepay6.htm#dspki2 use of digital signatures and
PKI
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and
PKI (addenda)
http://www.garlic.com/~lynn/aepay6.htm#userauth2 MS masters NC mind-set
(authentication is the key)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay10.htm#17 Visa 3-D Secure vs MasterCard
SPA Whitepaper (forwarded)
http://www.garlic.com/~lynn/aepay10.htm#34 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#35 some certification &
authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication
white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication
white paper
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and
Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing
Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing
Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing
Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing
Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process,
payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process,
payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process,
payment, authentication and identification
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
[EMAIL PROTECTED] on 11/12/2003 9:15 am wrote:
Maybe it is a bad idea to respond to your own postings but I give it a try
-:)
A logical consequence with the stuff below is that things like EMV, and
X9.59 has no bright future as they cannot support a reliable signature
mechanism except on a cryptographic level. But 3D Secure can! And 3D
Secure is just the first shot in this direction.
Stay tuned
/a
----- Original Message -----
From: Anders Rundgren
To: internet-payments
Sent: Wednesday, November 12, 2003 09:08
Subject: FAQ: e-Signatures and Payments
Extract from an FAQ for an on-line e-signature standards proposal in
progress:
...
That is, DRY Signatures are neither useful nor intended to be used where
the signature requester is unknown or maybe even untrusted by the user.
Does not the "trusted service provider" limit usability?
Although this may be considered as a serious disadvantage of DRY
Signatures, the same limitation is actually applicable to just about all
on-line systems, as both on-line "receipts" and automatic client-side
archival of "evidence" are usually missing. That is, the user must indeed
rely on the service provider to cater for trustworthy handling of the data
involved. Newer on-line payment systems, like VISA's 3D Secure, address
this in a very elegant fashion by instead of requiring users to sign
transactions directly to possibly unreliable merchants, instead routes
payment requests to the user's own trusted and known bank (issuer). By
doing that, users can be reasonably assured that transaction requests are
archived, and that signature requests will always be in the same format as
well as in a language that the user understands. This scheme even allows
fraudulent merchants to be automatically blocked by the bank.
Regards
Anders Rundgren (Editor)
