RE: [dss] Timestamping

[Robert Zuccherato <robert.zuccherato@entrust.com>]

Nick;

I also don't want to see a proliferation of protocols in this TC.  I think
it is entirely reasonable though to have one protocol that returns either a
(conventional) signature or a signed time stamp info object, depending upon
which is being requested.

	Robert.

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: Saturday, March 22, 2003 10:11 AM
> To: dss@lists.oasis-open.org
> Cc: Robert Zuccherato
> Subject: RE: [dss] Timestamping
> 
> 
> Trevor, Robert,
> 
> I agree with what Trevor has stated in his earlier messages.
> 
> If we have to define a different protocol for all the 
> different potential
> semantics of a DSS service then we are going have to define a 
> multitude of
> protocols.  Depending on the different inputs and output options being
> considered the DSS will have different semantics.  We have 
> already defined
> in the use cases which have different semantics: e.g. for individal
> signatures, corporate seals, delegated signatures, protecting SOAP
> exchanges, notarisation .....  If we define a separate 
> protocol for each
> then we will never finish our job.  Also, if we do have a 
> separate protocol
> for time-stamping I am concerned also about the need for a 
> separate protocol
> for verification of time-stamps.
> 
> In addition, having taken part in & watched years of discussion on the
> "non-repudiation bit", the exact semantics, and by implication legal
> liabilities, associated with signed data is much more than a technical
> question.
> 
> I suggest that a more efficient approach would be as 
> mentioned at the last
> DSS meeting:  that is to define a generic protocol with profiles for
> specific uses.  One of these profiles can be for time-stamping.
> 
> Nick
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com]
> > Sent: 21 March 2003 15:17
> > To: dss@lists.oasis-open.org
> > Subject: RE: [dss] Timestamping
> >
> >
> > Trevor;
> >
> > My feeling is that the semantics of a TSA's signature is 
> substantially
> > different enough from the semantics of other signatures 
> that it warrants a
> > separate syntax, or <TSTInfo>, for the signed data.  Thus, I
> > support option
> > B below.
> >
> > Let's compare the timestamping scenario with the Corporate 
> Seal use case
> > where only the hash of the data is sent to the server and the server
> > includes a time-mark (as some sort of authenticated 
> attribute).  This use
> > case is probably the closest in practice to the 
> timestamping scenario.  In
> > both situations the server sees only the hash of the data 
> and in both
> > situations the server is appending the current time in some 
> fashion.  The
> > semantics of the two situations are very different though.  
> The TSA is not
> > purporting to have originated the data and is not agreeing 
> to the data in
> > any way.  It is simply purporting to have seen the hash at 
> that time.
> > However, in the Corporate Seal use case I argue that even though
> > the server
> > itself has not seen the actual data, the entity that has
> > submitted the data
> > to the server has and thus the server can claim to have
> > originated the data
> > or can agree to the data on behalf of that submitter.  This is why
> > authentication to the server in this use case is so 
> important.  The server
> > is actually delegating some of it's responsibilities as a 
> signer to the
> > submitter and must authenticate that the submission is from 
> a trusted
> > entity.  Thus, the corporate seal provides origin 
> authentication or agrees
> > to the data on an organizational level.
> >
> > Now, we could still load all of these semantics into some 
> sort of signed
> > attribute and if we could be sure that the attribute would always be
> > honoured, this would likely be fine.  However, we don't have any
> > criticality
> > defined for authenticated attributes in most of the signature
> > formats that I
> > can think of.  Thus, I believe that it is likely that these 
> TSA signatures
> > will be mis-interpreted.  The safe way of doing things, I 
> believe, is to
> > have a separate syntax for timestamped data.
> >
> > 	Robert.
> >
> > > -----Original Message-----
> > > From: Trevor Perrin [mailto:trevp@trevp.net]
> > > Sent: Tuesday, March 18, 2003 4:38 PM
> > > To: dss@lists.oasis-open.org
> > > Subject: [dss] Timestamping
> > >
> > >
> > >
> > > The requirements subcommittee is considering what the
> > > requirements should
> > > be for a timestamp format and protocol.  We'd like some input
> > > from the
> > > group, since this hasn't had much discussion yet.
> > >
> > > Currently, the notions of time-marked signatures and time-stamped
> > > signatures have been defined:
> > >
> > > A time-marked signature is just a signature on some content
> > > with a signed
> > > attribute (created by the signer) containing the signing time.
> > >
> > > A time-stamped signature contains, as an unsigned attribute,
> > > a timestamp
> > > "token", which somehow binds the time and a hash of the 
> time-stamped
> > > signature's signatureValue, and is created and signed by a
> > > 3rd party TSA
> > > (Time Stamp Authority).
> > >
> > > More generally, a timestamp token may be used to timestamp
> > > other things
> > > than a signatureValue.
> > >
> > > Now, whatever format the timestamp token takes, a timestamp
> > > protocol just
> > > requires the client send a hash and receive back a token.
> > > This shouldn't
> > > be any different from the DSS protocol used in the
> > > "client-side hashing"
> > > and "receiving a detached signature" case.  Thus,
> > > time-stamping should just
> > > be a use-case of the DSS protocol, not a separate protocol.
> > >
> > > As for an XML timestamp token format, there's two approaches:
> > > A) Define a time-stamp token as just a time-marked signature
> > > produced by a
> > > 3rd-party that's trusted as a TSA.
> > > B) Define a time-stamp token as a signature on some new
> > > <TSTInfo> structure
> > > containing a hash of the to-be-timestamped data and the time.
> > >
> > > In (A), the TSA produces a normal signature using the hash of the
> > > to-be-timestamped data, with time as a signed attribute.  In
> > > (B), the TSA
> > > combines the hash of the to-be-timestamped data with the time
> > > into a new
> > > structure, and produces a normal signature on that.  (B) is
> > > the approach
> > > used in RFC 3161, which is PKIX's timestamping protocol, and
> > > is used to
> > > timestamp CMS signatures.
> > >
> > > The benefit of (A) is that timestamps aren't handled
> > > differently from any
> > > other signature type, they're just a particular "semantics"
> > > instead of
> > > "syntax".  The argument against this, is that timestamps
> > > *are* different
> > > from other signatures:  Normally signatures testify that the
> > > contents are
> > > associated with the signer as an originating entity, not that
> > > the contents
> > > are associated with a time.  So timestamps should have a
> > > different syntax
> > > to ensure that they're processed correctly, and that a 
> Relying Party
> > > understands that the time is the important thing, and doesn't
> > > mistakenly
> > > ignore a signing-time signed attribute and think the TSA
> > > originated the
> > > to-be-signed data.
> > >
> > > One way of framing the question: what are the semantics of a
> > > raw, DSIG
> > > signature?  If a DSIG signature is just a statement of the
> > > form "someone
> > > says something about some data", where
> > >   - the speaker ("someone") is identified with a <KeyInfo>
> > >   - the object ("some data") is identified with a <SignedInfo>
> > >   - the predicate (what is being said about the object) is
> > > identified by
> > > the <KeyInfo>'s properties/policy identifiers and signed 
> attributes
> > >
> > > Then asserting that the data existed at a certain time is
> > > just another
> > > predicate that can be asserted about <SignedInfo>, along with
> > > asserting
> > > that you originated it, or asserting that you agree to its
> > > contents, or
> > > asserting that it really came from some Identified Requestor.
> > >
> > > But if a DSIG signature also carries the semantics that the signer
> > > originated the data, then it would be misleading for a TSA to
> > > produce a
> > > signature on the to-be-timestamped hash while relegating the
> > > signing time
> > > to a signed attribute (but then wouldn't any use case where
> > > the server
> > > didn't originate the data, but just signed a hash, be 
> misleading?).
> > >
> > > But that may be unfair (I'm biased towards A).  What do other
> > > people prefer?
> > >
> > > Trevor
> > >
> >
> >
> 
>