John Merrells <[EMAIL PROTECTED]> writes: > On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote: > >> Method of ticket validation >> This draft validates the ticket by having the Membersite send a digest >> to the Homesite and get an ACK. It's not clear why this is desirable. >> Wouldn't it be simpler to have the Homesite digitally sign the ticket >> (the key could be delivered in the initial capabilities discovery >> phase) and then let the Membersite do the verification directly? >> I appreciate that there's a freshness concern, but this can >> be alleviated using the usual nonce-based anti-replay techniques. > > The motivation wasn't freshness. The dix:/message-id parameter > is a nonce that takes care of this. > > The motivation was to get all the binary crypto code out of the MS to > ease adoption. We learnt from our prior experience with the SXIP > protocol that this was a barrier to adoption. Writing good DSIG code > for all platforms/stacks/languages is tedious and expensive and worse > increases the number of lines of code that a MS developer has to > write to enable a site. [SXIP 1.0 worked this way.]
What do you mean "binary crypto code"? You've got a hash algorithm, no? At worst, you could share a pairwise secret between the MS and the HS during the initial discovery phase and use that to key a MAC. (This is of course only safe if you're doing that exchange over SSL/TLS, but that's true of your scheme too...) Anyway, I don't really find this that convincing. Java certainly comes with built-in public key functionality and there are modules for Python, Perl and PHP (it's actually a compilation flag for PHP). Yes, it's not zero effort, but it's not exactly prohibitive either. -Ekr _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
