[14001] in cryptography@c2.net mail archive
Re: invoicing with PKI
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Tue Sep 2 17:13:58 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 02 Sep 2003 15:02:50 -0600
To: Hadmut Danisch <hadmut@danisch.de>
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: iang@systemics.com, cryptography@metzdowd.com
In-Reply-To: <3F537280.FF3B5F8F@systemics.com>
At 12:23 PM 9/1/2003 -0400, Ian Grigg wrote:
> 1. invoicing, contracting - no known instances
> 2. authentication and authorisation - SSL client
> side certs deployed within organisations.
> 3. payments
> 4. channel security (SSL)
> 5. email (OpenPGP, S/MIME)
somewhat related thread in sci.crypt ... summary
http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
background
http://www.garlic.com/~lynn/2003l.html#24 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#27 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#28 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#32 RSA vs AES
when we were working with small client/server startup for payments
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
we coined the term "certificate manufacturing" as part of doing due
diligence on various commercial CAs ... to distinguish from PKI.
we've also since claimed that proposal, effectively by SSL server
certification business ... to have public keys registered as part of the
domain name process goes a long way to both 1) improving the integrity of
the domain name infrastructure and 2) provides basis for trusted, real-time
public key distribution making SSL server certificates redundant and
superfluous.
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
One of the big issues with identity x.509 certificates from the early 90s
was the quandary with 1) overloading a certificate with huge amounts of
privacy information (hoping that its use by unknown relying parties at some
point in the future would find something in the certificate useful and 2)
the extremely onerous privacy issues with the spraying of such privacy
information all over the world. Somewhat as a result, financial
infrastructures dropped back to relying-party-only certificates ....
something that effectively contained only the public key and the account
number.
http://www.garlic.com/~lynn/subtopic.html#rpo
Somebody from Deutsche bank made a presentation in 1998 regarding having
moved to relying-party-only certificates because of the enormous privacy
and liability issues. However, since Duetsche bank had issued the
certificate for the public key (and account), Duetsche bank already had the
public key on file. There was actually nothing in the appended
relying-party-only certificate that carried any information that Duetsche
bank didn't already had on file (and the elimination of the requirement to
append a certificate tended to remove a large payload penalty).
It was relatively trivial to show for financial transactions that
relying-party-only certificates were redundant and superfluous (i.e. the
financial institution already has all the information so there is no reason
to tack a certificate on to the end of every transaction or communication
with the bank).
The other issue ... somewhat highlighted by SET was that the payload
penalty for certificates in the payment infrastructure was enormous ... a
basic SET certificate possibly being two orders of magnitude larger than
the basic payment message. As a result, SET typically was deployed for
internet only operations with a gateway between the internet and the
payment network performing the signature verification, stripping off the
certificate and flagging the real payment transaction indicating that the
signature had verified. First of all that violates one of the basic
principles of end-to-end security. In fact, somebody from VISA presented
some numbers in an ISO standards meetings about the transactions flowing
through interchange with the "signature verified" flag set and they could
prove that no digital signature technology was ever involved.
The financial standards x9a10 working group was given the requirement to
preserve the integrity of the financial infrastructure for all electronic
retail payments (aka ALL as in internet, non-internet, point-of-sale,
face-to-face, non-face-to-face, debit, credit, ach, stored-value, etc ...
i.e. ALL). The result was a digital signed transaction that was lightweight
enough that it would operate in all environments and didn't require the
enourmous payload penalty of an appended certificate:
http://www.garlic.com/~lynn/index.html#x959
NACHA tested a certificate-less digitally signed debit transaction in their
Internet trials:
http://www.garlic.com/~lynn/index.html#aadsnacha
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
