Dear Ben, thank you very much for your thorough review of xmlers. I corrected nearly all of the items you raised and sent the revised version to my co-authors for approval and publication as version -10. On a note of further language style improvement beyond your comments, the AD advised us at the time of submission to rely on the RFC Editor. Details inline below. Kind regards, Tobias On 01/06/2011 11:32 PM, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may receive. > > Document: draft-ietf-ltans-xmlers-08 > Reviewer: Ben Campbell > Review Date: 11-01-06 > IETF LC End Date: 11-01-11 > > Summary: > > This draft is on the right track for proposed standard, but I think it needs more editing prior to publication. > > Note that I have not attempted to verify the XML schema or examples. These should be mechanically verified prior to publication, if they have not already been done so. xml schema has been verified. > -Major issues: > > None > > -Minor issues: > > -- General: I'd like to see some more architectural background. Who are the actors? What are their roles? You mention the time stamp authorities, but not much else. Who are the verifiers? How to Certificate Authorities fit in? For the architectural background I would refer you to ERS (RFC4998) which is the ASN variant. Furthermore the systems mainly need the time stamp authorities, all other players can actually vary with implementation. For this reason we are currently working on an informational draft draft-ietf-ltans-ari to exactly give a more detailed view on the use scenarios and actors and roles. > -- general: I'd like to see at least one complete example. > > -- 3.1.2, 1st paragraph: "exact time (obtained from trusted time source) of Time-Stamping." > > How exact? Actually to be precise "how exact" depends on the time source. So not sure what you mean here? > -- 3.1.2, paragraph before example: "The Attribute type must be used" > > Normative? yes, corrected to MUST > -- 3.1.3, 1st paragraph: > > Is that a normative SHOULD? Can you offer examples or an explanation of when thus might not be possible? corrected to SHOULD. Example of when this might not be possible is when the data structure of the used time-stamp token does not allow storing further verification data. > -- 3.1.3, 2nd paragraph: "Following values SHOULD be used as identifiers for the Type attribute" > > Just should? Don't you mean to say the type MUST be something in the IANA registry? yes, corrected to MUST > -- 4.1, last paragraph "must be valid at the present time" > > Normative? yes normative. Corrected to MUST > -- 4.1.1, general: > > (comments also apply to the Canonicalization method URL) > > What does the URI represent? Does that point to the actual definition of the algorithm? Can I make up arbitrary ones? Is there a registry? What schemes are allowed and/or reasonable? > > Are there any required-to-support algorithms? The URI is an identifier for the algorithm as specified in RFC4051 and 3275. The draft is intentionally algorithm agile, meaning it references algorithm identifiers from the listed RFCs and there are no "required-to-support algorithms" as these will obviously evolve over time and new ones may have to be developed and supported in the future when current ones become weak. > -- 4.1.1, 2nd paragraph: "those must be used as defined in [RFC3275] and [RFC4051]" > > Normative? Yes normative. Corrected to MUST. > -- 4.1.1, last paragraph: > > What do you mean by equal? The same algorithm? One of equal strength? How do you determine relative strength? Corrected language. They must be the same digest algorithm. > -- 4.2.1, last paragraph: "The new ATS and its hash tree MUST use the same digest algorithm as the preceding one" > > Does this imply they can't change to a new algorithm? What if an algorithm becomes deprecated over time? No it does not imply the digest algorithm can't be changed to a new one. But to change the hash algorithm you must use the hash tree renewal (section 4.2.2) > -- 7, 1st paragraph: "have to be considered by verifying components" > > Normative? Actually not. Because verifying components may use different criteria to determine which algorithm is considered secure. These can vary by country and legislation, so it would be inappropriate to make this normative. > -- 7, 4th paragraph: > > should "recommended" and "must" be normative? > > Why different TSAs? Wouldn't different algorithms be good enough? Are you assuming a given TSA is limited to a single algorithm at a time? Changed recommended to normative "RECOMMENDED". And changed non-normative "must" to normative "SHOULD": because there may theoretically be scenarios where redundancies still have value even without hash algorithm redundancy or two different secure hash algorithms may not be available. Different TSAs are recommended, because there may be events when one TSA (and all its keys) is compromised. In which case a redundant TSA would help mitigate this risk. (on a personal side note: in practice different TSAs are sometimes also needed because some of them do only offer a very limited range of algorithms.) > -- 7, last paragraph: "Time-Stamps should have the same or higher quality" > > Normative? > Yes, changed to normative. > -Nits/editorial comments: > > -- General: The draft could really use another editing pass to check for punctuation errors and awkward style. There's lots of missing or misused commas, missing articles, passive voice that obscures actors, etc. It looks like sections were edited in isolation from each other, with redundant assertions (how many times do you need to open with "time stamps prove the existence of data at a particular time"), inconsistent use of acronyms, etc. I will highlight some examples, but they are by no means exhaustive. > > Much of this could be handled by the RFC editor, but its best to minimize their work load, and better to minimize the opportunity for outside editors to misconstrue your meaning. Regarding punctuation errors and style the AD advised to rely on the editor for this in this case. However, as you kindly outlined some of the vulnerable areas, I will revisit each of them again and try to improve language there. > -- General: The pagination and vertical spacing seem strange. > > -- Abstract : "This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data." > > I assume this is for non-repudiation of more than just the "existence" of the data, right? Also, please expand the acronyms in the abstract. expanded. > -- section 1: "define XML Schema and processing rules for Evidence Record Syntax in XML format. The document is related to initial ASN.1 syntax" > > Missing articles. Also, since you use an acronym for this later, why not declare it here? done: declared ASN.1 and XML. > -- 1.1, first paragraph: "Such data and non-repudiable proof of existence must endure for long periods of time, even when information to prove data existence and integrity weakens or ceases to exist." > > That seems to say the proof must continue to exist past it's own existence. I assume that is not the intent. corrected > -- "digital signatures defined in [RFC5652] for example do not provide absolute reliability" > > Missing commas around "for example" corrected > -- 2nd paragraph: "All integrity and authenticity related techniques used today suffer from the same problem of time related reliability degradation including techniques for Time-Stamping, which are generally recognized as data existence and integrity proof mechanisms." > > I find it hard to parse that sentence. improved sentences structure. Will ask RFC Editor for further language improvements > -- "Some of the problems might not even be technically related like a decomposing Time-Stamping authority." > > Technically related to what? Do you mean to say "might not even be of a technical nature..."? Also, I'm not sure I understand "decomposing" in this context. yes, changed and replaced "decomposing" > -- 3rd paragraph: " introduced for example by" > > Missing commas corrected > -- "long term signature syntaxes like [RFC5126]" > > Missing words? (i.e. .... syntaxes like those defined in...) corrected > -- "Long term signature syntaxes and processing rules address mostly the long term endurance of digital signatures..." > > Seems self-redundant corrected > -- 4th paragraph: > > Please expand XMLERS on first mention. Also, this is not consistent with the acronym used in the abstract. expanded > -- 6th paragraph: "support for example import" > > commas corrected > -- section 1.2, first paragraph > > Multiple missing articles corrected > -- 3rd paragraph: "Evidence Record maintains a close relationship to Time-Stamping techniques" > > I doubt it "maintains" anything. It think you mean to say "is closely related to..." corrected > -- 1.2, 4th paragraph: "packed into a structure called a "hash tree"" > > The text appears to be trying to introduce the concept of a "hash tree", but that's already been mentioned several times. no change: yes it has been mentioned, but hash tree is one of the key elements of XMLERS so it should be mentioned in the overview provided in this section (1.2 general overview) > -- 1.2, 5th paragraph: "collected evidence data must be monitored and renewed before such events occur" > > monitored by whom? actually who monitors can vary with implementation (it could be the system operator, user or a third party) so we did intentionally not specify it here. > -- 1.3, 2nd paragraph: > > "multitude" connotes a large number. I think you just mean "set". Also, why the parentheses? corrected > -- 1.3, definition of "canonicalization" > > This seems like a definition of "canonicalization rules". Wouldn't "canonicalization" refer to the act of following the rules, rather than the rules themselves? > > Also, the draft needs a definition for "canonical form" unchanged: in this case I think the definition is appropriate and also the term "canonical form" is sufficiently well known in XML terms, so that it is not necessary to repeat definitions here. > -- section 2, first paragraph: > > It would be nice to have definitions of integrity and non-reputability in the terminology section. Maybe even "existence" as used in the context. Not changed: I would prefer to not "over-define" in the terminology section (as this can also reduce readability of the document). Words like existence and integrity should be sufficiently clear. > -- section 2, first paragraph: "unit of data, which is to be used" > > I think you mean "unit of data that is to be used" corrected > -- section 2, 1st paragraph: "Time-Stamp Tokens obtained from the Time-Stamping Authority (TSA)" > > Obtained by whom? corrected > -- section 2, 2nd paragraph "number of reasons" > > More than one example would be nice. added one more reason > -- 2.1, 1st paragraph: "CRLs or OCSP" > > Expand on first mention expanded. > -- 2.1, paragraph made up of "<CanonicalizationMethod> is a required element that specifies the canonicalization algorithm applied over the archive data in case of XML data objects, <ArchiveTimeStampSequence> or <TimeStamp> element prior to performing digest value calculations." > > Sentence does not make sense. Are therre missing words? corrected > -- 2.2, 3rd paragraph after numbered list: "the application not defined in this draft" > > I'm not sure what you mean. Is there a specific application defined elsewhere, or are you just trying to say it is out of scope? corrected > -- 2.2, 2nd to last paragraph: > > I'm not sure what this is an example of. It just looks like a continuation of the section text. Corrected. > -- "provide also evidence" > > also provide evidence corrected > -- 3.1.1, third to last paragraph "When a single Time-Stamp is obtained for a set of archive objects, a hash tree MUST be constructed to generate a single hash value to bind all archive objects from that group and then a reduced hash tree MUST be extracted from the hash tree for each archive object respectively (see Section 3.2.1)." > > Meaning obscured by passive voice. Who or what MUST generate and/or extract hash trees? corrected to active voice > -- 3.1.1, 2nd to last paragraph: "For example, the text value" > > Is this a second example, or a continuation of the previous one? corrected > -- 3.1.2, 1st paragraph "Since at the time being there is no standard" > > Won't is statement become false when this draft is published as an RFC? No, because the draft defines the Evidence Record in XML, but the time stamps are still not standardised in XML, only in ASN.1 (RFC3161). > -- 3.1.2, paragraph before example: "in particular, e.g." > > "in particular" or "e.g", not both. corrected > -- 3.2.1, 2nd paragraph: "This is the case:" > > Confusing. Do you mean to say "The values are unequal when either of the following are true:"? corrected > -- 3.2.1, 1st bullet list entry "is having" > > has corrected > -- 3.2.1, paragraph before 2nd numbered list: "is built from bottom to the root." > > Leaves to the root, or bottom to top. Also, who builds it? corrected, but kept passive voice in this case because who builds it is not important. > -- "The leaves represent the digest values of the archive objects:" > > It looks like you mean this sentence to introduce the following list, but it doesn't seem to do so. corrected > -- List entry 3: Need to define N. Is this the order of the tree? corrected > -- 3.3, list item 2: "If an additional proof is necessary that the Archive Time-Stamp relates to a data object group (e.g. a document and all its digital signatures), it can also be verified that only the hash values of the given data objects are in the first hash value list." > > I don't understand this sentence corrected > -- 3.3, numbered list: > > Is there a need to distinguish between kinds of negative results? No. For the standard there is no need to distinguish between different kinds of negative results. (Though a verification application may do that, to give further detailed information to the user.) > -- 4.1.2, last paragraph: "it is recommended to use c14n- 20010315." > > Reference? corrected. was already listed in references, just added it to section 4.1.2 > -- 4.2 "Archive Time-Stamps have to be renewed " > > by whom? put in active voice (LTA renews time-stamps) > -- section 7, "Secure Algorithms", etc > > Should these be numbered subsections? Ok. Introduced subsections in the security considerations section > -- 7, 1st paragraph: "have to be considered by verifying components" > > They need to be considered by people, not components, right? Also, is this a verification issue or a generation issue? corrected > -- section 8, 1st paragraph: "namespace has been registered in the IANA XML Registry." > > It's already been registered, or are you instrucing IANA to register it? (repeats several times in section) Yes, we instructed IANA to register it. And IANA has already responded and listed that they understood the required actions. > -- Appendix A, general: > > Why is this in an appendix? It seems central to the draft. lots of readers will stop reading when they get to the references sections. > > > In the last point I disagree. The appendix is the right place as it only provides a summary list of the verification steps of 2.3., 3.3. and 4.3. and how to bind it all together. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf