At 01:44 PM 9/9/2003 -0400, Ian Grigg wrote:
Anne & Lynn Wheeler wrote:
>
>  The result is X9.59 which addresses all the major
> exploits at both POS as well as internet (and not just credit, but debit,
> stored-value, ACH, etc ... as well).
> http://www.garlic.com/~lynn/index.html#x959


Lynn,


Whatever happened to x9.59?

Also, is there a single short summary description of what
x9.59 does?  I don't mean a bucket full of links to plough
through, I mean some sort of technical overview that wasn't
approved by the marketing department.

iang


look at:
http://www.garlic.com/~lynn/index.html#x959

and it has a pointer to the standards document at ANSI. I think there may be some discussion at the oct. x9 meeting about progressing x9.59 to ISO.

but slightly simpler description is the mapping of x9.59 to iso8583 (basically the credit/debit network standards protocol) at:
http://www.garlic.com/~lynn/8583flow.htm


the above lists the x9.59 elements and the iso 8583 elements .... and some mapping equivalence ... and how to carry the additional x9.59 values in an iso 8583 addenda field .... so you can achieve end-to-end authentication .... rather than truncated high integrity authentication at something like a boundary interface between the internet and the real payment infrastructure .... show how x9.59 can operate in all payment card processing environments (not just internet) and be able to provide x9.59 authentication on an end-to-end basis.

In this particular mapping between x9.59 and iso 8583 ... the original signed x9.59 object isn't carried end-to-end ... but there is a methodology defined for being able to reconstitute and verify the x9.59 object and the issuing financial institution.

The X9.59 standards document actual lists the ASN.1 encoding for the signing object (and therefor any reconstituted object) ... although there has been investigation into a x9.59 "version number" for XML specification. One of the original issues for XML encoding specification was that there was no deterministic encoding rules for XML .... allowing for an object to be mangled in transmission and then reconstituted for authentication. This is something that FSTC
http://www.fstc.org/
did for FSML .... the deterministic encoding rules to cover the scenario where a signed electronic check object was mangled for transmission thru the ACH network ... and then had to be reconstituted for signature authentication. Since then W3C has incorporated FSML into the xml signature specification work. some overview:.
http://www.echeck.org/overview/echecktech.html


The problem wasn't whether XML or ASN.1 was better encoding method ... the issue was that given that the signed string of bits were mangled during transmission and how to be reconstituted, there had to be identical, deterministic encoding rules at both the signing end and the authentication end. This was very close to what was used in the NACHA AADS trials ... reference at:
http://www.garlic.com/~lynn/index.html#aads


Although not in available document ... there was work mapping x9.59 directly to ACH network (the message formats in ACH are different than the message formats in the payment card networks .... actually many of the payment card networks ... both interchange and various acquiring networks ... have frequently proprietary differences from the ISO 8583 .... although there is lots of recent work to achieve convergence). These are primary electronic electronic networks for payment transactions. There has also been some work mapping of x9.59 to wholesale networks, aka FEDWIRE, SWIFT, etc. The original X9.59 work was done in X9A which deals with retail standards. In the past there has been some differentiation between the retail and wholesale financial networks under the assumption that the values in the wholesale transactions were a lot larger and therefor required much higher level of security which, in turn, should cost significantly more. However, I think we managed to demonstrate in X9.59 a level of integrity that is as high as anything required for wholesale transactions at the same time being able to achieve a cost that was acceptable for retail transactions.

To be effective ... the standard deployment just about needs a hardware token that can be trusted to house the private key and perform the signature operation. My joke from 5-6 years ago was that I was going to take a $500 mil-spec part and cost reduce by it two orders of magnitude while at the same time increasing the security ... and cut the time & power requirements so that it could meet the transit gate elapsed time requirements in a ISO 14443 contactless configuration (the transit constraint model was basically the octopus sony/mitsubishi card used in HK transit system)..
http://www.garlic.com/~lynn/index.html#aadsstraw


I needled the chip module guys on this subject at a talk I gave two years ago at the intel developer's conference trusted platform track ... that it took them several years to iterate to nearly the same design point. The guy that headed it up ... claimed it was because I didn't have a committee of 200 people helping me .... a zip'ed copy of the presentation is listed a little lower in the AADS section of the web page (in front of the taxonomy/glossary section of the web page):
http://www.garlic.com/~lynn/indexlhtml#aads


--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm



--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to