W3C home > Mailing lists > Public > www-xkms@w3.org > December 2002

FW: Suggested changes to XKMS 2.0 Spec

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 18 Dec 2002 09:25:28 -0800
Message-ID: <CE541259607DE94CA2A23816FB49F4A3953C1D@vhqpostal6.verisign.com>
To: "Www-Xkms (E-mail)" <www-xkms@w3.org>
I received these comments from Loren Hart who maintains the VeriSign
code. If there are no objections I will roll them in as they appear to
be editorial comments.


From: Hart, Loren L. 
Sent: Friday, December 13, 2002 1:24 PM
To: Hallam-Baker, Phillip
Subject: Suggested changes to XKMS 2.0 Spec


The following suggested changes to the XKMS 2.0 (Part 1) are made based
on
my reading of the Editors Copy dated 2002-10-17.


2.4	Support Requirements

    Does it make sense for to require that client implementations
    MUST support synchronous compound XKMS requests when services
    only MAY support them?
    I would suggest that clients at most SHOULD support these requests. 

2.8.3	<OpaqueClientData/>

    First the schema presented is not legal, and does not make sense.
    Second neither of them should be minOccurs="0" since if there is an
    <OpaqueClientData/> there should be at least one <OpaqueData/>
element.

2.8.7	<PendingNotification/>

    The Table column heading is currently "URI" and should be
"Mechanism"

    Also a clarification about urn:ietf:rfc:2616 should this be the
complete and
    exact URL that the XKSM server should perform a get on?
    Should there be a retry if there is an HTTP error code?
    Should redirects be followed?

5.1.1 <RegisterRequest/>	(both examples)

    The following Element:
       <UseKeyWith Application="urn:ietf:rfc:2459"
       Identifier="C=&quot;US&quot; O=&quot;Alice Corp&quot;
CN=&quot;Alice Aardvark&quot;" />

    Should look like the following: 
       <UseKeyWith Application="urn:ietf:rfc:2459"
		   Identifier="C=US, O=Alice Corp, CN=Alice Aardvark"/>

5.2 <ReissueRequest/>

    This section needs some clarification.
    Why reissue a credential? 
    Is this request like renew to get a new validity interval?
    Is Reissue for something else?

4.1.13 <RevocationCode>
4.1.14 <RevocationCodeIdentifier> 
7.1 MAC

    There are two problems here:

    1) Nowhere does this specification say which MAC to use, nor is
       there anywhere in the schema to indicate which MAC is being used.
       Our XKMS 1.0 implementation currently uses HMAC/SHA-1.

    2) Nowhere does this specification indicate the size of the MAC key
       values listed in section 7.1.   
       Our XKMS 1.0 implementation currently uses one byte Keys.


Received on Wednesday, 18 December 2002 12:25:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:40 UTC