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

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