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

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Oct 2004 17:11:04 +0200

> 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: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of [email-masked]
>>Sent: Tuesday, September 21, 2004 9:39 PM
>>To: [email-masked]
>>Cc: [email-masked]
>>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
>>[email-masked] 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:
>>	[email-masked].
>>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.
> 
>

---

From: Larry Masinter <[email-masked]>
Date: Sat, 02 Oct 2004 19:32:02 -0700

I apologize for not reviewing your comments carefully before
writing my own. In several places we make conflicting suggestions
for what should be done with the text. I suppose with editorial
suggestions that the editors have the final call, but where
there are areas of technical disagreement, the working group
should comment.

I think it's appropriate to respond to comments when they are
received, rather than waiting for the end of the 'last call'
period. Here are my comments on yours; we should work to resolve
conflicts where we've made different suggestions:

> origin of the data

The submitter? Or the originator? Or both?

> 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.

Is this a requirement of the protocol, or a definition of
a long-term archive system?

> "This document specifies the technical requirement for long-term archive 

> document specifies the main constituents of an archive policy".

This still doesn't distinguish between the description of an archive
service and the requirements for the protocol for interacting with it.

To be honest, it's usually fruitless to focus on the abstract if there
is disagreement about the substance, so we should come back to the
abstract later. I like most of what you wrote.

I still don't understand exactly what is meant by an 'archive policy'
and whether it is a service-wide policy or a document-specific policy.
Can one archive service provider proxy for many different ones, each
of which with its own policy?

> In fact the main constituents of an archive policy still need 

Yes, please.

> policy, i.e. the cryptographic maintenance policy, so the 
> work still needs to be done.

Perhaps you could be more explicit, or give some references, to
an example of what such a complete policy might be?

> 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 

> they shall take care themselves of the protection of their data.

Is this really the idea? That the long-term archive has no
responsibility to keep its archived data private??!? I could
imagine different archives with different service guarantees,
but it's hard to imagine a scenario where there is no requirement
for confidentiality by the service provider, e.g., if I don't
want my identity and the amount of data I've archived to be made
public. So, if privacy from traffic analysis is a requirement,
why is privacy in general not a requirement?

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

Is it the submitters that want to check, or some third party
to which the submitters wish to provide evidence? A submitter
knows what was submitted, no?

>       or asymmetric cryptography may be used).

I think the comment about cryptography is perhaps out of place.
It is a mechanism, not a requirement. Or is there a requirement
to use cryptography? Or to support one or the other or both?

> (*) 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.

I think there's a case where a malicious (or hacked) LTA might
provide unmodified data to some retrievers and modified data
to others, so it's useful to be clear about WHICH data has
been 'unmodified'.

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

Non-repudiation is important whether or not the data is public.

>       service). Note: that entity may or may not be a Notary.

I don't understand the use case where a Notary might be the
'originator'. Surely the Notary is another party whose role
is to add assurances, not an originator. Or do you imagine
a real (human) Notary using a LTA service?
 
> 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.

I don't think this follows. It's important for the storage to be
secure operationally, and that any transfers be performed securely.
One way to do that would be to encrypt the data and rely on the
encryption during the transfer, but this has its difficulties,
especially if the data is accompanied by meta-data (oh, access
control policies) that might also be confidential.

>       belonging to a given long-term archive service.

This is a good separation. I'm still a little uncomfortable
with 'originates', since the demonstration isn't really of
the origination but an initial attestation. 

> Since these evidences will be provided using cryptographic 
> means,

Must they be provided using cryptographic means? There are no
other means? How about 'When these evidences are provided ...'.

> validity period of the signature policy.

I'm unclear about whose validity 'maintain their validity' applies
to. The CA keys? You're going to maintain the validity of the keys
beyond the end of the validity period of the keys? 

> cryptographic maintenance policies."

I think cryptographic maintenance activities are one way of
providing long-term assurance, certainly.

> "A long-term archive service may optionally support a service able to
check 
> given long-term archive service."

I'm not sure why it is out of scope. It seems like a natural
service for long-term archive services to offer.

> 5. Introduction

I think my suggestions here are more explicit than yours, but I
hope I've accomplished the same goal.

> 6. Terminology
...
> 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 

When there is a 'named set of rules', what is the namespace?
Who maintains it?

Note that all of the maintenance should
happen BEFORE 'hash functions or asymmetrical algorithms become
week' and BEFORE private keys are compromised or become weak
and not after.

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

I think what you're saying is that cryptographic maintenance
is an option for providing long-term assurance. Of course,
you could consider this 'two modes', but calling them
'active' and 'passive' is misleading.  There may be other
operational ways of providing long-term assurance that don't
involve cryptographic maintenance but are still 'active'.

> set of archived packages".

Cryptographic maintenance is only applied when cryptographic maintenance
is applied, though. So how could a service with opaque data and no
information about its signatures apply a cryptographic maintenance
policy?