i think you have it confused again.
x9.59 defines fields that require verified integrity and authenticated. so
does the e-check project done by FSTC.
you can show x9.59 transactions in a user-friendly way ... sign
transactions in ASN.1 (and soon XML_ and send them in ASN.1, XML, 8583,
ach, etc.
as i outlined in the previous posting and numerous times previously in past
treads .... X9.59 (and e-check) define fields and encoding mechanism for
supporting verifying the integrity of the tranasaction as well
authenticating the transaction.
as I mentioned in the previous posting and numerous times previously in
past threads ... x9.59 (and e-check) allow the fields to mapped into
existing infrastructures and then be reconstructed for intetrity
verification and authentication.
security 101 teaches end-to-end security and integrity of operation. when
integrity of operation is broken .... either with missing and/or fragmented
security and possibly multiplicity of different operations .... then at
least complexity and opportunity for fraud and additional failure modes are
increased and/or introduced. Simple 101, kindergarten security principles.
For example, separating the actual transaction operation from the
authentication and integrity checking might result in the transaction
operation being executed independently of the authentication and integrity
checking. Trying to match up transaction operation which might be done in
one network on one time-scale .... with authentication and integrity
operations that is done in a completely different network and different
time-scale creates opportunities for things being out of sync, having
different failure modes, extreme complexity of matching up operations in
one context with operations in a totally different context. One of
kindergarten, security 101 things tend to be KISS .... the less KISS and
the more complex .... the more prone the infrastructure is to additional
failure (and fraud) modes.
All other things being equal .... KISS always wins out complexity for the
sake of complexity. Adding a electronic signature to an existing 8583
transaction .... so the integrity of the 8583 transaction can be checked
and authenticated by the issuing bank .... significantly beats out any
process that would send a 8583 transaction via one infrastructure .... and
any sort of electronic signature via a totally different infrastructure
.... and then expect that the issuing financial institution has to match up
authentication and integrity material with a totally independent 8583
transaction that is being processed via totally different infrastructure.
For instance, lets say I walk in the store and do an X9.59 transaction with
a chipcard. The issuing financial institution gets an electronic signature
along with the 8583 transaction, check the authentication and integrity of
the transaction, checks the other information related to the transaction
and sends back a real time approval. The merchant then lets me walk out
with the merchandise.
I would assert that any change that you would make to the above description
makes it less KISS, more complex, and less secure.
[EMAIL PROTECTED] on 11/12/2003 12:57 pm wrote:
The problem with this is the unnecessary narrow definition of end-to
-end security.
# Going through a possibly fraudulent merchant's systems to reach
my bank is indeed end-to-end security but pretty useless such unless
the thing you sign is exactly what is sent to the bank. This is for
many reasons not very practical. At least not on the net.
Using 3D Secure et al you don't have this restriction. I.e. you can
show transactions in a user-friendly way but send transactions in
ASN.1 or XML. Still signatures can be verified towards the
transaction data if you have the transaction- to-viewable-format
transformation logic.
# If I can't trust my bank for performing a transaction on my behalf
I could well do without the bank altogether. Anyway this is what
hundreds of millions people do on their on-line banks so I can
hardly see that it is impossible or security-wise wrong.
Anders
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
