"crypto.algorithms" doesn't exist



18 years ago
2 years ago


(Reporter: bugzilla, Unassigned)


1.0 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [kerh-ehz], URL)



18 years ago
In the psm1.4 the object "crypto.algorithms" existed. This is not the case
anymore with psm 2.0

The old documentation for the psm 1.4 at:

the crypto object for the current build can be seen at:

Comment 1

18 years ago
Henrik.  Thanks for pointing all of these to us.
version, target -> 2.0
Priority: -- → P3
Target Milestone: --- → 2.0
Version: 1.01 → 2.0

Comment 2

18 years ago
Mass reassigning target to 2.1
Target Milestone: 2.0 → 2.1


18 years ago
Keywords: nsenterprise
I looked at the implementation of the JavaScript crypto object in
security/manager/ssl/src/nsCrypto.cpp. I suspect the crypto.algorithms object
might have become unnecessary.

The sole purpose of the crypto.algorithms object was to provide information
about available keysizes for the particular algorithms. However, if I look into
the current sources, it might be that there is no longer a restriction on the
used key sizes. At least key sizes are not checked immediately at the interface
level, but passed on to the crypto code (which still might have some
limititations, though).

I suspect the crypto.algorithms object is missing by design, not by error, but I
suggest we ask someone who was involved in implementing the interface
nsIDOMCrypto or implemented the function PK11_GenerateKeyPair.

Comment 4

18 years ago
Kai: ask David whom you should ask regarding your comment. You're leaning toward
making this bug INVALID then. Henrik can comment whether there SHOULD be such a

Comment 5

18 years ago
Adding stevep to cc-list.

According to Javi, this feature can be used by CMS. We should consider it for
2.1 if the CMS team thinks it's important enough.

Comment 6

18 years ago
Moving all P3 and P4 bugs targetted to 2.1 to future.
Target Milestone: 2.1 → Future

Comment 7

18 years ago
removing nsenterprise keyword from PSM bugs with target milestone of future.
Keywords: nsenterprise

Comment 8

18 years ago
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer

Comment 9

18 years ago
We still need a way for the browser application to know what keysizes
are available. Otherwise, the user has no choice about what key size to
generate, and we must then discuss how to automatically choose the key
size for the client.

I guess one argument for having the parameter is so that people writing
HTML pages for certificate enrollment can make sure that the client is
going to perform a key enrollment with an appropriately sized key. If there
is no such enforcement at the client side, then CMS will always reject a
request with too small a key, but this 'wasted' keygen on the client side
has been the cause of complaints in the past. Especially when small-memeory
smartcards have been involved.

Some argument could be made for always choosing the largest keysize, but
not always be acceptable - if the largest key size is 4096. that's very
strong, but it may also be very slow for some applications.
Changing my e-mail address.
Removing old e-mail address.


18 years ago
QA Contact: ckritzer → junruh
Mass reassign ddrinan's PSM bugs (with his permission) to nobody
Assignee: ddrinan0264 → nobody
QA Contact: junruh → nobody
Target Milestone: Future → ---


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


13 years ago
Whiteboard: [kerh-ehz]
QA Contact: nobody → ui


11 years ago
Version: psm2.0 → 1.0 Branch
Bug 1030963 removed this functionality entirely.
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.