For what it's worth, the HMAC and signature output representations to use *are*
explicitly specified in the JWS and JWT specs (which is necessary to achieve
interoperability).
-- Mike
-----Original Message-----
From: Stephen Farrell [mailto:[email protected]]
Sent: Thursday, June 16, 2011 11:43 AM
To: Mike Jones
Cc: Joe Hildebrand; Tschofenig, Hannes (NSN - FI/Espoo); extManger, James H;
Sean Turner; [email protected]; [email protected]
Subject: Re: [woes] WOES Charter Proposal
On 16 Jun 2011, at 19:14, Mike Jones <[email protected]> wrote:
> About (3), you sign and encrypt things with keys. The header/envelope often
> references the key, which must have a known representation. In a JSON-based
> world, it's often simpler to represent public keys as JSON rather than ASN.1
> (for the same reasons that we're considering JSON signatures and encryption
> when we already have CMS). It's not creep - it's providing a complete
> JSON-based signing/encryption solution.
And you need algorithm ids and parameters and a way to represent hmac outputs
etc but those are not called out specifically which makes (3) look like a
slippery slope.
>
> I personal agree that (4) schemas is creep, but I support Joe's desire to
> have it considered as an input document.
I'm thinking in charter terms, this is the first I think I've heard of non
crypto work being proposed here (sorry if I missed that).
Simpler, more tightly scoped, charters seem to get approved easier,
Cheers
S
>
> -- Mike
>
> -----Original Message-----
> From: Stephen Farrell [mailto:[email protected]]
> Sent: Thursday, June 16, 2011 10:52 AM
> To: Joe Hildebrand
> Cc: Mike Jones; Tschofenig, Hannes (NSN - FI/Espoo); ext Manger, James H;
> Sean Turner; [email protected]; [email protected]
> Subject: Re: [woes] WOES Charter Proposal
>
>
> 3 & 4 there look a bit like scope-creep to me
>
> Why are they absolutely needed?
>
> S.
>
> On 16/06/11 18:33, Joe Hildebrand wrote:
>> Slight tweaks
>>
>>
>> On 6/16/11 11:26 AM, "Mike Jones" <[email protected]> wrote:
>>
>>> 1) A JSON-based method of applying digital signatures and keyed
>>> message digests to data that may represent JSON data structures.
>>
>> ... may represent arbitrary data, including JSON data structures and
>> text
>>
>>> 2) A JSON-based method of applying encryption to data that may
>>> represent JSON data structures.
>>
>> Same as 1) above. Not just for JSON.
>>
>>> Separately, we may want to consider whether the following should be in
>>> scope:
>>>
>>> 3) A JSON-based method of representing public keys.
>>>
>>> Also, please update and/or add these references (some were out of
>>> date, some were missing):
>>
>> Let's also add:
>>
>> 4) Any JSON-specific prerequisite tooling such as JSON Schema
>>
>> And add draft-zyp-json-schema as a reference. I CC'd Kris Zyp to see
>> if he's ok with that. Kris: this might be a chance for a WG to pick
>> up JSON Schema if you like.
>>
>
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
