This is the Disposition of Comments for the Candidate Recommentation XKMS Working Drafts:
Appendix C of the XKMS Version 2 Candidate Recommendation, entitled Sample Protocol Exchanges, contains examples of key derivations, some of which appear not to be accurate. I enclose my suggested corrections below.
Section 8.1 (Use of Limited-Use Shared Secret Data) says that "All space and control characters are removed." Given sections C.1.2 and C.1.3, this suggests that a hyphen is a control character. For the sake of clarity I propose using "punctuation characters" instead of or in addition to "control characters".
Also, it might be more appropriate to call the derived quantities "Secret Keys" as opposed to "Private Keys".
C.2.1 Alice Pass Phrase Computation
The values are correct, but the lines
should read
C.2.2 Bob Pass Phrase Computation
The values are correct, but the lines
should read
The proposed corrections were made to the Editor's draft.
Appendix C of the XKMS Vesion 2 Candidate Recommendation, entitled Sample Protocol Exchanges, contains examples of key derivations.
It might be more appropriate to call the derived quantities "Secret Keys" as opposed to "Private Keys".
The proposed corrections were made to the Editor's draft.
There is another error in Section C.2.2 that I missed:
This line:
should read:
The proposed corrections were made to the Editor's draft.
There is a part of the Schema defining "RequestSignatureValue" element in the Compound Request Section (par[127]) which I think it should appear before the beginning of this section, in par[126].
The proposed corrections were made to the Editor's draft.
In the definition of the "StatusRequest" element (par[132]) it is said that it inherits the element attributes of "PendingRequestType", and the same can be understood from the Schema. However, the "ResponseId" attribute -which is already part of "PendingRequestType"- is defined there. To make it more confusing it is said to be Optional whereas in "PendingRequestType" it was Required. Should this reference be removed from there?
The proposed corrections were made to the Editor's draft.
Maybe this is not so important, but in the Data Encryption Example (par[146]) a key is bound to bob @ "example.com" but then in par[147] the name used is bob @ "bobcorp.test". Of course the example is perfectly understandable but maybe both paragraphs should be consistent.
Typo in example - Complete fixed para [146].
If I have a QueryKeyBinding with 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. Do let us know if this causes any implementation problems in your code.
Stephen Farrell: I can imagine the union vs. intersection result being influenced by who's asking, from where, about whom, with which UseKeyWith, etc. I could also imagine a responder treating all such cases as an error for validate and doing a union for locate!
And I don't think it causes implementation problems, other than looking at how to code in the flexibility to allow a user to make the choice. If worst comes to worst we can always make a decision to go one way or t'other.
I did have one potential niggle that concerned me from an interop perspective on the second issue. If a client sends out a request with a particular set of UseKeyWith elements and receives back a response with a superset of those original elements, it *might* cause confusion if the client is only expecting a subset of what it asked for. (I think it would have to be a fairly naive implementation, thus only mild concern.)
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. Do let us know if this causes any implementation problems in your code.
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.)
And I don't think it causes implementation problems, other than looking at how to code in the flexibility to allow a user to make the choice. If worst comes to worst we can always make a decision to go one way or t'other.
I did have one potential niggle that concerned me from an interop perspective on the second issue. If a client sends out a request with a particular set of UseKeyWith elements and receives back a response with a superset of those original elements, it *might* cause confusion if the client is only expecting a subset of what it asked for. (I think it would have to be a fairly naive implementation, thus only mild concern.)
I assume there is a requirement on implementations to ensure that the signature(s) in a message actually refer(s) to the XKMS content. That's probably pretty obvious, but I can see some fairly trivial attacks against implementations that just check a signature is valid without ensuring that the reference actualy refers to the XKMS message.
Is this something worth mentioning in the security section?
Yes it should be mentioned if its not, so best is probably to add this to the issues list so it gets properly checked.
Section 10.11 was added to the spec, with the following text:
The Implementation of XKMS MUST check for signature value reference in the to-be-signed data when using a signed SOAP message. Also, Implementations MUST ensure that all bytes in the XKMS messages ex. from
Section 8.2.1 of Part 1 of the XKMS spec covers an element <RSAKeyPair> intended to carry public and private parameters of an RSA key pair.
However, the adjoining schema fragment (as well as the complete XKMS schema) does not define this element. Instead it defines another element, <RSAKeyValue>.
RSAKeyPair appears more appropriate for the intended purpose, so I'd favor a schema update, assuming this is not too late.
There is also a ds:RSAKeyValue in dsig so we don't want to reuse that element name either. I'd agree that we should change to properly use RSAKeyPair in the spec and schema, which is, as you point out, a substantive, though v. small, change to the schema.
There're associated changes required in the examples at the end of section 6.4 and in C.3.1, C.3.2 and C.3.3. Those should get caught as part of our "PR spec will contain samples actually used in interop" approach.
The proposed corrections were made to the Editor's draft.
Am not sure if this has been raised before, but I've been playing with schema validation of the various messages and have run into a problem with Xerces rejecting messages because of the (amongst others) KeyUsage Elements. In particular, the schema defines the KeyUsageType enumeration as follows :
I'm not a huge expert in XMLSchema, but my understanding is that enumeration values are literal. So if I use a different qualifier (or even no qualifier) it will fail strict validation.
E.g. the snippet
will fail, whereas
will succeed.
I think KeyBindingStatus will also have the same problem.
Am I misunderstanding XMLSchema? If not - do we really need to enumerate these values in the schema?
The Editor's draft of the XKMS schema was updated to use open
enumerations and the QNames were changed to URI values. The
open enumeration technique is described in
Paragraph [179] refers to TemplateKeyBinding; shouldn't this be PrototypeKeyBinding?
The proposed corrections were made to the Editor's draft.
Paragraph [115], "nonce attribute" should be "Nonce attribute".
The proposed corrections were made to the Editor's draft.
Paragraph [193], "both elements" should be "both attributes".
The proposed corrections were made to the Editor's draft.
Paragraph [149], the text states that KeyName and KeyValue are requested however in [150] only KeyValue is actually specified in request.
The proposed corrections were made to the Editor's draft. KeyName was droped from p. [149].
Paragraph [109] 3.2.4 Element <PendingNotification> Table has a column URI; use Mechanism instead?
The proposed corrections were made to the Editor's draft.
Part-2, paragraph [50] LocateRequest message contains invalid Respondwith value <RespondWith>Multiple</RespondWith>.
The line was suppressed from the example.
Paragraph [67] "with a value of true" should be "with a value of 1".
The proposed corrections were made to the Editor's draft.
Paragraph [68] SOAP 1.1 namespace URI in message should be
The proposed corrections were made to the Editor's draft.
The SOAP 1.2 namespace URI refers to a working draft
[http://www.w3.org/2002/06/soap-envelope] through out.
Shouldn't this be
The proposed corrections were made to the Editor's draft.
RegisterResult and RecoverResult may both contain signatures over encrypted data, however the order of these operations is not explicitly stated in the spec.
Given the PrivateKey schema fragment, I'm inclined to draw the conclusion that only encrypt-then-sign is required. Is this the intention and if so does this warrant a clarifying statement to that effect?
Speculation:
I believe the (un-encrypted) RSAKeyPair is deliberatly omitted from PrivateKey so as to *allow* implementations to mitigate the risk of disclosure of sensitive stuff through, say, the use of special purpose cryptographic hardware that, apart from their primary purpose, also can be programmed to extract the private key components from the surface syntax of an RSAKeyPair element. I imagine that this design *could* stand in the way of supporting sign-then-encrypt in XKMS - assuming that generating/verifying an enveloped signature is performed over a schema valid document, which is the only way I have explored.
A new paragraph was added to the specification to remove the ambiguity:
In the process of trying to get my head around the compound messaging and I discovered what I believe is an inconsistency in the spec.
The last sentence in Section 2.8, which goes like this:
"Alternatively a client MAY issue a compound request containing multiple inner pending requests corresponding to requests which were originally made independently."
is in conflict with both the schema and also with text elsewhere in the spec - PendingRequests's are not allowed in a CompoundRequest.
If this feature is required then the schema needs to be updated otherwise we'll get away with removing the offending sentence.
Deleted last sentence in para[83].
In the section 3.5.2 of the spec [1] (Element <StatusResult>), p[134], there are explanations about three attributes (Success, Failed and Pending) and what do they mean in the case of a *compound request*. Nothing is stated about a simple request scenario. As I understand it, a code of Success="1" or Failed="1" or Pending="1" would be returned, but maybe a bit of clarification would be appreciated.
[1]
Modified p. [134] in Section 3.5.2 to describe the ResultType attributes for non-compound requests. That is, {Success, Failed, Pending} describe in this case the status of the request operation that has completed and are indicated in the ResultMajor attribute.
I understand the RequestAbstractType.RespondWith elements indicate what data items the requestor is interested in receiving in a result message and that a service is encouraged to honor these indications to the best of its ability.
Section 3.2.3 Element <RespondWith> has a table that is pretty much clear except for the row that contains the following:
OCSP <ds:X509Data> PKIX OCSP token that validates an X509v3 certificate that authenticates the key
If the "PKIX OCSP token" is a quantity that the service is meant to Respond With then what form does it take?
If the intent is to communicate a DER encoded OCSP ASN.1 type back to the requestor, should that not be specified in XKMS along with the markup that would carry it - presumably a new ds:X509DataType element of type base64Binary?
Or should this row be in the forementioned table in the first place?
There's and open action [1] on me to check in various places as to whether there ought to be a new ds:KeyInfo option which could contain OCSP responses.
Instead of doing that, I'd like to propose that for the purposes of XKMS, we remove the offending text, and thus offer no explicit support for returning OCSP status information in XKMS responses.
Two reasons:
a) I don't believe anyone's really depending on this, since 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)
b) I believe that consulting with PKIX and others, might take a long time to produce a result, and in any case, the PKIX folks are mainly taken up with revising rfc3280 these days, so the chances of the topic getting serious consideration are perhaps slim.
So, I propose we resolve the issue by removing mention of xkms responses containing OCSP responses. That means removing the OCSP row of the table in #3.2.3 and the related line of schema (an enumeration, so no impact elsewhere).
[1]
Removed the OCSP row of the table in #3.2.3 and the related line of schema - fixed para [104] and [106] and updated schema.
Following our client-server tests Tommy and myself were discussing about the number of OpaqueData elements that the specification *intend* to allow in an OpaqueClientData element.
It seems that the way the schema currently stands multiple OpaqueData children are allowed for a OpaqueClientData element,
, but currently only the first one is handled by Tommy's implementation and so we would like to get confirmation that that's not the expected behaviour.
I remember there was a mail from Tommy [1] suggesting a mention to the child element OpaqueData. On the other hand, the addition of "including its children" has clarified the text, so that might be enough.
[1]
Fixed Para 94: inserted ", including its children," to clarify further
In part-1 of the spec, many examples quote an XKMS service called
I propose that we change this to something more neutral like
or
To avoid having fallback if ever the real owners of that domain (which is registered), complain to us.
Probably a good idea. I prefer your first alternative since www.example.org exists and refers to rfc2606 whereas the 2nd one just gives a dns error.
FWIW, xmltrustcenter.org was a place where VeriSign put copies of specs etc. prior to the WG starting so I guess the chances of them complaining or of the domain changing hands are both v. small. I just looked for the 1st time in ages and the front page there is quite out of date so again the change is probably a good idea.
The proposed corrections were made to the Editor's draft.
In part 1, par. 122 gives a table that defines the ResultMinor codes. There are some cells in the middle column (Possible Major Codes) that are empty. It can be interpreted that that case is when there is no MajorCode.
I think that rather it's an explanation of the MinorResult by itself.
In all cases, it looks confusing.
Added phrase "Generic Description:" to the cells which don't have a corresponding major result in para[122].
Section 4, Security Bindings, of part-2 is not clear. It requires more explanation text. There is no description of what is meant by "variant" on the tables or why the variant column doesn't give variants to all the options in the tables.
Looks like it needs more editing.
N.B. JK: This issue was announced as closed early on, but required some extra edits since then (done by the Editor, with my feedback). I used the last message announcement and the changelog extract to say it was closed.
Updated and consolidated the tables and text in this section, adding more clarifications where needed. Among the applied changes, we can cite the following:
Removed the URIs related to client authentication modes (which were non-existent and non-normative) in p. [72] and replaced them with text.
Deleted sentence in p. [71] related to profile URIs. Changed "Variants" to "Client Authentication Modes" in p. [74].
Added the definition of payload security to part-1, Section 1.2.
Deleted Row in table [71b] which associated the Request/Response correspondence with the XKMS element Request/MessageDigest as it was an error.
Deleted Row in table [71b] which associated the Request/Response correspondence with the XKMS element Request/MessageDigest as it was an error.
In the tables [71b] and [74a], for Replay Attack, DOS, and Non Repudiation Protection, added "Any" as the client authentication mode.
Changed -- in table [71b] with "Not Applicable"
In table below p. [71b], for the Replay Attack, XKMS element column, added qualifier - "in two-phase protocol"
In the table p. [72], changed Request/MessageDigest to Request.Signature with MAC - which is more accurate
Changed table column name "XKMS element" to "Comment" in pp. [71b] and [74a]
How is the shared secret "holder" in an NotBoundAuthentication intended to be identified?
Apart from altering the schema (adding a "Name" attribute) the only reasonable option seems to be, to combine these two pieces of information and include their base64 encoding in the Value attribute.
For example, a protocol defined out of scope to XKMS and identified by the URI urn:example-protocol:username-password specifies that the Value attribute carries a username/password pair separated by a ':' would take the form of the following instance fragment
Not sure if the KeyName would be best there, since I'd rather keep the key and auth-id names separate, but in any case, there's Tommy's b64 idea or how about "secret+sfarrell@cs.tcd.ie" (like people use to filter emails). I could also imagine using (whatever's the official term for) a CGI parameter in the URI itself ("http://www.cs.tcd.ie/secrets?u=sfarrell").
So, I'd say we're ok not to change the schema for this one - there's enough flexibility for what is probably a corner case.
> Not sure if the KeyName would be best there,
I second that. It seems to me that the KeyInfo in the PrototypeKeyBinding is intended to communicate information to be bound to the key pair being registered.
> So, I'd say we're ok not to change the schema for this one -
>; there's enough flexibility for what is probably a corner case.
I am of the same opinion.
> Tommy's b64 idea
I think the prose could be clearer: - while the schema allows for NotBoundAuthentication be used in any X-KRSS message section 7.1.3 paragraph says that NotBoundAuthentication is for registration only.
- section 7.1.5 paragraph [296] makes liberal use of the phrase "limited use shared secret" ; I don't like the innuendo of that and suggest that replacing this with simply "authentication data" would be more appropriate. Sure, using a limited use shared secret even as per section 8.1 may well be part of the Protocol, but this is specified by the Protocol and therefore out of scope in this spec.
Fixed pp. [291] and [296] - replaced "registration request" with "X-KRSS request"; used the phrase "limited use shared secret" as an example for "authentication data".
[1]
The spec sometimes mentions AbstractRequestType, and sometimes mentions RequestAbstractType (but obviously means the same type). These should be unified.
Replaced AbstractRequestType with RequestAbstractType in paras [111] and [128] in the Editor's draft[1].
[1]
I have *no* objections against the way in which these were handled.
In paragraphs 188 and 189, the semantics of the ValidityInterval element when used inside a UnverifiedKeyBinding element could be clearer. Currently, the spec says that an UnverifiedKeyBinding "describes" a key binding, but "makes no assertion regarding the status of the key binding."
So, what does "the time interval in which the key binding relationship is asserted" mean in a context where no assertion is made?
Modified explanation for ValidityInterval in par. [189] of part-1[1] as follows:
ValidityInterval [Optional]
The time interval for which the key binding relationship is requested to be asserted.
[1]
I have *no* objections against the way in which these were handled.
This protocol basically consists in sending a double hash (the RevocationCodeIdentifier) of a (presumably) user-typable or even user-picked pass phrase as part of the PrototypeKeyBinding element of a RegistrationRequest, and later sending a simple hash of the pass phrase (the RevocationCode) to authenticate a RevocationRequest. The spec does not contain any confidentiality requirements for these messages, and does not suggest encrypting them; paragraph 288 specifically talks about sending the RevocationCode "as plaintext."
An attacker with access to a RevocationCodeIdentifier can launch an offline dictionary attack to recover either the RevocationCode or the pass phrase. The intended recipient of these identifiers can also, of course, launch an offline dictionary attack. These dictionary attacks are an issue when the underlying pass phrases contain too little entropy.
Further, eavesdroppers with access to RevocationCodeIdentifier elements are able to determine whether two revocation codes are identical. If multiple key bindings are associated with the same revocation code identifier (and, hence, the same revocation code) and an eavesdropper observes one revocation transactions, then this eavesdropper is able to create valid revocation requests for any of the other key bindings with identical revocation code.
Based on these observations, I would recommend the following changes to the specification text:
* paragraph 288: "The double MAC calculation ensures that the <RevocationCode> value may be sent as plaintext without the risk of disclosing a value which might have been used by the end-user as a password in another context."
I would suggest to strike this text, for several reasons:
- As far as low-entropy passwords are concerned, the double MAC calculation doesn't ensure anything: These passwords are made accessible to an offline dictionary attack and can subsequently be compromised. (They aren't technically disclosed, though.)
- The text seems to indirectly encourage re-use of shared secrets across different contexts. It shouldn't.
- The text seems to suggest the use of low-entropy passwords to generate the revocation code. It shouldn't.
Paragraph 363 suggests that "the shared secret SHOULD contain a minimum of 32 bits of entropy if the service implements measures to prevent guessing of the shared secret, and a minimum of 128 bits of entropy otherwise."
It should, at the very least, be made crystal clear that "measures to prevent guessing of the shared secret" should include strong confidentiality protections for revocation code identifiers and revocation codes, to provide safeguards against the dictionary attacks outlined above, and to protect against attackers recognizing deliberate or accidental collisions of revocation codes.
* The security considerations part of the document should make clear that implementations should not re-use revocation codes across different key bindings (regardless of the amount of entropy used when generating them). Note that strong confidentiality protection of RevocationCodeIdentifier and RevocationCode elements would also help against this problem.
Other than the resolutions suggested, (which look fine at first glance), ought we put in place a better (though non-interoperable!) fix for the "able to determine whether two revocation codes are identical" threat which looks, now that he says it, a bit sloppy?
Fixes could be:
- use a salt, chosen at registration time and available for querying (needs a new operation, so yuk) at revocation time
- use some keybits, which is fine so long as you haven't lost the key (key loss being quite likely in a revocation scenario)
- lodge foo=H(H(pwd),X) where X is a random integer between 0 and 15, and at revocation time send all 16 possibles, resulting in an 1-in-4 chance of a foo-collision given the same pwd? (terrible hack and I've probably gotten the math wrong as usual, plus, the 1st revocation exposes the collision in any case, but at least the collision isn't apparent from the responder DB)
All sound like a bit too much work at this stage, so would anyone like to do any of these, or is there a better idea?
Deleted the first sentences in para [288] as suggested.
Added clarification statement in para [363] about guessing of shared secrets.:
[363]...Implementations should not re-use revocation codes across different key bindings (regardless of the amount of entropy used when generating them). Note that strong confidentiality protection of RevocationCodeIdentifier and RevocationCode elements would also help against this problem....
[1]
I have *no* objections against the way in which these were handled.
I have a technical question. It concerns Revoke, Reissue, and Recover requests. These types of requests contain a reference to their own types of KeyBindings (RevokeKeyBinding, ...) extensions from KeyBindingType base type. And this type contain a Status element. In your examples, for these types of requests, Status is always set to "Intermediate".
I do not understand the utility of this field in requests. Would it be possible to imagine other values than "Intermediate" in requests, and if so, in which cases ?
Frederic's question would no doubt be best answered by someone with a better perspective of the XKMS schema's evolution than myself, however, I am willing to offer my personal view:
I didn't find any occurences of the "Intermediate" so I assume that Frederic meant "Indeterminate". As a result, I don't think this is an editorial issue.
It looks like the primary intended use of the KeyBindingType is in the KeyBinding element in a ValidateResult. It is not clear how a server can make use of the Status element in Revoke, Reissue anad Recover operations and in any case, I think the server should probably not rely on the client's opinion of the Status of a key binding.
The fact that the {Revoke, Reissue, Recover}KeyBinding elements are all of type KeyBindingType has the unfortunate(?) 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.
Also, the addition of a RevocationReason info set element in a RevokeRequest would be welcome - at least X509 and PGP supports this notion.
All of this obviously implies schema changes and it is getting late for that.
The following paragraph was added to the Editor's draft[1]:
[206a]Note that the X-KRSS {Revoke, Reissue, Recover} KeyBinding elements are all of type KeyBindingType, which requires a Status element (c.f. Section 7). In the case of Reissue, Revoke, and Recover requests, servers MAY ignore the Indeterminate <Status> status value and Clients MAY set Indeterminate as status value.
[1]
Section '7.1.7 Element PrivateKey' does not specify whether or not to include a Type attribute in the EncryptedData [1]. I have seen this specified in other specs that make use of EncryptedData, most recently in SAML 2.0. The difference is that in XKMS, it is not intended that the EncryptedData be used with a decrypt-and-replace operation. Instead, it seems, the content of the EncryptedData (the RSAKeyPair markup) is to be treated as a separate document.
The fact that everybody reported interoperability despite the fact that my own server implementation and that of SQLData use different values for the Type attribute has led me to believe that the usefulness of the Type attribute in this application is limited.
However, since it is possible/likely that the RSAKeyPair is pre-appended with an XML declaration (^lt;?xml ... ?>) I am thinking it would be appropriate to require a Type attribute value of http://www.w3.org/2001/04/xmlenc#Content *if* the Type attribute is present. The MimeType attribute, while advisory, should be "text/xml" if present.
[1]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".
Due to the contradictory wording of Section '4.4.5 The PGPData Element' of XMLSIG[2] 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.
[2]
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.
[1]
N.B. This topic was discussed with Tommy, who is part of the XKMS
WG, on the 8 March 2005 XKMS Teleconference (
As the ProofOfPossession element is optional, an additional ResultMinor #ProofOfPossessionRequired would enhance clarity in situations where a client does not include this element for a server that requires it.
The proposed changes were accepted and added to the Editor's draft[1].
[1]
If a server does not support the TimeInstant element, it should indicate a failure *unless* it includes the optional ValidityInterval. The spec does not currently require this. Here too an additional result code may be useful.
A new minor result code, TimeInstantNotSupported, was added to the Editor's draft[1], A server returns this code when it doesn't support optional the TimeInstant element, rather than just silently discard it (updated pars. [213] and [122]. Updated the description of the TimeInstant element and corresponding result codes to schema.)
[1]
The AuthenticationType is currently a xsd:sequence consisting of two optional elements, KeyBindingAuthentication and NotBoundAuthentication. I can't think of a reasonable usage scenario where both of these would be present (or both absent). An xsd:choice may be a better ... choice. Alternatively, some constraining text would do the job.
The WG didn't want to modify the XKMS schema at this point of time. Added sentence "XKMS Responders do not have to support both of these optional elements in a request message." to para 291 of part-1[1].
[1]
RespondWith is only advisory so this is not a big deal but ...
RespondWith's should be discouraged/disallowed in request types for which the corresponding result type does not contain any key binding types. i.e. CompoundRequest, PendingRequest and StatusRequest. The CompoundRequest could be an exception, in which case it should be stated that RespondWith's in the containing request are applied to all inner requests.
Updated para [112a], [128a] and [132] of part-1[1] by adding that the <RespondWith> element cannot be present in these request elements.
@@@ JK: verify with Tommy.
[1]
After some thought and analysis, my feeling is that XKMS has an ambiguous use of the term [Optional] when referring to elements and attributes.
The interpretations that this term can have here are:
- An element or attribute that a client or a server may choose to include in a message.
- Implementation of a given element or attribute is required/recommended/optional
The point I want to make here is that we may have an optional element, but whose implementation is required by a server. If the implementation is optional, the server may then decide to ignore it. However, it should not ignore it if the implementation is required.
In few cases, the spec actually says that the implementation is optional. Most of the time it just says optional and it lets the reader the guesswork as to whether the inclusion of the element/attribute or its support by a client/server is optional.
In my opinion, this is is a source of confusion and of potential interoperability problems. The spec should be more precise here, while still leaving freedom of choice to the user.
You'll find here below a list (n.b. left in the original message [1]) of all the elements and attributes that are optional. I think it would really be good to have some extra text that says if their implementation is optional, recommended or required. We could add this as an appendix too.
[1]Defined a new ResultMinor code, OptionalElementNotSupported. A server returns this code when it doesn't support a given feature. See par. [352a] of part-1[1].
[1]
(summarizing this issue reported by Tommy for archival purposes)
The X-KRSS message defines the KeyBindingAuthentication element that lets a server authenticate the key binding element within an X-KRSS request. The content of this element has a ds:Signature calculated with an HMAC using a preshared secret.
The XKMS CR specification doesn't define how to identify the preshared secret. One developer did it using ds:KeyInfo.Keyname, while another one used UseKeyWith with a request can notify the server which shared secret it used. One implementation used ds:Keyinfo.Keyname where another one used UseKeyWith with certain values to make it work.
In order to avoid interoperability problems, it would be good if the XKMS recommended how to do this. Tommy's proposal to use ds:KeyInfo.Keyname for this makes sense to me.
Added the following paragraph to the Editor's draft[1]:
[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.
[1]
Deprecated the shared string canonicalization algorithm in favor of
the
The changes were made to Section 8.1, p. 329a-c of the Editor's spec[1].
[1]
The spec. is not clear for what happens in an asynchronous request if a user sends a ResponseMechanism=Pending without including a PendingNotification element (which is optional). This seems to imply that the client needs to poll the server using the StatusRequest. This is not clear in the spec.
The spec says that the service MAY use the notification mechanism indicated by the client, it does not have to do it. Therefore, it may be prudent of a client implementation to not rely only on notification to indicate when to issue the PendingRequest but to also to poll using StatusRequest, after all the notification may never arrive.
Part-1 of the draft specification[1] was modified to add a more explicit polling/notification description and the text in pp. [55] and [56] and in Section 2.5. A new section, 2.5.2, was added to cover the Status Request polling procedure. The asynchronous example given in this section was revised and an SMTP notification example was added.
[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.
[1]