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
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
