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

From: Peter Sylvester <[email-masked]>
Date: Mon, 13 Dec 2004 17:58:31 +0100 (MET)

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.

---

From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
Date: Thu, 16 Dec 2004 15:57:22 +0100

Thank You for the answer.
Comments below.

Loïc 

> In an inhouse environment LTA is a service for an application 
> system. E.g.
> inhouse environment is a hospital, LTA is document management 
> or archive
> system and application system is a medical system used for 
> generation of
> medical documents and signing them by doctors. 
> In this case only evidence records are needed to verify, that archived
> documents existed at a certain point in past - e.g. before 
> signature and
> hash-algorithms used in it got weak or certificates in it 
> were revoked.
> Acknoledgement is useful to have an indication, that storing 
> was accepted
> and successful. But no proof for document delivery is needed, 
> therefore no
> signed acknoledgements are needed.

[LH]So, there is case where signed notification is not needed. But if there is some use-case where it is, shouldn't it be consider ?

> 
> If archive service is an external by a service provider, 
> proof of delivery
> using a signed acknowledgement might be helpful. Problem is, 
> that signed
> acknowledgement is valid only a relatively short time. It 
> will loose its
> value of evidence over long periods of time (up to 10 or more years),
> because hash- and signature algorithms in it will get weak 
> and certificates
> expire. Archive service provider possibly could therefore 
> repudiate this
> acknowledgement after lets say 20 or 30 years if he wants to. 
> Sending signed acknowledgement to another service provider who has to
> archive it would leed us to recursive and in effect very 
> complex solutions.

[LH] Can't we imagine a TAA sending signed-notification each time the precedent one becomes invalid ? I see TAA as trusted authority, then I can believe that it must send me notification when new ones are needed.

> Therefore we prefer other strategies like protocols and 
> external audits of
> archive service providers to avoid successful repudiation of delivery.

[LH] Not sure that I understand your words. " avoid succesfull repudiation of delivery" means "avoid sucessfull repudiation of reception"? What we need I think is to be sure that the data send are well archived. Am I wrong ?

> Last but not least it would not be acceptable for users that 
> he must store
> signed acknoledgements for every (maybe little) document he 
> delivered to an
> archive service provider. If he wants to avoid to store 
> documents by using
> an archive provider and has to store signed acknoledgements - 
> were is the
> benefit?

[LH] With the idea of sending signed notification when needed, user (of TAA) only get one thing from the TAA, as with the acknoledgement.

> Storing a little index like a hash value or an integer should 
> be sufficient
> to retrieve archived documents. 

[LH] that little index or hash value couldn't be in the signed-notification ?

---

From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
Date: Thu, 16 Dec 2004 16:23:03 +0100

Peter,
my remarks/questions below

Loïc

> > I think these must be signed by the LTA in order to give 
> submitter an evidence that he sent data to LTA.
[LH]I my view, a LTA was an trusted authority, then could be able to deliver signed-notification. (analogy whith TSA). Am I really wrong ? If it's the case, and if you have the time, could you clear my mind ?

> > Nearly End of duration period of archive must be provided 
> to submitter, in order to let him change the duration if needed.
> > 
[LH] I just had a problem with this. A the end of the archivation period, (if it's 30 years e.g.) how the user know that it is the end ?
Must only the user deal with that ?

> > 
> > §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
[LH] As you can read, my english is poor compare to yours. What I wanted to say is that an LTA could not provide means for confidentiality.
Confidentiality could be part of the front end of the service, no?

Thank you

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 16 Dec 2004 17:26:18 +0100 (MET)

> [LH]I my view, a LTA was an trusted authority, then could be able to deliver signed-notification. (analogy whith TSA). Am I really wrong ? If it's the case, and if you have the time, could you clea…

That was also my position (water below), i.e. an service where you don't split
between the backend of archiving and a front end that delivers
an attestation. 

I don't thino you are wrong, you just use TWO services one behind
each other in a particular configuration, hydrogen+oxygen 
but you can have oxygen+carbon, this gives something else, also good for
plants.  The analogy stops here, because I am not saying that you need
boths, since otherwise plants won't grow. :-)

but you can have different type of USERS and SERVICES, it depends
on where you put responsibilities. And sometime you need a 'NOTARY'
in between. 

> Must only the user deal with that ?

Well, a user can count? Whether a user is informed about a deletion, seems to
me an independant service, informing *THE USER* after 30 years
may be difficult anyway. what seems important for the protocol is
that the user can be identified, i.e. one has enough redundant information
about who owns or may own or may retrieve the info, this may be for example
the court of city, etc. 

> Confidentiality could be part of the front end of the service, no?

Or the user: As far as I know, confidentiality with crypto means is never
supposed to last TOO long. An example: Would you think that a company that
hold a patent and recipe for a well know brown coloured drink would store
the information at an external archiver and transfer the information using
the Internet? 

regards
Peter

---

From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
Date: Fri, 17 Dec 2004 10:19:14 +0100

Peter,

See my comments hereafter:

> > [LH]I my view, a LTA was an trusted authority, then could 
> be able to deliver signed-notification. (analogy whith TSA). 
> Am I really wrong ? If it's the case, and if you have the 
> time, could you clear my mind ?
> 
> 
[LH] I need there an explanation what's a 'NOTARY' in this case ?

> 
> > [LH] I just had a problem with this. A the end of the 
> archivation period, (if it's 30 years e.g.) how the user know 
> that it is the end ?
> Well, a user can count? 
[LH] Well I guess so.

>Whether a user is informed about a 
> deletion, seems to
[LH] I agree, you're right.

> > [LH] As you can read, my english is poor compare to yours. 
> What I wanted to say is that an LTA could not provide means 
> for confidentiality.

[LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think.
Furthermore, I'm not sure I understand what you say...
Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ?

> Peter

Thank you,
Loïc

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 17 Dec 2004 14:18:16 +0100 (MET)

> [LH] I need there an explanation what's a 'NOTARY' in this case ?
*My* interpretation is: The 'notarisation middleperson' has a contract
with some archiving service provider or operates its own boxes to
store data. The interface to this box is secured with whatever way between
the 'notarisation service' and the box. 

on the other side, janus has clients that need some 'attestation',
in order to add this to a 'dossier' or not.  

...

> [LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think.

I think there is no disagreement; there different situations. There
is some desire from the client to have a particular level of confidentiality,
and the service proposes some way to respect this. This can be that the
serice says: you have to encrypt your data by yourself, we do our best
not to communicate to others but ... (I am not saying what I'd do
as a customer in this case). 

But even that artist data may be public, it may not mean that everybody has
a total access to the data *and* the way they are stored. The operator
may choose a bunker, which as a side effect ensures *some* confidentiality,
although this is not its main purpose. 

> Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ?
I think we agree, but to be sure: 

Since there are different layers and services, some parts may contribute to 
onfidentiality, others do not. The back back end stores data, the meaning of
the data may be pretty undefined there, i.e. there may not be many requirements for
the data to reveal something about the information they represent (it could be
encrypted docs, or pieces). 

An operator provides some means not to operate in a totally open environment,
but that's just a common sense or defense in depth behaviour.

/P

Date: Fri, 17 Dec 2004 14:18:16 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Cc: [email-masked]
Sender: [email-masked]

> [LH] I need there an explanation what's a 'NOTARY' in this case ?
*My* interpretation is: The 'notarisation middleperson' has a contract
with some archiving service provider or operates its own boxes to
store data. The interface to this box is secured with whatever way between
the 'notarisation service' and the box. 

on the other side, janus has clients that need some 'attestation',
in order to add this to a 'dossier' or not.  

...

> [LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think.

I think there is no disagreement; there different situations. There
is some desire from the client to have a particular level of confidentiality,
and the service proposes some way to respect this. This can be that the
serice says: you have to encrypt your data by yourself, we do our best
not to communicate to others but ... (I am not saying what I'd do
as a customer in this case). 

But even that artist data may be public, it may not mean that everybody has
a total access to the data *and* the way they are stored. The operator
may choose a bunker, which as a side effect ensures *some* confidentiality,
although this is not its main purpose. 

> Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ?
I think we agree, but to be sure: 

Since there are different layers and services, some parts may contribute to 
onfidentiality, others do not. The back back end stores data, the meaning of
the data may be pretty undefined there, i.e. there may not be many requirements for
the data to reveal something about the information they represent (it could be
encrypted docs, or pieces). 

An operator provides some means not to operate in a totally open environment,
but that's just a common sense or defense in depth behaviour.

/P

Content-class: urn:content-classes:message
Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Date: Fri, 17 Dec 2004 10:19:14 +0100
From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Peter,

[LH] Well I guess so.

Thank you,
Loïc

Date: Thu, 16 Dec 2004 17:26:18 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Cc: [email-masked]
Sender: [email-masked]

regards
Peter

Content-class: urn:content-classes:message
Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Date: Thu, 16 Dec 2004 16:23:03 +0100
From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

Loïc

Thank you

Content-class: urn:content-classes:message
Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Date: Thu, 16 Dec 2004 15:57:22 +0100
From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Loïc 

Date: Mon, 13 Dec 2004 17:58:31 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Sender: [email-masked]

loic and Ernst,

> Ernst.

From: <[email-masked]>
To: <[email-masked]>
Subject: AW: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Date: Mon, 13 Dec 2004 17:56:15 +0100
Sender: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von HOUSSIER Loic RD-MAPS-ISS
> Gesendet: Montag, 13. Dezember 2004 16:32
> An: [email-masked]
> Betreff: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
> 
> 
>  Hello,
> 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.
> 
Be welcome. Your Questions are not new, but not stupid.
> What the need of unsigned acknowledgment?

In an inhouse environment LTA is a service for an application system. E.g.
inhouse environment is a hospital, LTA is document management or archive
system and application system is a medical system used for generation of
medical documents and signing them by doctors. 
In this case only evidence records are needed to verify, that archived
documents existed at a certain point in past - e.g. before signature and
hash-algorithms used in it got weak or certificates in it were revoked.
Acknoledgement is useful to have an indication, that storing was accepted
and successful. But no proof for document delivery is needed, therefore no
signed acknoledgements are needed.

If archive service is an external by a service provider, proof of delivery
using a signed acknowledgement might be helpful. Problem is, that signed
acknowledgement is valid only a relatively short time. It will loose its
value of evidence over long periods of time (up to 10 or more years),
because hash- and signature algorithms in it will get weak and certificates
expire. Archive service provider possibly could therefore repudiate this
acknowledgement after lets say 20 or 30 years if he wants to. 
Sending signed acknowledgement to another service provider who has to
archive it would leed us to recursive and in effect very complex solutions.
Therefore we prefer other strategies like protocols and external audits of
archive service providers to avoid successful repudiation of delivery.
 
Last but not least it would not be acceptable for users that he must store
signed acknoledgements for every (maybe little) document he delivered to an
archive service provider. If he wants to avoid to store documents by using
an archive provider and has to store signed acknoledgements - were is the
benefit?
Storing a little index like a hash value or an integer should be sufficient
to retrieve archived documents. 

Content-class: urn:content-classes:message
Subject: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
Date: Mon, 13 Dec 2004 16:32:12 +0100
From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

 Hello,

§4.1.1 

§4.2.1

§4.5.1

Well I think that's all.

Regards,

Loïc HOUSSIER

Loïc HOUSSIER
France Telecom/Division R&D/MAPS/NSS 
Ingénieur recherche et développement
38-40, rue du Général Leclerc 
92794 Issy Moulineaux Cedex 9 
Tel: +33 (0)1 45 29 58 08 
Fax: +33 (0)1 45 29 65 19

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ernst G Giessmann
Envoyé : vendredi 10 décembre 2004 14:56
À : Peter Sylvester
Cc : [email-masked]
Objet : Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt

...

Regards,
Ernst.

Date: Fri, 10 Dec 2004 14:55:49 +0100
From: Ernst G Giessmann <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt
Sender: [email-masked]

...

Regards,
Ernst.

Date: Fri, 10 Dec 2004 14:07:32 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

cc-recipients can stop reading here.

----- Begin Included Message -----

Date: Sat, 02 Oct 2004 19:32:02 -0700
From: Larry Masinter <[email-masked]>
Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt
To: "'Denis Pinkas'" <[email-masked]>
Cc: [email-masked]

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?

----- End Included Message -----

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: Meeting minutes
Date: Thu, 2 Dec 2004 06:45:43 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0018_01C4D83A.8B9977D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Wallace: WG status and Archive Requirements document status briefings

- Abandoned aggressive schedule

- Three working group documents in progress: Archive Requirements document,
ERS and Notary document

- Agreement: Requirements document can assert that both crypto and
non-crypto are ok, but the WG work will focus on crypto mechanisms.  (SC:
question what about 2 of 2 with a random stream for XOR - will that meet the
requirement?)

- What is Archive Policy?  Is this recertification/timing policy.  Timing
and mechanism (signature based or hash based time stamp) and access control
and access policy.  Who is allowed to change archivation period is access
control policy?

Masinter: Notary Services discussion

- Definition of notary debate, name being changed to data certification and
validation services

- Went through the document

- Can a human notary use the document to perform their services

- Trials in CA on electronic notary.  We do not know what it is: electronic
assistance to notary, replacement of notary.

- Went through use cases of human notary and how electronic notary will do
it.

- Specific workflows in the Notary document

- DVCS is proposed as a place to build on.  Is there any prohibition on
moving it from PKIX to LTANS.  PKIX mail list should be asked.  It seems to
be experimental RFC and hence ok.

- How we got to data certification from notary?

- Long term trusted third party certification

- Debate with Chokhani on Archiving Vs. Notary.  Not sure what the
conclusion.

- Russ: Are you happy with the outcome.

- Larry: Seem to be happy with single service that offers archival and
notary.  He felts that they go hand in hand in the sense that there is no
benefit to electronic notary without long temr archive.

- Carl calls on OASIS and W3 - No response.

- Collapse the archive and notary requirements document into one.

- Russ: When will the documents be coming to IESG for approval?

- Carl: Most likely not before Minneapolis.  Need WG consensus first.

------=_NextPart_000_0018_01C4D83A.8B9977D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Meeting minutes</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT FACE=3D"Arial">Wallace: WG status and Archive Requirements =
document status briefings</FONT>
</P>

<P><FONT FACE=3D"Arial">- Abandoned aggressive schedule</FONT>
</P>

<P><FONT FACE=3D"Arial">- Three working group documents in progress: =
Archive Requirements document, ERS and Notary document</FONT>
</P>

<P><FONT FACE=3D"Arial">- Agreement: Requirements document can assert =
that both crypto and non-crypto are ok, but the WG work will focus on =
crypto mechanisms.&nbsp; (SC: question what about 2 of 2 with a random =
stream for XOR &#8211; will that meet the requirement?)</FONT></P>

<P><FONT FACE=3D"Arial">- What is Archive Policy?&nbsp; Is this =
recertification/timing policy.&nbsp; Timing and mechanism (signature =
based or hash based time stamp) and access control and access =
policy.&nbsp; Who is allowed to change archivation period is access =
control policy?</FONT></P>

<P><FONT FACE=3D"Arial">Masinter: Notary Services discussion</FONT>
</P>

<P><FONT FACE=3D"Arial">- Definition of notary debate, name being =
changed to data certification and validation services</FONT>
</P>

<P><FONT FACE=3D"Arial">- Went through the document</FONT>
</P>

<P><FONT FACE=3D"Arial">- Can a human notary use the document to perform =
their services</FONT>
</P>

<P><FONT FACE=3D"Arial">- Trials in CA on electronic notary.&nbsp; We do =
not know what it is: electronic assistance to notary, replacement of =
notary.</FONT></P>

<P><FONT FACE=3D"Arial">- Went through use cases of human notary and how =
electronic notary will do it.</FONT>
</P>

<P><FONT FACE=3D"Arial">- Specific workflows in the Notary =
document</FONT>
</P>

<P><FONT FACE=3D"Arial">- DVCS is proposed as a place to build on.&nbsp; =
Is there any prohibition on moving it from PKIX to LTANS.&nbsp; PKIX =
mail list should be asked.&nbsp; It seems to be experimental RFC and =
hence ok.</FONT></P>

<P><FONT FACE=3D"Arial">- How we got to data certification from =
notary?</FONT>
</P>

<P><FONT FACE=3D"Arial">- Long term trusted third party =
certification</FONT>
</P>

<P><FONT FACE=3D"Arial">- Debate with Chokhani on Archiving Vs. =
Notary.&nbsp; Not sure what the conclusion.</FONT>
</P>

<P><FONT FACE=3D"Arial">- Russ: Are you happy with the outcome.</FONT>
</P>

<P><FONT FACE=3D"Arial">- Larry: Seem to be happy with single service =
that offers archival and notary.&nbsp; He felts that they go hand in =
hand in the sense that there is no benefit to electronic notary without =
long temr archive.</FONT></P>

<P><FONT FACE=3D"Arial">- Carl calls on OASIS and W3 &#8211; No =
response.</FONT>
</P>

<P><FONT FACE=3D"Arial">- Collapse the archive and notary requirements =
document into one.</FONT>
</P>

<P><FONT FACE=3D"Arial">- Russ: When will the documents be coming to =
IESG for approval?</FONT>
</P>

<P><FONT FACE=3D"Arial">- Carl: Most likely not before =
Minneapolis.&nbsp; Need WG consensus first.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0018_01C4D83A.8B9977D0--