----- Original Message -----
From: "Thomas Kunz" <thomas.kunz@xxxxxxxxxxxxxxxxx>
To: "Turner, Sean P." <turners@xxxxxxxx>
Cc: <ietf-ltans@xxxxxxx>
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: owner-ietf-ltans@xxxxxxxxxxxx
>>> [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of Thomas Kunz
>>> Sent: Thursday, December 06, 2007 4:52 AM
>>> To: Turner, Sean P.
>>> Cc: ietf-ltans@xxxxxxx
>>> 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:thomas.kunz@xxxxxxxxxxxxxxxxx]
>>>>> Sent: Wednesday, December 05, 2007 8:02 AM
>>>>> To: Turner, Sean P.
>>>>> Cc: ietf-ltans@xxxxxxx
>>>>> 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
>>>>>>
>>>>>>
>>>>
>>
>>
>