[Bug 26465] Algorithm normalization doesn't allow arbitrary operations for AlgorithmIdentifier fields


--- Comment #7 from Mark Watson <watsonm@netflix.com> ---
Ok, so at least we are clear on the problem.

I think that a future algorithm for operation X which needs to be parameterized
by with an algorithm for operation Y, with Y != X is far far more likely than
the case where Y == X.

Can you give me any examples of an algorithm where Y == X ? A signature
algorithm which needs to be parameterized with another signature algorithm ? An
encryption algorithm which needs to be parameterized with another encryption
algorithm ?

If we are not going to solve this problem now (which I agree is an option), we
should remove the recursive normalization except for the explicit digest case,
because there are even fewer potential applications for that. It's also
confusing because there is no rationale for supporting that case and not the
more general one.

I agree with your point about the complexity of defining a full solution in
this specification. The alternative is to defer to the extension specification,
when/if it happens, by simply saying that the operation to be used will be
defined in the specification of the new algorithm.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 1 August 2014 15:53:48 UTC