Hm, I agree with Thomas.
Intuitively I feel that a flat structure of parameters will always be
sufficient to describe a used algorithm. Simply because every authority
publishing such info will most probably always publish this in algorithm
name and a simple (1..n) list of its acceptable parameters.
Tobias
> -----Original Message-----
> From: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx]
> On Behalf Of Thomas Kunz
> Sent: Friday, December 07, 2007 4:06 PM
> To: Turner, Sean P.
> Cc: ietf-ltans@xxxxxxx
> 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
> >>>>>
> >>>>>
> >>>
> >
> >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature