Subject: RE: Open issue: DPV relay

From: Tim Polk <[email-masked]>
Date: Mon, 15 Apr 2002 16:08:03 -0400

Folks,

Here is my take on the relay/referral fracas, in two parts.

The first part addresses DPV relay includes (1) my assumptions about DPV, 
(2) a little rationale, and (3) a proposed "solution" for DPV replay.  The 
second part amounts to four complaints about the impact of adding 
referrals, and my belief that it should not be supported.

                                                         Part 1: DPV Relay 
Proposal

Assumption #1:

DPV relay is irrelevant to DPV clients.  They request answers from a 
trusted DPV server X, and server X MUST stand behind the response.  (That 
is, X can't say "I don't know, but Server Y says this certificate is 
okay."  It is up to X whether it can trust that answer.)

Assumption #2:

Many DPV servers will not relay requests.

Tim's Theory and what it is, too:

DPV servers that do not relay requests do not care if the request has been 
relayed before they received it.  That only matters for loop 
detection/relay limits, etc.

DPV servers that do relay requests MUST be able to detect whether or not 
the request has been previously relayed, and the request MUST have the 
complete list of servers that have received the request.

So, the conformance requirements:

Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do not 
relay requests do not need to process or recognize the relay history 
information.

DPV servers that relay requests MUST satisfy all the following conditions:
           (1) recognize and process relay history if present in a DPV request;
           (2) able to generate a relay history including the complete list 
of servers that have
           already forwarded this request; and
           (3) before relaying a request, the DPV server MUST verify that 
the chosen DPV server
           has not already seen the message.  (That is loop detection 
occurs at the requester,
           not the recipient).

This proposal does not impact clients, it simplifies the most common DPV 
servers, and it places *all* the burden on DPV servers that relay 
requests.  (As it should be, in my opinion.)

                                                      Part 2: DPV Referrals

Complaint A

Referrals impact *all* DPV clients, significantly increasing their 
complexity.  Currently, the requirements indicate whether or not the server 
could build a satisfactory path.  It seems to me that referrals force all 
DPV clients to interpret a new class of answers: "I don't know but ask 
Server B".  (By itself, this isn't that compelling, I admit.  They get 
stronger, IMHO.)

Complaint B

One of the nice features of DPV is a single "proof" for archival.  This 
feature is broken by the introduction of DPV referrals.  Assume Alice is 
trusts Server A, but she receives a referral indicating that Server A 
trusts Server B to validate this certificate.  Alice will need to maintain 
both the referral from Server A and the answer from Server B.

Complaint C

Referrals for DPV are a very different animal than LDAP referrals.  Once 
again, assume Alice is trusts Server A but she receives a referral 
indicating that Server A trusts Server B to validate this 
certificate.  Alice will need to authenticate the identity of Server B 
using information from Server A.  I think that means that Server A needs to 
identify Server B by including Server B's public key in the referral.  If 
that is true, we just created a parallel key management infrastructure and 
increased the complexity of our universe.

Complaint D

If LDAP is any indicator, nobody does referrals anyway.  Since DPV 
referrals will be significantly more complex, wouldn't it be better to put 
the load on the server?

Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all think 
of these proposals?

Thanks,

Tim Polk

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 15 Apr 2002 16:27:03 -0700

Tim,

A few specific comments embedded below regarding relay.  In
summary:

1. Relay may some day be relevant to clients;
2. Relay history lists may get long, another solution?; and
3. Common servers may not be the same vendors five years out.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tim Polk
> Sent: Monday, April 15, 2002 1:08 PM
> To: [email-masked]
> Subject: RE: Open issue: DPV relay
>
>
>
> Folks,
>
> The first part addresses DPV relay includes (1) my
> assumptions about DPV,  (2) a little rationale, and
> (3) a proposed "solution" for DPV replay.  The
> second part amounts to four complaints about the
> impact of adding  > referrals, and my belief that
> it should not be supported.
>
>
> Part 1: DPV Relay
> Proposal
>
> Assumption #1:
>
> DPV relay is irrelevant to DPV clients.  They request
> answers from a trusted DPV server X, and server X MUST
> stand behind the response.  (That is, X can't say "I don't
> know, but Server Y says this certificate is okay."  It
> is up to X whether it can trust that answer.)

We may be premature in assuming relay will never be relevant
to clients.  In future applications it may be important for
a client to have in hand a digitally signed assertion from the
entity ultimately at risk for the reliability of a certificate
even if the client trusts a given server as a service
aggregation point for the purposes of system design economy.

> DPV servers that do not relay requests do not care if
> the request has been relayed before they received it.

I assume your further thinking is, "because in the event
they can't satisfy the request, they'll assert 'unknown' rather
than seek a suitable relay hop, thus breaking the relay chain."
Correct?

> That only matters for loop detection/relay limits, etc.
>
> DPV servers that do relay requests MUST be able to
> detect whether or not the request has been previously
> relayed, and the request MUST have the complete list of
> servers that have received the request.
>
> Support for DPV relay is OPTIONAL for DPV servers.
> DPV servers that do not relay requests do not need
> to process or recognize the relay history information.
>

I'm a bit worried about relay history being an increasingly
long list of server names and IP addresses.  There should be
something simpler here that enables loop detection.  Problem
is I'm not sure we can predict what it would look like until
we get into the protocol selection issue.

> (2) able to generate a relay history including the
>    complete list of servers that have already
>    forwarded this request; and

See above.

> (3) before relaying a request, the DPV server MUST verify
>     that the chosen DPV server has not already seen the
>     message.  (That is loop detection occurs at the requester,
>     not the recipient).

Loop detection at the requester makes sense.

> This proposal does not impact clients, it simplifies
> the most common DPV servers,

Hmm.  In five years the most common DPV servers may not be
those currently in favor.  Maybe you meant to say this
differently, but I'm hearing that market share and installed
base is relevant to our technical considerations.  I'm confident
this is a minor point easily clarified due to my misreading
of the above.

> and it places *all* the burden on DPV servers that relay

Looking forward, clients might want a piece of the action.
Hard to predict what the storage and processing limitations
will be (e.g. increasingly smarter smart cards).  My sense is
those capabilities are reliably expanding. Certainly though,
our intent from the very beginning with online status
mechanisms was to push complexity to the backend and so
make it easier to initiate, deploy and maintain a PKI.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 16 Apr 2002 10:31:38 +0200

Tim,

I will be leaving my office tomorrow evening for one full week 
(both holidays then business), so we had better solve this rapidly 
so that I can post a new draft before leaving. :-)

See my comments embedded.
 
> okay."  It is up to X whether it can trust that answer.)

Fine.
 
> relayed before they received it.  

True.
 
> That only matters for loop detection/relay limits, etc.

Wrong. If they do not relay, a loop can never occur. :-( 

> the request has been previously relayed, 

Correct.

> and the request MUST have the complete list of servers that have received the request.

No. You are specifying a solution, which would work but there are other
solutions to this problem: a list of servers is not the single way to solve
this issue. Since we are writing requirements we should not impose a
solution.

I believe that this requirement can be captured by the following sentence:
   
   When a server supports a relay mechanism, a mechanism to detect
   loops or repetition MUST be provided.

Now, to explain in more details:

When a DPV server relays a request to another DPV server:

    1) it must copy already present relay history information (if any),
    
    2) it must add relay history information in the relayed request. 

As an example, the added information can simply be a nonce and thus no
server name needs to be ever used. A sequence of nonces would thus do the
job nicely and avoid naming problems or naming conventions. Practically 
speaking, a sequence of INTEGER would do the job. 

> relay requests do not need to process or recognize the relay history

Correct.
 
>            (2) able to generate a relay history 

 .. information. Full stop.

> including the complete list of servers that have already forwarded this request; 

No. As said earlier, the received relay information is blindly copied.

>            has not already seen the message.  (That is loop detection

Correct.
 
> requests.  (As it should be, in my opinion.)

Correct.

> Server B".  (By itself, this isn't that compelling, I admit.  They get

No. The idea is to send back the referral in a non-critical extension so
that it can be ignored by a client. Clients must be ready to support
extension fields, but are not mandated to understand any non-critical
extension.

> trusts Server B to validate this certificate.  

No. It is not the meaning of the referral. Assume Alice trusts Server A, but
she receives a referral from server A indicating that Server B
might be able to validate this certificate. Alice has to make its own
decision whether she can trust or not server B.  

> Alice will need to maintain both the referral from Server A and the 
> answer from Server B.

No. See above.

> increased the complexity of our universe.

Not with the trust model that I indicated.

> referrals will be significantly more complex, wouldn't it be better to put

The load will be on the servers. Clients may fully ignore that field.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Apr 2002 11:24:38 +0100

Tim,

I echo almost all of Denis' comments on your mail.

In any case, isn't the latest text from Russ ok with you? If
not what alternative text would you suggest?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "todd glassey" <[email-masked]>
Date: Tue, 16 Apr 2002 07:25:01 -0700

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Tim Polk" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 16, 2002 1:31 AM
Subject: Re: Open issue: DPV relay

> >                                                          Part 1: DPV
Relay
> > relayed before they received it.

A DPV server that does not relay requests will never see input from another
DPV server unless it is the "victim" of a relayed DPV proofing request. This
problem-mode is real since this definition this DPV server probably cannot
allow its response to be knowingly relayed either... so how does it, a
non-relaying server, respond to the relayed request?

> Wrong. If they do not relay, a loop can never occur.

> > the request has been previously relayed,

So a relay-history list and policy OID or indicator is needed.

> this issue. Since we are writing requirements we should not impose a

OK, then how could you tell retrospectively where the decision in the DPV
chain was made? This is the problem with the current model. No real
auditing.

>    loops or repetition MUST be provided.

I am more worried about the logging of DPV events which as far as I can tell
is still missing from the Drafts.

> No. As said earlier, the received relay information is blindly copied.

Then there is no way to deal with the auditing of the DPV process. Denis
would you be willing to build a bridge between the DPV Server's operations
and that of a local RFC3161 Server??? If  a DPV process could use a TST as a
staged proofing model and include a set of or single event histriy token
with the response - you have killed two birds with one stone.

> >            (3) before relaying a request, the DPV server MUST verify
that
> >            has not already seen the message.  (That is loop detection

Or already responded. Look at a matrix of say 10 DPV servers in a chain. So
Server #1 gets a request that it cannot answer so it hands the request off
to #4, who in turn passes it to #5, 6, and 7 which is configured to refer
back to #2 who then refers to #4 for the second time this "event
verification action". So is this a loop? How would you log these actions?

> > requests.  (As it should be, in my opinion.)

there is a rudimentary question here as to whether a Trust Provider (the DPV
Server) needs to disclose its trust processes in normal uses. If it does not
need to then this anonymous model is OK, but otherwise there is some serious
logging and query processing to be added here.

> >                                                       Part 2: DPV
Referrals
> extension fields, but are not mandated to understand any non-critical

I think what you have here is actually two (2) different client types.
Lightweight and Heavywieght. The lightweight ones dont care about relaying
and maybe optionally can say they will or will not accept the relayed and
history-embellished CPV sessions, and the heavyweight ones do.

This is the easiest way to let the market decide which one is better.

> > feature is broken by the introduction of DPV referrals.

Not true if a TST is included at each step of the way and would make me feel
better about the RFC3161 use models.

>  > Assume Alice is
> > Referrals for DPV are a very different animal than LDAP referrals.

Once again a further justification for the call to simplify PKIX into a
standard user interface anc service calling model.

> > Once

This is non-sequitor. LDAP is not an Audit Authentication or Event
Processing Protocol like the trust services of a DPV server. It is a
Directory Access Protocol and that's that.

> > Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all
think

Flaming!