Transition history

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

Acknowledgment cycle

Transition history

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?

Acknowledgment cycle

Transition history

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.

Acknowledgment cycle

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

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

Transition history

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 :

Acknowledgment cycle

Transition history

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

Transition history

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.

Acknowledgment cycle

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

Transition history

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:

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?

Acknowledgment cycle

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

Acknowledgment cycle

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.

Acknowledgment cycle

Transition history

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

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.

Acknowledgment cycle

Transition history

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

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

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

Acknowledgment cycle

Transition history

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.

Acknowledgment cycle

Transition history

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

Transition history

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

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

Acknowledgment cycle

Transition history

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

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

Acknowledgment cycle

Transition history

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

Transition history

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.

Transition history

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

Transition history

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

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.

Acknowledgment cycle

Transition history

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.

Acknowledgment cycle

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

Transition history

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.

Acknowledgment cycle

Transition history

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

Acknowledgment cycle

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

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.

Acknowledgment cycle

Transition history

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?

Transition history

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

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

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

Transition history

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.

Acknowledgment cycle

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.

Transition history

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

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

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

Transition history

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

Acknowledgment cycle

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

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