ietf-smime
[Top] [All Lists]

Re: Algorithm Identifiers in sip-sec-flows

2008-07-14 12:02:34

At Mon, 14 Jul 2008 19:37:36 +0100,
Dr Stephen Henson wrote:

Eric Rescorla wrote:
Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows
(http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which
contains SIP security exampled and one of the open issues is algorithm
identifier encodings.

Like most others, We're using OpenSSL to generate the messages, with
RSA with SHA-1 for the signature algorithms. As people will recall,
RFC 3370 has this to say about the algorithm identifiers:

   The SHA-1 message digest algorithm is defined in FIPS Pub 180-1
   [SHA1].  The algorithm identifier for SHA-1 is:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          oiw(14) secsig(3) algorithm(2) 26 }

   There are two possible encodings for the SHA-1 AlgorithmIdentifier
   parameters field.  The two alternatives arise from the fact that when
   the 1988 syntax for AlgorithmIdentifier was translated into the 1997
   syntax, the OPTIONAL associated with the AlgorithmIdentifier
   parameters got lost.  Later the OPTIONAL was recovered via a defect
   report, but by then many people thought that algorithm parameters
   were mandatory.  Because of this history some implementations encode
   parameters as a NULL element and others omit them entirely.  The
   correct encoding is to omit the parameters field; however,
   implementations MUST also handle a SHA-1 AlgorithmIdentifier
   parameters field which contains a NULL.

   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.

However, as far as I can tell OpenSSL currently generates the encoding
with NULL rather than absent, and my memory is that the last time I
discussed this with the OpenSSL implementors, they weren't interested
in changing this.

When we were last working on this a few years ago, I got some message
from Fluffy saying that we should try to generate an encoding with
absent regardless. I spent some time patching OpenSSL to make it do
this, but upon reexamination, it seems kind of lame to have an example
in the draft that requires some one-off patch to generate, so I
thought it might be a good idea to get some more advice from the WG.
I'm not suggesting we change 3370, but is it really necessary to
have examples which need to be hand-tooled?


At the time OpenSSL didn't support CMS only PKCS#7.

There are a few separate cases which OpenSSL handles.

The PKCS#1 DigestInfo structure includes NULL. As I recall this is a 
specific exception partly to cover implementations that process 
DigestInfo with a cut and paste operations.

The PKCS#7 code includes NULL. I'd have to check my archives but I can 
vaguely recall that a compatibility test OpenSSL was put through 
required this.

The very recently added CMS code omits the parameters for sha1 and sha2 
algorithms and encodes them as NULL for others.

Has this stuff been released yet?

Thanks,
-Ekr

<Prev in Thread] Current Thread [Next in Thread>