From owner-ietf-ltans@mail.imc.org Sun Nov 2 10:22:39 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 036CA3A68B4 for ; Sun, 2 Nov 2008 10:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.344 X-Spam-Level: X-Spam-Status: No, score=-104.344 tagged_above=-999 required=5 tests=[AWL=2.255, 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 NfmdZ8Ac7de4 for ; Sun, 2 Nov 2008 10:22:38 -0800 (PST) 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 A4FDF3A67F7 for ; Sun, 2 Nov 2008 10:22:37 -0800 (PST) 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 mA2IF0Mh056225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2008 11:15:00 -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 mA2IF06d056224; Sun, 2 Nov 2008 11:15:00 -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 mA2IF02r056218 for ; Sun, 2 Nov 2008 11:15:00 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 457BC3A67D0; Sun, 2 Nov 2008 10:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-ltap-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081102181501.457BC3A67D0@core3.amsl.com> Date: Sun, 2 Nov 2008 10:15:01 -0800 (PST) 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 : Long-term Archive Protocol (LTAP) Author(s) : A. Jerman-Blazic, et al. Filename : draft-ietf-ltans-ltap-07.txt Pages : 64 Date : 2008-11-02 This document describes a service operated as a trusted third party to securely archive electronic documents called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ltap-07.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-ltap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-02100556.I-D@ietf.org> --NextPart-- From owner-ietf-ltans@mail.imc.org Mon Nov 3 08:00:00 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 055163A6B0B for ; Mon, 3 Nov 2008 08:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.072 X-Spam-Level: X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 6Wvhm7JX57Yn for ; Mon, 3 Nov 2008 07:59:59 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 38F6B3A6943 for ; Mon, 3 Nov 2008 07:59:59 -0800 (PST) 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 mA3Fj0ga053060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 08:45:00 -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 mA3Fj0Po053057; Mon, 3 Nov 2008 08:45:00 -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 mA3Fj0vt053037 for ; Mon, 3 Nov 2008 08:45:00 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 6B3173A69E9; Mon, 3 Nov 2008 07:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103154501.6B3173A69E9@core3.amsl.com> Date: Mon, 3 Nov 2008 07:45:01 -0800 (PST) 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 the Security Suitability of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-05.txt Pages : 41 Date : 2008-11-03 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability of cryptographic algorithms.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ltans-dssc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03073935.I-D@ietf.org> --NextPart-- From owner-ietf-ltans@mail.imc.org Wed Nov 12 00:22:15 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 AD9933A682B for ; Wed, 12 Nov 2008 00:22:15 -0800 (PST) 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 GIHsY0K0Xnfe for ; Wed, 12 Nov 2008 00:22:13 -0800 (PST) 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 D6C8B3A681D for ; Wed, 12 Nov 2008 00:22:08 -0800 (PST) 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 mAC8EZXm033785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 01:14: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 mAC8EZuJ033784; Wed, 12 Nov 2008 01:14: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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAC8ENoU033773 for ; Wed, 12 Nov 2008 01:14:34 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (Bull S.A.) with ESMTP id 1DB92789A for ; Wed, 12 Nov 2008 09:08:32 +0100 (CET) Received: from FRMYA-SIA24 ([129.182.109.121]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008111209142057:263144 ; Wed, 12 Nov 2008 09:14:20 +0100 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "IETF LTANS" Subject: Re: I-D Action:draft-ietf-ltans-dssc-05.txt Date: Wed, 12 Nov 2008 09:14:20 +0100 Message-Id: References: <20081103154501.6B3173A69E9@core3.amsl.com> 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 12/11/2008 09:14:20, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 12/11/2008 09:14:21, Serialize complete at 12/11/2008 09:14:21 Content-Type: multipart/alternative; boundary="----=_NextPart_08111209141887344650666_002" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_NextPart_08111209141887344650666_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ltans-dssc-05 =20 1. The abstract is only related to digitally signed data. The abstract sh= ould be extended to mention encryption.=20 It should also mention that the use of a weak cryptographic algorithm wit= hin a complex data structure=20 can be protected using a strong cryptographic algorithm which then may re= nder the whole data structure=20 adequate for its intended use. =20 The current abstract is the following: =20 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability=20 of cryptographic algorithms. =20 Proposed change for the whole abstract to solve these two comments: =20 Because cryptographic algorithms can become weak over the years,=20 it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting=20 data, these evaluations must be considered. This document specifies=20 a data structure that enables an automated analysis of the security=20 suitability of a given cryptographic algorithm at a given point of=20 time which may be in the past, at the present time or in the future. =20 The automated processing of a cryptographic data structure that=20 uses several cryptographic algorithms cannot be performed only using=20 the previous automated analysis, since in some cases a weak=20 cryptographic algorithm can be protected by a strong cryptographic=20 algorithm which may make the whole data structure adequate for its=20 intended use. =20 =20 2. Section 1.1. The text sates: =20 If algorithms lack the required properties, signatures could be forged= . =20 This sentence should be changed into: =20 If algorithms lack the required properties, signatures could be=20 forged, unless they are protected by a strong cryptographic=20 algorithm, e.g. a time-stamp token that uses a strong cryptographic=20 algorithm. =20 =20 3. Section 1.1. The text sates: =20 Very few algorithms satisfy the security requirements and are=20 suitable for usage in signatures. =20 This is not fully correct. =20 This sentence should be changed into: =20 Cryptographic algorithms that are used in signatures shall resist=20 during their period of use. For signature keys included in public key= =20 certificates, it is the validity period of the certificate. =20 Cryptographic algorithms that are used for encryption shall resist=20 during the time during which it is planned to keep the information=20 confidential.=20 =20 4. Section 1.1. The text sates: =20 A digital signature using a "weak" algorithm has no probative value. =20 This is not fully correct. =20 This sentence should be changed into: =20 A digital signature using a "weak" algorithm has no probative value,=20 unless the "weak" algorithm has been protected by a strong algorithm=20 before the time it was considered to be weak. =20 =20 5. Section 1.1. The text sates: =20 For this reason, it is important to periodically evaluate an algorithm's fitness and to consider the results of these evaluations when creating, verifying or renewing signatures. =20 This is not fully correct. A signature made by a human being that is dead= cannot be "renewed". =20 This sentence should be changed into: =20 For this reason, it is important to periodically evaluate an algorithm's fitness and to consider the results of these evaluations when creating and verifying signatures, or when maintaining the=20 validity of signatures made in the past. =20 6. Section 1.1. The text sates: =20 This prediction can help to detect whether an insecure algorithm=20 is used in a signature or whether a signature has been properly=20 preserved. =20 This is not fully correct. =20 This sentence should be changed into: =20 This prediction can help to detect whether a weak algorithm=20 is used in a signature and whether that signature has been properly=20 protected in due time by an another signature made using an algorithm=20 that is suitable at the present point of time. =20 =20 7. Definition of flexibility: =20 The text states: =20 Additionally the data structure must be designed independent of the=20 intended use, e.g., encryption, signing, verifying, and signature=20 renewing. Thus, the interpretion of the data structure is same for=20 every use case. Firstly there is typo on the word: interpretion =20 Secondly, the document does not define what is a signature algorithm.=20 There are three possible answers to that question, that may be illustrate= d=20 with the RSA algorithm: =20 1) it is only the RSA algorithm, 2) it is the RSA algorithm with a padding function, 3) it is the RSA algorithm with a padding function and a hash function= . =20 The text should clarify which case(s) are supported. If cases 2) or 3) ar= e supported,=20 then the above text is incorrect. =20 =20 8. Section 2.2.: =20 The text states: =20 An algorithm is suitable if it is contained in the current policy and the time of interest is within the validity period. =20 This sentence should be changed into: =20 An algorithm is suitable *at a time of interest* if it is contained=20 in the current policy and the time of interest is within the validity=20 period. =20 =20 9. Section 5.5. This section should first add another kind of output. Ple= ase add the following text: =20 If the algorithm is not in the policy, an error "algorithm unknown" is= =20 returned. =20 =20 10. Section 5.5. =20 The text states: =20 If the algorithm is not suitable relative to the time of interest,=20 return an error. =20 Change into: =20 If the algorithm is not suitable relative to the time of interest,=20 an error "algorithm unsuitable" is returned. =20 =20 11. Section 5.5. =20 The text states: =20 If the algorithm is suitable, return the Evaluation elements that were not discarded. =20 Change into: =20 If the algorithm is suitable, return the Evaluation elements that were not discarded, *in particular its validity period*. =20 =20 12. Section 6. Security Considerations=20 =20 In the comments made on draft-04, it has been requested to add text to wa= rn the user that=20 the processing rule described in section 5 is about *one* algorithm *inde= pendently of the use case*.=20 Depending upon the use case, an algorithm is no more suitable at the time= of evaluation, may be=20 no problem at all. =20 Proposed text: =20 The processing rule described in section 5 is about one cryptographic=20 algorithm independently of the use case. Depending upon the use case,= =20 an algorithm that is no more suitable at the time of interest, does no= t=20 necessarily mean that the data structure where it is used is no more=20 secure. =20 For example, an RSA signer's key of 1024 bits is being used in year=20 2009. The validity period of the signature key included in a public k= ey=20 certificate is three years. The signature is time-stamped in year 200= 9=20 with a time-stamp token that uses an RSA key of 2048 bits. =20 This data structure is revaluated in year 2020. Let us suppose that in= =20 year 2015 an RSA key size of 1024 bits will be broken. The fact that=20 the signature key of 1024 bits is no more suitable in year 2015 and=20 a fortiori in year 2020 does not mean that the whole structure is no=20 more secure, if an RSA key size of 2048 bits is still suitable in=20 year 2020. =20 In addition, to the key size considerations, other considerations=20 apply, like whether the time-stamp token has been provided by a=20 trusted authority. It means that the simple use of a suitability=20 policy is not the single element to consider when evaluating the=20 security of a complex data structure using several cryptographic=20 algorithms. =20 13. Section 6. Security Considerations . This section should include text= to cover the case of encryption. =20 Proposed text: =20 Re-encrypting documents that were originally encrypted using an=20 algorithm that is no more suitable, will not protect the semantics=20 of the document, if the document has been intercepted. However,=20 for documents stored in an encrypted form, re-encryption must be=20 considered, unless the document has lost its original value due to=20 time erosion. =20 =20 14. Appendix A.1. It should be indicated *in the title* that this appendi= x is informative. Denis ----- Message re=E7u -----=20 De : owner-ietf-ltans=20 =C0 : i-d-announce=20 Date : 2008-11-03, 16:45:01 Sujet : I-D Action:draft-ietf-ltans-dssc-05.txt Pi=E8ce(s) Jointe(s) au message original : (1). draft-ietf-ltans-dssc-05.txt Title : Data Structure for the Security Suitability of Cryptographic Al= gorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-05.txt Pages : 41 Date : 2008-11-03 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability of cryptographic algorithms.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_08111209141887344650666_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Comments on draft-ietf-ltans-dssc-05

 

1.=20 The abstract is only related to digitally signed data. The abstract shoul= d be=20 extended to mention encryption.

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

 

The=20 current abstract is the following:

 

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

=    and integrity of digital signed=20 data.  This proof depends o= n=20 the

=    security=20 suitability of the cryptographic algorithms used to=20 generate

=    or verify=20 the digital signature.  Bec= ause=20 algorithms can become weak

=    over the=20 years, it is necessary to periodically evaluate=20 their

=    security=20 suitability.  When signing = or=20 verifying data, these

=   =20 evaluations must be considered.&= nbsp;=20 This document specifies a data

=    structure=20 that enables automated analysis of the security suitability=20

=    of=20 cryptographic algorithms.

=  

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

 

=    Because=20 cryptographic algorithms can become weak over the years,=20

=    it is=20 necessary to evaluate their security suitability.

=    When=20 signing or verifying data, or when encrypting or decrypting=20

=    data,=20 these evaluations must be considered.&n= bsp;=20 This document specifies

=    a data=20 structure that enables an automated analysis of the security=20

=   =20 suitability of a given cryptographic algorithm at a given point of= =20

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

=  

=    The automated processing of a cryptographi= c data=20 structure that

   uses several cryptographi= c=20 algorithms cannot be performed only using

   the previous = automated=20 analysis, since in some cases a weak

=    cryptographic algorithm = can be=20 protected by a strong cryptographic

   algorithm which may make = the whole=20 data structure adequate for its

   intended use= .=

 

 

2. Section 1.1. The text=20 sates:

 

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

 

This=20 sentence should be changed into:

 

=    If=20 algorithms lack the required properties, signatures could be=20

=    forged, unless they are p= rotected=20 by a strong cryptographic

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

   = algorithm.

 

 

3. Section 1.1. The text=20 sates:

 

=    Very few=20 algorithms satisfy the security requirements and are=20

=    suitable for usage in=20 signatures.

 

This=20 is not fully correct.

 

This=20 sentence should be changed into:

 

   Cryptographic algorithms = that are=20 used in signatures shall resist

   during their period of us= e.  For signature keys included in = public=20 key

   certificates, it is the v= alidity=20 period of the certificate.

 

   Cryptographic algorithms = that are=20 used for encryption shall resist

   during the time during wh= ich it is=20 planned to keep the information

   confidential.=20

 

4. Section 1.1. The text=20 sates:

 

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

 

This=20 is not fully correct.

 

This=20 sentence should be changed into:

 

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

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

=    before=20 the time it was considered to be weak.

 

 

5. Section 1.1. The text=20 sates:

 

=    For this reason, it is important= to=20 periodically evaluate an

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

=    when creating, verifying = or=20 renewing signatures.

 

This=20 is not fully correct. A signature made by a human being that is dead cann= ot be=20 "renewed".

 

This=20 sentence should be changed into:

 

=    For this=20 reason, it is important to periodically evaluate an

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

=    when=20 creating and verifying signatures, or when maintaining the=20

=    validity of signatures ma= de in the=20 past.

 

6. Section 1.1. The text=20 sates:

 

=    This=20 prediction can help to detect whether an insecure algorithm=20

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

=    preserved.

 

This=20 is not fully correct.

 

This=20 sentence should be changed into:

 

=    This=20 prediction can help to detect whether a weak algorithm=20

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

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

=    that is suitable at the p= resent=20 point of time.

 

 

7.=20 Definition of flexibility:

 

The=20 text states:

 

=   =20 Additionally the data structure must be designed independent of th= e=20

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

=   =20 renewing.  Thus, the= =20 interpretion of the data structure is same for <= /P>

=    every use=20 case.

Firstly=20 there is typo on the word: = interpretion

 

Secondly, the document does not define what is a si= gnature=20 algorithm.

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

 

   1) it is only the RSA=20 algorithm,

   2) it is the RSA algorith= m with a=20 padding function,

   3) it is the RSA algorith= m with a=20 padding function and a hash function.

 

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

 

 

8.=20 Section 2.2.:

 

The=20 text states:

 

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

=    the time of interest is w= ithin the=20 validity period.

 

This=20 sentence should be changed into:

 

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

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

=    period.

 

 

9. Section 5.5. This section should firs= t add=20 another kind of output. Please add the following=20 text:

 

   If the algorithm is not i= n the=20 policy, an error "algorithm unknown" is

   returned.

 

 

10. Section=20 5.5.

 

The=20 text states:

 

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

=    return an=20 error.

 

Change into:

 

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

   an error "algorithm unsui= table" is=20 returned.=

 

 

11. Section=20 5.5.

 

The=20 text states:

 

=    If the=20 algorithm is suitable, return the Evaluation elements=20 that

=    were not=20 discarded.

 

Change into:

 

=    If the=20 algorithm is suitable, return the Evaluation elements=20 that

=    were not=20 discarded, *in particular its validity period*.<= /P>

 

 

12. Section 6. = Security=20 Considerations 

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

 

Proposed text:

 

   The processing rule descr= ibed in=20 section 5 is about one = cryptographic=20

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

   an algorithm that is no m= ore=20 suitable at the time of interest, does not

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

   secure.=

 

   For example, an RSA signe= r's key=20 of 1024 bits is being used in year

   2009.  The validity period of the sign= ature key=20 included in a public key

   certificate is three year= s.  The signature is time-stamped i= n year=20 2009

   with a time-stamp token t= hat uses=20 an RSA key of 2048 bits.

 

   This data structure is re= valuated=20 in year 2020. Let us suppose that in

   year 2015 an RSA key size= of 1024=20 bits will be broken.  The f= act that=20

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

   a fortiori in year 2020 d= oes not=20 mean that the whole structure is no

   more secure, if an RSA ke= y size of=20 2048 bits is still suitable in

   year 2020.

 

   In addition, to the key s= ize=20 considerations, other considerations

   apply, like whether the t= ime-stamp=20 token has been provided by a

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

   policy is not the single = element=20 to consider when evaluating the

   security of a complex dat= a=20 structure using several cryptographic

   algorithms.

 

13. Section 6. = Security=20 Considerations 

Proposed text:

 

=  =   Re-encrypting documents that we= re=20 originally encrypted using an

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

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

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

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

=    time=20 erosion.

 

 

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

 

Denis<= /P>

-----=20 Message re=E7u ----- De=20 : owner-ietf-ltan= s=20 =C0=20 : i-d-announce Date=20 : 2008-11-03, 16:45:01 Sujet=20 : I-D Action:draft-ietf-ltans-dssc-05.txt

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

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

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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", = "SHALL=20 NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" i= n=20 this
document are to be interpreted as described in [RFC2119].
A URL=20 for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt
Internet-Drafts=20 are also available by anonymous FTP=20 at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_08111209141887344650666_002-- From owner-ietf-ltans@mail.imc.org Tue Nov 18 00:46:07 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 44A9F3A6AC5 for ; Tue, 18 Nov 2008 00:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6] 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 LsfcemBzwyri for ; Tue, 18 Nov 2008 00:46:06 -0800 (PST) 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 1C68C3A6AAE for ; Tue, 18 Nov 2008 00:46:05 -0800 (PST) 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 mAI8YVwf030132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 01:34:31 -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 mAI8YViJ030131; Tue, 18 Nov 2008 01:34:31 -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 rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.247]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI8YKXg030122 for ; Tue, 18 Nov 2008 01:34:30 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by rv-out-0708.google.com with SMTP id c5so2771941rvf.34 for ; Tue, 18 Nov 2008 00:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=eaJDE4otgg/ZDY7n9EMg1VFNhTiB6jpKxHgPQnninHs=; b=cCCbT142CDRUFO5eHRl1LTVTiOoWldMagT2xndq8PL2vt1yHZOrCfi9pgDh7zteQfh VmC5gbL1SEdo8MYOwMQxgacotD1WrCqMSFG7SQgWBiu4zE8adQ3W9IiBjmV7s2Sq1iEF diSaOQM6THw8vhn89R1mP7vH7moKd2LNte2zY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=RTz1+9BXay/GMyw16jyDHKvxU/VhUc0pgbGPDSuWcGYIDoqYJRStk8Wk8P5VxiMBhL 6i4of1trXWrdZ7b+bAqNMLjlrWleTkif4PbfDoNwhEsi5RysNSIYtvAblhbyWwL/U8l4 hsRahX/6NqR7gUc/p7i2QSl50ZYLd14RpFe7w= Received: by 10.142.165.14 with SMTP id n14mr2473329wfe.24.1226997259637; Tue, 18 Nov 2008 00:34:19 -0800 (PST) Received: by 10.142.229.18 with HTTP; Tue, 18 Nov 2008 00:34:19 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2008 09:34:19 +0100 From: "Jesus Maria Mendez Perez" To: ietf-ltans@imc.org Subject: XSD Schema considerations MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_93635_20618816.1226997259621" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_93635_20618816.1226997259621 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I have checked lastest versions of LTANS drafts, and i have some questions about xsd=B4s schemas. In xmlers.xsd, inside EvidenceRecord element we can add this new elements t= o save up certificates and information of revocation. ----- defined in xmldisg-core-schema.xsd ----- defined in XAdES.xsd and change the complextype TimeStamp by this which is defined in oasis-dss-core-schema-v1.0-os.xsd: I want to know your opinion about these changes. Thanks. ------=_Part_93635_20618816.1226997259621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello,

I have checked lastest versions of LTANS drafts, and i have s= ome questions about xsd=B4s schemas.

In xmlers.xsd, inside EvidenceR= ecord element we can add this new elements to save up certificates and info= rmation of revocation.

<xsd:element name=3D"KeyInfo" type=3D"ds:KeyInfoType&= quot;/>  ----- defined in xmldisg-core-schema.xsd
<xsd:elemen= t name=3D"CompleteRevocationRefs" type=3D"xa:CompleteRevocat= ionRefsType"/> ----- defined in XAdES.xsd
   
and change the complextype TimeStamp

<xsd:= complexType name=3D"TimeStamp">
     &n= bsp; <xsd:sequence>
         &n= bsp;  <xsd:any namespace=3D"##other" minOccurs=3D"0&= quot; maxOccurs=3D"unbounded"/>  
       </xsd:sequence>
   </= xsd:complexType>

by this which is defined in oasis-dss-core-schem= a-v1.0-os.xsd:

<xsd:complexType name=3D"TimeStampType"&= gt;
        <xsd:choice>
            <xsd:element re= f=3D"ds:Signature"/>
        =     <xsd:element name=3D"RFC3161TimeStampToken"= type=3D"xsd:base64Binary"/>
      = ;      <xsd:element name=3D"Other" type=3D= "tn:AnyType"/>
        </xsd:choice>
</xsd:compl= exType>
   
<xsd:complexType name=3D"AnyTy= pe">
        <xsd:sequence><= br>            <xsd:any pro= cessContents=3D"lax" minOccurs=3D"0" maxOccurs=3D"= unbounded"/>
        </xsd:sequence>
</xsd:com= plexType>

I want to know your opinion about these changes.
Thanks.





------=_Part_93635_20618816.1226997259621-- From owner-ietf-ltans@mail.imc.org Tue Nov 18 08:08:46 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 AD13928C101 for ; Tue, 18 Nov 2008 08:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_63=0.6] 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 fDR5N9MaXlWl for ; Tue, 18 Nov 2008 08:08:45 -0800 (PST) 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 C63EF3A6851 for ; Tue, 18 Nov 2008 08:08:44 -0800 (PST) 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 mAIG0jFc057894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:00:45 -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 mAIG0jRh057893; Tue, 18 Nov 2008 09:00:45 -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-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIG0XFn057884 for ; Tue, 18 Nov 2008 09:00:44 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ppGJwBgFMmaNRKZmFFOGU3aCRhZvoRqR6U9MqjJfy05ChREf5kkZXQEHzEWl1uej; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=[192.168.0.32]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2T0D-0007qr-M7; Tue, 18 Nov 2008 11:00:33 -0500 Message-ID: <4922E6AB.9010201@earthlink.net> Date: Tue, 18 Nov 2008 08:00:43 -0800 From: TSG User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jesus Maria Mendez Perez CC: ietf-ltans@imc.org Subject: Re: XSD Schema considerations References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070708030506010501000300" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79052e0ccc85a7a4f59afba669dfd21613350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------070708030506010501000300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Jesus Maria Mendez Perez wrote: > Hello, > > I have checked lastest versions of LTANS drafts, and i have some > questions about xsd´s schemas. > > In xmlers.xsd, inside EvidenceRecord element we can add this new > elements to save up certificates and information of revocation. > > ----- defined in > xmldisg-core-schema.xsd > type="xa:CompleteRevocationRefsType"/> ----- defined in XAdES.xsd > > and change the complextype TimeStamp > > > > maxOccurs="unbounded"/> > > > > by this which is defined in oasis-dss-core-schema-v1.0-os.xsd: > > > > > type="xsd:base64Binary"/> > > > > > > > maxOccurs="unbounded"/> > > > > I want to know your opinion about these changes. What are the specific use models intended? It will make a difference. There is no one-size-fits-all type of evidence container yet, so the use models are specific to the evidence structures. Also any use model must be brought into alignment with the US Federal Rules of Evidence's five-point test for determining the strength and admissibility of the data contained therein, otherwise this is just another IETF game which will not produce a legally defensible data model IMHO. > > Thanks. > > > > > > ------------------------------------------------------------------------ > > > Internal Virus Database is out of date. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM > > --------------070708030506010501000300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jesus Maria Mendez Perez wrote:
Hello,

I have checked lastest versions of LTANS drafts, and i have some questions about xsd´s schemas.

In xmlers.xsd, inside EvidenceRecord element we can add this new elements to save up certificates and information of revocation.

<xsd:element name="KeyInfo" type="ds:KeyInfoType"/>  ----- defined in xmldisg-core-schema.xsd
<xsd:element name="CompleteRevocationRefs" type="xa:CompleteRevocationRefsType"/> ----- defined in XAdES.xsd
   
and change the complextype TimeStamp

<xsd:complexType name="TimeStamp">
       <xsd:sequence>
            <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>  
       </xsd:sequence>
   </xsd:complexType>

by this which is defined in oasis-dss-core-schema-v1.0-os.xsd:

<xsd:complexType name="TimeStampType">
        <xsd:choice>
            <xsd:element ref="ds:Signature"/>
            <xsd:element name="RFC3161TimeStampToken" type="xsd:base64Binary"/>
            <xsd:element name="Other" type="tn:AnyType"/>
        </xsd:choice>
</xsd:complexType>
   
<xsd:complexType name="AnyType">
        <xsd:sequence>
            <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
</xsd:complexType>

I want to know your opinion about these changes.

What are the specific use models intended? It will make a difference. There is no one-size-fits-all type of evidence container yet, so the use models are specific to the evidence structures.

Also any use model must be brought into alignment with the US Federal Rules of Evidence's five-point test for determining the strength and admissibility of the data contained therein, otherwise this is just another IETF game which will not produce a legally defensible data model IMHO.

Thanks.







Internal Virus Database is out of date.
Checked by AVG - http://www.avg.com 
Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM

--------------070708030506010501000300-- From owner-ietf-ltans@mail.imc.org Mon Nov 24 05:26:51 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 A34753A694D for ; Mon, 24 Nov 2008 05:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 vf4AYoRzWxUj for ; Mon, 24 Nov 2008 05:26:50 -0800 (PST) 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 6C2293A6940 for ; Mon, 24 Nov 2008 05:26:49 -0800 (PST) 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 mAODIP1X033372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 06:18:25 -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 mAODIPOa033371; Mon, 24 Nov 2008 06:18:25 -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.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAODIC1f033352 for ; Mon, 24 Nov 2008 06:18:23 -0700 (MST) (envelope-from susanneo@gmx.de) Received: (qmail invoked by alias); 24 Nov 2008 13:18:08 -0000 Received: from drms-4d00690f.pool.mediaWays.net (EHLO Macintosh.local) [77.0.105.15] by mail.gmx.net (mp015) with SMTP; 24 Nov 2008 14:18:08 +0100 X-Authenticated: #1167296 X-Provags-ID: V01U2FsdGVkX18D8kVDr8oDgnBEqqB7EzrKiVGoov4F6p04nnm0Ie H+azLijFCM0Ib0 Message-ID: <492AA98B.50806@gmx.de> Date: Mon, 24 Nov 2008 14:18:03 +0100 From: Susanne Okunick User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: denis.pinkas@bull.net CC: ietf-ltans@imc.org Subject: Re: I-D Action:draft-ietf-ltans-dssc-05.txt References: <20081103154501.6B3173A69E9@core3.amsl.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis,
 
We agree with most of your comments and will try to consider them in our next version. More comments inline...

7. Definition of flexibility:

 

The text states:

 

   Additionally the data structure must be designed independent of the

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

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

   every use case.

Firstly there is typo on the word: interpretion

ok.

 

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

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

 

   1) it is only the RSA algorithm,

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

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

 

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

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

We try to give a better definition of algorithm.

 

12. Section 6. Security Considerations

 

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

 

Proposed text:

 

   The processing rule described in section 5 is about one cryptographic

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

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

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

   secure.

 

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

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

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

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

 

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

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

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

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

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

   year 2020.

 

   In addition, to the key size considerations, other considerations

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

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

   policy is not the single element to consider when evaluating the

   security of a complex data structure using several cryptographic

   algorithms.

 

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

 

Proposed text:

 

   Re-encrypting documents that were originally encrypted using an

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

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

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

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

   time erosion.

 

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

Many thanks for your comments!
Susanne 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 mAODIP1X033372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 06:18:25 -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 mAODIPOa033371; Mon, 24 Nov 2008 06:18:25 -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.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAODIC1f033352 for ; Mon, 24 Nov 2008 06:18:23 -0700 (MST) (envelope-from susanneo@gmx.de) Received: (qmail invoked by alias); 24 Nov 2008 13:18:08 -0000 Received: from drms-4d00690f.pool.mediaWays.net (EHLO Macintosh.local) [77.0.105.15] by mail.gmx.net (mp015) with SMTP; 24 Nov 2008 14:18:08 +0100 X-Authenticated: #1167296 X-Provags-ID: V01U2FsdGVkX18D8kVDr8oDgnBEqqB7EzrKiVGoov4F6p04nnm0Ie H+azLijFCM0Ib0 Message-ID: <492AA98B.50806@gmx.de> Date: Mon, 24 Nov 2008 14:18:03 +0100 From: Susanne Okunick User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: denis.pinkas@bull.net CC: ietf-ltans@imc.org Subject: Re: I-D Action:draft-ietf-ltans-dssc-05.txt References: <20081103154501.6B3173A69E9@core3.amsl.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis,
 
We agree with most of your comments and will try to consider them in our next version. More comments inline...

7. Definition of flexibility:

 

The text states:

 

   Additionally the data structure must be designed independent of the

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

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

   every use case.

Firstly there is typo on the word: interpretion

ok.

 

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

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

 

   1) it is only the RSA algorithm,

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

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

 

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

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

We try to give a better definition of algorithm.

 

12. Section 6. Security Considerations

 

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

 

Proposed text:

 

   The processing rule described in section 5 is about one cryptographic

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

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

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

   secure.

 

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

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

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

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

 

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

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

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

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

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

   year 2020.

 

   In addition, to the key size considerations, other considerations

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

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

   policy is not the single element to consider when evaluating the

   security of a complex data structure using several cryptographic

   algorithms.

 

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

 

Proposed text:

 

   Re-encrypting documents that were originally encrypted using an

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

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

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

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

   time erosion.

 

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

Many thanks for your comments!
Susanne 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 mAIG0jFc057894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:00:45 -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 mAIG0jRh057893; Tue, 18 Nov 2008 09:00:45 -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-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIG0XFn057884 for ; Tue, 18 Nov 2008 09:00:44 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ppGJwBgFMmaNRKZmFFOGU3aCRhZvoRqR6U9MqjJfy05ChREf5kkZXQEHzEWl1uej; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=[192.168.0.32]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2T0D-0007qr-M7; Tue, 18 Nov 2008 11:00:33 -0500 Message-ID: <4922E6AB.9010201@earthlink.net> Date: Tue, 18 Nov 2008 08:00:43 -0800 From: TSG User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jesus Maria Mendez Perez CC: ietf-ltans@imc.org Subject: Re: XSD Schema considerations References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070708030506010501000300" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79052e0ccc85a7a4f59afba669dfd21613350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------070708030506010501000300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Jesus Maria Mendez Perez wrote: > Hello, > > I have checked lastest versions of LTANS drafts, and i have some > questions about xsd´s schemas. > > In xmlers.xsd, inside EvidenceRecord element we can add this new > elements to save up certificates and information of revocation. > > ----- defined in > xmldisg-core-schema.xsd > type="xa:CompleteRevocationRefsType"/> ----- defined in XAdES.xsd > > and change the complextype TimeStamp > > > > maxOccurs="unbounded"/> > > > > by this which is defined in oasis-dss-core-schema-v1.0-os.xsd: > > > > > type="xsd:base64Binary"/> > > > > > > > maxOccurs="unbounded"/> > > > > I want to know your opinion about these changes. What are the specific use models intended? It will make a difference. There is no one-size-fits-all type of evidence container yet, so the use models are specific to the evidence structures. Also any use model must be brought into alignment with the US Federal Rules of Evidence's five-point test for determining the strength and admissibility of the data contained therein, otherwise this is just another IETF game which will not produce a legally defensible data model IMHO. > > Thanks. > > > > > > ------------------------------------------------------------------------ > > > Internal Virus Database is out of date. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM > > --------------070708030506010501000300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jesus Maria Mendez Perez wrote:
Hello,

I have checked lastest versions of LTANS drafts, and i have some questions about xsd´s schemas.

In xmlers.xsd, inside EvidenceRecord element we can add this new elements to save up certificates and information of revocation.

<xsd:element name="KeyInfo" type="ds:KeyInfoType"/>  ----- defined in xmldisg-core-schema.xsd
<xsd:element name="CompleteRevocationRefs" type="xa:CompleteRevocationRefsType"/> ----- defined in XAdES.xsd
   
and change the complextype TimeStamp

<xsd:complexType name="TimeStamp">
       <xsd:sequence>
            <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>  
       </xsd:sequence>
   </xsd:complexType>

by this which is defined in oasis-dss-core-schema-v1.0-os.xsd:

<xsd:complexType name="TimeStampType">
        <xsd:choice>
            <xsd:element ref="ds:Signature"/>
            <xsd:element name="RFC3161TimeStampToken" type="xsd:base64Binary"/>
            <xsd:element name="Other" type="tn:AnyType"/>
        </xsd:choice>
</xsd:complexType>
   
<xsd:complexType name="AnyType">
        <xsd:sequence>
            <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
</xsd:complexType>

I want to know your opinion about these changes.

What are the specific use models intended? It will make a difference. There is no one-size-fits-all type of evidence container yet, so the use models are specific to the evidence structures.

Also any use model must be brought into alignment with the US Federal Rules of Evidence's five-point test for determining the strength and admissibility of the data contained therein, otherwise this is just another IETF game which will not produce a legally defensible data model IMHO.

Thanks.







Internal Virus Database is out of date.
Checked by AVG - http://www.avg.com 
Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM

--------------070708030506010501000300-- 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 mAI8YVwf030132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 01:34:31 -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 mAI8YViJ030131; Tue, 18 Nov 2008 01:34:31 -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 rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.247]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI8YKXg030122 for ; Tue, 18 Nov 2008 01:34:30 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by rv-out-0708.google.com with SMTP id c5so2771941rvf.34 for ; Tue, 18 Nov 2008 00:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=eaJDE4otgg/ZDY7n9EMg1VFNhTiB6jpKxHgPQnninHs=; b=cCCbT142CDRUFO5eHRl1LTVTiOoWldMagT2xndq8PL2vt1yHZOrCfi9pgDh7zteQfh VmC5gbL1SEdo8MYOwMQxgacotD1WrCqMSFG7SQgWBiu4zE8adQ3W9IiBjmV7s2Sq1iEF diSaOQM6THw8vhn89R1mP7vH7moKd2LNte2zY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=RTz1+9BXay/GMyw16jyDHKvxU/VhUc0pgbGPDSuWcGYIDoqYJRStk8Wk8P5VxiMBhL 6i4of1trXWrdZ7b+bAqNMLjlrWleTkif4PbfDoNwhEsi5RysNSIYtvAblhbyWwL/U8l4 hsRahX/6NqR7gUc/p7i2QSl50ZYLd14RpFe7w= Received: by 10.142.165.14 with SMTP id n14mr2473329wfe.24.1226997259637; Tue, 18 Nov 2008 00:34:19 -0800 (PST) Received: by 10.142.229.18 with HTTP; Tue, 18 Nov 2008 00:34:19 -0800 (PST) Message-ID: Date: Tue, 18 Nov 2008 09:34:19 +0100 From: "Jesus Maria Mendez Perez" To: ietf-ltans@imc.org Subject: XSD Schema considerations MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_93635_20618816.1226997259621" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_93635_20618816.1226997259621 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I have checked lastest versions of LTANS drafts, and i have some questions about xsd=B4s schemas. In xmlers.xsd, inside EvidenceRecord element we can add this new elements t= o save up certificates and information of revocation. ----- defined in xmldisg-core-schema.xsd ----- defined in XAdES.xsd and change the complextype TimeStamp by this which is defined in oasis-dss-core-schema-v1.0-os.xsd: I want to know your opinion about these changes. Thanks. ------=_Part_93635_20618816.1226997259621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello,

I have checked lastest versions of LTANS drafts, and i have s= ome questions about xsd=B4s schemas.

In xmlers.xsd, inside EvidenceR= ecord element we can add this new elements to save up certificates and info= rmation of revocation.

<xsd:element name=3D"KeyInfo" type=3D"ds:KeyInfoType&= quot;/>  ----- defined in xmldisg-core-schema.xsd
<xsd:elemen= t name=3D"CompleteRevocationRefs" type=3D"xa:CompleteRevocat= ionRefsType"/> ----- defined in XAdES.xsd
   
and change the complextype TimeStamp

<xsd:= complexType name=3D"TimeStamp">
     &n= bsp; <xsd:sequence>
         &n= bsp;  <xsd:any namespace=3D"##other" minOccurs=3D"0&= quot; maxOccurs=3D"unbounded"/>  
       </xsd:sequence>
   </= xsd:complexType>

by this which is defined in oasis-dss-core-schem= a-v1.0-os.xsd:

<xsd:complexType name=3D"TimeStampType"&= gt;
        <xsd:choice>
            <xsd:element re= f=3D"ds:Signature"/>
        =     <xsd:element name=3D"RFC3161TimeStampToken"= type=3D"xsd:base64Binary"/>
      = ;      <xsd:element name=3D"Other" type=3D= "tn:AnyType"/>
        </xsd:choice>
</xsd:compl= exType>
   
<xsd:complexType name=3D"AnyTy= pe">
        <xsd:sequence><= br>            <xsd:any pro= cessContents=3D"lax" minOccurs=3D"0" maxOccurs=3D"= unbounded"/>
        </xsd:sequence>
</xsd:com= plexType>

I want to know your opinion about these changes.
Thanks.





------=_Part_93635_20618816.1226997259621-- 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 mAC8EZXm033785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 01:14: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 mAC8EZuJ033784; Wed, 12 Nov 2008 01:14: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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAC8ENoU033773 for ; Wed, 12 Nov 2008 01:14:34 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (Bull S.A.) with ESMTP id 1DB92789A for ; Wed, 12 Nov 2008 09:08:32 +0100 (CET) Received: from FRMYA-SIA24 ([129.182.109.121]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008111209142057:263144 ; Wed, 12 Nov 2008 09:14:20 +0100 Reply-To: denis.pinkas@bull.net From: "Denis Pinkas" To: "IETF LTANS" Subject: Re: I-D Action:draft-ietf-ltans-dssc-05.txt Date: Wed, 12 Nov 2008 09:14:20 +0100 Message-Id: References: <20081103154501.6B3173A69E9@core3.amsl.com> 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 12/11/2008 09:14:20, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 12/11/2008 09:14:21, Serialize complete at 12/11/2008 09:14:21 Content-Type: multipart/alternative; boundary="----=_NextPart_08111209141887344650666_002" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_NextPart_08111209141887344650666_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ltans-dssc-05 =20 1. The abstract is only related to digitally signed data. The abstract sh= ould be extended to mention encryption.=20 It should also mention that the use of a weak cryptographic algorithm wit= hin a complex data structure=20 can be protected using a strong cryptographic algorithm which then may re= nder the whole data structure=20 adequate for its intended use. =20 The current abstract is the following: =20 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability=20 of cryptographic algorithms. =20 Proposed change for the whole abstract to solve these two comments: =20 Because cryptographic algorithms can become weak over the years,=20 it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting=20 data, these evaluations must be considered. This document specifies=20 a data structure that enables an automated analysis of the security=20 suitability of a given cryptographic algorithm at a given point of=20 time which may be in the past, at the present time or in the future. =20 The automated processing of a cryptographic data structure that=20 uses several cryptographic algorithms cannot be performed only using=20 the previous automated analysis, since in some cases a weak=20 cryptographic algorithm can be protected by a strong cryptographic=20 algorithm which may make the whole data structure adequate for its=20 intended use. =20 =20 2. Section 1.1. The text sates: =20 If algorithms lack the required properties, signatures could be forged= . =20 This sentence should be changed into: =20 If algorithms lack the required properties, signatures could be=20 forged, unless they are protected by a strong cryptographic=20 algorithm, e.g. a time-stamp token that uses a strong cryptographic=20 algorithm. =20 =20 3. Section 1.1. The text sates: =20 Very few algorithms satisfy the security requirements and are=20 suitable for usage in signatures. =20 This is not fully correct. =20 This sentence should be changed into: =20 Cryptographic algorithms that are used in signatures shall resist=20 during their period of use. For signature keys included in public key= =20 certificates, it is the validity period of the certificate. =20 Cryptographic algorithms that are used for encryption shall resist=20 during the time during which it is planned to keep the information=20 confidential.=20 =20 4. Section 1.1. The text sates: =20 A digital signature using a "weak" algorithm has no probative value. =20 This is not fully correct. =20 This sentence should be changed into: =20 A digital signature using a "weak" algorithm has no probative value,=20 unless the "weak" algorithm has been protected by a strong algorithm=20 before the time it was considered to be weak. =20 =20 5. Section 1.1. The text sates: =20 For this reason, it is important to periodically evaluate an algorithm's fitness and to consider the results of these evaluations when creating, verifying or renewing signatures. =20 This is not fully correct. A signature made by a human being that is dead= cannot be "renewed". =20 This sentence should be changed into: =20 For this reason, it is important to periodically evaluate an algorithm's fitness and to consider the results of these evaluations when creating and verifying signatures, or when maintaining the=20 validity of signatures made in the past. =20 6. Section 1.1. The text sates: =20 This prediction can help to detect whether an insecure algorithm=20 is used in a signature or whether a signature has been properly=20 preserved. =20 This is not fully correct. =20 This sentence should be changed into: =20 This prediction can help to detect whether a weak algorithm=20 is used in a signature and whether that signature has been properly=20 protected in due time by an another signature made using an algorithm=20 that is suitable at the present point of time. =20 =20 7. Definition of flexibility: =20 The text states: =20 Additionally the data structure must be designed independent of the=20 intended use, e.g., encryption, signing, verifying, and signature=20 renewing. Thus, the interpretion of the data structure is same for=20 every use case. Firstly there is typo on the word: interpretion =20 Secondly, the document does not define what is a signature algorithm.=20 There are three possible answers to that question, that may be illustrate= d=20 with the RSA algorithm: =20 1) it is only the RSA algorithm, 2) it is the RSA algorithm with a padding function, 3) it is the RSA algorithm with a padding function and a hash function= . =20 The text should clarify which case(s) are supported. If cases 2) or 3) ar= e supported,=20 then the above text is incorrect. =20 =20 8. Section 2.2.: =20 The text states: =20 An algorithm is suitable if it is contained in the current policy and the time of interest is within the validity period. =20 This sentence should be changed into: =20 An algorithm is suitable *at a time of interest* if it is contained=20 in the current policy and the time of interest is within the validity=20 period. =20 =20 9. Section 5.5. This section should first add another kind of output. Ple= ase add the following text: =20 If the algorithm is not in the policy, an error "algorithm unknown" is= =20 returned. =20 =20 10. Section 5.5. =20 The text states: =20 If the algorithm is not suitable relative to the time of interest,=20 return an error. =20 Change into: =20 If the algorithm is not suitable relative to the time of interest,=20 an error "algorithm unsuitable" is returned. =20 =20 11. Section 5.5. =20 The text states: =20 If the algorithm is suitable, return the Evaluation elements that were not discarded. =20 Change into: =20 If the algorithm is suitable, return the Evaluation elements that were not discarded, *in particular its validity period*. =20 =20 12. Section 6. Security Considerations=20 =20 In the comments made on draft-04, it has been requested to add text to wa= rn the user that=20 the processing rule described in section 5 is about *one* algorithm *inde= pendently of the use case*.=20 Depending upon the use case, an algorithm is no more suitable at the time= of evaluation, may be=20 no problem at all. =20 Proposed text: =20 The processing rule described in section 5 is about one cryptographic=20 algorithm independently of the use case. Depending upon the use case,= =20 an algorithm that is no more suitable at the time of interest, does no= t=20 necessarily mean that the data structure where it is used is no more=20 secure. =20 For example, an RSA signer's key of 1024 bits is being used in year=20 2009. The validity period of the signature key included in a public k= ey=20 certificate is three years. The signature is time-stamped in year 200= 9=20 with a time-stamp token that uses an RSA key of 2048 bits. =20 This data structure is revaluated in year 2020. Let us suppose that in= =20 year 2015 an RSA key size of 1024 bits will be broken. The fact that=20 the signature key of 1024 bits is no more suitable in year 2015 and=20 a fortiori in year 2020 does not mean that the whole structure is no=20 more secure, if an RSA key size of 2048 bits is still suitable in=20 year 2020. =20 In addition, to the key size considerations, other considerations=20 apply, like whether the time-stamp token has been provided by a=20 trusted authority. It means that the simple use of a suitability=20 policy is not the single element to consider when evaluating the=20 security of a complex data structure using several cryptographic=20 algorithms. =20 13. Section 6. Security Considerations . This section should include text= to cover the case of encryption. =20 Proposed text: =20 Re-encrypting documents that were originally encrypted using an=20 algorithm that is no more suitable, will not protect the semantics=20 of the document, if the document has been intercepted. However,=20 for documents stored in an encrypted form, re-encryption must be=20 considered, unless the document has lost its original value due to=20 time erosion. =20 =20 14. Appendix A.1. It should be indicated *in the title* that this appendi= x is informative. Denis ----- Message re=E7u -----=20 De : owner-ietf-ltans=20 =C0 : i-d-announce=20 Date : 2008-11-03, 16:45:01 Sujet : I-D Action:draft-ietf-ltans-dssc-05.txt Pi=E8ce(s) Jointe(s) au message original : (1). draft-ietf-ltans-dssc-05.txt Title : Data Structure for the Security Suitability of Cryptographic Al= gorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-05.txt Pages : 41 Date : 2008-11-03 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability of cryptographic algorithms.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_08111209141887344650666_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Comments on draft-ietf-ltans-dssc-05

 

1.=20 The abstract is only related to digitally signed data. The abstract shoul= d be=20 extended to mention encryption.

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

 

The=20 current abstract is the following:

 

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

=    and integrity of digital signed=20 data.  This proof depends o= n=20 the

=    security=20 suitability of the cryptographic algorithms used to=20 generate

=    or verify=20 the digital signature.  Bec= ause=20 algorithms can become weak

=    over the=20 years, it is necessary to periodically evaluate=20 their

=    security=20 suitability.  When signing = or=20 verifying data, these

=   =20 evaluations must be considered.&= nbsp;=20 This document specifies a data

=    structure=20 that enables automated analysis of the security suitability=20

=    of=20 cryptographic algorithms.

=  

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

 

=    Because=20 cryptographic algorithms can become weak over the years,=20

=    it is=20 necessary to evaluate their security suitability.

=    When=20 signing or verifying data, or when encrypting or decrypting=20

=    data,=20 these evaluations must be considered.&n= bsp;=20 This document specifies

=    a data=20 structure that enables an automated analysis of the security=20

=   =20 suitability of a given cryptographic algorithm at a given point of= =20

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

=  

=    The automated processing of a cryptographi= c data=20 structure that

   uses several cryptographi= c=20 algorithms cannot be performed only using

   the previous = automated=20 analysis, since in some cases a weak

=    cryptographic algorithm = can be=20 protected by a strong cryptographic

   algorithm which may make = the whole=20 data structure adequate for its

   intended use= .=

 

 

2. Section 1.1. The text=20 sates:

 

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

 

This=20 sentence should be changed into:

 

=    If=20 algorithms lack the required properties, signatures could be=20

=    forged, unless they are p= rotected=20 by a strong cryptographic

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

   = algorithm.

 

 

3. Section 1.1. The text=20 sates:

 

=    Very few=20 algorithms satisfy the security requirements and are=20

=    suitable for usage in=20 signatures.

 

This=20 is not fully correct.

 

This=20 sentence should be changed into:

 

   Cryptographic algorithms = that are=20 used in signatures shall resist

   during their period of us= e.  For signature keys included in = public=20 key

   certificates, it is the v= alidity=20 period of the certificate.

 

   Cryptographic algorithms = that are=20 used for encryption shall resist

   during the time during wh= ich it is=20 planned to keep the information

   confidential.=20

 

4. Section 1.1. The text=20 sates:

 

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

 

This=20 is not fully correct.

 

This=20 sentence should be changed into:

 

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

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

=    before=20 the time it was considered to be weak.

 

 

5. Section 1.1. The text=20 sates:

 

=    For this reason, it is important= to=20 periodically evaluate an

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

=    when creating, verifying = or=20 renewing signatures.

 

This=20 is not fully correct. A signature made by a human being that is dead cann= ot be=20 "renewed".

 

This=20 sentence should be changed into:

 

=    For this=20 reason, it is important to periodically evaluate an

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

=    when=20 creating and verifying signatures, or when maintaining the=20

=    validity of signatures ma= de in the=20 past.

 

6. Section 1.1. The text=20 sates:

 

=    This=20 prediction can help to detect whether an insecure algorithm=20

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

=    preserved.

 

This=20 is not fully correct.

 

This=20 sentence should be changed into:

 

=    This=20 prediction can help to detect whether a weak algorithm=20

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

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

=    that is suitable at the p= resent=20 point of time.

 

 

7.=20 Definition of flexibility:

 

The=20 text states:

 

=   =20 Additionally the data structure must be designed independent of th= e=20

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

=   =20 renewing.  Thus, the= =20 interpretion of the data structure is same for <= /P>

=    every use=20 case.

Firstly=20 there is typo on the word: = interpretion

 

Secondly, the document does not define what is a si= gnature=20 algorithm.

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

 

   1) it is only the RSA=20 algorithm,

   2) it is the RSA algorith= m with a=20 padding function,

   3) it is the RSA algorith= m with a=20 padding function and a hash function.

 

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

 

 

8.=20 Section 2.2.:

 

The=20 text states:

 

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

=    the time of interest is w= ithin the=20 validity period.

 

This=20 sentence should be changed into:

 

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

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

=    period.

 

 

9. Section 5.5. This section should firs= t add=20 another kind of output. Please add the following=20 text:

 

   If the algorithm is not i= n the=20 policy, an error "algorithm unknown" is

   returned.

 

 

10. Section=20 5.5.

 

The=20 text states:

 

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

=    return an=20 error.

 

Change into:

 

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

   an error "algorithm unsui= table" is=20 returned.=

 

 

11. Section=20 5.5.

 

The=20 text states:

 

=    If the=20 algorithm is suitable, return the Evaluation elements=20 that

=    were not=20 discarded.

 

Change into:

 

=    If the=20 algorithm is suitable, return the Evaluation elements=20 that

=    were not=20 discarded, *in particular its validity period*.<= /P>

 

 

12. Section 6. = Security=20 Considerations 

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

 

Proposed text:

 

   The processing rule descr= ibed in=20 section 5 is about one = cryptographic=20

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

   an algorithm that is no m= ore=20 suitable at the time of interest, does not

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

   secure.=

 

   For example, an RSA signe= r's key=20 of 1024 bits is being used in year

   2009.  The validity period of the sign= ature key=20 included in a public key

   certificate is three year= s.  The signature is time-stamped i= n year=20 2009

   with a time-stamp token t= hat uses=20 an RSA key of 2048 bits.

 

   This data structure is re= valuated=20 in year 2020. Let us suppose that in

   year 2015 an RSA key size= of 1024=20 bits will be broken.  The f= act that=20

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

   a fortiori in year 2020 d= oes not=20 mean that the whole structure is no

   more secure, if an RSA ke= y size of=20 2048 bits is still suitable in

   year 2020.

 

   In addition, to the key s= ize=20 considerations, other considerations

   apply, like whether the t= ime-stamp=20 token has been provided by a

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

   policy is not the single = element=20 to consider when evaluating the

   security of a complex dat= a=20 structure using several cryptographic

   algorithms.

 

13. Section 6. = Security=20 Considerations 

Proposed text:

 

=  =   Re-encrypting documents that we= re=20 originally encrypted using an

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

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

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

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

=    time=20 erosion.

 

 

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

 

Denis<= /P>

-----=20 Message re=E7u ----- De=20 : owner-ietf-ltan= s=20 =C0=20 : i-d-announce Date=20 : 2008-11-03, 16:45:01 Sujet=20 : I-D Action:draft-ietf-ltans-dssc-05.txt

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

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

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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", = "SHALL=20 NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" i= n=20 this
document are to be interpreted as described in [RFC2119].
A URL=20 for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt
Internet-Drafts=20 are also available by anonymous FTP=20 at:
ftp://ftp.ietf.org/internet-drafts/

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

------=_NextPart_08111209141887344650666_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 mA3Fj0ga053060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 08:45:00 -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 mA3Fj0Po053057; Mon, 3 Nov 2008 08:45:00 -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 mA3Fj0vt053037 for ; Mon, 3 Nov 2008 08:45:00 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 6B3173A69E9; Mon, 3 Nov 2008 07:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-dssc-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103154501.6B3173A69E9@core3.amsl.com> Date: Mon, 3 Nov 2008 07:45:01 -0800 (PST) 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 the Security Suitability of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-05.txt Pages : 41 Date : 2008-11-03 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the cryptographic algorithms used to generate or verify the digital signature. Because algorithms can become weak over the years, it is necessary to periodically evaluate their security suitability. When signing or verifying data, these evaluations must be considered. This document specifies a data structure that enables automated analysis of the security suitability of cryptographic algorithms.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ltans-dssc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03073935.I-D@ietf.org> --NextPart-- 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 mA2IF0Mh056225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2008 11:15:00 -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 mA2IF06d056224; Sun, 2 Nov 2008 11:15:00 -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 mA2IF02r056218 for ; Sun, 2 Nov 2008 11:15:00 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 457BC3A67D0; Sun, 2 Nov 2008 10:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-ltap-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081102181501.457BC3A67D0@core3.amsl.com> Date: Sun, 2 Nov 2008 10:15:01 -0800 (PST) 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 : Long-term Archive Protocol (LTAP) Author(s) : A. Jerman-Blazic, et al. Filename : draft-ietf-ltans-ltap-07.txt Pages : 64 Date : 2008-11-02 This document describes a service operated as a trusted third party to securely archive electronic documents called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ltap-07.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-ltap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-02100556.I-D@ietf.org> --NextPart--