Subject: Algorithm Class Data

From: "Jim Schaad" <[email-masked]>
Date: Mon, 30 Jul 2007 08:56:16 -0700

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: "Kemp, David P." <[email-masked]>
Date: Mon, 30 Jul 2007 15:10:24 -0400

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.

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

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

KEK Encryption

Key Derivation Algorithm

Digest Algorithm
   OID, Parameters

MAC Algorithm
   OID, Parameters

Jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 30 Jul 2007 17:03:42 -0400

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Jul 2007 15:23:01 -0700

At 5:03 PM -0400 7/30/07, Russ Housley wrote:
>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.