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.
> 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.
> 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.
> 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.
> 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.
> 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."
> 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.
>
> 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
