Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

[Lynn.Wheeler@xxxxxxxxxxxxx]

oh yes ... and to some extent the cert-less work, in fact grew out of working
on various SET projects (or lets say that the size of the certificate was
compressed
to zero bytes).

1) first off, set doesn't provide end-to-end authentication ... the digital
signature/cert is verified at (essentially) and internet boundary and then the
digital signature and cert is stripped off the transaction before forwarding to
the customers bank for final authentication, authorization, and execution. The
forwarded request does have a flag turned on saying whether the sender
succesfully performed a digital signature authentication. Two years ago, visa
presented some number at a ISO meeting in europe on the number of transactions
coming thru which had the digital signature validated turned on ... and for
which they could proove there was no digital signature capability (one of the
simple hazards of not having end-to-end security). Furthermore, the digital
signature authentication was just a preliminary screening and the consumer's
backend actually performed the real authentication, authorization and execution
using account record information.


2) while not part of the SET specification ... every institution that I know of
that looked at doing SET generated a work request to add the certificate/public
key to the consumer's account record.

3) trying to achieve end-to-end security with transaction that hits the account
record anyway ... in an infrastructure where the base transaction is 60 bytes
and there may be thousands of these per second ... it was a significant task to
get the operational people's attention that they should let an extra 80bytes
pass thru the production infrastructure (digital signature plus a little bit
more) on each transaction.


So applying a little bit of knowledge-based compression on the data to pass thru
the infrastructure ... in order to meet guidelines for end-to-end security ...
started trying to throw out every byte that was absolutely not necessary.

that was when it started to dawn that a certificate contained either all the
information to do the transaction or had a pointer to an account record that
contained the necessary information. If the transaction has to hit an account
record anyway ... then a little bit of knowledge-based compression ...
compressed the size of the certificate to zero bytes.

this is also a result of a more precise definition where the digital signature
authenticates the transaction ... and any certificate is used to authenticate a
public key used in the digital signature ... but certificates doesn't have to be
the only method of authenticating a public key (account records have been used
by businesses for eons for validating various information ... like current
account balance). The certificate doesn't authenticate the transaction ... the
digital
signature authenticates the transaction ... and any certificate is used to
authenticate the public key.

so back to the question in the thread about the  issue of of  certificate PKIs
costs being a downside inhibitor .... it may not only be the raw costs of the
certificate PKIs that is in question ... but also the fact that in several
environments that they may represent redundant and superfulous costs. The issue
then is that for such environments ... either the redudant and superfulous costs
are not appropriate and/or certificate PKIs need to find a way of leveraging
their characteristics for eliminating other costs.

And to re-iterate ... fully qualified identity certificates carrying full
permissions can be used to eliminate use of  account records (which can in turn
raise privacy and security concerns) ... or they just carry a pointer to the
account records ... which makes it harder to show that they aren't redundant and
superfulous.