David,
On 4/7/2016 15:49, David Woodhouse wrote:
On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:
The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single PKCS#11 object in a single token. Since the same cert can
exist in multiple tokens, but there can only be one CERTCertificate*
pointer for all of them, the only way to resolve the issue would be
for the lookup function to return something other than just
CERTCertificate* alone. PK11_ListCerts does that.
Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which
is why it has that crappy O(n²) behaviour? Does it *really* return more
than one of the 'same' certificate? Don't you *still* get a randomly-
chosen one with unpredictable contents of cert->slot?
It depends on the argument to PK11_ListCerts .
typedef enum {
PK11CertListUnique = 0, /* get one instance of all certs */
PK11CertListUser = 1, /* get all instances of user certs */
PK11CertListRootUnique = 2, /* get one instance of CA certs
without a private key.
* deprecated. Use PK11CertListCAUnique
*/
PK11CertListCA = 3, /* get all instances of CA certs */
PK11CertListCAUnique = 4, /* get one instance of CA certs */
PK11CertListUserUnique = 5, /* get one instance of user certs */
PK11CertListAll = 6 /* get all instances of all certs */
} PK11CertListType;
The cert->slot is still random. But you will get multiple cert list
entries with the same CERTCertificate*, but a different appData, if you
use the value that don't have "Unique" in the name.
OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?
It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?
In theory, yes, the slot for the key is what matters. The problem is if
you use cert->slot to look for the key (or even a NULL slot, to search
all slots).
You might end up with the "wrong" key object. Unlike for
CERTCertificate, identical keys in multiple tokens don't share a single
SECKEYPrivateKey object.
Of course, since the private key may not be extractable, it's not really
possible to compare private keys between tokens. But you could match
them by public key.
Fortunately, that is not an issue here, but the behavior is still
confusing since it's different than for DER certs.
I believe there can be multiple SECKEYPublicKeyStr objects also, even if
they are identical public keys, but not 100% sure.
I understand why 'key may not match the "token" in the original lookup'
might matter. Not clear why the others would matter — are those really
requirements that we should try to fulfil?
Well, the fact cert may not match "token" isn't necessarily an issue.
But it's definitely an issue for the key.
I'd combine those final three into a single string. It can be a
filename (perhaps starting with 'file:'), it can be a PKCS#11 URI
starting with 'pkcs11:', or it can be another form, which can happily
include subject/issuer/serial in some combination.
But yes, that makes a certain amount of sense.
I'm glad :)
I plead ignorance with TPMs. Is there a technical reasons why you
couldn't manipulate TPM objects as PKCS#11 objects ?
I forget the precise details but it's to do with the different PINs and
the management thereof, IIRC. The model isn't directly compatible.
Thanks.
Yeah, it's a separate engine. Working on fixing that :)
And if you find any app shipped in Fedora which *doesn't* support it,
please do file a bug.
Since I don't use Fedora, that is unlikely. The Linux we support is
either RHEL, or OEL which is some RH fork, not quite sure from what
tree. Dev is mostly done on OEL.
Yeah, but solving it for PKCS#11 is still a very big step forward for
usability. On Linux platforms it still gives us *consistent* access to
a key either in a hardware token, or in a software token like GNOME-
keyring's or even the NSS user database in ~/.pki/nssdb (although
there's more work to be done before that's easy).
Yeah, AFAIK Firefox/Thunderbird still don't use DB in the user's
directory. Also, they still don't use the sqlite DB.
Most server apps want to have a separate DB, also, in their own
location, not the home dir.
Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
