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

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



Comments on draft-ietf-ltans-dssc-05

 

1. The abstract is only related to digitally signed data. The abstract should be extended to mention encryption.

It should also mention that the use of a weak cryptographic algorithm within a complex data structure
can be protected using a strong cryptographic algorithm which then may render the whole data structure
adequate for its intended use.

 

The current abstract is the following:

 

   In many application areas it must be possible to prove the existence

   and integrity of digital signed data.  This proof depends on the

   security suitability of the cryptographic algorithms used to generate

   or verify the digital signature.  Because algorithms can become weak

   over the years, it is necessary to periodically evaluate their

   security suitability.  When signing or verifying data, these

   evaluations must be considered.  This document specifies a data

   structure that enables automated analysis of the security suitability

   of cryptographic algorithms.

 

Proposed change for the whole abstract to solve these two comments:

 

   Because cryptographic algorithms can become weak over the years,

   it is necessary to evaluate their security suitability.

   When signing or verifying data, or when encrypting or decrypting

   data, these evaluations must be considered.  This document specifies

   a data structure that enables an automated analysis of the security

   suitability of a given cryptographic algorithm at a given point of

   time which may be in the past, at the present time or in the future.

 

   The automated processing of a cryptographic data structure that

   uses several cryptographic algorithms cannot be performed only using

   the previous automated analysis, since in some cases a weak

   cryptographic algorithm can be protected by a strong cryptographic

   algorithm which may make the whole data structure adequate for its

   intended use.

 

 

2. Section 1.1. The text sates:

 

   If algorithms lack the required properties, signatures could be forged.

 

This sentence should be changed into:

 

   If algorithms lack the required properties, signatures could be

   forged, unless they are protected by a strong cryptographic

   algorithm, e.g. a time-stamp token that uses a strong cryptographic

   algorithm.

 

 

3. Section 1.1. The text sates:

 

   Very few algorithms satisfy the security requirements and are

   suitable for usage in signatures.

 

This is not fully correct.

 

This sentence should be changed into:

 

   Cryptographic algorithms that are used in signatures shall resist

   during their period of use.  For signature keys included in public key

   certificates, it is the validity period of the certificate.

 

   Cryptographic algorithms that are used for encryption shall resist

   during the time during which it is planned to keep the information

   confidential.

 

4. Section 1.1. The text sates:

 

A digital signature using a "weak" algorithm has no probative value.

 

This is not fully correct.

 

This sentence should be changed into:

 

   A digital signature using a "weak" algorithm has no probative value,

   unless the "weak" algorithm has been protected by a strong algorithm

   before the time it was considered to be weak.

 

 

5. Section 1.1. The text sates:

 

   For this reason, it is important to periodically evaluate an

   algorithm's fitness and to consider the results of these evaluations

   when creating, verifying or renewing signatures.

 

This is not fully correct. A signature made by a human being that is dead cannot be "renewed".

 

This sentence should be changed into:

 

   For this reason, it is important to periodically evaluate an

   algorithm's fitness and to consider the results of these evaluations

   when creating and verifying signatures, or when maintaining the

   validity of signatures made in the past.

 

6. Section 1.1. The text sates:

 

   This prediction can help to detect whether an insecure algorithm

   is used in a signature or whether a signature has been properly

   preserved.

 

This is not fully correct.

 

This sentence should be changed into:

 

   This prediction can help to detect whether a weak algorithm

   is used in a signature and whether that signature has been properly

   protected in due time by an another signature made using an algorithm

   that is suitable at the present point of time.

 

 

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

 

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.

 

 

8. Section 2.2.:

 

The text states:

 

   An algorithm is suitable if it is contained in the current policy and

   the time of interest is within the validity period.

 

This sentence should be changed into:

 

   An algorithm is suitable *at a time of interest* if it is contained

   in the current policy and the time of interest is within the validity

   period.

 

 

9. Section 5.5. This section should first add another kind of output. Please add the following text:

 

   If the algorithm is not in the policy, an error "algorithm unknown" is

   returned.

 

 

10. Section 5.5.

 

The text states:

 

   If the algorithm is not suitable relative to the time of interest,

   return an error.

 

Change into:

 

   If the algorithm is not suitable relative to the time of interest,

   an error "algorithm unsuitable" is returned.

 

 

11. Section 5.5.

 

The text states:

 

   If the algorithm is suitable, return the Evaluation elements that

   were not discarded.

 

Change into:

 

   If the algorithm is suitable, return the Evaluation elements that

   were not discarded, *in particular its validity period*.

 

 

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.

 

 

14. Appendix A.1. It should be indicated *in the title* that this appendix is informative.

 

Denis

----- Message reçu -----
Date : 2008-11-03, 16:45:01
Sujet : I-D Action:draft-ietf-ltans-dssc-05.txt

Pièce(s) Jointe(s) au message original :
  (1). draft-ietf-ltans-dssc-05.txt

  Title : Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
  Author(s) : T. Kunz, et al.
  Filename : draft-ietf-ltans-dssc-05.txt
  Pages : 41
  Date : 2008-11-03

In many application areas it must be possible to prove the existence
and integrity of digital signed data. This proof depends on the
security suitability of the cryptographic algorithms used to generate
or verify the digital signature. Because algorithms can become weak
over the years, it is necessary to periodically evaluate their
security suitability. When signing or verifying data, these
evaluations must be considered. This document specifies a data
structure that enables automated analysis of the security suitability
of cryptographic algorithms.Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.