[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [dss]
Minutes of the DSS TC meeting of March 10, 2003
1. Welcome by chair.
2. Roll call.
Voting Members
Carlisle Adams, Entrust
Greg Alvord, self
Steve Anderson, OpenNetwork Technologies
Dimitri Andivahis, Surety
Juan Carlos Cruellas, self
David Finkelstein, RSA Security
Ron Holm, Datum
Merlin Hughes, Baltimore
Burt Kaliski, RSA Security
Gregor Karlinger, Austrian Federal Ministry for Public Services and Sports
Andreas Kuehne, self
Hal Lockhart, BEA Systems
John Messing, self
Trevor Perrin, self
Nick Pope, self
Krishna Sankar, Cisco
Frank Siebenlist, Argonne National Laboratory
Kate Wang, IONA
Gideon Yuval, Microsoft
Robert Zuccherato, Entrust
Prospective Member
Krishna Yellepeddy, IBM
3. The Minutes of DSS TC Meeting Feb 24, 2003 sent out Wednesday, March 5, 2003 were approved.
4. Use Case Subcommittee Report
Use cases: some comments were made regarding a need for clarification of the use cases. By way of example, it was noted that the court filing use case needs to have the external url summarized as an Oasis document. Also the language of the use case regarding non-XML signing could be clarified. These and other points will be clarified by the use case subcommittee.
Nick Pope will be taking over the editing responsibilities vacated by Manoj Srivastava's departure from the TC.
5. Requirements stemming from the use cases
Trevor Perrin confirmed that he had become a member of the use case subcommittee. He explained his attempt at providing rough examples. He was attempting to segregate out various requirements common to the use cases. In a discussion of the TC it was observed that there was a need for the standard to be able to establish a signer's identity and a way to communicate it in a standardized way. It was observed that Oasis extensions to XML-DSIG may be required to accomplish this goal.
6. Authentication requirements and bindings/profiles
A question was posed if we were ready as a TC to segregate out authentication requirements from bindings and profiles. This was determined to be premature at this date. The subcommittee will attempt to clarify the issue by the next meeting. The examples of SAML and XKMS were cited.
7. A requirement for a co-chair was raised. The Chair noted his absence at several meetings and thought a co-chair would be appropriate. This item had been moved to item no. 1 on the agenda. Participants noted that co-chairs were preferable to vice-chairs. Nominations with the consent of the nominee would be solicited over the next few weeks. There will be a vote at the next TC meeting. The proposal was moved and seconded and adopted without objection.
8. Any other business.
An observation was made that signature authentication must be reflected as part of the signature or the signed data.
9. Close.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
Received: (qmail 25026 invoked by uid 60881); 19 Mar 2003 23:13:21 -0000
Received: from dimitri@surety.com by hermes by uid 0 with qmail-scanner-1.15
(spamassassin: 2.43. Clear:SA:0(-1.1/8.0):.
Processed in 0.363202 secs); 19 Mar 2003 23:13:21 -0000
X-Spam-Status: No, hits=-1.1 required=8.0
Received: from unknown (HELO drake.surety.com) (216.33.115.19)
by mail.oasis-open.org with SMTP; 19 Mar 2003 23:13:21 -0000
Received: from doris (doris.surety.com [141.156.119.10])
by drake.surety.com (8.11.6/8.11.6) with SMTP id h2JNLAv18452
for <dss@lists.oasis-open.org>; Wed, 19 Mar 2003 18:21:10 -0500
From: "Dimitri Andivahis" <dimitri@surety.com>
To: <dss@lists.oasis-open.org>
Subject: RE: [dss] Timestamping
Date: Wed, 19 Mar 2003 18:21:16 -0500
Message-ID: <FIEMJFOPLDNKKPDGBEGHGEMIDCAA.dimitri@surety.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <5.2.0.9.0.20030318130100.00bb1a28@postoffice.pacbell.net>
Trevor,
> -----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
>=20
>=20
>=20
> The requirements subcommittee is considering what the requirements =
should=20
> be for a timestamp format and protocol. We'd like some input from the =
> group, since this hasn't had much discussion yet.
>=20
> Currently, the notions of time-marked signatures and time-stamped=20
> signatures have been defined:
>=20
> A time-marked signature is just a signature on some content with a =
signed=20
> attribute (created by the signer) containing the signing time.
>=20
> A time-stamped signature contains, as an unsigned attribute, a =
timestamp=20
> "token", which somehow binds the time and a hash of the time-stamped=20
> signature's signatureValue, and is created and signed by a 3rd party =
TSA=20
> (Time Stamp Authority).
>=20
One comment on the last sentence above: 3rd party TSAs may be using=20
techniques other than digital signatures to bind the time and the hash=20
and generate the timestamp token. =20
For example, the TSAs defined for the binary protocols universe=20
in the ISO 18014-1,2,3 timestamping standards use digital signatures,=20
MACs or linking methods. If you are not familiar with them,
the ISO standards extend the protocols and data types defined=20
in RFC 3161 and are fully compatible with RFC 3161 when=20
the digital signatures method is used.
In the XML world now, there were timestamping input documents submitted=20
to this TC that contain XML Schemas covering all methods of=20
timestamping, not just the one using digital signatures.
> More generally, a timestamp token may be used to timestamp other =
things=20
> than a signatureValue.
>=20
> Now, whatever format the timestamp token takes, a timestamp protocol =
just=20
> requires the client send a hash and receive back a token. This =
shouldn't=20
> be any different from the DSS protocol used in the "client-side =
hashing"=20
> and "receiving a detached signature" case. Thus, time-stamping=20
> should just=20
> be a use-case of the DSS protocol, not a separate protocol.
>=20
I don't think the timestamping protocol should be confused with the
DSS protocol. The semantics of the two processes, requesting=20
a digital signature from a server vs. requesting a timestamp token from =
a TSA,
are totally different. Let alone, this is a non-starter=20
if the TSA generates timestamp tokens using a linking method or a MAC.
I think almost all XML Schemas for timestamping that were submitted=20
to this TC capture the complexity of the timestamp request/response
process and account for the need for a separate timestamping protocol.
> As for an XML timestamp token format, there's two approaches:
> A) Define a time-stamp token as just a time-marked signature=20
> produced by a=20
> 3rd-party that's as a TSA.
> B) Define a time-stamp token as a signature on some new <TSTInfo>=20
> structure=20
> containing a hash of the to-be-timestamped data and the time.
>=20
> In (A), the TSA produces a normal signature using the hash of the=20
> to-be-timestamped data, with time as a signed attribute. In (B), the =
TSA=20
> combines the hash of the to-be-timestamped data with the time into a =
new=20
> structure, and produces a normal signature on that. (B) is the =
approach=20
> used in RFC 3161, which is PKIX's timestamping protocol, and is used =
to=20
> timestamp CMS signatures.
>=20
> The benefit of (A) is that timestamps aren't handled differently from =
any=20
> other signature type, they're just a particular "semantics" instead of =
> "syntax". The argument against this, is that timestamps *are* =
different=20
> from other signatures: Normally signatures testify that the contents =
are=20
> associated with the signer as an originating entity, not that the=20
> contents=20
> are associated with a time. So timestamps should have a different =
syntax=20
> to ensure that they're processed correctly, and that a Relying Party=20
> understands that the time is the important thing, and doesn't =
mistakenly=20
> ignore a signing-time signed attribute and think the TSA originated =
the=20
> to-be-signed data.
>=20
> 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=20
> 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=20
> the <KeyInfo>'s properties/policy identifiers and signed attributes
>=20
> Then asserting that the data existed at a certain time is just another =
> predicate that can be asserted about <SignedInfo>, along with =
asserting=20
> that you originated it, or asserting that you agree to its contents, =
or=20
> asserting that it really came from some Identified Requestor.
>=20
> But if a DSIG signature also carries the semantics that the signer=20
> originated the data, then it would be misleading for a TSA to produce =
a=20
> signature on the to-be-timestamped hash while relegating the signing =
time=20
> 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?).
>=20
> But that may be unfair (I'm biased towards A). What do other=20
> people prefer?
>=20
> Trevor
>=20
My opinion is that we should have a separate timestamping protocol=20
for communicating with TSAs, for the reasons I described earlier.
In the interest of avoiding confusion with other timestamping standards
in the non-XML universe, I would also propose keeping timestamp tokens=20
separate from time-marks, if they are indeed different objects. =20
I'm a bit unclear on the issue of time-marking in general. I've seen a=20
short definition in ETSI 102023, but there was little detail.
=20
Could any cryptographic binding between a submitted hash and=20
a time value qualify as a "time-mark", as long as the time-mark=20
server archives "something" for each request and maintains a secure=20
audit trail, against which each "time-mark" issued may be validated? =20
If so, any of the TSAs defined in other timestamping standards=20
could be extended to do a bit of archiving and offer time-marking=20
services (time mark =3D=3D timestamp token).
Are there interesting cases of non-TSAs that offer some type=20
of time-marking service? If so, what precludes them from being =
full-blown TSAs?
Take care.
Dimitri
Received: (qmail 15389 invoked by uid 60881); 20 Mar 2003 04:36:00 -0000
Received: from trevp@trevp.net by hermes by uid 0 with qmail-scanner-1.15
(spamassassin: 2.43. Clear:SA:0(-2.9/8.0):.
Processed in 0.340193 secs); 20 Mar 2003 04:36:00 -0000
X-Spam-Status: No, hits=-2.9 required=8.0
Received: from unknown (HELO mta5.rcsntx.swbell.net) (151.164.30.29)
by mail.oasis-open.org with SMTP; 20 Mar 2003 04:36:00 -0000
Received: from TREVOR.trevp.net ([63.197.17.129]) by mta5.rcsntx.swbell.net
(iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002))
with ESMTP id <0HC10074A63KG1@mta5.rcsntx.swbell.net> for
dss@lists.oasis-open.org; Wed, 19 Mar 2003 22:35:45 -0600 (CST)
Date: Wed, 19 Mar 2003 20:35:43 -0800
From: Trevor Perrin <trevp@trevp.net>
Subject: RE: [dss] Timestamping
In-reply-to: <FIEMJFOPLDNKKPDGBEGHGEMIDCAA.dimitri@surety.com>
X-Sender: trevp@postoffice.pacbell.net
To: dss@lists.oasis-open.org
Message-id: <5.2.0.9.0.20030319164654.00bb6a08@postoffice.pacbell.net>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <5.2.0.9.0.20030318130100.00bb1a28@postoffice.pacbell.net>
At 06:21 PM 3/19/2003 -0500, Dimitri Andivahis wrote:
>Trevor,
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
[...]
> > 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).
> >
>
>One comment on the last sentence above: 3rd party TSAs may be using
>techniques other than digital signatures to bind the time and the hash
>and generate the timestamp token.
>
>For example, the TSAs defined for the binary protocols universe
>in the ISO 18014-1,2,3 timestamping standards use digital signatures,
>MACs or linking methods. If you are not familiar with them,
>the ISO standards extend the protocols and data types defined
>in RFC 3161 and are fully compatible with RFC 3161 when
>the digital signatures method is used.
>
>In the XML world now, there were timestamping input documents submitted
>to this TC that contain XML Schemas covering all methods of
>timestamping, not just the one using digital signatures.
Are there public docs for the ISO standards? They'd be interesting to look
at, since most of the timestamping submissions to the TC seem inspired by
RFC 3161 (these are the ones I remember):
http://lists.oasis-open.org/archives/dss/200211/msg00003.html - Entrust
http://lists.oasis-open.org/archives/dss/200212/msg00004.html - Juan Carlos
Cruellas
http://lists.oasis-open.org/archives/dss/200212/msg00012.html - EML
http://lists.oasis-open.org/archives/dss/200301/msg00001.html - Gregor
Karlinger
As for linking methods, only Gregor's submission discusses supporting them
in detail (though it does a good job). But are these methods practical,
and worth the effort? If so, what requirements should be added for them?
> > 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.
> >
>
>I don't think the timestamping protocol should be confused with the
>DSS protocol. The semantics of the two processes, requesting
>a digital signature from a server vs. requesting a timestamp token from a TSA,
>are totally different. Let alone, this is a non-starter
>if the TSA generates timestamp tokens using a linking method or a MAC.
>I think almost all XML Schemas for timestamping that were submitted
>to this TC capture the complexity of the timestamp request/response
>process and account for the need for a separate timestamping protocol.
Could you elaborate? Aside from linking, the above protocols all just send
a hash, and receive back a signature on the hash and time. This doesn't
seem any different than sending a hash and receiving back a signature on
the hash and any other signed attribute (such as requestor identity,
signature policy, etc..).
[...]
>My opinion is that we should have a separate timestamping protocol
>for communicating with TSAs, for the reasons I described earlier.
>In the interest of avoiding confusion with other timestamping standards
>in the non-XML universe, I would also propose keeping timestamp tokens
>separate from time-marks, if they are indeed different objects.
>I'm a bit unclear on the issue of time-marking in general. I've seen a
>short definition in ETSI 102023, but there was little detail.
>
>Could any cryptographic binding between a submitted hash and
>a time value qualify as a "time-mark", as long as the time-mark
>server archives "something" for each request and maintains a secure
>audit trail, against which each "time-mark" issued may be validated?
>If so, any of the TSAs defined in other timestamping standards
>could be extended to do a bit of archiving and offer time-marking
>services (time mark == timestamp token).
I was hoping a time mark was just when a signer adds a signed attribute
containing the time.
Maybe better terms come from Juan Carlos' submission, which says (in 3.2)
that adding such an attribute creates a "timed signature", but not a
"signed timestamp". I was thinking maybe a "timed signature" is a better
way of doing a timestamp, because it keeps separate the data the signer is
referring to (the <SignedInfo>) and what the signer is asserting about it
(the signed attributes).
This makes time-stamping more consistent with other function a DSS service
might provide (like signing contracts, or identifying requestors), and this
consistency would let a DSS service make multiple assertions about a
document in a single signature. For example, a notary might want to both
- attest to the identify of the requestor
- attest to the time of the request (i.e. timestamp the document)
If both <RequestTime> and <RequestorIdentity> could be attached as signed
attributes, then the notary could both timestamp the document and identify
the requestor within a single ds:Signature.
>Are there interesting cases of non-TSAs that offer some type
>of time-marking service? If so, what precludes them from being full-blown
>TSAs?
Maybe the notary service above? I'd say such a service is a "TSA" if TSA
just means someone trusted to be authoritative for time by some relying
party. Or maybe you wouldn't consider it a TSA, since it doesn't provide
timestamping as an individual service, only in conjunction with
authentication and requestor identification. I dunno.
Trevor
Received: (qmail 12453 invoked by uid 60881); 21 Mar 2003 00:27:54 -0000
Received: from dimitri@surety.com by hermes by uid 0 with qmail-scanner-1.15
(spamassassin: 2.43. Clear:SA:0(-0.8/8.0):.
Processed in 0.339797 secs); 21 Mar 2003 00:27:54 -0000
X-Spam-Status: No, hits=-0.8 required=8.0
Received: from unknown (HELO drake.surety.com) (216.33.115.19)
by mail.oasis-open.org with SMTP; 21 Mar 2003 00:27:53 -0000
Received: from doris (doris.surety.com [141.156.119.10])
by drake.surety.com (8.11.6/8.11.6) with SMTP id h2L0Zkv25947
for <dss@lists.oasis-open.org>; Thu, 20 Mar 2003 19:35:46 -0500
From: "Dimitri Andivahis" <dimitri@surety.com>
To: <dss@lists.oasis-open.org>
Subject: RE: [dss] Timestamping
Date: Thu, 20 Mar 2003 19:36:53 -0500
Message-ID: <FIEMJFOPLDNKKPDGBEGHEENDDCAA.dimitri@surety.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <5.2.0.9.0.20030319164654.00bb6a08@postoffice.pacbell.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Trevor,
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Wednesday, March 19, 2003 11:36 PM
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping
>=20
>=20
> At 06:21 PM 3/19/2003 -0500, Dimitri Andivahis wrote:
>=20
> >Trevor,
> >
> > > -----Original Message-----
> > > From: Trevor Perrin [mailto:trevp@trevp.net]
> > [...]
>=20
>=20
> Are there public docs for the ISO standards? They'd be=20
> interesting to look=20
> at,=20
ISO makes money by selling standards documents, so their docs=20
are usually NOT available to the general public for free. =20
There are a few people on this TC who have access to the ISO=20
time-stamping documents. I will check with the ISO admin folks,
see if they would allow us to share.
> since most of the timestamping submissions to the TC seem inspired by=20
> RFC 3161 (these are the ones I remember):
> http://lists.oasis-open.org/archives/dss/200211/msg00003.html - =
Entrust
> http://lists.oasis-open.org/archives/dss/200212/msg00004.html -=20
> Juan Carlos=20
> Cruellas
> http://lists.oasis-open.org/archives/dss/200212/msg00012.html - EML
> http://lists.oasis-open.org/archives/dss/200301/msg00001.html - Gregor =
> Karlinger
>=20
> As for linking methods, only Gregor's submission discusses=20
> supporting them=20
> in detail (though it does a good job). =20
I think Juan Carlos' submission had some coverage too, although not in =
detail. =20
> But are these methods practical,=20
> and worth the effort? If so, what requirements should be added for =
them?
>=20
>=20
I believe they are practical. A commercial implementation=20
of a digital timestamping service using linking methods=20
has been available on the Internet since 1995. =20
A TSA practicing linking methods is not required
to sign the submitted hash, time value and other info=20
within the timestamp token, and this may be an advantage=20
in various situations (key management issues, long-lived=20
timestamping).
Gregor's submission goes a long way towards providing support for it. =20
We would need to define a protocol for timestamp-token verification,
similar to what's done in ISO 18014-1. I am offering to contribute to =
any=20
additional work this may require.
> > > More generally, a timestamp token may be used to timestamp=20
> other things
> > > than a signatureValue.
> > >
> > > Now, whatever format the timestamp token takes, a timestamp=20
> protocol just
> > > requires the client send a hash and receive back a token. =20
> This shouldn't
> > > be any different from the DSS protocol used in the=20
> "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.
> > >
> >
> >I don't think the timestamping protocol should be confused with the
> >DSS protocol. The semantics of the two processes, requesting
> >a digital signature from a server vs. requesting a timestamp=20
> token from a TSA,
> >are totally different. Let alone, this is a non-starter
> >if the TSA generates timestamp tokens using a linking method or a =
MAC.
> >I think almost all XML Schemas for timestamping that were submitted
> >to this TC capture the complexity of the timestamp request/response
> >process and account for the need for a separate timestamping =
protocol.
>=20
> Could you elaborate? Aside from linking, the above protocols all=20
> just send=20
> a hash, and receive back a signature on the hash and time. This =
doesn't=20
> seem any different than sending a hash and receiving back a signature =
on=20
> the hash and any other signed attribute (such as requestor identity,=20
> signature policy, etc..).
>=20
Not exactly. A TSA using a linking method doesn't have to =20
sign anything that goes in the timestamp token. In the=20
binary protocols world of ISO 18014-3, the returned timestamp token=20
may be a value of type SignedData (for TSAs who link and sign)=20
or DigestedData (for those who link only). In XML, there=20
are minOccurs=3D"0" attributes for the various alternatives,=20
as shown on page 18 of Gregor's submission.
Requests for timestamp tokens produced using MACs, as defined
in ISO 18014-2, could be made to fit in your XML DigSig DSS protocol.
However, verification of timestamp tokens produced using MACs =20
requires that a verification protocol with the issuing TSA=20
be conducted, since the TSA is the only entity in possession of =20
the secret key(s).
The more general issue is, I don't think you can use the same
protocol (i.e., the same request and response objects)=20
for disparate services, such as requesting a generic digital signature=20
and a timestamp token issued by a TSA. There are many requirements=20
placed on the TSA generating a timestamp token that have nothing=20
to do with the fact that it may be generating them=20
as XML signatures over some data. These requirements=20
are reflected in the contents of the timestamp token returned,
which may or may not be a signed object. Even when the timestamp token=20
is a signed object, there's a lot more going on than saying=20
it's a special case of a digital signature request.
> [...]
>=20
> >My opinion is that we should have a separate timestamping protocol
> >for communicating with TSAs, for the reasons I described earlier.
> >In the interest of avoiding confusion with other timestamping =
standards
> >in the non-XML universe, I would also propose keeping timestamp =
tokens
> >separate from time-marks, if they are indeed different objects.
> >I'm a bit unclear on the issue of time-marking in general. I've seen =
a
> >short definition in ETSI 102023, but there was little detail.
> >
> >Could any cryptographic binding between a submitted hash and
> >a time value qualify as a "time-mark", as long as the time-mark
> >server archives "something" for each request and maintains a secure
> >audit trail, against which each "time-mark" issued may be validated?
> >If so, any of the TSAs defined in other timestamping standards
> >could be extended to do a bit of archiving and offer time-marking
> >services (time mark =3D=3D timestamp token).
>=20
> I was hoping a time mark was just when a signer adds a signed =
attribute=20
> containing the time.
>=20
> Maybe better terms come from Juan Carlos' submission, which says (in =
3.2)=20
> that adding such an attribute creates a "timed signature", but not a=20
> "signed timestamp". I was thinking maybe a "timed signature" is a =
better=20
> way of doing a timestamp, because it keeps separate the data the=20
> signer is=20
> referring to (the <SignedInfo>) and what the signer is asserting about =
it=20
> (the signed attributes).
>=20
OK, that clears up the definition of time-marking. However,=20
see top of page 7 for their argument over "timed signature" and TST.
> This makes time-stamping more consistent with other function a=20
> DSS service=20
I would substitute "time-stamping" to "time-marking" in the sentence =
above.
> might provide (like signing contracts, or identifying
> requestors), and this=20
> consistency would let a DSS service make multiple assertions about a=20
> document in a single signature. For example, a notary might want to =
both
> - attest to the identify of the requestor
> - attest to the time of the request (i.e. timestamp the document)
>=20
> If both <RequestTime> and <RequestorIdentity> could be attached as =
signed=20
> attributes, then the notary could both timestamp the document and=20
> identify=20
> the requestor within a single ds:Signature.
>=20
>=20
Again, I would substitute "time-mark the document" above.
> >Are there interesting cases of non-TSAs that offer some type
> >of time-marking service? If so, what precludes them from being=20
> full-blown=20
> >TSAs?
>=20
> Maybe the notary service above? I'd say such a service is a "TSA" if =
TSA=20
> just means someone trusted to be authoritative for time by some =
relying=20
> party. Or maybe you wouldn't consider it a TSA, since it doesn't =
provide=20
> timestamping as an individual service, only in conjunction with=20
> authentication and requestor identification. I dunno.
>=20
> Trevor=20
>=20
Agreed, the notary is a TTP that checks the digital signatures, and =
signs over=20
the data submitted and a time attribute that may be trusted.
The notary would have to follow the same requirements for trusted time=20
as a TSA, even though technically it's not a TSA. Will the same=20
requirements apply to all time-mark providers?
Dimitri
Received: (qmail 13273 invoked by uid 60881); 21 Mar 2003 00:46:45 -0000
Received: from jmessing@law-on-line.com by hermes by uid 0 with qmail-scanner-1.15
(spamassassin: 2.43. Clear:SA:0(1.2/8.0):.
Processed in 0.127928 secs); 21 Mar 2003 00:46:45 -0000
X-Spam-Status: No, hits=1.2 required=8.0
Received: from unknown (HELO law-on-line.com) (208.249.122.50)
by mail.oasis-open.org with SMTP; 21 Mar 2003 00:46:44 -0000
Date: Thu, 20 Mar 2003 19:51:26 -0500
Message-Id: <200303201951.AA206307782@law-on-line.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "jmessing" <jmessing@law-on-line.com>
Reply-To: <jmessing@law-on-line.com>
To: <dss@lists.oasis-open.org>,
"Dimitri Andivahis" <dimitri@surety.com>
Subject: RE: [dss] Timestamping
X-Mailer: <IMail v7.13>
Dmitri's description of a notary is inaccurate under existing law.
A notary could act as a TTP "plus" in that secure recordation of the time would be one essential component of the act of notarization, but the statement that the notary "checks the digital signatures" is not supported by current statutes. The notary is required by Anglo American law to check identity and the voluntariness of the act of signing, but not the signature of the signer. Moreover, there is no requirement of a digital signature of a signer, either in theory, or in the policies of the entities who are effectuating the infrastructure for online mortgage and title transactions, and sworn statements suitable for court.
The model most commonly mentioned allows the requestor to sign using any method he or she chooses, which is cryptographically bound to a transaction by the digital signature of the notary. This comes very close to the requestor use case, unless the notary is also required to witness the act of signature of the requestor which is affixed in the presence of the notary, as is the case in the paper world.
>Agreed, the notary is a TTP that checks the digital signatures, and signs over
>the data submitted and a time attribute that may be trusted.
>The notary would have to follow the same requirements for trusted time
>as a TSA, even though technically it's not a TSA. Will the same
>requirements apply to all time-mark providers?
>
>Dimitri
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]