On Thursday, April 16, 1998 2:01 PM, jsp(_at_)jgvandyke(_dot_)com
I respectfully disagree for the reasons that I stated before. There
reason why the receiving agent should not be able to decode the
and re-DER-encode the authenticatedAttributes. Your proposed text
discourages that behavior.
My points are as follows:
1. This exact problem has happened in the past -- a sending agent has
failed to order the SET OF according to DER. This is the senders
problem because their code is broken.
2. By saying "SHOULD NOT re-encode the attributes", implementors take
pause and say "Hmm. It really isn't necessary to recode these as DER.
I won't.", which would solve the problem in 1.
3. By saying "SHOULD NOT re-encode the attributes", we are discouraging
the (IMHO completely unnecessary) behavior, but we are not precluding
Your point has consistently been that "some receiving agents must
re-encode the attributes as DER as a course of normal processing". My
language does not prohibit that behavior, and will simply illustrate a
potential interoperability problem surrounding the digesting of
authenticated attributes. As far as strongly discouraging the behavior
-- why is that a problem? You can still do it if you want, at the risk
of not being able to verify signatures from broken senders that don't
use DER on the authenticatedAttributes.
I don't see my change as harmful at all, and I think the only thing it
will do is enhance interoperability. Unfortunately, I happen to be on
the losing side, since I would like to propose new language that you
oppose, and there isn't enough interest in the topic for others to take
sides, which causes the new language to automatically lose. All I can
do is say that this has been an interoperability issue in the past and
it can be addressed without compromise using the language I have
Blake C. Ramsdell
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060