Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside a specific flag in the TST to represent an official TST?)

From: Peter Sylvester <[email-masked]>
Date: Wed, 18 Jun 2003 16:53:18 +0200 (MET DST)

> 
> 
> Thanks Margus - yes they are different, both technically and "legally"...
> and so that is why they need the Policy Extension.

Margus seems to ask why just two different policy OID won't work?

---

From: "todd glassey" <[email-masked]>
Date: Wed, 18 Jun 2003 20:05:06 -0700

because the use of these is critical to making these more useful in
commercial and OLTP auditing. I want to see the specific use models penned
into the standard so they will be cast in concrete.

Todd

----- Original Message ----- 
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 18, 2003 7:53 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside
a specific flag in the TST to represent an official TST?)

---

From: Margus Freudenthal <[email-masked]>
Date: Thu, 19 Jun 2003 10:29:33 +0300

> into the standard so they will be cast in concrete.
Sorry, but he first sentence is confusing. What are critical and what
will be more useful?

Can you specify unambigously how this new extension would be processed
by the TSP-s and relying parties?

-- 
Margus

---

From: "todd glassey" <[email-masked]>
Date: Thu, 19 Jun 2003 04:23:27 -0700

Margus, part of the issue with the TST is that it is intended to be the
"universal" receipt. That is that it is supposed to stand as evidence of
some transaction... so then the issues become specific to what is the "best
case" evidentiary model, and what is the greatest common denominator amongst
all use models based on the need of a light-weight evidentiary declaration
as to ANYTHING.

because the mandates of evidentiary testimony are not well served by today's
TST... which is why I keep asking this WG to think of what the real uses of
the token are.

So then - how would you use a token in commercial processes? - It is
essentially useless if I have to create one-off solutions for use in
commercial venues, because its them that need the standardization. So with
that said, the current RFC is still incomplete as far as methods of using
it.

The other thing that the Data Structure itself needs to take into account
aside from evidentiary data payload requirements, is what its supposed to do
relative to eSign or other DSA and this is of course something that PKIX
refused to look at all the way through the RFC3161 process. Also apparently
something  no-one ever looked at.

Todd

---

From: Margus Freudenthal <[email-masked]>
Date: Thu, 19 Jun 2003 15:38:14 +0300

todd glassey wrote:
> TST... 

... and adding one bit of information would change that? In that case,
you can simply mandate that all time-stamp tokens which are meant to be
used for evidentiary purposes, MUST have policy OID whose last part is 1
(e.g. 1.2.3.4.1). Otherwise, last part of policy OID MUST be 2 (e.g.
1.2.3.4.2). Compliant implementations MUST NOT use any other numbers as
last part of the policy OID.

With that rule in place, we can boldly go where no time stamps have
never gone before.

>    which is why I keep asking this WG to think of what the real uses of
> the token are.
> 
What I personally would do with time stamps is a very long story and
most of it doesn't concern activities of PKIX. However, I see no way how
addition of a boolean field would change field of possible uses. As a
matter of fact, I can't see how removal of time-stamping policy field
would change possible use cases.

> something  no-one ever looked at.
I have asked several times that you describe how exactly would you use
time-stamp in legal context (with the help of "legal context bit"). So
far you have not given any examples.

-- 
Margus

---

From: "todd glassey" <[email-masked]>
Date: Thu, 19 Jun 2003 07:12:13 -0700

Margus, I have no problem in using the extensions to represent this. I just
want to predefine the use model as part of the AS for the Specification.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 19 Jun 2003 08:04:24 -0700

----- Original Message ----- 
From: "Margus Freudenthal" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 19, 2003 5:38 AM
Subject: Re: TSP Jurisdiction Extension (Was: gentlemen... can we set aside

> ... and adding one bit of information would change that? In that case,

if it can be agreed to, yes, that's the point.

> (e.g. 1.2.3.4.1).

Which means that mechanical policy is not also implemented as part of the
transactional policy... making the number of interpretable OIDS much larger
since for each instance of LEGAL_STATUS_OID there would be an accompaning
PHYSICAL_POLICY_Designator...

so with the proposed model you set forth , the total OID's = p*l rather than
the much smaller number represented by p+l for the model I proposed.

Both solutions work, except one is much smaller in the potential size of the
policy table that would have to be maintained and evaluated for each and all
timestamps issued or processed.

> Otherwise, last part of policy OID MUST be 2 (e.g.