Subject: RE: Delegated Path Validation draft.

From: Michael Zolotarev <[email-masked]>
Date: Mon, 16 Oct 2000 10:24:09 +1000

On the same tune: 

I expect that receiving 'No' answer will be rather an exception than a
common case of using DVP. If you keep receiving 'No's, it most likely
indicates that either your trust/policy settings are wrong, or you are under
attack. Significance of it is that each 'No' case will require human
intervention, at least at the initial stage of system's operations. With the
amount of data required to perform adequate 'why No' analysis being larger
than a single response message can reasonably communicate.

However, once the system went through the initial tuning up stage, and the
client has acquaired reasonable trust into quality of decisions by  the DPV
server, receiving 'No' answer should be just 'flagged' by the client, but
not investigated.

In short, communicating 'Why No' data to the client is rather a 'roll-out
stage trace/debug' feature, then normal operation mode feature. Therefore
making it a part of the core(!) protocol is not very justified, to me.

However, every DPV vendor may of course decide on a special way of ensuring
that the clients have access to the DPV decision making context. As a
minimum, I'd expect a server to make its verification procedure logic
publically known and auditable.

Frank - I'm still standing on attention to hear why do you think a client
may want to know 'why Yes'. No jokes. That'd be one of the major requirement
for audit performed on DPV, if there is for example a legal reason, or
something...

Michael

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Saturday, 14 October 2000 7:50
> To: Michael Zolotarev; 'Frank Balluffi'; Michael Myers;
> [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> 
> I generally agree.  I'm doing all I can to advocate for a 
> principle that
> "simpler is better until compelling proven otherwise." 
> However, it was a
> criticism of 2560 that there exists more easily predictable 
> error status
> values than 2560 currently recognizes.  I propose that we 
> take a look at
> that, building on Frank's suggestions and perhaps those of 
> others, but that
> we do not create a sub-protocol for error cause discovery.
> 
> Mike
> 
> > -----Original Message-----
> > From: Michael Zolotarev [mailto:[email-masked]]
> > Sent: Friday, October 13, 2000 8:19 AM
> > To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> > [email-masked]
> > Subject: RE: Delegated Path Validation draft.
> > 
> > 
> > Frank,
> > 
> > please, do not go this way. Keep it simple. 
> > Realistically speaking, a client only needs a simple 'yes' or 
> > 'now'. The
> > whole purpose of defining a TTP for path validation was to 
> > simplify things.
> > 
> > If a client is not satisfied by the 'yes' or 'now', there are 
> > other options
> > (other then been shot, of course). Mind you I fail undestand 
> > why a client
> > would ever ask 'why yes?' - would like to hear from you on this one,
> > frankly. 
> > 
> > To find out why 'No', a client can use DPD to get the path, 
> > and then ask DPV
> > for each component in the path.
> > 
> > Otherwise we'll end up with a hugely blown-up service, which 
> > wasn't the
> > purpose of the exercise.
> > 
> > M
>

---

From: Al Arsenault <[email-masked]>
Date: Mon, 16 Oct 2000 09:23:15 -0400

Comments in-line, prefaced by my initials.

Michael Zolotarev wrote:
> common case of using DVP. 

AWA: I tend to agree with this part. At least I *hope* that it will be
the case.

>If you keep receiving 'No's, it most likely

AWA: This part I disagree with. Suppose that I'm trying to access some
popular website from my wireless device, so I choose to use DPV.  Say
for the sake of argument that the site I'm accessing is my brokerage
account on "AlTrade".  Now, I get the result that "AlTrade's certificate
does not validate."  While it's true that during initial system testing
(and maybe during the initial operational stages) I'm going to have my
designers/testers go trace back to the problem, I do not believe that
steady-state operation will need or even want human intervention.  One
of the biggest drawbacks to this whole PKI thing in the eyes of many
people is the cost in terms of people needed to make it work.  If you're
going to staff a help-desk to respond to human phone calls saying "I was
trying to buy stock in XYZ; I got a message that the certificate didn't
validate, and no I have no clue what else was involved", you'd better be
ready to shell out some money for people.

Much more efficient would be "AlTrade's certificate does not validate
because the information is not available at this time; please try later
or call 123-456 for help" or "AlTrade's certificate appears to have
expired, please call 987-5432 to update it" or ...  That way, if you do
have to get the human help desk involved, at least you have a clue what
happened.

> server, receiving 'No' answer should be just 'flagged' by the client, but

AWA: "Not investigated" is only acceptable if what you really want is
for all of your users to answer "yes" to the question "AlTrade's
certificate did not validate, would you like to continue anyway?" It's
not often that they're just going to give up - and I'm not really sure
that that's what you want your customers to do, anyway.

> making it a part of the core(!) protocol is not very justified, to me.

AWA: For the reasons stated above, I disagree.
 
> for audit performed on DPV, if there is for example a legal reason, or

AWA: I can't think of any reasons to mandate that justification always
be passed with a "yes" answer, but I know of some circumstances where it
would be better to provide "yes, and here's the cert path I validated"
than just "yes". So I'd see "why YES" as more optional than mandatory.

> Michael

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.