SEC_OID_RC2_CBC should invoke CKM_RC2_CBC_PAD

RESOLVED WONTFIX

Status

NSS
Libraries
RESOLVED WONTFIX
15 years ago
15 years ago

People

(Reporter: Jamie Nicolson, Assigned: Robert Relyea)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
In the OID table in secoid.c, SEC_OID_RC2_CBC is associated with CKM_RC2_CBC.
This seems logical, but PKCS #5 v2.0 states that the rc2CBC OID should actually
represent the RC2-CBC-PAD mechanism.  There is no OID for RC2-CBC without
padding. According to the PKCS #5 spec, SEC_OID_RC2_CBC should be associated
with CKM_RC2_CBC_PAD.

I came across this because I'm trying to provide RC2-CBC-PAD through JSS, and I
was trying to figure out which OID to associate with the algorithm.
(Assignee)

Comment 1

15 years ago
Sigh,

This currently has to be this way for S/MIME.
S/MIME does it's own padding, so it needs to call the raw functions. We do this
so that this works with tokens that don't provide the _PAD functions. The _PAD
functions are only used directly in NSS when wrapping or unwrapping keys
(particularly private keys), because applications can't do the padding in these
cases.

bob
(Reporter)

Comment 2

15 years ago
So it sounds like S/MIME, when it encounters the SEC_OID_RC2_CBC oid, wants to
actually perform CKM_RC2_CBC. Can we just put this special-case code into
S/MIME, and make the OID->mechanism code comply with the standard?
(Assignee)

Comment 3

15 years ago
The S/MIME Code was the reason for creating that field in the OID's to begin with.
What may be useful is to provide a Standard to PAD mapping for JSS, though it's
probably best for JSS to do it's own padding for the same reasons that S/MIME is
doing it's own padding.

bob
(Assignee)

Comment 4

15 years ago
See previous comment
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.