Subject: RE: DVD & DVP requirements

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 23 Jan 2001 14:09:41 -0700

Steve, I didn't intend to "advertise," nor was I in any shape or form
advocating that the WG endorse or even consider the proprietary
attributes I was discussing.  They were only provided as a reference.

You asked for an example of parameters a client could change
between invocations of a DPD server, where multiple invocations 
would provide distinct, useful answers.

I think that the examples I provided do exactly that. You may or may
not like those examples, you may prefer to use other mechanisms
such as Policy OIDs, name subordination, or other techniques
(although I believe we might differ as to their utility in a general context), 
and that's all fine and good.

All I was attempting to provide were EXAMPLES, per your request,
not necessarily a proposed change to the standard, etc.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> Stephen Kent <[email-masked]> 01/23/01 10:33AM >>>
Bob,

>Steve, you said in part:
>>
>>I'd like to better understand what parameters the client will change
>>between invocations of a DPD server, in a controlled fashion, to make
>>multiple invocations for the same target certificate provide
>>distinct, useful, answers. Do you have some examples that could
>>clarify this scenario?
>>
>>Steve
>
>Let me give you a possible "existence proof " of such a scenario.
>
>There's an old joke about a Vermonter, who when asked, "How's
>your wife?" replied "Compared to what?"
>
>When we have said in this context, "Is this certificate chain valid?",
>we should really be asking "Can I trust this certificate chain?"
>and the only reasonable answer to that question is to say
>"compared to what?" or more precisely, "Trust it for what purpose?"

A DPV client specifies a set of parameters for controlling an 
objective, deterministic process that we call certificate validation. 
I think the word "trust" has no place in this process. At best, 
since the client selects the parameters relative to an intended use 
for the key in the cert, you might choose to say that the client 
chooses these parameters based on its perception of what it needs to 
trust the key for, but those would be your words, not mine.

>In other words, trust, like integrity, is not some binary value that is
>independent of any predicate. Instead, something, either a process
>or the data that was produced as a result of some process, is "trusted"
>if and only if the process conforms to a specified set of rules or
>expectations. It is clearly not possible for a process to be tested
>against all possible rules in the universe, so without qualifying the
>trust to a particular set of rules, the question is meaningless.

Validation is trinary here: yes, no, don't know.

>Now, the reason why a client or relying party might ask the server t
>hat question is obviously a function of the client's current context, i.e.,
>the type of transaction or whatever that is being evaluated.

Which is why it makes sense to keep this aspect of the decision to 
use a cert for a given application a local matter, outside the scope 
of this standard.

>And clearly, that context may vary, depending on the perceived value
>of the transaction, the history of that transaction and previous
>transactions with that signer, etc.

see comment immediately above.

>If the client is trying to decide whether to honor a purchase order
>for a single quart of 10-40 motor oil, the risk analysis for such a
>transaction would probably suggest that the probability of default
>is low, and that continued customer good will is worth more than
>that risk. In that case, maybe it isn't even worth the bother of
>consulting the server, except perhaps for auditing or logging
>purposes.
>
>On the other hand, if that very same client is evaluating a purchase
>order for one hundred million barrels of crude oil, to be delivered
>via multiple oil tankers FOB Saudi Arabia, then the risk analysis
>would suggest that the buyer's credentials had better be
>gilt-edged indeed.
>
>As to how the parameters would be conveyed, a very simple,
>existence-proof mechanism would be to simply encode the value
>of the transaction in dollars, and let the server try do its thing.
>maybe it has some artificial intelligence program that parses the
>Certificate Practice Statement and does a risk assessment.
>Or maybe it simply looks up the net worth of the buyer and the
>CA in Dun and Bradstreet and decides accordingly.

Since not all transactions are best characterized by monetary value, 
this is not my idea of a good example. It also shifts the burden to 
the server in a fashion that makes it impossible to test if a server 
is operating properly. So, no, this is not a good idea.

>Of course, since I have a hammer and this looks like a nail,
>I would suggest that a better mechanism would be to use
>the Novell Security Attributes (cf. 
>http://developer/novell.com/repository/attributes/certattrs_v10.htm),
>and to have the client either encode a minimum set of those
>attributes for this particular transaction. Or more likely,
>the client would be preconfigured with a set of attributes
>labeled platinum, gold, silver, bronze, green and brown,
>and would select one of those for certain kinds of transactions,

Bob, we frown on advertisements on this list. You know better.

><snip>
>
>In either case, the client can ask the question, "Is this certificate
>chain trustworthy with respect to my "Platinum" criteria?" and get one
>answer, and later ask the same question with respect to exactly the
>same certificate chain, but specifying the "Green" criteria, and perhaps
>get a different answer.

We support this via reference to different policies configured on the 
server, but only to the extent that the policies make use of standard 
cert attribute validation parameters. To do what you propose would 
require adding support for private extensions at the server and 
perhaps in client requests. This could be done if the WG wants, but 
it would be a supplement to the mandatory, 2459bis validation 
criteria.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 11:32:54 -0500

Bob,

>not necessarily a proposed change to the standard, etc.

If there had been more concrete examples of such parameters, rather 
than a high level discussion, plus the URL, I would have interpreted 
the message as addressing my request.

Steve