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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 May 2007 11:43:48 +0200

NEW: Preferred email for non-IBM matters: [email-masked]

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Tobias Gondrom" <[email-masked]>
Date: Wed, 23 May 2007 14:40:07 +0200

Ok, after conferring with Carl: 

We will remove both unused references.
(reasons: The references are not so important and when LTAP will become
RFC later, it will reference the ERS RFC.)

Tobias

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, May 21, 2007 8:38 PM
> To: Tobias Gondrom; Brian E Carpenter; General Area Review Team
> Cc: [email-masked]; [email-masked];
> [email-masked]; Tim Polk; [email-masked]
> Subject: Re: [Gen-art] RE: Gen-ART review of
draft-ietf-ltans-ers-13.txt
> 
> The RFC editor does not allow documents to be listed as references
> that are not referred to in the text.
> 
> Russ
> 
> At 02:01 PM 5/21/2007, Tobias Gondrom wrote:
> > > Editorial:
> > > ----------
> > >
> > > == Unused Reference: 'I-D.ietf-ltans-ltap' is defined on line
1117,
> >but no
> >[tg]: We thought we should leave them in as Informational references
as
> >they provide information about the context of the draft.