[Top] [All Lists]

RE: Algorithm Class Data

2007-08-17 13:46:53

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:

     &id             OBJECT IDENTIFIER,
     &privKeyType OPTIONAL,
     &pubKeyParams DEFAULT NULL,

   alg-DSS MY-ALG-CLASS {id-dss, INTEGER, INTEGER, dss-params, DSS-SIG,

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,

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.


-----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 
Sent: Thursday, August 16, 2007 5:04 PM
To: Jim Schaad; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Algorithm Class Data


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
to read rather than having to go through the entire document for the

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


<Prev in Thread] Current Thread [Next in Thread>