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

FW: Changelog Issues list part 2

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 4 Dec 2002 09:33:13 -0800
Message-ID: <CE541259607DE94CA2A23816FB49F4A34D61E5@vhqpostal6.verisign.com>
To: "Www-Xkms (E-mail)" <www-xkms@w3.org>
 

 
84 Deferred pending the great policy debate, probably want to mention
UseKeyWith here
 
85 Added in after message format
 
No XKMS operations are idempotent, that is all XKMS requests MAY cause a
change of state.
 
86 Change as follows:
 
xkms:X509Chain	 <ds:X509Data>*	 X509 Certificate v3 chain that
authenticates the specified key. Note that no ordering is implied in the
returned private key	
 
Note that OCSP was already specified in the spec.
 
89 Added the citation to follow the phrase XML Signature each time it
appears for the first time in a paragraph following standard academic
citation style.
 
92 No the text is necessary if the reader does not understand what XML
signature is
 
96 Deferred
 
100 Probably moot as result of the great policy debate
 
101 Fixed, was a typo, is ResponseMechanism
 
103 Deferred
 
104 Done
 
105 Deferred - Have made quite a few changes but not sure comment fully
addressed, wait for printout.
 
106 Done, actually the comment was meant to convey that we use the id
attribute, NOT unconstrained XPath navigation
 
107 No, Compound request is initiated by the client unilaterally. The
only valid response to compound request is a compound response or 'I
don't do that'
 
Issue: should we state that all XKMS responders must implement the
entire message set even if they do not implement the actual operations.
Ie it has to be able to generate a response but the response might be
'not implemented'.
 
108 Added a note to this effect. Need decision on removing entirely
 
xkms:MgmtData	 <ds:MgmtData>	 
Management Data (Note Management data is deprecated in the XML Signature
Speciation  <outbind://11/#XML-SIG> [XML-SIG])
 
109 Changed to just HTTP
 
110 reworded as follows:
 
An XKMS service MAY provide an interface to an underlying PKI such as
PKIX or PGP. This specification does not define how XKMS operations
interact with the underlying PKI. The XKMS Key Binding MAY be bound to a
data object such as a Certificate or Key Signing in the underlying PKI
such that XKMS operations on the Key Binding result in a corresponding
change to the data structures in the underlying PKI and vice versa. If
for example the XKMS service provides a mapping to an underlying
PKIX/X.509 PKI the registration of a key binding would typically result
in the issue of a certificate, even if the client does not ask for the
certificate to be returned in the registration result. If the key
binding were subsequently revoked the corresponding certificate in the
underlying PKI would typically be revoked also.
 
111 
 
p11 done with minor changes (its XML signature)
p35 done
49 done
53 done
86 done
96 done
109 done
 
112 edits - 
 
278 done
282 done
216 done
222 done
286 done
 
 


Received on Wednesday, 4 December 2002 12:33:17 GMT

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