[Delta] API updates
justin-psi2 at affinix.com
Sat Apr 14 14:31:25 PDT 2007
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
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?
More information about the delta