Re: Revised Test Cases

Hi Tommy, Yunhao, all,

I had just updated the test collection site [1] with Yunhao's draft but
I would be happy to do the necessary changes before we actually begin to
exercise those. 

I agree with the approach of grouping messages together in the same
scenario (example: validate+register+validate). Regarding the "missing
tests" (as other revocation options) I think they can always be added
later on. About the shared secrets/passphrases I agree with you that we
wouldn't have to define the same secret for everyone.

Cheers,
 - -Guillermo

[1]
http://www.w3.org/2001/XKMS/Drafts/test-suite/CR-XKMS-test-suite.html#testcollection

El mié, 13-10-2004 a las 12:00, Tommy Lindberg escribió:

> Hi Yunhao -
> 
> Here are some comments and suggestions that came to mind up front:
> 
> 1)
> While I am personally OK with the approach, using XKISS messages to 
> verify that XKRSS operations have produced the expected results may
> exclude implementors that only intend implementing XKRSS, or portions
> thereof, from executing some tests.
> 
> 2)
> Assuming that XKISS messages are used to verify expected results of XKRSS
> requests, it may be more meaningful to incorporate the XKISS messages in the
> actual XKRSS test case as opposed to having them separately, using T101 as
> an example:
> 
>   - verify that binding-to-be-registered does not exist (Validate/Locate)
>   - attempt registration
>   - verify that binding-to-be-registered does exist (Validate/Locate)
> 
> 3)
> I suggest we use Identifier's and DN's that identify the entity acting as a
> client. This will make it easier to do partial purges and will also keep the
> result messages smaller.
> 
> 4)
> I am not in favor of using the same shared secret for everyone.  Not only is
> it not realistic, but it also allows for accidental inteference
> between individual
> testers.
> 
> 5)
> I'd like to see a way to identify the shared secret used in an HMAC signature. I
> propose using a KeyInfo.KeyName in the enclosing Signature element.
> 
> 6)
> There's no need to require a certain passphrase in a revocation
> operation based on a
> revocation code.  The client can choose this at his own discretion.  I'd like to
> see this disappear from T106 to avoid interference.
> 
> 7)
> T106 uses revocation by revocation code; I'd like to see the other two
> options exercised too
> 
>   - revoke by HMAC signature
>   - revoke by private key signature
> 
> 8)
> Shouldn't we mandate checking the optional ProofOfPosession in T101? And T104?
> 
> 9)
> How about registering/reissuing a DSA key?
> 
> 10)
> While not strictly required we might want to state the symmetric
> algorithm used in T103
> and T105.  Personally I (claim to) support all symmetric algorithms
> mentioned in the XML
> Encryption standard.
> 
> Regards
> Tommy
> 
> 
> 
> 
> On Tue, 12 Oct 2004 17:45:22 -0400, Yunhao Zhang <yzhang@sqldata.com> wrote:
> >  
> >   
> > Sorry I missed today's call. 
> >   
> > Attached is a set of revised test cases for XKRSS. As Stephen suggested, I
> > added several Validate tests to verify state changes. Comments or
> > suggestions are welcome. 
> >   
> > Regards, 
> >   
> > Yunhao 
> >   
> >
>