On 2010/05/04 12:10 PDT, Robert Relyea wrote: > 2) almost all tokens mark the private key as private, and it's not even > findable if the token has not been logged in. As Honras and Nelson > pointed out, this is what makes a cert 'yours'. It's also used when > deciding if a cert is usable for client auth or Email signing or > decryption. > > To get around 2, NSS will look for a public key on the token with the > same CKA_ID as the private key. NSS uses the existance of a public key > to infer that the private key probably exists. > > If the token is marked with the publically readable certs/friendly > flag, then NSS will not try to authenticate to it before looking up > certs and depend on the public key semantics to identify 'user' certs.
By "depend on the public key semantics" Bob is referring the the previous paragraph, where NSS uses the presence of a public key object to infer the presence of a private key object that cannot (yet) be accessed because the user is not yet authenticated to the token. > If your token does not have a public key for every private key with the > matching CKA_ID, and you mark your token as friendly, your certs will > not appear to be user certs and NSS will not attempt to use them. As Bob explained two paragraphs above, if your token is marked "Friendly", and you're not logged into it, NSS will not even try to authenticate to that token before deciding if a cert is "yours" or not. Instead, it will rely on the presence (or absence) of a public key object on that token to infer the presence (or absence) of a (hidden) private key object. But that is the ONLY use that NSS makes of the public key objects -- as place holders for the private key objects. On non-friendly tokens, NSS authenticates to the token and then searches for private key objects directly. NSS doesn't need non-friendly tokens to have public keys. Some tokens don't have any public key objects. They have only certificate objects and private key objects. They work fine as long as they're not marked friendly, but if you mark such a token as friendly, then until you login to the token, NSS will search for public key objects, but not find any, and will conclude that the token has no private keys, on the basis that there are no corresponding public keys. > If you then explicity log in, everything will start working for that > token again. Once you're logged in to a friendly token, NSS will search it for private keys, and will find them, and the certs will appear to be "yours'. > This extra behavior is not required by PKCS #11, and that is why NSS > requires explicitly setting that flag before it depends on that > behavior. On 2010/05/05 01:57 PDT, M.Hunstock wrote: > Did you mix public and private key here? I thought NSS looks for the > public key with the matching ID first and the private key is looked up > later, when the user actually chose the cert belonging to it. Hopefully I've cleared that up with my explanation above. -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
