Hi Andreas-- Thanks for the followup on debian bug #509412
On 02/10/2010 03:36 AM, Andreas Jellinghaus <a...@dungeon.inka.de> wrote:
> Subject: user misunderstanding?
to be fair, i don't think i actually misunderstand -- i just think it
should work differently than it currently does ;) let me try to explain.
> pam_p11 needs to work with most pkcs#11 implementations and cards.
> one of the rules it has to follow that way are:
> * many cards have no RSA public keys.
> * private RSA keys are not visible until the user logs in.
fair enough. I understand this point, and my particular device is also
capable of storing/publishing X.509 certificates as well as public keys.
To be clear, these X.509 certificates consist of:
A) Some metadata specifying the certificate holder, the issuer, the
timing/validity of the certificate,X.509 extensions indicating its
acceptable usage, etc.
and
B) and RSA public key.
pam_p11 currently appears to ignore everything in A (e.g. it doesn't
care about the expiration date on the cert, the extensions, the issuer,
etc), and cares only about B. It asks: can the plugged-in-device, in
conjunction with the user-supplied PIN, produce a successful RSA
response from the associated private key?
> thus pam_p11 looks for certificates and assumes that private
> keys for those certificates are present (except for authorative certs).
> this heuristic works well.
(i'm not sure what you mean by the exception for authoritative certs --
can you explain?)
As another clarification: pam_p11 looks to match
~/.eid/authorized_certificates with certificates stored on the smart
card. But since all it cares about is the RSA material, it should be
possible to match against a simple public key as well: just look for
certificates which contain that public key.
If the card does not publish certificates, but *does* publish raw public
keys, it could just match against the public keys directly.
> asking the user for the PIN without knowing, if there will be a
> private key that can be used for authentication, would be wrong.
agreed! i wasn't proposing that pam_p11 wouldn't look at the card to
see if there was a matching RSA key available.
In fact, that would be a bad idea on my particular device, because i
have two keys on it. It's important that the authorized public key be
matched against a particular authentication slot (PIN) on the card and
be able to test that the supplied PIN enables the card to produce a
successful RSA response from the expected private key. We don't want to
blindly try all authentication slots.
But that's not an argument for disallowing raw public keys in the
authorization file.
> yes, smart card world is strange, but I can't fix that :(
also agreed ;) But we can make our corner of it more reasonable.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
