Re: Confirm decision on identity handling.

[Charlie_Kaufman@notesdev.ibm.com]

"Scott G. Kelly" <scott@airespace.com>
wrote:
> Basically, every example given
so far uses an ID value which can be
> verified against the cert. Can anyone give a realistic example of
a case
> where we would *not* want the ID to match something in the cert?

Realistic is in the eye of the beholder,
but here is an example that
works for me.

Today, lots of mobile laptop to corporate
firewall systems use
static keys because certificates are
simply too painful. Suppose
I want to use public keys while making
the smallest possible
investment in PKI. So at the corporate
firewall, instead of
storing a username and password, I store
a username and
certificate. The certificate might be
one I got for some other
purpose and it contains - say - my email
address. I put my
username in the IDi field. It is what
the firewall wants to use to
look up my authentication information.
For some users, it has
static keys. But for me, it has a certificate.

In this case, the ID and the cert must
match in the sense that
the cert has to be stored by the firewall
associated with my ID.
But there is no relationship between
the names that could be
pinned down in the spec.

A foolish use of technology? Well, yes.
But likely better
security than with the static shared
keys (since the firewall's
database is no longer so sensitive to
disclosure), and a
useful transition step.

        --Charlie