Subject: FW: OCSP-X Internet Draft: Extensions to OCSP

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Tue, 12 Oct 1999 14:33:52 -0400

All,

	Attached is an Internet Draft written by myself, based on comments
by Mike Myers, recent proposals to the list by Ambarish Malpani, conference
submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
list (for a fuller list please see the draft, if anyone thinks they have
been
forgotten please email me).

	At the time OCSP was first introduced it was agreed that the protocol
could be a vehicle to support much more than certificate revocation status
checking. It was also the consensus that the draft should be extreemly
narrowly focused in order to make progress. For this reason extensions such
as trust path processing, time stamping and such were tabled for later
discussion. It is now 'later' and time to have that discussion.

	The draft addresses two shortcommings of SCVP. First, as discussed in
Oslo all the functions of SCVP may be addressed in the OCSP syntax and
there is no need to duplicate all the work already done on OCSWP. Second,
SCVP addresses only trust path processing. This only addresses half of the
issue that an ISV with a product to be PKI enabled must address, if a client
is to delegate trust processing for authentication then it might as well
delegate authorization as well.

	My belief that this is a natural functionality set is confirmed by
the appearence of several commercial products offering precisely these
functions.

	The approach I have taken in OCSP-X is substantially different in
approach however. In the first place the transfer protocol is OCSP/HTTP
rather than LDAP, in the second URIs are used to identify resources.

	The reason for choosing OCSP/HTTP over LDAP is that this is a
machine/machine interaction in which both sides know a-priori the exact
reference terms to be employed. The value add of LDAP over HTTP is a
resource discovery protocol which in this case is unneeded. By avoiding
the LDAP data model the issue of schema conflicts is avoided. I believe
that convergence on a common specification will be considerably easier
using OCSP/HTTP as a technology base than attempting to agree on a
common directory schema.

	Additionally the protocol proposal made here is a 'thin client -
fat server' approach rather than the 'fat client - thin server' approach
directories are designed to support.

	The use of URIs as names for authenticatable resources takes some
explanation and for this reason an appendix provides some worked examples.
I believe it may be prudent to separate these examples into a second,
non-authoritative draft at a later date to avoid the risk that conventions
used in the examples be assumed to be dependable parts of the standard.

	Essentially this protocol employs URIs as names in that it uses
the URI to refer to a resource without actually retrieving it. This was
the original intention of URNs.

			Phill

Phillip Hallam-Baker
Principal Consultant, VeriSign Inc.
+1 (781)245-6996 x227
[email-masked]

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 12 Oct 1999 12:28:24 -0700

Phil,

Was OCSP (and any variants) not intended to be transport
independent? OCSP should be available as value-add
on CMP-based products soon, for example.

Why do you propose that OCSP, when extended to address
additional PKI-related semantics, have this
transport independence removed?

This web-centric change of direction seems at odds
with what is an otherwise highly articulate argument.

(Though I praise your argument, above, this does
not mean I agree with all its design
assumptions or your beliefs concerning seemingly
MANDATORY co-location of authentication and
authorization providers. This would
be inappropriate in certain quite typical military
contexts whose infrastructure requires
separation of these two management needs,
and where LOCAL authorization control is a
requirement. See SDN 801 and later MISSI work...
as reported by Ford and others )

> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[email-masked]]
> Sent: Tuesday, October 12, 1999 11:34 AM
> To: [email-masked]'
> Subject: FW: OCSP-X Internet Draft: Extensions to OCSP
>
>
> All,
>

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Tue, 12 Oct 1999 15:51:51 -0400

> on CMP-based products soon, for example.

I believe you have misunderstood me. OCSP and OCSP-X are both
transport independent. CMP would remain an appropriate transport 
layer.

What I was attempting to explain (perhaps poorly) was the 
reason for using OCSP as a base technology as opposed to LDAP
which I anticipated might be the subject of extensive 
protestations if not arguments.

The ability to run over CMP (or for that matter SMTP!) would be 
one further reason to adopt the OCSP approach.

> This would

Quite so, the argument I was trying to make was that the 
specification having addressed one aspect of the should 
really go the whole way and address both. This is not the
same thing as saying that applications must USE the features,
just that they should be there.

The degree of authorization delgation must as you point
out be left to the specific configuration. I very much
agree on the issue of LOCAL authorization information
management as the examples in the draft discuss at length.

		Phill

---

From: Ed Gerck <[email-masked]>
Date: Tue, 12 Oct 1999 16:20:23 -0700

Phillip M Hallam-Baker wrote:

> been forgotten please email me).

Phill:

The draft begins:

 For an application to make an informed decision as to whether it trusts a
 digital certificate the application must have knowledge of the certificate
 itself,

where the "humanization" of applications extends to the entire text. To talk
about "informed decision", "have knowledge" and so on is not only a style
slip but IMO also a dangerous overslight inducer. For example, rephrasing the
above for applications that are not sentient would produce:

 For an application to decide whether a digital certificate is trusted, the
 application must [be programmed with a trust metric, defined here to
 include, exclusively,] trust on the certificate itself,

where one should note not only the passive role of the application as
an evaluator of trust (actually, a proxy for the end user) but also the now
clear input that must be provided to the application: the trust metric.
Which was not mentioned in  the original section and which is still not
specified simply by specifying its components (the trust points).

Besides, I encounter the words "trust management".  Of course, we are all
familiar with the words "trust", "trusted system" and "'trusted third party".

However, it is IMO unfortunate to call "trust management" what actually
is "decision management" or, at most, "authorization management".

First, because if "trust management" would exist then it would imply
managing what you do not control. So, "trust management" is  an
oxymoron and one which leads to a series of unrelated assumptions
regarding the usefullness of that "management" .

Second, because trust is not boolean -- while the RFC constructs are
entirely boolean, yes or no.

Third, the fact that people introduce soundbites like "trust management"
instead of using clear words like "authorization management", does not
mean that any relevant conclusions can be drawn from the misuse
of terms like "trust" in the soundbite.

In other words, if you can successfully "manage" something, there is
nothing left to "trust" about it. That is, "trust" is qualified reliance
upon a "value" that cannot be directly observed or controlled at the
moment a decision is to be made that would depend upon that value
-- and which does *not* depend upon you at all, so there is nothing
you can "manage" about it.  Calling it "trust management" may be
reassuring, that we have everything under control, but such is not
true otherwise there would no need to trust -- you would control it.

However, and in a positive note, since a decision is *always* boolean,
decision management is a boolean problem amenable to the RFC. Even
though the whole process of authorization is not represented in your
RFC (for example, I miss the issues of delegation), one could still also
use it for authorization management of certificate validity in a restricted
(and, not sentient) sense.

Thus, my suggestion is that the trust points as well as the trust metric
used in the RFC must be made clear, and not "humanized", so that they
can be rendered as a logical process amenable to a protocol. Perhaps,
other options for trust metric could also be made available, including
the question of transtitive trust (depth of certificate chains acceptable),
fresheness of each component, reliance of each component in a risk model
as defined by CPS, insurance policies, etc.  If this is too complex, then the
RFC should mention what it is implictly assuming.

Cheers,

Ed Gerck

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Oct 1999 10:54:20 +0100

Phill,

When SCVP was originally proposed, I voiced a number of 
questions and objections. I guess its time to repeat them, 
since I don't believe they were addressed at the time. 
Now that OCSP-X has entered the picture, I also have 
a few new ones to do with authorization.

From my reading of the situation, the only potential 
benefits of these protocols are:

	- to allow centralisation of PKI policy 
          enforcement, and,
	- to remove certificate path discovery from 
	  the client.

(NB: I said "discovery", a.k.a. path constuction, 
*not* path validation, about which I remain to
be convinced, but see later.)

1) For centralisation of policy, I'd assert that the 
PKIX WG is *not* the place where this should be considered.
We simply don't have sufficient input on the range
of applications which give rise to requirements to
do a good job. 

For example, the policy and AAA WGs are both examining
many of these issues, in broader contexts, and with
more familiarity with the actual issues which arise. 
I do believe that some of these WGs outputs will show
up a need for PKIX to tackle some issues, but we're
not yet at that point. To be concrete, I've been
doing some work on authorization in the AAA WG, and
there are many environments in which the authorization
approach proposed with OCSP-X just won't work!
(E.g. mobileip or remote access when there are brokers
involved. There'll be an updated authorization
requirements draft from the AAA WG in the next few days
which should clarify the point.) It may be that we
can make some progress on centralising PKI policies,
but if the clients still have to get their other
equally important policy some other way, then I'm 
not sure we're helping them very much.

2) Certificate path discovery, OTOH, is an issue which
PKIX should and can address. Personally, I'm open as
to whether this uses a new protocol, an OCSP extension
or a CMP or CMC extension, or all whether we provide
all of the above options.

2) One of the major difficulties with SCVP and OCSP-X that
I do see is with the whole idea of a server deciding 
which paths are trustworthy.I think the onus is on 
those proposing this functionality to answer, in 
detail:

	What are the *concrete* applications or protocols
	which need this functionality today?
	For each application:
		- how will SCVP/OCSP-X work?
		- what RFCs will need to be changed?
		- what deployed base will need to be
		changed or extended?
		- how will the switch from client 
		processing to server processing
		occur?
		- what *specific* benefit does SCVP/OCSP-X
		offer?

I'd be happier with all of this if someone could
convincingly show how an an S/MIME, IPSec, or TLS 
implementation would be improved. They need so
much other ASN.1 & crypto code that the savings
are very unclear.

So, in conclusion I think PKIX should:

- progress with server-side path construction
- think hard about policy and authorization, after
  taking a look at what other WGs need and 
  what they're doing
- provide a real justification for server-side
  path validation with concrete examples as 
  requested above.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Thu, 14 Oct 1999 11:35:39 -0400

Ed,

	The ability to use knowledge is not generally considered a
sufficient requirement for sentience. Knowledge is simply information
that can be used.

	The language used would be appropriate if a human were 
performing the task, it is therefore appropriate if a machine replaces
the human.

	I don't find it usefull to revisit Searle's Chineese room on
an IETF mailing list. The only reason that Searle's argument is
so much discussed is that it is so bad that everyone has their own
favourite means of arguing against it.

		Phill

---

From: "Steve Sodt" <[email-masked]>
Date: Thu, 14 Oct 1999 11:58:17 -0400

Just an aside, I've also heard it argued that - paraphrased - knowledge
enables the use of information, implying that it is a prerequisite to the
effective use of information.  In this sense knowledge is independent, and
information dependent.  Sorry to interject any unwelcome simplemindedness.

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: Thursday, October 14, 1999 11:36 AM
To: Ed Gerck
Cc: [email-masked]'
Subject: RE: Sentient applications, was Re: FW: OCSP-X Internet Draft:
Extensions to OCSP

Ed,

		Phill

---

From: Ed Gerck <[email-masked]>
Date: Thu, 14 Oct 1999 10:24:01 -0700

> sufficient requirement for sentience. Knowledge is simply information

Not knowledge, but reasoning without data.

> performing the task, it is therefore appropriate if a machine replaces

If what you say is true, then I move for us to apply it immediately to all
laws and get rid of all lawyers, now substituted by computers.

So, since that is not possible (yet?) your document would be better
appreciated, IMO, if it would allow the reader to use today's tools --
where one needs to replace vague human-based reasonings such as

 "For an application to make an informed decision as to whether it trusts a
  digital certificate"

with programmable assertions such as

 "For an application to decide whether a digital certificate is trusted, the
 application must be programmed with a trust metric, defined here to
  include, exclusively,"

which MUST include the trust metrics used for the decision, not only the
trust-points (certificate, signing key, etc.).  To do otherwise is to require
reasoning without data.

Also, I don't find it useful to remind us of the Church-Turing hypothesis as
explicit in your second paragraph, unless you also note that time and
memory space were not factors in that hypothesis.

Thus, exactly because I valued your text, I would suggest it should not require
infinite time and memory in order to be implemented.

Cheers,

Ed Gerck