invoicing with PKI

[Anne & Lynn Wheeler]

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 at metzdowd.com