Hello, I hope this is the right place to ask this question: We were having trouble with a CMS signature and we finally located the problem. The underlying implementation interpreted the canonical DER encoding for SET-OF different from the implementation that we were using.
1. The first implementation compared each element contained in the set using its complete encoding, i.e. including the class tag and length element, and then compared them byte-wise, in the same way that you seem to do it (I checked in a_set.c, in int i2d_ASN1_SET(STACK *a, unsigned char **pp, i2d_of_void *i2d, int ex_tag, int ex_class, int is_set)), i.e. "Check them byte-by-byte up to the end of the shorter element, if they are equal up to this boundary, then the longer element is the greater element." 2. The second implementation did the same comparison, but excluding the length tag, only comparing the class tags and "Values" of the elements, the underlying algorithm being the same as above. At first I thought the second implementation was wrong, but then again I read the ITU specification for DER encodings, http://www.itu.int/rec/T-REC-X.690-200207-S/en. In chapter 11.6 they say: " 11.6 Set-of components The encodings of the component values of a set-of value shall appear in ascending order, the encodings being compared as octet strings with the shorter components being padded at their trailing end with 0-octets. NOTE The padding octets are for comparison purposes only and do not appear in the encodings. " Now this seems very ambiguous to me. I read this again and again and I am still confused. The elements shall be compared as octet strings with a padding of 0-octets at the end - this could mean two things: a) "Virtually" transform them to equal-length octet strings, i.e. with virtually equal length tags -> this would mean implementation 2 is right b) Compare the elements' octet string encoding byte-wise as is, which again would favor implementation 1. If b) is the correct approach, then I wonder what good it does to pad the elements at all - because the length tag will already decide the relation of two different-sized elements anyway. What do you think? Your response would help us a lot here, and could you please describe your decision to do this ordering in OpenSSL the same way that implementation 1 does it? Thanks in advance, Martin Boßlet ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
