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

[John Bradley]

Registration id_token_signed_response_alg already precludes the use of none as a option and sets the default to RS256. 

To allow none we would need to change that otherwise the AS doesn't know if the client is expecting RS256 for some non repudiation reason. 

The reason a client might want none is mostly size.  A RS256 signature likely more than doubles the size of a normal id_token. 
Also if you wanted a very simple lightweight IdP that only supported the code flow it might make sense.

As it stands now Mike is correct that none should not be considered valid. If we want to change that it requires changing registration at least.

John B.


On 2013-06-26, at 7:10 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> What do others think?  I understand what Brian is saying but I’m not sure that we want to give OPs permission to ever not sign ID Tokens.
>  
> The choices before us seem to be:
> 1.  Clarify that “none” is never an acceptable “alg” value.
> 2.  Change the specs to say that “none” may be supported by some OPs and limiting the circumstances under which they may do so.
> 3.  Change the specs to say that OPs are required to support “none” under specific circumstances.
>  
> I think I could personally live with either 1 or 2 and prefer 1.  I don’t think I can agree for us to do 3.
>  
> I think that 1 is the most straightforward thing to do and doesn’t impose any significant implementation burden.  Remember that as a design philosophy, we’re consciously moving complexity away from clients and pushing it to servers, when such tradeoffs arise.  This seems like such a case.  By requiring that OPs always sign the ID tokens they issue, Clients can always decide to check the signature.  They don’t have to deal with the case where they might not be able to check a signature because none is present.  And it’s really not hard for the server to just sign it.  So I don’t see any practical value in not signing the token.
>  
> But again, it would be good to hear from a lot of other people on this issue.
>  
>                                                                 -- Mike
>  
> From: Brian Campbell [mailto:bcampbell at pingidentity.com] 
> Sent: Wednesday, June 26, 2013 2:47 PM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Bitbucket] Issue #851: Messages 2.1.2.1 - Clarify that "none" is not an acceptable signature algorithm (openid/connect)
>  
>  
>  
> 
> 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)
>  
> 
> Brian Campbell commented on issue #851:
> Messages 2.1.2.1 - Clarify that "none" is not an acceptable signature algorithm
> 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 or add a comment by replying to this email.
> Unwatch this issue to stop receiving email updates.
> 
>  
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130626/754b97a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130626/754b97a2/attachment.p7s>