[Delta] API updates

[Justin Karneges]

On Saturday 14 April 2007 3:43 am, Alon Bar-Lev wrote:
> On 4/14/07, Justin Karneges <justin-psi2 at affinix.com> wrote:
> > The intent is that the token would not be accessed until you actually do
> > a sign/decrypt.
>
> But this has nothing to do with sign/decrypt...
> It has to do with application requesting name()

Well, and that's another idea: doing the enumeration and name assignment at 
the time of the name() call.  However, name() is supposed to return an answer 
immediately and not block, so that wouldn't really work I guess.

> > Passive entries would be created instantly, using either a
> > friendly name (if cached certs are present) or a DN string.  Thus,
> > passive entries stay fast, and we only pay a cost when it is time to
> > perform a real operation.
>
> I disagree... If you give passive friendly name using partial picture
> without enumerating keystores, how do you sync the friendly names of
> the none passive ones? You may have duplicates... Or you should cache
> all certificates ever detected and you make your friendly names be
> very complex.

Suppose the app creates some passive entries of a known store, and then calls 
entryList() to obtain non-passive entries from that same store.  The passive 
entries will have been assigned DN string names, and the non-passive entries 
will have been assigned friendly names.  There won't be any duplicate 
friendly names among all of these entries, simply because all non-passive 
entries have unique friendly names and the passive entries don't have 
friendly names.

Next, suppose the application creates more passive entries from this same 
store.  This time around, the entries would be assigned friendly names (at 
least if they are known to exist in the store, otherwise they would be 
assigned DN strings).  It might be possible that a passive entry has the same 
name as a non-passive entry, but it would be for the same cert.  There is no 
uniqueness problem yet.

The only problem I forsee is if, at this point, the user were to delete a cert 
from the token, re-insert it, entryList() is called, this list has a new set 
of friendly names assigned, and suddenly an existing entry held by the 
application has a duplicate friendly name.  Note that this problem isn't 
specific to passive entries.  To have it happen with entirely non-passive: 
app calls entryList() and keeps some entries, user deletes a cert, app calls 
entryList() again.  The second list might have friendly names that collide 
with those in the first list for different certs.

However, I see this as mostly a non-problem.  If an application ever gets a 
fresh entryList() from a token, it should throw away all other entry objects 
for that token (passive or not, doesn't matter).

> What do you think about the following simple solution...
> Modify KeyStoreEntryContext::serialize() to receive friendly name for
> user choice...
> So we can serialize and deserialize using the friendly name selected
> by the user.
> This solves most of the issues... And the friendly name will be
> constant between instances.

Can you give an example of how this would solve the problem?

-Justin