W3C XKMS Ver. 2 Candidate Recommendation Issues

Inside: Issue summary | State description | Decision cycle description | Issue details (Validate data)

This is the Disposition of Comments for the Candidate Recommentation XKMS Working Drafts:

XML Key Management Specification (XKMS) Version 2.0

XML Key Management Specification (XKMS) Version 2.0 Bindings

Issue summary (43 issues)

Reformat summary with options:
Expert mode options
Hide columns:
Hide issues by type:
Hide issues by state:
Hide issues by acknowledgment:

Other views: types | states | concerning | reviewers | open actions

Changes between dates (YYYY-MM-DD) and [Optional]

For maintainers: new issue data | new issues list data

Color key: error warning note

Id:Title StateTypeAck.
313-tl-1 : Innacurate examples of key derivations in Appendix CagreedchangeNo reply from reviewer
313-tl-2 : Use of "Secret Key" term rather than "Private Key" in Appendix CagreededitorialNo reply from reviewer
314-tl-1 : Error in Section C.2.2agreededitorialNo reply from reviewer
315-ga-1 : Misplaced definition of "RequestSignatureValue"agreedchangeNo reply from reviewer
315-ga-2 : Double definition of "ResponseId" attributeagreedchangeNo reply from reviewer
315-ga-3 : Typo in exampleagreededitorialNo reply from reviewer
316-bl-1 : Multiple answers for a QueryKeyBinding with both KeyInfo and UseKeyWith elements?declinedclarificationAgreement
316-bl-2 : Multiple answers for a QueryKeyBinding with a single UseKeyWith item?declinedclarificationAgreement
317-bl : Make a requirement that signatures in a message actually refer to the XKMS contentagreedchangeNo reply from reviewer
318-tl : Missing RSAKeyPair element in the XKMS schemaagreedchangeNo reply from reviewer
319-bl : Enumerations in schemaagreedchangeNo reply from reviewer
320-tl-1 : Editorial fixes for XKMS Spec. Part 1agreededitorialNo reply from reviewer
320-tl-2 : Editorial fixes for XKMS Spec. Part 1agreededitorialNo reply from reviewer
320-tl-3 : Editorial fixes for XKMS Spec. Part 1agreededitorialNo reply from reviewer
320-tl-4 : Editorial fixes for XKMS Spec. Part 1agreededitorialNo reply from reviewer
320-tl-5 : Editorial fixes for XKMS Spec. Part 1agreededitorialNo reply from reviewer
320-tl-6 : Editorial fixes for XKMS Spec. Part 2agreededitorialNo reply from reviewer
320-tl-7 : Editorial fixes for XKMS Spec. Part 2agreededitorialNo reply from reviewer
320-tl-8 : Editorial fixes for XKMS Spec. Part 2agreedchangeNo reply from reviewer
320-tl-9 : Editorial fixes for XKMS Spec. Part 2agreededitorialNo reply from reviewer
321-tl : Order of sign and encryptagreedchangeNo reply from reviewer
322-tl : Compound messaging spec and schema inconsistencyagreededitorialNo reply from reviewer
323-ga : StatusResult attsagreedchangeNo reply from reviewer
324-tl : RespondWith and OCSPagreedchangeNo reply from reviewer
325-ga : Unbounded or Opaque (Client) DataagreedchangeNo reply from reviewer
326-jk : Using a neutral XKMS service in the examplesagreededitorialNo reply from reviewer
327-jk : Unclear minor result code tableagreededitorialNo reply from reviewer
328-jk : Unclear security bindings sectionagreedchangeNo reply from reviewer
329-tl : NotBoundAuthenticationagreedchangeNo reply from reviewer
330-tlr-1 : AbstractRequestType / RequestAbstractType ambiguityagreededitorialAgreement
330-tlr-2 : Semantics of the ValidityInterval elementagreedchangeAgreement
330-tlr-3 : Concerns with the key revocation protocolagreederrorAgreement
331-fdl : Question about Status field in requests agreedchangeNo reply from reviewer
332-tl1 : Element PrivateKey and Type attribute in the EncryptedData element agreedchangeNo reply from reviewer
332-tl2 : disg:PGPData Element and "trust computations" declinedchangeAgreement
332-tl3 : Additional ResultMinor status for required ProofOfPossesion element agreedchangeNo reply from reviewer
332-tl4 : Processing of TimeInstant and ValidityInterval agreedchangeNo reply from reviewer
332-tl5 : KeyBindingAuthentication and NotBoundAuthentication agreedchangeNo reply from reviewer
332-tl6 : Use of RespondWith agreedchangeNo reply from reviewer
333-jk : Ambiguity in the interpretation of [Optional] in XKMS agreedchangeNo reply from reviewer
334-jk : HMAC key authentication and shared secret key hints agreedchangeNo reply from reviewer
335-jk : Canonicalization algorithm for shared secret data agreedchangeNo reply from reviewer
336-jk : Implicit polling HMAC key authentication and shared secret key hints agreedchangeNo reply from reviewer

State description

Decision cycle description

Issue details

313-tl-1: Innacurate examples of key derivations in Appendix C [link to this issue]

Transition history

raised on 7 Apr 2004

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.1.2 Bob Registration Authentication Key
Authentication Data
3N9CJ-JK4JK-S04JF-W0934-JSR09-JWIK4
Converted Authentication Data
[33][6e][39][63][6a][6a][6b][34] [6a][6b][73][30][34][6a][66][77] 
[30][39][33][34][6a][73][72][30]
[39][6a][77][69][6b][34]
Key = HMAC-SHA1 (Converted Authentication Data, 0x1)
[92][33][7c][7c][3e][8d][3b][7a] [cf][11][59][89][36][64][56][69] 
[95][4f][8f][d7]
C.1.3 Bob Registration Private Key Encryption
Authentication Data
3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4
Converted Authentication Data
[33][6e][39][63][6a][6b][34][6a] [6b][73][30][34][6a][77][66][30] 
[39][33][34][6a][73][72][30][39] [6a][77][69][6b][34]
First Block = HMAC-SHA1 (Converted Authentication Data, 0x4)
[78][f1][e7][b1][b3][fd][0c][bc] [96][04][e7][01][4f][33][78][d3] 
[0b][c8][5f][bd]
Key = First Block XOR 0x4
[7c][f1][e7][b1][b3][fd][0c][bc] [96][04][e7][01][4f][33][78][d3] 
[0b][c8][5f][bd]
Second Block = HMAC-SHA1 (Converted Authentication Data, Key)
[1e][7f][e1][b0][ab][d0][f8][09] [2e][28][f3][9d][14][a8][d0][83] 
[2e][ab][ea][22]
Final Private Key
[78][f1][e7][b1][b3][fd][0c][bc] [96][04][e7][01][4f][33][78][d3] 
[0b][c8][5f][bd][1e][7f][e1][b0]
C.1.4 Bob Recovery Private Key Encryption
Authentication Data
A8YUT vuhhu c9h29 8y43u h9j3i 23
Converted Authentication Data
[61][38][79][75][74][76][75][68] [68][75][63][39][68][32][39][38] 
[79][34][33][75][68][39][6a][33] [69][32][33]
Private Key
[91][8c][67][d8][bc][16][78][86] [dd][6d][39][19][91][c4][49][6f] 
[14][e2][61][33][6c][15][06][7b]

C.2.1 Alice Pass Phrase Computation

The values are correct, but the lines

Pass Phrase Pass 1 HMAC-SHA1 (Converted Authentication Data, 0x1)
Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x2

should read

Pass Phrase Pass 1 HMAC-SHA1 (Converted Authentication Data, 0x2)
Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x3)

C.2.2 Bob Pass Phrase Computation

The values are correct, but the lines

Pass Phrase Pass 1 HMAC-SHA1 (Converted Authentication Data, 0x1)
Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x2

should read

Pass Phrase Pass 1 HMAC-SHA1 (Converted Authentication Data, 0x2)
Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x3)
Acknowledgment cycle
Not started
agreed on 24 May 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 12 Oct 2004

313-tl-2: Use of "Secret Key" term rather than "Private Key" in Appendix C [link to this issue]

Transition history

raised on 7 Apr 2004

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".

Acknowledgment cycle
Not started
agreed on 24 May 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 12 Oct 2004

314-tl-1: Error in Section C.2.2 [link to this issue]

Transition history

raised on 8 Apr 2004

There is another error in Section C.2.2 that I missed:

This line:

Base 64 Encoding of Pass Phrase Stage 1
    PHx8li2SUhrJv2e1DyeWbGbD6rs=

should read:

Base 64 Encoding of Pass Phrase Stage 1
    8GYiVK8zBD5E0q9Rq2Y/Gci0Zpo=
Acknowledgment cycle
Not started
agreed on 24 May 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 12 Oct 2004

315-ga-1: Misplaced definition of "RequestSignatureValue" [link to this issue]

Transition history

raised on 22 Mar 2004

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].

http://www.w3.org/2001/XKMS/Drafts/XKMS20030826/xkms-part-1.html

Acknowledgment cycle
Not started
agreed on 24 May 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 24 May 2004

315-ga-2: Double definition of "ResponseId" attribute [link to this issue]

Transition history

raised on 22 Mar 2004

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?

http://www.w3.org/2001/XKMS/Drafts/XKMS20030826/xkms-part-1.html

Acknowledgment cycle
Not started
agreed on 24 May 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 5 Jul 2004

315-ga-3: Typo in example [link to this issue]

Transition history

raised on 22 Mar 2004

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.

http://www.w3.org/2001/XKMS/Drafts/XKMS20030826/xkms-part-1.html

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

Typo in example - Complete fixed para [146].

Acknowledgment cycle
announced by group on 16 Dec 2004

316-bl-1: Multiple answers for a QueryKeyBinding with both KeyInfo and UseKeyWith elements? [link to this issue]

Transition history

raised on 21 Jun 2004

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.)

Acknowledgment cycle
Not started
declined on 23 Jun 2004

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!

Acknowledgment cycle
announced by group on 23 Jun 2004
agreement by reviewer on 23 Jun 2004

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.)

316-bl-2: Multiple answers for a QueryKeyBinding with a single UseKeyWith item? [link to this issue]

Transition history

raised on 21 Jun 2004

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?)

For example, the request was <xkms:UseKeyWith Application="uri1" Identifier="berin"/>

Is the result

<xkms:UnverifiedKeyBinding>
<ds:KeyInfo>...</ds:KeyInfo>
<xkms:UseKeyWith Application="uri1" Identifier="berin"/>
</xkms:UnverifiedKeyBinding>

or

<xkms:UnverifiedKeyBinding>
<ds:KeyInfo>...</ds:KeyInfo>
<xkms:UseKeyWith Application="uri1" Identifier="berin"/>
<xkms:UseKeyWith Application="uri2" Identifier="berin"/>
</xkms:UnverifiedKeyBinding>
Acknowledgment cycle
Not started
declined on 23 Jun 2004

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.)

Acknowledgment cycle
announced by group on 23 Jun 2004
agreement by reviewer on 23 Jun 2004

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.)

317-bl: Make a requirement that signatures in a message actually refer to the XKMS content [link to this issue]

Transition history

raised on 23 Jun 2004

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?

Acknowledgment cycle
Not started
agreed on 23 Jun 2004

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 .... must be included in hashing and in the resulting signature value of the message.

Acknowledgment cycle
announced by group on 25 Oct 2004

318-tl: Missing RSAKeyPair element in the XKMS schema [link to this issue]

Transition history

raised on 30 Jun 2004

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.

Acknowledgment cycle
Not started
accepted on 30 Jun 2004

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.

Acknowledgment cycle
Not started
agreed on 25 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 24 Oct 2004

319-bl: Enumerations in schema [link to this issue]

Transition history

raised on 4 Jul 2004

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 :

<simpleType name="KeyUsageType">
<restriction base="QName">
<enumeration value="xkms:Encryption"/>
<enumeration value="xkms:Signature"/>
<enumeration value="xkms:Exchange"/>
</restriction>
</simpleType>

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

<xk:KeyUsage 
xmlns:xk="http://www.w3.org/2002/03/xkms#">xk:Signature</xk:KeyUsage>

will fail, whereas

<xk:KeyUsage 
xmlns:xkms="http://www.w3.org/2002/03/xkms#">xkms:Signature</xkms:KeyUsage>

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?

Acknowledgment cycle
Not started
agreed on 5 Oct 2004

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 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

Acknowledgment cycle
announced by group on 12 Oct 2004

320-tl-1: Editorial fixes for XKMS Spec. Part 1 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [179] refers to TemplateKeyBinding; shouldn't this be PrototypeKeyBinding?

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-2: Editorial fixes for XKMS Spec. Part 1 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [115], "nonce attribute" should be "Nonce attribute".

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-3: Editorial fixes for XKMS Spec. Part 1 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [193], "both elements" should be "both attributes".

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-4: Editorial fixes for XKMS Spec. Part 1 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [149], the text states that KeyName and KeyValue are requested however in [150] only KeyValue is actually specified in request.

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft. KeyName was droped from p. [149].

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-5: Editorial fixes for XKMS Spec. Part 1 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [109] 3.2.4 Element <PendingNotification> Table has a column URI; use Mechanism instead?

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-6: Editorial fixes for XKMS Spec. Part 2 [link to this issue]

Transition history

raised on 5 Jul 2004

Part-2, paragraph [50] LocateRequest message contains invalid Respondwith value <RespondWith>Multiple</RespondWith>.

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The line was suppressed from the example.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-7: Editorial fixes for XKMS Spec. Part 2 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [67] "with a value of true" should be "with a value of 1".

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-8: Editorial fixes for XKMS Spec. Part 2 [link to this issue]

Transition history

raised on 5 Jul 2004

Paragraph [68] SOAP 1.1 namespace URI in message should be http://schemas.xmlsoap.org/soap/envelope/.

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

320-tl-9: Editorial fixes for XKMS Spec. Part 2 [link to this issue]

Transition history

raised on 5 Jul 2004

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 http://www.w3.org/2003/05/soap-envelope ?

Acknowledgment cycle
Not started
agreed on 13 Oct 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 13 Oct 2004

321-tl: Order of sign and encrypt [link to this issue]

Transition history

raised on 5 Jul 2004

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.

Acknowledgment cycle
Not started
agreed on 12 Oct 2004

A new paragraph was added to the specification to remove the ambiguity:

[372a]Implementations supporting encryption of Private Key Data MUST support Shared Secret. Use of Shared Secret is detailed in section 8.1.
Acknowledgment cycle
announced by group on 13 Oct 2004

322-tl: Compound messaging spec and schema inconsistency [link to this issue]

Transition history

raised on 28 Sep 2004

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.

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

Deleted last sentence in para[83].

Acknowledgment cycle
announced by group on 16 Dec 2004

323-ga: StatusResult atts [link to this issue]

Transition history

raised on 3 Sep 2004

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]http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

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.

Acknowledgment cycle
announced by group on 16 Dec 2004

324-tl: RespondWith and OCSP [link to this issue]

Transition history

raised on 31 Aug 2004

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?

Acknowledgment cycle
Not started
accepted on 23 Nov 2004

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] http://lists.w3.org/Archives/Public/www-xkms/2004Sep/0014.html

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

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.

Acknowledgment cycle
announced by group on 16 Dec 2004

325-ga: Unbounded or Opaque (Client) Data [link to this issue]

Transition history

raised on 31 Aug 2004

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,

        <sequence maxOccurs="unbounded">
           <element ref="xkms:OpaqueData" minOccurs="0"/>
        </sequence>

, 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.

Acknowledgment cycle
Not started
accepted on 28 Oct 2004

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] http://lists.w3.org/Archives/Public/www-xkms/2004Sep/0006.html

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

Fixed Para 94: inserted ", including its children," to clarify further

Acknowledgment cycle
announced by group on 16 Dec 2004

326-jk: Using a neutral XKMS service in the examples [link to this issue]

Transition history

raised on 12 Oct 2004

In part-1 of the spec, many examples quote an XKMS service called

     http://test.xmltrustcenter.org/XKMS

I propose that we change this to something more neutral like

    http://www.example.org/XKMS

or

    http://xkms.example.org/

To avoid having fallback if ever the real owners of that domain (which is registered), complain to us.

Acknowledgment cycle
Not started
accepted on 12 Oct 2004

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.

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

The proposed corrections were made to the Editor's draft.

Acknowledgment cycle
announced by group on 16 Dec 2004

327-jk: Unclear minor result code table [link to this issue]

Transition history

raised on 23 Nov 2004

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.

Acknowledgment cycle
Not started
agreed on 29 Nov 2004

Added phrase "Generic Description:" to the cells which don't have a corresponding major result in para[122].

Acknowledgment cycle
announced by group on 16 Dec 2004

328-jk: Unclear security bindings section [link to this issue]

Transition history

raised on 23 Nov 2004

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.

Acknowledgment cycle
Not started
agreed on 1 Mar 2005

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]

Acknowledgment cycle
announced by group on 18 Apr 2005

329-tl: NotBoundAuthentication [link to this issue]

Transition history

raised on 6 Dec 2004

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

<NotBoundAuthentication
    Protocol="urn:example-protocol:username-password"
    Value="YWxpY2U6c2VjcmV0"/>
Acknowledgment cycle
Not started
accepted on 6 Dec 2004

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.

Acknowledgment cycle
announced by group on 12 Oct 2004
agreement by reviewer on 6 Dec 2004

> 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.

agreed on 1 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 1 Mar 2005

330-tlr-1: AbstractRequestType / RequestAbstractType ambiguity [link to this issue]

Transition history

raised on 17 Jan 2005

The spec sometimes mentions AbstractRequestType, and sometimes mentions RequestAbstractType (but obviously means the same type). These should be unified.

Acknowledgment cycle
Not started
agreed on 1 Mar 2005

Replaced AbstractRequestType with RequestAbstractType in paras [111] and [128] in the Editor's draft[1].

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 1 Mar 2005
agreement by reviewer on 1 Mar 2005

I have *no* objections against the way in which these were handled.

330-tlr-2: Semantics of the ValidityInterval element [link to this issue]

Transition history

raised on 17 Jan 2005

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?

Acknowledgment cycle
Not started
agreed on 1 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 1 Mar 2005
agreement by reviewer on 1 Mar 2005

I have *no* objections against the way in which these were handled.

330-tlr-3: Concerns with the key revocation protocol [link to this issue]

Transition history

raised on 17 Jan 2005

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.

Acknowledgment cycle
Not started
accepted on 6 Dec 2004

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?

Acknowledgment cycle
announced by group on 17 Jan 2004
agreed on 1 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 1 Mar 2005
agreement by reviewer on 1 Mar 2005

I have *no* objections against the way in which these were handled.

331-fdl: Question about Status field in requests [link to this issue]

Transition history

raised on 13 Jan 2005

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 ?

Acknowledgment cycle
Not started
accepted on 24 Jan 2004

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.

Acknowledgment cycle
Not started
agreed on 1 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 1 Mar 2005

332-tl1: Element PrivateKey and Type attribute in the EncryptedData element [link to this issue]

Transition history

raised on 3 Mar 2005

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.

http://www.w3.org/TR/xmlenc-core
Acknowledgment cycle
Not started
agreed on 31 Mar 2005

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".

Acknowledgment cycle
announced by group on 31 Mar 2005

332-tl2: disg:PGPData Element and "trust computations" [link to this issue]

Transition history

raised on 3 Mar 2005

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] http://www.w3.org/TR/xmldsig-core

Acknowledgment cycle
Not started
declined on 8 Mar 2005

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] http://www.w3.org/TR/xmldsig-core

Acknowledgment cycle
announced by group on 31 Mar 2005
agreement by reviewer on 8 Mar 2005

N.B. This topic was discussed with Tommy, who is part of the XKMS WG, on the 8 March 2005 XKMS Teleconference (minutes). No acknowledge from Tommy was sent to the declined announce as Tommy agreed with it directly in the meeting.

332-tl3: Additional ResultMinor status for required ProofOfPossesion element [link to this issue]

Transition history

raised on 3 Mar 2005

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.

Acknowledgment cycle
Not started
agreed on 31 Mar 2005

The proposed changes were accepted and added to the Editor's draft[1].

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 31 Mar 2005

332-tl4: Processing of TimeInstant and ValidityInterval [link to this issue]

Transition history

raised on 3 Mar 2005

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.

Acknowledgment cycle
Not started
agreed on 31 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 31 Mar 2005

332-tl5: KeyBindingAuthentication and NotBoundAuthentication [link to this issue]

Transition history

raised on 3 Mar 2005

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.

Acknowledgment cycle
Not started
agreed on 31 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 31 Mar 2005

332-tl6: Use of RespondWith [link to this issue]

Transition history

raised on 3 Mar 2005

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.

Acknowledgment cycle
Not started
agreed on 31 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 31 Mar 2005

333-jk: Ambiguity in the interpretation of [Optional] in XKMS [link to this issue]

Transition history

raised on 3 Mar 2005

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.

http://www.w3.org/2002/02/mid/20050303060610.GA6487@inrialpes.fr
Acknowledgment cycle
Not started
agreed on 31 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 31 Mar 2005

334-jk: HMAC key authentication and shared secret key hints [link to this issue]

Transition history

raised on 3 Mar 2005

(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.

Acknowledgment cycle
Not started
agreed on 31 Mar 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 31 Mar 2005

335-jk: Canonicalization algorithm for shared secret data [link to this issue]

Transition history

raised on 22 Dec 2005
comment
Acknowledgment cycle
Not started
agreed on 31 Mar 2005

Deprecated the shared string canonicalization algorithm in favor of the StringPrep SASL profile. Indicated that binary data doesn't need to be canonicalized.

The changes were made to Section 8.1, p. 329a-c of the Editor's spec[1].

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 11 Jan 2005

336-jk: Implicit polling HMAC key authentication and shared secret key hints [link to this issue]

Transition history

raised on 8 Apr 2005

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.

Acknowledgment cycle
Not started
agreed on 13 Apr 2005

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] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html

Acknowledgment cycle
announced by group on 14 Apr 2005

Maintained by XKMS Working Group.

Last update: $Date: 2005/06/23 13:48:57 $


This page was generated as part of the Extensible Issue Tracking System (ExIT)