Re: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

loic and Ernst,

First, sorry for the late answer. 

>  Hello,
> I am pretty new to ltans subjets.
> I read the Requirements draft and have some questions. Don't worry if some looks stupid, please let me know if it's the case.
> 

Questions are rarely stupid, only the answers, so you are in a safer position than me (since I am responding) :-)

> §4.1.1 
> You talk about "acknowledgment" that have to be provided by a LTA.
> I think these must be signed by the LTA in order to give submitter an evidence that he sent data to LTA.
> What the need of unsigned acknowledgment?

The idea behind is that the archive service has a backend that provides a 'pointer' to the
data, let's say a URI and then, independantly, and responing to other requirement, there 
may or may not be a front end that adds some security envelope attesting other information. 

You can for example have a (TLS) connection that just return a URI. 

> 
> For the question asked at the end of the chapter, I believe that many acknowledgement must be provided. The final one must be a summary of all precedents.

You are refering to the 'grouping' at the end of chapter 4? 

My interpretation of 4.7.1 seems to indicate to me that indeed at least each element needs
to be identifiable individually ==> acknowledgement, and of course, there is an acknowmedgment
for the group as a whole. 

I haven't yet finished some work of 'folding' out common basic data elements from the
original darfts and texts (TAP, DVCS, ERS, ...), so i have not yet a comple picture of
what a group actually is, and what protocol exchanges are really necessary;

groups may be represented for example as a mime multipart, as the newly proposed contentinfo
which encapsulates several others, as some manifest in XML, or as hash trees with some
simple things as leafs, ...

> 
> Nearly End of duration period of archive must be provided to submitter, in order to let him change the duration if needed.
> 
I can parse this question? Are you saying that an archiver must inform a client before the
end of a period in order to permit an extension? 

I think that this is somewhat of of scope, since it at least it can be added as an
additional service by an archiver, but not as an essential feature of the protocol.

or, when you say 'MUST inform', what does this mean? How can the archiver get a proof
of this? One may be tempted to say: May not delete before explicit confirmation of
the client. But what does this mean? Do you have an idea of a protocol exchange?

> 
> §4.2.1
> Why lta MUST permit the specify of metadata ?

> Can it be possible for a LTA services not to propose this permission ?

> Has metadata to be outside the data ?

The current idea among the few persons who try to come up with a protocol is:

metadata can be outside and inside. Some may be outside, i.e. explicity visible
in an attestation describing the content: 'This is the attestation for patent number 123',
'The archived raw data are in format "mimetype", The 'owner' 'dublin core info',
whatever you want to see explicitely.

Some metadata can be inside (not visible without retreaving the data), and mainly useful for
organising the internal work of the archiver, or to provide for potential transformations
in future. The same information as outside, thus, you don't want them to be seen
immediately in an attestation.  

You need to have at least (either explicitely or in a customer policy) a definition
of the nature of the raw octets to be archived. 

> Couldn't it be inside a group of data  --> [[data][metadata]], in order not to be dealed by LTA ?
That is a possible approach: It may also be possible to specify something like a mime multipart/mixed
or the newly proposed ContentInfo that encapsulated several Contentinfos. (If we talk CMS), in
xml-dsig, there may be other structure with manifests etc. 

> 
> §4.5.1
> The confidentiality might be not necessary. By example, let's think about a service that propose to archive patent. What the need of confidentiality ?
> So I propose to change "A long term archive MUST provide means to ensure..." by "A long term archive MAY..."
> 
The term is correct: You may not have any confidentiality requirements for a particular context, but
if you have them, the server must provide the means. The server cannot decide (dynamically) to forget
about confidentiality. (Well, this is said with my limited noletsch ow ze inklisch laehngwitsch.)


> Well I think that's all.
> 
> Regards,
> 
> Loïc HOUSSIER
> 
> Peter Sylvester wrote:
> 
> > During a telephone call Denis informed me that he had missed the 
> > following message. For convenience (of Denis), I resend it. Sorry to
> > bother the others again with the content. :-)
> > 
> > Peter
> ...
> >> 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.
> 
> The technical problem of maintaining the security status as it was at
> the time of deposit is that algorithms become weaker and that
> certificates binding a service or name to a public key may go
> out-of-date. The service provider can stop her operation after the
> latest NotAfter indication of all issued certificates is over and then
> you loose the outside trust anchor of the archive.

You mention TWO things here: 

- timely dependency of certificates (the ones used by the service provider
  I guess)
  ==> A known technique is to replace digital signatures by a hash links
      for which the top most hash is verifiable at the current time.
      (This can be also by means not using digital signatures, e.g. by
      comparision with a well published hash).

- cryptographic weaknesses.
  ==> in the above, dependancy on secrets for authenticity can be replaced
      by hashes, weaknesses in hash function, long term security needs
      at least one additional redundant need (for VERY long term), like
      a good possiblity that a current physical copy had been done at
      the indicated time, or transformations have been confirmed etc.

> 
> So it is not document specific, but you must be able to determine
> starting from the document which service-specific policy was active as
> the document was deposed.
> 
> Certainly we can consider different possiblities for maintenance but
> first we must think on crypto solutions.

I am not sure about the 'first' in this sentence :-) 
Do you want to address failures of hash functions. 

> 
> Regards,
> Ernst.
> 
> 
>