Subject: RE: Algorithm Class Data

From: "Jim Schaad" <[email-masked]>
Date: Fri, 3 Aug 2007 22:49:56 +0200

Dave,

What I am looking at doing the associations for is the data structures not
the data themselves.  Thus for example, I have several different tables in
my system that say what the different structures are that are associated
with each algorithm OID.  The ability to encode this in the ASN.1 module,
and thus potentially to have the data transferred to my program, seems to me
to be a good thing.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Kemp, David P.
> Sent: Monday, July 30, 2007 9:10 PM
> To: [email-masked]
> Subject: RE: Algorithm Class Data
> 
> 
> Jim,
> 
> What is the purpose of "associating" information in an ASN.1 module?
> Since ASN.1 describes the syntax of (for example) a signature as
> transmitted between systems (OID, Parameters, and Signature Value),
> I'm not sure what a compiler would do with other data associated
> with a signature.  The public key used to validate a signature is
> not contained in the same data object as the signature value itself
> (certificate vs. signed object), a private key might not appear
> in any ASN.1 module at all, and the data over which a signature is
> computed may be external.
> 
> Since ASN.1 is not a procedural language, it's not clear how an
> association between a private key and a signature could even be
> expressed.  The private key used to generate a signature is
> buried somewhere behind a PKCS#11 call.
> 
> Wouldn't you want to simply associate a specific data type with
> the algorithm OID that selects it, just as an attribute OID
> selects the syntax of the attribute value?
> 
> Dave
> 
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Monday, July 30, 2007 11:56 AM
> To: [email-masked]
> Subject: Algorithm Class Data
> 
> 
> At the face-to-face meeting I presented the fact that Paul Hoffman and
> I
> are
> currently working on a 2002 freeware ASN.1 compiler.  As part of this
> work
> we are requested to do re-writes of the core IETF ASN.1 modules to
> update
> them.  This message is looking at one portion of the update that we are
> contemplating.
> 
> 
> The current ITU definition of ALGORITHM contains just an OID and an
> open
> type.  From my point of view this seems to be missing a lot of data
> that
> should be associated together.  So the first question would be what
> information exists that COULD be associated together.  This meta data
> is
> generally collected somewhere, but is not associated in the current
> ASN.1
> file.
> 
> The following information what I think could be associated.  I would
> like to
> start by seeing if this is a complete set of data that could be
> associated.
> 
> Signature
>     OID, Parameters, Signature Value, Public Key, Private Key
> 
> Transport Encryption
>     OID, Parameters, EncryptedKey (contents of OCTET STRING ?), Public
> Key,
> Private Key
> 
> Key Agree Encryption
>    OID, Parameter, EncryptedKey (contents of OCTET STRING ?), Public
> Key,
> Private Key, OtherKeyAttributes Set
> 
> Symmetric Key Encryption
>    OID, Parameters, S/MIME Parameters
> 
> KEK Encryption
>    OID, Parameters, OtherKeyAttibutes Set
> 
> Key Derivation Algorithm
>    OID, Parameters, input format?
> 
> Digest Algorithm
>    OID, Parameters
> 
> MAC Algorithm
>    OID, Parameters
> 
> 
> 
> 
> Jim
> 
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 3 Aug 2007 22:49:56 +0200

Russ,

Here would be an example.   (Please note - this is conceptual ASN.1 not real
ASN.1)

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 }

All of the data is not associated together in META-DATA - this does not
affect what goes out over the wires, however the information could
potentially be used in the encode/decoder with some re-writes of the data
such as

SIGNED(ToBeSigned) ::= {
   toBeSigned    ToBeSigned
   algorithm    SEQUENCE {
       sigId   MY-ALG-CLASS.&id({SigAlgs}),
       params  MY-ALG-CLASS.&sigParams ({SigAlgs}{@sigId}) OPTIONAL,
   },
   Signature BIT STRING (CONTAINING
MY-ALG-CLASS.&sigStructure([email-masked]}))
}

This data structure COULD be encoded/decoded directly by the ASN.1 system.

Jim

> [email-masked]] On Behalf Of Russ Housley
> Sent: Monday, July 30, 2007 11:04 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: Algorithm Class Data
> 
> 
> Jim:
> 
> I do not see how these impact the things that go on the wire.  Maybe
> I have not thought about it enough, but an example would help me
> understand your proposal better.
> 
> Russ
> 
> 
> At 11:56 AM 7/30/2007, Jim Schaad wrote:
> 
> I are
> >     OID, Parameters, EncryptedKey (contents of OCTET STRING ?),
> Public Key,
> >Private Key
> >
> >Key Agree Encryption

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Aug 2007 11:00:02 -0400

Jim & Paul:

>>I do not see how these impact the things that go on the wire.
>
>That's exactly the point.
>
>>Maybe I have not thought about it enough, but an example would help 
>>me understand your proposal better.
>
>The idea is to have more programmatic logic in the ASN.1 module 
>itself, I believe. Right now, we have text in the RFC, comments in 
>the ASN.1 module, and the code-reflecting parts of the module. 
>Moving some of the first two into the latter might make 
>interoperability more likely.

That is not useful unless other development tools draw the line in 
the same place, right?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 16 Aug 2007 13:28:36 -0700

Russ,

> Sent: Saturday, August 11, 2007 8:00 AM
> To: Paul Hoffman; Jim Schaad; [email-masked]

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.

Jim

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Aug 2007 17:03:53 -0400

>to read rather than having to go through the entire document for the same

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

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 16 Aug 2007 22:13:55 -0400

Should the implementer net be wider that just SMIME? 

>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Thursday, August 16, 2007 5:04 PM
>>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
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 17 Aug 2007 04:16:40 -0700

Russ,

This is one of the reasons why I have initially restricted this question to
just the S/MIME group.  I was worried about the differences with X.509 for
certificates and wanted to address that on the PKIX list after the S/MIME
group had made it's decision.

Jim

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, August 16, 2007 2:04 PM
> people

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Aug 2007 08:21:12 -0400

Yes.  The suggestion that Jim made is equally viable in PKIX.

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Aug 2007 08:56:42 -0400

Jim:

But, the same structures are important in both situations.  All of 
the issues you raised are visible in the definition of 
AlgorithimIdentifier, which is used in many many places.

Russ

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 17 Aug 2007 16:17:56 -0400

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,

   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-----

people

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 24 Aug 2007 20:23:44 -0700

Dave,

Sorry about the delay, I have been out looking at grapes for the last couple
of days sending much of my time driving.

> Sent: Friday, August 17, 2007 1:18 PM
> To: [email-masked]
Yes this is an advantage,

> 2) the ASN.1 compiler to read and ignore, or
No, although many might do this.

>    diagnostic messages), without affecting bits on the wire

YES this is what we want it to do.

>    alg-DSS MY-ALG-CLASS (id-dss, BIT STRING, IA5 STRING, rsa-params,

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.

> 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.

Jim