Additional comments

Hi Jose -

Included are some comments, most of which relate to interoperability.  You may
treat them as issues. 

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 EncrypedData, 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 (<?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.

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

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

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

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

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

[1] http://www.w3.org/TR/xmlenc-core
[2] http://www.w3.org/TR/xmldsig-core
 
Regards,
Tommy

Received on Thursday, 3 March 2005 00:09:07 UTC