84173 - "crypto.algorithms" doesn't exist

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, defect, P3)

Description

[Henrik Gemal]

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:
http://docs.iplanet.com/docs/manuals/psm/14/cmcjavascriptapi.html

the crypto object for the current build can be seen at:
http://gemal.dk/browserspy/showprop.html?crypto

Comment 1

[Stephane Saux]

Henrik.  Thanks for pointing all of these to us.
P3
version, target -> 2.0

Comment 2

[Stephane Saux]

Mass reassigning target to 2.1

Comment 3

[(Don't use, old account) - Kai Engert]

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

[Stephane Saux]

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
property.

Comment 5

[David P. Drinan]

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

[Stephane Saux]

Moving all P3 and P4 bugs targetted to 2.1 to future.

Comment 7

[Stephane Saux]

removing nsenterprise keyword from PSM bugs with target milestone of future.

Comment 8

[John Unruh]

Mass assigning QA to ckritzer.

Comment 9

[Steve Parkinson]

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.

Comment 10

[Kai Engert (:KaiE:)]

Changing my e-mail address.

Comment 11

[Kai Engert (:KaiE:)]

Removing old e-mail address.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign ddrinan's PSM bugs (with his permission) to nobody

Comment 13

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Bug 1030963 removed this functionality entirely.