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

From: "Linn, John" <[email-masked]>
Date: Wed, 13 Oct 1999 16:19:48 -0400

Denis proposed the following as a candidate functional scope for an OCSP-X:

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

I agree that this would be a useful core set.  Further, return of (2) could
be optional.  It would be useful to those clients which wish to retrace the
path validation performed by the server, to display the path if needed, or
to record information for audit purposes.  If none of these cases hold,
return of the data collected by the server during the validation process
seems redundant. 

--jl

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 14 Oct 1999 14:39:29 +0100

John,

I fully agree with the additional explanations you have provided.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Oct 1999 14:17:55 +0100

John, Denis,

> I fully agree with the additional explanations you have provided.

'Fraid I don't, not "fully" anyway. Like I said in 
my previous mail, I'd still love to see a worked case 
showing why its a good thing to use a server to 
construct *and* validate *all* certificate paths
that a client will *ever* use. Even for one 
application, (e.g. TLS or S/MIME), I'm far from
convinced that this is a good approach. Until
I do see such an example, I'll be very sceptical.

(Don't forget, this isn't free, we'd be creating
a new highly attractive target for attacks, that
also has to be highly available and widely
contactable! Just imagine using this if you had
a mobile IP connection. Yuk!)

OTOH, I do see a use for such a service for
Denis' purpose, which, I guess, is to figure out 
whether a certificate was valid at some time
in the past as part of evaluating the evidence
for NR purposes. That's not what I read SCVP or
OCSP-X as trying to address though.

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: Denis Pinkas <[email-masked]>
Date: Thu, 14 Oct 1999 15:22:34 +0100

Stephen,

You made a good guess !

So at least you got one example, but you might be right to say
that's not what you read SCVP or OCSP-X are trying to address
though.

Denis

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 20 Oct 1999 10:51:19 -0700

> OCSP-X as trying to address though.

I believe OCSP-X is trying, amongst other things, to address the 
functions laid out in Section 8.1 of the VeriSign CPS, and 
similar requirements set out in more modern security
practice designs.
https://www.verisign.com/repository/CPS1.2/CPSCH8.HTM

The idea of authorization in VeriSign CPS 8.1 contrasts 
with technical authorization:

As Phill said, there is an "integrated" element of authorization,
but not the sense of X.509 AC's authorization
model, I suggest. The VeriSign CPS was designed to control the
behaviour of humans by tying them to intent so they
can be criminally prosecuted by govts or held in breach,
or liable for a tort, etc. ACs were designed
to instrument technical security systems, not
faciliate a legal protocol, per se.

In conclusion:

(1) I believe OCSP-X may co-locate "AC-type authorization
and access control" with signature verification functions. 
I disagree with Phill's apparent assertion that it is natural
for the VA deploymen to inherently colocate technical authentication 
and access  control decision making, and/or enforcement. 

(2) I also believe It IS appropriate in TTP-grade VAs (like VeriSign
and ValiCert) for there to be integrated, "natural" legal
authorization processing during signature verification,
as controlled by a C/VPS legal protocol.  OCSP-X seems to 
intend to enable this function to be partially performed 
by an entity distinct from the relying-party. The practice
statement of the VA responder (ValiCert's, AT&T's...)
then control the precise legal semantics, once the
OCSP-X packets have performed the raw signalling
and communication.