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

From: [email-masked]
Date: Sat, 8 Dec 2007 18:32:13 -0500 (EST)

Todd and all,

  I believe Todd has a very good and valid point here.
A flat sequence seems very much less than sufficient.

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

-----Original Message-----
>From: TS Glassey <[email-masked]>
>Sent: Dec 8, 2007 9:43 AM
>To: Thomas Kunz <[email-masked]>, "Turner, Sean P." <[email-masked]>
>Cc: [email-masked]
>Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>
>
>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
>
>
>> 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
>>
>>
>>
>>
>>
>> Turner, Sean P. schrieb:
>>> 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
>>>> -----Original Message-----
>>>> From: [email-masked] 
>>>> [mailto:[email-masked]] On Behalf Of Thomas Kunz
>>>> Sent: Thursday, December 06, 2007 4:52 AM
>>>> To: Turner, Sean P.
>>>> Cc: [email-masked]
>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> Turner, Sean P. schrieb:
>>>>> This would work for me.
>>>>>
>>>>> spt
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Thomas Kunz [mailto:[email-masked]]
>>>>>> Sent: Wednesday, December 05, 2007 8:02 AM
>>>>>> To: Turner, Sean P.
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>>>>>>
>>>>>> 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:
>>>>>>
>>>>>> AlgorithmValidityInfo ::= SEQUENCE {
>>>>>> identifier  AlgorithmIdentifier,
>>>>>> constraint  CHOICE {
>>>>>>                        exact  [0] OCTET STRING,
>>>>>>                        min    [1] OCTET STRING,
>>>>>>                        max    [2] OCTET STRING,
>>>>>>                        range  [3] Range,
>>>>>>                        other  [4] OtherConstraints
>>>>>> validity    Validity OPTIONAL,
>>>>>> information Information OPTIONAL }
>>>>>>
>>>>>> 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.
>>>>>>>
>>>>>>> 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: "Tobias Gondrom" <[email-masked]>
Date: Mon, 10 Dec 2007 19:32:02 +0100

Hi all, 

hm actually I do not understand the argument or miss the point. 
Could you please explain a bit more why your argument mandates against a
flat or for a non-flat structure of the DSSC format?

Thanks, Tobias

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Sunday, December 09, 2007 12:32 AM
> To: TS Glassey
> Cc: [email-masked]
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div.
> of
> >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
> >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve
algorithms
> only
> >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q >
160
> in

---

From: "todd glassey" <[email-masked]>
Date: Mon, 10 Dec 2007 11:05:35 -0800

Tobias - I will answer this when I get home tonight. I am only in the office 
for a little bit today (I have a cold) and need to pull a couple of cat-5 
lines from our new Time Servers into the lab.

Todd