Subject: Re: Open issue: requester identifier in DPV response

From: Denis Pinkas <[email-masked]>
Date: Tue, 16 Apr 2002 16:42:18 +0200

Peter and the list,

I have changed the name of the thread into "requester identifier in DPV
response" to reflect the issue.

I also believe that it is time to return to the list.

Peter is asking to add the following:

[The DPV server MAY require client authentication, therefore, the DPV 
request MUST be able to be authenticated]. 

"When the request is authenticated, the requestor MUST be able, upon 
request, to have an identifier to be included in the response. Whether 
and how the communicated identification(s) are validated against identities
derived by some authentication method depends on local configurations. 
Depending on that, the server MAY choose to copy, ignore, or replace 
the identities by some other in the response, or to refuse the
request."

My personal opinion is that since the server policy (which has nothing to do
with a validation policy) will be unkown (i.e. not visible in the response
and not fixed by the protocol), this field would have no value.

Opinions ?

Denis

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 16 Apr 2002 11:39:16 -0400

Denis, Peter:

      I have one question about this proposal.  Is the object to be placed
into the response a transaction identifier or the RP's identifier?  If it's
the RP's identifier, IMO it should be called something like "requestor's
claimed identity" and it should not be permitted to be altered by the
server, although it might be permitted to be dropped.

            Tom Gindin

Denis Pinkas <[email-masked]>@mail.imc.org on 04/16/2002 10:42:18 AM

Sent by:    [email-masked]

To:    Peter Sylvester <[email-masked]>
cc:    pkix <[email-masked]>
Subject:    Re: Open issue: requester identifier in DPV response

Peter and the list,

My personal opinion is that since the server policy (which has nothing to
do
with a validation policy) will be unkown (i.e. not visible in the response
and not fixed by the protocol), this field would have no value.

Opinions ?

Denis

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 16:29:39 +0200 (MET DST)

> >
> >The protocol MUST allow to provide to the requestor and/or the
> >responder a means to indicate a textual description indicating for example
> >the natuer or reason of the request/response to appear in the
> >result of the response.
> 
> I think you are asking for an optional comment field.  Right?

Yes, one might call this this way: The USAGE of the field is optional.

> 
> > > When the request is authenticated, the requestor SHOULD be able, upon
> > > request, to indicate an identifier to be included in the response.
> > > How this identifier is matched with the authenticated identity depends
> > > on local server conditions and/or the validation policy. The server
> > > MAY choose to refuse to include an identifier in the response, or MAY
> > > refuse to create a response.
> >
> >There are
> >
> >- IDs identifying the requesting entity (or entities) or
> >   entities which are entitled to use the response.
> >
> >- IDs identifying the responding or responsible entity (or entities)
> >
> >I give an example (probably using the wrong rules).
> >
> >"We, the President of Unites States, and the General Secretary of
> >  the United Nation", certify to you, President of France, President
> >  of the French General assembly, and president of the French Senate,
> >  the the certificate XXYZ can be used by you as a strong authentication
> >  method to demand deployment of a combined UN ad US forces on May 5
> >  according to plan LEF".
> >
> >The request had been signed by two of three French authorities containg
> >the name of the persons involved and their roles. The response has
> >been signed by the two persons occupying the indicated 'role', plus
> >by the presidents of the congress and senate and by the members of
> >the UN security council.
> 
> I do not think that such rules have anything to do with DPV and DPD.  We 
> are not dealing with multi-party trust.  The client trusts the server that 
> was queried.  The client does not care whether the server consulted other 
> parties to come up with the response.

You are already dealing with multipart trust, you trust into each entity in a chain
telling the truth about its subordinate certificate. 

But, note, that there are TWO requirements, one for the 'client identifiers',
and another for the 'service identifiers'. For both fields, a similar
statement as with the 'optional comment' can be made, with the difference
that the syntax of the field is not pur text but "identifiers" which may
or may not correspond to some authenticated entity of the request/response.

If the DPV response is immediately consumed by the client without
storing it elsewhere, then all additional information are somewhat
unnecessary since the valid or not response conditions the treatment.

But if the response is saved and may be reverified by some other entity
years later, identification of the participating entities may be necessary,
for different reasons. One example would be that the DPV server
takes a response from another relay, authnticated it, but does NOT
return the authentication information into the final response, simply
because there is none which is permenant (SSL connection), BUT the
id of the relayed service allows to find a service that can validate
against a journal whether the attestation is valid.

Well, see below.

> 
> > > This should close the last issue raised during the last call.
> >
> >I propose that we add somewhere in the introduction a statement like:
> >
> >   A protocol feature proposal MUST not be rejected as out of
> >   scope for the sole reason of not having been mentioned in this
> >   requirements document ".
> 
> I would not mind such a statement as long as it was explanatory (no 
> MUST).  That is, a protocol that conforms to the requirements document can 
> also meet other requirements so long as they are not in conflict with the 
> ones in the requirement document.

I am not sure about the right wording, by using a MUST in whatever context
I would like to be sure that one cannot say: this protocol is not good
because it has feature that are not required in the req doc. 

Of course, conflicts with the requirements is a show stopper.  
> Russ
Peter

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 29 Apr 2002 17:30:51 +0200 (MET DST)

> > 
> > Are you asking for a requirement to be included in the
> > text that indicates:
> > 
> > " A protocol that implements the requirements of this document
> >   MUST NOT, never ever, implement other features, even optional ones. "
> 
> I do not think that we need any sentence. Now, if we really needed one, here
> is a proposal:
> 
> The basic protocol SHOULD NOT support any additional requirement besides the
> requirements listed in this document. Any additional feature not listed
> SHOULD only be supported using extension fields.
>

At least you start accepting that other features MAY be implemented by a protocol.
We are therefore a little bit further than:

   > No. We would not make the effort of writing these requirements if we were
   > going to allow a protocol that supports many other features that are *not*
   > required.

Nevertheless, I consider your proposition as overspecification and unjustified.

- You make the assumption that there is something like an extensions mechanism. 
- You restrict ALL features to that extension mechanism without leaving 
  the possibility of 'devine inspiration' that leads to an obvious feature of a
  protocol implemented in an obvious way immediately.

I would agree that additional features that are supported by a protocol need
to have consensus since they may create additional development effort and
interoperability problems. 

Peter