RE: [dss] Timestamping

["Gregor Karlinger" <gregor.karlinger@cio.gv.at>]

All,

I agree with Nick: If we decide to support only time stamp tokens
that can be represented by a signature comprising

  * the hash presented the requester together with

  * a couple of signed/unsigned attributes

we should conceive a time stamp token as a kind of signature, similar
to other use cases we have identified.

We should  

  * define a syntax for the signature

  * define a couple of widely usable attributes

  * define a protocol by which the requester can tell the signature
    service how to combine signature and attributes in order to create
    a particular kind of signature (in the creation use case), or which
    combination of signature and attributes is expected by the requester
    (in the verification use case).

Regards,
Gregor Karlinger
          

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com] 
> Sent: Monday, March 24, 2003 5:41 PM
> To: Robert Zuccherato; dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping
> 
> 
> Robert,
> 
> I see we have language problem.  I see the syntax just a 
> component of the
> protocol.
> 
> I Re-run my argument with syntax instead of protocol.
> 
> If we have to define a different syntax for all the
> different potential semantics of a DSS service then we are 
> going have to
> define a
> multitude of syntaxes.  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  
> syntax for each then
> we will never finish our job.  Also, if we do have a separate 
> syntax for
> time-stamping I am concerned also about the need for a
> separate syntax for verification of time-stamps.
> 
> Nick
> 
> > -----Original Message-----
> > From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com]
> > Sent: 24 March 2003 15:53
> > To: 'Nick Pope'; dss@lists.oasis-open.org
> > Subject: RE: [dss] Timestamping
> >
> >
> > 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
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> 
>

smime.p7s