Document: draft-ietf-ltans-reqs-09.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Wednesday 10/25/2006 9:52 AM CST IETF LC Date: October 23, 2006 IESG telechat Date: October 26, 2006 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. 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). 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? 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. 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. 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. 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. 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. 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). 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/ 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. s4.4: Maybe this should come ahead of s4.2 which needs to know about these reqs. 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. 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'. 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. 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. 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. 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.' 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). s2: 'Archivation period': Ugh! Try 'Archival Period'. s2: 'Crytographic Maintenance Policy': Being 'named' doesn't seem important. Maybe 'specific' or just omit 'named'. (also applies to 'Long-term Archive Policy') s2: 'Originator': Would be worth emphasizing '*digitally* (or cryptographically) signs'. 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. s3, para 3: s/an other/another/ s3, para 5: s/the existence of archived data object/the existence of an archived data object/ 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.