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

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 4 Dec 2007 18:32:46 -0800

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

---

From: Paul Thorpe <[email-masked]>
Date: Wed, 5 Dec 2007 05:41:09 -0800 (PST)

>                                 -- algorithm object identifier value

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
[email-masked]

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 05 Dec 2007 15:29:43 +0100

>  in 1994 and
In other LTANS specifications the following approach is used:

One module is specified in 'CURRENT' ASN.1 syntax.
An alternative module is done for 'old' compilers with is an almost 88 
syntax
Which one is normative is still a debate (as in another group).

In some specs also an XSD schema is defined. For LTAP at least the XSD
is automatically generated from the ASN.1 and produces the same encodings
and an XER encoding of the ASN.1

Besides that and in response to Sean.

Although a module can reuse a name that is defined in another module, I
agree that this may be confusing.

Peter

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite'; 
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 5 Dec 2007 07:16:41 -0800

>-----Original Message-----
>From: Peter Sylvester [mailto:[email-masked]] 
>Sent: Wednesday, December 05, 2007 6:30 AM
>To: Paul Thorpe
>Cc: Turner, Sean P.; [email-masked]
>Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>
>
>
>>  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.
>>
>>   
>An alternative module is done for 'old' compilers with is an 
>almost 88 syntax Which one is normative is still a debate (as 
>in another group).
>
>In some specs also an XSD schema is defined. For LTAP at least 
>the XSD is automatically generated from the ASN.1 and produces 
>the same encodings and an XER encoding of the ASN.1
>
>Although a module can reuse a name that is defined in another 
>module, I agree that this may be confusing.
>

I like the idea of moving to the later ASN.1. The reason we've been stopped
in the past was the lack of an open source compiler. We basically have one
now with the a2c compiler.

Peter - are you saying you don't want to import code, you'd rather grow your
own? If you do I'd like to see how the current syntax would break out if I
specified an elliptic curve and all it's parameters. It would be an long
sequence of 'stuff' that you'd have to write up some verbiage about the 1st
element of the sequence was this, the next this, and so on. That seems like
an unworkable solution to me.

spt

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 05 Dec 2007 16:56:15 +0100

> now with the a2c compiler.
I disagree that we were stopped by that. But that's an old story I hope
> an unworkable solution to me.
I have made no comment about the structure of the information that this 
document is
proposing. I just mentioned that reusing a particular name 'Algorithm' 
to define
another but similar structure as in some other module is not a good 
idea, and
indeed defining another thing like AlgorithmValidityInfo is better.

I think you refer to some older message from me?
Following your comment: Before really entering into concrete syntax,
it would be good to describe what abstract information needs to be encoded
and how a validator (an automatic tool!!) is supposed to operate.
An important requirement to me seems that when adding something to
the structure, the core validator doesn't change.

Does that makes sense?
P

---

From: Thomas Kunz <[email-masked]>
Date: Wed, 05 Dec 2007 17:01:46 +0100

The problem with your suggested syntax is the definition of the our 
constraints. If we used the RFC3280 AlgorithmIdentifier structure, we 
would integrate the constraints as follows:

It's not possible to determine constraints for more than one parameter 
(e.g. p > 1024 and q > 160 in case of DSA).
Additionally defining ranges is impossible (e.g. modulus < 2048 and 
modulus > 1024).

so & tk

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 5 Dec 2007 08:21:25 -0800

This would work for me.

spt

>From: Thomas Kunz [mailto:[email-masked]] 
>Sent: Wednesday, December 05, 2007 8:02 AM
>To: Turner, Sean P.
>Cc: [email-masked]
>The problem with your suggested syntax is the definition of 
>the our constraints. If we used the RFC3280 
>AlgorithmIdentifier structure, we would integrate the 
>constraints as follows:
>
>It's not possible to determine constraints for more than one 
>parameter (e.g. p > 1024 and q > 160 in case of DSA).
>Additionally defining ranges is impossible (e.g. modulus < 
>2048 and modulus > 1024).
>
>
>so & tk
>
>
>Turner, Sean P. schrieb:
>> 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.
>>

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 5 Dec 2007 08:24:03 -0800

>> I like the idea of moving to the later ASN.1. The reason we've been 
>> stopped in the past was the lack of an open source compiler. We 
>> basically have one now with the a2c compiler.
>>   
>> Peter - are you saying you don't want to import code, you'd rather 
>> grow your own? If you do I'd like to see how the current 
>syntax would 
>> break out if I specified an elliptic curve and all it's 
>parameters. It 
>> would be an long sequence of 'stuff' that you'd have to 
>write up some 
>> verbiage about the 1st element of the sequence was this, the next 
>> this, and so on. That seems like an unworkable solution to me.
>>   
>I have made no comment about the structure of the information 
>that this document is proposing. I just mentioned that reusing 
>a particular name 'Algorithm' 
>to define
>another but similar structure as in some other module is not a 
>good idea, and indeed defining another thing like 
>AlgorithmValidityInfo is better.
>
>Following your comment: Before really entering into concrete 
>syntax, it would be good to describe what abstract information 
>needs to be encoded and how a validator (an automatic tool!!) 
>is supposed to operate.
>An important requirement to me seems that when adding 
>something to the structure, the core validator doesn't change.
>
>Does that makes sense?
>P

I guess I was reacting to the thoughts of algorithm spec writers have to
have to different formats for representing their algorithms. One which is
used in most ASN.1 based security protocols and another for this. I think
picking another syntax would sink this proposal. Thomas has solved my
concern though.

spt

---

From: "Tobias Gondrom" <[email-masked]>
Date: Thu, 6 Dec 2007 00:13:09 +0100

Hello all, 

in the past the fact that we did not have a comprehensive free
ASN.1-compiler for 1997 or 2002 available has been keeping us to at
least provide 1988-ASN.1 as one of the modules with every RFC. 

Thanks to the good and by the IETF well recognized progress on free
ASN.1 compilers for 2002-ASN.1 we can now freely use this more recent
ASN.1 version. So please consider the new version of ASN.1 to be
recommended for your drafts and it no longer to be required to provide a
module in 1988-ASN.1 in parallel. 

Compiler I am referring to is a2c. 

Regards, Tobias

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Turner, Sean P.
> Sent: Wednesday, December 05, 2007 7:17 AM
> To: 'Peter Sylvester'; 'Paul Thorpe'
> Cc: [email-masked]
> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt
> 
> 
> stopped
grow
> your
> sequence of 'stuff' that you'd have to write up some verbiage about
the
> 1st

---

From: Thomas Kunz <[email-masked]>
Date: Thu, 06 Dec 2007 13:51:43 +0100

We think, You misunderstood our last post.
With the mentioned structure (AlgorithmValidityInfo) we wanted to show 
that we CANNOT use the AlgorithmIdentifier.

The reason is, we cannot model the following cases:
1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in 
case of DSA).
2. defining ranges is impossible (e.g. 1024 < modulus < 2048)

The main problem is that AlgorithmIdentifier describes entirely one 
algorithm with all its parameters. Therefor it is not possible to set 
different constraints for the parameters.

so & tk

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 6 Dec 2007 09:27:53 -0800

Yes I did misunderstand. With algorithms like DSA where there are few
parameters your structure might work but for EC algorithms (I attached some
of the ASN.1 for their parameters) I don't think the flat sequence of will
work.

  ECParameters ::= CHOICE {
    namedCurve      CURVE.&id({NamedCurve}),
    specifiedCuve   SpecifiedCurve,
    implicitCurve   NULL
  }

  CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
    WITH SYNTAX { ID &id }

  NamedCurve CURVE ::= {
   { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } |
   { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } |
   { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } |
   { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } |
   { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } |
   ... -- Extensible
  }

  SpecifiedCurve ::= SEQUENCE {
    version  SpecifiedCurveVersion
                   ( ecpVer1 | ecpVer2 | ecpVer3 ),
    fieldID  FieldID {{FieldTypes}},
    curve    Curve,            -- Curve E
    base     ECPoint,          -- Base point P
    order    INTEGER,          -- Order n of the base point
    cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
    hash     HashAlgorithm OPTIONAL,
    ...                        -- Extensible
  }

  SpecifiedCurveVersion ::= INTEGER {
    ecpVer1(1),
    ecpVer2(2),
    ecpVer3(3),
    ... -- Extensible
  }
  FIELD-ID ::= TYPE-IDENTIFIER

  FieldID { FIELD-ID:IOSet } ::= SEQUENCE { 
    fieldType FIELD-ID.&id({IOSet}),
    parameters FIELD-ID.&Type({IOSet}{@fieldType})
  }

  FieldTypes FIELD-ID ::= {
    { Prime-p IDENTIFIED BY prime-field } |
    { Characteristic-two IDENTIFIED BY characteristic-two-field } |
    ... -- Extensible
  }

  prime-field OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }

  Prime-p ::= INTEGER

  characteristic-two-field OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }

  Characteristic-two ::= SEQUENCE {
    m INTEGER, -- Field size 2^m
    basis CHARACTERISTIC-TWO.&id({BasisTypes}),
    parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
  }

  CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER

  BasisTypes CHARACTERISTIC-TWO ::= {
    { NULL        IDENTIFIED BY gnBasis } |
    { Trinomial   IDENTIFIED BY tpBasis } |
    { Pentanomial IDENTIFIED BY ppBasis } |
    ...  -- Extensible
  }

  gnBasis OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
    characteristic-two-basis(2) 1 }

  tpBasis OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
    characteristic-two-basis(2) 2 }

  Trinomial ::= INTEGER

  ppBasis OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
    characteristic-two-basis(2) 3 }

  Pentanomial ::= SEQUENCE {
    k1 INTEGER, -- k1 > 0
    k2 INTEGER, -- k2 > k1
    k3 INTEGER  -- k3 > k2
  }

  Curve ::= SEQUENCE {
    a     FieldElement,
    b     FieldElement,
    seed  BIT STRING OPTIONAL
    -- Shall be present if used in SpecifiedCurve
    -- with version of ecdpVer2 or ecdpVer3
  }
  FieldElement ::= OCTET STRING

  ECPoint ::= OCTET STRING 

>[mailto:[email-masked]] On Behalf Of Thomas Kunz
>Sent: Thursday, December 06, 2007 4:52 AM
>To: Turner, Sean P.
>Cc: [email-masked]
>With the mentioned structure (AlgorithmValidityInfo) we wanted 
>to show that we CANNOT use the AlgorithmIdentifier.
>
>1. constraints for more than one parameter (e.g. p > 1024 and 
>q > 160 in case of DSA).
>The main problem is that AlgorithmIdentifier describes 
>entirely one algorithm with all its parameters. Therefor it is 
>not possible to set different constraints for the parameters.
>
>so & tk
>
>
>
>Turner, Sean P. schrieb:
>> This would work for me.
>> 
>> spt
>> 
>>>> AlgorithmValidityInfo ::= SEQUENCE {  identifier  
>>>> AlgorithmIdentifier,

---

From: Thomas Kunz <[email-masked]>
Date: Fri, 07 Dec 2007 16:06:03 +0100

We think, our flat sequence is sufficient.

The goal of a policy is to specify a range for specific 
(safety-critical) parameters of an algorithm. Therefor it's not 
necessary to define all parameters.

In the evaluations of BSI and NIST
(e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms 
only one value is defined (namely q). By NIST a q_length of 160 is 
suitable until 2010.

In this case, the XML structure would be:

<Algorithm>
	<AlgorithmIdentifier>
         	<Name>EC-DSA 160</Name>
         	<ObjectIdentifier>...</ObjectIdentifier>
        	</AlgorithmIdentifier>
         <Parameter name="qLength"><Min>160</Min></Parameter>
         <Validity><End>2010-12-31</End></Validity>
</Algorithm>

so & tk

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 8 Dec 2007 06:43:49 -0800

Maybe not from a control perspective but that is only half of the picture. 
The key value of LTANS as a 'thing' is that is would need to meet both the 
legal and emerging document management processes or else those parties who 
are constrained by those frameworks will not be able to use it, nor will 
those parties attached to the people so constrained.

Todd Glassey

----- Original Message ----- 
From: "Thomas Kunz" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 07, 2007 7:06 AM
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt

> The goal of a policy is to specify a range for specific (safety-critical) 
> parameters of an algorithm. Therefor it's not necessary to define all 
> parameters.
>
> (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only 
> one value is defined (namely q). By NIST a q_length of 160 is suitable 
> until 2010.
>
>>   FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType 
>> FIELD-ID.&id({IOSet}),

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 10 Dec 2007 19:31:54 +0100

Hm, I agree with Thomas. 

Intuitively I feel that a flat structure of parameters will always be
sufficient to describe a used algorithm. Simply because every authority
publishing such info will most probably always publish this in algorithm
name and a simple (1..n) list of its acceptable parameters.

Tobias

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Thomas Kunz
> Sent: Friday, December 07, 2007 4:06 PM
> To: Turner, Sean P.
> Cc: [email-masked]