[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comment on draft-ietf-ltans-dssc-01.txt
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
>>>>
>>>>
>>
>>
>