Subject: Algorithm Identifiers in sip-sec-flows

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Jul 2008 11:16:58 -0700

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?

-Ekr

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 14 Jul 2008 19:37:36 +0100

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

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Jul 2008 11:50:56 -0700

At Mon, 14 Jul 2008 19:37:36 +0100,
> algorithms and encodes them as NULL for others.

Has this stuff been released yet?

Thanks,
-Ekr

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 14 Jul 2008 11:50:13 -0700

On Mon, Jul 14, 2008 at 11:16:58AM -0700, Eric Rescorla wrote:
>    Implementations SHOULD generate SHA-1
...

>From RFC 2119:

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course.

I say that the OpenSSL implementation emitting NULL and the prevalence of
that implementation constitutes a valid reason in a particular circumstance,
and the full implication is understood (receiving implementations MUST support
NULL). This email exchange constitutes careful weighing before choosing a
different course.

So emit NULL and feel bad about it. You might consider submitting the patch to
OpenSSL anyway though.

Blake

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 14 Jul 2008 21:26:42 +0100

> Has this stuff been released yet?

The documentation and full functionality is present in the development 
version (which will be 0.9.9).

A slightly less functional version has been backported to 0.9.8 and 
first appears in the 0.9.8h release. It has to be specifically enabled 
using "enable-cms" at configuration time. Though a 0.9.8h bug means it 
is advisable to use the latest 0.9.8-stable snapshot.

Steve.