Yes that is an issue. I think one of the things that kicked this off was a question of will this make it pointless for people to use algs such as AES GCM256 when it is perceived that our choice of hash somehow limits overall security to 128bits.
Let me take another run at this. Things like block cyphers need to have long term secrecy. An attacker may still get value from decrypting something years down the road. Things like signatures typically need to have some non repudiation property that lasts the useful lifetime of the document. That can be years or minutes depending on the document. In our case we are providing out of band integrity protection for the cert. We could include the cert directly but it is allready being sent as part of TLS. In general the lifetime of the key pair used for access tokens will be less than the lifetime of the certificate, so it is hard to argue that we need stronger security than the cert itself. We have a way to rotate keys/certs daily if desired with JWKS and it can support self signed certificates. The security of this is still limited by the security of the TLS cert for the JWKS endpoint, but that is relatively easy to update if there is a need, and alternate certificate chains become available with security better than SHA256. However currently most if not all CAB forum roots are using SHA256 hashes with RSA2048 keys (some like RSA still have roots using RSA 1028bit keys) I am normally the paranoid one in the crowd, but I would rather pick off some of the other issues that are more likely to go wrong first. We can point out extensibility for future use, but I am not buying us defining a new thumbprint when the one we have is as strong or stronger than the other parts of the trust chain. I can see people choosing to use SHA512 having larger messages more processing as a way to avoid certificate rollover and that would be a bad tradeoff. John B. > On Apr 30, 2018, at 6:19 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > > > On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > > > On 30 Apr 2018, at 15:07, John Bradley <ve7...@ve7jtb.com > > <mailto:ve7...@ve7jtb.com>> wrote: > > > My concern is that people will see a bigger number and decide it is better > > if we define it in the spec. > > We may be getting people to do additional work and increasing token size > > without a good reason by putting it in the spec directly. > > I’m not sure why this is a concern. As previously pointed out, SHA-512 is > often *faster* than SHA-256, and an extra 32 bytes doesn’t seem worth > worrying about. > > Seems like maybe it's worth noting that with JWT, where size can be a > legitimate constraint, those extra bytes end up being base64 encoded twice. > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
