DOM crypto.generateCRMFRequest argument to force enrollment to a(n unspecified) hardware

RESOLVED WONTFIX

Status

Core Graveyard
Security: UI
P2
enhancement
RESOLVED WONTFIX
16 years ago
a year ago

People

(Reporter: awnuk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kerh-ehz])

(Reporter)

Description

16 years ago
1. To do simple hardware deployments crypto object needs to supply method
   to generate key with specific security module.
   This could be done as extension of generateCRMFRequest() method
   or any other way.
2. Crypto object doesn't supply any methods to list security modules.

I'm on 2001-10-22-18-0.9.4
(Reporter)

Updated

16 years ago
Component: Daemon → Client Library

Comment 1

16 years ago
Can you elaborate?  Do you want the ability to specify which hardware token the
key will be generated (or stored) on?
Priority: -- → P2
Target Milestone: --- → 2.2
(Reporter)

Comment 2

16 years ago
If you need to deploy keys and certificates on hardware only, you don't have
to watch them to be sure that it is done right. It is enough to verify presence
of the specific security module and then generate key or keys on it.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

16 years ago
nsbeta1
Keywords: nsbeta1

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1-

Comment 4

16 years ago
I'm still not sure if I understand you correctly.

Let me try to repeat what you say, and please confirm or explain more detailed.

You want to use generate a certificate/key using JavaScript, and that
certificate should be stored on a hardware device.

You say the JavaScript logic should be able to check, which hardware devices a
user has? And you want that the JavaScript logic can decide on its own, where
the key/certificate will be stored?

In order to reach that goal, you request
- a new JavaScript method to list the installed devices
- an extensions to the certificate generation to request storage on a particular
device

Do I understand that correctly?


Considered I understand you correctly, here is my opinion:
JavaScript methods should not be able to query the user's hardware.
A website could use that to spy out a user.
My understanding is, when a website triggers the creation of certificate
request, and the user has multiple tokens, the application will prompt the user,
and the user will decide on which device the certificate will be stored.
Isn't that sufficient?
(Reporter)

Comment 5

16 years ago
This is actually what I would like to avoid.  Imagine that you would like
to force your employees to use smartcards only.  Current choice is either
watch them picking correct (hardware) module or do the picking for them.
Both situations are requiring human assistance and they are little bit
embarrassing.
This could be avoided by adding to generateCRMFRequest() method,
ability to generate keys on specified module.
It would be even nicer to inform end user that he/she is missing required
(hardware) module.  We could achieve this by making generateCRMFRequest()
return appropriate error or/and adding a new method which would allow
to check the presence of the specific module.

Comment 6

16 years ago
Could we meet in the middle?

Instead of providing a way to iterate over available modules, and instead of
adding a "module name" parameter to the generate key request, we could do
something else: We could extend the key generation method to take a boolean
parameter, that says "only hardware allowed".

If there is no hardware device, Mozilla could display an error message (hardware
device requested but n/a).
If there is exactly one hardware device, Mozilla could use just that one.
If there are multiple hardware devices available, Mozilla could display a list
of all hardware devices (not allowing to select the software device).

Comment 7

16 years ago
We should not design this without imput from Terry Hayes.

The real solution may involve CMC, support on server and client, etc...
If we think this is high priority, we should schedule a design/architecture
meeting.  I'm not sure this is such high priority at the moment.

Note that the relying party (the party who really cares whether the key/certs
are generated on the device) is the issuing CA.

The CA can only certify that the key has been generated on a hardware device if
the cert request from the client contains data that cryptographically identifies
the device.

The CA must have a way to request this extra info from the client.


Summary: Hole in PKI hardware deployments → Force enrollment on hardware device: Hole in PKI hardware deployments

Updated

16 years ago
Keywords: nsbeta1

Updated

16 years ago
Keywords: nsbeta1-

Comment 8

15 years ago
Looks like a dupe of bug 110183
Blocks: 157818
Target Milestone: 2.2 → 2.4
Version: unspecified → 2.4

Updated

15 years ago
QA Contact: junruh → bmartin

Comment 9

14 years ago
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

12 years ago
Whiteboard: [kerh-ehz]

Comment 10

12 years ago
changing obsolete psm* target to --- (unspecified)
Target Milestone: psm2.4 → ---
QA Contact: bmartin → ui

Updated

10 years ago
Version: psm2.4 → 1.0 Branch

Comment 11

10 years ago
this (bug which is focused on letting the web page demand a hardware device) isn't a duplicate of that bug (which is interested in letting the user pick a default target)
Severity: normal → enhancement
Summary: Force enrollment on hardware device: Hole in PKI hardware deployments → DOM crypto.generateCRMFRequest argument to force enrollment to a(n unspecified) hardware
Version: 1.0 Branch → Trunk
Are any other browsers going to implement generateCRMFRequest? I doubt so, and I guess that means that there is no hope for standardizing this. Perhaps, then, we should WONTFIX all the enhancements to this method?
Bug 1030963 removed this functionality entirely.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.