[Openid-specs-ab] [Bitbucket] Issue #851: Messages 2.1.2.1 - Clarify that "none" is not an acceptable signature algorithm (openid/connect)

[Brian Campbell]

On Tue, Jun 25, 2013 at 10:07 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  It’s a breaking change because clients currently conforming to Messages
> that always verify the ID Token signature would break if no signature is
> contained in the ID Token.****
>
> **
>

And any such client would already be registered or configured for one of
the other algorithms and wouldn't receive a token with the "none"
algorithm. That breaking change situation wouldn't occur.



> **
>
> “none” is not a signature algorithm.  JWS and JWA are clear that this
> results in an unsigned, “plaintext JWS”, and JWT is clear that this results
> in a “plaintext JWT” – not a signed JWT.  Messages requires that ID Tokens
> be signed.  Sending an unsigned ID Token doesn’t fulfill this requirement.
> ****
>
>
>
**
>
> This bug is about making the current meaning of the text – that ID Tokens
> must be signed – even more clear, so that developers who aren’t reading JWS
> closely won’t make the mistake of thinking that just because “none” can be
> used to create a JWS, that the resulting JWS is signed.  (Apparently you
> were one such developer – making the need for this clarification all the
> more evident. J)****
>
>
>

I guess we agree that it's not at all clear as it currently written. Yes
"none" is different than the other algorithms but I'd say that line of
reasoning is a slippery slope.  Messages 2.1.2.1., for example, says that
the ID Token must be signed thereby providing non-repudiation, "ID Tokens
MUST be signed using JWS [JWS] and OPTIONALLY both signed and then
encrypted using JWS [JWS] and JWE [JWE] respectively, thereby providing
authentication, integrity, non-repudiation, and optionally,
confidentiality, per Section 9.13."  But the HMAC algorithms aren't
signature algorithms either and certainly don't provide non-repudiation. So
they shouldn't be acceptable algorithms either, right?

I realize it's probably futile to argue but what I'm saying is that it is a
reasonable thing to use "none" when the token is sent only via the TLS
protected back-channel. And given that I'm "one such developer," I've now
got publicly released software that does allow "none" in that situation
where it does make sense.



 ** **
>
> *From:* Brian Campbell [mailto:issues-reply at bitbucket.org]
> *Sent:* Tuesday, June 25, 2013 7:58 AM
> *To:* Mike Jones
> *Subject:* Re: [Bitbucket] Issue #851: Messages 2.1.2.1 - Clarify that
> "none" is not an acceptable signature algorithm (openid/connect)****
>
> ** **
>
> [image: b_d_c]****
>
> *Brian Campbell* commented on issue #851: ****
>
> *Messages 2.1.2.1 - Clarify that "none" is not an acceptable signature
> algorithm<https://bitbucket.org/openid/connect/issue/851/messages-2121-clarify-that-none-is-not-an>
> *
>
> I disagree. ****
>
> How would that be a breaking change? If a client is currently
> configured/registered for RS/EC/HS signature, how would allowing none as a
> different option be a breaking change? ****
>
> Our implementation currently does allow none as an option (it will only
> send such an ID Token via the back-channel). Which is, I'll argue, a
> perfectly reasonable interpretation of what's been written. So explicitly
> disallowing it is a breaking for us. ****
>
> View this issue<https://bitbucket.org/openid/connect/issue/851/messages-2121-clarify-that-none-is-not-an>or add a comment by replying to this email.
> ****
>
> Unwatch this issue<https://bitbucket.org/openid/connect/issue/851/unwatch/mbj/f843d56eb7066d599d3972aaab0b00d200d1d4b4/>to stop receiving email updates.
> ****
>
> [image: Bitbucket] <https://bitbucket.org>****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130626/7c1dc725/attachment.html>