Subject: [Gen-art] Gen-art review of draft-ietf-ltans-reqs-09.txt

From: Elwyn Davies <[email-masked]>
Date: Wed, 25 Oct 2006 15:52:07 +0100

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.

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.

Regards,
Elwyn Davies

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 27 Oct 2006 09:31:27 -0700

Responses inline throughout prefaced by [CRW]. 

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2006 10:52 AM
> To: General Area Review Team
> Cc: Mary Barnes; [email-masked]; 
> [email-masked]; 
> [email-masked]; 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).
> strength of encryption and authentication mechanisms over time. Also 
> not explicitly pulled out as a security threat.
[CRW] The -00 draft did use 2119 language, but the WG felt it was not
appropriate in this sort of document.
 
> 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.

> 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."  
 
> s/value/identifier/ maybe.
[CRW] Changed to identifier.
> 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 
[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.
> 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."
 
> s/may be possible/may NOT be possible/
[CRW] Changed.
 
> 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 
[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 
[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

> 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

> 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.".
 
> Addressed??  Maybe 'that has to be addressed'? Or just 'to'.
[CRW] Changed to "that must be addressed".
 
> lifetime: Is this a security matter?  Surely an operational concern or

> a requirement in s4.4.
[CRW] Moved to operational considerations section.

> 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.
 
> 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:
> >
[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.
 
> 'Long-term Archive Policy')
[CRW] Removed "named".
 
> cryptographically) signs'.
[CRW] Added "digitally".
 
> 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.

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 31 Oct 2006 19:18:10 +0000

Hi.

Thanks for the quick response.
A few comments inline.

/Elwyn
Carl Wallace wrote:
>> (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
>> =======
>> - 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.
>>     
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
I am surprised about this.  It struck me as something that is important 
to something that is specifically targeting 3rd party services.
>> 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.  
>>     
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.
>>     
>> 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.
>>     
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.
>>     
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).
>>     
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.
>>>
>>>       
>> 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.
>>     
>> lifetime: Is this a security matter?  Surely an operational 
>> concern or a requirement in s4.4.
>>     
>> 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.
>>     
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:
>>     
>> 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.
>>     
>> 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: '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: 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 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.
>>