Comment on draft-ietf-ltans-xmlers-03.txt

["Andreas Menke" <[e-mail]>]

Hello list.

Point 4.2.1. Time Stamp Renewal in 'draft-ietf-ltans-xmlers-03.txt' is
irritating me: Is it right that 'the complete content of the last ATS MUST
be time-stamped...'?

RFC4998 point 5.2 says 'the content of the timeStamp field
   of the old Archive Timestamp has to be hashed and timestamped by a
   new Archive Timestamp [...] generally one can collect a number of
   old Archive Timestamps and build the new hash tree with the hash
   values of the content of their timeStamp fields.'

Is it right that there should be no conversion between XML and RFC4998
coding ever since working with different hash values?

Is it right that a collection of 'a number of old Archive Timestamps and
build the new hash tree' is not supported by XML coding in contrast to
RFC4998?

In 2.1 Structure there seems to be shown a structure which does not
correspond to the schema in 6. Is it right to assume that the schema in 6.
is what is meant?


Regards


Andreas Menke

-----------------------------
Diplom-Informatiker (Uni.)
Andreas Menke
Team Leader, Development

OPENLiMiT SignCubes GmbH
Saarbrücker Str. 38 A
D-10405 Berlin

Fon: [phone] – 10
Fax: [phone] – 11
[e-mail]
www.openlimit.com

Geschäftsführer:
Heinrich Dattler, Armin Lunkeit
Nadine Model (Prokuristin)
Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 86352 B
Finanzamt für Körperschaften II
St.-Nr. 37/155/20819
USt-ID: DE 224136339
---

Erleben Sie, wie einfach es ist, elektronisch zu unterschreiben und testen
Sie die neue Signatur-Software OpenLimit CC Sign 2.5 für 30 Tage kostenlos.
Hier downloaden:
https://www.openlimit.com/de/produkte/cc-sign/download-cc-sign-testversion.h
tml




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 n5N7EBSW065100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 23 Jun 2009 00:14:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5N7EB0X065096; Tue, 23 Jun 2009 00:14:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from postrelay2.edis.at (postrelay2.edis.at [85.126.233.175]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5N7DwN1065082 for <[e-mail]>; Tue, 23 Jun 2009 00:14:09 -0700 (MST) (envelope-from [e-mail])
Received: from mailrelay.edis.at (postrelay2.edis.at [85.126.233.175]) by postrelay2.edis.at (Postfix) with ESMTP id 77A5F1804FC97 for <[e-mail]>; Tue, 23 Jun 2009 09:13:57 +0200 (CEST)
Received: from ANDY-MOB ([::ffff:212.202.128.19]) (AUTH: LOGIN [e-mail], SSL: TLSv1/SSLv3,128bits,AES128-SHA) by mailrelay.edis.at with esmtp; Tue, 23 Jun 2009 09:13:57 +0200 id 0000000000030443.000000004A4080B5.0000164D
Received: from ANDYMOB by ANDY-MOB (PGP Universal service); Tue, 23 Jun 2009 09:14:01 +0100
X-PGP-Universal: processed; by ANDY-MOB on Tue, 23 Jun 2009 09:14:01 +0100
From: "Andreas Menke" <[e-mail]>
To: [e-mail]
Subject: Comment on draft-ietf-ltans-xmlers-03.txt
Date: Tue, 23 Jun 2009 09:13:40 +0200
Organization: OpenLimit SignCubes GmbH
Message-ID: <000701c9f3d2$2c018a70$84049f50$@[e-mail]>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acnz0iHCeAYJp3CIQwmtkCW2s605pQ=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Language: de
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello list.

Point 4.2.1. Time Stamp Renewal in 'draft-ietf-ltans-xmlers-03.txt' is
irritating me: Is it right that 'the complete content of the last ATS MUST
be time-stamped...'?

RFC4998 point 5.2 says 'the content of the timeStamp field
   of the old Archive Timestamp has to be hashed and timestamped by a
   new Archive Timestamp [...] generally one can collect a number of
   old Archive Timestamps and build the new hash tree with the hash
   values of the content of their timeStamp fields.'

Is it right that there should be no conversion between XML and RFC4998
coding ever since working with different hash values?

Is it right that a collection of 'a number of old Archive Timestamps and
build the new hash tree' is not supported by XML coding in contrast to
RFC4998?

In 2.1 Structure there seems to be shown a structure which does not
correspond to the schema in 6. Is it right to assume that the schema in 6.
is what is meant?


Regards


Andreas Menke

-----------------------------
Diplom-Informatiker (Uni.)
Andreas Menke
Team Leader, Development

OPENLiMiT SignCubes GmbH
Saarbrücker Str. 38 A
D-10405 Berlin

Fon: [phone] – 10
Fax: [phone] – 11
[e-mail]
www.openlimit.com

Geschäftsführer:
Heinrich Dattler, Armin Lunkeit
Nadine Model (Prokuristin)
Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 86352 B
Finanzamt für Körperschaften II
St.-Nr. 37/155/20819
USt-ID: DE 224136339
---

Erleben Sie, wie einfach es ist, elektronisch zu unterschreiben und testen
Sie die neue Signatur-Software OpenLimit CC Sign 2.5 für 30 Tage kostenlos.
Hier downloaden:
https://www.openlimit.com/de/produkte/cc-sign/download-cc-sign-testversion.h
tml





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 n5FAjCiu002860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 15 Jun 2009 03:45:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5FAjCLe002859; Mon, 15 Jun 2009 03:45:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 n5FAjBFp002852 for <[e-mail]>; Mon, 15 Jun 2009 03:45:12 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 24A423A6CB7; Mon, 15 Jun 2009 03:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-ltans-dssc-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 15 Jun 2009 03:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--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-09.txt
	Pages           : 42
	Date            : 2009-06-15

Since cryptographic algorithms can become weak over the years, it is
necessary to evaluate their security suitability.  When signing or
verifying data, or when encrypting or decrypting data, these
evaluations must be considered.  This document specifies a data
structure that enables an automated analysis of the security
suitability of a given cryptographic algorithm at a given point of
time which may be in the past, at the present time or in the
future.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-09.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-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--