[lamps] Problems with the current ALGORITHM information object class

[Erik Andersen <[e-mail]>]

In our work with IEC 62351-4 and X.510 we have identified a limitation with
the current ALGORITHM information object class. The current definition is 

 

ALGORITHM ::= CLASS {

  &Type         OPTIONAL,

  &id           OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {

  [PARMS        &Type]

  IDENTIFIED BY &id }

 

The PARM field is used for defining parameters associated with the
algorithms. However, the parameters are of two types:

 

1.       Parameters that provide additional information about the procedure
to be applied according to the algorithm. An example is ecPublicKey, where
the parameter value is the elliptic curve to be used. 

2.       Parameters that specified the syntax of the value to be used when
the algorithm is deployed. An example is the AES algorithms that require a
value of the parameter transferred together with the encrypted data.

 

This causes problems when negotiating the use of algorithms. When specifying
ecPublicKey algorithms in such negotiation, the parameter value is relevant.
When specifying AES-CBC in such a negotiation, the random value of some
InitializationVector is not relevant. This make algorithm negotiation
cumbersome.

 

We have therefore suggested to extend the ALGORITHM information object class
in the following way.

 

ALGORITHM ::= CLASS {

  &Type         OPTIONAL,

  &DynParms     OPTIONAL,

  &id           OBJECT IDENTIFIER UNIQUE }

WITH SYNTAX {

  [PARMS        &Type]

  [DYN-PARMS    &DynParms]

  IDENTIFIED BY &id }

 

A suggested update to the ALGORITHM information object class is attached. It
also includes three derivative parameterized data types. By using those data
types it has been possible to define the wrapper protocol without "hard
coding" specific algorithm details, e.g., we have avoided a specific
component for an initialization vector. This has allowed different
cryptographic algorithms to be used for different communication instances
make life a little more difficult for adversaries.  

 

Certain algorithms have to be redefined, which could cause some negative
reactions. As an example the aes256-CBC algorithm must be changed from

 

aes256-CBC ALGORITHM ::= { 

  PARMS         AES-InitializationVector

  IDENTIFIED BY { aes 42 } }

 

To 

 

aes256-CBC ALGORITHM ::= { 

  DYN-PARMS       AES-InitializationVector

  IDENTIFIED BY { <some OID> } }

 

However, most algorithms do not need to be modified.

 

The current version of X.510 may be found at
https://www.dropbox.com/s/i7mizfvoy9uo21x/x510.docx?dl=0.

 

Any comments?

 

Best regards,

 

Erik