Re: Revised Test Cases

I don't think we've anyone who's only doing xkrss so this is
a bit academic. However, I'm happy so long as the tests have
sufficient coverage and there's no block to iterating them
without manual server-side messing.

For revocation, we cannot make it a requirement to produce an
X.509 artefact. The simplest thing here *is* to require an
xkiss request - but note that that doesn't have to have come
from the same client! I.e. for testing xkrss messages, we
can require use of xkiss messaging, but we don't require
the same client to do both! So as soon as we have a usable,
freely available xkiss client, then we can allow for its use
in xkrss testing, if required.

Stephen.

Tommy Lindberg wrote:
> Hi Yunhao -
> 
> 
>>I don't see how the tests could exclude implementors from inplementing only
>>XKRSS. ...
> 
> 
> My understanding from the additional tests was the new XKISS messages
> would be used to verify that key bindings were affected in the desired
> way after an XKRSS operation.  Whether they were individual XKISS
> testcases or part of an XKRSS testcase, this approach creates a
> dependency on XKISS.
> 
> So, it doesn't prevent the implemention of XKRSS - but it does seem to
> get in the way of testing XKRSS as the implementor wouldn't have the
> XKISS functionality required to execute the test.
> 
> I wagely recall someone indicating only implementing a subset of XKRSS
> - I was only sensitive to this.  Personally, I couldn't give a toss :)
> 
> 
>>The question is, do we allow people to test only registration without
>>verifying state change?
> 
> 
> Yes I think so. Register, like Reissue and Recover, returns some
> artifact that can form the basis for determining whether the operation
> succeeded or failed; provided of course that all service implementers
> agreed upon returning that artifact.
> 
> Revoke may require a bit more; if we agreed, a service could produce a
> CRL in the result on which the revoked key resided. This is X509'ish
> but so are the current XKISS tests.
> 
> Regards
> Tommy
> 
> On Wed, 13 Oct 2004 09:19:18 -0400, Yunhao Zhang <yzhang@sqldata.com> wrote:
> 
>>Hi Tommy
>>
>>
>>>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.
>>>
>>
>>I don't see how the tests could exclude implementors from inplementing only
>>XKRSS. We already have a long list of KRISS tests and it doesn't preclude
>>people from implementing only part of XKISS or even part of a client to
>>participate in the test. Remember that the test cases can be exercised
>>individually, and untested cases can be marked as 4 in the report.
>>
>>
>>>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)
>>>
>>
>>Then the case can only be used by ones who implement both XKISS and XKRSS.
>>The question is, do we allow people to test only registration without
>>verifying state change?
>>
>>
>>>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.
>>>
>>
>>Using the same shared secret is to facilitate automated testing where all
>>the test cases are conducted in sequential order. We can certainly make it a
>>parameter so that it can be entered before testing.
>>
>>As for more test cases, we can definitely add when needed.
>>
>>Regards,
>>
>>Yunhao
>>
>>
> 
>

Received on Thursday, 14 October 2004 10:01:08 UTC