Ted Lemon has entered the following ballot position for
draft-ietf-oauth-assertions-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Ted Lemon has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http
On Oct 14, 2014, at 7:53 AM, Mike Jones wrote:
> The proposed resolution below has been applied to the -28 draft.
Thanks!
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
On Oct 7, 2014, at 9:06 PM, Mike Jones wrote:
> I'll plan to take the action described yesterday that you said you were OK
> with - adding language about "If both signing and encryption are necessary"
> in order to make the context of this advice clear. I believe that that will
> improve the u
On Oct 7, 2014, at 1:14 PM, John Bradley wrote:
> Encrypting and then signing is likely only a special case used by some
> applications that are configured to understand what is going on.
This isn't really responsive to what I said. As I said, I'm just asking you
to be consistent, not to cha
On Oct 7, 2014, at 10:57 AM, John Bradley wrote:
> The main reason for signing inside the encryption, tends to be legal in that
> a signature over something you can't see is not considered enforceable most
> places.
> So if you are signing for non repudiation then inside the encryption is
> typ
On Oct 7, 2014, at 1:29 AM, Mike Jones wrote:
> I propose that we add language about "If both signing and encryption are
> necessary" in order to make the context of this advice clear. Would that
> resolution be acceptable to you, Ted?
So you're saying that if signing and encryption are necess
On Oct 6, 2014, at 3:54 AM, Mike Jones wrote:
> Sometimes authenticated encryption alone is good enough without requiring a
> signature. Different applications will have different requirements. So
> while this section discussion the applicable considerations, the working
> group felt that it
