I'm still a bit confused. Is all this data to be put in a single
location for:
1) people to read,
2) the ASN.1 compiler to read and ignore, or
3) the ASN.1 compiler to read and do something with (such as emitting
diagnostic messages), without affecting bits on the wire
For 1) wouldn't putting the proposed structures in ASN.1
comments be appropriate, and have no effect on compatibility?
2) is pointless.
For 3), using the example:
MY-ALG-CLASS ::= CLASS {
&id OBJECT IDENTIFIER,
&privKeyType OPTIONAL,
&pubKeyType,
&pubKeyParams DEFAULT NULL,
&sigStructure,
&sigParams)
alg-DSS MY-ALG-CLASS {id-dss, INTEGER, INTEGER, dss-params, DSS-SIG,
NULL }
only &id and &sigParams are used by the encoder/decoder to process
SIGNED data. Is there any expectation that future ASN.1 compilers might
understand enough about this class to complain if the user typed
something bogus, like:
alg-DSS MY-ALG-CLASS (id-dss, BIT STRING, IA5 STRING, rsa-params,
ECDSA-SIG, NULL)
If the envisioned compiler cannot assist the user with recovering
from mistakes like this, then there is no reason to introduce
an incompatibility. Just put comments around the structure and let
humans contemplate its beauty.
Dave
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ
Housley
Sent: Thursday, August 16, 2007 5:04 PM
To: Jim Schaad; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Algorithm Class Data
Jim:
I believe that this is useful independent of where tools draw the line.
This is an advantage of putting more data into a single location for
people
to read rather than having to go through the entire document for the
same
data.
I've been thinking about this, and I agree. It really would help
implementors to link all of this information together with
unambiguous ASN.1, but it does lead to a compatibility problem. We
would no longer be using the same definitions as X.509. The new ones
would include this additional information to aid implementors, and
generate exactly the same bits on the wire. I'm not sure the
incompatibility is worth it.
Implementors need to speak up here? The structures proposed by Jim
would replace tables (or some other structure chosen by the
implementor). Are implementors going to embrace the approach offered by
Jim?
Russ