On 8/5/11 3:04 PM, Phillip Hallam-Baker wrote:
Actually, I suspect that with AES in hand and having good MAC modes
specified we might well want to use one of those in preference to the
traditional HMAC.
On Fri, Aug 5, 2011 at 2:45 PM, Sean Turner <[email protected]
<mailto:[email protected]>> wrote:
On 8/4/11 4:41 PM, Hal Lockhart wrote:
+1
-----Original Message-----
From: Paul Hoffman [mailto:[email protected]
<mailto:[email protected]>]
Sent: Thursday, August 04, 2011 12:03 PM
To: Eric Rescorla
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [woes] Proposed charter, post-Quebec edition
On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
IMO, symmetric integrity protection is a useful
primitive, and it's
already part of the
JWT spec. I think all that's required here in the
charter is to
wordsmith it to separate
out symmetric from asymmetric integrity algorithms,
Current:
1) A Standards Track document specifying how to apply a
JSON-structured digital signature to data, including (but not
limited to) JSON data structures. "Digital signature" is
defined as a hash operation followed by a signature operation
using asymmetric keys.
It sounds like you would prefer something like:
1) A Standards Track document specifying how to apply
integrity protection to data, including (but not limited to)
JSON data structures. This integrity protection can be
achieved with both symmetric and asymmetric algorithms.
Is that right?
I'm liking what Paul B. suggested but tweaked ever so slightly:
1) A Standards Track document specifying how to ensure the integrity
and/or authenticity of data, including (but not limited to) JSON
data structures. HMAC-based (RFC 2104) and Asymmetric cryptographic
algorithms both need to be supported.
I'd like to not just call out integrity - and we should just call
out the HMAC-based algs because that's what folks really want to use
(or have I gotten this wrong?).
Any violent objections to this?
Right after I sent this I remembered AES-CMAC. Precise enough to say:
MAC-based (e.g., HMAC-SHA256, AES-CMAC) and Asymmetric cryptographic
algorithms both need to be supported.
spt
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
