[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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