Jim:
Thanks. Can you provide 1988 syntax?
Russ
Not if you want to use version 3 certificates. Using 1988 ASN.1 would limit you
to using only version 1 certificates, as there is no conceivable way to write
constraints on version 2 or version 3 certificates (which are defined in 1994
ASN.1) to use only 1988 compatable ASN.1.
As noted by Phil Griffin a week ago, you cannot (for obvious reasons) import
into 1988 ASN.1 types which use features which were not defined in 1988 ASN.1.
There are a few syntax errors in the ASN.1, a draft and WIP, but my
real concern is the mixing of ASN.1:1988/90 and the current standard,
ASN.1:1994. By my reading, the current standard states that the two
can not be mixed in X.680, section A.2, "Mixing ASN.1-88/90 and
current ASN.1 notation":
"Both the ASN.1-88/90 and the current ASN.1 notation specify a
top-level syntactic construct which is an ASN.1 module. A user of
ASN.1 writes a collection of ASN.1 modules, and may import
definitions from other ASN.1 modules."
[snip PHG]
"Where a module conforms to the ASN.1-88/90 notation, type and value
references may be imported from a module that was defined using the
current notation. Such types and values must be associated with types
that can be defined using only the ASN.1-88/90 notation. For example,
a module written using the ASN.1-88/90 notation cannot import a value
of type UniversalString, since this type is defined in the current
notation but not in ASN.1-88/90; it can, however, import values whose
types are, for example, INTEGER, IA5String, etc."
Both BMPString and UniversalString are types defined only in the
current standard, ASN.1:1994. The S/MIME work is not alone in this
problem. I've just finished creating ASN.1:1994 definitions for PKCS
#12. It too attempts to use BMPString in code that uses the
superceded ANY DEFINED BY, which is described in Annex I (not an
intgral part of the ASN.1 standards). The current PKIX work also
attempts to merge the standards.
Such ASN.1 usage will certainly break tools that correctly implement
the ASN.1 standards. I'm not sure why there's so much reluctance to
migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
specifications than X.208-X.209.
An alternative would be to drop national language support and keep
using ASN.1:1988/90.
Phil
--
Phillip H. Griffin
Jim