Hi Nils,
Now, I am getting really curious about what document precludes or allows
several similar object per ID.
In fact, I even wonder what it would mean to have several private keys
sharing the same ID. You can't retrieve them and figure which one you
prefer... the key is used by the card and all you get is a result
(signature). This makes me doubting that various similar objects could
share an ID.
Would (AuthID | ID) be a unique identifier ? I.e. the right object with
the desired ID would be unique for a given AuthID (but there could be
several objects with the same ID and a different AuthID)...
This way, selecting the right object becomes a matter of logging in
(with an AuthID) and then selecting an object (by ID).
I am just guessing here as I do not have access to ISO 7816-[4,5] to
verify and I can't find relevant information in PKCS#15.
Can you share what you know about this ?
thanks,
fred
On Tue, 2006-02-07 at 21:54 +0100, Nils Larsch wrote:
> Christian Horn wrote:
> ...
> >>>I have an idea for a different implementation: leave the current counting
> >>>of certs as it is. When an application tries to use cert with an ID that
> >>>has no private key with the same ID decrease the ID until we hit the ID
> >>>of an existing private key. That way i could still address all certs on
> >>>the card, which is a problem at the moment with the dirty hack.
> >>>OpenSwan should a) ask for the cert with ID 2 and get it, and b) ask
> >>>for privatekey ID 2 and get it.
> >>
> >>this would require a changes in every application using libopensc
> >>(including pkcs11), hence not a good idea :)
> >
> >
> > Please make me understand how they would break :)
> >
> > As i see it the only change would be in OpenSC. Just bevore returning a
> > 'could not find private-key with the ID you requested' it would try to
> > get the private-key ID-1 and return that if possible.
> > This would help with OpenSwan for my kind of smartcard.
>
> if the application asks the library for a key with a certain id
> the library should return this key object (if it exists) and
> nothing else. Otherwise the library would return something the
> application would not expect (as returning a key with a different
> id contradicts the specification of the function), hence break
> the api. Of course one could add a new function returning a private
> key object for a specifc cert/public object, but this would require
> changes in the applications using opensc.
> Furthermore such a new function wouldn't be usable for pkcs11 as
> the pkcs11 api doesn't support this functionality ...
>
> >
> > Downsides i see are
> > - applications expecting to get a 'no private-key of that ID there'
> > - making this workaround for a probably low number of cases
> > - the cardtype the workaround is for isnt even fitting into
> > PKCS#11-recommendations
> >
> > Just discovered that signing/encrypting with pkcs15-crypt gives me
> > 'Compute signature failed: Buffer too small' / no message at all, and
> > no output-file, grmpf.
>
> what did you exaclty try to do ?
>
> Cheers,
> Nils
> _______________________________________________
> opensc-devel mailing list
> [email protected]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
