Subject: RE: A challenge

From: [email-masked]
Date: Thu, 13 Feb 2003 09:27:04 -0700

my previously post in this thread was more on the semantics of certificates
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)

rather than the most recent post
http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge
which is about 7816 contact smartcard. one of the issues is that 7816 also
pretty much dictates the packaging and form factor.  migration away from
7816 contact to any of the contactless/wireless conventions also can
totally open up the packaging and form factor issues.

my certificate assertion wasn't that you can't have certificates
representing a binding/association registration process, my assertion was
that the certificates .... were actually that ... just a representation of
a binding/association registration process (along with a side note that in
an online environment the use of certificates as a representation of the
binding/association registration process would frequently redundant and
superfluous ... not that it wouldn't work).

My primary points were 1) that it seems that sometimes that the
certificates are mistaken for the binding/associationr registration
business process ... as opposed to just a representation of the
binding/association registration business process (originally targeted for
recipients who would never have been involved in any binding/assication
registration business process) ....  and 2) that sometimes such semantic
confusion can complicate processes with regard to which are addressing the
binding/association registration business process and which are addressing
just the management of things that represent that binding/association
registration business process (especially in an online environment when
having separate representations can be redundant and superflous).

However, just because something may be redundant and superfluous doesn't
mean that it can't work.

The issue in something like login .... is supposedly something has been
registered to allow login .... in the PKI/certificate case, presumably what
has been registered is some information that is bound in a PKI certificate
(name, serial number, etc) ... in addition, the login process has the
public key registration of acceptable certification authorities (that can
be used to validate acceptable certificates to the login process). I've
never claimed that doesn't work ... I've just claimed that frequently it is
possible to show semantic equivalence between the login process
registration of some value out of a certificate and the login process
registration of the public key directly;

The PKI registration process provides a type of information mapping
indirection (somewhat like DNS provides a real-time mapping between
hostnames and ip-address) .... where the CA digital signature asserts to
the equivalence of the information (like a person's name or userid) bound
in a certificate and a public key.  The login process then has a set of
registered CA public keys. In the PKI scenario, the login process gets a
signed message that has an appended digital signature and an appended
certificate. The login process finds the registered CA public key and
validates the certificate, it then uses the public key in the certificate
to validate the signed message. At this point it presumably has a proven
equivalence between the entity sending the message and some bound
information in the certificate (like a name). The login process can then
have its own registry that maps between names found in certificates and
userids .... and uses that to establish a valid login for that userid. The
informaiton assurance mapping goes

I've never asserted that it doesn't work. I have asserted that in situation
where the login process has its own registery and mapping;  that directly
registering an entity's public key bound to a userid ....  can be
equivalent to a entity registering their public key with a CA, the CA
signing a certificate that equates a name in a certificate with that public
key, and then the login process registering a name in a certificate bound
to a userid. The issue isn't that the levels of PKI information indirection
(between public key and userid) don't work, the point was purely that they
may be superfluous and redundant.

This is somewhat equivalent to the IETF pk-init draft for Kerberos which
provides for both certificate (aka PKI) based registration as well as
certificateless based registration .... aka directly registering the
entity's public key. The business process of registering a name from a
certificate as equivalent to a userid .... can be shown to be the same as
directly registering a public key as equivalent to a userid. The issue then
is whether all the additional business processes in support of the various
registering process providing information indirection between the name in
the certificate and the entity's public key provides real value or is
purely redundant and superfluous (given that there has to be a  complex
infrastructure for not only creating the certificates .... but once created
these certificates now also have to be managed).

Now the intersection with certifications and smartcards (actually hardwoare
token) .... was whether there was a unique token/certificate pair for every
environment or whether there was one (or a very small number of) token(s)
could be used across a multitude of environments. If the environment
supported a registration process, then the above assertion that public key
can be directly registered would support that the public key of a single
token could be registered in multiple environments. The counter-argument is
some future environment that has migrated to hardware token authentication
potentially requiring a unique token per environment and an entity possibly
having to manage hundreds of such tokens.

So an additional assertion is an ideal place for certificates is where
there isn't an additional registration process and the certificate is
sufficent for establishing both authentication as well as permissions (aka
all/any generic employee certificate gets an entity through the door).

A corresponding scenario would be a system login that has no userid
directory/registration and when presented with a login message with an
attached certificate .... it is possible for the login process to establish
the complete user environment from just the contents of the certificate
(not requiring a userid directory/registration at all).

The problem is that tends to require a unqiue certificate for each
environment ... which may or may not imply a corresponding unique hardware
token. If it requires a unique hardware token, then the future possibility
is that people walk around with hundreds of hardware tokens.

Moving it out of the digital signature domain but still in the area of
authentication might be biometrics. There is the possibility that a login
process directly registers a person's fingerprint in the userid directory.
The person then types in their userid and applies their finger to a
fingerprint sensor. I assert that the direct registration of a person's
fingerprint in a userid directory is equivalent to the direct registration
of a public key in the userid directory.  However, the downside is that a
person's fingerprint is, in effect, a shared-secret ... anybody copying the
fingerprint representation and being able to regenerate it can impersonate
that entity. The upside of public key registration is that it isn't a
shared-secret, knowledge of the public key isn't sufficient to impersonate.

So sort of a summary .... 1) understanding that the binding/registration
process is indenpendent of certificates that represent that process can
result in better designs dealing with the two sepaate issues and 2) when
there are additional registries (like userid directories) it is possible to
view certificates as a type of information indirection and that such levels
of indirection may be redundant and superfluous (not that they can't work
just that they are redundant and superfluous).

some kerberos related threads:
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and somewhat topic drift ... redundant and superfluous may represent
additional complexity and cost that are hard to justify. From recent
discussion about DNS, KISS, theory, and practice:
http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ...
fyi
http://www.garlic.com/~lynn/2003c.html#24 Network separation using host
w/multiple network interfaces
http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment
http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment

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

[email-masked] on 2/12/2003 8:21 pm wrote:

For better, or worse, the current sc logon to o/s's uses a cert in the
sc.  It could be argued that the sc really only needs to cache the
user's name in an insecure manner, but the point is that a PKI is used
to authenticate the user w/ the sc.  It seems to work.  It's hard to
imagine how it could be improved by some structure other than a PKI.
There is no biz rule associated w/ the authentication.

I doubt that u can argue that it does not work.
I am sure that a better sol'n is possible, that is always true.

So, let's just use sc w/ cert for logon authN.  Ok?  ..tom