Hi Elwyn and Carl, thank you for your review. (Some small comments from my side as the WG chair and document shepherd.) I'm glad Carl could solve most of the DISCUSS items. And I am in full agreement with his comments and the proposed changes. My Comments on the open issues are inline and marked with [TG].
Tobias > -----Original Message----- > From: Elwyn Davies [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 31, 2006 8:18 PM > To: Carl Wallace > Cc: General Area Review Team; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > Tobias Gondrom; Russ Housely > Subject: Re: Gen-art review of draft-ietf-ltans-reqs-09.txt > > 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. [TG] A specific implementation of the service might be a third party service. The specific role of the "owner of a document or data" is not of main important concern, the document views him in his specific functional roles: Originator, Submitter, Retriever, Modifier and Arbitrator. The functional requirements e.g. in section 4.1 do specify that the operations of retrieval, etc. must be authenticated and authorized. (comment from Tobias: the legal role of the "owner" may vary depending on countries and scenarios. (in some the owner might be the writer, in others a legal entity, etc.) In all cases the system must apply access control as agreed with the users of its service.) > > > >> 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. [TG] Hm, am not sure: Which text should be changed to make this clearer? We could either remove this sentence as it merely describes a general observation and is not a requirement itself. Or we could change it to e.g. "If the archived data object itself contains digitally signed data, other systems integrated or working with the LTA might also authenticate the signer based on this information." Would this be better? > > > >> 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. [TG] Hm I am not sure: I believe that the addition to the Sec Considerations is sufficient, but maybe we can add a sentence to the bullet list in sec4.2.1: "- manage encrypted content including ways to change its encryption in an auditable and accurate way" Would this solve your concern? (note: If you say this item is more a "comment" than a "discuss" I would prefer to keep section 4.2.1 as it is.) > > > >> 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. [TG] Again I feel that the section is already clear enough, but however: How about add a last sentence to the last paragraph in sec4.2.1. "The service may use individual archive policies for every object, or groups or system wide archive policies." ([TG] this one here is my last comment in this email, as I found that all other issues have already been resolved by agreed changes or explanations.) > > > > > >> 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
