RE: apologies and comments on SCVP

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

I think that some of the SCVP discussion are like arguing
how to use a special version of a car, about your capablities
to drive, traffic jams, etc but your real intention is to find
an appropriate way to get somewhere.  

A user or even a client may not be interested per se in a
certificate chain or tree, the end application may need
a decision whether a given signature on a document is good
or whether a user is allowed to sign with its signature cert, 
or whether an encryption cert is good. These technical terms here
are in fact wrong, the user want to know who has signed a doc
and whether the signer was authorised, or to be sure that
he can exchange data in a confidential way with some partner etc.

> 
> So by and large, the CPU speed for such applications is irrelevant, 
> and it is very difficult to imagine an application that couldn't verify 
> a digital signature faster than it could send it off to a server to be
> done for it. So all really talking about is the amount of memory that is
> required, and it cost.
... 
> 
> Now of course, people probably have more memory in a digital watch than
> we used to have in mainframes back then, and a single chip contains 
> 1 to 4 megabytes or more, with very little discount for less memory.
> 
> So I'm still curious to learn exactly what kinds of applications really need 
> these functions, and what the business justification is.

The assumption is that the knowledge of how to validate a chain, the
cert chain, and the local company trusted root's and policies are
not available to the client. As soon as some online verification
is necessary, a one-shot proxy type doesn't seem such a bad idea.  

> 
> 
> > ClientType1 basically wants to be able to use public key
> > cryptography (and the PKIX infrastructure), without needing to
> > understand all of PKIX part1, OCSP, LDAP etc. It is outsourcing
> > the task of checking cert status, cert expiry, policy management
> > etc to the SCVP server. The main question ClientType1 is asking
> > is: "Hey, I got this cert, can I use it for application X?".
> > The minimal response the server needs to provide is a signed
> > yes/no. If you throw away all the extra stuff, you essentially
> > have the client sending in a cert and getting back a yes/no
> > answer.
> 
> Why is the best answer to this need a protocol instead of a library? It
> seems if this is a technical need, you could craft a nice library with
> simple APIs to do this.

I wonder whether someone remembers the discussion more than
a year ago about 'positive answers from OCSP'. There had
been several people who wanted a little bit more work to be
done by OCSP, especially the question of the availability 
of the signing CA cert. 

In fact, it is easy to slightly misuse OCSP and implement
whatever logic you want in the server. One could think about 
a kind of OCSP proxy or broker. 

OCSP provides an extension mecanism, thus the basic answer
of the OCSP would be the certificate chain, and in some
extension, the broker would return the actual responses
from other OCSP servers. 

In order to be syntactically conformant, a client can
always use a fake signing cert hash (or, in order to
be able to detect it, the cert of its broker.)

I gave up trying to ask extensions for OCSP shortly after
September last year after having read the DCS draft. 
 

Have fun.
Peter Sylvester