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