Re: [woes] New WOES charter proposal

[Dave CROCKER <[e-mail]>]

On 7/5/2011 1:44 PM, Paul Hoffman wrote:
> 1) A Standards Track document specifying how to apply a JSON-structured
> digital signature to data, including (but not limited to) JSON data
> structures.
>
> 2) A Standards Track document specifying how to apply a JSON-structured
> encryption to data, including (but not limited to) JSON data structures.
>
> The working group may decide to address both of these goals in a single
> document, in which case the concrete milestones for signing/encryption below
> will both be satisfied by the single document.
>
> Goals and Milestones --------------------
>
> Aug 2011    Submit JSON object signing document as a WG item.
>
> Aug 2011    Submit JSON object encryption document as a WG item.


The language "how to apply" is a bit odd.  It implies that the thing already
exists and that the current effort is an implementation effort.

I suggestion:

    A specification for JSON-based [digital signature / encryption] for JSON data.

I do note the "but not limited to" language, but it is not obvious what it
means.  This needs to be explained explicitly, since it implies a major
value-add and potential a significant bit of added work.  I'm not claiming it IS
a lot more work, but merely that the cryptic reference could imply all sorts of
things and needs to be constrained.


>>> protocols that use JSON. The Working Group will base its work on the
>>> Cryptographic Message Syntax (CMS), and will solicit input from the rest
>>> of the IETF Security Area to be sure that the security functionality in
>>> the JSON format is correct.

I share the question about requiring that the work start with CMS.  Perhaps it 
is the right decision, but there are arguments in other directions and I don't 
think I've seen the question resolved.

I'll echo Hannes' question too:  the meaning of "based on" needs to be stated 
more explicitly.  A variety of entirely reasonable meanings could apply, from 
conceptual through to installed base of code, so the specific meaning here needs 
to be provided.  (And then debated.)

As an example of the debate:

    *  What is the Internet-scale momentum that justifies using CMS as the 
starting point?

    *  What are the negatives about CMS that could argue against using it?

    *  How is CMS better than alternatives that could be used as the basis?



> On 7/5/2011 2:55 PM, Mike Jones wrote:
>> I'm still going to hold out for inclusion of the third document or
>> capability needed for end-to-end JSON-based signing and encryption:
>>
>> 3) A Standards Track document specifying how to represent public keys as
>> JSON data structures.

A standardized mobile key format could be helpful, since transporting these
these is an essential function for OA&M.  Even within a single-administration
environment, keys need to be shuttled among applications and systems.

This issue came up in the background for DKIM.  I have not heard a huge
community outcry demanding it, but I have repeatedly heard background grumbles
wishing for it.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net