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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf