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

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Oct 1999 10:18:28 -0400

I share Stephen's concerns about PKIX getting involved in authorization; I
think it's way too premature.

There are many places where cross-certification is "outlawed" and path
discovery is pretty darn simple.  I think that's justification enough
to start work here.
	/r$

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 13 Oct 1999 16:42:45 +0100

> think it's way too premature.

I share the same concern too. We should not address authorization.
The document is in fact adsressing too many aspects. From the list
of functionality only two items should be covered/supported: 

1) validating a certificate * for a given time * against some rules
which would desribe an acceptable certification *forest* to be used
(a forest has several trees and thus several roots to be fully
explicit).

2) giving back to the user the certification path (i.e. the
certificate identifiers - not necessarilly the certificates
themselves) that have been used * for that given time * for the
validation, including the relevant revocation (i.e. CRLs) or status
(i.e. OSCP responses) information.

This would be quite sufficient at the time being.

Denis

---

From: Ed Gerck <[email-masked]>
Date: Wed, 13 Oct 1999 09:14:27 -0700

> > think it's way too premature.

I agree, except if the implict assumptions in the RFC (see my last msg) are
made explict.  Then, the RFC could specify authorization but with clear
trust metrics to be applied, not just trust points as it does today.  In
practice, though, this would not be very much different than what you
suggest below, which also IMO deals with authorization. For example,
you define one such trust metric below, authorizing a certificate to be
used if it meets the criteria trusted beforehand ("some rules",

> (a forest has several trees and thus several roots to be fully

Yes. However, for the sake of terminology (and, saving trees), the
data model you mention is not called forest but "network" -- in contrast
to a "hierarchical tree".  To summarize the difference, the network data
model can be regarded as an extended form of the hierarchic
data model – the principal distinction between the two being that
in a hierarchic structure, a child record has exactly one parent
whereas in a network structure, a child record can have any
number of parents (possibly even zero).

The other data model which could also be applied  is the relational
data model, which then would describe an acceptable *view* to
be used when authorizing a certificate within a trust metric.

Cheers,

Ed Gerck

---

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

All,

	To give some explanation for the proposed scope of OCSPX.
As I see it there are two potential models for deployment of
PKI functionality.

1)	Fat PKIX aware Client supported by minimal server
		bringing together a data set.

2)	Thin client, PK aware but not PKI aware, supported by
		PKIX aware server.

	As members of the group are probably aware, my personal
prejudice is for approach (1). This is however a prejudice and
not an argument. There are many applications in which the
second approcah is more appropriate. These include wireless
applications and interactions with legacy mainframes.

	[I find the references to "Mobile IP" and such irrelevant.
It is taken as a given that in any situation in which a client
is relying on a server for trust decisions that an appropriately
secure protocol will be employed and that the client will ensure
that the data supplied is authentic, this requires only mutual
authentication however and not a PK INFRASTRUCTURE. I will make 
this more explicit in the security issues section of next draft.]

	I believe there are applications which will mandate 
particular approaches. My hypothesis is that there is _NO_ middle
ground. Whenever there is a need for a thin authentication client
a fat authorization client will be unacceptable.

	As I specifically state in the draft, there is a security
risk in delegation of trust path dicovery to a remote server. There
is an additional risk in delegation of trust path validation. There
is however no ADDITIONAL risk in then adding the authorization since
an attacker who can spoof authentication can spoof authorization by
simply spoofing the identity of a sufficiently priviledged individual.

	[Equally the 'risk' introduced by delegating trust path 
discovery is not that great since regardless of where the data is 
analyzed it must come from an outside source.]

	Issues of timing and venue are important, so much so that
I would hope to see a little more explanation of opinions than
"I don't believe the time is right". The time is never right in 
the IETF, there is always another group. 

	I don't think that the IETF process progresses at such a 
reckless pace that we need be affraid of putting out proposals
for fear that it is 'too soon'. I have customers who have expressed
a clear demand for the functionality described. If the problem
is complex and needs time to be worked on then the time to start 
is now. The only reason to wait would be if there was insufficient
experience of PKI deployment to understand the problems at this
point. This is certainly not the case where I sit.

	That said, if there is a clear consensus that there is
a clear need etc. for one subset of the OCSP-X functionality and
no consensus for the remainder it may be appropriate to write
two drafts, one on the proposed standard track and another on the
experimental. I would like to see reasons other than "thats not
the way I want to do it" and I would like to see specific references
to the draft before taking this approach however.

		Phill