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

[Larry Masinter <LMM@xxxxxxx>]

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:

> The document misses to indicate that it is necessary to demonstrate the 
> 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?

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

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 
> to be defined.

Yes, please.

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

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

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?

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

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.

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

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.

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

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

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

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? 

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

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

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

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

> 4. Introduction
> 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 
> digital signature of a signed object be compromised or become weak.

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

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

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

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?