Subject: Re: TSP interop update

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 21:17:44 +1300 (NZDT)

Margus Freudenthal <[email-masked]> writes:

>In addition, this makes the protocol more complex as the client must implement
>procedures for dealing with time stamps with funny and unexpected policy
>identifiers.

It's far easier to compare the returned ID with a known-good set than to submit
a string of requests going down a list of acceptable policies trying to find
one the TSA won't reject.

Peter.

---

From: Antonio Lioy <[email-masked]>
Date: Fri, 01 Feb 2002 09:26:17 +0100

> one the TSA won't reject.

No, only the client knowns which are the acceptable policies to it,
while the TSA issue a TST under one specific policy. So the client MUST
send its list of acceptable policies, listed in order of preference, and
the TSA MUST issue a TST with the policy of highest preference
available, or MUST return an error "no acceptable policy here".

Antonio

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Feb 2002 09:49:45 +0100

Antonio,

> available, or MUST return an error "no acceptable policy here".

Your proposal is leading into a direction I am quite familiar with:
Negotiation (see RFC 2478 - The Simple and Protected GSS-API Negotiation
Mechanism).

IF, I did say "IF", we go into that direction, then it would mean changing
the reqPolicy field in TimeStampReq by allowing a sequence of TSA policies
instead of a single policy.

Would this fit the concern from Peter ?
What would be the opinion of the current implementers, and of the WG ?

Denis

---

From: "Gianluca Ramunno" <[email-masked]>
Date: Fri, 1 Feb 2002 14:55:31 +0100

Denis,

> instead of a single policy.

why not to introduce in the request message an extension to express the
ordered list containing the preferred policies?

This way, expressing which policy is preferred or requested could be a
little more tricky, but it could achieve the task to preserve backward
compatibility.

Gianluca

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Feb 2002 16:13:52 +0100

Gianluca,

> ordered list containing the preferred policies?

Before defining a solution, the first question is the following: 
is this feature really needed ?
 
> little more tricky, but it could achieve the task to preserve backward

Thenafter we may define a solution. I have the same concern that you have:
"backward compatibility". Making a sequence of policies is simpler but
incompatible with the current document, hence why I asked first the question
to implementers whether they would be ready or have have problems to make
such a change.

Adding a new extension is a solution that I would like to avoid, but would
achieve backward ASN.1 compatibility, with the burden of defining things
like what happens when the new extension is present but not reqPolicy, 
or when both are present. :-(

Once again, the first question is the following: 
is this feature really needed ?

I would like to hear opinions.

Denis