Re: I-D Action:draft-ietf-ltans-dssc-05.txt

[Susanne Okunick <susanneo@xxxxxx>]

Denis,
 
We agree with most of your comments and will try to consider them in our next version. More comments inline...

7. Definition of flexibility:

 

The text states:

 

   Additionally the data structure must be designed independent of the

   intended use, e.g., encryption, signing, verifying, and signature

   renewing.  Thus, the interpretion of the data structure is same for

   every use case.

Firstly there is typo on the word: interpretion

ok.

 

Secondly, the document does not define what is a signature algorithm.

There are three possible answers to that question, that may be illustrated
with the RSA algorithm:

 

   1) it is only the RSA algorithm,

   2) it is the RSA algorithm with a padding function,

   3) it is the RSA algorithm with a padding function and a hash function.

 

The text should clarify which case(s) are supported. If cases 2) or 3) are supported,
then the above text is incorrect.

Every kind of signature algorithm is supported.
 However the analysis is the same for every use case. In case 1) the datastructure is used to find out whether e.g. "RSA with key length 1024" is suitable at any point of time (e.g. now). In case 3) additionally the suitability of any hash algorithm is checked. The datastructure ist interpreted one or more times in the same way.
Secondly, the data structure ist flexible enough to support combined algorithms such like "SHA1withRSA" (example in appendix E). Also in this case the data structure is analysed in the same way.
We think, the text is correct.

We try to give a better definition of algorithm.

 

12. Section 6. Security Considerations

 

In the comments made on draft-04, it has been requested to add text to warn the user that
the processing rule described in section 5 is about *one* algorithm *independently of the use case*.
Depending upon the use case, an algorithm is no more suitable at the time of evaluation, may be
no problem at all.

 

Proposed text:

 

   The processing rule described in section 5 is about one cryptographic

   algorithm independently of the use case.  Depending upon the use case,

   an algorithm that is no more suitable at the time of interest, does not

   necessarily mean that the data structure where it is used is no more

   secure.

 

   For example, an RSA signer's key of 1024 bits is being used in year

   2009.  The validity period of the signature key included in a public key

   certificate is three years.  The signature is time-stamped in year 2009

   with a time-stamp token that uses an RSA key of 2048 bits.

 

   This data structure is revaluated in year 2020. Let us suppose that in

   year 2015 an RSA key size of 1024 bits will be broken.  The fact that

   the signature key of 1024 bits is no more suitable in year 2015 and

   a fortiori in year 2020 does not mean that the whole structure is no

   more secure, if an RSA key size of 2048 bits is still suitable in

   year 2020.

 

   In addition, to the key size considerations, other considerations

   apply, like whether the time-stamp token has been provided by a

   trusted authority.  It means that the simple use of a suitability

   policy is not the single element to consider when evaluating the

   security of a complex data structure using several cryptographic

   algorithms.

 

13. Section 6. Security Considerations . This section should include text to cover the case of encryption.

 

Proposed text:

 

   Re-encrypting documents that were originally encrypted using an

   algorithm that is no more suitable, will not protect the semantics

   of the document, if the document has been intercepted.  However,

   for documents stored in an encrypted form, re-encryption must be

   considered, unless the document has lost its original value due to

   time erosion.

 

We don't see the need to warn the user in detail: We expect the user is familiar with these issues. Additionally in Appendix A we linked to the ERS.

Many thanks for your comments!
Susanne