- From: Ned Freed <NED@innosoft.com>
- Date: Wed, 21 Feb 1996 16:56:14 -0800 (PST)
- To: Paul Leach <paulle@microsoft.com>
- Cc: dmk@allegra.att.com, ned@innosoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> ] For the material you've selected to work it should be used as the nonce > ] value. This is included in the digest and will have the effect you're trying > ] to achieve. > The draft also says that the nonce is a "server specified integer > value". (It _doesn't_ say if it's *HEX or *DIGIT...) Interesting point. The nonce is described as an integer but is used as an opaque string. This really needs to be clarified. > If it included all > the material Dave uses, it would be a pretty big integer, and clients > probably wouldn't know how to increment it. It would only be a hash of all that stuff. But even so, it will probably be pretty long... In any case, since the specification doesn't talk about incrementing the nonce anywhere (at least not that I can find) I don't see how having a long nonce value would break anything. I did mention the concept of incrementing the nonce myself, but only in passing. > Changing the spec to say it's *HEX, and that the last 32 bits is the > part that clients must increment each time they return it in a request, > would enable the implementation of your suggestions. I don't think it is necessary that this be done, but I agree that this should be clarified. > The draft also isn't very specific about what "<message-body>" > includes. Does it mean entity-body, or does it include the headers as > well? The latter is preferable. I haven't considered the case where digests are used to authenticate returned content, but you're right, this also needs to be tightened up. Ned
Received on Wednesday, 21 February 1996 17:05:50 UTC