On 02/10/2010 12:18 PM, Andreas Jellinghaus wrote: > Am Mittwoch 10 Februar 2010 17:59:18 schrieb Daniel Kahn Gillmor: >> All spelled out, my proposal is: >> >> * the filesystem can supply certificates, certificate requests, or raw >> public keys in ~/.eid/authorized_certificates >> >> * pam_p11 extracts the RSA public key from these, to create a set of >> public keys. >> >> * the card produces a set of public keys bound to authentication slots, >> either embedded in X.509 certificates or as raw public keys. >> >> * the system finds the first public key which is in both sets, and asks >> the user to authenticate to the corresponding slot on the card >> >> * the system grants the authentication based on whether the card can >> properly compute the response to the RSA challenge using the >> user-supplied PIN. >> >> Does that make it clearer? I probably should have written it up like >> that earlier. > > ok, sounds nice. not sure how many users want to use CSR or pubkeys instead > of certs, but if these formats can be detected easily, then it is propably > not too much code to read them and extract the public rsa key, no matter > which format was used. but I have little clue about openssl API, so I > can't tell.
the openssl API is a bit hairy but i don't think it'll be too horrible.
i might also drop the CSR option in that first step, because it's just
a really weird carrier for a public key; far less likely than a raw
public key.
and if we're adding weird public key carriers, i can think of other ones
i'd prefer to an X.509 CSR.
> no issue at all. hope you don't mind me closing it maybe a bit too fast.
not a problem. it was a good incentive for me to clarify what i was
talking about ;)
--dkg
signature.asc
Description: OpenPGP digital signature
