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