RE: alternate key server mechanisms

["william(at)elan.net" <william@xxxxxxxx>]

On Sat, 30 Jul 2005, Hallam-Baker, Phillip wrote:

> > From: Dave Crocker [mailto:dhc@xxxxxxxxxxxx]
>
> > It is also not clear that it is enforceable in any way other
> > than developing the
> > entire architecture from the start, which thereby misses the
> > benefits of starting simply.
>
> Architectures developed incrementally are inevitably piecemeal.
>
> If you are doing the architecture right the system gets simpler as you
> add more requirements.
>
> XKMS is capable of doing everything that PKIX does, only it can be
> implemented in about 2,000 lines of code rather than 250,000+

PKIX includes more features that are needed by anyone specification using
it. Its a base of framework for PK architecture with various components 
that can be reused in various systems building PKI.

For our use where we only need to confirm the public key is good, something
like what is described in PKIX certstore-http draft would be enough:
 http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-08.txt

Unless I'm mistaken that is less complex then XKMS and easier to deploy 
then SCVP.

> I always consider as many uses as possible, whether in the scope of the
> spec or not.

HTTP is the kind of protocol that is successful because its easy to build
upon. Closed protocols never achieve much used and are sometimes even 
supplemented in their own field by "alternative" use of some other protocol.

--
William Leibzon
Elan Networks
william@xxxxxxxx