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 th
