To clarify, we will organize a formal review from Web Crypto in late
February/early March before Last Call ideally, and one during Last Call
if needed.
As WebCrypto will not likely hit Last Call till Fall this year, it is
always possible new requirements may happen after the proposed Last Call
dates, but I don't think that will necessitate changes to the draft
charter.
Do notify us once the charter is updated/approved.
I think Mike has done a great job liasoning between the WGs and Richard
has gone out of his way to get compatibility better. However, there are
different requirements in WebCrypto than JOSE for some features and we
need to make sure the members of the WebCrypto API who aren't also
members of JOSE (i.e. Mike and Richard) spend the time to clarify their
requirements before you hit Last Call.
cheers,
harry
On 01/25/2013 05:28 PM, Richard Barnes wrote:
In my view as a humble participant, now.
It seems that there is a fair bit of disagreement about what exactly should be
the relationship between WebCrypto and JOSE, as evidenced by a recent thread on
the WebCrypto mailing list [1]. It would be good to find out sooner rather
than later what the requirements are for JOSE from WebCrypto, and whether the
current specs meet these requirements.
--Richard
[1] <http://lists.w3.org/Archives/Public/public-webcrypto/2013Jan/0024.html>
On Jan 25, 2013, at 2:44 AM, Thomas Roessler <[email protected]> wrote:
From a process perspective, my recommendation would be for Web Crypto to
review the JOSE deliverables *before* they hit last call.
What would be a good time for that from the Jose WG's perspective?
Thanks,
--
Thomas Roessler, W3C <[email protected]> (@roessler)
On 2013-01-23, at 12:18 +0100, Harry Halpin <[email protected]> wrote:
I'd just like to note that the W3C Web Crypto WG (of which Mike Jones is a
member) have been informally liasoning. However, as we enter Last Call we may
need to formalize this relationship more.
I expect the Web Crypto WG to give a formal review of JOSE specs when they hit
Last Call. We probably don't need to sync charters (as that would delay JOSE
and we'd prefer JOSE to be stable *before* we hit Last Call), but we do need to
review and may need to ask for changes. If that is necessary to note in the
rechartering, please do so.
And yes, its via discussions in the WebCrypto WG that the need for private and
symmetric key JOSE formats was brought up. Our spec is not in Last Call, and
thus our use of those is not yet set in stone, but it does seem like a good
idea to add them to the charter as we may need them.
cheers,
harry
On 01/11/2013 09:02 PM, Karen O'Donoghue wrote:
Folks,
Below is a draft update to our charter based on discussions at the last IETF
meeting. The key changes are adding key representations and algorithm
identifiers to the scope of work. This includes some minor language updates in
the general section, the addition of deliverables 5-8, and the addition and
modification of a number of milestones related to these documents.
In addition, the phrase "using a compact URL-safe representation" has been added to the
descriptions of the first two deliverables and "compact JSON object" used in the
milestones.
Jim and I will be submitting a revised charter shortly, and we would like your
comments by 18 January if possible.
Thanks,
Karen
Description of Working Group
JavaScript Object Notation (JSON) is a text format for the serialization of
structured data described in RFC 4627. The JSON format is often used for
serializing and transmitting structured data over a network connection. With
the increased usage of JSON in protocols in the IETF and elsewhere, there is
now a desire to offer security services such as encryption, digital signatures,
message authentication codes (MACs), and key representations for data that is
being carried in JSON format.
Different proposals for providing such security services have already been
defined and implemented. This Working Group's task is to standardize four
kinds of security services, integrity protection (signature and MAC),
encryption, key representations, and algorithm identifiers, in order to
increase interoperability of security features between protocols that use JSON.
The Working Group will base its work on well-known message security primitives
(e.g., 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.
This group is chartered to work on eight documents:
(1) A Standards Track document specifying how to apply JSON-structured integrity
protection to data, including (but not limited to) JSON data structures, using a compact
URL-safe representation. "Integrity protection" includes public-key digital
signatures as well as symmetric-key MACs.
(2) A Standards Track document specifying how to apply a JSON-structured
encryption to data, including (but not limited to) JSON data structures, using
a compact URL-safe representation.
(3) A Standards Track document specifying how to encode public keys as
JSON-structured objects.
(4) A Standards Track document specifying algorithms and algorithm identifiers,
including mandatory-to-implement algorithms for the previous three documents.
(5) A Standards Track document specifying how to apply JSON-structured
integrity protection to data, including (but not limited to) JSON data
structures, using a JSON representation supporting multiple recipients. This
document will build upon the concepts and structures in (1).
(6) A Standards Track document specifying how to apply a JSON-structured
encryption to data, including (but not limited to) JSON data structures, using
a JSON representation supporting multiple recipients. This document will build
upon the concepts and structures in (2).
(7) A Standards Track document specifying how to encode private and symmetric
keys as JSON-structured objects. This document will build upon the concepts
and structures in (3).
(8) A Standards Track application document specifying a means of protecting
private and symmetric keys via encryption. This document will build upon the
concepts and structures in (2) and (7). This document may register additional
algorithms in registries defined by (4).
The working group may decide to address combinations of these goals in
consolidated document(s), in which case the concrete milestones for these goals
will be satisfied by the consolidated document(s).
Goals and Milestones
Jan 2012 Submit compact JSON object integrity document (1) as a WG
item.
Jan 2012 Submit compact JSON object encryption document (2) as a
WG item.
Jan 2012 Submit JSON key format document (3) as a WG item.
Jan 2012 Submit JSON algorithm document (4) as a WG item.
Feb 2013 Start Working Group Last Call on compact JSON object
integrity document (1).
Feb 2013 Start Working Group Last Call on compact JSON object
encryption document (2).
Feb 2013 Start Working Group Last Call on JSON key format document
(3).
Feb 2013 Start Working Group Last Call on JSON algorithm document
(4).
Mar 2013 Submit JSON object integrity document (1) to IESG for
consideration as Standards Track document.
Mar 2013 Submit JSON object encryption document (2) to IESG for
consideration as Standards Track document.
Mar 2013 Submit JSON key format document (3) to IESG for
consideration as Standards Track document.
Mar 2013 Submit JSON algorithm document (4) to IESG for
consideration as Standards Track document.
Mar 2013 Submit multi-recipient JSON object integrity document (5)
as a WG item.
Mar 2013 Submit multi-recipient JSON object encryption document (6)
as a WG item.
Mar 2013 Submit JSON private and symmetric key document (7) as a WG
item.
Mar 2013 Submit JSON key protection application document (8) as a
WG item.
Jun 2013 Start Working Group Last Call on multi-recipient JSON
object integrity document (5).
Jun 2013 Start Working Group Last Call on multi-recipient JSON
object encryption document (6).
Jun 2013 Start Working Group Last Call on JSON private and
symmetric key document (7).
Jun 2013 Start Working Group Last Call on JSON key protection
application document (8).
Jul 2013 Submit multi-recipient JSON object integrity document
(5) to IESG for consideration as Standards Track document.
Jul 2013 Submit multi-recipient JSON object encryption document
(6) to IESG for consideration as Standards Track document.
Jul 2013 Submit JSON private and symmetric key document (7) to
IESG for consideration as Standards Track document.
Jul 2013 Submit JSON key protection application document (8) to
IESG for consideration as Standards Track document.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
