Manger, James H wrote:
[Santosh] My suggestion is that it is appropriate to use the Alg ID and assert the parameters in spite of RFC 5480. My reasoning is as follows. The ASN.1 permits it; we need it for interoperability; the RFC wants them absent when asserting in Signature or SIGNED MACRO since getting the parameters from those locations have proven to be vulnerable to substitution attack (at least in degenerate cases); they definitely are not authenticated. But, the application in this I-D is different. Since the whole structure is unauthenticated, there is no harm in unauthenticated parameters as well. I disagree. The ASN.1 DOES NOT support using the same object id in different instances of the AlgorithmIdentifier structure with different parameter syntaxes. The ASN.1 may allow ANY syntax for the parameters, but the assumption (or explicit constraint -- depending on your version of ASN.1) is that the syntax is defined by the preceding object id.
I agree with James here. Algorithm Identifier does allow you to define an algorithm with what ever parameters you want, but you just can't stick more parameters on the ecdsa-with-* OID. The OIDs have been well defined/registered in RFC 3278, RFC 3279, RFC 5480, draft-ietf-pkix-sha2-dsa-ecdsa, draft-ietf-smime-3278bis (in RFC editor's queue), and draft-ietf-smime-new-asn (with IESG) which all say either NULL or absent parameters (depending on the hash alg).
Some code will have tables mapping OID-to-parameter-syntax to automatically decode Alg.Id values. With Santosh's suggestion the code would need different tables depending on context: one table when decoding an Alg.Id in the PreferredSignatureAlgorithms type, and another table when decoding an Alg.Id in a Signature type. Yuck.
It looks like what is really needed is a rule for matching acceptable combinations of signature algorithm and signing key properties (key algorithm and key length). To do that properly requires a new matching rule with its own syntax.
P.S. field names usually (must?) start with lower-case letters in ASN.1 so PreferredSignatureAlgorithms should be "SEQUENCE { algorithms SEQUENCE OF Alg.Id. }".
James Manger
James.H.Manger@xxxxxxxxxxxxxxxx
Identity and security team — Chief Technology Office — Telstra