x9.59

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com