If I may summarize the call: -- There was agreement that we should define a "header + data" format, with no cryptographic protection
-- There was disagreement on whether that unprotected format should be part of JWS, or something separate. Two options were proposed: 1. Use JWS, but require that implementations MUST NOT accept "none" unless explicitly directed to by an application 2. Define a new format, distinct from JWS, that just has header and payload (no signature). In the compact format, this would just have two dot-separated components. -- It was observed that either one of these options causes work for existing implementations. Option 1 causes them to expose API surface that may not be there now (to specify acceptable algorithms). Option 2 requires a change to parsing. On Tue, Aug 20, 2013 at 10:09 AM, George Fletcher <[email protected]> wrote: > > On 8/20/13 9:49 AM, Justin Richer wrote: > > > On 08/19/2013 05:46 PM, Richard Barnes wrote: > > > [snip] > > It's important that something that is not signed is does not pass JWS > validation. If something unsigned is ever accepted as a valid JWS, then > there's a huge downgrade risk. > > > I think that's a red herring. It's the same downgrade risk if someone > sends alg:rot13 and your app doesn't want to accept that "signature" > either. A JWS with alg:none should pass *only* if the signature field is > empty, full stop. > > -- Justin > > > +1 > > And to take it even a bit further. There will come a time in the future > when HS256 is deemed to be insecure and SHOULD NOT be used because it's > been hacked/compromised. At that point in time, all the implementations > will have to have a way to not allow alg:256. Hence there could be no > security difference between alg:hs256 and alg:none at some point in the > future. > > I realize I missed the call last night so maybe this is all mute:) > > Thanks, > George >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
