[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Confirm decision on identity handling.



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

It's transitional cases like this that I always
wonder why people don't just use a hash of the
public key as the "password" instead. Since it's a
baby step as you state, it *does* eliminate the
(manfiestly) daunting task of issuing
certificates, and still gets rid of static keys
and all of their downsides.

Has a BCP ever been written about all of this? My
sense is that confusion and timidity is one of the
larger problems here since it's about "security"
and thus frightening. There seems to be a pretty
large gap with people's professed desires (certs)
and its mismatch with reality (ie, legacy
creds...), helping the transition to public key
based authentication would be a generally Good
Thing, I'd think -- even if it doesn't make it to
the PKI promised land.

		Mike