Subject: Re: Comments on LTANS documents

From: Peter Sylvester <[email-masked]>
Date: Thu, 22 Jul 2004 16:19:17 +0200 (MEST)

> Comments on LTANS documents
> 
> I have only been recently aware of the existence of the LTANS working group. 

You are pardonned. Welcome on board. 

I am not answering on behalf of the authors nor do my comments
necessarily reflect the authors' opinions.

> While I believe that work should be done along an archive service, the 
> current documents still do not provide the right presentation of the 
> problem, nor the right answers. 27 comments follow.

I think the participants of this group would like to read 
your presentation of the problem and your ideas for an answer. 

Your are probably aware of work that has been done
be various people in that area in the IETF and also outside. 
Some of the work is referenced in the ltans web server,
and people are discovering other related work regularily. 

The contributors on this list spend some time to identify
common elements in order to fold out something which is 
acceptable to some large community, otherwise it would
be 'YAS' (yet another standard). 

Well, then:

> Comments on draft-ietf-ltans-requs-01.txt
> 
> 1. Since the document is a requirements document, it should use a 
> terminology in accordance with RFC 2119 and use the following key words: 
> "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
> NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

At the current state I see the requirements documents as an attempt
to get a common understanding of the problem to be solved, there
are examples where the right usage of such terms is difficult, at
least for non native english people, your point 16 seems to be an
example (to me). But there will certainly a next round.  

> 2. The document is using the word TAA. the T is for "Trusted". As soon as 
> this word "trust" is being used, then it is necessary to say *WHO trusts 
> SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be 
> used instead, since AA already means Attribute Authority.
> 
> As far as the WHO is concerned, there are:
> 
>     1) the person or the application who did the deposit,
> 
>     2) the persons or the applications allowed to retrieve the data
>        (not necessarily the same as 1))
> 
>     3) the persons or the applications wishing to make sure that
>        some data originates from a given Archiving Unit (Arch-Unit)
>        under the responsibility of a given Archiving Authority
>        (Arch-A) and has been stored by it at a given point of time.

Could you write this a little bit simpler for me, I am not sure 
whether I understand the second line of point 3. Is this a relying party
which 1) has to convince that some required archiving had been done?  

You have introduced a term Arch-unit without giving a definition.

> The difference between the above "players" should be introduced in the 
> documents.

I think there is some overlap with the existing players mentioned
as Arbitrator, Submitter, Retriever, Originator. And there may be
others, judge, software provider, operator, configurator, system maintainer, ...
 
> 
> As far as the WHAT is concerned, each of the previous players is trusting 
> the Arch-A for a different purpose which should be detailed.

I think that all players want that the archival service stores the data 
correctly and can make it available to whoever is authorized, or do I 
miss something? Trust is always a problematic word.  

> 3. When a person or an application makes deposit, it is of primary 
> importance that it gets back a "proof of deposit" from an Arch-Unit. In case 
> the deposited data would be lost, then the Arch-A would be responsible from 
> the loss.

I am not sure that we are all thinkinn about the same thing. 

There is a difference between the technical element of a 'receipt' or 'acknowledge' 
of an operation, which is meantioned in the req text, and something
which can have this receipt as a part, which can be considered by the
participating legal entities as sufficiently binding to whatever.

Data are submitted, and a receipt is obtained containing at least a
reference allowing to obtain the data. All security additions are
in outside this but are obviously necessary for various requierments.

> Note that AFNOR has done some work to standardize different kinds of proof, 
> including a "proof of deposit" with a full description of the data structure 
> of that proof using ASN.1. This work should be published soon as an AFNOR 
> Experimental Standard.
> 
> The concept of a "proof of deposit" should be introduced in the documents.

Feel free to contribute a definition. 

> 4. The deposit is made for a given archiving time period. This period cannot 
> be shortened, unless the person who made the deposit signs a document 
> allowing the Arch-A to do so. In case the person who did the deposit 
> complains later on, then the Arch-A would be able to demonstrate that the 
> archiving period has been shortened.
> 
> This concept should be introduced in the documents.

Your example is only a special case of operations which are performed in more
or less exceptional cases. A client may terminate a contract and ask to
transfer all his data to some other provider for example, including 
a situation as in your comment 15.

Whether a period can be shortend or not is not a question of whether
a client has signed it, it is a question of whether this is possible
at all inside the policy, it depends on the needs of relying parties. 

Anyway, the archiving service may itself need to archive of all transactions,
to have evidence about what had been performed.

> 5. The documents states that "a long-term archive service provides material 
> needed to demonstrate the existence and integrity of data object". This 
> definition is far from sufficient, since, it is missing two dimensions:
> 
>      1) the fact to demonstrate that the archive was made
>        *at a given time*,
> 
>      2) the fact to demonstrate that the archived data originates
>         *from a given Arch-Unit and Arch-A*.

How to you link these with the existing text. These dimensions
are to me optional and not required in all contexts.  

> 
> A better definition is present in section 4.3.1.

> 6. A major component which is not sufficiently described is the Archive 
> Policy (Arch-Pol). The components of an Arch-Pol should be first identified, 
> before attempting to define any data structure or protocol. Section 4.4.2 
> should grow from 3 lines to one or two pages and should be introduced much 
> earlier in the document.

If you have some contributions about what things should be in a policy,
please contribute. Reading your comment 3, you probably have that
precious knowledge, since their is an protocol containing data structures
etc.

> 7. One of the several aspects to be developed about the Arch-Pol would be 
> how to relate the Arch-Pol under which the document is retrieved 30 years 
> later to the initial Arch-Pol under which the document has be deposited. 
>
> These policies cannot be the same, since, for example Time-Stamping 
> Authorities used 30 years later could not be known initially. There may be a 
> chain of Arch-Pol to consider.

I am not sure whether we talk about the same idea of the service to be 
provided.

On of the first things to do is to agree on the same understanding of what
means policy. I see the Policy under which a document is archived and accessed
is mainly a configuration including default rules and parameters for
processing, and maybe indications/references to rules, documents describing
the policy of required feature. Other wording are: 
Requirements policy and derived operational policy. 

If something changes through the lifetime of the archived data, there
are several possibilities. Either, the archive provider performs permitted
changes to a policy and keeps track of them, and/or initiated a transfer
of the re-achived data to itself. 

> 8. One of the several aspects to be developed about the Arch-Pol would be 
> the policy for the "automatic" maintenance of archived data.
See above. 
 
> One obvious possibility is to time-stamp the archived data at the time of 
> the deposit. One or more time-stamps tokens (TST) may be applied (more than 
> one time-stamp token is not addressed in the documents).

Aren't you commenting the requirements doc here? This sounds more a
comment to either the ERS or to the not yet available protocol doc.
or some best pracise doc on how to manage and create evidence under
the assumption the only existing security meachnism are digital signatures.
> 
> For the maintenance of these TSTs, there are then two options:
> 
>      a) apply a new TST before the end of the validity period of the
>         TSU certificate and then capture the CRL of the CA which has
>         produced the TSU certificate in order to demonstrate that the
>         TSU certificate was not revoked at the time the new TST was
>         applied (this point is not addressed in any of the current
>         two documents).
> 
>      b) rely on the Certificate Policy of the CA which has produced
>         the TSU certificate, which will impose a specific protection for
>         the TSU private key (key generation mandatory within a security
>         module and no key export possible, mandatory zeroization of the
>         private key at the end of the private key usage period. Once
>         the TSU certificate has expired, then the private key from the
>         TSU cannot be compromised anymore, except using brute force
>         attacks. In practice, the Archiving Unit will need to capture
>         the revocation status of the TSU certificate (usually a CRL),
>         once the TSU certificate has expired, in order to demonstrate
>         that the TSU certificate was not revoked at the end of the
>         validity period of the TSU certificate (this point is not
>         addressed in any of the current two documents).

Such a discussion sounds premature, it is by no means obvious that
relying on time stamping results requires signature validation for example. 

Anyway: relying on single potential point of failure, i.e. a broken chain
doesn't seem to be an elegant approach for long term. redundancy,
defense in depth techniques are needed. 
 
> 
> 9. When an archived data is retrieved, with the proof it was archived at a 
> given time, then the proof that the last TST is still valid has to be 
> produced. In practice this means (for case a) above) that the *current* CRL 
> of the last TSU has to be produced (this point is not addressed in any of 
> the current two documents).
Another detail to early. you assume a particular implementation and
technology.

> 10. As noted "notarization" has many different definitions and this term 
> should not be used at all.

the term 'Notarization' is not used in the doc.
there are two occurences of the word 'notary service' refering to other
documents to be developed by this working group. And since an appropriate
definition will be given the 

Archiving also has many different definitions, some of them have few things
to do of what is intende here. ... the word that I looked for is 'Archive Time Stamp'.

> 11. Retrieving of data should be done using information given in the "proof 
> of deposit".

'should' ?? 

One should be able to retrieve for example 'all data
for a particular client' without referencing all the stored items.
And 30 years later, I may only have a vague idea.

IMO a search protocol allows to retrieve publicaly available
'acknowledgement', the details of this are outside scope.
The actual retrieval must be done by such a reference.

The basic archival server is not required to
provide a sophisticated search facility. 

> 12. The document states: "it must be possible to authenticate requests and 
> responses". This is not the right requirement. A "proof of deposit" response 
> must be electronically signed. Some requests for shortening the archiving 
> time period must also be electronically signed. Authentication is not enough.
>

It would be good if you can distingusih between several things. You are
proposing some means that seems to be the one to cover different
security needs. 
 
See also my remarks 3.

The need of authenticity is IMO the right term here, electronic signature
is at best a means, unfortunately it has no final definition
(collection of time stamps of signed data etc is just one proposed
 way of adding evidence about authenticity.) 

We are not talking about digital signatures here. The 'client' can be
directly connected without an possible interference, then the ack
would not need any security envelope. As soon as the distance and
network changes, strong authentication methods may or may not be
needed, still a pure technical strong authentication. 

Question: Do you think that an archive service can operate, let's say
on top of http, i.e., the client prepares a request, and gets
(in your terms) a 'proof of deposit'? 

> 13. The documents states that "a long term archive service must be capable 
> of providing evidence records to support the long-term non repudiation of 
> data". Non-repudiation of data is not one of the possible variants of a non 
> repudiation service. Section 4.2 would need to be fully re-written.

What does your proposed 'proof of deposit' provide? 

What service does an electronic signature provide?

> 
> 
> 14. Transfer from one archive service to another one may only apply for the 
> same or compatible Archive Policies (Arch-Pol).

'may'? do you mean 'MUST'. 

> 15. Disclosing or not the archived data to the Arch-Unit is an interesting 
> topic. Three cases should be identified:
> 
>      1) the archived data is public data,
> 
>      2) the archived data is private data, and only a hash of it
>         is communicated,
> 
>      3) the archived data is private data, and only encrypted data
>         is communicated.
> 
> There is a difference between cases 2 and 3:
> 
> In case 2) the user who made the deposit needs to keep the clear text of the 
> deposited data.

Somehow this looks like extended time stamping to me, like the one in RFC 3029?

> In case 3) the user who made the deposit only needs to keep a private key 
> corresponding to the public key used to perform the encryption (which is not 
> what the second document is saying).
No, a key to decrypt, e.g. a session key for example. 

> 
> Only case 1) allows to perform self-maintenance of the validity of the 
> archived data in case a hash function originally used is becoming weak. But 
> what about the two other cases ? Some contact points should be given when 
> making the deposit, so that maintenance can be performed with the 
> cooperation of the person who did the deposit or of the persons allowed to 
> perform a retrieval.

A lot of information needs to be provided to an authentication
and authorisation service, customer handling, billing etc.
It is useful to consider some of such data as part of metadata
either of the data or the transaction, i.e. to have containers
in the data structure where such information can be carried
in an extensible way. 
 
You also need to provide (or not) information about what to do in case
of cessation of activity, the weakness of a hash function can simply provoke
a declaration: "We will cease out all activities under policies that
used a weak hash function". 

> 
> 16. The documents states "where groups of data objects are submitted, 
> non-repudiation proof [of what ?] must still be available for each archived 
> data separately". This is not a MUST. This MAY be a feature.

what mean MAY here? 

read this as your proposed 'proof of deposit'.

The requirement proposes that a client can group together archived
elements or elements to be archived and obtain evidence receipts 
for the group. 

If I understand your MAY I'd call them structured documents which are
always handled together, and the individual parts are not 
distingusihable by the service, and cannot be obtained individually.

> 17. The topic of the third paragraph security considerations section is 
> quite interesting. There is however no guidance to indicate how to deal with 
> that problem. Such a guidance should be provided.

Do you propose something else than selecting identifications that tend
to have some good redundancy or globality characteristics?
Note also that authentication methods, customer handling, authorisations
are outside of scope as far as I see.
 
> Comments on draft-ietf-ltans-ers-00.txt
> 
> 18. Since the requirements document is far from being stabilized, it is 
> rather premature to progress this document.

See my initial comments.  

> 19. If an encryption method is supported (section 5.1), it should first be 
> based on a public key certificate value rather than a public key value, 
> since public key certificates make easier much easier to find out what/where 
> is the corresponding private key which shall be used.
Why that? 

See your comment 18.

> 
> 
> 20. For the intellectual property statements, it should noted that some 
> companies have patents about hash-tree applied to Time-Stamping. If somebody 
> participating to this working group has or knows some patents along 
> hash-tree applied to Time-Stamping, it would be fair that this participant 
> informs us of any patent that would be related to the ERS document. This 
> point should be raised to all the participants of the WG session at the San 
> Diego meeting.

I have made a list of potentially relevant patents is available to
stimulate the discussion.

  http://ltans.edelweb.fr/patents.html

If some people know the actual status, ...

> 
> Comments on draft-ietf-notareqs-00.txt
> 
> 21. Since the document is a requirements document, it should use a 
> terminology in accordance with RFC 2119 and use the following key words: 
> "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
> NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
See above. 

> 
> 
> 22. The abstract does not provide yet a good summary of the content (and the 
> goals) of this document.

Note that we are not aiming to define something that electronically
does whatever a notary does. We are aiming IMO opinion to provide
a system that provides some service that can be operated/used
by different 'profession', but the primary goal is to determine
some technical behaviour, which can be OMO something like

- 'information reduction' to simplify work flows.
- 'provide time verifications'
- ...

> 23. The definition of notary from the terminology section is far too vague.
> Proposed definition inspired from section 3.2:
> 
> Notary: An officer whose duties are generally prescribed by the laws of a 
> country, who attests deeds, agreements and other instruments, in order to 
> give them authenticity.
> 
> When applied to agreements: a person who issues a document testifying that 
> all parties involved in the signature of an agreement understood and 
> received the whole information and consequences of the information being 
> signed by them; then applies his own signature on the signatures from the 
> other parties and finally provides the whole result to all the parties and 
> keeps at least one original.

This is a particular way how one particular activity is performed and attested on paper.
'Apply a signature in the signatures' means what on paper? 

> 24. Technically speaking, it is a scheme where someone applies a 
> counter-signature, with a specific meaning (i.e. specified in a commitment 
> type), on already present signatures. This is already covered in RFC 3126.

There are many things covered in existing texts. I could say that RFC 3029
already covers all needs for archiving, in a similar way as you could say that
RFC 3161 already covers timestamping. 
  
> 25. The definition of notary service is not correct as well.
Feel free to propose one that seems correct to you. 

I think I should read some of the patents that talk about electronic notaries.
 
> 26. The definition of seal from the terminology section is not appropriate. 
> A seal for many people is done using secret key technology. If to be kept, 
> define it a " Notary seal".
Sounds reasonable. 

> 27. The technical requirements from section 4 are not aligned with the text 
> from section 3.
Ther seems some work to be done. 

> Denis
Peter

---

From: Ernst G Giessmann <[email-masked]>
Date: Wed, 28 Jul 2004 17:12:00 +0200

Dear all,
I'm new on the LTANS list too.

Some remarks to Peter's reply to Denis (text shortened to save memory)

Peter Sylvester wrote:

....
> which 1) has to convince that some required archiving had been done?  

The players are similiar to the players in the signature game:
1 someone signs a document
2 someone receives the signed document
3 someone validates the signature of the document

Answering your question:
No, the relying party must not necessarily convinced by 1, and it may be
not sufficient to convince 3 that the archiving was done.
It is a person that proves that some given data was archived under given
conditions at a given time.
The target may be the fact of archiving but also the content archived or
the time of archiving.

> others, judge, software provider, operator, configurator, system maintainer, ...

I guess that the three roles Denis mentioned are a good starting point.
Do you think that there are other important roles?

> miss something? Trust is always a problematic word.  

The word "correctly" is problematic as well. S oit is necessary to have
a defined unambigous set of rules, conditions that the verification
gives always the some result.

> provide a sophisticated search facility. 

Agree. We must differentiate between searching and retrieving. But it is
important to identify unambigously the point of retrieval, otherwise you
may get two different documents from two different sources both claiming
that they are the archived documents.

> is at best a means, unfortunately it has no final definition
When a definition is finalized?
Let us stick for a while at the formats of RFC 3126.

> What service does an electronic signature provide?
It is a rhetoric question isn't it?

An electronic signature produced in accordance with RFC 3126
provides evidence that can be processed to get confidence that some
commitment has been explicitly endorsed under a signature policy, at
a given time, by a signer under an identifier, e.g., a name or a
pseudonym, and optionally a role.

>>     3) the archived data is private data, and only encrypted data
...
> No, a key to decrypt, e.g. a session key for example. 
Correct. It may be a private (asymmetric) key as well.

>  http://ltans.edelweb.fr/patents.html
Thank you.

I wish you a sucessfull meeting in San Diego.

Regards,
Ernst.

-- 
	Ernst G Giessmann
	T-Systems GmbH ITC-Security
	Goslarer Ufer 35, D-10589 Berlin
	phone:+49-30-3497-4342 mailto:[email-masked]