Subject: RE: TAP

From: "todd glassey" <[email-masked]>
Date: Tue, 1 Apr 2003 08:58:38 -0800

Stephen - TAP is one of the most important things that PKI
and PKIX can undertake and it should be adopted within PKIX
or allowed to flow through PKIX as a sub group. Maybe it has
its own list and is a short termed project???

I cant see any reason for you as the WG Chair to say no to
TAP other than it actually has real deliverables and could
potentially be one of the most important things to come out
of PKIX and the PKI world in many years. And for many of us,
this potentially may be the log that breaks the log-jam in
the PKI marketplace as well.

I believe it is in PKIX's best Interest to allow TAP into
its fold either as an "in-house" project or as a sub
project. Further I think you or the TAP team should define a
set of vetting requirements for it and thus allow us to get
on with this.

If PKIX as a group as enough people that want to work on TAP
then they should be allowed to do that, unless that is this
is a monarchy and not a democracy within the WG.

Todd Glassey

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Santosh
Chokhani
Sent: Monday, March 31, 2003 4:21 PM
To: 'Stephen Kent'; 'Stefan Santesson'
Cc: [email-masked]
Subject: RE: TAP

Steve and Stephan:

The TAP protocol is not about rights to access data.  It is
based on using
PKI to provide long-term non-repudiation of information.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Monday, March 31, 2003 6:01 PM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: TAP

At 12:27 AM +0200 4/1/03, Stefan Santesson wrote:
>I'm not sure, but is strikes me that the efforts of the
OASIS Rights
>Language TC
http://www.oasis-open.org/committees/rights/charter.php
>might be used as a protocol framework to exercise rights
over
>information and policies/conditions for its archival and
retrieval.
>All supported by PKI based authentications of rights
holders and
>licensees.
>
>It would be interesting if anyone else has more deep
knowledge about
>this.
>/Stefan

Well, I would not like to become embroiled in any schemes
that focus
on DRM, or to depend on them for archive.  I think the two
are very
separate functions, and even through there may be functions
in DRM
that make use of archive, I would not want to make use of
trusted
archive depend on adoption of DRM technologies, given the
generally
very negative perception associated with DRM.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Apr 2003 09:45:11 -0500

>the PKI marketplace as well.

You missed the point, again, Todd.

I agreed to add TAP as a WG item, in response to a request by its authors.

This decision was questioned at the PKIX meeting (read the minutes).

I then initiated a discussion on whether TAP should be a WG item.

Do try to keep up,

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 03 Apr 2003 17:05:47 +0200

The technical quality of this draft document is very questionable.

Like another draft document (i.e. SCVP) there is an abuse of OIDs
in particular for archiveControls and even for the inclusion of
a nonce using id-tap-nonce !!!

I wonder when the next draft posted to this WG will simply contain:

        queryControlType   OBJECT IDENTIFIER
        queryControlValue  ANY DEFINED BY queryControlType OPTIONAL

with the corresponding response:

        responseControlType   OBJECT IDENTIFIER
        responseControlValue  ANY DEFINED BY responseControlType OPTIONAL

Note the OPTIONAL at the end of the line !

The aspect of periodic refresh are mentioned in section 1.4 but the
rational for it is missing many aspects. Section 7.2 only mentions:

     In order to protect against algorithm (i.e., hashing and digital
     signature) compromise and/or computing technology advances,
     timestamps are periodically refreshed.

This is only a small part of the whole story.

Santosh said that TAP provide long-term non-repudiation of information.
I disagree with this. TAP has nothing to do with non-repudiation.

TAP is an archive protocol and should be addressed in a group specialized
in archiving. PKIX is not such a WG.

Note that it is also wrong to say that the TAA MAY be a TSA.

My position:

TAP should not been addressed in the PKIX WG, but some PKIX members could 
certainly provide guidance to the security section dedicated to time-stamping.

As an alternative, we could produce a *draft* dedicated to the use of
time-stamp tokens associated with archives and the way to apply and
verify them. That draft would *not* reach the RFC status and would
be integrated in an RFC produced elsewhere.

Denis