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

Edits

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 25 Sep 2002 09:43:13 -0700
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869BD5@vhqpostal.verisign.com>
To: XKMS <www-xkms@w3.org>

All,

	I have made the following edits to the draft, links to issues list
in parenthesis (), paragraph numbers with squarebrackets or hash #.

	This constitutes the majority of the editorial items that were
non-involved (i.e. involving schema changes). More to come.


(2)  [Throughout] Changed assertions to keybinging

(10) #198 Changed the text to the following:

A Registration service MAY support key recovery. For key recovery to be
possible the private key to be recovered MUST have been previously escrowed
with the recovery service, for example by means of the XKRSS registration of
a server generated key. A key recovery request is made in the same manner as
the initial registration of a key except that since the registration service
might not have a record of the key binding to be recovered the result code
xkms:NotFound MAY be returned.
The key recovery service is likely to require time to respond to the
recovery request. Clients supporting Key Recovery SHOULD support
asynchronous processing.


(10)  #201 Clarification text on revoke on recover

The policy of this particular registration service is to revoke a private
key whenever key recovery is performed. A registration service might adopt a
revoke on recover policy for a number of reasons which include concern that
the recovery process might be considered to have compromised the key in some
way.  The service returns the revoked key binding and the private key
parameters:


(12) Added borders to tables


(14) Fixed

(18) Done

(38) Removed the To Do list.

(40) Done

(41) #22 Typeface on <ds:KeyInfo>

(42) #103 The schema def is missing for KeyBindingAbstractType in the prose.

(43) #163 
(44) #168
	[And similar problem with <prototype> ]


(45) ##21 Clarification on 'super-encryption'

The use of transport or payload confidentiality protection is NOT a
substitute for the encryption of private keys specified in the XKRSS
Registration and Recovery services. A service that supports registration of
server generated keys or Key Recovery MUST implement the use of XML
Encryption with a strong cipher. 

(46) ##everywhere] Identifiers

All identifiers are now http://www.w3.org/2002/03/xkms# etc


(48) Done - see 18.

(59) Done

(60) Fixed, it is the unencrypted private key parameters
Received on Wednesday, 25 September 2002 12:41:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:17 GMT