Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 15 Jan 2007 15:59:02 +0100

I said in an earlier e-mail: “The WG has to justify why it would not fulfill its needs”. 
Carl has provided interesting information to explain the differences with ISO ISO-18014-3 
and why ERS is different. The main advantage is the use of “ordinary” time-stamps rather 
than time-stamps with specific extensions. However, this information should not be lost 
and be used to write an informative annex.
 
There are indeed much more important topics. 

ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn’it ?
 
However, many of the requirements that are present in the requirements document 
are not met by the current ERS draft. 
 
Here are a few examples :
1. ltans-reqs-10 defines an Archival Period as “The period during which an archiveddata object is preserved by a long-term archive service”. How may a long term-archive service be held responsible of storing the data during that time-period, since the information to know the time period is not present in the ER ?

2. ltans-reqs-10 defines a Cryptographic Maintenance Policy. There is no corresponding element in ERS. How can a long term-archive service know which maintenance to apply, since the information to perform the maintenance correctly is not present in ER ?
3. ltans-reqs-10 states on page 7: A long-term archive service provides evidence that may be used to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time. The ER is supposed to be the basic piece of data to support that evidence. However, it is not signed by the long term-archive service, thus it cannot be used “to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time”.

4. ltans-reqs-10 adds on page 7: “Additionally, the evidence identifies the LTA(s) that have participated in the preservation of the archived data object”. However, ER does not contain the names of the LTA(s) that have participated in the preservation of the archived data object.

5. ltans-reqs-10 states on page 9: “A long-term archive service must operate in accordance with a long-term archive service policy that defines characteristics of the implementation of the long-term archive service”. However, ER does not contain a data item to support the “long-term archive service policy”. 

6. ltans-reqs-10 adds on page 10: “ Over the course of many years, the policies under which an LTA operates may undergo modification.  Thus, an evidence record may feature multiple indications of policies active at various points during the life of an archived data object.” However, the ER does not contain such an information.
7. ltans-reqs-10 states on page 11: “A long-term archive service must be capable of providing evidence that can be used to demonstrate the integrity of data for which it is responsible from the time it received the data until the expiration of the archival period of the data”. However, no data item is specified in ER to provide this evidence.

This means that much work is still needed on the document to fulfill the requirements.
 
Now, let us see what should be done. The following is obviously an unpolished strawman proposal.
 
In order to reduce the number of time stamps, it is necessary to be able to aggregate data 
before applying a time stamp on it. For doing it, the following structure (close to the 
structure of ArchiveTimeStamp, but different) would fulfill the need).
 
   TimeStampedNode ::= SEQUENCE {
     digestAlgorithm        [0] AlgorithmIdentifier OPTIONAL,
     archivalPolicy             ArchivalPolicy,
     archivalTimePeriod         ArchivalTimePeriod,
     cryptoMaintenancePolicy    CryptoMaintenancePolicy,
     reducedHashtree            SEQUENCE OF PartialHashtree,
     timeStamp                  TimeStampToken }
 
   PartialHashtree ::= SEQUENCE OF OCTET STRING

   ArchivalPolicy::= OBJECT IDENTIFIER

   ArchivalTimePeriod ::= SEQUENCE {
        notBefore      GeneralizedTime,
        notAfter       GeneralizedTime }

CryptoMaintenancePolicy would need more work to be defined, but basically 
would contain a sequence of algorithm identifiers with their parameters.
 
The CryptoMaintenancePolicy applies to the data in the tree and to the crypto of 
the time stamp token.
 
The hash included in the TimeStampToken is computed on the reducedHashtree element.
 
If this structure is signed by an agent from an archival service, then it can be used 
to demonstrate that a given agent from an LTA has accepted to archive, under a given 
policy for a given time period, the data items that are under the hash tree.
 
This means that TimeStampedNode must be the eContent of a CMS message signed by 
an LTA agent in order to form a SignedNode.
 
Later on, the same, another or more LTA agents may need to add some other data to 
a signed Node, without loosing the previous time-stamp and signature. 
 
This leads to the following structure:
 
   EvidenceNode ::= SEQUENCE {
      version                        INTEGER { v1(1) } ,
      digestAlgorithms               SEQUENCE OF AlgorithmIdentifier,
      archivalPolicy                 ArchivalPolicy,
      archivalTimePeriod             ArchivalTimePeriod,
      cryptoMaintenancePolicy        CryptoMaintenancePolicy,
      evidenceRecord                 EvidenceRecord,
                                     -- the evidence record that serves 
                                     -- for the construction
      signedNodeSequence             SignedNodeSequence   OPTIONAL,
                                     -- the elements that are added 
                                     -- to the previous evidence
      timeStamp                      TimeStampToken }
 
with:
 
   signedNodeSequence ::= SEQUENCE OF SignedNode
 
The CryptoMaintenancePolicy applies to the previous evidence record, to all 
the data that are in the tree and to the crypto of the time stamp token.
 
The hash included in the TimeStampToken is computed on the concatenation of the 
evidenceRecord element and of the signedNodeSequence element.
 
This means that EvidenceNode must be the eContent of a CMS message signed by 
an LTA agent in order to form an EvidenceRecord.

This new proposal fulfills the seven requirements mentioned here above.

Denis

Tony,

I think Denis should provide additional details when calling for a working group item to be dropped, especially when making this request this late in the process with non-freely available documents as the basis.  However, I'll try to make the case in the other direction.

I don't think it's simply a case of too many options that require profiling.  One motivation often cited during the development of ERS is support for aggregations of data.  This is represented in ERS via the reducedHashtree field in the ArchiveTimeStamp structure.  This field and the related ArchiveTimeStampChain and ArchiveTimeStampSequence structures allow handling of the aggregation when the initial timestamp is generated, when simple timestamp renewal is required as well as when simple timestamp renewal is not sufficient and the original data must be hashed again.

The ISO spec uses the ExtRenewal extension for timestamp renewal.  This is roughly analogous to the timestamp renewal feature in ERS.  However, there does not seem to be sufficient support for cases where the hash algorithm is updated and the original data must be rehashed.  In ERS, when a hash algorithm update is necessary, the preceding timestamp tokens are hashed along with the original data.  In the ISO spec, an existing timestamp token is presented for renewal but the original data is not.  It may be possible to make this work using the extHash extension, but I don't see any description of this in the current spec (nor do I see any text that describes verification of the ExtRenewal extension).  I don't follow how the aggregation mechanisms in the ISO spec can be used to aggregate data for the initial timestamp well enough to compare them to ERS.  

ERS support for aggregation is more clearly stated and ERS provides more complete handling of renewal operations.  For these reasons, I think we should proceed with ERS instead of trying to enhance the ISO spec.

Carl

From: Tony Capel [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 11:04 AM
To: 'Carl Wallace'; 'Denis Pinkas'; [email-masked]
Cc: [email-masked]; 'Tobias Gondrom'; 'Russ Housley'
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl:

I think Denis asks simply for the justification for the introduction of new technology to solve a problem which may already be solved with an existing ISO standard (which has already been published and is presumably more mature than what is being proposed).

Denis notes (in his previous comment) that perhaps the ISO standard offers too many options and that perhaps a Profile of this ISO standard might be published as an RFC to tailor the ISO standard for the specific application(s) you have in mind.  In such a case the RFC should profile (see ISO/IEC TR10000) the ISO standard and not introduce new technology.

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: January 11, 2007 10:16 AM
To: Denis Pinkas; [email-masked]
Cc: [email-masked]; Tobias Gondrom; Russ Housley
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

My response wasn't a reversal of the question but a request for details.  Folks on the list have previously discussed these specifications, including their use within an EvidenceRecord.  You made a sweeping comment that lacked any details and called for fairly drastic measures.  I simply asked for justification.

From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 9:46 AM
To: Carl Wallace; [email-masked]
Cc: [email-masked]; Russ Housley; Tobias Gondrom
Subject: Re: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Carl,

Please do not reverse the question. ISO 18014-3 already exists. The WG has to justify why it would not fulfill its needs.
I will refine my question: Why is a profile of ISO 18014-3 not adequate to fulfill the needs ?
A profile would make sense, since ISO 18014-3 has many options.

Denis

---

From: "todd glassey" <[email-masked]>
Date: Mon, 15 Jan 2007 07:35:02 -0800

Denis
  ----- Original Message ----- 
  From: Denis Pinkas 
  To: [email-masked] 
  Cc: [email-masked] ; 'Russ Housley' 
  Sent: Monday, January 15, 2007 6:59 AM
  Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd

  I said in an earlier e-mail: "The WG has to justify why it would not fulfill its needs". 

  and why ERS is different. The main advantage is the use of "ordinary" time-stamps rather 

  ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?

1. ltans-reqs-10 defines an Archival Period as "The period during which an archiveddata object is preserved by a long-term archive service". How may a long term-archive service be held responsible of storing the data during that time-period, since the information to know the time period is not present in the ER ? Denis this is one of the key disagreement's you and I have with timestamping. There is NO need to keep that information online or mechanically provable in a methodology that remains consistant with any taks than proving the signature at the time of its signing in the technology available at the time of the signing. 2. ltans-reqs-10 defines a Cr!
 yp!
tographic Maintenance Policy. There is no corresponding element in ERS. How can a long term-archive service know which maintenance to apply, since the information to perform the maintenance correctly is not present in ER ?
3. ltans-reqs-10 states on page 7: A long-term archive service provides evidence that may be used to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time. The ER is supposed to be the basic piece of data to support that evidence. However, it is not signed by the long term-archive service, thus it cannot be used "to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time".4. ltans-reqs-10 adds on page 7: "Additionally, the evidence identifies the LTA(s) that have participated in the preservation of the archived data object". However, ER does not contain the names of the LTA(s) that have participated in the preservation of the archived data object.5. ltans-reqs-10 states on page 9: "A long-term archive service must operate in accordance with a long-term archive service policy that defines characteristics of the implementation of the long-term archive service". However, ER does not contain a data item to support the "long-term archive service policy". There  is no specification in the protocol drafts that these 'policies and control features' be a part of the mechanical processes of the LTANS service Denis...6. ltans-reqs-10 adds on page 10: " Over the course of many years, the policies under which an LTA operates may undergo modification.  Thus, an evidence record may feature multiple indications of policies active at various points during the life of an archived data object." However, the ER does not contain such an information.
7. ltans-reqs-10 states on page 11: "A long-term archive service must be capable of providing evidence that can be used to demonstrate the integrity of data for which it is responsible from the time it received the data until the expiration of the archival period of the data". However, no data item is specified in ER to provide this evidence.This means that much work is still needed on the document to fulfill the requirements.

   

                                       -- for the construction

  with:

  Denis

------------------------------------------------------------------------------

  Tony,

  Carl

----------------------------------------------------------------------------

    Carl:

    Tony

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
    Sent: January 11, 2007 10:16 AM
    To: Denis Pinkas; [email-masked]
    Cc: [email-masked]; Tobias Gondrom; Russ Housley
    Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

--------------------------------------------------------------------------

      Carl,

      Denis

------------------------------------------------------------------------------