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
-----Original Message-----
From: owner-ietf-ltans@xxxxxxxxxxxx
[mailto:owner-ietf-ltans@xxxxxxxxxxxx]
On Behalf Of jwkckid1@xxxxxxxxxxxxx
Sent: Sunday, December 09, 2007 12:32 AM
To: TS Glassey
Cc: ietf-ltans@xxxxxxx
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
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
jwkckid1@xxxxxxxxxxxxx
Phone: 214-244-4827
-----Original Message-----
>From: TS Glassey <tglassey@xxxxxxxxxxxxx>
>Sent: Dec 8, 2007 9:43 AM
>To: Thomas Kunz <thomas.kunz@xxxxxxxxxxxxxxxxx>, "Turner, Sean P."
<turners@xxxxxxxx>
>Cc: ietf-ltans@xxxxxxx
>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" <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.
>>
>> 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: 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
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>
>