[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comment on draft-ietf-ltans-dssc-01.txt
Todd and all,
I believe that Todd has a good and valuable point here that
should not be discounted or otherwise ignored. It could
be however that whomever the "WE" is which Thomas is referring
to is unknown or not specifically defined or is a broader group that
has little or no concern or consideration as to whether all
are defined, ergo some international rather than US based/centric
legalistic requirement. If so, and I cannot myself determine base
on what I have seen or read thus far clearly enough to make such
a definitive determination, than I can only logically conclude that
the "Flat sequence" approach in this protocol will face significant
resistance as a viable standard. As such, it may be that the IETF
will face some significant resistance as a comprehensive standards
body.
From my own perspective, I am beginning to find these latest
comments in this dialog, increasingly troubling....
Regards,
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
My Phone: 214-244-4827
todd glassey wrote:
> ----- 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
> >>>>>>
> >>>>>>
> >>>>
> >>
> >>
> >