On 11/27/06, Joe Orton <[EMAIL PROTECTED]> wrote:
> And if you wish to be nice to users, you can enumerate existing
> certificates, I don't know how much you wish the API to be flexible...
> In order to display the user a set of available certificates you need
> to enumerate objects:
>
> list = pkcs11h_certificate_enumCertificateIds ()
It sounds like it would be useful to expose that too.
Great!
So you can provide the means to load several PKCS#12 files end
enumerate them too...
You see... I don't see a different between PKCS#11 based object and
file based objects.
As I see it, we you initialize the interface, you provide all your
identities...
And then you can enumerate objects, select the correct one or prompt
for passphrase.
The problem with PKCS#12 files is that you need the passphrase before
you can parse the certificate... Because of this, projects tends to
provide cert/key files.
I just want to encourage a single functionality for all cases...
> Well... The callbacks should be common to sessions... And I think you
> should add such callback to PKCS#12 as well, when user should be
> prompted for passphrase.
Do you mean common to *all* sessions; does the library require that to
be so? This means process-global state!
Haaham... Sorry about that.
There is nothing I can do... PKCS#11 is global context.
> Also there should be a way to specify somekind of configuration, for
> example which providers to load, provider specific parameters etc...
This is where supporting hardware tokens generally gets really awkward -
providers will be process-global state, is that correct?
True.
You need to load shared library for each provider, initialize it (globally).
I though of hiding this part in pkcs11-helper, but then I realized
that I may break some providers... So yes... Global context...
Best Regards,
Alon Bar-Lev.
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon
