Hi.
Thanks for the quick response.
A few comments inline.
/Elwyn
Carl Wallace wrote:
Responses inline throughout prefaced by [CRW].
-----Original Message-----
From: Elwyn Davies [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:52 AM
To: General Area Review Team
Cc: Mary Barnes; [EMAIL PROTECTED];
[EMAIL PROTECTED];
[EMAIL PROTECTED]; Tobias Gondrom; Russ Housely
Subject: Gen-art review of draft-ietf-ltans-reqs-09.txt
I have been selected as the General Area Review Team
(Gen-ART) reviewer for this draft (for background on Gen-ART,
please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these (slightly belated - sorry) comments
along with any other Last Call comments you may receive. (I
understand this has now gone forward to the IESG so you will
have to consult your AD about what to do next).
Summary
=======
This document needs further work (it is not ready for publication).
The main concerns which I have are:
- No discussion of ownership of archived data
- No discussion of interactions with legal requirements (data
being subpoenaed, privacy and data protection issues)
- Lack of actual requirements for functions to deal with
decay in the strength of encryption and authentication
mechanisms over time. Also not explicitly pulled out as a
security threat.
- Lack of clarity as to whether signatures used by the LTA
may or may not be embedded in the archived data (as opposed
to the Evidence Record).
There is also need for editorial clean up as some issues
appear to be mentioned twice in adjacent pieces of text.
Issues
======
Use of RFC 2119 requirements language: This document doesn't
and it certainly could do.
[CRW] The -00 draft did use 2119 language, but the WG felt it was not
appropriate in this sort of document.
OK.
s2: Isn't there a need for an 'Owner' as well as Submitter
and Originator? The Submitter might die (if a person), be
taken over (if a
company) or sell the data (either).
[CRW] The concept of an "owner" does not particularly influence the
specifications this document is aiming to establish requirements for.
There was initially a parallel requirements document for notaries, but
that work was suspended. At present, the only nod in this direction is
text identifying access control as a security consideration.
I am surprised about this. It struck me as something that is important
to something that is specifically targeting 3rd party services.
s3, para 5:
If the
archived data object itself contains digitally signed data,
authentication of the signer is also possible.
Is this a requirement or function of the LTA?
[CRW] This is not a requirement of the LTA. It is an observation that
it may be possible to act upon the data handled by the LTA to perform
additional verification steps.
Maybe what is
meant is that if the associated Evidence Record contains a
digital signature then the signer can be authenticated -
surely the LTA should not expect to interpret or authenticate
signatures 'contained in' the archived data object.
[CRW] The statement aims to convey the idea that the relying party may
verify signatures contained in the data that was covered by the evidence
record.
That is fair enough but the wording is not IMO sufficiently clear that
this is not something the LTA can do anything about and would not be
expected to understand in the data. I am clear that the general
principles don't expect this but some of the following text muddies the
waters.
This is
further confused by explicit mention of (separate) signature
files (as archived data objects) in s4.7. I think it is
vitally important that the requirements make it quite clear
that the LTA should not and generally cannot make any
assertions about the semantics of the archived data objects:
all they are trying to do is preserve their integrity as
opaque chunks of data, and any interpretable data needs to be
kept separate in the evidence record.
[CRW] Generally agree, but don't feel we should preclude an LTA from
acting on data if it understands the data. This is expressed in the
General Principles section as follows: "A long-term archive service may
preserve archived data objects as opaque collections of bytes with the
primary aim of data integrity. A long-term archive service is not
required to operate upon evidence related to the content of archived
data objects. Content-focused operations, including data format
migration or translation, may be performed by another service. However,
an LTA may incorporate support for such services."
s4.1.1:
Following submission, the service must provide a value that can be
used to retrieve the archived data and/or associated evidence.
s/value/identifier/ maybe.
[CRW] Changed to identifier.
s4.2: Shouldn't this section contain requirements for methods
to maintain the cryptographic strength of any authentication
or encryption methods used? For very long term storage this
will be an essential management requirement IMO.
[CRW] These requirements may differ from one context to another. A new
security consideration was added in response to another comment that
clarifies the expectation that organizational or governmental
authorities will establish policies for use of cryptographic algorithms
at specific points in time.
That is good, but in line with some of the other comments from the IESG,
it strikes me that being able to change the encryption in a traceable
and guaranteed accurate way is something that is actually a requirement
under some circumstances as well as a security consideration.
s4.2.1, last para: Is the indication of the policy enforced
intended to be the overall policy or the effective per object
policy (i.e. the LTA's policy as modified by the submitter's
per object policy)? This duplicates/interacts with reqs in
s4.4 - see below.
[CRW] It's expressed as per object but an LTA may operate with a single
policy.
I suggest you make the text more consistent to avoid this sort of confusion.
s4.2.1 et seq: Some statements about the impact of legal
requirements on an LTA are needed. An LTA may well have to
respond to requests from governments and other state bodies
to retrieve data when subpoenaed.
This may have some impact on deletion requests (an LTA may
need to preserve data even if the submitter (or other
authorized principal) asks for deletion - no shredding of
evidence!). Also there may be interactions with data privacy
and/or data protection laws (a LTA would almost certainly
need to be a party to certain statements in the EU if the
data is not encrypted).
[CRW] Added a new operational consideration to capture this concern: "An
LTA must be capable of operating in accordance with any applicable legal
regime. For example, an LTA may be required to reject a deletion
request from an authorized requestor if the target of the request has
been subpoenaed by law enforcement authorities."
OK
s4.3.1, para 2:
For example,
authentication of an originator may be possible in all
cases, e.g.,
where the object submitted to the archive is not signed
or where the
object does not include the necessary information to
authenticate the
object's signer.
s/may be possible/may NOT be possible/
[CRW] Changed.
As with the point about s3, para 5, I think it needs to be
clarified that an origination signature embedded in the
archived data object can't be the basis of the LTA's
authentication of the originator - the LTA needs to know that
a piece of the (meta)data is the originator's signature
before it can offer any view as to the integrity of the signature.
[CRW] I don't think we need to preclude recognition of a data format.
For example, an LTA could incorporate a DVCS component that recognizes
and acts upon the data carried in the archived data object.
s4.4: Maybe this should come ahead of s4.2 which needs to
know about these reqs.
[CRW] Moved old section 4.4 to be new section 4.2.
s4.4.2, last para: This raises some concerns about the
'contract' under which an object is originally submitted to
an LTA. If a submitter requests certain policies originally,
s/he needs to agree either upfront or on a case by case basis
to changes which affect the policies
requested: it implies need to inform the submitter of
proposed changes or be able to specify no policy changes
maybe. Things may be a little fraught if the submitter
discovers that the policies have changed under his feet, and
are no longer to her liking. I see this is sort of mentioned
in the security section.
s6: I would have expected to see some discussion of the
effective decay of the strength of cryptographic algorithms here.
[CRW] Added a new security consideration: "A long-term archive system
must perform maintenance activities on a schedule that considers factors
such as the strength of relevant cryptographic algorithms, lifespan of
relevant certification authorities, and revocation status of relevant
entities, e.g., timestamp authorities. Standards for use of
cryptographic algorithms are expected to be established by organization
or governmental bodies, not by individual LTAs.".
s6, para 1:
The principle threat addressed by a long-term archive service is
undetected loss of data integrity.
Addressed?? Maybe 'that has to be addressed'? Or just 'to'.
[CRW] Changed to "that must be addressed".
s6, para 5: Checking compatible policies are used throughout archival
lifetime: Is this a security matter? Surely an operational
concern or a requirement in s4.4.
[CRW] Moved to operational considerations section.
Editorial
=========
s1, para 1: The term 'cryptanalysis period' is not AFAICS a
well-known term of the art. I *think* I understand what is
implied here (something about how long it might take to break
the algorithm???) but this needs explaining.
[CRW] This term is used elsewhere in IETF (see RFC3647). Added "i.e.,
the time after which an algorithm no longer provides the intended
security properties." to the end of the section in paragraph 1.
Good. This term seems to have appeared in RFC2527 and then been copied
into 3647 but it isn't actually defined in either of them and AFAICS it
is not in general use.
s1, para 2: s/non-reputability/non-repudiability/ (I believe
this is about requiring that it should not be possible to
*repudiate* the fact of data existence.) I think this piece
could be better phrased - I had difficulty parsing it:
and the non-reputability of data existence by a particular point in
time
It is possible that it is actually saying the same thing as
the next paragraph and the situation could be cleared up by
just omitting the examples in para 2.
[CRW] Changed to non-repudiability. Reworded the list of examples
slightly as follows: "For example, it might periodically perform
activities to preserve data integrity and the non-repudiability of data
existence by a particular point in time or take actions to ensure the
availability of data."
s1, para 3: (this is related to the point about para 1 I
think): 'beyond ... the validity of algorithms': To the best
of my knowledge, cryptographic algorithms do not 'expire' -
they remain valid algorithms in the sense that they do what
they claim for ever. This piece is about the 'best before
date' on the algorithm: improvements in methods and speed of
computation may render crytographic techniques less useful
over time. Suggest something like 'even beyond the time when
the algorithms used ... cease to offer effective protection
because of improvements in computing speeds and methods.'
[CRW] Accepted suggested wording.
s2: It would be good to consistently capitalize all the words
in defined terms (some are, some aren't at the moment) and
also where they are used especially in the terminology (e.g.,
'... associated Evidence Record' in Archive Package definition).
[CRW] Adjusted the capitalization in the terminology section changing
"Evidence record" to "Evidence Record" and etc. throughout this section.
s2: 'Archivation period': Ugh! Try 'Archival Period'.
[CRW] Changed.
s2: 'Crytographic Maintenance Policy': Being 'named' doesn't
seem important. Maybe 'specific' or just omit 'named'. (also
applies to 'Long-term Archive Policy')
[CRW] Removed "named".
s2: 'Originator': Would be worth emphasizing '*digitally* (or
cryptographically) signs'.
[CRW] Added "digitally".
s2: Expansions of TSA: Both Time Stamping Authority and
Time-Stamp Authority are used: Choose one (RFC3161 uses the
unhyphenated version - Time Stamping Authority - but also
uses time-stamp)! Also time-stamps and time stamps are used:
Again choose one.
[CRW] Changed to Time Stamping Authority and time stamp throughout.
s3, para 3: s/an other/another/
[CRW] Fixed.
s3, para 5: s/the existence of archived data object/the
existence of an archived data object/
[CRW] Fixed.
s4.2.1: The sentence after the bullets ('It should be
possible to extend or shorten the archivation period after
the initial submission.') duplicates the 2nd bullet.
[CRW] Deleted the sentence and left the bullet.
Regards,
Elwyn Davies
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
