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

From: [email-masked]
Date: Sat, 17 Jul 1999 14:25:42 -0700

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.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jul 1999 16:34:54 -0400

Lynn,

>using account record information.

I am certainly willing to believe that merchants said they were validating
SET transaction sigs when they were not, but certainly the rationale for
carrying a cert with the transaction, as far as the merchant, was to permit
such validation.  So, let's not confuse what the architecture was desigend
to do vs. what people may be doing right now.  If we did that with
cert-full systems, and used current browsers as examples, we'd get a
terrible model of how X.509 certificate validation is done, for example :-).

>key to the consumer's account record.

Presumably the issuing bank has access to these certs, in whatever format,
and how they access them is a purely local matter, hence not a subject of
standardization. Thus I am not surprised that this would not become part of
the SET spec.

<snip>

>account records ... which makes it harder to show that they aren't

What you describe is a traditional ACL vs. capability model, but with a
blurring of authentication vs. authorization.  The cert-less approach you
describe argues that authentication and authorization must always be tied
together, whereas the infosec community (as well as all the standards I
know of) have always felt the two are independent.  For exmaple, one can
authenticate a user for audit purposes independent of any authorization
decisions.  Also, in rule-based access control systems, one can grant
access independent of knowing the identity of the user, allthough some part
of the system usually does have authentication data available for
accountability.  Because systems may distribute authorization data
separately from authentication data, it is generally attractive to be able
to support these two distinct services via separable mechanisms, separate
databases, etc.

Steve