202925 - SEC_OID_RC2_CBC should invoke CKM_RC2_CBC_PAD

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Jamie Nicolson]

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.

Comment 1

[Robert Relyea]

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

Comment 2

[Jamie Nicolson]

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?

Comment 3

[Robert Relyea]

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

Comment 4

[Robert Relyea]

See previous comment