- From: Jose Kahan <jose.kahan@w3.org>
- Date: Wed, 13 Apr 2005 17:45:43 +0200
- To: www-xkms@w3.org
- Message-ID: <20050413154543.GA24976@rakahanga.inrialpes.fr>
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