RE: OCSP-X vs SCVP

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

It seems to me that this discussion has focused on encoding and syntax, but
not on the semantics of path creation and validation. In other words, what
are the requirements for server-based (including delegated) path creation
(or discovery) and validation.

I would like to see PKIX's solution support the ability for a client to make
one request to a server to create and validate a certification path given an
end-entity certificate, with the option of having the server return the path
in its response. It should also be possible to include one or more
end-entity certificates in a request.

Frank

> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr]
> Sent: Friday, November 10, 2000 8:29 AM
> To: ietf-pkix@imc.org
> Subject: Re: OCSP-X vs SCVP
> 
> 
> > 
> > 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
>