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