RE: Clarification of ISO-IEC 18014 documents

["Tobias Gondrom" <tgondrom@xxxxxxxxxxxx>]

Hello,

from what I know of the ISO 19014 I see no reason to deviate from the
current course. It is one thing to provide a solution for a single
timestamp ro document but another to concur with the aggregation and
support of large numbers of documents as provided by ERS. (In fact this
was one of the most important attributes in the first place, cause if
you only consider one document or one signature you could do this by
hand simply by applying a new timestamp on container (e.g. zip) of a
document and its RFC3161 TS and you are done. 

The main problem was to aggregate large numbers of documents with high
performance. And I can not see that this is covered by ISO 18014. 

Second I will not rely or speculate on a solution that is currently
"work in progress" at ISO to consider whether ERS should be stopped in
this final stage. I would rather turn the arguments around and say ISO
should consider taking a closer look at IETF ERS draft which is ready
now and in case they plan to dublicate its functionality, reconsider
whether this would be very wise. 

Tobias


> -----Original Message-----
> From: owner-ietf-ltans@xxxxxxxxxxxx
[mailto:owner-ietf-ltans@xxxxxxxxxxxx]
> On Behalf Of Young H Etheridge
> Sent: Thursday, January 18, 2007 2:47 AM
> To: Carl Wallace
> Cc: ietf-ltans@xxxxxxx
> Subject: Re: Clarification of ISO-IEC 18014 documents
> 
> 
> Yes, the spec is rather opaque in that regard.  Fortunately,
> 18014-1-revised will do so.
> 
> It seems to me that aggregation would need to be built into extRenewal
> or other EXTENSIONS in a standard way.
> 
> I agree the opportunity for change has been waiting about for well
over
> a year.  How many applications are ready for this draft to be a
standard?
> 
> Carl Wallace wrote:
> >
> > I see.  So it does address the coverage of original and current
hashes
> > (if only the spec had included language about verification of
> > extRenewal I might have caught that).  How about support for
> > aggregation?
> >
> > Aside from the technical bits, there's also the question of whether
an
> > 11th hour request like this is justifiable.
> >
> > > -----Original Message-----
> > > From: Young H Etheridge [mailto:yhe@xxxxxxxxxxxxxxx]
> > > Sent: Wednesday, January 17, 2007 5:33 PM
> > > To: Carl Wallace
> > > Cc: ietf-ltans@xxxxxxx
> > > Subject: Re: Clarification of ISO-IEC 18014 documents
> > >
> > > As I understand the process:
> > >
> > > A TSA that supports renewal requests, in response:
> > >   - generates a new TSTInfo,
> > >   - copies the hash value from the request into the TSTInfo,
> > >   - copies the extRenewal extension from the request into an
> > > extRenewal
> > >     extension of the TSTInfo with this extRenewal containing
> > > the desired
> > >     original TS,
> > >   - sets the current time and fills in the other fields of
> > > TSTInfo, and
> > >   - proceeds to generate the renewal timestamp token for this
TSTInfo.
> > >
> > > Unless I misunderstand the process this renewal timestamp
> > > token covers both the submitted hash value and the previous
> > > timestamp token regardless of the method is used by the TSA
> > > for generating the ContentInfo.
> > >
> > > This process is echoed in the revised 18014-1text.
> > >
> > > Carl Wallace wrote:
> > > >
> > > > In response to Denis' post, I reviewed the mechanisms in
> > > 18014-3.  How
> > > > do those align with the text from -1?
> > > >
> > > > > -----Original Message-----
> > > > > From: Young H Etheridge [mailto:yhe@xxxxxxxxxxxxxxx]
> > > > > Sent: Wednesday, January 17, 2007 4:19 PM
> > > > > To: CWallace@xxxxxxxxxxxx
> > > > > Cc: ietf-ltans@xxxxxxx
> > > > > Subject: Clarification of ISO-IEC 18014 documents
> > > > >
> > > > > Carl,
> > > > >
> > > > > A clarification of the ISO 18014 documents may be useful.
> > > > >
> > > > > ISO-IEC 18014-1-2002 uses the term TS reissue to intend
> > > TS renewal
> > > > > in the terms as expressed in WG communications of late.  I
quote:
> > > > > "A time-stamp re-issue may also be necessary when the
> > > hash--function
> > > > > used to form the hash value from the original data is called
into
> > > > > question.  In this case, both the old time-stamp token and the
> > > > > original data must be included in the newly calculated hash
value
> > > > > submitted for time-stamp reissue."
> > > > >
> > > > > A revision of 18014-1 is in-progress.  The term reissue is
being
> > > > > replaced with renewal along with descriptive information
> > > that makes
> > > > > the point clear that a renewal contains a hash of the data
along
> > > > > with the hash of the original TS that is being renewed.  The
new
> > > > > description is quite clear in regard to creation and
> > > verification of
> > > > > renewal.
> > > > >
> > > > > Furthermore, ANSI X9.95 is consistent on renewal with
> > > those found in
> > > > > 18014-2-2002, 18014-3-2004 and the revision of 18014-1-2002.
> > > > >
> > > > > I hope this helps.
> > > > >
> > > > > yhe
> > > > >
> > > >
> > >
> >