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 |