> Thank you for your help, I'll answer directly into your answers, too:
>
> Robert Relyea schrieb:
>
>>>
>>> If I remember well, the PKCS11 specs tell that there's exactly 1
>>> crypto-object per token (soft or hardware).
>>
>> FALSE- A token can and does regularly have multiple crypto-objects
>> active at any given time. I suspect getting this wrong will make
>> understanding the rest impossible.
>
>
> thanks, with that correction in mind, maybe some points are going to
> be clearer in a few minutes, when I'll walk through the code again.
>
>
>>> If that's true, I don't understand the key arrays
>>> PK11SymKey *freeSymKeysWithSessionHead;
>>> PK11SymKey *freeSymKeysHead;
>>> in PK11SlotInfo, and neither why they are tagged as "free".
>>
>> These are an internal free list of empty key objects. The are a
>> performance enhancement to reduce the time to allocate a new symkey
>> object. They have nothing to do with actual symkeys. NOTE: I think your
>> confusion, however, is caused by the assumption that there is only one
>> possible key in a token. This is not true.
>
>
> Oh ok, I didn't understand that. My last conception was that
> PK11SlotInfo must be a sort of session-handling object, besides the
> information about a slot, but that's wrong too, I guess. Which
> object/instance holds an overview of all existing (instanciated)
> key-instances with or without an opened session to the crypto-objects
> in the tokens, in NSS?
NSS doesn't hold a list of opened objects (other than a cache of certs).
The application keeps track of the keys it's using. The objects are
reference counted (well most are, unfortunately a few that should have
been aren't). Symkeys are reference counted.
Symkeys know which slot they are in and what their handle is. Tokens
keep track of their own keys themselves. These data structures are
inside each individual PKCS #11 module. A token could "loose" a handle
at any time (usually because it gets removed). When that happens, it
invalidates all it's handles. The symkey structures still exist,
however. When an application tries to use one of those keys it will get
an error (because the token will return an error when it's referenced).
>
>>> My question is:
>>> What do those code-lines do? Why do I need them in order to find the
>>> key-id, before a key can be found using that key-id?
>>>
>>> PK11_SETATTRS(attrs, CKA_CLASS, &keyclass, sizeof(keyclass)); attrs++;
>>> PK11_SETATTRS(attrs, CKA_TOKEN, &ckTrue, sizeof(ckTrue)); attrs++;
>>> if (keyID) {
>>> PK11_SETATTRS(attrs, CKA_ID, keyID->data, keyID->len);
>>> attrs++;
>>> }
>>> tsize = attrs - findTemp;
>>> PORT_Assert(tsize <= sizeof(findTemp)/sizeof(CK_ATTRIBUTE));
>>
>> This is a basic set up to do a PKCS #11 C_FindObjects. This call is
>> looking for a key that is already in the token. The call will return a
>> handle, which is the only address we have for the key. For the meaning
>> of this you really need to be familiar with the PKCS #11 spec.
>
>
> Thanks, I'll look for it in the specs. But if I now know there are
> several objects in a token (that must be sooo basic, I feel like a
> stupid chicken), I guess C_FindObjects uses those attributes to look
> for an object that matches them, isn't it?
Yes.
> Do C_something functions (I read in the specs C stands for "function")
> refer to operations on the pk11libraries of a module-provider?
yes. The C_ stands for "Cryptoki", which is the old name for the PKCS
#11 spec. The definitions of these functions are in that spec.
> So the "leafs" of the "implementation-tree" of NSS is always a
> C_something, which is finally executed by the module-libraries, to
> interact with the reader/slots/tokens/objects themselves?
yes. (you are obviously not a stupid chicken, only a tempararily
confused programmer;).
>>> By the way, I don't know why this key is called "fixed", and do I need
>>> to have opened sessions at that point?
>>
>> It's an unfortunate name. It's looking for a TokenKey (which is also an
>> unfortunate name). Fixed == Token == Persistant. A key that does not
>> disappear when the session it was created on goes away, or when the
>> token it's created on powers down.
>
>
> This is a rare point I clearly understand now, I think :-) It means
> one of the crypto-objects inside a token, but one that is a key.
:) So one point of confusion is that sometimes session objects can live
in the hardware token. That is why the names are unfortunate. They are
tied to the lifetime of the key, not it's residence.
>>
>>> I don't know if FindFixedKey() looks into tokens
>>> or looks in existing NSS-PK11SymKey-Objects which already have
>>> sessions opened.
>>
>> It's looking into the token, only for those symetric keys that are
>> Persistant.
>
>
> Are there unpersistant keys in a token? I'll also look for that point
> in the specs.
Yes, they are called session objects. In typical operation they are more
common then the persistant variety.
>>>
>>> If you can see that I'm wrong in my structure-conception, please tell
>>> me ^^
>> Mostly at the very beginning;(.
>
>
> :-D I'm a looser...
No, It's just hard to build an argument when the first step was wrong.
>>
>> If I may ask, what is it you are trying to accomplish?
I'll answer these in a separate email...
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
