As for “ECDH-SS rfc6278 (being) easier for implementers to get wrong than
ECDH-ES” the good news about crypto is that if you get it even a little bit
wrong, it doesn’t work with other’s implementations at all, so this situation
tends to be self-correcting.
Cheers,
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:02 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens
They provide integrity protection for the encryption, that is very important
for preventing padding oracle attacks.
AES
GCM<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7518%23section-5.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Km4lrYHuFSmIvYONtiusFoZEtSRoAj4Ri8udIoiA5Nk%3d>
and
AES_CBC_HMAC_SHA2<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7518%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IaQ9hYN4Lw5bVTXRcSwNi4RzKnojIKAAIdtf53JDBvE%3d>
are both examples of Authenticated
Encryption<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedia.org%2fwiki%2fAuthenticated_encryption&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eRV5xgf17IWyz0j5QwgDmubDw5rqJneMaYtCHu1CLVs%3d>
in the sense that the received encryption is true and not that the sender is
identified.
English speakers have a hard time with the subtle difference between
identification and authentication , so I wanted to be clear.
That being said there is a special case where if the JWT ie encrypted with a
symmetric key known only to two parties and it is “authenticated” and you
didn’t create it, then by a process of elimination it cold have only come from
one party. This is NOT a signature, however it is a useful trick that some
people use to only encrypt and while still knowing with relative certainty who
encrypted it.
I should note that ECDH-SS rfc6278 a key agreement algorithm we didn’t put in
the base JWA spec also has the property of providing encryption and
authenticity based on the public keys of both sender and receiver.
(note this is easier for implementers to get wrong than ECDH-ES but that is
another debate:)
Probably more than you wanted to know, but Nat started it:)
John B.
On Jul 17, 2015, at 2:09 PM, Brian Campbell
<[email protected]<mailto:[email protected]>> wrote:
Though you want to be careful with that as the asymmetric algs in JWE don't
provide authentication of the sender.
On Thu, Jul 16, 2015 at 11:26 PM, Nat Sakimura
<[email protected]<mailto:[email protected]>> wrote:
Hi Malla,
Just to add one more thing:
If you just want to “sign” for the sake of integrity protection, you really do
not need to do it as all the algs in JWE are integrity protected.
--
Nat Sakimura <[email protected]<mailto:[email protected]>>
Nomura Research Institute, Ltd.
PLEASE READ:
The information contained in this e-mail is confidential and intended for the
named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified
that any review, dissemination, distribution or duplication of this message is
strictly prohibited. If you have received this message in error, please notify
the sender immediately and delete your copy from your system.
From: OAuth [mailto:[email protected]<mailto:[email protected]>] On
Behalf Of John Bradley
Sent: Friday, July 17, 2015 7:45 AM
To: Malla Simhachalam
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Nesting Signatures and Encryption JWT Tokens
https://tools.ietf.org/html/rfc7519#section-11.2<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-11.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bJjUa9H%2fhsoQGfjmZEBQIyYxwZNc5Hlt%2bDzrEj%2bHG70%3d>
It is in the JWT spec. You can do it both ways however you really need a good
reason not to sign then encrypt, and then after you have a good reason you
should still sign then encrypt because you probably have not considered
everything,
There are probably some edge cases that are exceptions to the rule, but they
are rare.
John B.
On Jul 16, 2015, at 11:33 PM, Malla Simhachalam
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I am looking at the spec
https://datatracker.ietf.org/doc/rfc7520/?include_text=1<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2frfc7520%2f%3finclude_text%3d1&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9X3auySnL4XlT%2fRW%2bAOaBG5wX8jrNc82AZ0Go%2bZIruM%3d>
for combining JWS and JWE use case, I could not find it obvious that a JSON
document should be signed first and then encrypt or other way around.Are there
any recommendations one over the other?
Thanks for help.
Malla
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldOnSanQEP6YOoHdd36Ur6bWEnQga%2fINlTLAx4BOEes%3d>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7cMichael.Jones%40microsoft.com%7c5bc9eda0e8da494e11bb08d28eb0519f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ldOnSanQEP6YOoHdd36Ur6bWEnQga%2fINlTLAx4BOEes%3d>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
