Re: OCSP-X vs SCVP

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> 
> A few weeks ago, there was a brief discussion of OCSP-X vs SCVP.  The only 
> consensus point was that we need to have one PKIX solution for 
> certification path validation, not two.  However, we did not pick one of 
> these two alternatives.  I think we need to pick one.  We should not put 
> further efforts into two solutions.

> 
> There are at least three communities that need to be served by this 
> protocol: very lightweight clients, organizations that want centralized 
> control, and clients that do not parse ASN.1 but understand XML.  I am not 
> sure that there is consensus about these user groups.  If not, we need to 
> get to consensus ...

> 
> If these are the user groups that we are trying to satisfy, then I think 
> that SCVP is the better answer.
> 
> Let the debate begin ... 

If I remember correctly, the first element of the discussion was
that we are actually talking about 'two services', i.e., path
determintation and path validation. And that there was some feeling
that the SCVP definition of path determination is not sufficient.
  
Or, SCVP contains two completely different parts, and at least
one of them is not a protocol at all. 

Furthermore, I do not think that having defined two concrete encoding
for the same abstract data is enough reason alone to choose a protocol. 

The ASN1 SCVP encoding use 'yet another signature scheme'.
It is already unfortunate that in the ASN1 case we have at least three
different ways of signing data, i.e., x509 certs, pkcs7 signeddata, 
ocsp responses. I don't think we need a new one. Think about the
the code to validate a time stamped pkcs7 extended signature
containing some responses from ocps and maybe scvp.
 
The error and status codes defined a character strings are not reusing
semantically equivalent and already existing data like PKIStatus.

The XML part still requires that an implementation knows something about
ASN1. What about having the protocol not just validate the certificate,
but also to extract the textual components like X509IssuerSerial, keyInfo
etc, i.e. allow a very light client that has no ASN1 knowledge at all. 

The overall OCSP response data structures are also somewhat unfortunate.
There are several layers: an unsigned outer part, a security envelope
(signature), signing arbitary content defined by an OID. Several content
definition. IMHO, the outer level is useless, because you need to look at
the signed content anyway. The signature scheme is as bad as the X509 cert
scheme, two passes necessary for verification. I am not quite sure why one
hadn't simply used pkcs7. 

I have the impression that any of the content types that are defined
in OCSP, or TSP, etc, could be encoded as well in XER++ instead of DER, 
CER, BER. IMHO this encoding rules should not be defined on a protocol
by protocol basis, but in a general way. This may needs some restriction
of the use of some ASN1 features or/and a way to express things like asn1
structures encapsulated in octet/bitstrings, in order to get a non blob
version of Extensions for example.

Then, for example If someone likes the PSResponse content, it seems possible
to me to define an OID for that and use this either in an OCSP response, or
as a pkcs7 signed data content, or as xmldsig protected data.
In other words, any protocol should specify the data to be transported, 
requirement about the security needs for transport and long term, and one
should try to use already established techniques. 
 
BTW: Marc is right about ASN1: "liberez A S N un, liberez A S N un" !!! :-)

nuf said.
Peter