"when sort orders differ" - the sort order for an ASN.1 SET in DER
encoding is a fixed canonical ordering, which is why it's used as the
input for the signature. A signature over a different ordering would be
How was the SignedData generated?
On 7/4/20 2:41 pm, Wolfgang Bauer wrote:
> we are encountering a problem when verifying a CMS signature (SignedData
> containing Signed Attributes).
> When parsing the SignerInfo structure the follwing code is used inside
> the library :
> authenticatedAttributes = ASN1Set.getInstance((ASN1TaggedObject)obj,
> During signature verification
> the signed Attribute set gets sorted (when calling
> getEncodedSignedAttributes) and therefore the verification fails (when
> sort orders differ).
> This issue still exists in the latest 1.65 release.
> Should I create a new issue on github, or is this the right place to
> discuss this topic?
It will allow you to override the effective encoding used for a
Don't forget to also still check signatures against the correct encoding!
On 7/4/20 5:36 pm, Wolfgang Bauer wrote:
> Hi Pete,
> thanks for your quick response. The SignedData is part of a PDF (PADES)
> signature and according to Adobe Acrobat Reader (and other tools) the
> signature is valid.
> All these tools seem to keep the ordering as read from the DER encoding.
> Although this approach might not be 100% correct, it improves interop.
> Do you see any chance to skip the ordering step in bc without patching
> the library?
> On Tue, 2020-04-07 at 16:02 +0700, Peter Dettman wrote:
>> Hi Wolfgang,
>> "when sort orders differ" - the sort order for an ASN.1 SET in DER
>> encoding is a fixed canonical ordering, which is why it's used as the
>> input for the signature. A signature over a different ordering would be
>> How was the SignedData generated?
>> Pete Dettman