Re: Confirm decision on identity handling.

["Scott G. Kelly" <scott@airespace.com>]

Hi Charlie,

Thanks for commenting on this. I've seen some other comments that lead
me to see that this is indeed useful under some circumstances. I guess
my objections would be overcome if we implemented what I think was one
of Steve Kent's suggestions, i.e. if we specify (somewhere) how an ID
which does not match the cert in some way is bound to the cert (and the
policy rule) in the SPD. I think mcr's and Jim Knowles' suggestions for
see-the-cert-dummy ID payload type would be useful as well.

Scott

Charlie_Kaufman@notesdev.ibm.com wrote:
> 
> "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