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

[Stephen Kent <kent@xxxxxxx>]

Lynn,

>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.

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 :-).

>
>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.

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>

>
>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.

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