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

From: "todd glassey" <[email-masked]>
Date: Thu, 17 Jan 2008 13:07:25 -0800

----- 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.

Actually - this is the problem we are facing now Thomas, that is from an 
evidence management perspective, this "We Think" is not sufficient to assure 
LTANS encapsulated documents meet the emerging and followon legal 
constraints for document archiving is a key flaw in the mindset.

>
> 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.

Uh NO... A policy is a 'rule based on a set of constraints' and as such 
those constraints and the policy itself need to be defined and verifiable as 
well.

>
> 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.

But NIST itself nor BSI are underwriting anyone and those are the key 
issues. Also ANY service MUST meet the new US Rules of Civil Procedure and 
the updated Federal Rules of Evidence in specific to that content's 
admissibility in US Courts as 'ESI'...

>
> 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: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 17 Jan 2008 17:45:26 -0800

Todd and all,

  I believe that Todd has a good and valuable point here that
should not be discounted or otherwise ignored.  It could
be however that whomever the "WE" is which Thomas is referring
to is unknown or not specifically defined or is a broader group that
has little or no concern or consideration as to whether all
are defined, ergo some international rather than US based/centric
legalistic requirement.  If so, and I cannot myself determine base
on what I have seen or read thus far clearly enough to make such
a definitive determination, than I can only logically conclude that
the "Flat sequence" approach in this protocol will face significant
resistance as a viable standard.  As such, it may be that the IETF
will face some significant resistance as a comprehensive standards
body.

  From my own perspective, I am beginning to find these latest
comments in this dialog, increasingly troubling....

Regards,

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]
My Phone: 214-244-4827

---

From: "TS Glassey" <[email-masked]>
Date: Thu, 17 Jan 2008 17:29:43 -0800

----- Original Message ----- 
From: "Jeffrey A. Williams" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Thomas Kunz" <[email-masked]>; "Turner, Sean P." 
<[email-masked]>; <[email-masked]>; "Dan Swanson" 
<[email-masked]>; "DHS cert" <[email-masked]>; "DHS info" 
<[email-masked]>
Sent: Thursday, January 17, 2008 5:45 PM
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt

> should not be discounted or otherwise ignored.

The issue is simple here - these protocols are to perform tasks which have 
an actual impact under the law and as such the effect they produce or which 
can be had by using the protocol MUST be properly defined otherwise there is 
NO POSSIBLE REASON for building this protocol since it will be prevented 
from its being used by the Audit and Insurance Industry who will simply say 
they wont bond or recognize those that use the protocol.

What we need is formal support and buy-in from any number of professional 
industries for LTANS and if we cannot get it, then anyone who uses the 
protocol will  have to have their own protocol certified individually 
including the entire design. The problem is that this would give them 
leverage over what anyone else did with that protocol, since that 
certification would be for a specific implementation and not the actual 
protocol standard under their workproduct.

The problem with this is that this 'commercial ownership of the 
certification' will encumber ALL of the other users who claim that their 
protocol is 'certified' as well.

The reasoning is that one where basic protocol of party "A" was certified, 
to derivative claims against those other users by the first party to have 
their protocol certified. This also includes damages against the IETF in the 
process, and with this type of liability, IMHO no one will touch LTANS with 
a ten foot pole. That said, this can all be set aside by soliciting outside 
critique of the LTANS protocol by the people who would be responsible for 
using it and auditing it's implementation and use.

Just my two cents

Todd Glassey

>  It could