Skip to main content

Evidence Record Syntax (ERS)
draft-ietf-ltans-ers-15

Revision differences

Document history

Date Rev. By Action
2012-08-22
15 (System) post-migration administrative database adjustment to the Yes position for Russ Housley
2007-06-04
15 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-06-04
15 (System) New version available: draft-ietf-ltans-ers-15.txt
2007-06-04
15 Amy Vezza IESG state changed to Approved-announcement sent
2007-06-04
15 Amy Vezza IESG has approved the document
2007-06-04
15 Amy Vezza Closed "Approve" ballot
2007-06-01
15 Tim Polk State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Tim Polk
2007-06-01
15 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley
2007-05-31
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-05-31
14 (System) New version available: draft-ietf-ltans-ers-14.txt
2007-05-25
15 (System) Removed from agenda for telechat - 2007-05-24
2007-05-24
15 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-05-24
15 (System) [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by IESG Secretary
2007-05-24
15 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2007-05-24
15 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2007-05-24
15 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-05-24
15 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-05-24
15 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2007-05-23
15 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-05-23
15 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-05-23
15 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-05-22
15 Russ Housley
[Ballot comment]
From the Gen-ART Review by Brian Carpenter:

  At the end of section 4.2:
  >
  > The data (e.g. certificates, CRLs …
[Ballot comment]
From the Gen-ART Review by Brian Carpenter:

  At the end of section 4.2:
  >
  > The data (e.g. certificates, CRLs or OCSP-Responses) needed to verify
  > the timestamp SHOULD be stored in the timestamp itself or MUST be
  > preserved otherwise.
  >
  I find this insufficiently clear. When would it be acceptable not to
  store these data in the timestamp, and if not done so, how would the
  retriever know where to look?

  Just before section 5.1:
  >
  > After the renewal, always only the last, i.e. most recent
  > ArchiveTimeStamp and the algorithms and timestamps used by it must
  > be watched regarding expiration and loss of security.
  >
  This raises a general question - maybe this is well understood in LTANS,
  but RFC 4810 didn't clarify it for me. When a hash or crypto algorithm
  becomes "insecure" is not a well-defined moment. What is the triggering
  event for a Time Stamping Authority to decide to switch to a new
  algorithm, for example? What is the significance of the rather
  under-defined data stored in cryptoInfos (section 3.1)? If it says
  "SHA1 valid until 2010" does that means it is or isn't OK to use SHA1
  to generate timestamps in December 2009? Maybe all this is documented
  elswehere?

  I'm surprised that the redundancy mentioned in the Security
  Considerations is only a recommendation. To my taste, it would
  be a MUST, since we are discussing the *really* long term here.
2007-05-22
15 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2007-05-22
15 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-05-21
15 Russ Housley
[Ballot discuss]
The object identifier in section 2.4 has already been assigned for
  another purpose.  A different object identifier must be used here.
  …
[Ballot discuss]
The object identifier in section 2.4 has already been assigned for
  another purpose.  A different object identifier must be used here.
  Of course, this object identifier also appears in the Appendices.

  Section 7 says:
  >
  > Retrospectively, certain parts of an Archive Timestamp may turn out
  > to have lost their security suitability before this has been publicly
  > known.  E.g. it may turn out retrospectively, that algorithms have
  > lost their security suitability.  And even TSAs might be considered
  > as untrustworthy retrospectively.  This can result in Archive
  > Timestamps using those losing their probative force.  To counter such
  > risks it is recommended to generate and manage at least two redundant
  > Evidence Records with ArchiveTimeStampSequences using different hash
  > algorithms and different TSAs.
  >
  The loss in confidence of an algorithm impact all TSAs.  The loss
  confidence in a particular TSA has a much more local impact, and
  having a second time stamp from a different TSA resolves this concern.
  The advice that two hash algorithms be used also assumes something
  about the digital signature algorithms and key sizes used by the TSAs.
  Please separate these various concerns so that the consequences of
  each can be appropriately described.
2007-05-21
15 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-05-20
15 Tim Polk Ballot has been issued by Tim Polk
2007-05-20
15 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-05-16
15 Tim Polk [Ballot Position Update] New position, Yes, has been recorded by Tim Polk
2007-05-16
15 Tim Polk Created "Approve" ballot
2007-05-16
15 Tim Polk Placed on agenda for telechat - 2007-05-24 by Tim Polk
2007-05-16
15 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Tim Polk
2007-05-10
15 Amy Vezza
The IETF Secretariat was requested to place these comments into the comment log for this I-D:

"Due to a final revision of the LTANS OID …
The IETF Secretariat was requested to place these comments into the comment log for this I-D:

"Due to a final revision of the LTANS OID registry structure several OIDs need to be changed in the draft.
The following OIDs will be changed accordingly:

OLD:
id-em OBJECT IDENTIFIER ::= { ltans 2 }

NEW:
id-meth OBJECT IDENTIFIER ::= { ltans 1 } -- methods

and OLD:
id-EvidenceRecord-Internal OBJECT IDENTIFIER ::= {id-em 2}
id-EvidenceRecord-External OBJECT IDENTIFIER ::= {id-em 3}
NEW:
id-meth-er-internal OBJECT IDENTIFIER ::= { id-meth 1 }
id-meth-er-external OBJECT IDENTIFIER ::= { id-meth 2 }

and the ERS module OID will be changed:
OLD:
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(1) id-mod-ers88(2) }
to NEW:
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers88(1) id-mod-ers88-v1(1) }


and OLD:
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(1) id-mod-ers(1) }

to NEW:
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers(2) id-mod-ers-v1(1) }"
2007-05-10
15 Amy Vezza
The IETF Secretariat received a request to place these comments into the comment log for this document:


From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Monday, …
The IETF Secretariat received a request to place these comments into the comment log for this document:


From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Monday, March 05, 2007 9:07 PM
To: Tobias Gondrom; tobias.gondrom@opentext.com;
ralf.brandner@intercomponentware.com; ulrich.pordesch@zv.fraunhofer.de;
CWallace@cygnacom.com
Cc: tim.polk@nist.gov
Subject: RE: AD Review: draft-ietf-ltans-ers-11

Tobias:


1. Section 1.3. Terminology
[ Should you also define "initial archive timestamp"? It gets used
often. ]

A: No. This should not get its own definition as its only intended to by
a sub-type of the defined archive timestamp (which is defined). I think
that definition of this might lead to the mistake that the initial
archive timestamp has an own structure deviating from the archive
timestamp - which is not the case.


I'm okay with your decision.

[tg]: Ok.



2. Section 2.1.1
[ I do not really see the need for these sections. They should just
appear in the ASN.1 modules. ]

A: I kept the sections for formatting reasons: a) I think it might be
helpful for the reader to have the full information in the right order
inside the document and b) The appendices are generated from the
structures written in the text.


Up to you, but for someone that deals with many ASN.1-oriented
specifications, they are out of place.
[tg]: Ok.




3. 3.1. Syntax
The 'version' field indicates the syntax version, for compatibility
with future revisions of this specification and to distinguish it
from earlier non-conformant or proprietary versions of the ERS. The
value 1 indicates this specification. Lower values indicate an
earlier version of the ERS has been used. An implementation
conforming to this specification SHOULD reject a version value below
1.

[ Why not "(1..MAX)" to make sure that negative and zero are not
allowed? ]

A: The version value for this spec is 1 not (1...MAX) - only later
versions may use higher values. (And in fact an implementation conform
with the spec might decide to implement some backwards compatibility
mode for their own proprietary ERS implementation and accept version
numbers below 1.


You missed my point. The syntax could prevent the use of zero and
negative integer values. I realize that the only valid value right now
is 1. You do not want to change the definition in the future versions
(if they ever exist).
[tg]: It seems not appropriate to absolutely forbid version values below
1. As stated in the document in section 3.1

"The value 1 indicates this specification. Lower values indicate an

earlier version of the ERS has been used. An implementation

conforming to this specification SHOULD reject a version value below
1."

This is a "SHOULD", not a "MUST".





4. Section 4.2 Generation
OLD:

Assuming that the sorted binary ordering of the hashes in Figure 1
is: h2abc < h1 then the reduced hash-tree for data group 1 (d1) is:

+--------------------------------+
| +----------------+ +--------+ |
| | +------+ +----+ | | +----+ |
| | | h2abc| | h1 | | | | h3 | |
| | +------+ +----+ | | +----+ |
| +----------------+ +--------+ |
+--------------------------------+

[ I do not understand this figure. ]

Figure 2: Reduced hash-tree for data group 1


A: In my opinion figure 2 should be understandable when looking at it
together with figure 3 right below it.


It is not. I expected:

+--------------------------------+
| +-----------------+ +--------+ |
| | +------+ +----+ | | +----+ | |
| | | h2abc| | h1 | | | | h3 | | |
| | +------+ +----+ | | +----+ | |
| +-----------------+ +--------+ |
+--------------------------------+





[tg]: You are right, corrected with draft draft-ietf-ltans-ers-13


5. Section 6.1 Syntax
[ Please explain why CMS EncryptedData or EnvelopedData is not used
here.
What is gained by defining a new content type? ]

[ If you do not adopt CMS, it does not seem like there is enough here to
ensure interoperable implementations. ]

A: Appendix A explicitly describes the use of CMS together with ERS. But
other forms of encryption might be used. One example that has been
discussed in the WG a few years ago is, that content data might be split
up between several repositories (to prevent its disclosure) and only be
put back together when the integritiy of the initial content must be
verified. In this case it is necessary for the verifying party to know
the algorithm and parameters of the encryption method. And for this
information the structure EncryptionInfo is designed. It is not in
concurrency with EncryptedData or EnvelopedData but derives from the
needs of potentially other (unspecified) Methods of Encryption.


CMS is algorithm agile, so I still do not understand the need for a new
structure.

[tg] Answer: The reason is EncryptionInfo does not exactly match CMS
EncryptedData or EnvelopedData.

EncryptionInfo is not intended to store encrypted data or normal
encryption information but information to ensure the unambiguous
bi-directional mapping of the unencrypted data to the stored and
protected encrypted data.

Excerpt from an explanation to a similar question on the mailing-list:
encryptionInfo has the intend to ensure a bi-directional mapping between
used encryption methods (like e.g. splitting the bits between several
archive systems) and the documents. (Note in some cases such an
encryption algorithm might use additional parameters and only be
surjective but not be bijective. The encryptionInfo field is allow the
user to provide all necessary information to make the operation fully
bijective. (By this the proof that the decrypted information
mathematically unambiguously matches the encrypted and by the
EvidenceRecord protected content.)

So EncryptionInfois different to the named CMS structures.



And now all the changes that were executed as advised by you:


[snip]
7. 2.1. ASN.1 module definition



OLD: Depending on the syntax version of your compiler
implementation you can use the imports for the 1988 conformant ASN.1
syntax or the imports for the current ASN.1 syntax. The appendix of
this document lists the two complete alternative ASN.1 modules.

[ If there are descrepencies, the 1988 module needs to take precedence.
]

NEW:
Depending
on the syntax version of your compiler implementation you can use the
imports for the 1988 conformant ASN.1 syntax or the imports for the
1997-ASN.1 syntax. The appendix of this document lists the two
complete alternative ASN.1 modules. If there is a conflict between
both modules, the 1988-ANS.1 module precedes.

s/ANS/ASN/

[tg]: You are right, corrected with draft draft-ietf-ltans-ers-13


8. Section 2.3 LTANS identification and Section 2.4 ERS identifiers

Corrected the Identifier "id-ltans" to "ltans"

LTANS Object Identifier tree root

[ Looks like a cut and paste error from section 3.3, but I think the
section is not needed anyway. ]

id-em OBJECT IDENTIFIER ::= { id-ltans 2 }

which lead to the following changes:
OLD:
id-ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }

id-em OBJECT IDENTIFIER ::= { id-ltans 2 }

NEW:
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }

id-em OBJECT IDENTIFIER ::= { ltans 2 }


This was not the problem. The comment "LTANS Object Identifier tree
root" appears two places.

I have no problem with "id-ltans"



[tg]: Ok, understood. You are right. The second line "LTANS Object
Identifier tree root" in section 2.4 will be removed with draft
draft-ietf-ltans-ers-13

15. Section 7. Security Considerations
OLD:
Redundancy

Algorithms can lose there security suitability or Time Stamping
Authorities may be considered as untrustworthy retrospectively.
Therefore Archive Timestamps can lose their probative force. If

[ There seems to be two things going on here. Consider separate
paragraphs. ]

Archive Timestamps are managed centrally several redundant
ArchiveTimeStampSequences can be generated using different hash
algorithms and different Time Stamping Authorities.


NEW:
Redundancy

Retrospectively, certain parts of an Archive Timestamp may turn out
to have lost their security suitability before this has been publicly
known. E.g. it may turn out retrospectively, that algorithms have
lost their security suitability. And even TSAs might be considered
as untrustworthy retrospectively. This can result in Archive
Timestamps using those losing their probative force. To counter such
risks it is recommended to generate and manage at least two redundant
Evidence Records with ArchiveTimeStampSequences using different hash
algorithms and different TSAs.

To best achieve and manage this redundancy, it is recommended to
manage the Archive Timestamps in a central LTA.

The loss in confidence of an algorithm impact all TSAs. The loss
confidence in a TSA has a much more local impact, and having a second
timestamp from a different TSA resolves this concern.

id-EvidenceRecord-Internal OBJECT IDENTIFIER ::= {id-em 2}

id-EvidenceRecord-External OBJECT IDENTIFIER ::= {id-em 3}

Should these be registered?

[tg]: Yes. The OIDs have been revised and updated in the
draft-ietf-ltans-ers-13 accordingly. They will be registered with the
ltans oid registry.

Russ
2007-05-10
15 Amy Vezza
The IETF Secretariat received a request to put the following email into the comment log for this document:

-----Original Message-----
From: Ulrich Pordesch [mailto:ulrich.pordesch@sit.fraunhofer.de …
The IETF Secretariat received a request to put the following email into the comment log for this document:

-----Original Message-----
From: Ulrich Pordesch [mailto:ulrich.pordesch@sit.fraunhofer.de]
Sent: Tuesday, May 01, 2007 6:43 PM
To: Tobias Gondrom; ietf-ltans@imc.org
Subject: AW: I-D ACTION:draft-ietf-ltans-ers-12.txt

Hello,

I fully agree with your assessment, Tobias. There is no need to modify the
draft based on these new comments from Denis.

Ulrich

-----Ursprüngliche Nachricht-----
Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im
Auftrag von Tobias Gondrom
Gesendet: Montag, 30. April 2007 14:41
An: Denis Pinkas
Cc: ietf-ltans@imc.org
Betreff: RE: I-D ACTION:draft-ietf-ltans-ers-12.txt


Hello Denis,

thank you for your review and please excuse that it took me so long to
answer.

0. As ERS is in IETF LC (started 2007-02-21), I will treat and document
your comments also as IETF LC comments.

But now concerning your comments:
1. This is as designed. When an initial EvidenceRecord is created there
is only one ArchiveTimeStamp in it. Further ArchiveTimeStamps (in the
ArchiveTimeStampChain are added when Timestamp-renewald are necessary
(this means there is always just one further ArchiveTimestamp added to
the chain). and similar to that of with new ArchiveTimestamps created by
hashtree-renewal. So the use case (to create at one point in time
multiple ArchiveTimestamps within the same ArchiveTimestampchain) you
described actually never applies.

2. In fact it is very easy to find out which documents are
stored/covered by and ArchiveTimeStamp: the hash values of the documents
(which can be computed easily) are stored in the first ArchiveTimeStamp.
So it is trivial to relate documents to the EvidenceRecord.

3. CryptoInfos and EncryptionInfo follow two very different goals:
CryptoInfos to provide information (like all used algorithms) at the
higher level of the EveidenceRecord to make processing easier (or to
make it easy to decide for an implementation whether it shall proceed
with the evaluation or abort if it may not be able to compute one of
thee listed algorithms.)
encryptionInfo has the intend to ensure a bi-directional mapping between
used encryption methods (like e.g. splitting the bits between several
archive systems) and the documents. (Note in some cases such an
encryption algorithm might use additional parameters and only be
surjective but not be bijective. The encryptionInfo field is allow the
user to provide all necessary information to make the operation fully
bijective. (By this the proof that the decrypted information
mathematically unambiguously matches the encrypted and by the
EvidenceRecord protected content.)

4.
a) An unlimited number of levels in the hashtree is definitely possible
with the current structure. (It is not limited to 3 levels.)
b) every node is unambiguous.
c) at first the structure of the EvidenceRecord is obviously intended to
be extended every time algorithms get weak and a timestamp-renewal or
hashtree-renewal occurs. So it is not intended to include an
EvidenceRecord within another for this need (the equivalent of your idea
is that ArchiveTimestamps protect the preceeding ArchiveTimestamps,
which is the case).
At any given time an existing EvidenceRecord can be extended (also by
another party) and if it is necessary (although I can see no clear use
case for that) it can of course also be stored and protected itself as a
data object protected by an EvidenceRecord.
d) we have added several hooks for extensibility with the Attributes in
the ArchiveTimeStamp structure. (btw. inspired by your last review)
e) it is not intended to stack time-stamp tokens with CRLs by a
one-to-one relationship. Additional verification data for the timestamps
should be stored in the timestamp structures themselves or in the
cryptoInfos.


Summarizing:
The comments above are due to misunderstanding but do not demonstrate a
defect in the draft or data structure. I can see no need to make any
changes to the draft, except for the wording: there had been a few
wording comments from the AD review and those will be addressed in a new
version.
The new draft is scheduled to be submitted in one week and will (if no
further objections occur) then be processed further in the IETF LC.

Tobias




> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: Tuesday, April 10, 2007 11:44 AM
> To: ietf-ltans@imc.org
> Subject: Re: I-D ACTION:draft-ietf-ltans-ers-12.txt
>
>
> Comments on draft-ietf-ltans-ers-12
>
> Major comments 1 to 4
>
> The current syntax is defined as:
>
> EvidenceRecord ::= SEQUENCE {
> version INTEGER { v1(1) } ,
> digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
> cryptoInfos [0] CryptoInfos OPTIONAL,
> encryptionInfo [1] EncryptionInfo OPTIONAL,
> archiveTimeStampSequence ArchiveTimeStampSequence
> }
>
> ArchiveTimeStampSequence ::= SEQUENCE OF
> ArchiveTimeStampChain
>
> ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
>
> ArchiveTimeStamp ::= SEQUENCE {
> digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
> attributes [1] Attributes OPTIONAL,
> reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
> timeStamp ContentInfo}
>
> Attributes ::= SET SIZE (1..MAX) OF Attribute
>
> PartialHashtree ::= SEQUENCE OF OCTET STRING
>
> There are several problems with this syntax:
>
> 1) Within ArchiveTimeStamp, the timeStamp element is mandatory.
> When an ArchiveTimeStampChain is being built, several time stamp
tokens
> will be needed whereas only one time stamp token at the top of the
> hierarchy
> is really needed. It should be possible to have a timeStamp element
> present
> in the EvidenceRecord structure.
>
> 2) When the Evidence Record is stored separate from the archived data,
> the syntax does not allow to interoperate, since there is no way to
know
> how to build or reconstruct the right sequence of PartialHashtrees.
>
> PartialHashtree ::= SEQUENCE OF OCTET STRING
>
> One way to solve this issue would be to add the name of each element
used
> to construct the hash tree, so that that name can be used to locate
and
> fetch
> the corresponding file.
>
> 3) cryptoInfos and encryptionInfo are currently defined as follows:
>
> CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
>
> EncryptionInfo ::= SEQUENCE {
> encryptionInfoType OBJECT IDENTIFIER,
> encryptionInfoValue ANY DEFINED BY encryptionInfoType
> }
>
> cryptoInfos and encryptionInfo do not allow any kind of
interoperability.
> It would more appropriate to define generic extensions, like for
> certificates and CRLs:
>
> extensions Extensions OPTIONAL,
>
> 4) The current syntax does not allow :
>
> - an unlimited number of levels in the tree (only three levels are
> possible);
> - to identify a node;
> - to incorporate into an Evidence Record, previously computed
Evidence
> Records;
> - to add new extensions;
> - to stack time-stamp tokens and CRLs.
>
> The following syntax would solve the issue:
>
> EvidenceRecord::= SEQUENCE {
> version INTEGER { v1(1) } ,
> digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
> reducedHashtree ReducedHashtree OPTIONAL,
> otherEvidenceRecords SEQUENCE OF EvidenceRecord OPTIONAL,
> extensions Extensions OPTIONAL,
> timeStamps SEQUENCE OF TimeStamp
> }
>
> ReducedHashTree ::= SEQUENCE {
> hashTreeElements SEQUENCE OF HashTreeElement,
> reducedHashTree SEQUENCE OF ReducedHashTree OPTIONAL
> }
>
> HashTreeElement ::= SEQUENCE {
> node BOOLEAN DEFAULT FALSE,
> digestAlgorithm AlgorithmIdentifier,
> elementHash OCTET STRING,
> elementName GeneralName OPTIONAL,
> }
>
> TimeStamp ::= SEQUENCE {
> tst ContentInfo,
> crl CertificateList OPTIONAL
> }
>
> Sections 3.2 and 3.3 would need to be rewritten.
>
> Minor comment
>
> The word non-repudiation is misused in several places. For example, on
> page 6:
>
> " each Archive Timestamp preserves non-repudiation of the previous
Archive
> Timestamp" .
> There is no need to use the word non-repudiation here, since the
following
> sentence is sufficient:
> " each new time-stamp maintains the validity of the previous
time-stamp".
>
> Denis
>
> ================================================================
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Long-Term Archive and Notary
Services
> Working Group of the IETF.
> >
> > Title : Evidence Record Syntax (ERS)
> > Author(s) : R. Brandner, et al.
> > Filename : draft-ietf-ltans-ers-12.txt
> > Pages : 34
> > Date : 2007-3-8
> >
> > In many scenarios, users must be able prove the existence and
> > integrity of data, including digitally signed data, in a common
and
> > reproducible way over a long and possibly undetermined period of
> > time. This document specifies the syntax and processing of an
> > Evidence Record, a structure designed to support long-term non-
> > repudiation of existence of data.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > i-d-announce-request@ietf.org with the word unsubscribe in the body
of
> > the message.
> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then
> > "get draft-ietf-ltans-ers-12.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-ltans-ers-12.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > Content-Type: text/plain
> > Content-ID: < 2007-3-8122718.I-D@ietf.org>
> >
> > ENCODING mime
> > FILE /internet-drafts/draft-ietf-ltans-ers-12.txt
> >
>
> Regards,
>
> Denis Pinkas
2007-05-09
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-05-09
13 (System) New version available: draft-ietf-ltans-ers-13.txt
2007-05-01
15 Tim Polk Status date has been changed to 2007-05-15 from
2007-04-27
15 Tim Polk State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Tim Polk
2007-04-06
15 Amy Vezza
The IETF Secretariat received a request to place the fllowing email into the comment log for this document.

From: Tobias Gondrom
Sent: Tuesday, March 13, …
The IETF Secretariat received a request to place the fllowing email into the comment log for this document.

From: Tobias Gondrom
Sent: Tuesday, March 13, 2007 3:21 PM
To: 'ietf@ietf.org'
Cc: 'tim.polk@nist.gov'; Russ Housley; 'Carl Wallace'
Subject: RE: Last Call: draft-ietf-ltans-ers (Evidence Record Syntax
(ERS)) to Proposed Standard - comment from Tim and answer
Importance: Low

Comment to the draft received from Tim Polk during review:

> I thought I might follow up on the first unaddressed comment:
>
> I notice that the phrase "the Initial Archive Timestamp" frequently
> appears in the text with a capitalized 'I' in word "initial". This
seems
> to indicate that there *is* something special about this timestamp,
and I
> would expect to find a definition in the terminology section.
>
> Perhaps a lowercase 'i' would more clearly indicate that it is simply
a
> subtype with the same structure? That is, if the phrase was "the
initial
> Archive Timestamp", I would only expect to find "Archive Timestamp" in
the
> terminology section. (Actually, the phrase appears with a lowercase
'i'
> twice - once in section 1.2 and again in 5.2. I assume there is no
> difference?)
>
> Thanks,
>
> Tim Polk

Answer from I-D author:
> Hi Tim,
>
> I agree with you, and follow your comment and will make sure in the
final
> revision of the draft that the word "initial" of the "initial Archive
> Timestamp" only starts with a capital letter at the beginning of a
> sentence.
>
> Thanks, Tobias
2007-04-05
15 Sam Weiler Request for Last Call review by SECDIR Completed. Reviewer: Stefan Santesson.
2007-03-30
15 Russ Housley Responsible AD has been changed to Tim Polk from Russ Housley
2007-03-29
15 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-03-20
15 Yoshiko Fong IANA Last Call Comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2007-03-09
15 Sam Weiler Request for Last Call review by SECDIR is assigned to Stefan Santesson
2007-03-09
15 Sam Weiler Request for Last Call review by SECDIR is assigned to Stefan Santesson
2007-03-08
15 Amy Vezza Last call sent
2007-03-08
15 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-03-08
15 Russ Housley Last Call was requested by Russ Housley
2007-03-08
15 Russ Housley State Changes to Last Call Requested from AD Evaluation by Russ Housley
2007-03-08
15 (System) Ballot writeup text was added
2007-03-08
15 (System) Last call text was added
2007-03-08
15 (System) Ballot approval text was added
2007-03-08
12 (System) New version available: draft-ietf-ltans-ers-12.txt
2007-02-26
15 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2007-02-21
15 Russ Housley [Note]: 'PROTO Shepherd is Carl Wallace <CWallace@cygnacom.com>' added by Russ Housley
2007-02-21
15 Russ Housley
Document Shepherd Write-Up

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this …
Document Shepherd Write-Up

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The Document Shepherd is Carl Wallace, who has reviewed this version of the document and believes it to be ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been extensively reviewed by key WG members and was reviewed as part of a cross posting to the SMIME WG during the most recent working group last call.  The document shepherd has no concerns about the depth or breadth of the reviews.  Several independent implementations reportedly exist, with at least two (Fraunhofer and Open Text Corporation) claiming interoperability. Several other vendors have also reported to have implemented the specification.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.  An XML version of the specification will be published as a separate draft.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The document shepherd has no outstanding concerns with the draft.

Note: WG participants researched potential IPR conflicts and found that no patents in conflict with the specification.  A list of patents derived from RFC3029 has been named in the draft. Additionally there has been one IPR disclosure filed by one of the authors according to RFC3979 section 6.1.3 submitted July 31, 2005: https://datatracker.ietf.org/publ2ic/ipr_detail_show.cgi?ipr_id=698
The WG and the authors do not believe that the draft is in conflict with any of these patents.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The document represents relatively strong consensus of the WG.  The draft has been a WG draft for several years.  Recently, some questions have been raised with regard to similarity with an ISO publication.  However, after mailing list discussion there are no outstanding claims to abandon this draft in favour of the ISO specification.  Several WG last calls have been held and the final WG last call resulted in small, minor corrections.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Yes, idnits version 2.02.2 has been used to check the document. It has met all formal requirements. idnits has been used in very verbose mode and reported 0 errors and 3 experimental warnings, which have been identified as false warnings. 

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes the document has split its references into normative and informative.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The document does not require an IANA considerations section.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The Document Shepherd has verified that the ASN.1 module with the current syntax is accepted by the free ASN.1 compiler asn1c and a commercial ASN.1 compiler from Objective Systems.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

  Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media Type
            review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director? Is an IANA expert needed?

Technical Summary

In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time.  This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data.
           
Working Group Summary

No special notes to the WG process.

Document Quality

There exist several implementations of the specification. And several vendors have explained their urgent need for this specification. At least two vendors have already run compatibility tests based on draft version 08 and will run final tests after the publication of ERS.

Personnel

Document Shepherd: Carl Wallace
Area Director: Russ Housley
IANA expert: none needed
2007-02-21
15 Russ Housley [Note]: 'PROTO Shepherd is Carl Wallace ' added by Russ Housley
2007-02-21
15 Russ Housley Draft Added by Russ Housley in state Publication Requested
2007-02-20
11 (System) New version available: draft-ietf-ltans-ers-11.txt
2007-02-16
10 (System) New version available: draft-ietf-ltans-ers-10.txt
2007-01-04
09 (System) New version available: draft-ietf-ltans-ers-09.txt
2006-10-18
08 (System) New version available: draft-ietf-ltans-ers-08.txt
2006-05-15
07 (System) New version available: draft-ietf-ltans-ers-07.txt
2006-04-20
06 (System) New version available: draft-ietf-ltans-ers-06.txt
2006-02-08
05 (System) New version available: draft-ietf-ltans-ers-05.txt
2005-12-08
04 (System) New version available: draft-ietf-ltans-ers-04.txt
2005-10-17
03 (System) New version available: draft-ietf-ltans-ers-03.txt
2005-07-31
(System) Posted related IPR disclosure: Tobias Gondrom's Statement about Possible IPR claimed in draft-ietf-ltans-ers-02.txt and draft-ietf-ltans-reqs-04.txt belonging to Surety
2005-04-08
02 (System) New version available: draft-ietf-ltans-ers-02.txt
2004-07-21
01 (System) New version available: draft-ietf-ltans-ers-01.txt
2004-02-12
00 (System) New version available: draft-ietf-ltans-ers-00.txt