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

Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt


Hello friends,

the first document of our working group is coming to a final state. I asked Carl and the authors of the document to integrate the input of
the last discussions inspired by Denis into the document so that we get
to a final version. From my feeling the discussion here on the
mailing-list has come to the time of conclusion about the requirements
for long-term archive.

I do no have that feeling yet. Until we agree on this document, a Last Call for the ERS document would be premature.

Many discussions and ideas have been presented.
For me it was very insightful and interesting to learn the different
views and requirements from all over the world. We took our time for all
the aspects, now I think we can move to a conclusion with this document
so that we can lead our discussions concerning the Notary Services
easier.

We still need to agree on what is or is not a Notary Service, but we have not finished the discussion on the requirements for a long-term archive service.

I think that Carl, Ulrich and Ralf did a good job on this and
hope that you agree. 

So I start the WG LAST CALL for our first WG document:
"draft-ietf-ltans-reqs-02.txt"


I declare WG Last Call (period 2 weeks) terminating at 7th October 2004
12:00 EST.

You will find my comments below:

It is believed that the last call was made to force comments to be done shortly, since the document is not yet mature. All the comments below are focussed on usage of cryptography for the short and long term, thus concerns like longevity of the storage media (although very important) are not considered.

The following comments are thus offered:


1. Abstract

The abstract is not correct and should be changed.

The document misses to indicate that it is necessary to demonstrate the origin of the data and that the document has been placed in a storage before a given date so that even the system engineers in charge of the archive system do not have the possibility to modify any more stored documents.

It is proposed to delete the present abstract and to replace it with:

“This document specifies the technical requirement for long-term archive services able to support non repudiation of data origin with integrity and existence of data at a given time. Data to be stored and retrieved may include signed data. Long-term archive services operate under an archive policy which will need to be periodically redefined as the time goes. This document specifies the main constituents of an archive policy”.

In fact the main constituents of an archive policy still need to be defined. The following comments focus on one of the components of an archiving policy, i.e. the cryptographic maintenance policy, so the work still needs to be done.


2. Introduction

The second paragraph needs to be revisited (besides the two typos in the first sentence) because it is too vague. Proposed replacement:

“A long term archive service accepts data from users. This data may be confidential data or public data. When it is confidential data, it is the responsibility of users only to take care of the confidentiality of the data they submit. If users care that their data shall not have its semantics disclosed to the system engineers from the long term archive service, then they shall take care themselves of the protection of their data.

When data is confidential data, it is important that submitters can check for themselves:

   - that the data was placed in a server from the long-term archive
     service,

   - that the data has been unmodified since the time of its
     placement (*), and

   - that the data originates from them (either symmetric
     or asymmetric cryptography may be used).

(*) more precisely a proof of existence of data at a given time preceding the archival time, to demonstrate that the data was placed in a server from the long-term archive before that time.

When the data is public data, it is important to be able to demonstrate to someone else (i.e. obtain a non-repudiation evidence):

   - that the data was placed in a server from the long-term archive
     service,

   - that the data has been unmodified since the time of its
     placement, and

   - that the data originally placed originates from a given entity
     (different from servers belonging to the long-term archive
     service). Note: that entity may or may not be a Notary.

Since the document addresses long term storage, transfer from one data storage unit to another may happen. Retrieval of data may thus be done from a server different from the server where the data was originally stored. It is therefor important to attach the security to the data itself and not to rely only on the security mechanisms and procedures performed by the server where the data is stored or retrieved.

Two non-repudiation evidences will need to be provided:

   - a first one to demonstrate to third parties the data originally
     placed originates from a given entity,

   - a second one to demonstrate to third parties that the data was
     originally accepted for storage, at a given time, by a server
     belonging to a given long-term archive service.

Since these evidences will be provided using cryptographic means, it is important to maintain the cryptographic quality of theses evidences, even if the signature policy under which the signatures have been done has expired.

A signature policy cannot last longer than the resistance of the root keys used in that policy, so it will always be limited in time.

Some CA keys used to validate an electronic signature may last in practice shorter that the end of the validity period of a signature policy. So it is important to be able to maintain their validity beyond the end of the validity period of the signature policy.

This cryptographic maintenance activity is part of the responsibilities of a long-term archive service and will be performed according to one or more cryptographic maintenance policies.”


3. Introduction

The third paragraph needs to be revisited because it is inappropriate.

Validation of assertions of agreements originally asserted with digital signatures is not a task that is within the scope of a long-term archive service. Proposed replacement:

“A long-term archive service may optionally support a service able to check an evidence demonstrating that an archive package has been originally accepted for storage, at a given time, by a server belonging to another given long-term archive service.”


4. Introduction

The first sentence from last (i.e. fifth) paragraph from page 3 needs to be revisited because it is to vague (what is the “something ?”). Delete the first sentence.


5. Introduction

The very last sentence from the paragraph from page 3 needs to be revisited because it is too vague. Since notarization is an undefined or controversial term, it cannot be said that it will or will not be covered in this document. It is proposed to delete that sentence and not to use the words notarization and notary at any place within this document.


6. Terminology

The overall new terminology looks fine. However, it would be useful to introduce three new terms:

Cryptographic maintenance policy: a named set of rules that defines how to maintain the validity of digitally signed objects should one of the hash functions or asymmetrical algorithm used to create a digital signature of a signed object become weak or one of the private keys used to create a digital signature of a signed object be compromised or become weak.

Critical cryptographic parameters: collection of cryptographic parameters, together with their associated parameters, if any (e.g. key lengths), associated with data, to be used to maintain the validity of digitally signed objects under a cryptographic maintenance policy.

Cryptographic maintenance parameters: Critical cryptographic parameters together with a reference to a cryptographic maintenance policy.


7. General Principles

Starting from the second sentence on page 6, the text needs to be revisited, since the text is only addressing one case out of two.

As mentioned previously two non-repudiation evidences may be attached to a given archived data object. These non-repudiation evidences will need to be maintained over time.

If the data object that is submitted does not include an evidence to demonstrate to third parties the data originally placed originates from a given entity, then it is correct to say that the data object is opaque.

However, this is no more the case, when the data object that is submitted includes an evidence to demonstrate to third parties the data originally placed originates from a given entity.

The “conclusion” made in the third paragraph is therefor incorrect. A long-term archive service may need to operate in accordance with the content of the archived data objets. In addition, as said earlier, since notarization is an undefined or controversial term, it should not be used at any place within this document.

Proposed replacement for both the second and third paragraphs:

“A long-term archive service may operate in two modes:

   - a passive mode, where the archived data object is an opaque
     collection of bytes, or/and

   - an active mode, where the archived data object is associated
     with cryptographic maintenance parameters.

When operating is the active mode, a long-term archive service has to apply a cryptographic maintenance policy on archived data objects using the critical cryptographic parameters associated with every archived data object.

When operating either in the passive or the active mode, a long-term archive service has to apply a cryptographic maintenance policy on the archived packages using the cryptographic maintenance parameters associated with a set of archived packages”.

8. General Principles

The text from the last sentence, on page 6, needs to be revisited. Proposed replacement:

“ A long term archive service provides material that may be used to demonstrate the existence at a given time of archived data objects, and both the integrity and authenticity of these archived data objects (i.e. that they originate from servers under the responsibility of a given long term archive service.”


9. Section 4. Technical requirements

This section describes, quite well, the functions dedicated to storage and retrieval.

However, it currently misses to describe the functions associated with the use of cryptographic maintenance policies and cryptographic maintenance parameters which are always associated with archived packages and with critical security parameters which may be associated with archived data objects.

In order to fill-in this gap, some text in provided below:

“4.X Cryptographic maintenance

4.X.1 Functional requirements

   A long term archive service must maintain the cryptographic
   validity of its evidence records. It needs to perform the following
   basic operations:

       - attach cryptographic maintenance parameters to one or a set
         of archived packages,

       - apply the cryptographic maintenance policy referenced within
         the cryptographic maintenance parameters to maintain the
         validity of its evidence records using the critical
         cryptographic parameters,

       - periodically apply the original cryptographic maintenance
         policy using the critical cryptographic parameters,

       - periodically apply a new cryptographic maintenance policy
         should the previous cryptographic maintenance policy become
         weak or inappropriate.

   When an archived data objet is submitted to a long term archive
   service with cryptographic maintenance parameters, then the long
   term archive service shall either maintain the cryptographic
   validity of that archived data objet or refuse to accept the
   service. If it accepts, then it needs to perform the following
   basic operations:

       - apply the cryptographic maintenance policy requested by the
         submitter within the cryptographic maintenance parameters and
         maintain the validity of the archived data objet according to
         that cryptographic maintenance policy using the critical
         cryptographic parameters that are present in the
         cryptographic maintenance policy associated with the archived
         data objet,

       - periodically apply the original cryptographic maintenance
         policy that has been used in accordance with the critical
         cryptographic parameters,

       - periodically apply a new cryptographic maintenance policy
         if the previous cryptographic maintenance policy
         becomes too weak or inappropriate.


4.X.1 Rational

Maintenance of the validity of archived packages is a necessary basic function of a long-term archive service.

Maintenance of the validity of archived data objets is an optional function of a long-term archive service”.


10. A new section should be introduced to address the requirement of some data structures. Proposed text;

“ Y. Requirements on some data objects

Y.1 Requirements on cryptographic maintenance policies

A cryptographic maintenance policy:

   - must be unambiguously identified by an object identifier
     (e.g. an OID),

- must include a validity period,

   - must specify how the necessary bindings to the time scale will
     be guaranteed, for example it can specify the Time-Stamping Units
     (TSU) recognized under that policy,

   - may unambiguously reference a sequence of one or more previously
     defined cryptographic maintenance policies.


Y.2 Requirements on critical cryptographic parameters

Critical cryptographic parameters shall include data objects describing all the algorithms, and the associated key lengths used in the object to which the critical cryptographic parameters are associated. These data objects may be in the form of data objects identified using an OID, and may include one or more algorithm specific parameters.

Y.3 Requirements on cryptographic maintenance parameters

Cryptographic maintenance parameters shall include two components:

- critical cryptographic parameters, and

- an unambiguous reference to one cryptographic maintenance policy.


11. In formation should be added to address cryptographic maintenance issues in case a hash function exhibits collisions. Proposed text to be included in the security considerations section:

“Cryptographic maintenance issues in case a hash function exhibits collisions

Submitters may submit:

   1) signed data and their associated signatures, or
   2) signatures only (i.e. without the signed data).

In case the hash function used to compute the digital signature over the original data exhibits collisions, it is necessary to recompute a hash of that original data using another hash function. This is not feasible if signatures only are submitted (i.e. without the signed data)”.


12. Minor comment on section 4.2.1. page 8.

The first sentence is too vague since “non-repudiation of data” is not a well defined service. It is believed it is meant there something like: “non-repudiation of the fact that some data was placed in a server from the long-term archive service, and that the data has been unmodified since the time of its placement”. A similar change should be done in section 4.2.2.


13. Comment on section 4.3. page 8.

This section is confusing since the previous one already covers data integrity. Its text should be merged with the previous section.


14. Comment on section 4.4.1 page 9.

This section introduces the term “long-term archive service policy”. Since the concept of cryptographic maintenance policy has now be introduced, it would be more exact to say that the “characteristics such as quality of the time-stamps” are part of the cryptographic maintenance policy, which itself may be part of a long-term archive service policy. The text should be changed accordingly.


15. Comment on section 6 page 12.

The second paragraph should be modified to refer to the cryptographic maintenance policy.

Note: the very last sentence of the section is very true, but should be moved in the main body of the document with additional explanations, since the chain of policies has also to do with a chain of cryptographic maintenance policies.

END OF COMMENTS

Denis

Best regards

	Tobias
	Chair of LTANS



Ps.: Small remark: Soon after completion of this Last Call I prepare to
start the Last Call for the ERS document so that we can focus our work
fully on the notary services problems at the 61st IETF meeting in
November.




-----Original Message-----
From: owner-ietf-ltans@xxxxxxxxxxxx

[mailto:owner-ietf-ltans@xxxxxxxxxxxx]

On Behalf Of Internet-Drafts@xxxxxxxx
Sent: Tuesday, September 21, 2004 9:39 PM
To: i-d-announce@xxxxxxxx
Cc: ietf-ltans@xxxxxxx
Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt

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

	Title		: Long term archive service requirements
	Author(s)	: C. Wallace, et al.
	Filename	: draft-ietf-ltans-reqs-02.txt
	Pages		: 17
	Date		: 2004-9-21

In many scenarios, users need to be able to ensure and prove the
existence and integrity of data, especially digitally signed data, in
a common and reproducible way over a long and possibly undetermined
period of time.  This document specifies the technical requirements
for a long-term archive service to support such scenarios.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of

the

message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ltans-reqs-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@xxxxxxxxx
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-reqs-02.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail

readers

	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.


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