RE: SCVP-01

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Is the only thing difficult about a PKI iin its current way of evolution
- is which protocol do I use and where when and why...

I was quite happy in the good old days with signed DAP to X.500
(trusted) distributed directories using CRL and certficate component
matching rules and adding a few objects and processes to things to
provide different ways of dealing with status and validity . 
eg. It seems we can extend directory search matching rules to deal with
component matches (as per X.500/9), could we not also extend these to
deal with status and validation? ie take an object oriented approach to
information processing over a common protocol -

Rather than -  lets have a new protocol for every type of object
processing semantic....:-((( 

I hope traffic lights and air traffic control systems dont get too many
protocols:-)

regards as always

> -----Original Message-----
> From:	David P. Kemp 
> Sent:	Wednesday, September 01, 1999 11:07 PM
> To:	Alan.Lloyd@OpenDirectory.com.au; peterw@valicert.com
> Cc:	ietf-pkix@imc.org
> Subject:	RE: SCVP-01
> 
> 
> > From: "Peter Williams" <peterw@valicert.com>
> > 
> > Policy WG, and reuse: I would like to see the SCVP
> > specification take component form, enabling its
> > object to be reused in the extension mechanisms of other
> > suitable value-adding services, including CMP and DCS.
> 
> 
> I would like to see that too.  It's in the spirit of the (now-defunct)
> Certificate Management Message Format (CMMF):
> 
>  * define a set of messages, and define the sequence of messages
> exchanged
>     to perform a particular action.
>  * encapsulate/protect the messages using whatever transport/security
>     mechanism (CMP, CMS, DCS, AH/ESP, ...) fits the bill.
> 
> Defining transport-independent message sets for specific purposes
> reduces the difference between "a lot of single-purpose protocols" and
> "one big do-everything protocol", enables reuse of existing transport
> modules/APIs, and as a design paradigm should be a no-brainer.
> 
> Whatever happened to CMMF anyway?  Is this the time to revive it,
> before
> CMP and CMC go to Draft?