Sorry I didn't find time to read your answers before today. But thanks,
your explanations help me a lot! I guess it's always difficult to figure
out all dependencies in the beginning, one has to know many puzzle
peaces to see what the final picture could look like ^^
Robert Relyea schrieb:
>> 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).
That shows me that I was wrong looking for a list of all existing
symkeys. The application (I guess mozStorage, in my case) must
instanciate and hold a session to every key by itself, if I want to
browse all the keys. That's an important information. So the function I
asked you about last time, the pk11-list-something, must be run by every
application / every instance of an xpcom-component in order to create a
list. I think it's the only way. Fazit: I need to have code that creates
one each time nsSDR is instanciated.
Is the key-sequence itself copied into each key-object-instance, or does
it just point to the real crypto-object? (security question)
I guess the "point to" one should be correct, otherwise one could
continue to use the key object even when the token's removed, as long as
it lives.
>> 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.
Great. I think that make-a-list-pk11-symkeys-function() does
translate/format those attributes for me, and forward them to some
C_something_functions(). At that point I think I don't really care
anymore how that is done, as long as I know that it is done.
This kind of things are points I need to understand more or less before
I know how I can use the already implemented functions in the NSS libraries.
By the way, do I have to remove the reference-counts always by myself,
or is there a kind of "garbage collector" or something?
I was thinking about the best way to handle those key-objects after they
were instanciated when I create a list. I think if it doesn't take
minutes to create them, the best thing to do would be to dereference the
keys and let them "die".
>> 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.
aaah okey! I wondered why they took "C" for "F unction". Now I know :)
>
>> 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;).
LOL thx, at least not a fried one ...yet ^^
>> 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.
Ok, that really confuses me again :) But I think, as long as it's
"inside the token", I don't care. This is the librarie's business (I
hope), as long as the handling of those key's transparent.
>> 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.
Well, now my question: Are both of those key-kinds handled the same way,
or do I have to consider both cases when I create a key object pointing
to those keys?
>>> If I may ask, what is it you are trying to accomplish?
> I'll answer these in a separate email...
>
Thanks. Maybe I should do an uml-schema or something, even if that's not
a lot. But with those dirty lines, I have to think lots myself too,
that's annoying.
After heaving read that mail, many things became clearer.
When it comes to the point that I want to look for the key in all other
tokens, I'll really have to instanciate a key-object-session to every
single one, if I want to be able to look into every one.
But: I also have to create a list of all tokens. I guess I saw a
function that already does that. How does that work, if no NSS object
keeps information about instances of objects like keys, tokens, slots etc?
And: I still have the problem with the GUI. I saw there are some calls
to windows inside functions like password changing or so. But I don't
understand the mechanisms yet, neither where I could set the standard
token/crypto-object to be used, except into a stupid file somewhere on
disk. But I'm sure there's a 0.999999 probability that there's a
convention how to do that.
Marc
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
