Subject: [pkix] Question on new PKIX ASN.1 syntax

From: Ed Day <[email-masked]>
Date: Fri, 16 Jul 2010 15:09:24 -0400

In RFC-5912, the first paragraph states:

"This document updates those ASN.1 modules to conform to the 2002
version of ASN.1. There are no bits-on-the-wire changes to any of the
formats; this is simply a change to the syntax."

It appears to me that in the final revision of the spec, there is
syntax that causes a "bits on the wire change".  There is a data file
that we could decode with previous versions but now which appears to
not work with the latest version.

The change in question involves the definition of "signature" at the
end of the specification.  There are 3 alternative definitions with
the last one enabled by default:

 SIGNED{ToBeSigned} ::= SEQUENCE {
    toBeSigned           ToBeSigned,
    algorithmIdentifier  SEQUENCE {
        algorithm        SIGNATURE-ALGORITHM.
                           &id({SignatureAlgorithms}),
        parameters       SIGNATURE-ALGORITHM.
                           &Params({SignatureAlgorithms}
                             [email-masked]}) OPTIONAL
    },
    signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
                             {SignatureAlgorithms}
                             [email-masked]}))
 }

This indicates that signature is an open type (i.e. a fully encoded
TLV component) wrapped in a BIT STRING.  However, in sample data I
have (one example of which is a file named rfc3280bis_cert1.cer which I
believe came from NIST), this does not appear to be the case - the value
appears to be opaque binary data that cannot be interpreted as an ASN.1
TLV.  Am I wrong in this assessment?

Regards,
Ed Day
Objective Systems, Inc.
http://www.obj-sys.com