305718 - why RSA sign still uses SHA-1 AlgorithmId with a NULL parameter?

Status: RESOLVED INVALID

(NSS :: Libraries, enhancement)

Description

[Speedo Goo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

According to RFC 3370 (ftp://ftp.rfc-editor.org/in-notes/rfc3370.txt) 2.1 SHA-1:

   The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
   the parameters field MUST contain a NULL.  Implementations MUST
   accept SHA-1 AlgorithmIdentifiers with absent parameters.
   Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
   parameters.  Implementations SHOULD generate SHA-1
   AlgorithmIdentifiers with absent parameters.

But it seems certutil is still using the with-NULL mode (which I find with
certutil -S -s "CN=My Issuer" -n myissuer -x -t "C,C,C" -k rsa -z SHA1). Is
there any particular reason for this?

BTW, do you guys know what is the de-facto style everyone is using, in spite of
the RFC recommendation? I'm developing on a similar product that does
SHA1withRSA signing and would like to choose between the two.

Reproducible: Always




Sorry, this is not a bug. I just want to know why you implement it this way.

Comment 1

[Wan-Teh Chang]

I don't know why we add NULL parameters when we encode
the SHA-1 AlgorithmIdentifier.  Bob, Nelson, do you know?

I believe the NULL parameters are added in the SECOID_SetAlgorithmID
function:
http://lxr.mozilla.org/security/ident?i=SECOID_SetAlgorithmID

So fixing this problem may be as simple as removing
SEC_OID_SHA1 (and any other algorithms that should have
absent parameters) from the switch statement in
SECOID_SetAlgorithmID.  Speedo Goo, could you try this
change?

Do any other standards specify how to encode the SHA-1
AlgorithmIdentifier?

Comment 2

[Robert Relyea]

This twists very old memories. It seemed this topic, in the past, threatened to
drive Lisa and Jeff quite loopy.

I may be remembering a different issue, but I think either:
 1) the issue is that not all implementations  in the past met the RFC.
or
 2) the our ASN.1 decoder has a generic 'encode NULL' code which handles this
case by sending explicitly encoding a NULL parameter.

I think this issue is the latter. There are other cases where we MUST send the
encoded NULL, and there is no way in our templates to distiguish between these 2
cases I seem to remember a number of painful bugs switching from one case to
another in the past.

this is all sort of vague, so take these with a grain of salt...

bob

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I believe the above-quoted text is present in the latest CMS (nee PKCS7) RFCs
but not in the older ones.  I believe it was added there to finally resolve
an ancient argument about this very topic.  The code that sends the NULL was 
put there for interoperability with other clients at the time this code was 
written ('96/97).  It's quite possible that there are still S/MIME clients out 
there that require the NULL.  Since the RFC now requires that all recipients 
be able to handle them, it seems safe to continue to send them.  

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I think "worksforme" is an appropriate resolution here.