NEW: Preferred email for non-IBM matters: [EMAIL PROTECTED]
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-ltans-ers-13.txt
Reviewer: Brian Carpenter
Review Date: 21 May 2007
IESG Telechat date: 24 May 2007
Summary: This draft is basically ready for publication, but the reviewer has
three questions.
Comments:
Substantive:
------------
The General AD is certainly more qualified than this reviewer for
this topic, and I have not verified the ASN.1. The document is clear
and seems ready except for three points:
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?
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?
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.
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_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
