[Gen-art] RE: Gen-ART review of draft-ietf-ltans-ers-13.txt

["Tobias Gondrom" <[e-mail]>]

Hello Brian, 

thank you very much for your review. 
Answering to your questions: 

> 1. At the end of section 4.2:
> 
>  The data (e.g. certificates, CRLs or OCSP-Responses) needed to verify
>  the timestamp SHOULD be stored in the timestamp itself or MUST be
>  preserved otherwise.
> 
> I find this insufficiently clear. When would it be acceptable not to
> store these data in the timestamp, and if not done so, how would the
> retriever know where to look?

[tg]: There are three main reasons why we did intentionally write this
up in this level of detail: 
At first, most of the verification of a RFC3161-timestamp has been
documented very well in the timestamp and CMS specifications. Second,
ERS is open for other timestamps as well (e.g. ISO-18014-x) and they may
(and do) require other verification data than RFC3161, plus these other
formats may not be able to store all the necessary information for
verification inside their data structures. 
And third, as some of the verification data may be dependent on the use
case and country where it is verified, the WG works on the I-D
http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-01.txt to
describe the verification and the required data in more detail. 


> 2. Just before section 5.1:
> 
>  After the renewal, always only the last, i.e. most recent
>  ArchiveTimeStamp and the algorithms and timestamps used by it must be
>  watched regarding expiration and loss of security.
> 
> This raises a general question - maybe this is well understood in
LTANS,
> but RFC 4810 didn't clarify it for me. When a hash or crypto algorithm
> becomes "insecure" is not a well-defined moment. What is the
triggering
> event for a Time Stamping Authority to decide to switch to a new 
> algorithm, for example? What is the significance of the rather under-
> defined data stored in cryptoInfos (section 3.1)? If it says "SHA1
valid 
> until 2010" does that means it is or isn't OK to use SHA1 to generate 
> timestamps in December 2009? Maybe all this is documented elswehere?

[tg]: In general the cryptographer community has defined criteria when
an algorithm is "insecure". (E.g. one would be "when it no longer
fulfils its defined protection profile".) 
The exact time (day, hour and second) when an algorithm becomes insecure
may not be 100% defined. E.g. the time span when algorithms are
officially accepted as secure may differ by country. E.g. some countries
may name a specific official end-date (e.g. 31.12.2008) after which the
algorithm is no longer accepted as secure although it has not been
broken by then. These dates may deviate from country to country.
These local differences can not be resolved by the standard. 
The ID draft-ietf-ltans-validate-01.txt shall also provide guidance on
this. 

As further explanation: Generally there are two ways to look at this:
a) Retrospectively from the point of view of the verification party in
the future: At a future point in time a verification party will verify
the Evidence Record and in the process will compare the time until when
the algorithms and certificates have been used with the times they where
considered secure by them, by their government or policies of other
regulating bodies accepted by the verification entity. 
The mentioned instance of the cryptoInfos (i.e. the "SHA1 valid until
2010") can be a helpful hint, allowing a more efficient run of the
verification routine. 
b) Thinking forward from the point of view of the Long-term archive
service protecting its data:
The service must continually monitor the cryptographic developments
around the algorithms used by its hashtree and timestamps. This can also
be achieved by watching government bodies like NIST or e.g. the German
"Bundesnetzagentur" and others who publish information on the security
of algorithms. If these bodies indicate that some of the algorithms will
be broken soon, the LTA service must apply the according
timestamp-renewal or hashtree-renewal with new stronger algorithms. 


> 3. Finally, I'm surprised that the redundancy mentioned in the
Security 
> Considerations is only a recommendation. To my taste, it would
> be a MUST, since we are discussing the *really* long term here.

[tg]: "MUST" is not appropriate here:
The unbroken chain of one Evidence Record clearly proofs the integrity
of the data. Of course as we wrote in the Security Considerations it's
recommended to keep a redundant ER to counter the risk of retrospective
loss of security of some of the used algorithms. And you might even
consider triple redundancy where possible. 
But, some systems may not be able to offer this redundancy, e.g. if they
do not implement additional redundant algorithms or even if there is
only one secure algorithm available to them (note: e.g. many timestamp
servers tend to use the same one algorithm and many systems e.g. only
implemented SHA-1). 
And if the used algorithms in the non-redundant systems are not broken
before they will have been renewed, their Evidence Records are
absolutely trustworthy and MUST be verified with "ok", although they did
not run with redundant other algorithms. 
So, basically, the level of redundancy is a quality of the Long-term
archive service. 
(And last but not least: ERS is defining a syntax/data structure, not
the system.) 
To summarize: It would not be fair to exclude smaller providers/services
by raising this bar to "MUST", plus it MUST NOT be necessary to verify
that a second redundant Evidence Record exists just to verify the first
one, and there may even be situations where only one secure algorithm is
available. 

 
> Editorial:
> ----------
> 
> == Unused Reference: 'I-D.ietf-ltans-ltap' is defined on line 1117,
but no
>    explicit reference was found in the text
> 
> == Unused Reference: 'RFC3029' is defined on line 1144, but no
explicit
>    reference was found in the text


[tg]: We thought we should leave them in as Informational references as
they provide information about the context of the draft. 


Best wishes, 

Tobias



> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Monday, May 21, 2007 11:46 AM
> To: General Area Review Team
> Cc: [e-mail]; [e-mail];
> [e-mail];
[e-mail];
> Tim Polk
> Subject: Gen-ART review of draft-ietf-ltans-ers-13.txt
> 
> NEW: Preferred email for non-IBM matters: [e-mail]
> 
> Sorry, forgot to copy Tim the first time...



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