Re: comment on draft-ietf-ltans-dssc-01.txt

[Paul Thorpe <thorpe@xxxxxxx>]

On Tue, 4 Dec 2007, Turner, Sean P. wrote:

>
> I'm only commenting on the Parameter structure in the ASN.1. I think that it
> might be better to change Algorithm to be a sequence of algorithmIdentifier,
> validity, and information - call it AlgorithmValidityInfo. I suggest this
> for two reasons:
>
> 1. The AlgorithmIdentifier structure that is used to assign an algorithm's
> object identifier also define the parameters. So it probably makes sense to
> reuse this structure.
>
> 2. The parameters structures for some of the newer algorithms is quite
> complicated. For example,  RSASSA-PSS [RFC4055] and ECC Algs [RFC3279]
> aren't just an OID they are nested structure.
>
> (not sure how to do it in XML)
>
> Replace:
>
> Algorithm ::= SEQUENCE {
>         algorithmIdentifier  AlgID,
>         parameters           [0] SEQUENCE OF Parameter  OPTIONAL,
>         validity             [1] Validity,
>         information          [2] SEQUENCE OF UTF8String OPTIONAL
>    }
>
>    AlgID ::= SEQUENCE {
>         name  UTF8String,
>         oid   [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>         uri   [1] SEQUENCE OF IA5String OPTIONAL
>    }
>
>    Parameter ::= SEQUENCE {
>         name        UTF8String,
>         constraint  CHOICE {
>                       exact  [0] OCTET STRING,
>                       min    [1] OCTET STRING,
>                       max    [2] OCTET STRING,
>                       range  [3] Range,
>                       other  [4] OtherConstraints
>         }
>    }
>
> With:
>
> AlgorithmValidityInfo ::= SEQUENCE {
>  identifier  AlgorithmIdentifier,
>  validity    Validity OPTIONAL,
>  information Information OPTIONAL }
>
> Validity ::= SEQUENCE {
>   start  [0] GeneralizedTime OPTIONAL,
>   end    [1] GeneralizedTime OPTIONAL }
>
> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>
> -- From RFC3280
> AlgorithmIdentifier  ::=  SEQUENCE  {
>      algorithm               OBJECT IDENTIFIER,
>      parameters              ANY DEFINED BY algorithm OPTIONAL  }
>                                 -- contains a value of the type
>                                 -- registered for use with the
>                                 -- algorithm object identifier value
>
> spt
>

The ASN.1 type "ANY DEFINED BY" was withdrawn from ASN.1 in 1994 and
replaced with the "open type" which allows ASN.1 compilers to explicitly
link the contents of the "open type" field with the object identifier.

For example try the following:

SOMECLASS ::= CLASS {
    &id      OBJECT IDENTIFIER UNIQUE,
    &Type
}

AlgorithmIdentifier ::= SEQUENCE {
    algorithm      SOMECLASS.&id ({SomeTable}),
    parameters     SOMECLASS.&Type ({SomeTable}{@algorithm})
}

SomeTable SOMECLASS ::= {
 { &id  oid1, &Type TypeForOid1 } |
 { &id  oid2, &Type TypeForOid2 },
 ...
}

The bits on the wire will be identical to the old ANY DEFINED BY, but you
can explicitly list the types that particular oids correspond to.  An
ASN.1 Tool can automatically handle this for you rather than every
implementer needing to hand code the table linking the list of object
identifiers to a specific ASN.1 type for the parameter.

Again, the key is that the bits on the wire are identical, but good ASN.1
Tools can take advantage of the table to make programmers tasks easier and
less error prone.

Note that "SomeTable" can be either completely specific in the
specification, or it can have rows added or removed dynamically at runtime
if desired.

I recommend using the "open type" instead of the "ANY DEFINED BY" which
was withdrawn from ASN.1 in 1994.

Paul Thorpe
thorpe@xxxxxxx