Hi Anders,
Thank you very much for your reply, and I like your suggestion, I
think the token parameter will handle most cases. However, it seems
it's not gonna happen fast enough for my case. So, is there a
alternative way other than <keygen> that can be used to solve this
problem?
I checked the generateCRMFRequset way, but it seems it cannot
specifies the token either. Besides, I have not found a good way to
handle the CRMF/CMMF from the server side yet, I heard JSS can do the
trick, but changing the whole server architecture for this seems not a
very promising solution for the bank, but that's another story.
Back to the topic, I read from another email that the website JS
when given the authority to use XPCOM, can be used to detect whether a
hardware token is connected to the machine, and which token that is.
Is there a way to maybe specify the token used to generate the
certificate request, and generate the request using JS?
On Sun, Apr 11, 2010 at 4:18 PM, Anders Rundgren
<anders.rundg...@telia.com> wrote:
> Amax Guan wrote:
>>
>> Hi,
>> I'm working on a Certificate renew process for a bank in china.
>> The bank stored the certificate in a USB key, and when the user needs
>> to renew the certificate, the bank will trigger the cert issue process
>> to do that, using <keygen>. But when the issue begins, because the USB
>> key, which is a token, is connected to the computer, that will cause
>> the Firefox detect at least 2 tokens, and a dialog will popup and tell
>> the user to select a token. But, if the user select the software token
>> embedded in Firefox, which is the default choice, then the cert issue
>> process will be in vain, although it may succeed.
>> Is there anyway to automatically select a token for the user, So
>> that the token choose dialog does not appear? Thank you very much in
>> advance:)
>
> Hi Amax,
>
> <keygen> wasn't designed for usage by consumers (and particularly not
> for "hard" tokens); it was designed by Netscape some 15 years ago to
> enable client-certificate provisioning for people who actually know
> both what a token is and a certificate is.
>
> There is no easy fix to the specific issue you are pointing to
> and it has not been recognized by the HTML5 WG as an issue either
> although it as you say is a rather delicate problem.
>
> In a so far only "emulator-ware" <keygen> replacement proposal
> of mine, the above situation is handled by indicating token type
> (soft, embedded, external, any) which in most (but not all) cases
> eliminate token container selection dialogs.
>
> Since banks in the US are ten years behind EU and Asia when it comes
> to PKI for consumers, I guess we cannot expect Mozilla to do anything
> about <keygen> :-(
>
> Anders
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
