changelog #3

 
 Response to Merlin's comments 




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>

 
Done - this was actually awhat the text said already.


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>

Done

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"

There was a problem with the use of any, but now we nuked any this is no
longer an issue

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>

Lests make this an ISSUE

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>


Changed in response to slava's comments


6. TimeInstant

    Suggest that the Time attribute be nonoptional.

Done

7. PassPhraseAuthentication

    Is an orphan.

Done

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

I would prefer the consistency of them being top level. I don't much
like the unnecessary distinction introduced by schema.


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


OK create an issue, the point outstanding here was I believe someone
arguing the case.