ok, let me phrase it that way: a typical card has certificates - non-authoritative belong to the user, authoritatives are part of the chain to the root ca. normal cards don't have rsa public keys. normal cards have a private rsa keys for each user certificate. normal cards need a pin before the private rsa key is visible.
so what pam_p11 does is match the certificates or rsa public key in whatever file against the certificates (or rsa public key inside the certificate). only if it finds a match, it will ask for the pin, and then make sure there is a private key that can sign some random data, and verifiy that signature. if there is no matching certificate the card is refused without ever asking for a pin. switching from looking to certificate to _INSTEAD_ look for public rsa keys only would be a grave mistake, as many cards have no public rsa keys (well, with some cards opensc emulates those, but other pkcs#11 libs don't do that). so with typical cards it will no longer work. you could extend the code, to look also for public keys. but that will only work with some cards, and only with the _openssl module. while it might be a nice solution cards with a public rsa key, but without certificates (opensc can create those), I don't think many cards like that are around. patches are welcome. > 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. IIRC only for the _openssh module, but not 100% sure. > It asks: can the plugged-in-device, in > conjunction with the user-supplied PIN, produce a successful RSA > response from the associated private key? no, it first tries to guess, if there is a matching private key on the card. and the way to do that is to look for a matching certificate with the public rsa key part in it. public rsa key objects only exist with some cards. > (i'm not sure what you mean by the exception for authoritative certs -- > can you explain?) if the "authoritive" flag is set, we assume that this is a CA cert (e.g. root CA cert, or a middle cert in the chain between root CA and the users certificate), and assume that no private rsa key for that cert is present. > If the card does not publish certificates, but *does* publish raw public > keys, it could just match against the public keys directly. you are the first user I remember who wants to use such a feature. using pkcs#11 API without also using x.509 certificates is completely uncommon. and those that have certificates don't need such code. so having a debian bug about this possibility is kind of pointless. if you send a clean and nice patch to add such functionality, I can apply it and release a new version. but since you are the first user in ages to ask for such an uncommon feature, it is unlikely anyone else will implement it, unless you do it yourself. > 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. well, the code should only ask for a pin and use it, if the slot contains a matching ceritificate. so I don't see any "blindly try all authentication slots". yes, we could add an option to limit the pam module to some slot. haven't had a request for it so far, patches welcome. also for alternative locations for those files (the file names implemented are simply the old file names that had been implemented by old modules preceeding pam_p11)... > But that's not an argument for disallowing raw public keys in the > authorization file. the current code is simple, allowing more is adding complexity. if people need more features, they can be added, but so far the code was small and simple and worked without much work. also there is a much bigger and more complex alternative to pam_p11: pam_pkcs11. it has modules, does CA chain certificateion, can check if certiifcates are expired or revoked, can lookup ldap etc. so I'm not sure how much complexity added to pam_p11 would still be good, or when users would be better off with using pam_pkcs11. the whole point of pam_p11 is: it is dead simple. so what do you think is best to do? Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
