the limits of crypto and authentication

[Anne & Lynn Wheeler]

Pat Farrell wrote:
> As others have said, and in the spirit of the subject
> of this thread, SET failed for many reasons, many
> of them economic. There was little effort made
> to bribe the merchants, I think there was talk of
> a 26 basis point change in the discount rate,
> which the banks thought was huge and the merchants
> thought was noise. What really killed it
> was the billions it would have cost all
> the banks to issue and manage all the
> certificates.

this was some of the confusion between identification and
authentication. The SET effort was smart enuf to not do x.509 identity
certificates and instead do relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

and they even made comments about the enormous privacy and liability
issues raised with x.509 identity certificates.

They also avoided doing any sort of PKI infrastructure ... aka the
management and administration of the certificates. The effectively were
doing the same stuff as the original SSL domain name certificates ...
for which we coined the term "certificate manufactoring" (to
differentiate from a certificate administrative and management
operation). They basically said that the certificate only contained the
account number ... and the account number could be turned-off at the
issuing financial institution ... making it redundant and superfluous to
also have to have a separate infrastructure for invaliding the certifcate.

So they have an online infrastructure with real-time transactions and
real-time operation of the real information. It is an extremely trivial
additional step to show that then the certificates themselves are
redundant and superfluous.

The cost of the certificates only become an issue if you are talking
about having to pay a trusted third party, $100/annum for every certificate.

So we can take this in incremental steps.

1) you have the consumer's financial infrastructure register the public
key. they then can generate and issue a relying-party-only certificate
to the consumer (containing the consumer's public key and account number).

2) there was work started in X9 financial standards body on compressed
certificates. Even the SET relying-party-only certificate overhead ran
4k-12k bytes. The typical iso8583 financial message is on the order of
60-80 bytes. Even the trivial SET relying-party-only certificates
represented a payload bloat of one hundred times (besides the RSA-ops
inflating processing overhead by 3-4 orders of magnitude).

3) Because of the enormous payload bloat contributed by the
certificates, the digital signature processing was being truncated at
the internet boundary and a standard iso 8583 message was then generated
with a flag turned on indicating that the internet had validated the
digital signature. The merchants had an incentive to see that flag
turned on since that was the basis on which a lower discount was
calculated. At an ISO meeting in europe ... one of the association
network people presented statistics on the number of iso 8583 messages
that they found with the flag turned on and they could prove that no
digital signature technology could have been involved

4) I presented an argument that a valid compressing technology is to
eliminate all fields from the (certificate) contents that were known to
already be in possession of the relying party. Since it could be proved
that all fields in the SET relying-party-only certificate were already
on file with at the consumer's financial institutions ... it would be
possible to eliminate all fields from the relying-party-only
certificates. If they preferred, i would start describing the process of
appending zero byte digital certificates as an alternative to describing
certificateless digital signature operation
http://www.garlic.com/~lynn/subpubkey.html#certless

5) The consumer's financial institution could effectively use the
existing business processes for registering PINs as a mechanism for
registering public keys. That is not known to be an expensive business
process. A consumer's financial institution then could set up a website
where the consumer could later retrieve their (redundant and superfluous
relying-party-only) digital certifcate. There is some integrity
constraints here ... but since the purpose of a digital certificate is
to spray it all over the world ... there isn't a lot of confidentiality
constraints (i.e. it doesn't hurt a lot if other people pick up your
digital certificate). However, since both the public key and the digital
certificate would already be on file ... you could require people to
perform digital signature authentication before picking up their
redundant and superfluous digital certificate. This does have an
unfortunate downside since it highlights that consumer digital
signatures can be validated by onfile public keys w/o needing digital
certificates

6) there were lots of comments that leaving all the PKI gorp in the
hands of trusted third parties was a trade-off of the
$100/annum/certificate against the upfront costs of modifying mainline
production systems. The two problems was that only worked as long as the
PKI stuff was being limited to toy demos. For any sort of producting
roll-out,

a) the $100/annum/certificate would exceed the costs of upgrading
mainline production system,

b) toy demos didn't have to worry about customer calls, if you wanted to
provide a service, you have to take trouble/customer calls. To have
integrated financial institution trouble/customer sevice ... you have to
integrate the public key stuff into the production systems.

aka ... the only scenario where you could use trusted third party
trade-off of $100/annum/certificate against modifying production systems
was in the toy demo stage.

7) concurrent with SET ... we were also working in the X9A10 financial
standards working group ... which had been charged with preserving the
integrity of the financial infrastructure for all retail payments. we
had done many of the detailed business and technology issue examination
coming up with x9.59 standard ...
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

which then made it much easier to spot them in the SET specification.





















---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com