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

["Manger, James H" <[e-mail]>]

> 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