Re: Algorithm Identifiers in sip-sec-flows

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

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