RE: apologies and comments on SCVP

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Ron,

> ----------
> From: 	Ron Ramsay[SMTP:Ron.Ramsay@OpenDirectory.com.au]
> Sent: 	Sunday, August 29, 1999 9:15 PM
> To: 	'Mary_Ellen_Zurko@iris.com'; Ambarish Malpani
> Cc: 	ietf-pkix@imc.org
> Subject: 	RE: apologies and comments on SCVP
> 
> But a library will require that each client collect CRLs, that each
> client be configured with the business/trust rules, etc. This sounds
> like a significant systems administration problem.
 
Not if the library does all this.  Then the only question is whether the
client acquires this functionality via a protocol or via a library with an
API (note that the library may achieve this essentially by itself or by a
protocol exchange with an SCVP server; this is invisible to the client).

Either mechanism (protocol or API) removes the complexity from the client,
so this is not the basis for the choice.  It may be argued that a library
requires a larger footprint than a protocol engine, but even this is not
necessarily true (since, as mentioned above, the library may perform the
validation by using a protocol to an external server), so this cannot be the
basis for the choice.

Ultimately, what it comes down to (it seems to me) is how many "things"
(applications, operating system, other protocol engines, etc.) on the client
platform need this functionality.  If the answer is "more than one", then
the library/API is probably a better architectural model than having each of
these "things" implement its own protocol engine for validation.  A single
library called by all these "things" is likely to be a smaller footprint
overall than multiple instances of a validation protocol.  If, on the other
hand, the answer is "one" (i.e., a totally dedicated, single-use device)
then it probably makes little difference, although the straight protocol
would have a slightly smaller code size than the protocol with an API
wrapper and might be preferable...

Carlisle.

> > -----Original Message-----
> > From:	Mary_Ellen_Zurko@iris.com [SMTP:Mary_Ellen_Zurko@iris.com]
> > Sent:	Friday, August 27, 1999 9:55 PM
> > To:	Ambarish Malpani
> > Cc:	ietf-pkix@imc.org
> > Subject:	RE: apologies and comments on SCVP
> > 
> > Hi Ambarish,
> > 
> > > 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.
> >      Mez
>