Subject: RE: A challenge (addenda)

From: [email-masked]
Date: Tue, 11 Feb 2003 09:23:36 -0700

ref:
http://www.garlic.com/~lynn/aadsm13.htm#13

in fact, i would assert that is one of the short comings of mistaken the
certificate being the binding ... as opposed to representing the business
process of having done the binding.

in lots of businesses ... they will do their own binding business process
.... based on their own business requirements. that is somewhat the
appearance of the relying-party-only certificates as opposed to the
earlier, one-size-fits-all, identity x509 certificates.

the issue is that the relying-party-only certificates are very analogous to
a bank issuing a payment card .... originally one for every account or type
of account. this is in the old offline days .... the merchant (standing in
for the bank) in an offline environment examined the card and checked it
against a paper booklet negative list mailed out once a month or so. in the
transition to the online environment, a magstripe was placed on the back of
the certificate .... and online transactions were being performed directly
with the bank. this representing somewhat of a schizophrenic identity for
the piece of plastic .... since it now carried the characteristics of
operating both in the offline environment (the plastic credential and the
paper booklet) or in an online environment (the magstripe on the back).

From a consumer perspective ... the incomplete migration to totally online
.... has had a down side .... potentially tens of plastic cards needing to
be carried around.  The magstripe is just on the verge of not having to be
unique. It still is shared-secret based (account number and pins) which
standard security requires unique shared-secret for different security
domains.

A migration to totally online and a migration to non-shared-secret (say
digital signature public key) would eliminate the security requirement for
1) unique physical certificate/credential that is used in offline
situations by stand-in parties/merchants responsible for examining the
validity of the (plastic) certificate and 2) unique shared-secret.

The assertion is then that a single hardware token performing digital
signature authentication can be used as binding device in multiple
different contexts (since there is not the uniqueness security requirement
that exists for shared-secret paradigms) and that the token would only
require a certificate representing each of those binding contexts if the
token were to be used in offline operations (requiring validation by 3rd
parties not having access to the responsible binding authority). As long as
the token was used in online transactions involving the business process
that was also the binding authority .... or in business processes with
entities that had online access to the binding authority ... then
certificates representing such binding business processes are redundant and
superfluous.

So the scenario is some future environment that is extensively digitally
signature authentication oriented with some token. Continuing to emulate
the old offline paradigm where a unique token/certificate exists for each
context potentially means that individuals carry hundreds of such tokens.
This is somewhat analogous to the evolving copy protection paradigm of the
early 80s where each application required that a unique floppy disk had to
be inserted.  If this were to continue into today's environment an
individual would have hundreds of copy protection floppy disks .... and
constantly swapping floppy disks ... simarily one could imagine having
hundreds of hardware tokens and having to constantly swap them.

Now there is some possibility of just returning to the simple,
one-size-fits-all, identity x509 certificate. However, there is still the
idea of binding a person to a specific bank account. Just because a person
has a x509 identity certificate doesn't mean that they can draw money from
every account at every bank (or the existance of a x509 certificate doesn't
equate to being permitted to perform all possible business operations). If
there is a single certificate ... and it represents all possible binding
operations ... then either the information about all such bindings has to
be carried in the same certificate ... or the bindings have to be available
at some online location. So doing the mapping of the offline certificate
paradigm to an online binding environment .... would imply that some value
from the certificate is registered in the online binding
registry/account-record.  However, if some value is to be registered ....
it is possible to have an account number and the binding registry directly
registers the public key
This bypasses the levels of indirection involved in registering something
about a certificate which is offline representation of the business process
of binding/registering something about the public key.
If I were going to register something about a certificate in an online
binding registry (say is a specific entity entitled to withdraw money from
this specific bank account) .... and a public key certificate is just an
offline representation of some other online binding registry/authority
(that just possibly isn't always online or directly accessable) ... I
assert that it is possible to register the public key directly and dispense
with the levels of indirection related to registering anything about the
certificate.

So lots & lots of certificates ... each uniquely carrying some collection
of possible binding attributes (like permissions, authorizations, etc). Or
a few certificates .... that only carry a very few binding attributes
related to a public key. Then individual operations carry online account
records with the actual permissions and a mapping to some value in a
certificate. However, it is possible in such situations to eliminate the
indirection of registering the certificate that maps to the public key ...
and just register the public key. Normally, levels of indirection help when
they allow change w/o affecting all the binding registries .... aka in the
internet domain name system .... I can use the host name www.something ...
and not need to worry about it may having dozens of different ip addresses
that can change over time.  However, if i'm dealing with a certificate
indirection infrastracture that I know is a direct mapping to a single
public key and the same certificate will never mask a remapping to a
totally different public key then I can bypass the certificate indirection
and just record the public key.

One such situation would be a generic employee certificate .... there are
lots and lots of them .... all mapping to different public keys. There is
an environment that doesn't have (or need) direcl access to the online
employee binding registry and only cares whether somebody has a valid
employee binding (represented by their generic employee certificate) but
doesn't actually care who the employee is (and the situation is low-value
enough that it doesn't require real-time access to the real employing
binding registry). However, this has the down-side attribute that it
represents the lots & lots of certificate paradigm.  a unique generic
certificate is required for each unique (low-value) domain (work, home, ISP
login, specific website, etc). As soon as something like ISP login requires
specific authorization information .... it is either in the certificate ...
or in an online account record. If it needs to register a unique value from
a certificate that is unique for each authorized public key ... then it can
go ahead and register the public key directly and dispense with any
registering of anything related to a certificate (and some other agency's
binding operation).

An ISP family certificate would work if it listed a dozen different public
keys ... and the certificate could change the listed public keys in a
trusted and reliable way that the ISP need never be aware that it was
happeing. However, in the internet domain name scenario this works because
it is an online registry .... there aren't these offline credentials
(representing the binding process) with long lifetimes floating around that
can go bad and potentially need constant checking for revokation.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm