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