Re: Confirm decision on identity handling.

[Greg Troxel <gdt@ir.bbn.com>]

  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?

Perhaps this is far afield, but consider Kerberos usage.  A user has a
principal, which is akin to a certificate with a name (different
namespaces and way of proving identity, but conceptually similar).
Many protocols using Kerberos enable one to say 'log in to the remote
machine as user foo', and the normal ACL check looks at ~foo/.klogin
and sees if the Kerberos principal that authenticated the request is
on the list.

So, I might have a certificate with a name, and want to use that to
prove identity but select different roles on the remote system by use
of the ID field.  The question then becomes if the proved ID is
authorized access under the requested ID.

Given that IPsec currently has no way to link the proved/requested ID
in the IKE negotiation to the application that gets packets over an
SA, this is not yet very relevant.  And, one could claim that this ID
mapping should be done closer to the application.  But, the
'{[k]r,s}login hostname -l username' usage was and is useful.

        Greg Troxel <gdt@ir.bbn.com>