W3C home > Mailing lists > Public > www-xkms@w3.org > March 2002

RE: Issue: Server/Client key generation

From: Mike Just <Mike.Just@entrust.com>
Date: Wed, 6 Mar 2002 10:05:45 -0500
Message-ID: <9A4F653B0A375841AC75A8D17712B9C90257A923@sottmxs04.entrust.com>
To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com>, www-xkms@w3.org
Although I prefer the flatter structure with regard to avoiding Types, I
think that in this case, since we have a choice between either client or
server generated, I like the way it is defined now (i.e. as a choice within
a single register request).  (If we chose the other option, we'd have to
have two Reissue request elements as well, which I'd prefer not to do.)

Mike

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Tuesday, March 05, 2002 1:39 PM
To: www-xkms@w3.org
Subject: Issue: Server/Client key generation



Should we have separate requests for registering a server generated key and
a client generated key?

Pro: Cleans up the specification and schema somewhat

Con: Might encourage applications to only support one mode, the idea that
the client should be able to depend on the server for PKI support is
somewhat weakened.

Of course it may be that it only makes sense for applications to chose what
they support in this instance. Server generated keys typically only make
sense in the context of key recovery, an XKMS service may legitimately want
to avoid any contact with signing keys.


		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

 
Received on Wednesday, 6 March 2002 10:06:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:38 UTC