Re: QCA KeyStore API updated

On 4/5/07, Justin Karneges <justin-psi2affinix.com> wrote:
> TokenAsker requires the token and entry.
> PasswordAsker requires the token.  Entry is optional.

I think the behavior of all askers should be the same...
Also get same parameters...
For example why password accepts keyStoreId?

But thank you for allowing token to be NULL...

OK... Now, I expected that when I insert the token, qcatool
will
automatically detect this, and not wait for <Enter>...
If I remember
correctly this is what we discussed in the past. Should I
add
something to the provider in order to make it work?

> > But... most importantly... when a token is
requested the high-level
> > object which caused the request is not always
available.
> > This is common both to Password and Token
askers... They ask for
> > information common to the whole token, not to a
specific object.
>
> Well, if it is a large problem, we can make the entry
id optional for token
> events.  Entry id is already optional for password
events, as I mentioned
> above.  I assumed that the entry info would always be
known for token
> prompts, since they would be passive entries.  However,
if you end up losing
> this information in your abstraction, we can relax the
requirement.
>
> That said, I think entry id in events are neat.  I like
how the GnuPG plugin
> asks for the specific PGP key needed for a passphrase. 
It would be nice for
> smartcards.

I added this.

As I see it... And I am so sorry that I always come up with
different designs...
The high-level API should have a context for every operation
triggered
by user, this context is forwarded to every atom in the
chain of
implementation.
Now... If an asker is triggered it lookup the details needed
from the context.
This way, the low-level component should not be aware of the
higher
level details.

In our example, the user begins a sign operation, a context
is
created, the entry is added to this context, the provider is
called in
order to perform the signature, the provider requests more
information
(token, password), the asker lookup friendly name from the
context and
prompt the user.

> > So provider should provide an object which bundle
the private object
> > and the public object, then these two objects are
moved into
> > higher-level object which complete the information
from all sort of
> > sources and provide it to the user.
>
> Yes, this way makes sense.
>
> However, I still like the idea of chain completion in
qca-pkcs11 keybundles
> because it works well in the absense of such a system. 
And, if/when we do
> add such a system, it would not break because of it.
>
> I'll think about how we might implement the
intermediate object handling, but
> I have no schedule.

Do we have any other schedule? 

Best Regards,
Alon Bar-Lev
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Thursday 05 April 2007 7:24 am, Alon Bar-Lev wrote:
> On 4/5/07, Justin Karneges <justin-psi2affinix.com> wrote:
> > TokenAsker requires the token and entry.
> > PasswordAsker requires the token.  Entry is
optional.
>
> I think the behavior of all askers should be the
same...
> Also get same parameters...
> For example why password accepts keyStoreId?

This is to handle a password-protected entryList.  The
provider would need to 
ask for a password for just the store, since the app is not
trying to access 
any specific entry.

> But thank you for allowing token to be NULL...

Yes, I've updated qcatool to make the entry optional for
both kinds of events, 
so from now on we'll consider this to be allowed.  If no
entry is specified, 
then you must specify a store though.

> OK... Now, I expected that when I insert the token,
qcatool will
> automatically detect this, and not wait for
<Enter>... If I remember
> correctly this is what we discussed in the past. Should
I add
> something to the provider in order to make it work?

That functionality may be possible in a future qcatool, but
only for passive 
entries.  For non-passive, qcatool expects the token/entry
to be present at 
the time of launch (this is because qcatool does the
substring matching, and 
so it isn't quite sure what it is actually looking for).

When your KeyStoreListContext is start()'ed, you should
probe for available 
tokens and emit busyEnd() once you're done with that. 
qcatool blocks until 
this signal is emitted.

> > I'll think about how we might implement the
intermediate object handling,
> > but I have no schedule.
>
> Do we have any other schedule? 

Hmm, good point.   Well, we
can talk about this again maybe after Beta 4.

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com