A note on vendor reaction speed to the e=3 problem

[Anne & Lynn Wheeler]

Taral wrote:
> *That* is the Right Way To Do It. If there are variable parts (like
> hash OID, perhaps), parse them out, then regenerate the signature data
> and compare it byte-for-byte with the decrypted signature. Anything
> you don't understand/control that might be variable (e.g. options) is
> eliminated by this process.

FSTC originally created FSML for digitally signed xml encoded data ... which was then donated to w3c and became part of xml digital signature specification.

the issue for FSTC was "e-checks" ... where originator took fields from ACH transaction ... encoding them in XML, digitally signed the XML encoding, and then appended the signature to the original ACH transaction. the recipient received the ACH transaction ... duplicated the original XML encoding process, computed the hash ... and then compared it to the decoded signature (from the ACH transaction append field).

the original issue for FSML was that XML didn't have a bit-deterministic encoding process ... which could result in the originator and the recipient getting different results doing XML encoding of ACH transaction fields.

X9.59 financial transaction specified something similar
http://www.garlic.com/~lynn/x9.59.html#x959

which allowed originator and recipient to perform deterministic encoding of standard financial transaction (in manner similar to FSTC e-check process) ... where the signature was carried in standard electronic transaction append field. the base standard specified ASN.1 encoding ... but the fully constituted x9.59 fields included a version field ... the purpose of which included being able to specify an x9.59 version that used XML encoding (rather than ASN.1 encoding).

the standard just specified all the fields and ordering for the encoding.

there were sample mappings between the fields in the standard and fields in various
existing financial transactions. if x9.59 called for fields that weren't part of
specific financial transaction ... then those fields needed to be carried in the transaction append/addenda, along with the digital signature (i.e. the digital signature was appended
to standard transaction in unencoded format, it wasn't required that the encoded format
being transmitted ... just that the encoded format could be reproduced in a deterministic manner). 

old write-up giving correspondence between x9.59 fields and some fields from some
common financial transaction formats (includes a proposed xml tagged encoding)
http://www.garlic.com/~lynn/8583flow.htm

part of the issue for the x9.59 specification was the requirement for a standard that preserved the integrity of the financial infrastructure for all retail payments (ALL, including point-of-sale).

A typical point-of-sale payment card transaction avgs. 60-80 bytes. By comparison, some of the PKI digital signature based specifications from the period had enormous payload bloat resulting in 4k-12k bytes ... aka increasing transaction payload size by two orders of magnitude (100 times).
http://www.garlic.com/~lynn/subpubkey.html#x959
http://www.garlic.com/~lynn/subpubkey.html#certless

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com