XKMS 2.0 draft comments

I agree with the URL use to specify the trust model, and the need to include
the SigningContext in the response. I'm not sure I understand how the
meaning is associated with a URL, other than to say it is out of band
agreement. Also, although URLs aren't supposed to change, they do. Again I
assume this is out of scope.

I have some questions and comments on the XKMS 2.0 working draft.

1) I suggest that the primary classifications not be named by Tier or
message but by purpose, as follows:

KeyInfo Retrieval (Tier 0 - ds:RetrievalMethod processing)
KeyInfo Resolution Service (Tier 1 - Locate processing)
KeyInfo Parsing Service (Tier 2 - Validate processing)

Resolution/Tier 1: Locate section comments
2) The resolution service (Locate) implicitly has the trust server vouch for
the result, since it returns it. What is vouches for is that the values
returned correspond to the KeyInfo and that they were obtained correctly
from the underlying service (for example, that the X.509 certificate was
parsed correctly). This does not imply that the service vouches for the
timeliness of the information (e.g. certificate validity), a value added
service. The spec should make clear that the trust server does vouch for
what it returns.

3) The Respond element should use XML elements for the types of returned
values instead of strings
(e.g. <string>KeyName</string> should be <KeyName/>), and  also support
namespaces in this mechanism, e.g. <ds:KeyName xmlns:ds="..."/>

4) Alternative to using digital signatures for request/response
authentication and integrity, transport security such as SSL could also be
used (although this would not provide persistent integrity for archived
requests/responses).

5) In the encryption example, how does a client application know the KeyName
to use? Presumably this is communicated out of band. Is this something to be
looked up in a UDDI directory?

Binding Validation/Tier 2 Validate

6) Isn't the ValidityInterval an attribute of the status, or to put it
differently, isn't the status conditional upon the ValidityInterval
assertion?
Does this imply that the XML ValidityInterval element should be  a child of
the Status element? In other words, what if a client application just checks
status and does not process the rest of the XML result. It would produce the
wrong result sometimes... It might be valuable to allow an application to
pull out the status without examining the rest of the XML in some
circumstances (e.g. to see if still valid now)

7) To make use of digitally signed trust server responses the client
application needs to have XML signature verification capability Are we
assuming that client applications will have a trusted server public key
installed and be able to verify XML digital signatures with this key? Does
this bring us back to the browser approach of having pre-installed trusted
keys?  Is it correct to say that a client application does not need to have
a trusted server key installed if a shared secret is negotiated and an HMAC
used for authentication?

KIS messages

8) Does XKMS encode all values as element data for compatability with SOAP?
If so, why isn't the use of ds:KeyInfo attribute values a problem with SOAP?
More explanation would be helpful to understand the rationale.

9) Why does the RequestAbstractType include MajorVersion and MinorVersion?
I've noticed that most XML recommendations use namespaces for versioning.
Should XKMS be different in this, or is something else happening here?

10) SOAP Faults
I believe all error responses should be in XKMS responses and for the
specific SOAP binding it may be an optimization to replicate them in the
SOAP response, but the body of the XKMS spec should not assume SOAP faults.

Validate Service

11) Do we have a clear definition of "trust policy" or a reference to a
definition? How are trust policies communicated? I agree with the list
discussion that this can be configured avoiding the need for complicated
dynamic mechanisms.

12) What does "security enhancement" mean,  in the section on KeyId? I
assume it means that KeyId is a URL corresponding to a class of applications
that use a key for some purpose (confidentiality, integrity), but based on
URI templates. How does this communicate whether the key is for signing or
encryption if the application could use more than one key?

KeyUsage

13) The draft says the key usage element should be ignored when a key usage
is specified that the algorithm does not support. I'd argue it should be an
error, since ignoring the key usage implies that the client intention is
ignored. If the intent to be able to ask if a given key is valid for a given
use, then if the queried use is wrong, I'd expect either an error or "no"
response.

KRS  - Registration

14) Some clarification in this section might be useful For example, although
KeyId is not required (in the schema), it provides a simple linkage to many
applications which use keys and can form a primary index.

15) Does the order of requested values in a response match the order in a
request? Presumably there is no requirement?

Key Registration Service message set

16) An explanation of pending would be useful - some requirements on the
pending response will be the appropriate context information.

17) If one registration binds one group of attributes with a key, and then
another step binds another group, subsequently there is no meaning to the
groupings associated with registration. In effect each assertion bound with
the key is independent. Is this true?

18) Presumably a  reissue request is to issue a new certificate for a key
(for certificate lifecycle management), although it could be viewed more
generally as changing the validity interval for an assertion.
The section might need more explanation.

Cryptographic algorithm section

19) Is the intent to say use XML encoding but only the ASCII printable
characters, allowing use of unicode ascii format? Is use of XML encoding
consistent with specifying no "control characters", presumably a term with
meaning in ASCII.

20) What is the rationale for using different mac keying values, or is it
just to create a broader target hash space?

21) Is the length of 160 MAC dependent and should it be explicit in the XKMS
spec?

22) Serial numbers should not be simply increasing integers to avoid replay
attacks, they should not be predicatable, is that correct?

---
Frederick Hirsch
Zolera Systems, http://www.zolera.com/
Information Integrity, XML Security

Received on Wednesday, 28 November 2001 14:45:08 UTC