From owner-ietf-ltans@mail.imc.org Wed Oct 8 00:55:17 2008 Return-Path: X-Original-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Delivered-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797373A6BB9 for ; Wed, 8 Oct 2008 00:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.438 X-Spam-Level: X-Spam-Status: No, score=-104.438 tagged_above=-999 required=5 tests=[AWL=2.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eF4f4jGnxCM for ; Wed, 8 Oct 2008 00:55:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 260FF3A6874 for ; Wed, 8 Oct 2008 00:55:12 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m987jh7H067703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2008 00:45:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m987jhnu067702; Wed, 8 Oct 2008 00:45:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m987jh09067695 for ; Wed, 8 Oct 2008 00:45:43 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id DB6BF3A6851; Wed, 8 Oct 2008 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081008074501.DB6BF3A6851@core3.amsl.com> Date: Wed, 8 Oct 2008 00:45:01 -0700 (PDT) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-04.txt Pages : 41 Date : 2008-10-08 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 these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities 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-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ltans-dssc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-08003503.I-D@ietf.org> --NextPart-- From owner-ietf-ltans@mail.imc.org Wed Oct 8 05:23:03 2008 Return-Path: X-Original-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Delivered-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FAD3A692E for ; Wed, 8 Oct 2008 05:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+c3cOd3AKaW for ; Wed, 8 Oct 2008 05:23:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id CD9DC3A682C for ; Wed, 8 Oct 2008 05:23:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m98CGGlu000170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2008 05:16:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m98CGGUl000169; Wed, 8 Oct 2008 05:16:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m98CG5Lr000139 for ; Wed, 8 Oct 2008 05:16:16 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 12106 invoked from network); 8 Oct 2008 12:02:49 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;08 Oct 2008 12:02:49 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 8 Oct 2008 12:02:49 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: I-D Action:draft-ietf-ltans-dssc-04.txt Date: Wed, 8 Oct 2008 08:15:59 -0400 Message-ID: In-Reply-To: <20081008074501.DB6BF3A6851@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-ltans-dssc-04.txt Thread-Index: AckpGlkqudo98IjLQNeSnQdv3AyeKQAJPS0g References: <20081008074501.DB6BF3A6851@core3.amsl.com> From: "Carl Wallace" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This draft is the result of some offlist comments submitted during WG last call for the -03 draft. Last call for this version will start today and end on October 24th. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 08, 2008 3:45 AM To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-04.txt Pages : 41 Date : 2008-10-08 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 these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities 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-04.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. From owner-ietf-ltans@mail.imc.org Tue Oct 21 00:04:04 2008 Return-Path: X-Original-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Delivered-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C9D3A6A24 for ; Tue, 21 Oct 2008 00:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRdOs2Ut7tcg for ; Tue, 21 Oct 2008 00:04:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 50F383A6A12 for ; Tue, 21 Oct 2008 00:04:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L6q97K095154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 23:52:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9L6q8t0095153; Mon, 20 Oct 2008 23:52:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L6ptjL095132; Mon, 20 Oct 2008 23:52:07 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22176; Tue, 21 Oct 2008 09:04:29 +0200 Received: from FRMYA-SIA24 ([129.181.81.4]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008102108511788:159734 ; Tue, 21 Oct 2008 08:51:17 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "owner-ietf-ltans", "IETF LTANS" Subject: RE: I-D Action:draft-ietf-ltans-dssc-04.txt Date: Tue, 21 Oct 2008 08:51:15 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 21/10/2008 08:51:23, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 21/10/2008 08:51:55, Serialize complete at 21/10/2008 08:51:55 Content-Type: multipart/alternative; boundary="----=_NextPart_08102108510267074778150_002" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_NextPart_08102108510267074778150_002 Content-Transfer-Encoding: 8Bit Content-Type: text/plain; charset="ISO-8859-1" Comments on draft-ietf-ltans-dssc-04 1. The title of the document is: “Data Structure for Security Suitabilities of Cryptographic Algorithms”. The document states that the data structure is independent of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. Note that “Suitabilities” should always be used with the singular: Suitability. Replace with: “Data Structure to Estimate the Validity Period of Cryptographic Algorithms”. 2. The acronym DSSC should be changed into: DSEC (Data Structure to Estimate Cryptographic algorithms). 3. The start of the abstract is only related to digitally signed data. However, the fourth use case is about re-encryption, but such a use case is not mentioned in the abstract. The abstract should be extended to mention encryption. 4. This draft defines a data structure which estimates the validity period of cryptographic algorithms independently of the intended use. The text states in the abstract: “This document specifies a data structure that enables automated analysis of the security suitabilities of cryptographic algorithms”. This sentence should be corrected. The document states that the data structure is independent of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. See the comment on the security considerations section for further explanations. Proposed replacement: “This document specifies a data structure that enables an automated estimation of the validity period of a single cryptographic algorithm at a time. The automated processing of a cryptographic data structure that includes one or more cryptographic algorithms needs to be tailored to a specific use case and is outside the scope of this document”. 5. On page 5, the term "security suitability policy" is being used. The data structure is a set of rules which allows to estimate the validity period of various cryptographic algorithms. The wording "security suitability policy" should not be used, because the word “suitable” implies that the algorithm would be suitable in a specific context and there is no such context. Replace the term "security suitability policy” by “cryptographic resistance policy”. The word “suitable” should be replaced in many instances in this document. 6. In the requirements section (2.1), it is mentioned that the integrity and authenticity of a published "data structure" must be assured. Since the previous requirement is source authentication, this requirement should not be mandatory. In fact, the document considers the signature of the data structure as an option, which is fine. 7. In the requirements section (2.1), a requirement is missing: the date of issue of the data structure shall be indicated. In fact, the document considers the date of issue as mandatory, which is fine. 8. In the assumptions section (2.2), it is mentioned that "an algorithm is valid if it is contained in the current policy and the time of interest is within the validity period". This assumption is incorrect. The data structure should be usable to tell "until when" a given algorithm was or will be usable, instead of simply telling "valid". When estimating the cryptographic resistance of an algorithm with this data structure, the output should not simply be "valid" or "invalid", but "valid until XXXX". 9. Section 3.12 is about the validity element. The last sentence of the paragraph defines a processing rule which is the following: "If the end of the validity period is in the past, the algorithm is not suitable". This sentence should be replaced with: "If the end of the validity period is in the past, the algorithm was suitable until that date". 10. Section 5 is about "Processing". The text states: “In the following, a process is described that can be used to determine if an algorithm was valid at a particular point of time”. “Valid” is not the right word. The algorithm was resistant against estimated attacks at a particular point of time”. Replace with: “In the following, a process is described that can be used to determine if one algorithm was resistant against real or estimated attacks at a particular point of time”. 11. Section 5.3 states: "To determine if an algorithm is valid ...". This sentence should be changed into: "To determine the validity period of an algorithm...". Similar changes need to be made in the text that follows. 12. Section 5.5 mentions that if the algorithm is not valid, an error is returned. It would be more adequate to return the Evaluation elements so that a decision can be made, which is dependent both upon the context of use and the data structure where the algorithm is being used. Both sentences from this section should be replaced by. " If the algorithm is in the table, the Evaluation elements are returned. Otherwise an error "algorithm unknown" is returned". 13. Section 6. This section should be expanded to warn the user that the processing rules described in section 5 are about *one* algorithm at a time *independently of the use case*. Depending upon the use case, if an algorithm is no more resistant at the time of evaluation, this may be no problem at all. Let us take an example: an RSA signer's key of 900 bits is being used. If an evaluation is made in year 2015, this key size will probably be broken. Is the algorithm unsuitable in 2015? This fully depends upon the use case and upon the elements of the data structure that are evaluated. Example: if the signature was time-stamped with an RSA signature key of 2048 bits, before an RSA key size of 900 bits was broken, then the data structure is fine. If it was not, the *data structure* is no more resistant at the time of evaluation. Another example is the use of a MD5 hash function. If this hash function is being used in a data structure, but the data has been rehashed with SHA-256 before MD5 was "broken", then the data structure is fine. 14. Section 8. The informative reference [ETSI-TS101903] is obsolete. The last version is: ETSI TS 101 903 V1.3.2 (2006-03). 15. Section 8. The informative reference [ETSI-TS102176-1-2005] is obsolete. The last version is: ETSI TS 102 176-1 V2.0.0 (2007-11). 16. Appendix A.1. It should be indicated that this appendix is informative. 17. Appendix A.1 is a specific use case. If a hash function in the inner timestamp is no more resistant, does it means that the whole structure is invalid ? If yes, does ERS provides a way to protect against this threat ? More explanations should be provided. 18. Appendix A.2. It should be indicated that this appendix is normative. 19. Appendix B. It should be indicated that this appendix is normative. 20. Appendix C. It should be indicated that this appendix is informative. 21. Appendix D. It should be indicated that this appendix is normative. Denis ----- Message reçu ----- De : owner-ietf-ltans À : ietf-ltans Date : 2008-10-08, 14:15:59 Sujet : RE: I-D Action:draft-ietf-ltans-dssc-04.txt This draft is the result of some offlist comments submitted during WG last call for the -03 draft. Last call for this version will start today and end on October 24th. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 08, 2008 3:45 AM To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-04.txt Pages : 41 Date : 2008-10-08 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 these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities 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-04.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. ------=_NextPart_08102108510267074778150_002 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="ISO-8859-1"

Comments on draft-ietf-ltans-dssc-04

 

1. The title of the document is: “Data Structure for Security Suitabilities of Cryptographic

Algorithms”.

 

The document states that the data structure is independent of the intended use (page 8);

therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. Note that

“Suitabilities” should always be used with the singular: Suitability.

 

Replace with: “Data Structure to Estimate the Validity Period of Cryptographic Algorithms”.

 

 

2. The acronym DSSC should be changed into: DSEC (Data Structure to Estimate

Cryptographic algorithms).

 

 

3. The start of the abstract is only related to digitally signed data. However, the fourth use

case is about re-encryption, but such a use case is not mentioned in the abstract. The abstract

should be extended to mention encryption.

 

 

4. This draft defines a data structure which estimates the validity period of cryptographic

algorithms independently of the intended use. The text states in the abstract: “This document

specifies a data structure that enables automated analysis of the security suitabilities of

cryptographic algorithms”.

 

This sentence should be corrected. The document states that the data structure is independent

of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any

intended purpose. See the comment on the security considerations section for further

explanations.

 

Proposed replacement:

 

“This document specifies a data structure that enables an automated estimation of the validity

period of a single cryptographic algorithm at a time. The automated processing of a

cryptographic data structure that includes one or more cryptographic algorithms needs to be

tailored to a specific use case and is outside the scope of this document”.

 

 

5. On page 5, the term "security suitability policy" is being used. The data structure is a set of

rules which allows to estimate the validity period of various cryptographic algorithms. The

wording "security suitability policy" should not be used, because the word “suitable” implies

that the algorithm would be suitable in a specific context and there is no such context.

 

Replace the term "security suitability policy” by “cryptographic resistance policy”.

 

The word “suitable” should be replaced in many instances in this document.

 

 

6. In the requirements section (2.1), it is mentioned that the integrity and authenticity of a

published "data structure" must be assured. Since the previous requirement is source

authentication, this requirement should not be mandatory. In fact, the document considers the

signature of the data structure as an option, which is fine.

 

 

7. In the requirements section (2.1), a requirement is missing: the date of issue of the data

structure shall be indicated. In fact, the document considers the date of issue as mandatory,

which is fine.

 

 

8. In the assumptions section (2.2), it is mentioned that "an algorithm is valid if it is contained

in the current policy and the time of interest is within the validity period". This assumption is

incorrect. The data structure should be usable to tell "until when" a given algorithm was or

will be usable, instead of simply telling "valid".

 

When estimating the cryptographic resistance of an algorithm with this data structure, the

output should not simply be "valid" or "invalid", but "valid until XXXX".

 

 

9. Section 3.12 is about the validity element. The last sentence of the paragraph defines a

processing rule which is the following:

 

"If the end of the validity period is in the past, the algorithm is not suitable".

 

This sentence should be replaced with:

 

"If the end of the validity period is in the past, the algorithm was suitable until that date".

 

 

10. Section 5 is about "Processing".

 

The text states: “In the following, a process is described that can be used to determine if an

algorithm was valid at a particular point of time”.

 

“Valid” is not the right word. The algorithm was resistant against estimated attacks at a

particular point of time”.

 

Replace with: “In the following, a process is described that can be used to determine if one

algorithm was resistant against real or estimated attacks at a particular point of time”.

 

 

11. Section 5.3 states: "To determine if an algorithm is valid ...". This sentence should be

changed into: "To determine the validity period of an algorithm...". Similar changes need to

be made in the text that follows.

 

 

12. Section 5.5 mentions that if the algorithm is not valid, an error is returned. It would be

more adequate to return the Evaluation elements so that a decision can be made, which is

dependent both upon the context of use and the data structure where the algorithm is being

used.

 

Both sentences from this section should be replaced by.

" If the algorithm is in the table, the Evaluation elements are returned.

Otherwise an error "algorithm unknown" is returned".

 

 

13. Section 6. This section should be expanded to warn the user that the processing rules

described in section 5 are about *one* algorithm at a time *independently of the use case*.

Depending upon the use case, if an algorithm is no more resistant at the time of evaluation,

this may be no problem at all.

 

Let us take an example: an RSA signer's key of 900 bits is being used. If an evaluation is

made in year 2015, this key size will probably be broken. Is the algorithm unsuitable in 2015?

This fully depends upon the use case and upon the elements of the data structure that are

evaluated. Example: if the signature was time-stamped with an RSA signature key of 2048

bits, before an RSA key size of 900 bits was broken, then the data structure is fine. If it was

not, the *data structure* is no more resistant at the time of evaluation.

 

Another example is the use of a MD5 hash function. If this hash function is being used in a

data structure, but the data has been rehashed with SHA-256 before MD5 was "broken", then

the data structure is fine.

 

 

14. Section 8. The informative reference [ETSI-TS101903] is obsolete. The last version is:

ETSI TS 101 903 V1.3.2 (2006-03).

 

 

15. Section 8. The informative reference [ETSI-TS102176-1-2005] is obsolete. The last

version is: ETSI TS 102 176-1 V2.0.0 (2007-11).

 

 

16. Appendix A.1. It should be indicated that this appendix is informative.

 

 

17. Appendix A.1 is a specific use case. If a hash function in the inner timestamp is no more

resistant, does it means that the whole structure is invalid ? If yes, does ERS provides a way

to protect against this threat ? More explanations should be provided.

 

 

18. Appendix A.2. It should be indicated that this appendix is normative.

 

 

19. Appendix B. It should be indicated that this appendix is normative.

 

 

20. Appendix C. It should be indicated that this appendix is informative.

 

 

21. Appendix D. It should be indicated that this appendix is normative.

 

Denis
 
----- Message reçu -----
Date : 2008-10-08, 14:15:59
Sujet : RE: I-D Action:draft-ietf-ltans-dssc-04.txt

This draft is the result of some offlist comments submitted during WG
last call for the -03 draft. Last call for this version will start
today and end on October 24th.

-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, October 08, 2008 3:45 AM
To: i-d-announce@ietf.org
Cc: ietf-ltans@imc.org
Subject: I-D Action:draft-ietf-ltans-dssc-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Long-Term Archive and Notary Services
Working Group of the IETF.


  Title : Data Structure for Security Suitabilities of
Cryptographic Algorithms (DSSC)
  Author(s) : T. Kunz, et al.
  Filename : draft-ietf-ltans-dssc-04.txt
  Pages : 41
  Date : 2008-10-08

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 these security
suitabilities. When signing or verifying data, these evaluations must
be considered. This document specifies a data structure that enables
automated analysis of the security suitabilities 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-04.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.


------=_NextPart_08102108510267074778150_002-- From owner-ietf-ltans@mail.imc.org Thu Oct 23 01:26:20 2008 Return-Path: X-Original-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Delivered-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F813A6935 for ; Thu, 23 Oct 2008 01:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bVsHNwaHq7A for ; Thu, 23 Oct 2008 01:26:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 996323A69AF for ; Thu, 23 Oct 2008 01:26:18 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9N8KZWj082899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 01:20:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9N8KZcU082898; Thu, 23 Oct 2008 01:20:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9N8KKCP082878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2008 01:20:33 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.88.87] (sitp2_210.sit.fraunhofer.de [141.12.69.210]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id m9N8JjO7023924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 10:19:45 +0200 Message-ID: <4900338F.6040104@sit.fraunhofer.de> Date: Thu, 23 Oct 2008 10:19:27 +0200 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: denis.pinkas@bull.net, ietf-ltans@imc.org Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for your comments. We will try to consider the comments in the draft. - Thomas Denis Pinkas schrieb: > Comments on draft-ietf-ltans-dssc-04 > > > > 1. The title of the document is: “Data Structure for Security > Suitabilities of Cryptographic > > Algorithms”. > > > > The document states that the data structure is independent of the > intended use (page 8); > > therefore, it cannot be said if an algorithm is *suitable* for any > intended purpose. Note that > > “Suitabilities” should always be used with the singular: Suitability. > > > > Replace with: “Data Structure to Estimate the Validity Period of > Cryptographic Algorithms”. > > > > > > 2. The acronym DSSC should be changed into: DSEC (Data Structure to > Estimate > > Cryptographic algorithms). > > > > > > 3. The start of the abstract is only related to digitally signed data. > However, the fourth use > > case is about re-encryption, but such a use case is not mentioned in the > abstract. The abstract > > should be extended to mention encryption. > > > > > > 4. This draft defines a data structure which estimates the validity > period of cryptographic > > algorithms independently of the intended use. The text states in the > abstract: “This document > > specifies a data structure that enables automated analysis of the > security suitabilities of > > cryptographic algorithms”. > > > > This sentence should be corrected. The document states that the data > structure is independent > > of the intended use (page 8); therefore, it cannot be said if an > algorithm is *suitable* for any > > intended purpose. See the comment on the security considerations section > for further > > explanations. > > > > Proposed replacement: > > > > “This document specifies a data structure that enables an automated > estimation of the validity > > period of a single cryptographic algorithm at a time. The automated > processing of a > > cryptographic data structure that includes one or more cryptographic > algorithms needs to be > > tailored to a specific use case and is outside the scope of this document”. > > > > > > 5. On page 5, the term "security suitability policy" is being used. The > data structure is a set of > > rules which allows to estimate the validity period of various > cryptographic algorithms. The > > wording "security suitability policy" should not be used, because the > word “suitable” implies > > that the algorithm would be suitable in a specific context and there is > no such context. > > > > Replace the term "security suitability policy” by “cryptographic > resistance policy”. > > > > The word “suitable” should be replaced in many instances in this document. > > > > > > 6. In the requirements section (2.1), it is mentioned that the integrity > and authenticity of a > > published "data structure" must be assured. Since the previous > requirement is source > > authentication, this requirement should not be mandatory. In fact, the > document considers the > > signature of the data structure as an option, which is fine. > > > > > > 7. In the requirements section (2.1), a requirement is missing: the date > of issue of the data > > structure shall be indicated. In fact, the document considers the date > of issue as mandatory, > > which is fine. > > > > > > 8. In the assumptions section (2.2), it is mentioned that "an algorithm > is valid if it is contained > > in the current policy and the time of interest is within the validity > period". This assumption is > > incorrect. The data structure should be usable to tell "until when" a > given algorithm was or > > will be usable, instead of simply telling "valid". > > > > When estimating the cryptographic resistance of an algorithm with this > data structure, the > > output should not simply be "valid" or "invalid", but "valid until XXXX". > > > > > > 9. Section 3.12 is about the validity element. The last sentence of the > paragraph defines a > > processing rule which is the following: > > > > "If the end of the validity period is in the past, the algorithm is not > suitable". > > > > This sentence should be replaced with: > > > > "If the end of the validity period is in the past, the algorithm was > suitable until that date". > > > > > > 10. Section 5 is about "Processing". > > > > The text states: “In the following, a process is described that can be > used to determine if an > > algorithm was valid at a particular point of time”. > > > > “Valid” is not the right word. The algorithm was resistant against > estimated attacks at a > > particular point of time”. > > > > Replace with: “In the following, a process is described that can be used > to determine if one > > algorithm was resistant against real or estimated attacks at a > particular point of time”. > > > > > > 11. Section 5.3 states: "To determine if an algorithm is valid ...". > This sentence should be > > changed into: "To determine the validity period of an algorithm...". > Similar changes need to > > be made in the text that follows. > > > > > > 12. Section 5.5 mentions that if the algorithm is not valid, an error is > returned. It would be > > more adequate to return the Evaluation elements so that a decision can > be made, which is > > dependent both upon the context of use and the data structure where the > algorithm is being > > used. > > > > Both sentences from this section should be replaced by. > > " If the algorithm is in the table, the Evaluation elements are returned. > > Otherwise an error "algorithm unknown" is returned". > > > > > > 13. Section 6. This section should be expanded to warn the user that the > processing rules > > described in section 5 are about *one* algorithm at a time > *independently of the use case*. > > Depending upon the use case, if an algorithm is no more resistant at the > time of evaluation, > > this may be no problem at all. > > > > Let us take an example: an RSA signer's key of 900 bits is being used. > If an evaluation is > > made in year 2015, this key size will probably be broken. Is the > algorithm unsuitable in 2015? > > This fully depends upon the use case and upon the elements of the data > structure that are > > evaluated. Example: if the signature was time-stamped with an RSA > signature key of 2048 > > bits, before an RSA key size of 900 bits was broken, then the data > structure is fine. If it was > > not, the *data structure* is no more resistant at the time of evaluation. > > > > Another example is the use of a MD5 hash function. If this hash function > is being used in a > > data structure, but the data has been rehashed with SHA-256 before MD5 > was "broken", then > > the data structure is fine. > > > > > > 14. Section 8. The informative reference [ETSI-TS101903] is obsolete. > The last version is: > > ETSI TS 101 903 V1.3.2 (2006-03). > > > > > > 15. Section 8. The informative reference [ETSI-TS102176-1-2005] is > obsolete. The last > > version is: ETSI TS 102 176-1 V2.0.0 (2007-11). > > > > > > 16. Appendix A.1. It should be indicated that this appendix is informative. > > > > > > 17. Appendix A.1 is a specific use case. If a hash function in the inner > timestamp is no more > > resistant, does it means that the whole structure is invalid ? If yes, > does ERS provides a way > > to protect against this threat ? More explanations should be provided. > > > > > > 18. Appendix A.2. It should be indicated that this appendix is normative. > > > > > > 19. Appendix B. It should be indicated that this appendix is normative. > > > > > > 20. Appendix C. It should be indicated that this appendix is informative. > > > > > > 21. Appendix D. It should be indicated that this appendix is normative. > > > > Denis > From owner-ietf-ltans@mail.imc.org Wed Oct 29 03:46:10 2008 Return-Path: X-Original-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Delivered-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDCF3A6874 for ; Wed, 29 Oct 2008 03:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWHzSgUCKodE for ; Wed, 29 Oct 2008 03:46:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 561DA3A67C1 for ; Wed, 29 Oct 2008 03:46:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TAcNku017851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 03:38:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TAcNxl017850; Wed, 29 Oct 2008 03:38:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TAcBqJ017771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2008 03:38:22 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.88.87] (sitp2_15.sit.fraunhofer.de [141.12.69.15]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id m9TAbaiw026140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 11:37:37 +0100 Message-ID: <49083CDF.2020207@sit.fraunhofer.de> Date: Wed, 29 Oct 2008 11:37:19 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: denis.pinkas@bull.net CC: IETF LTANS Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Comments inline... Denis Pinkas schrieb: > Comments on draft-ietf-ltans-dssc-04 > > > > 1. The title of the document is: “Data Structure for Security > Suitabilities of Cryptographic Algorithms”. > The document states that the data structure is independent of the > intended use (page 8); therefore, it cannot be said if an algorithm > is *suitable* for any intended purpose. > > Note that “Suitabilities” should always be used with the singular: Suitability. > > Replace with: “Data Structure to Estimate the Validity Period of > Cryptographic Algorithms”. > We don't agree with your suggested title. The data structure is used to express policies which are *not* independent of the intended use (see the definition in the terminology). For this reason, the data structure contains the "Usage" element. The data structure itself can be used in different use cases. But one policy doesn't necessarily express that an algorithm is suitable for any intended purpose. We will try to clarify this issue in the draft. > > 2. The acronym DSSC should be changed into: DSEC (Data Structure to > Estimate Cryptographic algorithms). > For the above mentioned reasons, will will keep the acronym DSSC and will only change "Suitabilities" to "Suitability". > > 3. The start of the abstract is only related to digitally signed data. > However, the fourth use case is about re-encryption, but such a > use case is not mentioned in the abstract. The abstract > should be extended to mention encryption. > OK, we will try to include this in the abstract. > > 4. This draft defines a data structure which estimates the validity > period of cryptographic algorithms independently of the intended use. > The text states in the abstract: “This document > specifies a data structure that enables automated analysis of the > security suitabilities of cryptographic algorithms”. > This sentence should be corrected. The document states that the data > structure is independent of the intended use (page 8); therefore, it cannot be said if an > algorithm is *suitable* for any intended purpose. See the comment > on the security considerations section > for further explanations. > see above > > > 6. In the requirements section (2.1), it is mentioned that the integrity > and authenticity of a published "data structure" must be assured. Since the previous > requirement is source authentication, this requirement should not be mandatory. In fact, the > document considers the > signature of the data structure as an option, which is fine. > OK > > 7. In the requirements section (2.1), a requirement is missing: the date > of issue of the data structure shall be indicated. In fact, the document considers the date > of issue as mandatory, which is fine. > Good point, we will add this requirement. > > 8. In the assumptions section (2.2), it is mentioned that "an algorithm > is valid if it is contained in the current policy and the time of interest > is within the validity period". This assumption is > incorrect. The data structure should be usable to tell "until when" a > given algorithm was or will be usable, instead of simply telling "valid". > We think the assumption is correct. An algorithm is valid or suitable if it is contained in the current policy and the time of interest is within the validity period. Of course the data structure is able to tell until when an algorithm was or will be valid, but this has nothing to do with this assumption. In the "processing" section, we give the time of interest as input (i.e. we ask if an algorithm is or was valid at this point of time; we don't ask until when an algorithm was or will be valid). > > > 9. Section 3.12 is about the validity element. The last sentence of the > paragraph defines a processing rule which is the following: > "If the end of the validity period is in the past, the algorithm is not > suitable". > This sentence should be replaced with: > > "If the end of the validity period is in the past, the algorithm was > suitable until that date". > OK. > > > 10. Section 5 is about "Processing". > > The text states: “In the following, a process is described that can be > used to determine if an algorithm was valid at a particular point of time”. > “Valid” is not the right word. The algorithm was resistant against > estimated attacks at a particular point of time”. > > Replace with: “In the following, a process is described that can be used > to determine if one algorithm was resistant against real or estimated attacks at a > particular point of time”. > In our context we use "valid" and "suitable" synonymic to each other. We will try to clarify this in the terminology. > > > 13. Section 6. This section should be expanded to warn the user that the > processing rules described in section 5 are about *one* algorithm at a time > *independently of the use case*. > Depending upon the use case, if an algorithm is no more resistant at the > time of evaluation, this may be no problem at all. > > Let us take an example: an RSA signer's key of 900 bits is being used. > If an evaluation is made in year 2015, this key size will probably be > broken. Is the algorithm unsuitable in 2015? > This fully depends upon the use case and upon the elements of the data > structure that are evaluated. Example: if the signature was time-stamped > with an RSA signature key of 2048 > bits, before an RSA key size of 900 bits was broken, then the data > structure is fine. If it was not, the *data structure* is no more resistant > at the time of evaluation. > Another example is the use of a MD5 hash function. If this hash function > is being used in a data structure, but the data has been rehashed with > SHA-256 before MD5 was "broken", then the data structure is fine. > We don't see the need for this warning. The data structure is solely about evaluating algorithms, not about evaluating data structures which use these algorithms. To take your example, the data structure is used to verify if RSA with 900 bit was valid at the point of time when the signature was time-stamped with 2048 bit key. We think the document sufficiently illustrate this issue. Thomas From owner-ietf-ltans@mail.imc.org Wed Oct 29 11:21:05 2008 Return-Path: X-Original-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Delivered-To: ietfarch-ltans-archive-ba2WohFa@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600503A680C for ; Wed, 29 Oct 2008 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCpUMae3uBUg for ; Wed, 29 Oct 2008 11:21:03 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 145683A6405 for ; Wed, 29 Oct 2008 11:21:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TIDWxY018256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 11:13:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TIDW5e018253; Wed, 29 Oct 2008 11:13:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TIDKLS018184 for ; Wed, 29 Oct 2008 11:13:31 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JZoNDHVOceCMCbto6mMhjAQZN5N/ILXWQt3f9o7TPsWn3dme61AutrfScZaJ3Sjr; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvFXh-0000Ig-1W; Wed, 29 Oct 2008 14:13:17 -0400 Message-ID: <010001c939f2$220b6210$2000a8c0@tsg1> From: "TS Glassey" To: "Thomas Kunz" , Cc: "IETF LTANS" References: <49083CDF.2020207@sit.fraunhofer.de> Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt Date: Wed, 29 Oct 2008 11:13:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e394cc44190f11446645e31a6cba78bf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Guys ----- Original Message ----- From: "Thomas Kunz" To: Cc: "IETF LTANS" Sent: Wednesday, October 29, 2008 3:37 AM Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt > > Comments inline... > > Denis Pinkas schrieb: >> Comments on draft-ietf-ltans-dssc-04 >> >> >> >> 1. The title of the document is: “Data Structure for Security >> Suitabilities of Cryptographic Algorithms”. >> The document states that the data structure is independent of the >> intended use (page 8); therefore, it cannot be said if an algorithm > > is *suitable* for any intended purpose. > > >> Note that “Suitabilities” should always be used with the singular: >> Suitability. >> > > Replace with: “Data Structure to Estimate the Validity Period of >> Cryptographic Algorithms”. >> > We don't agree with your suggested title. I love the title it means that there is a likelyhood that Deni's masterpiece is already covered by my Patent issuance. However I also suggest changing it. > The data structure is used to > express policies which are *not* independent of the intended use (see > the definition in the terminology). For this reason, the data structure > contains the "Usage" element. Agreed > The data structure itself can be used in > different use cases. As a policy control object - with a reliable source of information relative to time and location - that for sure is covered under our patent. > But one policy doesn't necessarily express that an > algorithm is suitable for any intended purpose. > We will try to clarify this issue in the draft. > >> >> 2. The acronym DSSC should be changed into: DSEC (Data Structure to >> Estimate Cryptographic algorithms). >> > For the above mentioned reasons, will will keep the acronym DSSC and > will only change "Suitabilities" to "Suitability". OK. > >> >> 3. The start of the abstract is only related to digitally signed data. >> However, the fourth use case is about re-encryption, but such a > > use case is not mentioned in the abstract. The abstract >> should be extended to mention encryption. >> > OK, we will try to include this in the abstract. No folks... ABSOLUTELY NO... From an "evidentiary perspecitve" the interior content (i.e. the Crypto-payload) cannot be resigned except in the form of newly included encapsulation or it will break every digital evidence standard on this planet. Simply put the resigning of the content unless it is a layered encapsulation will IMHO destroy the provable Chain of Custody such that the content's anti-spoliation controls would be meaningless before a Court with any attorney's that get it. If however you had a "Ceremony in Software" that would allow that data to be 'de-signed' and reduced to its original state there might be a process for this but that is included in my new amendment to the existing patent so it also is protected. > >> >> 4. This draft defines a data structure which estimates the validity >> period of cryptographic algorithms independently of the intended use. > > The text states in the abstract: “This document >> specifies a data structure that enables automated analysis of the >> security suitabilities of cryptographic algorithms”. >> This sentence should be corrected. The document states that the data >> structure is independent of the intended use (page 8); therefore, it >> cannot be said if an >> algorithm is *suitable* for any intended purpose. See the comment > > on the security considerations section >> for further explanations. >> > see above > >> >> >> 6. In the requirements section (2.1), it is mentioned that the integrity >> and authenticity of a published "data structure" must be assured. \ that's actually supposed to be a MUST not a 'must'. > > Since the previous >> requirement is source authentication, this requirement should not be >> mandatory. In fact, the >> document considers the >> signature of the data structure as an option, which is fine. >> > OK Which again destroys the integrity of the CHAIN OF CUSTODY making the evidence produced hear-say at best. > >> >> 7. In the requirements section (2.1), a requirement is missing: the date >> of issue of the data structure shall be indicated. In fact, the document >> considers the date >> of issue as mandatory, which is fine. >> > Good point, we will add this requirement. Depending on what the DATE control is used for there are a number other issues including of all things McNeil's and my patent. > >> >> 8. In the assumptions section (2.2), it is mentioned that "an algorithm >> is valid if it is contained in the current policy and the time of >> interest > > is within the validity period". This assumption is >> incorrect. The data structure should be usable to tell "until when" a >> given algorithm was or will be usable, instead of simply telling "valid". >> This is an issue - there is an ASSUMPTION here which should not be. NOTHING about EVIDENCE and its protection can be assumed. Proof for each assertion MUST be part of the control process. > We think the assumption is correct. An algorithm is valid or suitable if > it is contained in the current policy and the time of interest > is within the validity period. Of course the data structure is able to > tell until when an algorithm was or will be valid, but this has nothing > to do with this assumption. > In the "processing" section, we give the time of interest as input (i.e. > we ask if an algorithm is or was valid at this point of time; we don't > ask until when an algorithm was or will be valid). > >> >> >> 9. Section 3.12 is about the validity element. The last sentence of the >> paragraph defines a processing rule which is the following: >> "If the end of the validity period is in the past, the algorithm is not >> suitable". >> This sentence should be replaced with: >> >> "If the end of the validity period is in the past, the algorithm was >> suitable until that date". >> > OK. Uh - expired time-stamps and ALG Identifiers are ONLY persuant to how an individual record was 'stored' - the expiry of this is worthless unless something actually happens. So what is it that this expiry is setup for? > >> >> >> 10. Section 5 is about "Processing". >> >> The text states: “In the following, a process is described that can be >> used to determine if an algorithm was valid at a particular point of >> time”. >> “Valid” is not the right word. The algorithm was resistant against >> estimated attacks at a particular point of time”. >> >> Replace with: “In the following, a process is described that can be used >> to determine if one algorithm was resistant against real or estimated >> attacks at a >> particular point of time”. >> > In our context we use "valid" and "suitable" synonymic to each other. We > will try to clarify this in the terminology. > >> >> >> 13. Section 6. This section should be expanded to warn the user that the >> processing rules described in section 5 are about *one* algorithm at a >> time >> *independently of the use case*. >> Depending upon the use case, if an algorithm is no more resistant at the >> time of evaluation, this may be no problem at all. >> >> Let us take an example: an RSA signer's key of 900 bits is being used. >> If an evaluation is made in year 2015, this key size will probably be > > broken. Is the algorithm unsuitable in 2015? >> This fully depends upon the use case and upon the elements of the data >> structure that are evaluated. Example: if the signature was time-stamped > > with an RSA signature key of 2048 >> bits, before an RSA key size of 900 bits was broken, then the data >> structure is fine. If it was not, the *data structure* is no more >> resistant > > at the time of evaluation. > >> Another example is the use of a MD5 hash function. If this hash function >> is being used in a data structure, but the data has been rehashed with > > SHA-256 before MD5 was "broken", then the data structure is fine. >> > We don't see the need for this warning. The data structure is solely > about evaluating algorithms, not about evaluating data structures which > use these algorithms. To take your example, the data structure is used > to verify if RSA with 900 bit was valid at the point of time when the > signature was time-stamped with 2048 bit key. > We think the document sufficiently illustrate this issue. > > > > > Thomas > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.4/1754 - Release Date: 10/29/2008 7:45 AM Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TIDWxY018256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 11:13:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TIDW5e018253; Wed, 29 Oct 2008 11:13:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TIDKLS018184 for ; Wed, 29 Oct 2008 11:13:31 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JZoNDHVOceCMCbto6mMhjAQZN5N/ILXWQt3f9o7TPsWn3dme61AutrfScZaJ3Sjr; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KvFXh-0000Ig-1W; Wed, 29 Oct 2008 14:13:17 -0400 Message-ID: <010001c939f2$220b6210$2000a8c0@tsg1> From: "TS Glassey" To: "Thomas Kunz" , Cc: "IETF LTANS" References: <49083CDF.2020207@sit.fraunhofer.de> Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt Date: Wed, 29 Oct 2008 11:13:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e394cc44190f11446645e31a6cba78bf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Guys ----- Original Message ----- From: "Thomas Kunz" To: Cc: "IETF LTANS" Sent: Wednesday, October 29, 2008 3:37 AM Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt > > Comments inline... > > Denis Pinkas schrieb: >> Comments on draft-ietf-ltans-dssc-04 >> >> >> >> 1. The title of the document is: “Data Structure for Security >> Suitabilities of Cryptographic Algorithms”. >> The document states that the data structure is independent of the >> intended use (page 8); therefore, it cannot be said if an algorithm > > is *suitable* for any intended purpose. > > >> Note that “Suitabilities” should always be used with the singular: >> Suitability. >> > > Replace with: “Data Structure to Estimate the Validity Period of >> Cryptographic Algorithms”. >> > We don't agree with your suggested title. I love the title it means that there is a likelyhood that Deni's masterpiece is already covered by my Patent issuance. However I also suggest changing it. > The data structure is used to > express policies which are *not* independent of the intended use (see > the definition in the terminology). For this reason, the data structure > contains the "Usage" element. Agreed > The data structure itself can be used in > different use cases. As a policy control object - with a reliable source of information relative to time and location - that for sure is covered under our patent. > But one policy doesn't necessarily express that an > algorithm is suitable for any intended purpose. > We will try to clarify this issue in the draft. > >> >> 2. The acronym DSSC should be changed into: DSEC (Data Structure to >> Estimate Cryptographic algorithms). >> > For the above mentioned reasons, will will keep the acronym DSSC and > will only change "Suitabilities" to "Suitability". OK. > >> >> 3. The start of the abstract is only related to digitally signed data. >> However, the fourth use case is about re-encryption, but such a > > use case is not mentioned in the abstract. The abstract >> should be extended to mention encryption. >> > OK, we will try to include this in the abstract. No folks... ABSOLUTELY NO... From an "evidentiary perspecitve" the interior content (i.e. the Crypto-payload) cannot be resigned except in the form of newly included encapsulation or it will break every digital evidence standard on this planet. Simply put the resigning of the content unless it is a layered encapsulation will IMHO destroy the provable Chain of Custody such that the content's anti-spoliation controls would be meaningless before a Court with any attorney's that get it. If however you had a "Ceremony in Software" that would allow that data to be 'de-signed' and reduced to its original state there might be a process for this but that is included in my new amendment to the existing patent so it also is protected. > >> >> 4. This draft defines a data structure which estimates the validity >> period of cryptographic algorithms independently of the intended use. > > The text states in the abstract: “This document >> specifies a data structure that enables automated analysis of the >> security suitabilities of cryptographic algorithms”. >> This sentence should be corrected. The document states that the data >> structure is independent of the intended use (page 8); therefore, it >> cannot be said if an >> algorithm is *suitable* for any intended purpose. See the comment > > on the security considerations section >> for further explanations. >> > see above > >> >> >> 6. In the requirements section (2.1), it is mentioned that the integrity >> and authenticity of a published "data structure" must be assured. \ that's actually supposed to be a MUST not a 'must'. > > Since the previous >> requirement is source authentication, this requirement should not be >> mandatory. In fact, the >> document considers the >> signature of the data structure as an option, which is fine. >> > OK Which again destroys the integrity of the CHAIN OF CUSTODY making the evidence produced hear-say at best. > >> >> 7. In the requirements section (2.1), a requirement is missing: the date >> of issue of the data structure shall be indicated. In fact, the document >> considers the date >> of issue as mandatory, which is fine. >> > Good point, we will add this requirement. Depending on what the DATE control is used for there are a number other issues including of all things McNeil's and my patent. > >> >> 8. In the assumptions section (2.2), it is mentioned that "an algorithm >> is valid if it is contained in the current policy and the time of >> interest > > is within the validity period". This assumption is >> incorrect. The data structure should be usable to tell "until when" a >> given algorithm was or will be usable, instead of simply telling "valid". >> This is an issue - there is an ASSUMPTION here which should not be. NOTHING about EVIDENCE and its protection can be assumed. Proof for each assertion MUST be part of the control process. > We think the assumption is correct. An algorithm is valid or suitable if > it is contained in the current policy and the time of interest > is within the validity period. Of course the data structure is able to > tell until when an algorithm was or will be valid, but this has nothing > to do with this assumption. > In the "processing" section, we give the time of interest as input (i.e. > we ask if an algorithm is or was valid at this point of time; we don't > ask until when an algorithm was or will be valid). > >> >> >> 9. Section 3.12 is about the validity element. The last sentence of the >> paragraph defines a processing rule which is the following: >> "If the end of the validity period is in the past, the algorithm is not >> suitable". >> This sentence should be replaced with: >> >> "If the end of the validity period is in the past, the algorithm was >> suitable until that date". >> > OK. Uh - expired time-stamps and ALG Identifiers are ONLY persuant to how an individual record was 'stored' - the expiry of this is worthless unless something actually happens. So what is it that this expiry is setup for? > >> >> >> 10. Section 5 is about "Processing". >> >> The text states: “In the following, a process is described that can be >> used to determine if an algorithm was valid at a particular point of >> time”. >> “Valid” is not the right word. The algorithm was resistant against >> estimated attacks at a particular point of time”. >> >> Replace with: “In the following, a process is described that can be used >> to determine if one algorithm was resistant against real or estimated >> attacks at a >> particular point of time”. >> > In our context we use "valid" and "suitable" synonymic to each other. We > will try to clarify this in the terminology. > >> >> >> 13. Section 6. This section should be expanded to warn the user that the >> processing rules described in section 5 are about *one* algorithm at a >> time >> *independently of the use case*. >> Depending upon the use case, if an algorithm is no more resistant at the >> time of evaluation, this may be no problem at all. >> >> Let us take an example: an RSA signer's key of 900 bits is being used. >> If an evaluation is made in year 2015, this key size will probably be > > broken. Is the algorithm unsuitable in 2015? >> This fully depends upon the use case and upon the elements of the data >> structure that are evaluated. Example: if the signature was time-stamped > > with an RSA signature key of 2048 >> bits, before an RSA key size of 900 bits was broken, then the data >> structure is fine. If it was not, the *data structure* is no more >> resistant > > at the time of evaluation. > >> Another example is the use of a MD5 hash function. If this hash function >> is being used in a data structure, but the data has been rehashed with > > SHA-256 before MD5 was "broken", then the data structure is fine. >> > We don't see the need for this warning. The data structure is solely > about evaluating algorithms, not about evaluating data structures which > use these algorithms. To take your example, the data structure is used > to verify if RSA with 900 bit was valid at the point of time when the > signature was time-stamped with 2048 bit key. > We think the document sufficiently illustrate this issue. > > > > > Thomas > -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.4/1754 - Release Date: 10/29/2008 7:45 AM Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TAcNku017851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 03:38:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9TAcNxl017850; Wed, 29 Oct 2008 03:38:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9TAcBqJ017771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2008 03:38:22 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.88.87] (sitp2_15.sit.fraunhofer.de [141.12.69.15]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id m9TAbaiw026140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 11:37:37 +0100 Message-ID: <49083CDF.2020207@sit.fraunhofer.de> Date: Wed, 29 Oct 2008 11:37:19 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: denis.pinkas@bull.net CC: IETF LTANS Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Comments inline... Denis Pinkas schrieb: > Comments on draft-ietf-ltans-dssc-04 > > > > 1. The title of the document is: “Data Structure for Security > Suitabilities of Cryptographic Algorithms”. > The document states that the data structure is independent of the > intended use (page 8); therefore, it cannot be said if an algorithm > is *suitable* for any intended purpose. > > Note that “Suitabilities” should always be used with the singular: Suitability. > > Replace with: “Data Structure to Estimate the Validity Period of > Cryptographic Algorithms”. > We don't agree with your suggested title. The data structure is used to express policies which are *not* independent of the intended use (see the definition in the terminology). For this reason, the data structure contains the "Usage" element. The data structure itself can be used in different use cases. But one policy doesn't necessarily express that an algorithm is suitable for any intended purpose. We will try to clarify this issue in the draft. > > 2. The acronym DSSC should be changed into: DSEC (Data Structure to > Estimate Cryptographic algorithms). > For the above mentioned reasons, will will keep the acronym DSSC and will only change "Suitabilities" to "Suitability". > > 3. The start of the abstract is only related to digitally signed data. > However, the fourth use case is about re-encryption, but such a > use case is not mentioned in the abstract. The abstract > should be extended to mention encryption. > OK, we will try to include this in the abstract. > > 4. This draft defines a data structure which estimates the validity > period of cryptographic algorithms independently of the intended use. > The text states in the abstract: “This document > specifies a data structure that enables automated analysis of the > security suitabilities of cryptographic algorithms”. > This sentence should be corrected. The document states that the data > structure is independent of the intended use (page 8); therefore, it cannot be said if an > algorithm is *suitable* for any intended purpose. See the comment > on the security considerations section > for further explanations. > see above > > > 6. In the requirements section (2.1), it is mentioned that the integrity > and authenticity of a published "data structure" must be assured. Since the previous > requirement is source authentication, this requirement should not be mandatory. In fact, the > document considers the > signature of the data structure as an option, which is fine. > OK > > 7. In the requirements section (2.1), a requirement is missing: the date > of issue of the data structure shall be indicated. In fact, the document considers the date > of issue as mandatory, which is fine. > Good point, we will add this requirement. > > 8. In the assumptions section (2.2), it is mentioned that "an algorithm > is valid if it is contained in the current policy and the time of interest > is within the validity period". This assumption is > incorrect. The data structure should be usable to tell "until when" a > given algorithm was or will be usable, instead of simply telling "valid". > We think the assumption is correct. An algorithm is valid or suitable if it is contained in the current policy and the time of interest is within the validity period. Of course the data structure is able to tell until when an algorithm was or will be valid, but this has nothing to do with this assumption. In the "processing" section, we give the time of interest as input (i.e. we ask if an algorithm is or was valid at this point of time; we don't ask until when an algorithm was or will be valid). > > > 9. Section 3.12 is about the validity element. The last sentence of the > paragraph defines a processing rule which is the following: > "If the end of the validity period is in the past, the algorithm is not > suitable". > This sentence should be replaced with: > > "If the end of the validity period is in the past, the algorithm was > suitable until that date". > OK. > > > 10. Section 5 is about "Processing". > > The text states: “In the following, a process is described that can be > used to determine if an algorithm was valid at a particular point of time”. > “Valid” is not the right word. The algorithm was resistant against > estimated attacks at a particular point of time”. > > Replace with: “In the following, a process is described that can be used > to determine if one algorithm was resistant against real or estimated attacks at a > particular point of time”. > In our context we use "valid" and "suitable" synonymic to each other. We will try to clarify this in the terminology. > > > 13. Section 6. This section should be expanded to warn the user that the > processing rules described in section 5 are about *one* algorithm at a time > *independently of the use case*. > Depending upon the use case, if an algorithm is no more resistant at the > time of evaluation, this may be no problem at all. > > Let us take an example: an RSA signer's key of 900 bits is being used. > If an evaluation is made in year 2015, this key size will probably be > broken. Is the algorithm unsuitable in 2015? > This fully depends upon the use case and upon the elements of the data > structure that are evaluated. Example: if the signature was time-stamped > with an RSA signature key of 2048 > bits, before an RSA key size of 900 bits was broken, then the data > structure is fine. If it was not, the *data structure* is no more resistant > at the time of evaluation. > Another example is the use of a MD5 hash function. If this hash function > is being used in a data structure, but the data has been rehashed with > SHA-256 before MD5 was "broken", then the data structure is fine. > We don't see the need for this warning. The data structure is solely about evaluating algorithms, not about evaluating data structures which use these algorithms. To take your example, the data structure is used to verify if RSA with 900 bit was valid at the point of time when the signature was time-stamped with 2048 bit key. We think the document sufficiently illustrate this issue. Thomas Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9N8KZWj082899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 01:20:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9N8KZcU082898; Thu, 23 Oct 2008 01:20:35 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9N8KKCP082878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2008 01:20:33 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.88.87] (sitp2_210.sit.fraunhofer.de [141.12.69.210]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id m9N8JjO7023924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 10:19:45 +0200 Message-ID: <4900338F.6040104@sit.fraunhofer.de> Date: Thu, 23 Oct 2008 10:19:27 +0200 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: denis.pinkas@bull.net, ietf-ltans@imc.org Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for your comments. We will try to consider the comments in the draft. - Thomas Denis Pinkas schrieb: > Comments on draft-ietf-ltans-dssc-04 > > > > 1. The title of the document is: “Data Structure for Security > Suitabilities of Cryptographic > > Algorithms”. > > > > The document states that the data structure is independent of the > intended use (page 8); > > therefore, it cannot be said if an algorithm is *suitable* for any > intended purpose. Note that > > “Suitabilities” should always be used with the singular: Suitability. > > > > Replace with: “Data Structure to Estimate the Validity Period of > Cryptographic Algorithms”. > > > > > > 2. The acronym DSSC should be changed into: DSEC (Data Structure to > Estimate > > Cryptographic algorithms). > > > > > > 3. The start of the abstract is only related to digitally signed data. > However, the fourth use > > case is about re-encryption, but such a use case is not mentioned in the > abstract. The abstract > > should be extended to mention encryption. > > > > > > 4. This draft defines a data structure which estimates the validity > period of cryptographic > > algorithms independently of the intended use. The text states in the > abstract: “This document > > specifies a data structure that enables automated analysis of the > security suitabilities of > > cryptographic algorithms”. > > > > This sentence should be corrected. The document states that the data > structure is independent > > of the intended use (page 8); therefore, it cannot be said if an > algorithm is *suitable* for any > > intended purpose. See the comment on the security considerations section > for further > > explanations. > > > > Proposed replacement: > > > > “This document specifies a data structure that enables an automated > estimation of the validity > > period of a single cryptographic algorithm at a time. The automated > processing of a > > cryptographic data structure that includes one or more cryptographic > algorithms needs to be > > tailored to a specific use case and is outside the scope of this document”. > > > > > > 5. On page 5, the term "security suitability policy" is being used. The > data structure is a set of > > rules which allows to estimate the validity period of various > cryptographic algorithms. The > > wording "security suitability policy" should not be used, because the > word “suitable” implies > > that the algorithm would be suitable in a specific context and there is > no such context. > > > > Replace the term "security suitability policy” by “cryptographic > resistance policy”. > > > > The word “suitable” should be replaced in many instances in this document. > > > > > > 6. In the requirements section (2.1), it is mentioned that the integrity > and authenticity of a > > published "data structure" must be assured. Since the previous > requirement is source > > authentication, this requirement should not be mandatory. In fact, the > document considers the > > signature of the data structure as an option, which is fine. > > > > > > 7. In the requirements section (2.1), a requirement is missing: the date > of issue of the data > > structure shall be indicated. In fact, the document considers the date > of issue as mandatory, > > which is fine. > > > > > > 8. In the assumptions section (2.2), it is mentioned that "an algorithm > is valid if it is contained > > in the current policy and the time of interest is within the validity > period". This assumption is > > incorrect. The data structure should be usable to tell "until when" a > given algorithm was or > > will be usable, instead of simply telling "valid". > > > > When estimating the cryptographic resistance of an algorithm with this > data structure, the > > output should not simply be "valid" or "invalid", but "valid until XXXX". > > > > > > 9. Section 3.12 is about the validity element. The last sentence of the > paragraph defines a > > processing rule which is the following: > > > > "If the end of the validity period is in the past, the algorithm is not > suitable". > > > > This sentence should be replaced with: > > > > "If the end of the validity period is in the past, the algorithm was > suitable until that date". > > > > > > 10. Section 5 is about "Processing". > > > > The text states: “In the following, a process is described that can be > used to determine if an > > algorithm was valid at a particular point of time”. > > > > “Valid” is not the right word. The algorithm was resistant against > estimated attacks at a > > particular point of time”. > > > > Replace with: “In the following, a process is described that can be used > to determine if one > > algorithm was resistant against real or estimated attacks at a > particular point of time”. > > > > > > 11. Section 5.3 states: "To determine if an algorithm is valid ...". > This sentence should be > > changed into: "To determine the validity period of an algorithm...". > Similar changes need to > > be made in the text that follows. > > > > > > 12. Section 5.5 mentions that if the algorithm is not valid, an error is > returned. It would be > > more adequate to return the Evaluation elements so that a decision can > be made, which is > > dependent both upon the context of use and the data structure where the > algorithm is being > > used. > > > > Both sentences from this section should be replaced by. > > " If the algorithm is in the table, the Evaluation elements are returned. > > Otherwise an error "algorithm unknown" is returned". > > > > > > 13. Section 6. This section should be expanded to warn the user that the > processing rules > > described in section 5 are about *one* algorithm at a time > *independently of the use case*. > > Depending upon the use case, if an algorithm is no more resistant at the > time of evaluation, > > this may be no problem at all. > > > > Let us take an example: an RSA signer's key of 900 bits is being used. > If an evaluation is > > made in year 2015, this key size will probably be broken. Is the > algorithm unsuitable in 2015? > > This fully depends upon the use case and upon the elements of the data > structure that are > > evaluated. Example: if the signature was time-stamped with an RSA > signature key of 2048 > > bits, before an RSA key size of 900 bits was broken, then the data > structure is fine. If it was > > not, the *data structure* is no more resistant at the time of evaluation. > > > > Another example is the use of a MD5 hash function. If this hash function > is being used in a > > data structure, but the data has been rehashed with SHA-256 before MD5 > was "broken", then > > the data structure is fine. > > > > > > 14. Section 8. The informative reference [ETSI-TS101903] is obsolete. > The last version is: > > ETSI TS 101 903 V1.3.2 (2006-03). > > > > > > 15. Section 8. The informative reference [ETSI-TS102176-1-2005] is > obsolete. The last > > version is: ETSI TS 102 176-1 V2.0.0 (2007-11). > > > > > > 16. Appendix A.1. It should be indicated that this appendix is informative. > > > > > > 17. Appendix A.1 is a specific use case. If a hash function in the inner > timestamp is no more > > resistant, does it means that the whole structure is invalid ? If yes, > does ERS provides a way > > to protect against this threat ? More explanations should be provided. > > > > > > 18. Appendix A.2. It should be indicated that this appendix is normative. > > > > > > 19. Appendix B. It should be indicated that this appendix is normative. > > > > > > 20. Appendix C. It should be indicated that this appendix is informative. > > > > > > 21. Appendix D. It should be indicated that this appendix is normative. > > > > Denis > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L6q97K095154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 23:52:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9L6q8t0095153; Mon, 20 Oct 2008 23:52:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L6ptjL095132; Mon, 20 Oct 2008 23:52:07 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22176; Tue, 21 Oct 2008 09:04:29 +0200 Received: from FRMYA-SIA24 ([129.181.81.4]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008102108511788:159734 ; Tue, 21 Oct 2008 08:51:17 +0200 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "owner-ietf-ltans", "IETF LTANS" Subject: RE: I-D Action:draft-ietf-ltans-dssc-04.txt Date: Tue, 21 Oct 2008 08:51:15 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 21/10/2008 08:51:23, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 21/10/2008 08:51:55, Serialize complete at 21/10/2008 08:51:55 Content-Type: multipart/alternative; boundary="----=_NextPart_08102108510267074778150_002" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_NextPart_08102108510267074778150_002 Content-Transfer-Encoding: 8Bit Content-Type: text/plain; charset="ISO-8859-1" Comments on draft-ietf-ltans-dssc-04 1. The title of the document is: “Data Structure for Security Suitabilities of Cryptographic Algorithms”. The document states that the data structure is independent of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. Note that “Suitabilities” should always be used with the singular: Suitability. Replace with: “Data Structure to Estimate the Validity Period of Cryptographic Algorithms”. 2. The acronym DSSC should be changed into: DSEC (Data Structure to Estimate Cryptographic algorithms). 3. The start of the abstract is only related to digitally signed data. However, the fourth use case is about re-encryption, but such a use case is not mentioned in the abstract. The abstract should be extended to mention encryption. 4. This draft defines a data structure which estimates the validity period of cryptographic algorithms independently of the intended use. The text states in the abstract: “This document specifies a data structure that enables automated analysis of the security suitabilities of cryptographic algorithms”. This sentence should be corrected. The document states that the data structure is independent of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. See the comment on the security considerations section for further explanations. Proposed replacement: “This document specifies a data structure that enables an automated estimation of the validity period of a single cryptographic algorithm at a time. The automated processing of a cryptographic data structure that includes one or more cryptographic algorithms needs to be tailored to a specific use case and is outside the scope of this document”. 5. On page 5, the term "security suitability policy" is being used. The data structure is a set of rules which allows to estimate the validity period of various cryptographic algorithms. The wording "security suitability policy" should not be used, because the word “suitable” implies that the algorithm would be suitable in a specific context and there is no such context. Replace the term "security suitability policy” by “cryptographic resistance policy”. The word “suitable” should be replaced in many instances in this document. 6. In the requirements section (2.1), it is mentioned that the integrity and authenticity of a published "data structure" must be assured. Since the previous requirement is source authentication, this requirement should not be mandatory. In fact, the document considers the signature of the data structure as an option, which is fine. 7. In the requirements section (2.1), a requirement is missing: the date of issue of the data structure shall be indicated. In fact, the document considers the date of issue as mandatory, which is fine. 8. In the assumptions section (2.2), it is mentioned that "an algorithm is valid if it is contained in the current policy and the time of interest is within the validity period". This assumption is incorrect. The data structure should be usable to tell "until when" a given algorithm was or will be usable, instead of simply telling "valid". When estimating the cryptographic resistance of an algorithm with this data structure, the output should not simply be "valid" or "invalid", but "valid until XXXX". 9. Section 3.12 is about the validity element. The last sentence of the paragraph defines a processing rule which is the following: "If the end of the validity period is in the past, the algorithm is not suitable". This sentence should be replaced with: "If the end of the validity period is in the past, the algorithm was suitable until that date". 10. Section 5 is about "Processing". The text states: “In the following, a process is described that can be used to determine if an algorithm was valid at a particular point of time”. “Valid” is not the right word. The algorithm was resistant against estimated attacks at a particular point of time”. Replace with: “In the following, a process is described that can be used to determine if one algorithm was resistant against real or estimated attacks at a particular point of time”. 11. Section 5.3 states: "To determine if an algorithm is valid ...". This sentence should be changed into: "To determine the validity period of an algorithm...". Similar changes need to be made in the text that follows. 12. Section 5.5 mentions that if the algorithm is not valid, an error is returned. It would be more adequate to return the Evaluation elements so that a decision can be made, which is dependent both upon the context of use and the data structure where the algorithm is being used. Both sentences from this section should be replaced by. " If the algorithm is in the table, the Evaluation elements are returned. Otherwise an error "algorithm unknown" is returned". 13. Section 6. This section should be expanded to warn the user that the processing rules described in section 5 are about *one* algorithm at a time *independently of the use case*. Depending upon the use case, if an algorithm is no more resistant at the time of evaluation, this may be no problem at all. Let us take an example: an RSA signer's key of 900 bits is being used. If an evaluation is made in year 2015, this key size will probably be broken. Is the algorithm unsuitable in 2015? This fully depends upon the use case and upon the elements of the data structure that are evaluated. Example: if the signature was time-stamped with an RSA signature key of 2048 bits, before an RSA key size of 900 bits was broken, then the data structure is fine. If it was not, the *data structure* is no more resistant at the time of evaluation. Another example is the use of a MD5 hash function. If this hash function is being used in a data structure, but the data has been rehashed with SHA-256 before MD5 was "broken", then the data structure is fine. 14. Section 8. The informative reference [ETSI-TS101903] is obsolete. The last version is: ETSI TS 101 903 V1.3.2 (2006-03). 15. Section 8. The informative reference [ETSI-TS102176-1-2005] is obsolete. The last version is: ETSI TS 102 176-1 V2.0.0 (2007-11). 16. Appendix A.1. It should be indicated that this appendix is informative. 17. Appendix A.1 is a specific use case. If a hash function in the inner timestamp is no more resistant, does it means that the whole structure is invalid ? If yes, does ERS provides a way to protect against this threat ? More explanations should be provided. 18. Appendix A.2. It should be indicated that this appendix is normative. 19. Appendix B. It should be indicated that this appendix is normative. 20. Appendix C. It should be indicated that this appendix is informative. 21. Appendix D. It should be indicated that this appendix is normative. Denis ----- Message reçu ----- De : owner-ietf-ltans À : ietf-ltans Date : 2008-10-08, 14:15:59 Sujet : RE: I-D Action:draft-ietf-ltans-dssc-04.txt This draft is the result of some offlist comments submitted during WG last call for the -03 draft. Last call for this version will start today and end on October 24th. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 08, 2008 3:45 AM To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-04.txt Pages : 41 Date : 2008-10-08 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 these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities 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-04.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. ------=_NextPart_08102108510267074778150_002 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="ISO-8859-1"

Comments on draft-ietf-ltans-dssc-04

 

1. The title of the document is: “Data Structure for Security Suitabilities of Cryptographic

Algorithms”.

 

The document states that the data structure is independent of the intended use (page 8);

therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. Note that

“Suitabilities” should always be used with the singular: Suitability.

 

Replace with: “Data Structure to Estimate the Validity Period of Cryptographic Algorithms”.

 

 

2. The acronym DSSC should be changed into: DSEC (Data Structure to Estimate

Cryptographic algorithms).

 

 

3. The start of the abstract is only related to digitally signed data. However, the fourth use

case is about re-encryption, but such a use case is not mentioned in the abstract. The abstract

should be extended to mention encryption.

 

 

4. This draft defines a data structure which estimates the validity period of cryptographic

algorithms independently of the intended use. The text states in the abstract: “This document

specifies a data structure that enables automated analysis of the security suitabilities of

cryptographic algorithms”.

 

This sentence should be corrected. The document states that the data structure is independent

of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any

intended purpose. See the comment on the security considerations section for further

explanations.

 

Proposed replacement:

 

“This document specifies a data structure that enables an automated estimation of the validity

period of a single cryptographic algorithm at a time. The automated processing of a

cryptographic data structure that includes one or more cryptographic algorithms needs to be

tailored to a specific use case and is outside the scope of this document”.

 

 

5. On page 5, the term "security suitability policy" is being used. The data structure is a set of

rules which allows to estimate the validity period of various cryptographic algorithms. The

wording "security suitability policy" should not be used, because the word “suitable” implies

that the algorithm would be suitable in a specific context and there is no such context.

 

Replace the term "security suitability policy” by “cryptographic resistance policy”.

 

The word “suitable” should be replaced in many instances in this document.

 

 

6. In the requirements section (2.1), it is mentioned that the integrity and authenticity of a

published "data structure" must be assured. Since the previous requirement is source

authentication, this requirement should not be mandatory. In fact, the document considers the

signature of the data structure as an option, which is fine.

 

 

7. In the requirements section (2.1), a requirement is missing: the date of issue of the data

structure shall be indicated. In fact, the document considers the date of issue as mandatory,

which is fine.

 

 

8. In the assumptions section (2.2), it is mentioned that "an algorithm is valid if it is contained

in the current policy and the time of interest is within the validity period". This assumption is

incorrect. The data structure should be usable to tell "until when" a given algorithm was or

will be usable, instead of simply telling "valid".

 

When estimating the cryptographic resistance of an algorithm with this data structure, the

output should not simply be "valid" or "invalid", but "valid until XXXX".

 

 

9. Section 3.12 is about the validity element. The last sentence of the paragraph defines a

processing rule which is the following:

 

"If the end of the validity period is in the past, the algorithm is not suitable".

 

This sentence should be replaced with:

 

"If the end of the validity period is in the past, the algorithm was suitable until that date".

 

 

10. Section 5 is about "Processing".

 

The text states: “In the following, a process is described that can be used to determine if an

algorithm was valid at a particular point of time”.

 

“Valid” is not the right word. The algorithm was resistant against estimated attacks at a

particular point of time”.

 

Replace with: “In the following, a process is described that can be used to determine if one

algorithm was resistant against real or estimated attacks at a particular point of time”.

 

 

11. Section 5.3 states: "To determine if an algorithm is valid ...". This sentence should be

changed into: "To determine the validity period of an algorithm...". Similar changes need to

be made in the text that follows.

 

 

12. Section 5.5 mentions that if the algorithm is not valid, an error is returned. It would be

more adequate to return the Evaluation elements so that a decision can be made, which is

dependent both upon the context of use and the data structure where the algorithm is being

used.

 

Both sentences from this section should be replaced by.

" If the algorithm is in the table, the Evaluation elements are returned.

Otherwise an error "algorithm unknown" is returned".

 

 

13. Section 6. This section should be expanded to warn the user that the processing rules

described in section 5 are about *one* algorithm at a time *independently of the use case*.

Depending upon the use case, if an algorithm is no more resistant at the time of evaluation,

this may be no problem at all.

 

Let us take an example: an RSA signer's key of 900 bits is being used. If an evaluation is

made in year 2015, this key size will probably be broken. Is the algorithm unsuitable in 2015?

This fully depends upon the use case and upon the elements of the data structure that are

evaluated. Example: if the signature was time-stamped with an RSA signature key of 2048

bits, before an RSA key size of 900 bits was broken, then the data structure is fine. If it was

not, the *data structure* is no more resistant at the time of evaluation.

 

Another example is the use of a MD5 hash function. If this hash function is being used in a

data structure, but the data has been rehashed with SHA-256 before MD5 was "broken", then

the data structure is fine.

 

 

14. Section 8. The informative reference [ETSI-TS101903] is obsolete. The last version is:

ETSI TS 101 903 V1.3.2 (2006-03).

 

 

15. Section 8. The informative reference [ETSI-TS102176-1-2005] is obsolete. The last

version is: ETSI TS 102 176-1 V2.0.0 (2007-11).

 

 

16. Appendix A.1. It should be indicated that this appendix is informative.

 

 

17. Appendix A.1 is a specific use case. If a hash function in the inner timestamp is no more

resistant, does it means that the whole structure is invalid ? If yes, does ERS provides a way

to protect against this threat ? More explanations should be provided.

 

 

18. Appendix A.2. It should be indicated that this appendix is normative.

 

 

19. Appendix B. It should be indicated that this appendix is normative.

 

 

20. Appendix C. It should be indicated that this appendix is informative.

 

 

21. Appendix D. It should be indicated that this appendix is normative.

 

Denis
 
----- Message reçu -----
Date : 2008-10-08, 14:15:59
Sujet : RE: I-D Action:draft-ietf-ltans-dssc-04.txt

This draft is the result of some offlist comments submitted during WG
last call for the -03 draft. Last call for this version will start
today and end on October 24th.

-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Wednesday, October 08, 2008 3:45 AM
To: i-d-announce@ietf.org
Cc: ietf-ltans@imc.org
Subject: I-D Action:draft-ietf-ltans-dssc-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Long-Term Archive and Notary Services
Working Group of the IETF.


  Title : Data Structure for Security Suitabilities of
Cryptographic Algorithms (DSSC)
  Author(s) : T. Kunz, et al.
  Filename : draft-ietf-ltans-dssc-04.txt
  Pages : 41
  Date : 2008-10-08

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 these security
suitabilities. When signing or verifying data, these evaluations must
be considered. This document specifies a data structure that enables
automated analysis of the security suitabilities 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-04.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.


------=_NextPart_08102108510267074778150_002-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m98CGGlu000170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2008 05:16:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m98CGGUl000169; Wed, 8 Oct 2008 05:16:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m98CG5Lr000139 for ; Wed, 8 Oct 2008 05:16:16 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 12106 invoked from network); 8 Oct 2008 12:02:49 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;08 Oct 2008 12:02:49 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 8 Oct 2008 12:02:49 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: I-D Action:draft-ietf-ltans-dssc-04.txt Date: Wed, 8 Oct 2008 08:15:59 -0400 Message-ID: In-Reply-To: <20081008074501.DB6BF3A6851@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-ltans-dssc-04.txt Thread-Index: AckpGlkqudo98IjLQNeSnQdv3AyeKQAJPS0g References: <20081008074501.DB6BF3A6851@core3.amsl.com> From: "Carl Wallace" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This draft is the result of some offlist comments submitted during WG last call for the -03 draft. Last call for this version will start today and end on October 24th. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, October 08, 2008 3:45 AM To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-04.txt Pages : 41 Date : 2008-10-08 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 these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities 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-04.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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m987jh7H067703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2008 00:45:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m987jhnu067702; Wed, 8 Oct 2008 00:45:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m987jh09067695 for ; Wed, 8 Oct 2008 00:45:43 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id DB6BF3A6851; Wed, 8 Oct 2008 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081008074501.DB6BF3A6851@core3.amsl.com> Date: Wed, 8 Oct 2008 00:45:01 -0700 (PDT) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-04.txt Pages : 41 Date : 2008-10-08 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 these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitabilities 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-04.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-ltans-dssc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-08003503.I-D@ietf.org> --NextPart--