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

From: Carl Wallace <[email-masked]>
Date: Mon, 15 Jan 2007 10:46:01 -0500

Denis,
 
Thanks for the analysis.  Regarding: 
 
ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?
 
We've been proceeding with ERS + LTAP intended to meet the requirements, not
ERS in isolation.  Thus, some of the information you mentioned is addressed
at the protocol level, not in the evidence record.  I think this is
certainly true of items 1, 2 and 4.  For item 3, the service can provide the
evidence without contributing signatures to the evidence record.  It simply
has to be trusted to take the appropriate renewal actions at the right
times.  For item 7, the period is implied by the time in the innermost
timestamp and the outermost timestamp and the evidence record is itself the
evidence being provided.
 
For items 5 and 6, I agree that the ArchiveTimestamp is probably the best
place to represent the policies to meet this requirement.  Since these
values can change over time, they are not as easily represented in an outer
wrapper applied at the protocol level.  Perhaps the following:
 
   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
     policy          [1] OBJECT IDENTIFIER OPTIONAL,
     timeStamp       ContentInfo}

Using this structure, the policy would be asserted when a renewal is
performed.
 
Carl

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Monday, January 15, 2007 9:59 AM
	To: [email-masked]
	Cc: [email-masked]; 'Russ Housley'
	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". 

	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 archived
	data 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 Cryp!
	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". 
		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: "Denis Pinkas" <[email-masked]>
Date: Tue, 16 Jan 2007 09:27:08 +0100

Carl,

ERS + LTAP do not meet the requirements.

In order to understand LTAP, there is the need to wait until page 28, 
where the operations are only sketched :

- The ARCHIVE operation applies to "rawData and a messageDigest" 
   without any information on these two pieces of information and 
   their relationship, if any, with ERS.

 - The STATUS operation is hardly defined.

 - The EXPORT operation returns "data and metadata of the object"
   without any information on these two pieces of information and 
   their relationship, if any, with ERS.

 - The DELETE operation "returns the updated metadata (or nothing)" 
   without any information on this piece of information and its relationship, 
   if any, with ERS. 

The archival policy, the archival time period and the crypto maintenance policy are never mentioned. 
Since they are currently not part of ERS, they appear nowhere.

It is never mentioned that a response is signed. 

ERS + LTAP contain no signature from a LTA agent.

About the DELETE operation, what is worse is the following sentence: "Note that this does not mean that 
the server does not maintain a trace record of the delete operation". A trace record would not be sufficient. 
Deletion of an archive shall normally not happen, since the LTA is trusted to keep the data until the end of 
the archive period. A signed permission of deletion, by the owner of the data shall be given, before deletion 
can occur. This is mentioned nowhere in the document.

Once again, the current set of documents does not meet the requirements.

I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it.

Denis

Denis, 

  
We've been proceeding with ERS + LTAP intended to meet the requirements, not ERS in isolation.  Thus, some of the information you mentioned is addressed at the protocol level, not in the evidence record.  I think this is certainly true of items 1, 2 and 4.  For item 3, the service can provide the evidence without contributing signatures to the evidence record.  It simply has to be trusted to take the appropriate renewal actions at the right times.  For item 7, the period is implied by the time in the innermost timestamp and the outermost timestamp and the evidence record is itself the evidence being provided.
 
For items 5 and 6, I agree that the ArchiveTimestamp is probably the best place to represent the policies to meet this requirement.  Since these values can change over time, they are not as easily represented in an outer wrapper applied at the protocol level.  Perhaps the following:
 
Using this structure, the policy would be asserted when a renewal is performed. 
  
Carl 

        From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas 

        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. 

         
        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 archived 
        data 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 Cryp! 
        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". 
                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). 

         

        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. 

              digestAlgorithms               SEQUENCE OF AlgorithmIdentifier, 
                                             -- the evidence record that serves 
         
        with: 

        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 

        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 

                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.

                        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: "Denis Pinkas" <[email-masked]>
Date: Tue, 16 Jan 2007 16:31:38 +0100

Carl,

I will have lo leave the discussion here for a few days, since I need to attend different meetings.

This leaves you more time to look again at the arguments explained in my three e-mails
and to my proposal where the new proposed ASN.1 fulfils the LTANS requirements 
whereas ERS does not.

I simply reiterate my position:
 
 - neither ERS, nor LTAP, nor (ERS + LTAP) meet the requirements. 
 - ERS is not mature.
 - LTAP is not mature.
 - ARI is not mature.
 - validate is not mature.
 - ERS needs major revisions. 
 - ERS cannot be sent alone to the IESG.

Denis  

inline...

Sent: Tuesday, January 16, 2007 3:27 AM

Carl,

ERS + LTAP do not meet the requirements. 
[CRW] ERS is currently the focus.  Not LTAP. 

 <snip> 
The archival policy, the archival time period and the crypto maintenance policy are never mentioned. 
Since they are currently not part of ERS, they appear nowhere.
[CRW] "Policy" is cited throughout and is included in the RequestInformation structure.  "Archival policy" and "crypto maintenance policy" are not distinguished.  They should be, but not in ERS.

ERS + LTAP contain no signature from a LTA agent. 
[CRW] See the following in section 8: "These data are optionally encapsulated by CMS content types that provide for authentication and/or confidentiality, e.g.  SignedData or EnvelopedData."  

[CRW] This should be added.

I guess you reacted too quickly to my proposal from yesterday and you should pay more attention to it. 
[CRW] Most of your suggestions apply to a different document, in my opinion.  I do think you were correct w.r.t. inclusion of an indication of policy in the ArchiveTimeStamp layer.  Towards that end, my counter-proposal yesterday may serve us better if we exchange the optional OBJECT IDENTIFIER field for an optional Attributes field, where policy could be an instance:

   ArchiveTimeStamp ::= SEQUENCE { 
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, 
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, 
     attributes          [2] Attributes OPTIONAL, 
     timeStamp       ContentInfo} 

I think the other matters can and should be addressed in the context of LTAP.

Carl

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 16 Jan 2007 16:30:51 +0100

Peter,

You said:

>The details how a delete request is authenticated is outside of scope of 
>LTAP as well as management of ownerships etc.

Many aspects seem to be outside the scope of the document, whereas they should not..

>A trace record means: "At this place there had been some data which can 
>be described by (list of some metadata),
>they had been deleted (metadata about that fact)." It is not the backend 
>LTA that creates all these metedata,
>the frontend that authenticates the request prepares some of them. The 
>LTA does not make complicated decisions.

A trace record from the LTA would be insufficient in case of a dispute.

An LTA is providing a service for someone. An LTA has to be made responsible 
of its actions, and therfor must give back some proof for each deposit or for an addition 
to a former deposit.

In case the owner of the data decides to shorten the original archival time period 
(BTW mentioned nowhere in ERS or in LTAP), then the LTA must be able to present 
some proof of that will, otherwise the owner of the data could pretend that the archive 
was deleted by the LTA before the end of the original archival period.

(text deleted)

Denis                                                  

>Peter

---

From: "Tobias Gondrom" <[email-masked]>
Date: Tue, 16 Jan 2007 17:03:06 +0100

Denis,

Small comment: 

I agree with, that ARI and validate is not mature.

I agree that LTAP still needs some improvement for WGLC - though I
believe it is in good shape.

I obviously do not agree with that ERS is not mature. 

And I totally disagree that ERS cannot be sent alone to the IESG. 

Concerning the last two disagreements: 

1. As Carl already pointed out it seems there might be a
misunderstanding of the relationship between ERS and REQS: 

ERS is definitely not the complete answer to all requirements from REQS,
but fulfils its part. Other things shall be defined by LTAP and some
REQS may even be addressed at a later time (or only by individual
implementations but not by an I-D). (The goal of REQS is to help choose
the right technical solutions and approach by defining the objective
targets for the specifications.)

2. ERS as the data structure for the records is valuable on its own and
has with intent been only loosely coupled with LTAP. So we can progress
ERS. This makes the work of the WG easier and more efficient as we then
can focus on LTAP and ARI and validate (note: the last two are only
intended to be informational).

Thanks, Tobias

Sent: Tuesday, January 16, 2007 4:32 PM
Cc: [email-masked]

Carl,

I will have lo leave the discussion here for a few days, since I need to
attend different meetings.

This leaves you more time to look again at the arguments explained in my
three e-mails
and to my proposal where the new proposed ASN.1 fulfils the LTANS
requirements 
whereas ERS does not.

 - ERS is not mature.

 - LTAP is not mature.

 - ARI is not mature.

Denis  

inline...

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

	Carl,

	 <snip> 

	The archival policy, the archival time period and the crypto
maintenance policy are never mentioned. 

	[CRW] "Policy" is cited throughout and is included in the
RequestInformation structure.  "Archival policy" and "crypto maintenance
policy" are not distinguished.  They should be, but not in ERS.

	[CRW] See the following in section 8: "These data are optionally
encapsulated by CMS content types that provide for authentication and/or
confidentiality, e.g.  SignedData or EnvelopedData."  

	About the DELETE operation, what is worse is the following
sentence: "Note that this does not mean that 
	the server does not maintain a trace record of the delete
operation". A trace record would not be sufficient. 

	Deletion of an archive shall normally not happen, since the LTA
is trusted to keep the data until the end of 

	the archive period. A signed permission of deletion, by the
owner of the data shall be given, before deletion 

	Once again, the current set of documents does not meet the
requirements.

	I guess you reacted too quickly to my proposal from yesterday
and you should pay more attention to it. 

	[CRW] Most of your suggestions apply to a different document, in
my opinion.  I do think you were correct w.r.t. inclusion of an
indication of policy in the ArchiveTimeStamp layer.  Towards that end,
my counter-proposal yesterday may serve us better if we exchange the
optional OBJECT IDENTIFIER field for an optional Attributes field, where
policy could be an instance:

	I think the other matters can and should be addressed in the
context of LTAP.

	Carl