Reorganization of the changelog

Hi folks,

In a pre-review, my colleagues asked us to reorganize the Changelog
in the spec so that one can see in a glance what has changed between
the XKMS CR and PR versions (without taking into account minor changes
like typos or rewording for clarification).

I sorted the issues and previous changelog compiled the following 
list of changes.  Please review the first section (Changes between
CR and PR) to see if I was not to strict. I put in that section
everything that resulted in a change of the spec, other than
clarification.

If there are no objections,
I'll put the markup into the PUB spec tomorrow for the list (except for
the declined issues). I plan to  reuse the links that Shivaram already
put in his changelog.

Thanks!

-jose

Changes between CR and PR
-------------------------

- Fixed the key derivations and examples in Appendix C (313-tl-1,
  314-tl-1)

- Added Section 10.11 for requiring that implementations check that
  the signature of a signed SOAP message actually refers to the XKMS
  content (317-bl)

- Deprecated the use of RSAKeyValue for RSAKeyPair. Both were defined
  for the spec., with the same, use, but the text was not
  consistent. The spec. and the schema were changed to use RSAKeyPair
  and RSAKeyPairType instead of RSAKeyValue and RSAKeyValueType,
  respectively. (318-tl).

- The XKMS schema was updated to use open enumerations and the QNames
  were changed to URI values. The open enumeration technique
  is described in
  http://lists.oasis-open.org/archives/wss/200402/msg00011.html. The
  rationale for the change is given at
  http://www.w3.org/2001/tag/doc/qnameids.html#sec-archrec. (319-bl)

- Order of sign and encrypt. RegisterResult and RecoverResult may both
  contain signatures over encrypted data, however the order of these
  operations was not explicitly stated in the spec. Par. [372a] was
  added to the spec. to be more explicit. "Implementations supporting
  encryption of Private Key Data MUST support Shared Secret. Use of
  Shared Secret is detailed in section 8.1.". (321-tl)

- RespondWith and OCSP. The encoding for communicating a PKIX OCSP
  token was undefined. The OCSP row of the table in section 3.2.3 and
  the related lines in the XKMS schema were removed. Fixed pp. [104]
  and p106] and updated (324-tl).  schema. Reasons for the change: The
  WG doesn't believe anyone's really depending on this. The XKMS
  response itself can effectively give the same information, but more
  directly, and with probably equivalent security (if the XKMS
  responder is going to cheat on you, it can probably set things up so
  you'll swallow a bogus OCSP response by first feeding you a bogus
  caCert). (324-tl)

- Children of the OpaqueClientData element. Modified the
  OpaqueClientData element definition so that it also comprises the
  children of this element. (325-ga)

- Unclear Security Bindings section in part-2. Reformatted and cleaned
  the text in part-2, Security Bindings to make it more precise
  (328-jk). Removed @@@add the features that were removed and why)

- Key Revocation Protocol. Added a clarification statement about
  guessing of shared secrets in p. 363. (330-tlr-3).

- Status field in requests. Modified pars. [205] and [221] to say that
  servers may ignore an "Indeterminate" as status value and Clients
  may set "Indeterminate" as status value. The fact that the {Revoke,
  Reissue, Recover} KeyBinding elements are all of type KeyBindingType
  has the side effect that the Status element is required in all of
  these elements. Instead they should be of types derived directly
  from UnverifiedKeyBindingType (or KeyBindingAbstractType); this
  would allow for information set elements better suited for each of
  the intended purposes. However, the WG decided against making this
  XKMS schema modification. (331-fdl)

- Element PrivateKey and Type attribute in the EncryptedData.
  The following text was added to the description of the
  xenc:EncryptedData element: The Type attribute SHOULD be present
  and, if present, MUST contain a value of
  http://www.w3.org/2001/04/xmlenc#Content. The MimeType attribute,
  SHOULD be "text/xml". (332-tl1)

- Processing of TimeInstant and ValidityInterval. A new minor result
  code, TimeInstantNotSupported, was added to the Editor's draft[1]
  (updated pars. [213] and [122], added text to the TimeInstant
  element and corresponding result codes to schema.) (332-tl4)

- More informative failure codes. Added the following ResultMinor
  error codes to table [122] so that the server can be more precise on
  why a request failed:

   - OptionalElementNotSupported: The receiver has refused the
     operation because it does not support the OPTIONAL Element value
     present in the request. (333-jk)

   - ProofOfPossesionRequired: The receiver has refused the operation
     because it requires the sender to include the ProofOfPossession
     element in the request. (332-tl3)

   - TimeInstantNotSupported: he receiver has refused the operation
     because it does not support the TimeInstant element. (332-tl4)

   - TimeInstantOutOfRange: The receiver has refused the operation
     because the indicated time is outside the range that it responds
     to. (323-tl4)

- KeyBindingAuthentication and NotBoundAuthentication. The
  AuthenticationType is currently a xsd:sequence consisting of two
  optional elements, KeyBindingAuthentication and
  NotBoundAuthentication. There is apparently no reasonable usage
  scenario where both of these would be present (or both absent). To
  constrain the use of these elements, the following sentence was
  added: "XKMS Responders do not have to support both of these
  optional elements in a request message." to [291] to constrain their
  use (the WG didn't want to further modify the XKMS schema and add
  xsd:choice at this point of time). (332-tl5)

- Use of RespondWith. Changed pp. [112a], [128a], and [132] to disallow
  the use of a <RespondWith> element child in the request elements
  that do not contain any key binding types, i.e., CompoundRequest,
  PendingRequest, and StatusRequest. (332-tl6)

- HMAC key authentication and shared secret key hints. The XKMS spec
  doesn't define how to identify a pre-shared secret. Added the
  following following advisory text (p. 277a).  Clients and Responders
  MAY use dsig:KeyName for HMAC validation. Alternatively, they may
  use other Identity related information derived from security
  binding, such as the Sender's IP address. (334-jk)

- In Section 8.1, use of Limited-Use Shared Secret Data, p. 29,
  deprecated the shared string canonicalization algorithm in favor of
  the StringPrep SASL profile (change proposed 22/Dec/2004, in message
  http://www.w3.org/2002/02/mid/20041222163421.GA15731@inrialpes.fr,
  and accepted during the XKMS teleconf of 11/Jan/2005
  http://www.w3.org/2001/XKMS/Minutes/050111-tele.html).

Summary of changes to the XKMS schema
-------------------------------------
N.B. The XKMS target name space was not changed.

- Changed RSAKeyValue and RSAKeyValueType to RSAKeyPair and RSAKeyPairType respectively

- Replaced qname with URI using open enumeration technique described
  in http://lists.oasis-open.org/archives/wss/200402/msg00011.html
  Rationale for the change is given at
  http://www.w3.org/2001/tag/doc/qnameids.html#sec-archrec

- Updated annotation regarding documentation

- Removed the following OCSP enumeration value from
  RespondWithEnum. Rationale: Issue 324-tl <enumeration
  value="http://www.w3.org/2002/03/xkms#OCSP"/>

- Added prefix xml: to lang:"en"

- Added ResultMinorEnum codes ProofOfPossessionRequired,
  TimeInstantNotSupported and TimeInstantOutOfRange. Rationale: Issues
  332-tl3 and 332-tl4

- Added ResultMinorEnum code OptionalElementNotSupported . Rationale: Issue 333-jk

Detailed list of changes (major and minor)
------------------------------ 

- 313-tl-2 
- 315-ga-1 * (def)o 
- 315-ga-2 * (double def.)  
- 315-ga-3 
- 320-tl-1 
- 320-tl-2 
- 320-tl-3 
- 320-tl-4 
- 320-tl-5 
- 320-tl-6 
- 320-tl-7 
- 320-tl-8 
- 320-tl-9 
- 322-tl 
- 323-ga (clarification) 
- 326-jk
- 327-jk 
- 329-tl 
- 330-tlr-1 
- 330-tlr-2 
- 330-tlr-3 (only the first part)

Declined Issues
----------------
@@@ this is only for the implementation report

316-bl-1: Clarification: Multiple answers for a QueryKeyBinding with 
both KeyInfo and UseKeyWith elements?
   
   If I have a QueryKeyBinding both a KeyInfo and a set of UseKeyWith
   elements, and the two constructs refer to different keys (or sets
   of keys), I assume the resultant response is implementation
   dependant? (I.e. union vs. intersection of keys found under the two
   sets of conditions.)

   This issue is deliberately not addressed. The union
   vs. intersection result could be influenced by who's asking, from
   where, about whom, with which UseKeyWith, etc. A responder could
   treating all such cases as an error for validate and
   doing a union for locate!

   It could be confusing for fairly naive implementations, but
   otherwise won't represent implementation problems.

316-bl-2: Clarification: Multiple answers for a QueryKeyBinding with a
single UseKeyWith item?

   If I have a QueryKeyBinding with a UseKeyWith item, and there are
   actually multiple applications defined for the key that is found,
   should the LocateResult have all the potential applications defined
   in the response UseKeyWith items, or just the intersection between
   those originally requested and the full list? (Again, I assume
   application dependant?)

   This issue is deliberately not addressed by the XKMS
   specification. Some keys can be shared across applications
   (e.g. S/MIME and TLS client auth), others might be mandated not to
   be so shared e.g. a VPN or SET cert (ok ignoring that SET is kind
   of dead-ish, but it did specifically mandate that its certs not be
   used for other apps.)

   It could be confusing for fairly naive implementations, but
   otherwise won't represent implementation problems.

   Some keys can be shared across applications (e.g. S/MIME and TLS
   client auth), others might be mandated not to be so shared e.g. a
   VPN or SET cert (ok ignoring that SET is kind of dead-ish, but it
   did specifically mandate that its certs not be used for other
   apps.)

332-tl2: Editorial: dsig:PGPData element and "Trust computations"
   
   Due to the contradictory wording of Section '4.4.5 The PGPData
   Element' of XMLSIG it is not clear whether or not PGP packet
   types other than Key Material Packet's are allowed in a
   PGPKeyPacket. In order to support XKMS clients that want to perform
   "trust computations" themselves (as opposed to delegating this to
   an XKMS service), access to SignaturePackets and TrustPackets would
   be useful. This is an XMLSIG issue, but I thought it would be
   prudent to mention it here anyway.

   This issue was declined as the working group feels that this is a
   XML DSig [1] issue.  It has also been mentioned that this issue
   could be adressed as an XML DSig Errata.

Received on Wednesday, 13 April 2005 15:45:45 UTC