There are attacks that we have seen in the past that are possible if the attacker can predict the header and control what is signed in the body.
Perhaps nonce is not the best name for it. People seem to have kept to the conclusion that it is used to maintain session state between parties. I raised it as a standard place to add per message entropy, as JOSE doesn't control the content of the body. I was not saying that it is required, it is not in cases where the signer is producing the body without external input. It is intended as a optional claim who's value may not be processed by the receiver at all. Some applications might code something into the nonce, or use it to prevent replay, that was however not my primary intent. John B. On 2012-08-27, at 5:02 PM, Anthony Nadalin <[email protected]> wrote: > Depends on what the nonce is used for as if this is for key entropy then I > would say there is very little overhead and storage issues and in this case I > would expect the header to contain the nonce, if it’s for state of some sort > then I would expect it at the application level and not as a header and more > of a JWT claim. > > From: [email protected] [mailto:[email protected]] On Behalf Of Brian > Eaton > Sent: Monday, August 27, 2012 1:06 PM > To: Dick Hardt > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <[email protected]> wrote: > I have an application for JWT that is not OAuth2. > > Should nonce and timestamp logic go in the application level protocol? > > Having said that, nonce's are difficult to implement at scale and I have > heard of many sites that don't implement them fully. > > Nonce alone can't be implemented efficiently. You have to have time stamps > as well, otherwise you are stuck storing ever nonce you've ever seen, forever. > > Even nonce + time stamp is challenging in distributed systems. It adds a lot > of complexity. That complexity is sometimes merited, but not always. > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
