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 [EMAIL PROTECTED]
