Subject: Further comments on SCVP

From: Michael Myers <[email-masked]>
Date: Tue, 6 Jul 1999 08:24:56 -0700

All,

My data points on the similarities and diffs between RFC2560 and the
proposed protocol.  Analysis to follow.

Similarities between RFC2560 and the proposed protocol:
-----------------------------------------------------------------------

-  Both are online request-response protocols related to reliance on public
key certificates.
-  Both enable use of a digitally signed request.
-  Both enable generation of a digitally signed response
-  Both provide for OID-based request extensibility.
-  Both provide for OID-based response extensibility.
-  Both have optional nonces in the request.
-  Both enable integration of request nonces in the response.
-  Both enable basic revocation checking.
-  Both provide a producedAt value in the response.
-  Both include a value of thisUpdate in the response.
-  Both include response values for unknown, revoked and good.
-  Both enable inclusion of multiple certificates in the request.
-  Both establish request version numbers.
-  Both establish response version numbers.
-  Both enable inclusion of policy OIDs.
-  Both define response status fields
-  Both define a per-certificate response validation structure

OCSP further enables certificate validation against archives and the
optional specification in the request of the URL address of a requester's
intended responder. 

SCVP appears to introduce online certificate validation protocol elements
that eliminate or substantially reduce reliance on embedded trusted roots.
Call this the "Delegated Path Validation" (DPV) extension to the basic
concept of online certificate validation. Building on the above
capabilities, SCVP proposes a DPV transaction as:

Request extensions
------------------------
1.  Optional use of a RequestHash  in lieu of a digitally signed request.
2.  Explicit specification of a request being a path validation request vs.
a revocation status check.
3.  Optional inclusion of the subject certificate in the request.
4.  Optional support for PGP style public key management.
5.  Optional request for the value of subject public key, subject name,
certificate chain or revocation proof.
6.  Optional specification of intermediate certificates to use as a
supplement to the validation path of the subject certificate.
7.  Optional specification of trusted roots the server must rely on.
8.  Optional configuration identifier that points to a pre-defined set of
the above options.
9.  Extensions may be critical or non-critical.

And in the response: 

Response extensions
--------------------------
10.  "Unrecognized" error codes related to the above optional request
protocol elements.
11.  Validation response values for "valid", "notValid",
"temporarilyUnknown" and "unknown".
12.  Optional inclusion of an errorMessage text string
13.  Optional inclusion of subject public key value, subject name or path
validation chain, consistent with prior request.
14.  Optional inclusion of requestHash appearing in request.
15.  Optional inclusion of revocation proof content.
16.  Optional use of a digital signature

Mike