Re: [pkix] I-D Action:draft-ietf-pkix-ocspagility-02.txt

["Jim Schaad" <[e-mail]>]

One only needs to have the parameters in the event that there is information that needs to be conveyed which is not "instance" data rather than global data.  Thus when you look at a block algorithm, one would not want to say - you must use a specific IV - making the set of parameters for an algorithm like AES not required when you want to specify support.

There is a difference if you were looking at algorithms such as RSA-PSS or RSA-OAEP where one would have the ability to say that different hash or mask functions are supported.  The question for ECC would be what should one be able to advertise as being supported, and what items everybody needs to be able to support (or are implicit in the OID value).  I have not really looked into this.

There is a strong reason to support using the same OID value for both the S/MIME capability and any other uses, it means that one does not need to keep a table of equivalencies and makes the code much easier.  We did very much stress the need to understand that the structures where different, however this was not a new problem we introduced at this point.  Consider the RSA algorithm where the same OID is used in different locations with different parameters.



> -----Original Message-----
> From: Manger, James H [mailto:[e-mail]]
> Sent: Sunday, August 23, 2009 6:41 PM
> To: Jim Schaad; [e-mail]
> Subject: RE: [pkix] I-D Action:draft-ietf-pkix-ocspagility-02.txt
> 
> > I am afraid that James is wrong when saying there is only one
> structure that
> > can be associated with an OID, the correct statement should be that
> for any
> > given location, only one structure can be associated with an OID.
> 
> At least SMIMECapability is not defined to be an AlgorithmIdentifier --
> it is a separate type, with different field names, and different
> related CLASSs (SMIME-CAPS vs ALGORITHM). Consequently, using the same
> OID in these two types with different parameter structures is not as
> bad as using the same OID with different parameter structures in
> different instances of AlgorithmIdentifier (which is what I objected
> to).
> 
> Curiously, in RFC 3851 "S/MIME 3.1" section 2.5.2.1 (where the one
> SMIMECapability in the document is defined for RC2) much of the text is
> solely to remind the reader not to confuse the two parameter
> structures. A new OID for the new parameter structure may have been a
> less confusing solution.
> 
> 
> draft-ietf-smime-new-asn1 defines lots of SMIMECapability values
> collated from various specs. I can only see two parameter structures:
> INTEGER holding a key length for RC2; and KeyWrapAlgorithm.
> KeyWrapAlgorithm is itself a SMIMECapability (or Alg.Id elsewhere in
> the same draft!!!). Effectively, it seems to be more OIDs with no other
> structures. SMIMECapabilities already combines different types of
> algorithms (signature algs, symmetric algs, key encipherment algs...)
> in a single list. It might have been more in keeping with this usage to
> include key wrap algs in this list directly, instead of as parameters
> of another algorithms.
> 
> James Manger