Re: Test about "use of limited-use shared secret data"

Test case XKRSS-T2 uses the algorithm specified in Section 8.1.  The
point of my argument is that if the algorithm, given a string,
generates a certain sequence of bytes, then inserting arbitrary space
and changing the case of characters in that same string should,
according to the algorithm, produce the same sequence of bytes.  If
that doesn't happen there is no need to go to interop.  This is a
useful unit test, in my opinion, not a meaningful interop test.

I understand the potential usefulness of not using the algorithm in
Section 8.1, i.e. by importing some key material from somewhere and
using this as is, however, this test case is not intended to exercise
that scenario.

Regards,
Tommy


On Mon, 06 Dec 2004 09:51:00 +0000, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> 
> I'd be for including this test on the basis that string2key
> functions always generate bugs whenever there's a string2string
> bit first.
> 
> This can however, be tested, for w3c purposes, by validating that
> two client implementations do the same thing for a range of
> input strings (btw, I'd like to see more xml-frigging in the set
> of test cases), so server implementers needn't worry.
> 
> I can see why server implementations might not include this step
> if they always generate the shared secret values where the input
> and output of the function will be the same, however, any
> commercial server will have to live in a world where those
> values can be imported (e.g. from a pre-existing password DB), and
> so there will be two vendors' code involved (the client code
> at runtime and the server code at DB-import time). If I were
> someone thinking of using xkms, I'd be happier to see that my
> server had passed such a test (but as stated above, that's
> irrelevant for w3c progression).
> 
> Lastly, I can't see how the "plenty of material" argument applies,
> other than to make it easier to develop and successfully execute
> such a test.
> 
> Stephen.
> 
> 
> 
> Tommy Lindberg wrote:
> 
> > The reason I have this opinion is that we have vectors for the limited
> > use shared secret key material derivations in the spec as well as
> > sample messages that include signatures/macs computed with keys
> > derived in the same way, an implementor has plenty of material
> > available to test his/her implementation without involving another
> > party.
> >
> > Regards,
> > Tommy
> >
> >
> > On Fri, 03 Dec 2004 18:09:40 +0000, Guillermo Álvaro Rey
> > <alvarorg@cs.tcd.ie> wrote:
> >
> >> Hi all,
> >>
> >> While designing tests for the test collection we couldn't agree on if the
> >>following test (or something similar) should be included or not:
> >>
> >> (Similar to XKRSS-T2 but with shared secrets equivalent to "secret") A
> >>client wishes to register five keys generated by the XKMS server (Key Names:
> >>TestKey[1-5]). He sends registration requests to the XKMS service provider
> >>using the following shared secrets: "SECRET", "sec ret", " sEC r E  t ",
> >>"SeCrE      t" and "s ECr ET  ", for key binding authentication. The shared
> >>secrets associated to the keys in the service side will be the same used by
> >>the client, without an explicit order as all of them will transform to
> >>"secret". The processing mode is synchronous, and the keys are to be used
> >>with an email address. The XKMS server returns an RSA key pair with
> >>encrypted private key for every registration operation. The resulting set of
> >>messages will consist of ten messages: five Register request/response pairs.
> >>
> >> The idea would be to check if the string conversion rules included in the
> >>"use of limited-use shared secret data" section would guarantee
> >>interoperability. On the other hand, Tommy suggested that this kind of test
> >>is not an interoperability issue as the execution of the algorithm involves
> >>only one entity.
> >>
> >> Does anyone have an opinion on this? :)
> >>
> >> Cheers,
> >> - -Guillermo
> >>
> >>
> >
> >
>

Received on Monday, 6 December 2004 10:27:04 UTC