Dave,
Sorry about the delay, I have been out looking at grapes for the last couple
of days sending much of my time driving.
-----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 Kemp, David P.
Sent: Friday, August 17, 2007 1:18 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Algorithm Class Data
I'm still a bit confused. Is all this data to be put in a single
location for:
1) people to read,
Yes this is an advantage,
2) the ASN.1 compiler to read and ignore, or
No, although many might do this.
3) the ASN.1 compiler to read and do something with (such as emitting
diagnostic messages), without affecting bits on the wire
YES this is what we want it to do.
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)
No the compiler cannot handle this, if you are looking at the contents of a
.asn file. There is no way for the compiler to know if this is what was
supposed to happen.
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.
What I hope will happen, is that compilers will emit the data and start
using it. Here are some different ways that it could be done.
1. The compiler provides the table of data along with some access
functions. This would allow for the coder to ask questions like "What
encoder should I be using for the parameters of a public key for this OID"
2. The compiler can potentially do checks and return a warning if a value
in a field is not contained in a table of values for a field.
3. The compiler could actually automatically do the decode operation in a
single function call for things like parameters without the coder having to
make additional calls.
I guess part of the question is do you think that putting a size restriction
on a field is currently reasonable. Most compilers ignore this piece of
information, but some compilers that understand constraints actually emit
code that can check this before doing an encode operation.
Dave
Jim