RE: I-D Action:draft-ietf-pkix-ocspagility-02.txt

["Manger, James H" <James.H.Manger@xxxxxxxxxxxxxxxx>]

[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.

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