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

Reply via email to