- From: merlin hughes <merlin@baltimore.ie>
- Date: Wed, 27 Nov 2002 18:55:43 +0000
- To: www-xkms@w3.org
Hi, Some minor comments - first schema edits, then pkcs 10.. 1. UseKeyWith Both the Application and Identifier are use="optional" (default). In line with PendingNotification, they should perhaps both be mandatory: <complexType name="UseKeyWithType"> <attribute name="Application" type="anyURI" use="required"/> <attribute name="Identifier" type="string" use="required"/> </complexType> 2. Both the OpaqueClientData element and its content are optional. I think we would be better off asserting that the content of containers such as OpaqueClientData is nonoptional, so there's only one way of saying that there is no OpaqueClientData; by omitting the element altogether. <element name="OpaqueClientData" type="xkms:OpaqueClientDataType"/> <complexType name="OpaqueClientDataType"> <sequence maxOccurs="unbounded"> <element ref="xkms:OpaqueData" /> </sequence> </complexType> 3. xkms:KeyInfo Is there a different semantic to the KeyInfo element in XKMS, or why don't we reuse the XMLDSIG one directly? element ref="dsig:KeyInfo" 4. OpaqueData In XBULK, OpaqueClientData could hold XML content; not just binary data. I don't think that the devolution to base-64 encoded content in XKMS is preferable; I'd rather any namespace="##any" (or ##other). <element name="OpaqueData" type="xkms:OpaqueDataType"/> <complexType name="OpaqueDataType" mixed="true"> <sequence maxOccurs="unbounded"> <any namespace="##any" processContents="lax /> </sequence> </complexType> 5. Status The entire content of Status is optional; should some be mandatory? I also think that a set of reasons is cleaner than three lists. I presume you can get a mix of valid and invalid reasons identifying what checks passed, what failed, etc. <element name="Status" type="xkms:StatusType"/> <complexType name="StatusType"> <choice minOccurs="0" maxOccurs="unbounded"> <element ref="xkms:ValidReason" /> <element ref="xkms:IndeterminateReason" /> <element ref="xkms:InvalidReason" /> </choice> <attribute name="StatusValue" type="xkms:KeyBindingStatus" use="required" /> </complexType> 6. TimeInstant Suggest that the Time attribute be nonoptional. 7. PassPhraseAuthentication Is an orphan. 8. RSAKeyValue In line with xmldsig, I'm tempted to suggest that the component elements are anonymous/whatever is the term: <!-- RSAKeyPair --> <element name="RSAKeyValue" type="xkms:RSAKeyValueType"/> <complexType name="RSAKeyValueType"> <sequence> <element name="Modulus" type="ds:CryptoBinary"/> <element name="Exponent" type="ds:CryptoBinary"/> <element name="P" type="ds:CryptoBinary"/> <element name="Q" type="ds:CryptoBinary"/> <element name="DP" type="ds:CryptoBinary"/> <element name="DQ" type="ds:CryptoBinary"/> <element name="InverseQ" type="ds:CryptoBinary"/> <element name="D" type="ds:CryptoBinary"/> </sequence> </complexType> It just doesn't seem that they deserve top-levelness.. 9. PKCS#10 support In X-BULK we had legacy PKCS#10 support. There is an argument that an X-BULK client (back when we had X-BULK) could have taken the PKCS#10 request from the legacy device, validated it, and then converted it to an unsigned pure XML request within the X-BULK batch request. The responder could then get by without PoP by virtue of trusting the X-BULK client. However, I still think that PKCS#10 support is useful in XKMS because there is no trusted intermediary between one-by-one legacy clients and the XKMS responder who can do this type of trusted conversion. In these situations, PKCS#10 is the only PoP mechanism possible without forcing legacy hardware devices to perform two signing operations; one on the PKCS#10 that they produce, and then one on an application-level conversion of that to XML. I'm not so sure that all hardware will be willing to do this second signature prior to receiving their certificate. merlin
Received on Wednesday, 27 November 2002 13:56:18 UTC