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

From: "Kingdon, Kevin" <[email-masked]>
Date: Tue, 12 Oct 1999 16:50:17 -0700

A few comments and questions about the OCSP-X draft (mostly about the
ASN.1):

Why use EXPLICIT context tagging for the SingleExtendedStatus CHOICE?
Wouldn't IMPLICIT tagging produce a more efficient encoding without
increased complexity for "hand-written" encoders?

What are the semantics implied by the SEQUENCE OF SEQUENCE { OBJECT
IDENTIFIER } definition of Rules? What purpose is served by wrapping the
Rule oid in a sequence?

I believe the Evaluate type would be better defined as a BIT STRING of named
bits. The current structure should at least define the SEQUENCE elements as
OPTIONAL.

The AuthorizationMode type would also be better defined as a BIT STRING of
named bits. If defined as a SEQUENCE, the elements should be OPTIONAL and
use IMPLICIT tagging.

The AuthorizationStatus type is not completely defined. I believe it should
be a CHOICE of IMPLICIT-ly tagged NULLs.

It would help me to understand how OCSP-X fits into OCSP if some example
PDUs were included. I would suggest using the ASN.1 value notation for these
examples.

Kevin W. Kingdon
RSA Security, Inc.

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

		 << File: Certificate Extensions to OCSP III.txt >> 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]