Subject: RE: DVD & DVP requirements

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 22 Jan 2001 16:08:29 -0700

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?"

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.

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.

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.

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.

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,

Whether the name of the attribute string was sent to the 
server, or the content of the attribute wouldn't matter that much.
The important point is that the MAC label portion could be used
to encode what CAs (registries) that may have been certified 
by a particular root are to be trusted in this context, as well as 
what enterprises. And individuals and/or role within an enterprise 
can be encoded to indicate whether o not that person is required
to have Purchasing Agent authority, or perhaps Owner or
Managing Director authority.

And regardless of the claimed authority, the certificate quality 
portion of the Novell Security Attributes label would convey useful
information as to how and where the key as generated (the 
assurance level of the platform), the assurance level of the 
platform where the key will actually be used, and how and where 
the key was stored in the meantime.  And finally, there would 
be a minimum certificate class requirement that would deal with
the nature of the end-entity and the due diligence invested by
the CA in confirming both the nature of the end-entity and the 
right of that end-entity to use those credentials.

Given a compact, machine-readable representation of 
all of these parameters, I believe it should be obvious how the server
could validate the certificate chain.  If all of the attributes were 
encoded in the certificate chain itself, then other than perhaps 
the difficulty of finding and downloading all of the certificates
the client could easily validate these parameters itself -- it's
just code, and I'm not assuming that this has to run on something
like a cellular phone.

But if all of the certificate do not contain pre-encoded Novell 
Security Attributes, then perhaps the server knows something 
about the issuer and their policies, perhaps as a result of some
human having read the CA's CPS and the end-entity's balance 
sheet, and had prestored some judgements that can then be 
presented.

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.

(BTW, a certificate chain that satisfies the Platinum criteria might 
not satisfy the "Green" criteria.  Bill Gates of Microsoft might satisfy
the platinum criteria, but if the item being bought was $35 worth of
a controlled substance, and the "Green" criteria required that either a
Doctor's or a Registered Pharmacist's DEA license number had 
to be specified, then Bill's order wouldn't qualify.)

Regards,

Bob

Robert R. Jueneman
Security Architect

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

---

From: Michael Sierchio <[email-masked]>
Date: Mon, 22 Jan 2001 16:08:58 -0800

> trust to a particular set of rules, the question is meaningless.

Trust may be fuzzy -- it depends on subjective evaluation, etc. But
reliance follows an act of defuzzification (a technical term, believe
it or not) in which the fuzzy output set is converted to a crisp
(yes, binary) number (we open the box and the cat is either dead or 
alive).

Open to the chapter with the heading:

	Trust -> Confidence -> Reliance -> Dependence

Audun Jøsang(*) suggests an interesting approach to modelling trust. 
Belief trust requires an assessment of external data (or capta), the
accuracy, completeness, truthfulness and reliability of which may
not be known perfectly by a relying party.

Even with a fixed ruleset it seems to me that the problem is one
of constraint based reasoning under conditions of uncertainty.
Do you propose that a validation responder, for example, reply with a 
membership grade (percent probability of being valid)?  That actually
seems reasonable and promising.  This is a nascent research area.

*)
	http://www.item.ntnu.no/~ajos/PhD.html