Re: testing error cases

Yunhao,

I still think we have to be careful here not to end up testing
every x.509 failure mode, so in your list below I'd change to:

3: Handling error response(s) to a revocation request
4: Handling error response(s) to a registration request
5: Unacceptable signature

Sorry to go on about this, but there is a rats-nest awaiting
us if we not careful!

Stephen.

Yunhao Zhang wrote:
> Joe,
> 
> Yes. I agree with you. We should test error scenarios, especially in XKRSS.
> Cases may be considered include,
> 
> 1. Requesting with bad secret.
> 2. Recovering a client generated key.
> 3. Revoking an invalid, or nonexistent,  key.
> 4. Registering a key with unknown identity.
> 5. Invalid signature or signed by an untrusted certificate.
> 
> 
> Our client can be twisted to support the cases easily.
> 
> Regards,
> 
> Yunhao
> 
> 
> 
> ----- Original Message ----- 
> From: "Jose Kahan" <jose.kahan@w3.org>
> To: <www-xkms@w3.org>
> Sent: Tuesday, October 19, 2004 12:07 PM
> Subject: testing error cases
> 
> 
> 
>>Hi!
>>
>>As part of the test suite, we should try to test not only the succesful
>>behaviour, but the errors too.
>>
>>For example, what happens when you revoke a certificate that doesn't
>>exist, what happens when you use the wrong shared secret, what happens
>>when you use the status request and you don't get a sucess reply...
>>
>>Guillermo pointed out to me today that it may be difficult to do those
>>tests, as in some cases the clients or the servers need to be able to send
>>wrong messages. What we want to test in these cases is what happens
>>when either the client or server receive an invalid message.
>>
>>It seems that the SOAP people used fake clients or servers to test
>>the error cases. I have no idea how flexible are the current
>>implementations.
>>
>>Any ideas on how to proceed here are welcome.
>>
>>-jose
>>
>>
> 
> 
> 
>

Received on Wednesday, 20 October 2004 08:11:31 UTC