Jim:
I guess that you kave real problems with PKIX Part 1. The x.509 version 3
is defined using 1988 ASN.1 in that document. Take a look. By the way,
PKIX Part 1 is in last call.
Russ
At 06:00 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
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