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

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 

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 
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 
common financial transaction formats (includes a proposed xml tagged encoding)

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).

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

Reply via email to