Subject: [woes] Fwd: WG Review: Javascript Object Signing and Encryption (jose)
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Date: Tue, 30 Aug 2011 19:03:13 -0400
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>

Begin forwarded message:

> From: IESG Secretary <[email-masked]>
> Subject: WG Review: Javascript Object Signing and Encryption (jose) 
> Date: August 30, 2011 12:28:37 PM EDT
> To: IETF Announcement list <[email-masked]>
> Reply-To: [email-masked]
> 
> A new IETF working group has been proposed in the Security Area.  The 
> IESG has not made any determination as yet. The following draft charter 
> was submitted, and is provided for informational purposes only. Please 
> send your comments to the IESG mailing list ([email-masked]) by Tuesday, 
> September 6, 2011                            
> 
> Javascript Object Signing and Encryption (jose)
> =================================================
> Status: Proposed Working Group
> Last updated: 2011-08-18
> 
> Chairs
>    TBD
> 
> Security Area Directors:
>    Stephen Farrell <[email-masked]>
>    Sean Turner <[email-masked]>
> 
> Security Area Advisor:
>    Sean Turner <[email-masked]>
> 
> Mailing Lists:
>   General Discussion: [email-masked]
>   To Subscribe: <https://www.ietf.org/mailman/listinfo/jose>
>   Archive: <http://www.ietf.org/mail-archive/web/jose/>
> 
> 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, and message authentication codes (MACs) 
> 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 two security services, integrity protection (signature and 
> MAC) and encryption, 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 four documents:
> 
> 1) A Standards Track document specifying how to apply JSON-structured 
> integrity protection to data, including (but not limited to) JSON data 
> structures.  "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.
> 
> 3) A Standards Track document specifying how to encode public keys as 
> JSON-structured objects.
> 
> 4) A Standards Track document specifying mandatory-to-implement 
> algorithms for the other three documents.
> 
> The working group may decide to address one or more 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
> --------------------
> 
> Jan 2012    Submit JSON object integrity document as a WG item.
> 
> Jan 2012    Submit JSON object encryption document as a WG item.
> 
> Jan 2012    Submit JSON key format document as a WG item.
> 
> Jan 2012    Submit JSON algorithm document as a WG item.
> 
> Jun 2012    Start Working Group Last Call on JSON object integrity 
>            document.
> 
> Jun 2012    Start Working Group Last Call on JSON object encryption 
>            document.
> 
> Jun 2012    Start Working Group Last Call on JSON key format document.
> 
> Jun 2012    Start Working Group Last Call on JSON algorithm document.
> 
> Jul 2012    Submit JSON object integrity document to IESG for 
>            consideration as Standards Track document.
> 
> Jul 2012    Submit JSON object encryption document to IESG for 
>            consideration as Standards Track document.
> 
> Jul 2012    Submit JSON key format document to IESG for consideration
>            as Standards Track document.
> 
> Jul 2012    Submit JSON algorithm document to IESG for consideration
>            as Standards Track document.
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Aug 2011 10:28:20 -0700
To: [email-masked]
Subject: [woes] Minutes posted

<http://www.ietf.org/proceedings/81/minutes/woes.txt>

Many thanks to Karen O'Donoghue for taking the minutes!

--Paul Hoffman

Date: Thu, 25 Aug 2011 12:25:54 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: [woes] charter status

No objections from IESG.  Charter is headed out for external review.

I'm assuming that folks want the mailing list name changed to match the 
new name.  I'll get that process rolling this weekend.

spt

Date: Thu, 18 Aug 2011 09:01:54 -0400
From: Sean Turner <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>, [email-masked]
Subject: Re: [woes] Proposed JOSE Charter

Richard,

Thanks for pulling this together.

All,

I've forwarded this to the IESG secretariat for inclusion on the 
2011-08-28 IESG telechat.  Assuming all goes well with the IESG, it'll 
go out to the entire IETF and the new-work mailing list for a two week 
review period.  To ensure no surprises next week with the IESG, I've 
also added it to today's informal IESG telechat (to get first impressions).

spt

On 8/17/11 1:34 PM, Richard L. Barnes wrote:
> Dear ADs,
>
> Please find below an updated charter proposal for a working group on JSON integrity and encryption.  Based on working group discussions, I believe there is consensus around the current text.
>
> Changes from<http://www.ietf.org/mail-archive/web/woes/current/msg00160.html>:
> -- Moved milestone dates forward 5 months
> -- Changed "signing" to "integrity protection", to encompass asymmetric and symmetric
>
> Thanks,
> --Richard
>
>
>
>
> Javascript Object Signing and Encryption (jose)
> =================================================
>
> Background
> ----------
>
> 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, and message authentication codes (MACs) 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 two security services, integrity protection (signature and MAC) and encryption, 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 four documents:
>
> 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures.  "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.
>
> 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
>
> 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.
>
> The working group may decide to address one or more 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
> --------------------
>
> Jan 2012    Submit JSON object integrity document as a WG item.
>
> Jan 2012    Submit JSON object encryption document as a WG item.
>
> Jan 2012    Submit JSON key format document as a WG item.
>
> Jan 2012    Submit JSON algoritm document as a WG item.
>
> Jun 2012    Start Working Group Last Call on JSON object integrity document.
>
> Jun 2012    Start Working Group Last Call on JSON object encryption document.
>
> Jun 2012    Start Working Group Last Call on JSON key format document.
>
> Jun 2012    Start Working Group Last Call on JSON algorithm document.
>
> Jul 2012    Submit JSON object integrity document to IESG for consideration as
> Standards Track document.
>
> Jul 2012    Submit JSON object encryption document to IESG for consideration
> as Standards Track document.
>
> Jul 2012    Submit JSON key format document to IESG for consideration
> as Standards Track document.
>
> Jul 2012    Submit JSON algorithm document to IESG for consideration
> as Standards Track document.
>
>
>

Date: Thu, 18 Aug 2011 00:20:28 -0700
From: Joe Hildebrand <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>, "[email-masked]" <[email-masked]>, Sean Turner <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: Re: [woes] Proposed JOSE Charter

+1

On 8/17/11 10:34 AM, "Richard L. Barnes" <[email-masked]> wrote:

> Dear ADs,
> 
> Please find below an updated charter proposal for a working group on JSON
> integrity and encryption.  Based on working group discussions, I believe there
> is consensus around the current text.
> 
> Changes from 
> <http://www.ietf.org/mail-archive/web/woes/current/msg00160.html>:
> -- Moved milestone dates forward 5 months
> -- Changed "signing" to "integrity protection", to encompass asymmetric and
> symmetric
> 
> Thanks,
> --Richard
> 
> 
> 
> 
> Javascript Object Signing and Encryption (jose)
> =================================================
> 
> Background 
> ----------
> 
> 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, and message authentication codes (MACs) 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 two
> security services, integrity protection (signature and MAC) and encryption, 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 four documents:
> 
> 1) A Standards Track document specifying how to apply JSON-structured
> integrity protection to data, including (but not limited to) JSON data
> structures.  "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.
> 
> 3) A Standards Track document specifying how to encode public keys as
> JSON-structured objects.
> 
> 4) A Standards Track document specifying mandatory-to-implement algorithms for
> the other three documents.
> 
> The working group may decide to address one or more 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
> --------------------
> 
> Jan 2012    Submit JSON object integrity document as a WG item.
> 
> Jan 2012    Submit JSON object encryption document as a WG item.
> 
> Jan 2012    Submit JSON key format document as a WG item.
> 
> Jan 2012    Submit JSON algoritm document as a WG item.
> 
> Jun 2012    Start Working Group Last Call on JSON object integrity document.
> 
> Jun 2012    Start Working Group Last Call on JSON object encryption document.
> 
> Jun 2012    Start Working Group Last Call on JSON key format document.
> 
> Jun 2012    Start Working Group Last Call on JSON algorithm document.
> 
> Jul 2012    Submit JSON object integrity document to IESG for consideration as
> Standards Track document.
> 
> Jul 2012    Submit JSON object encryption document to IESG for consideration
> as Standards Track document.
> 
> Jul 2012    Submit JSON key format document to IESG for consideration
> as Standards Track document.
> 
> Jul 2012    Submit JSON algorithm document to IESG for consideration
> as Standards Track document.
> 
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

-- 
Joe Hildebrand

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Wed, 17 Aug 2011 11:29:57 -0700
Subject: Re: [woes] Proposed JOSE Charter

--=-Zwo5b26p/ZAy4lE/XFwr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

+1

On Wed, 2011-08-17 at 13:34 -0400, Richard L. Barnes wrote:

> Dear ADs,
> 
> Please find below an updated charter proposal for a working group on JSON integrity and encryption.  Based on working group discussions, I believe there is consensus around the current text.  
> 
> Changes from <http://www.ietf.org/mail-archive/web/woes/current/msg00160.html>:
> -- Moved milestone dates forward 5 months
> -- Changed "signing" to "integrity protection", to encompass asymmetric and symmetric
> 
> Thanks,
> --Richard
> 
> 
> 
> 
> Javascript Object Signing and Encryption (jose)
> =================================================
> 
> Background 
> ----------
> 
> 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, and message authentication codes (MACs) 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 two security services, integrity protection (signature and MAC) and encryption, 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 four documents:
> 
> 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures.  "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.
> 
> 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
> 
> 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.
> 
> The working group may decide to address one or more 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 
> --------------------
> 
> Jan 2012    Submit JSON object integrity document as a WG item.
> 
> Jan 2012    Submit JSON object encryption document as a WG item.
> 
> Jan 2012    Submit JSON key format document as a WG item.
> 
> Jan 2012    Submit JSON algoritm document as a WG item.
> 
> Jun 2012    Start Working Group Last Call on JSON object integrity document.
> 
> Jun 2012    Start Working Group Last Call on JSON object encryption document.
> 
> Jun 2012    Start Working Group Last Call on JSON key format document.
> 
> Jun 2012    Start Working Group Last Call on JSON algorithm document.
> 
> Jul 2012    Submit JSON object integrity document to IESG for consideration as 
> Standards Track document.
> 
> Jul 2012    Submit JSON object encryption document to IESG for consideration 
> as Standards Track document.
> 
> Jul 2012    Submit JSON key format document to IESG for consideration 
> as Standards Track document.
> 
> Jul 2012    Submit JSON algorithm document to IESG for consideration 
> as Standards Track document.
> 
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--=-Zwo5b26p/ZAy4lE/XFwr
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
+1<BR>
<BR>
On Wed, 2011-08-17 at 13:34 -0400, Richard L. Barnes wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Dear ADs,

Please find below an updated charter proposal for a working group on JSON integrity and encryption.  Based on working group discussions, I believe there is consensus around the current text.  

Changes from &lt;<A HREF="http://www.ietf.org/mail-archive/web/woes/current/msg00160.html">http://www.ietf.org/mail-archive/web/woes/current/msg00160.html</A>&gt;:
-- Moved milestone dates forward 5 months
-- Changed &quot;signing&quot; to &quot;integrity protection&quot;, to encompass asymmetric and symmetric

Thanks,
--Richard

Javascript Object Signing and Encryption (jose)
=================================================

Background 
----------

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, and message authentication codes (MACs) 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 two security services, integrity protection (signature and MAC) and encryption, 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 four documents:

1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures.  &quot;Integrity protection&quot; 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.

3) A Standards Track document specifying how to encode public keys as JSON-structured objects.

4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.

The working group may decide to address one or more 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 
--------------------

Jan 2012    Submit JSON object integrity document as a WG item.

Jan 2012    Submit JSON object encryption document as a WG item.

Jan 2012    Submit JSON key format document as a WG item.

Jan 2012    Submit JSON algoritm document as a WG item.

Jun 2012    Start Working Group Last Call on JSON object integrity document.

Jun 2012    Start Working Group Last Call on JSON object encryption document.

Jun 2012    Start Working Group Last Call on JSON key format document.

Jun 2012    Start Working Group Last Call on JSON algorithm document.

Jul 2012    Submit JSON object integrity document to IESG for consideration as 
Standards Track document.

Jul 2012    Submit JSON object encryption document to IESG for consideration 
as Standards Track document.

Jul 2012    Submit JSON key format document to IESG for consideration 
as Standards Track document.

Jul 2012    Submit JSON algorithm document to IESG for consideration 
as Standards Track document.

_______________________________________________
woes mailing list
<A HREF="mailto:[email-masked]">[email-masked]</A>
<A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>

--=-Zwo5b26p/ZAy4lE/XFwr--

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 17 Aug 2011 13:34:41 -0400
To: [email-masked], Sean Turner <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: [woes] Proposed JOSE Charter

Dear ADs,

Please find below an updated charter proposal for a working group on =
JSON integrity and encryption.  Based on working group discussions, I =
believe there is consensus around the current text. =20

Changes from =
<http://www.ietf.org/mail-archive/web/woes/current/msg00160.html>:
-- Moved milestone dates forward 5 months
-- Changed "signing" to "integrity protection", to encompass asymmetric =
and symmetric

Thanks,
--Richard

Javascript Object Signing and Encryption (jose)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Background=20
----------

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, and message authentication codes (MACs) =
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 two security services, integrity protection (signature and =
MAC) and encryption, 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 four documents:

1) A Standards Track document specifying how to apply JSON-structured =
integrity protection to data, including (but not limited to) JSON data =
structures.  "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.

3) A Standards Track document specifying how to encode public keys as =
JSON-structured objects.

4) A Standards Track document specifying mandatory-to-implement =
algorithms for the other three documents.

The working group may decide to address one or more 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=20
--------------------

Jan 2012    Submit JSON object integrity document as a WG item.

Jan 2012    Submit JSON object encryption document as a WG item.

Jan 2012    Submit JSON key format document as a WG item.

Jan 2012    Submit JSON algoritm document as a WG item.

Jun 2012    Start Working Group Last Call on JSON object integrity =
document.

Jun 2012    Start Working Group Last Call on JSON object encryption =
document.

Jun 2012    Start Working Group Last Call on JSON key format document.

Jun 2012    Start Working Group Last Call on JSON algorithm document.

Jul 2012    Submit JSON object integrity document to IESG for =
consideration as=20
Standards Track document.

Jul 2012    Submit JSON object encryption document to IESG for =
consideration=20
as Standards Track document.

Jul 2012    Submit JSON key format document to IESG for consideration=20
as Standards Track document.

Jul 2012    Submit JSON algorithm document to IESG for consideration=20
as Standards Track document.

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 15 Aug 2011 13:29:06 -0700
Subject: [woes] Progress?

--=-WpQK3raw0Kfyf01gmeM4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Any news of progress on getting the charter codified and approved, so we
can move onto the "funner" parts? :-)

Paul

--=-WpQK3raw0Kfyf01gmeM4
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
Any news of progress on getting the charter codified and approved, so we can move onto the &quot;funner&quot; parts? :-)<BR>
<BR>
Paul
</BODY>
</HTML>

--=-WpQK3raw0Kfyf01gmeM4--

Date: Wed, 10 Aug 2011 20:01:13 -0600
From: Joe Hildebrand <[email-masked]>
To: Thomas Hardjono <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

On 8/10/11 12:38 PM, "Thomas Hardjono" <[email-masked]> wrote:

> So perhaps the next best thing would be for
> the Charter to list the second draft (listing
> the MTI ciphers/algorithms) as a WG deliverable,
> with a delivery date.

+1

-- 
Joe Hildebrand

From: Thomas Hardjono <[email-masked]>
To: Joe Hildebrand <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 10 Aug 2011 14:38:36 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

> -----Original Message-----
> From: Joe Hildebrand [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2011 10:57 AM
> To: Thomas Hardjono; [email-masked]
> Subject: Re: [woes] Support multiple Crypto algorithms? was RE:
> Proposed charter, post-Quebec edition
>=20
> On 8/9/11 2:43 PM, "Thomas Hardjono" <[email-masked]> wrote:
>=20
> > Its perfectly ok (and necessary for interop) for the implementers to
> > agree beforehand about which cipher(s) are must implement.
>=20
> I'd phrase this "agree beforehand" as the mandatory-to-implement set of
> algorithms.  I read your original message as saying that you didn't
> think there should be *any* MTI algorithms.  If I misread, then we're
> on the same page.

Hi Joe,

Apologies if I miscommunicated -- I think we're on the same page :)

>=20
> > Support for multiple
> > ciphers is a good thing. However, there is no need to call these out
> > within the JOSE specification.
>=20
> The proposal on the table is for there to be a second draft which
> contains the MTI algorithms.

ok, great.

>=20
> > Perhaps the chairs can simply do a WG consensus call to ask which
> > ciphers/algorithms to implement as part of the first WG deliverables.
>=20
> We'd need to write that consensus down in a document so that folks who
> came along later would know what we decided.  Drafts don't *have* to be
> long and complicated. :)

Agree. Typically IETF WGs do not maintain=20
strict meeting Minutes :(

So perhaps the next best thing would be for
the Charter to list the second draft (listing
the MTI ciphers/algorithms) as a WG deliverable,
with a delivery date.

/thomas/

Date: Wed, 10 Aug 2011 08:56:32 -0600
From: Joe Hildebrand <[email-masked]>
To: Thomas Hardjono <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

On 8/9/11 2:43 PM, "Thomas Hardjono" <[email-masked]> wrote:

> Its perfectly ok (and necessary for interop) for the implementers to agree
> beforehand about which cipher(s) are must implement.

I'd phrase this "agree beforehand" as the mandatory-to-implement set of
algorithms.  I read your original message as saying that you didn't think
there should be *any* MTI algorithms.  If I misread, then we're on the same
page.

> Support for multiple
> ciphers is a good thing. However, there is no need to call these out within
> the JOSE specification.

The proposal on the table is for there to be a second draft which contains
the MTI algorithms.

> Perhaps the chairs can simply do a WG consensus call to ask which
> ciphers/algorithms to implement as part of the first WG deliverables.

We'd need to write that consensus down in a document so that folks who came
along later would know what we decided.  Drafts don't *have* to be long and
complicated. :)

-- 
Joe Hildebrand

From: Thomas Hardjono <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 9 Aug 2011 16:43:49 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

Hi Joe,

Its perfectly ok (and necessary for interop) for the implementers to agree =
beforehand about which cipher(s) are must implement. Support for multiple c=
iphers is a good thing. However, there is no need to call these out within =
the JOSE specification.

Perhaps the chairs can simply do a WG consensus call to ask which ciphers/a=
lgorithms to implement as part of the first WG deliverables.

/thomas/

__________________________________________

> -----Original Message-----
> From: Joe Hildebrand [mailto:[email-masked]]
> Sent: Tuesday, August 09, 2011 2:34 PM
> To: Thomas Hardjono; [email-masked]
> Subject: Re: [woes] Support multiple Crypto algorithms? was RE:
> Proposed charter, post-Quebec edition
>=20
> One of the goals of JOSE is to increase the number of interoperable
> implementations.  I don't think a lack of MTI algorithms will further
> that goal.
>=20
>=20
> On 8/9/11 12:02 PM, "Thomas Hardjono" <[email-masked]> wrote:
>=20
> >
> > As far as I can remember, CMS (RFC3852 and RFC5652) does not choose
> > any specific algorithm.
> >
> > Therefore it make sense for JOSE to follow the same approach.
> >
> > /thomas/
> >
> >
> >
> > __________________________________________
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Phillip Hallam-Baker
> > Sent: Monday, August 08, 2011 10:34 PM
> > To: Joe Hildebrand
> > Cc: [email-masked]
> > Subject: Re: [woes] Support multiple Crypto algorithms? was RE:
> > Proposed charter, post-Quebec edition
> >
> >
> > On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand
> > <[email-masked]>
> > wrote:
> > Agree. Algorithm agility is a must, but large numbers of supported
> > algorithms out of the gate are not. Having a small set of algorithms
> > widely-implemented will increase interoperability drastically,
> > particularly considering that in some of the target operating
> > environments, we'll need to wait for people with adequate
> cryptographic skills to help.
> >
> > I do really like the idea of splitting the MTI specification into a
> > small separate draft, so that it can be rev'd easily as needed.
> >
> > +1
> >
> > And that way we can have two profiles (or more) to address different
> > implementation situations.
> >
> > Web Services implementation constraints are frequently asymmetric.
> > There is one portion built on some all-singing/dancing platform like
> > .NET or whatever and that talks to a thin client embedded in Jscript
> > or a mobile device or what-have-you.
> >
> > If we can avoid creating yet another crypto-registry (i.e. re-use the
> > PEM or whatever algorithm registry) then all the spec needs to say is
> > that X is the slot where the algorithm name goes and the MTI doc(s)
> > specify how to get interoperability.
> >
>=20
> --
> Joe Hildebrand

Date: Tue, 09 Aug 2011 12:34:10 -0600
From: Joe Hildebrand <[email-masked]>
To: Thomas Hardjono <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

One of the goals of JOSE is to increase the number of interoperable
implementations.  I don't think a lack of MTI algorithms will further that
goal.

On 8/9/11 12:02 PM, "Thomas Hardjono" <[email-masked]> wrote:

>=20
> As far as I can remember, CMS (RFC3852 and RFC5652) does not choose any
> specific algorithm.
>=20
> Therefore it make sense for JOSE to follow the same approach.
>=20
> /thomas/
>=20
>=20
>=20
> __________________________________________
>=20
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Phillip Hallam-Baker
> Sent: Monday, August 08, 2011 10:34 PM
> To: Joe Hildebrand
> Cc: [email-masked]
> Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed
> charter, post-Quebec edition
>=20
>=20
> On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand <[email-masked]>
> wrote:
> Agree. Algorithm agility is a must, but large numbers of supported
> algorithms out of the gate are not. Having a small set of algorithms
> widely-implemented will increase interoperability drastically, particular=
ly
> considering that in some of the target operating environments, we'll need=
 to
> wait for people with adequate cryptographic skills to help.
>=20
> I do really like the idea of splitting the MTI specification into a small
> separate draft, so that it can be rev'd easily as needed.
>=20
> +1
>=20
> And that way we can have two profiles (or more) to address different
> implementation situations.
>=20
> Web Services implementation constraints are frequently asymmetric. There =
is
> one portion built on some all-singing/dancing platform like .NET or whate=
ver
> and that talks to a thin client embedded in Jscript or a mobile device or
> what-have-you.
>=20
> If we can avoid creating yet another crypto-registry (i.e. re-use the PEM=
 or
> whatever algorithm registry) then all the spec needs to say is that X is =
the
> slot where the algorithm name goes and the MTI doc(s) specify how to get
> interoperability.
> =A0

--=20
Joe Hildebrand

From: Thomas Hardjono <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 9 Aug 2011 14:02:51 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

As far as I can remember, CMS (RFC3852 and RFC5652) does not choose any spe=
cific algorithm.

Therefore it make sense for JOSE to follow the same approach.

/thomas/

__________________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phi=
llip Hallam-Baker
Sent: Monday, August 08, 2011 10:34 PM
To: Joe Hildebrand
Cc: [email-masked]
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed ch=
arter, post-Quebec edition

On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand <[email-masked]> w=
rote:
Agree. Algorithm agility is a must, but large numbers of supported
algorithms out of the gate are not. Having a small set of algorithms
widely-implemented will increase interoperability drastically, particularly
considering that in some of the target operating environments, we'll need t=
o
wait for people with adequate cryptographic skills to help.

I do really like the idea of splitting the MTI specification into a small
separate draft, so that it can be rev'd easily as needed.

+1

And that way we can have two profiles (or more) to address different implem=
entation situations.

Web Services implementation constraints are frequently asymmetric. There is=
 one portion built on some all-singing/dancing platform like .NET or whatev=
er and that talks to a thin client embedded in Jscript or a mobile device o=
r what-have-you.

If we can avoid creating yet another crypto-registry (i.e. re-use the PEM o=
r whatever algorithm registry) then all the spec needs to say is that X is =
the slot where the algorithm name goes and the MTI doc(s) specify how to ge=
t interoperability.
=A0
--=20
Website: http://hallambaker.com/

Date: Tue, 9 Aug 2011 03:34:13 +0100
From: Phillip Hallam-Baker <[email-masked]>
To: Joe Hildebrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

--00163691fc2d3f97cb04aa0966ad
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand <[email-masked]>wrote:

> Agree. Algorithm agility is a must, but large numbers of supported
> algorithms out of the gate are not. Having a small set of algorithms
> widely-implemented will increase interoperability drastically, particularly
> considering that in some of the target operating environments, we'll need
> to
> wait for people with adequate cryptographic skills to help.
>
> I do really like the idea of splitting the MTI specification into a small
> separate draft, so that it can be rev'd easily as needed.

+1

And that way we can have two profiles (or more) to address different
implementation situations.

Web Services implementation constraints are frequently asymmetric. There is
one portion built on some all-singing/dancing platform like .NET or whatever
and that talks to a thin client embedded in Jscript or a mobile device or
what-have-you.

If we can avoid creating yet another crypto-registry (i.e. re-use the PEM or
whatever algorithm registry) then all the spec needs to say is that X is the
slot where the algorithm name goes and the MTI doc(s) specify how to get
interoperability.

-- 
Website: http://hallambaker.com/

--00163691fc2d3f97cb04aa0966ad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Aug 8, 2011 at 8:48 PM, Joe Hild=
ebrand <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">jo=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
Agree. Algorithm agility is a must, but large numbers of supported<br>
algorithms out of the gate are not. Having a small set of algorithms<br>
widely-implemented will increase interoperability drastically, particularly=
<br>
considering that in some of the target operating environments, we&#39;ll ne=
ed to<br>
wait for people with adequate cryptographic skills to help.<br>
<br>
I do really like the idea of splitting the MTI specification into a small<b=
r>
separate draft, so that it can be rev&#39;d easily as needed.</blockquote><=
div><br></div><div>+1</div><div><br></div><div>And that way we can have two=
 profiles (or more) to address different implementation situations.</div>
<div><br></div><div>Web Services implementation constraints are frequently =
asymmetric. There is one portion built on some all-singing/dancing platform=
 like .NET or whatever and that talks to a thin client embedded in Jscript =
or a mobile device or what-have-you.</div>
<div><br></div><div>If we can avoid creating yet another crypto-registry (i=
.e. re-use the PEM or whatever algorithm registry) then all the spec needs =
to say is that X is the slot where the algorithm name goes and the MTI doc(=
s) specify how to get interoperability.</div>
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br><br>

--00163691fc2d3f97cb04aa0966ad--

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 8 Aug 2011 17:11:25 -0400
To: Joe Hildebrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

+1

This is exactly what the  DNSSEC community has done.
<http://tools.ietf.org/html/rfc6014>

On Aug 8, 2011, at 3:48 PM, Joe Hildebrand wrote:

> Agree. Algorithm agility is a must, but large numbers of supported
> algorithms out of the gate are not. Having a small set of algorithms
> widely-implemented will increase interoperability drastically, =
particularly
> considering that in some of the target operating environments, we'll =
need to
> wait for people with adequate cryptographic skills to help.
>=20
> I do really like the idea of splitting the MTI specification into a =
small
> separate draft, so that it can be rev'd easily as needed.
>=20
>=20
> On 8/8/11 1:04 PM, "John Bradley" <[email-masked]> wrote:
>=20
>> Hal,
>>=20
>> JWE/JWS supports multiple algorithms.   I haven't seen any argument =
to not
>> have algorithm ajility.
>>=20
>> There was a mention of what algorithms should be MTI.   I expect that
>> discussion will continue.  (It is still gong on for xmlenc/xmldeig =
over at
>> W3C)
>>=20
>> We clearly need multiple algorithms, in my opinion.
>>=20
>> John B.
>> On 2011-08-08, at 2:28 PM, Hal Lockhart wrote:
>>=20
>>> There seems to be a position forming around the idea that =
woes/joes/jose
>>> should specify (perhaps even design) a single algorithm (perhaps one =
for sign
>>> and one for encrypt). I presume that means that if in future it was =
necessary
>>> to use a different algorithm we would just start over and write a =
new spec.
>>>=20
>>> I am not in favor of this, but I concede that it would simplify =
things in
>>> this group a lot.
>>>=20
>>> If there was only one algorithm, there is no need for any JSON =
metadata about
>>> what the algorithm is being used.
>>> All we need is a way to indicate what is signed or encrypted and =
something
>>> that says this is a JOES signature (or encryption) and perhaps some =
kind of
>>> indication of what key was used.
>>>=20
>>> If we were to specify only one algorithm, but provide metadata to =
indicate
>>> the algorithm, others will use additional, unspecified algorithms, =
just as
>>> people used 3-DES and AES in Kerberos while continuing to cite RFC =
1510 which
>>> only includes DES.
>>>=20
>>> I won't bother to list the many (many, many) reasons why a single =
algorithm
>>> is unlikely to fly, unless it turns out a lot of people are really =
committed
>>> to that view.=20
>>>=20
>>> Instead, I suggest we say explicitly say that multiple algorithms =
will be
>>> possible, but one will be MTI. It wouldn't hurt to also say we are =
not going
>>> to design any new algorithms, but simply provide means to specify =
which
>>> existing one is being used.
>>>=20
>>> Hal
>>>=20
>>>> -----Original Message-----
>>>> From: Jeremy Laurenson [mailto:[email-masked]]
>>>> Sent: Saturday, August 06, 2011 12:31 AM
>>>> To: [email-masked]
>>>> Subject: Re: [woes] Proposed charter, post-Quebec edition
>>>>=20
>>>>=20
>>>> =46rom a Javascript dev perspective, specifying an algorithm
>>>> will make it a hell of of lot easier to implement, instead of
>>>> having to potentially account for multiples.
>>>>=20
>>>> Lets use the example of a web app that aggregates social
>>>> media data - just for giggles - and uses WOES to secure the
>>>> communications to well-defined interfaces
>>>>=20
>>>> If multiple vendors' websites implement WOES/JOES/JOSE with
>>>> different algorithms, it becomes more complex vs a single,
>>>> consistent one.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
>>>>=20
>>>>> So I'll bite on this ;)
>>>>>=20
>>>>> I think we can write the spec to require a particular
>>>> algorithm choice, but it might make more sense to define the
>>>> options and then allow the environment in which the solution
>>>> will be used to specify it's requirements.  But, I believe
>>>> that is a discussion we'll have while writing the spec.
>>>>>=20
>>>>> spt
>>>>>=20
>>>>> On 8/4/11 9:29 AM, John Bradley wrote:
>>>>>> HMAC is requirement for adoption in the JWS use cases.
>>>>>>=20
>>>>>> If we want to describe it as something other than a
>>>> "Qualified Digital
>>>>>> Signature", that is fine as long as it is MTI:)
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>>=20
>>>>>> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>=20
>>>>>>>  On 8/2/11 7:13 PM, Paul Hoffman wrote:
>>>>>>>=20
>>>>>>>      Here is a proposal for the charter based on the
>>>> discussion in
>>>>>>>      the BoF last week and later discussion with Sean Turner.
>>>>>>>      Comments, praise, scorn, etc., are welcome.
>>>>>>>=20
>>>>>>>      --Paul and Richard
>>>>>>>=20
>>>>>>>      Javascript Object Signing and Encrypting (jose)
>>>>>>>      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D__=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>>>>>>>=20
>>>>>>>      Background
>>>>>>>      ----------
>>>>>>>=20
>>>>>>>      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 and
>>>>>>>      digital signatures for data that is being carried
>>>> in JSON format.
>>>>>>>=20
>>>>>>>      Different proposals for providing such security
>>>> services have
>>>>>>>      already been defined and implemented. This Working Group's
>>>>>>>      task is to standardize two security services,
>>>> encrypting and
>>>>>>>      digitally signing, 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.
>>>>>>>=20
>>>>>>>      This group is chartered to work on four documents:
>>>>>>>=20
>>>>>>>      1) A Standards Track document specifying how to apply a
>>>>>>>      JSON-structured digital signature to data,
>>>> including (but not
>>>>>>>      limited to) JSON data structures. "Digital signature" is
>>>>>>>      defined as a hash operation followed by a
>>>> signature operation
>>>>>>>      using asymmetric keys.
>>>>>>>=20
>>>>>>>=20
>>>>>>>  I just want to make sure that we agree now that a digital
>>>>>>>  signature is a hash followed by a signature algorithm
>>>> (e.g., RSA
>>>>>>>  with SHA-256). I've seen a couple of drafts that tried
>>>> to say an
>>>>>>>  HMAC (e.g., HMAC-SHA256) was a digital signature; one
>>>> called it a
>>>>>>>  symmetric key based digital signature algorithm (note
>>>> this phrase
>>>>>>>  didn't get through the IESG).
>>>>>>>=20
>>>>>>>=20
>>>>>>> An HMAC is not a digital signature, but the spec
>>>> definitely needs to
>>>>>>> be able to cover MAC based authentication.
>>>>>>>=20
>>>>>>>=20
>>>>>>> I know that public key is getting easier as far as
>>>> computation goes.
>>>>>>> But for many applications the non-repudiation you get in digital
>>>>>>> signatures is actually undesirable.
>>>>>>>=20
>>>>>>> There are interesting tricks you can do with symmetric
>>>> crypto that are
>>>>>>> much harder to do in public key and end up with some
>>>> scheme that only
>>>>>>> 50 academics in the world can follow and has a security proof =
that
>>>>>>> rest on rather esoteric assumptions.
>>>>>>>=20
>>>>>>> --
>>>>>>> Website: http://hallambaker.com/
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> woes mailing list
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>> https://www.ietf.org/mailman/listinfo/woes
>>>>>>=20
>>>>> _______________________________________________
>>>>> woes mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/woes
>>>>=20
>>>> _______________________________________________
>>>> woes mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/woes
>>>>=20
>>> _______________________________________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/woes
>>=20
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>=20
> --=20
> Joe Hildebrand
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

Date: Mon, 08 Aug 2011 13:48:08 -0600
From: Joe Hildebrand <[email-masked]>
To: John Bradley <[email-masked]>, Hal Lockhart <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

Agree. Algorithm agility is a must, but large numbers of supported
algorithms out of the gate are not. Having a small set of algorithms
widely-implemented will increase interoperability drastically, particularly
considering that in some of the target operating environments, we'll need to
wait for people with adequate cryptographic skills to help.

I do really like the idea of splitting the MTI specification into a small
separate draft, so that it can be rev'd easily as needed.

On 8/8/11 1:04 PM, "John Bradley" <[email-masked]> wrote:

> Hal,
> 
> JWE/JWS supports multiple algorithms.   I haven't seen any argument to not
> have algorithm ajility.
> 
> There was a mention of what algorithms should be MTI.   I expect that
> discussion will continue.  (It is still gong on for xmlenc/xmldeig over at
> W3C)
> 
> We clearly need multiple algorithms, in my opinion.
> 
> John B.
> On 2011-08-08, at 2:28 PM, Hal Lockhart wrote:
> 
>> There seems to be a position forming around the idea that woes/joes/jose
>> should specify (perhaps even design) a single algorithm (perhaps one for sign
>> and one for encrypt). I presume that means that if in future it was necessary
>> to use a different algorithm we would just start over and write a new spec.
>> 
>> I am not in favor of this, but I concede that it would simplify things in
>> this group a lot.
>> 
>> If there was only one algorithm, there is no need for any JSON metadata about
>> what the algorithm is being used.
>> All we need is a way to indicate what is signed or encrypted and something
>> that says this is a JOES signature (or encryption) and perhaps some kind of
>> indication of what key was used.
>> 
>> If we were to specify only one algorithm, but provide metadata to indicate
>> the algorithm, others will use additional, unspecified algorithms, just as
>> people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 which
>> only includes DES.
>> 
>> I won't bother to list the many (many, many) reasons why a single algorithm
>> is unlikely to fly, unless it turns out a lot of people are really committed
>> to that view. 
>> 
>> Instead, I suggest we say explicitly say that multiple algorithms will be
>> possible, but one will be MTI. It wouldn't hurt to also say we are not going
>> to design any new algorithms, but simply provide means to specify which
>> existing one is being used.
>> 
>> Hal
>> 
>>> -----Original Message-----
>>> From: Jeremy Laurenson [mailto:[email-masked]]
>>> Sent: Saturday, August 06, 2011 12:31 AM
>>> To: [email-masked]
>>> Subject: Re: [woes] Proposed charter, post-Quebec edition
>>> 
>>> 
>>> From a Javascript dev perspective, specifying an algorithm
>>> will make it a hell of of lot easier to implement, instead of
>>> having to potentially account for multiples.
>>> 
>>> Lets use the example of a web app that aggregates social
>>> media data - just for giggles - and uses WOES to secure the
>>> communications to well-defined interfaces
>>> 
>>> If multiple vendors' websites implement WOES/JOES/JOSE with
>>> different algorithms, it becomes more complex vs a single,
>>> consistent one.
>>> 
>>> 
>>> 
>>> 
>>> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
>>> 
>>>> So I'll bite on this ;)
>>>> 
>>>> I think we can write the spec to require a particular
>>> algorithm choice, but it might make more sense to define the
>>> options and then allow the environment in which the solution
>>> will be used to specify it's requirements.  But, I believe
>>> that is a discussion we'll have while writing the spec.
>>>> 
>>>> spt
>>>> 
>>>> On 8/4/11 9:29 AM, John Bradley wrote:
>>>>> HMAC is requirement for adoption in the JWS use cases.
>>>>> 
>>>>> If we want to describe it as something other than a
>>> "Qualified Digital
>>>>> Signature", that is fine as long as it is MTI:)
>>>>> 
>>>>> John B.
>>>>> 
>>>>> 
>>>>> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>   On 8/2/11 7:13 PM, Paul Hoffman wrote:
>>>>>> 
>>>>>>       Here is a proposal for the charter based on the
>>> discussion in
>>>>>>       the BoF last week and later discussion with Sean Turner.
>>>>>>       Comments, praise, scorn, etc., are welcome.
>>>>>> 
>>>>>>       --Paul and Richard
>>>>>> 
>>>>>>       Javascript Object Signing and Encrypting (jose)
>>>>>>       ==============================__=================
>>>>>> 
>>>>>>       Background
>>>>>>       ----------
>>>>>> 
>>>>>>       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 and
>>>>>>       digital signatures 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 two security services,
>>> encrypting and
>>>>>>       digitally signing, 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 four documents:
>>>>>> 
>>>>>>       1) A Standards Track document specifying how to apply a
>>>>>>       JSON-structured digital signature to data,
>>> including (but not
>>>>>>       limited to) JSON data structures. "Digital signature" is
>>>>>>       defined as a hash operation followed by a
>>> signature operation
>>>>>>       using asymmetric keys.
>>>>>> 
>>>>>> 
>>>>>>   I just want to make sure that we agree now that a digital
>>>>>>   signature is a hash followed by a signature algorithm
>>> (e.g., RSA
>>>>>>   with SHA-256). I've seen a couple of drafts that tried
>>> to say an
>>>>>>   HMAC (e.g., HMAC-SHA256) was a digital signature; one
>>> called it a
>>>>>>   symmetric key based digital signature algorithm (note
>>> this phrase
>>>>>>   didn't get through the IESG).
>>>>>> 
>>>>>> 
>>>>>> An HMAC is not a digital signature, but the spec
>>> definitely needs to
>>>>>> be able to cover MAC based authentication.
>>>>>> 
>>>>>> 
>>>>>> I know that public key is getting easier as far as
>>> computation goes.
>>>>>> But for many applications the non-repudiation you get in digital
>>>>>> signatures is actually undesirable.
>>>>>> 
>>>>>> There are interesting tricks you can do with symmetric
>>> crypto that are
>>>>>> much harder to do in public key and end up with some
>>> scheme that only
>>>>>> 50 academics in the world can follow and has a security proof that
>>>>>> rest on rather esoteric assumptions.
>>>>>> 
>>>>>> --
>>>>>> Website: http://hallambaker.com/
>>>>>> 
>>>>>> _______________________________________________
>>>>>> woes mailing list
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/woes
>>>>> 
>>>> _______________________________________________
>>>> woes mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/woes
>>> 
>>> _______________________________________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/woes
>>> 
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

-- 
Joe Hildebrand

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 08 Aug 2011 12:21:01 -0700
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

--=-iNkFK04kZGa6VOzG8o7y
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2011-08-08 at 11:28 -0700, Hal Lockhart wrote:

> There seems to be a position forming around the idea that
> woes/joes/jose should specify (perhaps even design) a single algorithm
> (perhaps one for sign and one for encrypt). I presume that means that
> if in future it was necessary to use a different algorithm we would
> just start over and write a new spec.

If such a position is actually forming, I'd like to know why we'd want
to pre-bake obsolescence into the spec.

> I am not in favor of this, but I concede that it would simplify things
> in this group a lot.

If by simplify you mean thinning out the number of people who will find
it useful, perhaps. ;-)

> If there was only one algorithm, there is no need for any JSON
> metadata about what the algorithm is being used.

True, but perhaps at the very least we'd need some kind of metadata
saying what version of JOSE is being used, if nothing more than to
determine what version of what cipher(s) it supports.

> All we need is a way to indicate what is signed or encrypted and
> something that says this is a JOES signature (or encryption) and
> perhaps some kind of indication of what key was used.

This may not be enough, especially when JOSE undergoes a revision.

> If we were to specify only one algorithm, but provide metadata to
> indicate the algorithm, others will use additional, unspecified
> algorithms, just as people used 3-DES and AES in Kerberos while
> continuing to cite RFC 1510 which only includes DES.

I think if we establish a minimum supported set, with extensibility
(i.e. cipher suite can be specified), we retain core interoperability
while not throwing out the standard when the core ciphers prove
unsuitable.

> I won't bother to list the many (many, many) reasons why a single
> algorithm is unlikely to fly, unless it turns out a lot of people are
> really committed to that view.

+1

> Instead, I suggest we say explicitly say that multiple algorithms will
> be possible, but one will be MTI. It wouldn't hurt to also say we are
> not going to design any new algorithms, but simply provide means to
> specify which existing one is being used.

+1, though I suggest we may codify a handful of well-used suites while
possibly making one mandatory to implement. 

Paul

--=-iNkFK04kZGa6VOzG8o7y
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
On Mon, 2011-08-08 at 11:28 -0700, Hal Lockhart wrote:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    There seems to be a position forming around the idea that woes/joes/jose should specify (perhaps even design) a single algorithm (perhaps one for sign and one for encrypt). I presume that means that if in future it was necessary to use a different algorithm we would just start over and write a new spec.<BR>
</BLOCKQUOTE>
If such a position is actually forming, I'd like to know why we'd want to pre-bake obsolescence into the spec.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    I am not in favor of this, but I concede that it would simplify things in this group a lot.<BR>
</BLOCKQUOTE>
If by simplify you mean thinning out the number of people who will find it useful, perhaps. ;-)<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    If there was only one algorithm, there is no need for any JSON metadata about what the algorithm is being used.<BR>
</BLOCKQUOTE>
True, but perhaps at the very least we'd need some kind of metadata saying what version of JOSE is being used, if nothing more than to determine what version of what cipher(s) it supports.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    All we need is a way to indicate what is signed or encrypted and something that says this is a JOES signature (or encryption) and perhaps some kind of indication of what key was used.<BR>
</BLOCKQUOTE>
This may not be enough, especially when JOSE undergoes a revision.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    If we were to specify only one algorithm, but provide metadata to indicate the algorithm, others will use additional, unspecified algorithms, just as people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 which only includes DES.<BR>
</BLOCKQUOTE>
I think if we establish a minimum supported set, with extensibility (i.e. cipher suite can be specified), we retain core interoperability while not throwing out the standard when the core ciphers prove unsuitable.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    I won't bother to list the many (many, many) reasons why a single algorithm is unlikely to fly, unless it turns out a lot of people are really committed to that view.<BR>
</BLOCKQUOTE>
+1<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Instead, I suggest we say explicitly say that multiple algorithms will be possible, but one will be MTI. It wouldn't hurt to also say we are not going to design any new algorithms, but simply provide means to specify which existing one is being used.<BR>
</BLOCKQUOTE>
+1, though I suggest we may codify a handful of well-used suites while possibly making one mandatory to implement. <BR>
<BR>
Paul
</BODY>
</HTML>

--=-iNkFK04kZGa6VOzG8o7y--

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 15:04:23 -0400
To: Hal Lockhart <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

--Apple-Mail=_21BAFEBD-0FB8-4418-86E3-D7491350BDB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hal,

JWE/JWS supports multiple algorithms.   I haven't seen any argument to =
not have algorithm ajility.

There was a mention of what algorithms should be MTI.   I expect that =
discussion will continue.  (It is still gong on for xmlenc/xmldeig over =
at W3C)

We clearly need multiple algorithms, in my opinion.

John B.
On 2011-08-08, at 2:28 PM, Hal Lockhart wrote:

> There seems to be a position forming around the idea that =
woes/joes/jose should specify (perhaps even design) a single algorithm =
(perhaps one for sign and one for encrypt). I presume that means that if =
in future it was necessary to use a different algorithm we would just =
start over and write a new spec.
>=20
> I am not in favor of this, but I concede that it would simplify things =
in this group a lot.
>=20
> If there was only one algorithm, there is no need for any JSON =
metadata about what the algorithm is being used.
> All we need is a way to indicate what is signed or encrypted and =
something that says this is a JOES signature (or encryption) and perhaps =
some kind of indication of what key was used.
>=20
> If we were to specify only one algorithm, but provide metadata to =
indicate the algorithm, others will use additional, unspecified =
algorithms, just as people used 3-DES and AES in Kerberos while =
continuing to cite RFC 1510 which only includes DES.
>=20
> I won't bother to list the many (many, many) reasons why a single =
algorithm is unlikely to fly, unless it turns out a lot of people are =
really committed to that view.=20
>=20
> Instead, I suggest we say explicitly say that multiple algorithms will =
be possible, but one will be MTI. It wouldn't hurt to also say we are =
not going to design any new algorithms, but simply provide means to =
specify which existing one is being used.
>=20
> Hal
>=20
>> -----Original Message-----
>> From: Jeremy Laurenson [mailto:[email-masked]]
>> Sent: Saturday, August 06, 2011 12:31 AM
>> To: [email-masked]
>> Subject: Re: [woes] Proposed charter, post-Quebec edition
>>=20
>>=20
>> =46rom a Javascript dev perspective, specifying an algorithm=20
>> will make it a hell of of lot easier to implement, instead of=20
>> having to potentially account for multiples.
>>=20
>> Lets use the example of a web app that aggregates social=20
>> media data - just for giggles - and uses WOES to secure the=20
>> communications to well-defined interfaces
>>=20
>> If multiple vendors' websites implement WOES/JOES/JOSE with=20
>> different algorithms, it becomes more complex vs a single,=20
>> consistent one.
>>=20
>>=20
>>=20
>>=20
>> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
>>=20
>>> So I'll bite on this ;)
>>>=20
>>> I think we can write the spec to require a particular=20
>> algorithm choice, but it might make more sense to define the=20
>> options and then allow the environment in which the solution=20
>> will be used to specify it's requirements.  But, I believe=20
>> that is a discussion we'll have while writing the spec.
>>>=20
>>> spt
>>>=20
>>> On 8/4/11 9:29 AM, John Bradley wrote:
>>>> HMAC is requirement for adoption in the JWS use cases.
>>>>=20
>>>> If we want to describe it as something other than a=20
>> "Qualified Digital
>>>> Signature", that is fine as long as it is MTI:)
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>>=20
>>>>>   On 8/2/11 7:13 PM, Paul Hoffman wrote:
>>>>>=20
>>>>>       Here is a proposal for the charter based on the=20
>> discussion in
>>>>>       the BoF last week and later discussion with Sean Turner.
>>>>>       Comments, praise, scorn, etc., are welcome.
>>>>>=20
>>>>>       --Paul and Richard
>>>>>=20
>>>>>       Javascript Object Signing and Encrypting (jose)
>>>>>       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D__=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>>>>>=20
>>>>>       Background
>>>>>       ----------
>>>>>=20
>>>>>       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=20
>> the increased
>>>>>       usage of JSON in protocols in the IETF and=20
>> elsewhere, there is
>>>>>       now a desire to offer security services such as=20
>> encryption and
>>>>>       digital signatures for data that is being carried=20
>> in JSON format.
>>>>>=20
>>>>>       Different proposals for providing such security=20
>> services have
>>>>>       already been defined and implemented. This Working Group's
>>>>>       task is to standardize two security services,=20
>> encrypting and
>>>>>       digitally signing, in order to increase interoperability of
>>>>>       security features between protocols that use JSON.=20
>> The Working
>>>>>       Group will base its work on well-known message security
>>>>>       primitives (e.g., CMS), and will solicit input=20
>> from the rest
>>>>>       of the IETF Security Area to be sure that the security
>>>>>       functionality in the JSON format is correct.
>>>>>=20
>>>>>       This group is chartered to work on four documents:
>>>>>=20
>>>>>       1) A Standards Track document specifying how to apply a
>>>>>       JSON-structured digital signature to data,=20
>> including (but not
>>>>>       limited to) JSON data structures. "Digital signature" is
>>>>>       defined as a hash operation followed by a=20
>> signature operation
>>>>>       using asymmetric keys.
>>>>>=20
>>>>>=20
>>>>>   I just want to make sure that we agree now that a digital
>>>>>   signature is a hash followed by a signature algorithm=20
>> (e.g., RSA
>>>>>   with SHA-256). I've seen a couple of drafts that tried=20
>> to say an
>>>>>   HMAC (e.g., HMAC-SHA256) was a digital signature; one=20
>> called it a
>>>>>   symmetric key based digital signature algorithm (note=20
>> this phrase
>>>>>   didn't get through the IESG).
>>>>>=20
>>>>>=20
>>>>> An HMAC is not a digital signature, but the spec=20
>> definitely needs to
>>>>> be able to cover MAC based authentication.
>>>>>=20
>>>>>=20
>>>>> I know that public key is getting easier as far as=20
>> computation goes.
>>>>> But for many applications the non-repudiation you get in digital
>>>>> signatures is actually undesirable.
>>>>>=20
>>>>> There are interesting tricks you can do with symmetric=20
>> crypto that are
>>>>> much harder to do in public key and end up with some=20
>> scheme that only
>>>>> 50 academics in the world can follow and has a security proof that
>>>>> rest on rather esoteric assumptions.
>>>>>=20
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>>>=20
>>>>> _______________________________________________
>>>>> woes mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/woes
>>>>=20
>>> _______________________________________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/woes
>>=20
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_21BAFEBD-0FB8-4418-86E3-D7491350BDB3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_21BAFEBD-0FB8-4418-86E3-D7491350BDB3--

Date: Mon, 8 Aug 2011 11:28:46 -0700 (PDT)
From: Hal Lockhart <[email-masked]>
To: Jeremy Laurenson <[email-masked]>, [email-masked]
Subject: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

There seems to be a position forming around the idea that woes/joes/jose sh=
ould specify (perhaps even design) a single algorithm (perhaps one for sign=
 and one for encrypt). I presume that means that if in future it was necess=
ary to use a different algorithm we would just start over and write a new s=
pec.

I am not in favor of this, but I concede that it would simplify things in t=
his group a lot.

If there was only one algorithm, there is no need for any JSON metadata abo=
ut what the algorithm is being used.
All we need is a way to indicate what is signed or encrypted and something =
that says this is a JOES signature (or encryption) and perhaps some kind of=
 indication of what key was used.

If we were to specify only one algorithm, but provide metadata to indicate =
the algorithm, others will use additional, unspecified algorithms, just as =
people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 whi=
ch only includes DES.

I won't bother to list the many (many, many) reasons why a single algorithm=
 is unlikely to fly, unless it turns out a lot of people are really committ=
ed to that view.=20

Instead, I suggest we say explicitly say that multiple algorithms will be p=
ossible, but one will be MTI. It wouldn't hurt to also say we are not going=
 to design any new algorithms, but simply provide means to specify which ex=
isting one is being used.

Hal

> -----Original Message-----
> From: Jeremy Laurenson [mailto:[email-masked]]
> Sent: Saturday, August 06, 2011 12:31 AM
> To: [email-masked]
> Subject: Re: [woes] Proposed charter, post-Quebec edition
>=20
>=20
> From a Javascript dev perspective, specifying an algorithm=20
> will make it a hell of of lot easier to implement, instead of=20
> having to potentially account for multiples.
>=20
> Lets use the example of a web app that aggregates social=20
> media data - just for giggles - and uses WOES to secure the=20
> communications to well-defined interfaces
>=20
> If multiple vendors' websites implement WOES/JOES/JOSE with=20
> different algorithms, it becomes more complex vs a single,=20
> consistent one.
>=20
>=20
>=20
>=20
> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
>=20
> > So I'll bite on this ;)
> >=20
> > I think we can write the spec to require a particular=20
> algorithm choice, but it might make more sense to define the=20
> options and then allow the environment in which the solution=20
> will be used to specify it's requirements.  But, I believe=20
> that is a discussion we'll have while writing the spec.
> >=20
> > spt
> >=20
> > On 8/4/11 9:29 AM, John Bradley wrote:
> >> HMAC is requirement for adoption in the JWS use cases.
> >>=20
> >> If we want to describe it as something other than a=20
> "Qualified Digital
> >> Signature", that is fine as long as it is MTI:)
> >>=20
> >> John B.
> >>=20
> >>=20
> >> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
> >>=20
> >>>=20
> >>>=20
> >>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
> >>> <mailto:[email-masked]>> wrote:
> >>>=20
> >>>    On 8/2/11 7:13 PM, Paul Hoffman wrote:
> >>>=20
> >>>        Here is a proposal for the charter based on the=20
> discussion in
> >>>        the BoF last week and later discussion with Sean Turner.
> >>>        Comments, praise, scorn, etc., are welcome.
> >>>=20
> >>>        --Paul and Richard
> >>>=20
> >>>        Javascript Object Signing and Encrypting (jose)
> >>>        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D__=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
> >>>=20
> >>>        Background
> >>>        ----------
> >>>=20
> >>>        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=20
> the increased
> >>>        usage of JSON in protocols in the IETF and=20
> elsewhere, there is
> >>>        now a desire to offer security services such as=20
> encryption and
> >>>        digital signatures for data that is being carried=20
> in JSON format.
> >>>=20
> >>>        Different proposals for providing such security=20
> services have
> >>>        already been defined and implemented. This Working Group's
> >>>        task is to standardize two security services,=20
> encrypting and
> >>>        digitally signing, in order to increase interoperability of
> >>>        security features between protocols that use JSON.=20
> The Working
> >>>        Group will base its work on well-known message security
> >>>        primitives (e.g., CMS), and will solicit input=20
> from the rest
> >>>        of the IETF Security Area to be sure that the security
> >>>        functionality in the JSON format is correct.
> >>>=20
> >>>        This group is chartered to work on four documents:
> >>>=20
> >>>        1) A Standards Track document specifying how to apply a
> >>>        JSON-structured digital signature to data,=20
> including (but not
> >>>        limited to) JSON data structures. "Digital signature" is
> >>>        defined as a hash operation followed by a=20
> signature operation
> >>>        using asymmetric keys.
> >>>=20
> >>>=20
> >>>    I just want to make sure that we agree now that a digital
> >>>    signature is a hash followed by a signature algorithm=20
> (e.g., RSA
> >>>    with SHA-256). I've seen a couple of drafts that tried=20
> to say an
> >>>    HMAC (e.g., HMAC-SHA256) was a digital signature; one=20
> called it a
> >>>    symmetric key based digital signature algorithm (note=20
> this phrase
> >>>    didn't get through the IESG).
> >>>=20
> >>>=20
> >>> An HMAC is not a digital signature, but the spec=20
> definitely needs to
> >>> be able to cover MAC based authentication.
> >>>=20
> >>>=20
> >>> I know that public key is getting easier as far as=20
> computation goes.
> >>> But for many applications the non-repudiation you get in digital
> >>> signatures is actually undesirable.
> >>>=20
> >>> There are interesting tricks you can do with symmetric=20
> crypto that are
> >>> much harder to do in public key and end up with some=20
> scheme that only
> >>> 50 academics in the world can follow and has a security proof that
> >>> rest on rather esoteric assumptions.
> >>>=20
> >>> --
> >>> Website: http://hallambaker.com/
> >>>=20
> >>> _______________________________________________
> >>> woes mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/woes
> >>=20
> > _______________________________________________
> > woes mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/woes
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

Date: Mon, 8 Aug 2011 11:07:23 -0700 (PDT)
From: Hal Lockhart <[email-masked]>
To: "Paul C. Bryan" <[email-masked]>, [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--__131282684526824645abhmt112.oracle.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think people are reading more into my comment about raw keys than I said.

The specific historical use case was that we needed to verify a signature w=
ith a specific PK. There was no certificate chain, no PKI processing of any=
 kind required. The key was explicitly trusted. Revocation was out of scope=
. Therefore we (SAML TC) decided to specify the use of a PK as a binary val=
ue, not imbedded in a cert.=20

When implementations were done, it was discovered that common libraries, Op=
enSSL for example, expected the key to be contained in something that looke=
d like an ASN.1 formatted certificate. It would not accept a binary value. =
In order to use such a library, it was necessary to gin up an ASN.1 certifi=
cate structure and stuff in the key value, simply to comply with the requir=
ements of the method signature.

I am not talking about doing PKI. I am not talking about doing X.509. I am =
not talking about processing any other part of the cert except the PK.

I am talking about defining something that is practical to implement. I agr=
ee with those who believe both forms should be specified.=20

There seems to be a distinct argument about the generality of the spec, whi=
ch I will address in a separate message.

Hal
  -----Original Message-----
  From: Paul C. Bryan [mailto:[email-masked]]
  Sent: Monday, August 08, 2011 1:09 PM
  To: [email-masked]
  Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Que=
bec edition

  On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote:=20
On 8/8/11 8:36 AM, Hal Lockhart wrote:
>
> I am with Eric here. I would like to explicitly state that I think it
> is NOT desirable to do anything which encourages people to do new
> implementations of crypto operations. The corollary is that the spec
> should specify objects in formats which make them easy to be passed
> as arguments to existing libraries, especially libraries which are
> likely to be present in the target environment.

I think this may miss some important use cases. We're using JWT/JWS at=20
https://browserid.org, and we need to do all of the crypto in=20
JavaScript. JavaScript-based crypto, and crypto in other programming=20
languages in general, is likely to be a growing need. So, "no new=20
implementations" is unrealistic. There will be new implementations.=20
There have to be.
I think the point is that one should use existing, proven software librarie=
s to implement the cryptography wherever possible=E2=80=94JOSE should not n=
ecessitate a novel application of cryptography to achieve the charter objec=
tives. If no such library exists in a particular programming/runtime enviro=
nment, then obviously one would need to be developed. That said, I would su=
ggest that such a new implementation focus on implementing the cryptographi=
c functions much the way they are implemented in other environments, and al=
low JOSE implementations to build upon that.=20

If we force these new implementations to bear the full complexity of=20
X.509, then we're introducing security risk. It would be much better if=20
we had a simpler, JSON-focused certificate format.

We don't get to choose whether there will be new implementations. We=20
only get to choose how simple those have to be.

-Ben
_______________________________________________
woes mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/woes

--__131282684526824645abhmt112.oracle.com
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; CHARSET=UTF-8">
<META content="MSHTML 6.00.6000.17098" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff size=2>I 
think people are reading more into my comment about raw keys than I 
said.</FONT></SPAN></DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff size=2>The 
specific historical use case was that we needed to verify a signature with a 
specific PK. There was no certificate chain, no PKI processing of any kind 
required. The key was explicitly trusted. Revocation was out of scope. Therefore 
we (SAML TC) decided to specify the use of a PK as a binary value, not imbedded 
in a cert. </FONT></SPAN></DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff size=2>When 
implementations were done, it was discovered that common libraries, OpenSSL for 
example, expected the key to be contained in something that looked like an ASN.1 
formatted certificate. It would not accept a binary value. In order to use such 
a library, it was necessary to gin up an ASN.1 certificate structure and stuff 
in the key value, simply to comply with the requirements of the method 
signature.</FONT></SPAN></DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff size=2>I am 
not talking about doing PKI. I am not talking about doing X.509. I am not 
talking about processing any other part of the cert except the 
PK.</FONT></SPAN></DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff size=2>I am 
talking about defining something that is practical to implement. I agree with 
those who believe both forms should be specified. </FONT></SPAN></DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff size=2>There 
seems to be a distinct argument about the generality of the spec, which I will 
address in a separate message.</FONT></SPAN></DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=623085317-08082011><FONT face=Arial color=#0000ff 
size=2>Hal</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Paul C. Bryan 
  [mailto:[email-masked]]<BR><B>Sent:</B> Monday, August 08, 2011 1:09 
  PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re: [woes] Naked Public Key, 
  was: RE: Proposed charter, post-Quebec edition<BR><BR></FONT></DIV>On Mon, 
  2011-08-08 at 09:41 -0700, Ben Adida wrote: 
  <BLOCKQUOTE TYPE="CITE"><PRE>On 8/8/11 8:36 AM, Hal Lockhart wrote:
&gt;
&gt; I am with Eric here. I would like to explicitly state that I think it
&gt; is NOT desirable to do anything which encourages people to do new
&gt; implementations of crypto operations. The corollary is that the spec
&gt; should specify objects in formats which make them easy to be passed
&gt; as arguments to existing libraries, especially libraries which are
&gt; likely to be present in the target environment.

I think this may miss some important use cases. We're using JWT/JWS at 
<A href="https://browserid.org">https://browserid.org</A>, and we need to do all of the crypto in 
JavaScript. JavaScript-based crypto, and crypto in other programming 
languages in general, is likely to be a growing need. So, "no new 
implementations" is unrealistic. There will be new implementations. 
There have to be.
</PRE></BLOCKQUOTE>I think the point is that one should use existing, proven 
  software libraries to implement the cryptography wherever possible—JOSE should 
  not necessitate a novel application of cryptography to achieve the charter 
  objectives. If no such library exists in a particular programming/runtime 
  environment, then obviously one would need to be developed. That said, I would 
  suggest that such a new implementation focus on implementing the cryptographic 
  functions much the way they are implemented in other environments, and allow 
  JOSE implementations to build upon that. <BR><BR>
  <BLOCKQUOTE TYPE="CITE"><PRE>If we force these new implementations to bear the full complexity of 
X.509, then we're introducing security risk. It would be much better if 
we had a simpler, JSON-focused certificate format.

We don't get to choose whether there will be new implementations. We 
only get to choose how simple those have to be.

-Ben
_______________________________________________
woes mailing list
<A href="mailto:[email-masked]">[email-masked]</A>
<A href="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

--__131282684526824645abhmt112.oracle.com--

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 13:57:05 -0400
To: Ben Adida <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--Apple-Mail=_889604BA-A29C-4043-9C6B-BB0F3EEF0759
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

That is a larger issue, that I prefer to leave for a later charter.

We both have specs (arguably competing ones) that require JOSE in a =
timely manner. =20

Tide and the Web wait for no SDO:)

John

On 2011-08-08, at 1:42 PM, Ben Adida wrote:

> On 8/8/11 10:38 AM, John Bradley wrote:
>> We just can't assume that it is trivial to reemployment PKIX X.509
>> processing in all new environments. Using public keys without PKIX, =
is a
>> simpler task.
>=20
> Exactly. And even the certificate format world could use a *much* =
simpler, more webby approach than X.509.
>=20
> -Ben
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_889604BA-A29C-4043-9C6B-BB0F3EEF0759
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_889604BA-A29C-4043-9C6B-BB0F3EEF0759--

Date: Mon, 08 Aug 2011 10:42:59 -0700
From: Ben Adida <[email-masked]>
To: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 8/8/11 10:38 AM, John Bradley wrote:
> We just can't assume that it is trivial to reemployment PKIX X.509
> processing in all new environments. Using public keys without PKIX, is a
> simpler task.

Exactly. And even the certificate format world could use a *much* 
simpler, more webby approach than X.509.

-Ben

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 13:38:03 -0400
To: "Paul C. Bryan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--Apple-Mail=_F1ED0488-305E-47F6-ACA2-320AE606F946
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FECC2141-93E2-42A6-AA71-9948010399F3"

--Apple-Mail=_FECC2141-93E2-42A6-AA71-9948010399F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

No argument on that.

We just can't assume that it is trivial to reemployment PKIX X.509 =
processing in all new environments.  Using public keys without PKIX, is =
a simpler task.

Where we need to develop new libraries, using establishd cryptographic =
methods should be the goal.

JWE/JWS had no intention of deviating from those norms and inventing new =
algorithms.

John B.
On 2011-08-08, at 1:09 PM, Paul C. Bryan wrote:

> On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote:
>>=20
>> On 8/8/11 8:36 AM, Hal Lockhart wrote:
>> >
>> > I am with Eric here. I would like to explicitly state that I think =
it
>> > is NOT desirable to do anything which encourages people to do new
>> > implementations of crypto operations. The corollary is that the =
spec
>> > should specify objects in formats which make them easy to be passed
>> > as arguments to existing libraries, especially libraries which are
>> > likely to be present in the target environment.
>>=20
>> I think this may miss some important use cases. We're using JWT/JWS =
at=20
>> https://browserid.org, and we need to do all of the crypto in=20
>> JavaScript. JavaScript-based crypto, and crypto in other programming=20=

>> languages in general, is likely to be a growing need. So, "no new=20
>> implementations" is unrealistic. There will be new implementations.=20=

>> There have to be.
> I think the point is that one should use existing, proven software =
libraries to implement the cryptography wherever possible=97JOSE should =
not necessitate a novel application of cryptography to achieve the =
charter objectives. If no such library exists in a particular =
programming/runtime environment, then obviously one would need to be =
developed. That said, I would suggest that such a new implementation =
focus on implementing the cryptographic functions much the way they are =
implemented in other environments, and allow JOSE implementations to =
build upon that.=20
>=20
>> If we force these new implementations to bear the full complexity of=20=

>> X.509, then we're introducing security risk. It would be much better =
if=20
>> we had a simpler, JSON-focused certificate format.
>>=20
>> We don't get to choose whether there will be new implementations. We=20=

>> only get to choose how simple those have to be.
>>=20
>> -Ben
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_FECC2141-93E2-42A6-AA71-9948010399F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">No =
argument on that.<div><br></div><div>We just can't assume that it is =
trivial to reemployment PKIX X.509 processing in all new environments. =
&nbsp;Using public keys without PKIX, is a simpler =
task.</div><div><br></div><div>Where we need to develop new libraries, =
using establishd cryptographic methods should be the =
goal.</div><div><br></div><div>JWE/JWS had no intention of deviating =
from those norms and inventing new =
algorithms.</div><div><br></div><div>John B.<br><div><div>On 2011-08-08, =
at 1:09 PM, Paul C. Bryan wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">

  <meta http-equiv=3D"Content-Type" content=3D"text/html; =
CHARSET=3DUTF-8">
  <meta name=3D"GENERATOR" content=3D"GtkHTML/3.30.3">

<div>
On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote:
<blockquote type=3D"CITE">
<pre>On 8/8/11 8:36 AM, Hal Lockhart wrote:
&gt;
&gt; I am with Eric here. I would like to explicitly state that I think =
it
&gt; is NOT desirable to do anything which encourages people to do new
&gt; implementations of crypto operations. The corollary is that the =
spec
&gt; should specify objects in formats which make them easy to be passed
&gt; as arguments to existing libraries, especially libraries which are
&gt; likely to be present in the target environment.

I think this may miss some important use cases. We're using JWT/JWS at=20=

<a href=3D"https://browserid.org/">https://browserid.org</a>, and we =
need to do all of the crypto in=20
JavaScript. JavaScript-based crypto, and crypto in other programming=20
languages in general, is likely to be a growing need. So, "no new=20
implementations" is unrealistic. There will be new implementations.=20
There have to be.
</pre>
</blockquote>
I think the point is that one should use existing, proven software =
libraries to implement the cryptography wherever possible=97JOSE should =
not necessitate a novel application of cryptography to achieve the =
charter objectives. If no such library exists in a particular =
programming/runtime environment, then obviously one would need to be =
developed. That said, I would suggest that such a new implementation =
focus on implementing the cryptographic functions much the way they are =
implemented in other environments, and allow JOSE implementations to =
build upon that. <br>
<br>
<blockquote type=3D"CITE">
<pre>If we force these new implementations to bear the full complexity =
of=20
X.509, then we're introducing security risk. It would be much better if=20=

we had a simpler, JSON-focused certificate format.

We don't get to choose whether there will be new implementations. We=20
only get to choose how simple those have to be.

-Ben
_______________________________________________
woes mailing list
<a href=3D"mailto:[email-masked]">[email-masked]</a>
<a =
href=3D"https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/m=
ailman/listinfo/woes</a>
</pre>
</blockquote>
<br>
</div>

_______________________________________________<br>woes mailing =
list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/ma=
ilman/listinfo/woes<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_FECC2141-93E2-42A6-AA71-9948010399F3--

--Apple-Mail=_F1ED0488-305E-47F6-ACA2-320AE606F946
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_F1ED0488-305E-47F6-ACA2-320AE606F946--

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 08 Aug 2011 10:09:24 -0700
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--=-gSZmC/xeaJPa9sNDMyYL
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote:

> On 8/8/11 8:36 AM, Hal Lockhart wrote:
> >
> > I am with Eric here. I would like to explicitly state that I think it
> > is NOT desirable to do anything which encourages people to do new
> > implementations of crypto operations. The corollary is that the spec
> > should specify objects in formats which make them easy to be passed
> > as arguments to existing libraries, especially libraries which are
> > likely to be present in the target environment.
> 
> I think this may miss some important use cases. We're using JWT/JWS at 
> https://browserid.org, and we need to do all of the crypto in 
> JavaScript. JavaScript-based crypto, and crypto in other programming 
> languages in general, is likely to be a growing need. So, "no new 
> implementations" is unrealistic. There will be new implementations. 
> There have to be.

I think the point is that one should use existing, proven software
libraries to implement the cryptography wherever possible—JOSE should
not necessitate a novel application of cryptography to achieve the
charter objectives. If no such library exists in a particular
programming/runtime environment, then obviously one would need to be
developed. That said, I would suggest that such a new implementation
focus on implementing the cryptographic functions much the way they are
implemented in other environments, and allow JOSE implementations to
build upon that. 

> If we force these new implementations to bear the full complexity of 
> X.509, then we're introducing security risk. It would be much better if 
> we had a simpler, JSON-focused certificate format.
> 
> We don't get to choose whether there will be new implementations. We 
> only get to choose how simple those have to be.
> 
> -Ben
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--=-gSZmC/xeaJPa9sNDMyYL
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
On Mon, 2011-08-08 at 09:41 -0700, Ben Adida wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 8/8/11 8:36 AM, Hal Lockhart wrote:
&gt;
&gt; I am with Eric here. I would like to explicitly state that I think it
&gt; is NOT desirable to do anything which encourages people to do new
&gt; implementations of crypto operations. The corollary is that the spec
&gt; should specify objects in formats which make them easy to be passed
&gt; as arguments to existing libraries, especially libraries which are
&gt; likely to be present in the target environment.

I think this may miss some important use cases. We're using JWT/JWS at 
<A HREF="https://browserid.org">https://browserid.org</A>, and we need to do all of the crypto in 
JavaScript. JavaScript-based crypto, and crypto in other programming 
languages in general, is likely to be a growing need. So, &quot;no new 
implementations&quot; is unrealistic. There will be new implementations. 
There have to be.
</PRE>
</BLOCKQUOTE>
I think the point is that one should use existing, proven software libraries to implement the cryptography wherever possible&#8212;JOSE should not necessitate a novel application of cryptography to achieve the charter objectives. If no such library exists in a particular programming/runtime environment, then obviously one would need to be developed. That said, I would suggest that such a new implementation focus on implementing the cryptographic functions much the way they are implemented in other environments, and allow JOSE implementations to build upon that. <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
If we force these new implementations to bear the full complexity of 
X.509, then we're introducing security risk. It would be much better if 
we had a simpler, JSON-focused certificate format.

We don't get to choose whether there will be new implementations. We 
only get to choose how simple those have to be.

-Ben
_______________________________________________
woes mailing list
<A HREF="mailto:[email-masked]">[email-masked]</A>
<A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>

--=-gSZmC/xeaJPa9sNDMyYL--

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 13:07:40 -0400
To: Ben Adida <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--Apple-Mail=_FCDBA439-571B-4FA2-A0E1-60FD69A816F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1  For openID Connect forcing x.509 processing in all environments is =
not practical, or desirable.

Not all environments can call out to openSSL.  We will need to create =
new native libraries for some environments.  Having a simple JSON =
container for key information is important to our developers.

John Bradley
On 2011-08-08, at 12:41 PM, Ben Adida wrote:

> On 8/8/11 8:36 AM, Hal Lockhart wrote:
>>=20
>> I am with Eric here. I would like to explicitly state that I think it
>> is NOT desirable to do anything which encourages people to do new
>> implementations of crypto operations. The corollary is that the spec
>> should specify objects in formats which make them easy to be passed
>> as arguments to existing libraries, especially libraries which are
>> likely to be present in the target environment.
>=20
> I think this may miss some important use cases. We're using JWT/JWS at =
https://browserid.org, and we need to do all of the crypto in =
JavaScript. JavaScript-based crypto, and crypto in other programming =
languages in general, is likely to be a growing need. So, "no new =
implementations" is unrealistic. There will be new implementations. =
There have to be.
>=20
> If we force these new implementations to bear the full complexity of =
X.509, then we're introducing security risk. It would be much better if =
we had a simpler, JSON-focused certificate format.
>=20
> We don't get to choose whether there will be new implementations. We =
only get to choose how simple those have to be.
>=20
> -Ben
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_FCDBA439-571B-4FA2-A0E1-60FD69A816F9
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_FCDBA439-571B-4FA2-A0E1-60FD69A816F9--

Date: Mon, 08 Aug 2011 09:41:48 -0700
From: Ben Adida <[email-masked]>
To: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 8/8/11 8:36 AM, Hal Lockhart wrote:
>
> I am with Eric here. I would like to explicitly state that I think it
> is NOT desirable to do anything which encourages people to do new
> implementations of crypto operations. The corollary is that the spec
> should specify objects in formats which make them easy to be passed
> as arguments to existing libraries, especially libraries which are
> likely to be present in the target environment.

I think this may miss some important use cases. We're using JWT/JWS at 
https://browserid.org, and we need to do all of the crypto in 
JavaScript. JavaScript-based crypto, and crypto in other programming 
languages in general, is likely to be a growing need. So, "no new 
implementations" is unrealistic. There will be new implementations. 
There have to be.

If we force these new implementations to bear the full complexity of 
X.509, then we're introducing security risk. It would be much better if 
we had a simpler, JSON-focused certificate format.

We don't get to choose whether there will be new implementations. We 
only get to choose how simple those have to be.

-Ben

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 08 Aug 2011 09:02:24 -0700
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--=-csXRWkCdChWLQmyeCmqs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2011-08-08 at 08:36 -0700, Hal Lockhart wrote:

> I would like to explicitly state that I think it is NOT desirable to
> do anything which encourages people to do new implementations of
> crypto operations. The corollary is that the spec should specify
> objects in formats which make them easy to be passed as arguments to
> existing libraries, especially libraries which are likely to be
> present in the target environment.

+1

Paul

--=-csXRWkCdChWLQmyeCmqs
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
On Mon, 2011-08-08 at 08:36 -0700, Hal Lockhart wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    I would like to explicitly state that I think it is NOT desirable to do anything which encourages people to do new implementations of crypto operations. The corollary is that the spec should specify objects in formats which make them easy to be passed as arguments to existing libraries, especially libraries which are likely to be present in the target environment.<BR>
</BLOCKQUOTE>
<BR>
+1<BR>
<BR>
Paul
</BODY>
</HTML>

--=-csXRWkCdChWLQmyeCmqs--

Date: Mon, 8 Aug 2011 08:36:02 -0700 (PDT)
From: Hal Lockhart <[email-masked]>
To: Eric Rescorla <[email-masked]>, Joe Hildebrand <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

Hal:
> >> I would like to push back on the idea of only supporting=20
> naked public keys. It
> >> is my understanding that common cryto libraries, e.g.=20
> OpenSSL, expect public
> >> keys to be in certificates and the coding to get them to=20
> accept a naked key as
> >> input is ugly. I don't think they care if the cert is self=20
> signed or even
> >> signed at all, its just a format issue.

Joe:
> > Just doing the math yourself, from scratch, is pretty easy=20
> if you have the
> > bare key. =A0It's nigh-on trivial if you have a bigint=20
> library. =A0Solution:
> > don't use OpenSSL. =A0I propose we don't get bogged down in=20
> the certificate
> > problem for the moment.

Eric:
> Cryptographer's warning: do not do this. Hard hat area ahead.

I am with Eric here. I would like to explicitly state that I think it is NO=
T desirable to do anything which encourages people to do new implementation=
s of crypto operations. The corollary is that the spec should specify objec=
ts in formats which make them easy to be passed as arguments to existing li=
braries, especially libraries which are likely to be present in the target =
environment.

Hal

Date: Mon, 8 Aug 2011 08:28:04 -0700 (PDT)
From: Hal Lockhart <[email-masked]>
To: Sean Turner <[email-masked]>, [email-masked]
Cc: Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

Given the state of the art in integrity protection is in flux (e.g. new att=
acks, authenticated encryption modes) it seems foolish to limit integrity p=
rotection to two specific technologies.

Although there may be no intent to cover anything more than asymmetric key =
signatures and HMACs during the initial phase, the JSON metadata should be =
capable of representing other, present and future methods, at least to the =
extent we currently understand their requirements.

Hal

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Friday, August 05, 2011 2:45 PM
> To: [email-masked]
> Cc: Hal Lockhart; Paul Hoffman; Eric Rescorla
> Subject: Re: [woes] Proposed charter, post-Quebec edition
>=20
>=20
> On 8/4/11 4:41 PM, Hal Lockhart wrote:
> > +1
> >
> >> -----Original Message-----
> >> From: Paul Hoffman [mailto:[email-masked]]
> >> Sent: Thursday, August 04, 2011 12:03 PM
> >> To: Eric Rescorla
> >> Cc: [email-masked]
> >> Subject: Re: [woes] Proposed charter, post-Quebec edition
> >>
> >>
> >>
> >> On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
> >>
> >>> IMO, symmetric integrity protection is a useful=20
> primitive, and it's
> >>> already part of the
> >>> JWT spec. I think all that's required here in the charter is to
> >>> wordsmith it to separate
> >>> out symmetric from asymmetric integrity algorithms,
> >>
> >> Current:
> >> 1) A Standards Track document specifying how to apply a
> >> JSON-structured digital signature to data, including (but not
> >> limited to) JSON data structures. "Digital signature" is
> >> defined as a hash operation followed by a signature operation
> >> using asymmetric keys.
> >>
> >> It sounds like you would prefer something like:
> >> 1) A Standards Track document specifying how to apply
> >> integrity protection to data, including (but not limited to)
> >> JSON data structures. This integrity protection can be
> >> achieved with both symmetric and asymmetric algorithms.
> >>
> >> Is that right?
>=20
> I'm liking what Paul B. suggested but tweaked ever so slightly:
>=20
> 1) A Standards Track document specifying how to ensure the integrity=20
> and/or authenticity of data, including (but not limited to) JSON data=20
> structures.  HMAC-based (RFC 2104) and Asymmetric cryptographic=20
> algorithms both need to be supported.
>=20
> I'd like to not just call out integrity - and we should just call out=20
> the HMAC-based algs because that's what folks really want to use (or=20
> have I gotten this wrong?).
>=20
> Any violent objections to this?
>=20
> spt
>

Date: Sun, 07 Aug 2011 11:59:18 +0200
From: Leif Johansson <[email-masked]>
To: Joe Hildebrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 08/06/2011 07:30 PM, Joe Hildebrand wrote:
> On 8/6/11 7:43 AM, "Leif Johansson" <[email-masked]> wrote:
> 
>> So in that case I still support having the spec explain (very carefully)
>> how you do "raw keys" - i.e keys with no intrinsic semantics - and then
>> also adding the cryptographers caveat to that.
> 
> To be clear, when I was talking about raw keys, I didn't mean keys with no
> intrinsic semantics.  I just meant something along the lines of PKCS1; a
> modulus, an exponent, some algorithm info, and that's about it (I'd be ok
> with defining private keys in the same format as well).  It would have
> defined semantic, it just wouldn't be tied to an identity.

OK that was more or less what I was trying to say aswell.

> 
> A definite goal for me that is NOT met by PKCS1 however, is to *limit* the
> choices and extensibility in certain directions to reduce the overall
> complexity.
> 
> Of course, once you've got primitives for sign and encrypt and you've got a
> key format, doing something like PKIX is possible.  Perhaps we could sketch
> that out as potential follow-on work in the charter, so we can make progress
> on some of the shorter-term stuff first?
> 

indeed

	Cheers Leif

From: John Bradley <[email-masked]>
Date: Sat, 6 Aug 2011 16:40:04 -0400
To: Joe Hildebrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

Short term stuff first.=20

Boil ocean stage 2.=20

Replacing PKIX may be a noble goal,  but is out of scope for phase 1.=20

John B.=20

Sent from my iPhone

On 2011-08-06, at 1:30 PM, Joe Hildebrand <[email-masked]> wrote:

> On 8/6/11 7:43 AM, "Leif Johansson" <[email-masked]> wrote:
>=20
>> So in that case I still support having the spec explain (very carefully)
>> how you do "raw keys" - i.e keys with no intrinsic semantics - and then
>> also adding the cryptographers caveat to that.
>=20
> To be clear, when I was talking about raw keys, I didn't mean keys with no=

> intrinsic semantics.  I just meant something along the lines of PKCS1; a
> modulus, an exponent, some algorithm info, and that's about it (I'd be ok
> with defining private keys in the same format as well).  It would have
> defined semantic, it just wouldn't be tied to an identity.
>=20
> A definite goal for me that is NOT met by PKCS1 however, is to *limit* the=

> choices and extensibility in certain directions to reduce the overall
> complexity.
>=20
> Of course, once you've got primitives for sign and encrypt and you've got a=

> key format, doing something like PKIX is possible.  Perhaps we could sketc=
h
> that out as potential follow-on work in the charter, so we can make progre=
ss
> on some of the shorter-term stuff first?
>=20
> --=20
> Joe Hildebrand
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

Date: Sat, 06 Aug 2011 13:30:08 -0400
From: Joe Hildebrand <[email-masked]>
To: Leif Johansson <[email-masked]>, Eric Rescorla <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 8/6/11 7:43 AM, "Leif Johansson" <[email-masked]> wrote:

> So in that case I still support having the spec explain (very carefully)
> how you do "raw keys" - i.e keys with no intrinsic semantics - and then
> also adding the cryptographers caveat to that.

To be clear, when I was talking about raw keys, I didn't mean keys with no
intrinsic semantics.  I just meant something along the lines of PKCS1; a
modulus, an exponent, some algorithm info, and that's about it (I'd be ok
with defining private keys in the same format as well).  It would have
defined semantic, it just wouldn't be tied to an identity.

A definite goal for me that is NOT met by PKCS1 however, is to *limit* the
choices and extensibility in certain directions to reduce the overall
complexity.

Of course, once you've got primitives for sign and encrypt and you've got a
key format, doing something like PKIX is possible.  Perhaps we could sketch
that out as potential follow-on work in the charter, so we can make progress
on some of the shorter-term stuff first?

-- 
Joe Hildebrand

Date: Sat, 6 Aug 2011 10:58:47 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--001636c5bbf379591904a9d773c1
Content-Type: text/plain; charset=ISO-8859-1

How about one spec with two implementation profiles?

WOES-P  MUST implement PKIX key handling.
WOES-R  MUST implement raw key handling.

The reason I think we need both is that the WOES-R mechanism is going to be
much more appropriate for the applications for which self-signed certs are
generally used.

[I really can't see what benefit a self signed cert provides over a raw key
for any application. All you have is proof that the holder of the key
created a self-signed cert.]

So in my application I am going to want a stack that supports certs for the
Internet trust aspects and a stack that supports raw key for the handheld
device aspects. I don't want to implement the raw key in the Internet
request side of things and I definitely don't want to implement the cert
stuff in the handheld device. Mobile phones come with PKIX libraries but
thermocouple driver chips don't .

--001636c5bbf379591904a9d773c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

How about one spec with two implementation profiles?
<div><br></div><div>WOES-P =A0MUST implement PKIX key handling.</div><div>W=
OES-R =A0MUST implement raw key handling.</div><div><br></div><div>The reas=
on I think we need both is that the WOES-R mechanism is going to be much mo=
re appropriate for the applications for which self-signed certs are general=
ly used.</div>
<div><br></div><div>[I really can&#39;t see what benefit a self signed cert=
 provides over a raw key for any application. All you have is proof that th=
e holder of the key created a self-signed cert.]</div><div><br></div><div>
<br></div><div>So in my application I am going to want a stack that support=
s certs for the Internet trust aspects and a stack that supports raw key fo=
r the handheld device aspects. I don&#39;t want to implement the raw key in=
 the Internet request side of things and I definitely don&#39;t want to imp=
lement the cert stuff in the handheld device. Mobile phones come with PKIX =
libraries but thermocouple driver chips don&#39;t .</div>

--001636c5bbf379591904a9d773c1--

Date: Sat, 6 Aug 2011 10:05:16 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Jeremy Laurenson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

--00163691ff511a529404a9d6b42d
Content-Type: text/plain; charset=ISO-8859-1

We absolutely need to make a choice on algorithms.

What I am saying is that I would like to make the choice once every three
years or so as an IETF-wide issue and not have to revisit it in every new WG
and have each WG go through the same discussion.

On Sat, Aug 6, 2011 at 12:30 AM, Jeremy Laurenson <[email-masked]>wrote:

> From a Javascript dev perspective, specifying an algorithm will make it a
> hell of of lot easier to implement, instead of having to potentially account
> for multiples.
>
> Lets use the example of a web app that aggregates social media data - just
> for giggles - and uses WOES to secure the communications to well-defined
> interfaces
>
> If multiple vendors' websites implement WOES/JOES/JOSE with different
> algorithms, it becomes more complex vs a single, consistent one.
>
>
>
>
> On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:
>
> > So I'll bite on this ;)
> >
> > I think we can write the spec to require a particular algorithm choice,
> but it might make more sense to define the options and then allow the
> environment in which the solution will be used to specify it's requirements.
>  But, I believe that is a discussion we'll have while writing the spec.
> >
> > spt
> >
> > On 8/4/11 9:29 AM, John Bradley wrote:
> >> HMAC is requirement for adoption in the JWS use cases.
> >>
> >> If we want to describe it as something other than a "Qualified Digital
> >> Signature", that is fine as long as it is MTI:)
> >>
> >> John B.
> >>
> >>
> >> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
> >>
> >>>
> >>>
> >>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
> >>> <mailto:[email-masked]>> wrote:
> >>>
> >>>    On 8/2/11 7:13 PM, Paul Hoffman wrote:
> >>>
> >>>        Here is a proposal for the charter based on the discussion in
> >>>        the BoF last week and later discussion with Sean Turner.
> >>>        Comments, praise, scorn, etc., are welcome.
> >>>
> >>>        --Paul and Richard
> >>>
> >>>        Javascript Object Signing and Encrypting (jose)
> >>>        ==============================__=================
> >>>
> >>>        Background
> >>>        ----------
> >>>
> >>>        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 and
> >>>        digital signatures 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 two security services, encrypting and
> >>>        digitally signing, 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 four documents:
> >>>
> >>>        1) A Standards Track document specifying how to apply a
> >>>        JSON-structured digital signature to data, including (but not
> >>>        limited to) JSON data structures. "Digital signature" is
> >>>        defined as a hash operation followed by a signature operation
> >>>        using asymmetric keys.
> >>>
> >>>
> >>>    I just want to make sure that we agree now that a digital
> >>>    signature is a hash followed by a signature algorithm (e.g., RSA
> >>>    with SHA-256). I've seen a couple of drafts that tried to say an
> >>>    HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a
> >>>    symmetric key based digital signature algorithm (note this phrase
> >>>    didn't get through the IESG).
> >>>
> >>>
> >>> An HMAC is not a digital signature, but the spec definitely needs to
> >>> be able to cover MAC based authentication.
> >>>
> >>>
> >>> I know that public key is getting easier as far as computation goes.
> >>> But for many applications the non-repudiation you get in digital
> >>> signatures is actually undesirable.
> >>>
> >>> There are interesting tricks you can do with symmetric crypto that are
> >>> much harder to do in public key and end up with some scheme that only
> >>> 50 academics in the world can follow and has a security proof that
> >>> rest on rather esoteric assumptions.
> >>>
> >>> --
> >>> Website: http://hallambaker.com/
> >>>
> >>> _______________________________________________
> >>> woes mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/woes
> >>
> > _______________________________________________
> > woes mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/woes
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

-- 
Website: http://hallambaker.com/

--00163691ff511a529404a9d6b42d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We absolutely need to make a choice on algorithms.<div><br></div><div>What =
I am saying is that I would like to make the choice once every three years =
or so as an IETF-wide issue and not have to revisit it in every new WG and =
have each WG go through the same discussion.<br>
<br><div class=3D"gmail_quote">On Sat, Aug 6, 2011 at 12:30 AM, Jeremy Laur=
enson <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">jlaurens@=
cisco.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
>From a Javascript dev perspective, specifying an algorithm will make it a h=
ell of of lot easier to implement, instead of having to potentially account=
 for multiples.<br>
<br>
Lets use the example of a web app that aggregates social media data - just =
for giggles - and uses WOES to secure the communications to well-defined in=
terfaces<br>
<br>
If multiple vendors&#39; websites implement WOES/JOES/JOSE with different a=
lgorithms, it becomes more complex vs a single, consistent one.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:<br>
<br>
&gt; So I&#39;ll bite on this ;)<br>
&gt;<br>
&gt; I think we can write the spec to require a particular algorithm choice=
, but it might make more sense to define the options and then allow the env=
ironment in which the solution will be used to specify it&#39;s requirement=
s. =A0But, I believe that is a discussion we&#39;ll have while writing the =
spec.<br>

&gt;<br>
&gt; spt<br>
&gt;<br>
&gt; On 8/4/11 9:29 AM, John Bradley wrote:<br>
&gt;&gt; HMAC is requirement for adoption in the JWS use cases.<br>
&gt;&gt;<br>
&gt;&gt; If we want to describe it as something other than a &quot;Qualifie=
d Digital<br>
&gt;&gt; Signature&quot;, that is fine as long as it is MTI:)<br>
&gt;&gt;<br>
&gt;&gt; John B.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner &lt;<a href=3D"mai=
lto:[email-masked]">[email-masked]</a><br>
&gt;&gt;&gt; &lt;mailto:<a href=3D"mailto:[email-masked]">[email-masked]=
m</a>&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0On 8/2/11 7:13 PM, Paul Hoffman wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Here is a proposal for the charter based on the=
 discussion in<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0the BoF last week and later discussion with Sea=
n Turner.<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Comments, praise, scorn, etc., are welcome.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0--Paul and Richard<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Javascript Object Signing and Encrypting (jose)=
<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D__=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Background<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0----------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Javascript Object Notation (JSON) is a text for=
mat for the<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0serialization of structured data described in R=
FC 4627. The<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0JSON format is often used for serializing and t=
ransmitting<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0structured data over a network connection. With=
 the increased<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0usage of JSON in protocols in the IETF and else=
where, there is<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0now a desire to offer security services such as=
 encryption and<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0digital signatures for data that is being carri=
ed in JSON format.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Different proposals for providing such security=
 services have<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0already been defined and implemented. This Work=
ing Group&#39;s<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0task is to standardize two security services, e=
ncrypting and<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0digitally signing, in order to increase interop=
erability of<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0security features between protocols that use JS=
ON. The Working<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0Group will base its work on well-known message =
security<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0primitives (e.g., CMS), and will solicit input =
from the rest<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0of the IETF Security Area to be sure that the s=
ecurity<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0functionality in the JSON format is correct.<br=
>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0This group is chartered to work on four documen=
ts:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A01) A Standards Track document specifying how to=
 apply a<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0JSON-structured digital signature to data, incl=
uding (but not<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0limited to) JSON data structures. &quot;Digital=
 signature&quot; is<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0defined as a hash operation followed by a signa=
ture operation<br>
&gt;&gt;&gt; =A0 =A0 =A0 =A0using asymmetric keys.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0I just want to make sure that we agree now that a digit=
al<br>
&gt;&gt;&gt; =A0 =A0signature is a hash followed by a signature algorithm (=
e.g., RSA<br>
&gt;&gt;&gt; =A0 =A0with SHA-256). I&#39;ve seen a couple of drafts that tr=
ied to say an<br>
&gt;&gt;&gt; =A0 =A0HMAC (e.g., HMAC-SHA256) was a digital signature; one c=
alled it a<br>
&gt;&gt;&gt; =A0 =A0symmetric key based digital signature algorithm (note t=
his phrase<br>
&gt;&gt;&gt; =A0 =A0didn&#39;t get through the IESG).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; An HMAC is not a digital signature, but the spec definitely ne=
eds to<br>
&gt;&gt;&gt; be able to cover MAC based authentication.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I know that public key is getting easier as far as computation=
 goes.<br>
&gt;&gt;&gt; But for many applications the non-repudiation you get in digit=
al<br>
&gt;&gt;&gt; signatures is actually undesirable.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There are interesting tricks you can do with symmetric crypto =
that are<br>
&gt;&gt;&gt; much harder to do in public key and end up with some scheme th=
at only<br>
&gt;&gt;&gt; 50 academics in the world can follow and has a security proof =
that<br>
&gt;&gt;&gt; rest on rather esoteric assumptions.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank"=
>http://hallambaker.com/</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; woes mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a> &lt;mailto:=
<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/woes</a><br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; woes mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/woes</a><br>
<br>
_______________________________________________<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/woes</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--00163691ff511a529404a9d6b42d--

Date: Sat, 06 Aug 2011 13:43:12 +0200
From: Leif Johansson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 08/05/2011 06:43 PM, Eric Rescorla wrote:
> On Fri, Aug 5, 2011 at 7:42 AM, Leif Johansson <[email-masked]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>>> Just doing the math yourself, from scratch, is pretty easy if you have the
>>>> bare key.  It's nigh-on trivial if you have a bigint library.  Solution:
>>>> don't use OpenSSL.  I propose we don't get bogged down in the certificate
>>>> problem for the moment.
>>>
>>> Cryptographer's warning: do not do this. Hard hat area ahead.
>>>
>>
>> That is advice for implementors and not for spec writers, right?
> 
> Correct. Getting the implementation right is tricky.

So in that case I still support having the spec explain (very carefully)
how you do "raw keys" - i.e keys with no intrinsic semantics - and then
also adding the cryptographers caveat to that.

	Cheers Leif

From: Jeremy Laurenson <[email-masked]>
Date: Sat, 6 Aug 2011 00:30:43 -0400
To: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

=46rom a Javascript dev perspective, specifying an algorithm will make =
it a hell of of lot easier to implement, instead of having to =
potentially account for multiples.

Lets use the example of a web app that aggregates social media data - =
just for giggles - and uses WOES to secure the communications to =
well-defined interfaces

If multiple vendors' websites implement WOES/JOES/JOSE with different =
algorithms, it becomes more complex vs a single, consistent one.

On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:

> So I'll bite on this ;)
>=20
> I think we can write the spec to require a particular algorithm =
choice, but it might make more sense to define the options and then =
allow the environment in which the solution will be used to specify it's =
requirements.  But, I believe that is a discussion we'll have while =
writing the spec.
>=20
> spt
>=20
> On 8/4/11 9:29 AM, John Bradley wrote:
>> HMAC is requirement for adoption in the JWS use cases.
>>=20
>> If we want to describe it as something other than a "Qualified =
Digital
>> Signature", that is fine as long as it is MTI:)
>>=20
>> John B.
>>=20
>>=20
>> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>>=20
>>>=20
>>>=20
>>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>=20
>>>    On 8/2/11 7:13 PM, Paul Hoffman wrote:
>>>=20
>>>        Here is a proposal for the charter based on the discussion in
>>>        the BoF last week and later discussion with Sean Turner.
>>>        Comments, praise, scorn, etc., are welcome.
>>>=20
>>>        --Paul and Richard
>>>=20
>>>        Javascript Object Signing and Encrypting (jose)
>>>        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D__=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>>>=20
>>>        Background
>>>        ----------
>>>=20
>>>        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 =
and
>>>        digital signatures for data that is being carried in JSON =
format.
>>>=20
>>>        Different proposals for providing such security services have
>>>        already been defined and implemented. This Working Group's
>>>        task is to standardize two security services, encrypting and
>>>        digitally signing, 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.
>>>=20
>>>        This group is chartered to work on four documents:
>>>=20
>>>        1) A Standards Track document specifying how to apply a
>>>        JSON-structured digital signature to data, including (but not
>>>        limited to) JSON data structures. "Digital signature" is
>>>        defined as a hash operation followed by a signature operation
>>>        using asymmetric keys.
>>>=20
>>>=20
>>>    I just want to make sure that we agree now that a digital
>>>    signature is a hash followed by a signature algorithm (e.g., RSA
>>>    with SHA-256). I've seen a couple of drafts that tried to say an
>>>    HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a
>>>    symmetric key based digital signature algorithm (note this phrase
>>>    didn't get through the IESG).
>>>=20
>>>=20
>>> An HMAC is not a digital signature, but the spec definitely needs to
>>> be able to cover MAC based authentication.
>>>=20
>>>=20
>>> I know that public key is getting easier as far as computation goes.
>>> But for many applications the non-repudiation you get in digital
>>> signatures is actually undesirable.
>>>=20
>>> There are interesting tricks you can do with symmetric crypto that =
are
>>> much harder to do in public key and end up with some scheme that =
only
>>> 50 academics in the world can follow and has a security proof that
>>> rest on rather esoteric assumptions.
>>>=20
>>> --
>>> Website: http://hallambaker.com/
>>>=20
>>> _______________________________________________
>>> woes mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/woes
>>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

Date: Fri, 5 Aug 2011 16:53:35 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--00163691ff518a13d304a9c84ab0
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 5, 2011 at 4:23 PM, Sean Turner <[email-masked]> wrote:

>
> I have no problem with adding something along the line of:
>
> OLD:
>
> The resulting solutions will support both JSON-encoded public keys and
> X.509 public key certificates.
>

Works for me.

> I purposely choose "support" and didn't specify which is the MTI.  We can
> have that debate when writing the spec.
>
> do others have an issue with this?
>

I would prefer not to specify an MTI at all.

One of the neat features of C# is that you can now specify List <Foo> and
get a strongly typed list of type Foo. Unlike in C where the list container
is generic, you can specify a structure with a List <foo> and know that
nothing else will be put in it.

What I would like to end up with with Woes is scheme where a specification
using Woes can specify Woes <PKIX> or Woes <Raw>.

I think it is a mistake for every IETF security WG to get into discussions
on which algorithms to make mandatory for the same reason. We should have
one set of algorithms that is the preferred IETF set across the board and
those should apply unless a particular WG has a very particular reason to do
otherwise.

In fact that is the reason I want WOES in the first place. I can write out a
way to sign this stuff in a few hours and make it work for my stuff. I can
even write up a spec. What I greatly dislike is a situation where we get
into a committee and spend two years making a series of design decisions
en-bank and then join another group and go through the whole set all over
again, often with many of the same people.

-- 
Website: http://hallambaker.com/

--00163691ff518a13d304a9c84ab0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 4:23 PM, Sean Tur=
ner <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">turners@ieca.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br></div>
I have no problem with adding something along the line of:<br>
<br>
OLD:<br>
<br>
The resulting solutions will support both JSON-encoded public keys and X.50=
9 public key certificates.<br></blockquote><div><br></div><div>Works for me=
.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I purposely choose &quot;support&quot; and didn&#39;t specify which is the =
MTI. =A0We can have that debate when writing the spec.<br>
<br>
do others have an issue with this?<br></blockquote><div><br></div><div>I wo=
uld prefer not to specify an MTI at all.</div><div><br></div><div>One of th=
e neat features of C# is that you can now specify List &lt;Foo&gt; and get =
a strongly typed list of type Foo. Unlike in C where the list container is =
generic, you can specify a structure with a List &lt;foo&gt; and know that =
nothing else will be put in it.</div>
<div><br></div><div><br></div><div>What I would like to end up with with Wo=
es is scheme where a specification using Woes can specify Woes &lt;PKIX&gt;=
 or Woes &lt;Raw&gt;.=A0</div><div><br></div><div>I think it is a mistake f=
or every IETF security WG to get into discussions on which algorithms to ma=
ke mandatory for the same reason. We should have one set of=A0algorithms=A0=
that is the preferred IETF set across the board and those should apply unle=
ss a particular WG has a very particular reason to do otherwise.</div>
<div>=A0</div></div><div><br></div><div>In fact that is the reason I want W=
OES in the first place. I can write out a way to sign this stuff in a few h=
ours and make it work for my stuff. I can even write up a spec. What I grea=
tly dislike is a situation where we get into a committee and spend two year=
s making a series of design decisions en-bank and then join another group a=
nd go through the whole set all over again, often with many of the same peo=
ple.</div>
<br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.=
com/</a><br><br>

--00163691ff518a13d304a9c84ab0--

Date: Fri, 05 Aug 2011 16:34:32 -0400
From: Sean Turner <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

On 8/5/11 3:04 PM, Phillip Hallam-Baker wrote:
> Actually, I suspect that with AES in hand and having good MAC modes
> specified we might well want to use one of those in preference to the
> traditional HMAC.
>
>
>
> On Fri, Aug 5, 2011 at 2:45 PM, Sean Turner <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 8/4/11 4:41 PM, Hal Lockhart wrote:
>
>         +1
>
>             -----Original Message-----
>             From: Paul Hoffman [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             Sent: Thursday, August 04, 2011 12:03 PM
>             To: Eric Rescorla
>             Cc: [email-masked] <mailto:[email-masked]>
>             Subject: Re: [woes] Proposed charter, post-Quebec edition
>
>
>
>             On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
>
>                 IMO, symmetric integrity protection is a useful
>                 primitive, and it's
>                 already part of the
>                 JWT spec. I think all that's required here in the
>                 charter is to
>                 wordsmith it to separate
>                 out symmetric from asymmetric integrity algorithms,
>
>
>             Current:
>             1) A Standards Track document specifying how to apply a
>             JSON-structured digital signature to data, including (but not
>             limited to) JSON data structures. "Digital signature" is
>             defined as a hash operation followed by a signature operation
>             using asymmetric keys.
>
>             It sounds like you would prefer something like:
>             1) A Standards Track document specifying how to apply
>             integrity protection to data, including (but not limited to)
>             JSON data structures. This integrity protection can be
>             achieved with both symmetric and asymmetric algorithms.
>
>             Is that right?
>
>
>     I'm liking what Paul B. suggested but tweaked ever so slightly:
>
>     1) A Standards Track document specifying how to ensure the integrity
>     and/or authenticity of data, including (but not limited to) JSON
>     data structures.  HMAC-based (RFC 2104) and Asymmetric cryptographic
>     algorithms both need to be supported.
>
>     I'd like to not just call out integrity - and we should just call
>     out the HMAC-based algs because that's what folks really want to use
>     (or have I gotten this wrong?).
>
>     Any violent objections to this?

Right after I sent this I remembered AES-CMAC.   Precise enough to say:

   MAC-based (e.g., HMAC-SHA256, AES-CMAC) and Asymmetric cryptographic
   algorithms both need to be supported.

spt

Date: Fri, 05 Aug 2011 16:23:38 -0400
From: Sean Turner <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 8/5/11 2:49 PM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:
>
>         Question: What exactly is a 'raw key' in any case?
>
>
>     I believe the people that want this are trying to avoid X.509.  I'd
>     bet a $1 it won't end up just being the 'raw key' there's going to
>     be parameters, etc.  If you look at what Mike's proposing in
>     http://datatracker.ietf.org/__doc/draft-jones-json-web-key/
>     <http://datatracker.ietf.org/doc/draft-jones-json-web-key/> which I
>     believe is one draft on offer as input, it already includes more
>     than just the key - as it should.
>
>
> At some point he will add a criticality flag but call it something else.
> Like Conditions. There was some guy who did that in SAML...

nothing like designing a protocol by committee ;)

> I am not even opposed to eventually creating a whole new cert format.
> Just as long as we don't fool ourselves into thinking that this is the
> easy option, its not.
>
>
>     I have never assumed that the charter item for a 'raw key' implied
>     that it was *the* way to convey the public key in the resulting
>     JSON-structures for signatures/encryption.  I have always assumed
>     there would be some faction that would want an option to refer
>     to|point to|include a certificate.
>
>
> Given the way certain charters have been used to lay claim to 'own'
> certain issues in the recent past I would like this to be explicit in
> the charter. I don't want to end up having a four month argument as to
> whether to do it.

I have no problem with adding something along the line of:

OLD:

The resulting solutions will support both JSON-encoded public keys and 
X.509 public key certificates.

I purposely choose "support" and didn't specify which is the MTI.  We 
can have that debate when writing the spec.

do others have an issue with this?

spt

>     We can fight about what the required mechanism is when we actually
>     write the spec.  I've gotten the impression that regardless of the
>     choice that wins a 'bare key' JSON format is needed - hence the
>     charter item.
>
>
> No, I don't think that there should be a required mechanism as I don't
> think this is going to be used on its own.
>
> Specifically for my protocol, Web Confirmation Protocol (WCP) support
> for certificates is definitely going to be a MUST for authenticating
> inbound confirmation requests. But support for raw keys is going to be a
> MUST for interaction between the service and the client.
> --
> Website: http://hallambaker.com/
>

Date: Fri, 5 Aug 2011 15:04:49 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--001636c5be9285b1e804a9c6c5a2
Content-Type: text/plain; charset=ISO-8859-1

Actually, I suspect that with AES in hand and having good MAC modes
specified we might well want to use one of those in preference to the
traditional HMAC.

On Fri, Aug 5, 2011 at 2:45 PM, Sean Turner <[email-masked]> wrote:

> On 8/4/11 4:41 PM, Hal Lockhart wrote:
>
>> +1
>>
>>  -----Original Message-----
>>> From: Paul Hoffman [mailto:[email-masked]]
>>> Sent: Thursday, August 04, 2011 12:03 PM
>>> To: Eric Rescorla
>>> Cc: [email-masked]
>>> Subject: Re: [woes] Proposed charter, post-Quebec edition
>>>
>>>
>>>
>>> On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
>>>
>>>  IMO, symmetric integrity protection is a useful primitive, and it's
>>>> already part of the
>>>> JWT spec. I think all that's required here in the charter is to
>>>> wordsmith it to separate
>>>> out symmetric from asymmetric integrity algorithms,
>>>>
>>>
>>> Current:
>>> 1) A Standards Track document specifying how to apply a
>>> JSON-structured digital signature to data, including (but not
>>> limited to) JSON data structures. "Digital signature" is
>>> defined as a hash operation followed by a signature operation
>>> using asymmetric keys.
>>>
>>> It sounds like you would prefer something like:
>>> 1) A Standards Track document specifying how to apply
>>> integrity protection to data, including (but not limited to)
>>> JSON data structures. This integrity protection can be
>>> achieved with both symmetric and asymmetric algorithms.
>>>
>>> Is that right?
>>>
>>
> I'm liking what Paul B. suggested but tweaked ever so slightly:
>
> 1) A Standards Track document specifying how to ensure the integrity and/or
> authenticity of data, including (but not limited to) JSON data structures.
>  HMAC-based (RFC 2104) and Asymmetric cryptographic algorithms both need to
> be supported.
>
> I'd like to not just call out integrity - and we should just call out the
> HMAC-based algs because that's what folks really want to use (or have I
> gotten this wrong?).
>
> Any violent objections to this?
>
> spt
>
> ______________________________**_________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>

-- 
Website: http://hallambaker.com/

--001636c5be9285b1e804a9c6c5a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Actually, I suspect that with AES in hand and having good MAC modes specifi=
ed we might well want to use one of those in preference to the traditional =
HMAC.<div><br></div><div><br><br><div class=3D"gmail_quote">On Fri, Aug 5, =
2011 at 2:45 PM, Sean Turner <span dir=3D"ltr">&lt;<a href=3D"mailto:turner=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div><div></div><div class=3D"h5">On 8/4/11=
 4:41 PM, Hal Lockhart wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
+1<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: Paul Hoffman [mailto:<a href=3D"mailto:[email-masked]" target=
=3D"_blank">[email-masked]</a>]<br>
Sent: Thursday, August 04, 2011 12:03 PM<br>
To: Eric Rescorla<br>
Cc: <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br=
>
Subject: Re: [woes] Proposed charter, post-Quebec edition<br>
<br>
<br>
<br>
On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
IMO, symmetric integrity protection is a useful primitive, and it&#39;s<br>
already part of the<br>
JWT spec. I think all that&#39;s required here in the charter is to<br>
wordsmith it to separate<br>
out symmetric from asymmetric integrity algorithms,<br>
</blockquote>
<br>
Current:<br>
1) A Standards Track document specifying how to apply a<br>
JSON-structured digital signature to data, including (but not<br>
limited to) JSON data structures. &quot;Digital signature&quot; is<br>
defined as a hash operation followed by a signature operation<br>
using asymmetric keys.<br>
<br>
It sounds like you would prefer something like:<br>
1) A Standards Track document specifying how to apply<br>
integrity protection to data, including (but not limited to)<br>
JSON data structures. This integrity protection can be<br>
achieved with both symmetric and asymmetric algorithms.<br>
<br>
Is that right?<br>
</blockquote></blockquote>
<br></div></div>
I&#39;m liking what Paul B. suggested but tweaked ever so slightly:<br>
<br>
1) A Standards Track document specifying how to ensure the integrity and/or=
 authenticity of data, including (but not limited to) JSON data structures.=
 =A0HMAC-based (RFC 2104) and Asymmetric cryptographic algorithms both need=
 to be supported.<br>

<br>
I&#39;d like to not just call out integrity - and we should just call out t=
he HMAC-based algs because that&#39;s what folks really want to use (or hav=
e I gotten this wrong?).<br>
<br>
Any violent objections to this?<br>
<br>
spt<div><div></div><div class=3D"h5"><br>
______________________________<u></u>_________________<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/woes</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001636c5be9285b1e804a9c6c5a2--

Date: Fri, 5 Aug 2011 15:03:06 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--00163691fc2d69f0cb04a9c6bf4b
Content-Type: text/plain; charset=ISO-8859-1

I would also strongly urge talking to the OASIS people on this.

OASIS has a big dog in this fight, OK they are a bit XML centric, but they
are responsible for a very significant fraction of actual Web Services
applications.

I am much less worried about how fast the boat travels as how many people
are on board when it sails.

On Fri, Aug 5, 2011 at 2:26 PM, Sean Turner <[email-masked]> wrote:

> The AD did push back on the dates ;)
>
> Part of the process to get buy-in is progressing the charter.  It'll go out
> for two weeks internally to the IETF and then probably another two
> externally (W3C, etc.).  I'll make sure to bring it up with the W3C liaison
> (shocked if he's not on this list).  We (Stpehen and I) are also keeping the
> Apps ADs in the loop (both Pete and Peter were at the WOES/JOSE session).
>  There's also other IETF areas monitoring what's going on.
>
> As to the deliverable dates, I think we should try to be somewhat
> aggressive.  I'd rather not build in 'wait time.'  Getting something through
> the IESG by March (as I suggested) is going to be a challenge.
>
> spt
>
>
> On 8/4/11 2:18 PM, Jeremy Laurenson wrote:
>
>> Agree - I would think the ADs would agree and push back.
>>
>> On Aug 4, 2011, at 12:11 AM, Phillip Hallam-Baker wrote:
>>
>>  Is the object here to arrive at an RFC or to arrive at a standard with a
>>> broad base of support in the web services apps community?
>>>
>>> If the latter the I suggest much more time so as to have the ability to
>>> get buy in from the relevant community.
>>>
>>>
>>> Sent from my angry birds pad
>>>
>>> On Aug 2, 2011, at 19:13, Paul Hoffman<[email-masked]>  wrote:
>>>
>>>  Here is a proposal for the charter based on the discussion in the BoF
>>>> last week and later discussion with Sean Turner. Comments, praise, scorn,
>>>> etc., are welcome.
>>>>
>>>> --Paul and Richard
>>>>
>>>> Javascript Object Signing and Encrypting (jose)
>>>> ==============================**=================
>>>>
>>>> Background
>>>> ----------
>>>>
>>>> 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 and digital
>>>> signatures 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
>>>> two security services, encrypting and digitally signing, 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 four documents:
>>>>
>>>> 1) A Standards Track document specifying how to apply a JSON-structured
>>>> digital signature to data, including (but not limited to) JSON data
>>>> structures. "Digital signature" is defined as a hash operation followed by a
>>>> signature operation using asymmetric keys.
>>>>
>>>> 2) A Standards Track document specifying how to apply a JSON-structured
>>>> encryption to data, including (but not limited to) JSON data structures.
>>>>
>>>> 3) A Standards Track document specifying how to encode public keys as
>>>> JSON-structured objects.
>>>>
>>>> 4) A Standards Track document specifying mandatory-to-implement
>>>> algorithms for the other three documents.
>>>>
>>>> The working group may decide to address one or more 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.
>>>>
>>>> Aug 2011    Submit JSON key format document as a WG item.
>>>>
>>>> Aug 2011    Submit JSON algoritm document as a WG item.
>>>>
>>>> Jan 2012    Start Working Group Last Call on JSON object signing
>>>> document.
>>>>
>>>> Jan 2012    Start Working Group Last Call on JSON object encryption
>>>> document.
>>>>
>>>> Jan 2012    Start Working Group Last Call on JSON key format document.
>>>>
>>>> Jan 2012    Start Working Group Last Call on JSON algorithm document.
>>>>
>>>> Feb 2012    Submit JSON object signing document to IESG for
>>>> consideration as
>>>> Standards Track document.
>>>>
>>>> Feb 2012    Submit JSON object encryption document to IESG for
>>>> consideration
>>>> as Standards Track document.
>>>>
>>>> Feb 2012    Submit JSON key format document to IESG for consideration
>>>> as Standards Track document.
>>>>
>>>> Feb 2012    Submit JSON algorithm document to IESG for consideration
>>>> as Standards Track document.
>>>>
>>>> ______________________________**_________________
>>>> woes mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>>>>
>>> ______________________________**_________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>>>
>>
>> ______________________________**_________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>>
>>

-- 
Website: http://hallambaker.com/

--00163691fc2d69f0cb04a9c6bf4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would also strongly urge talking to the OASIS people on this.<div><br></d=
iv><div>OASIS has a big dog in this fight, OK they are a bit XML centric, b=
ut they are responsible for a very significant fraction of actual Web Servi=
ces applications.</div>
<div><br></div><div><br></div><div>I am much less worried about how fast th=
e boat travels as how many people are on board when it sails.</div><div><br=
></div><div><br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 2:26 PM, =
Sean Turner <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">turne=
[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">The AD did push back on the dates ;)<br>
<br>
Part of the process to get buy-in is progressing the charter. =A0It&#39;ll =
go out for two weeks internally to the IETF and then probably another two e=
xternally (W3C, etc.). =A0I&#39;ll make sure to bring it up with the W3C li=
aison (shocked if he&#39;s not on this list). =A0We (Stpehen and I) are als=
o keeping the Apps ADs in the loop (both Pete and Peter were at the WOES/JO=
SE session). =A0There&#39;s also other IETF areas monitoring what&#39;s goi=
ng on.<br>

<br>
As to the deliverable dates, I think we should try to be somewhat aggressiv=
e. =A0I&#39;d rather not build in &#39;wait time.&#39; =A0Getting something=
 through the IESG by March (as I suggested) is going to be a challenge.<br>

<br>
spt<div><div></div><div class=3D"h5"><br>
<br>
On 8/4/11 2:18 PM, Jeremy Laurenson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Agree - I would think the ADs would agree and push back.<br>
<br>
On Aug 4, 2011, at 12:11 AM, Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Is the object here to arrive at an RFC or to arrive at a standard with a br=
oad base of support in the web services apps community?<br>
<br>
If the latter the I suggest much more time so as to have the ability to get=
 buy in from the relevant community.<br>
<br>
<br>
Sent from my angry birds pad<br>
<br>
On Aug 2, 2011, at 19:13, Paul Hoffman&lt;<a href=3D"mailto:paul.hoffman@vp=
nc.org" target=3D"_blank">[email-masked]</a>&gt; =A0wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Here is a proposal for the charter based on the discussion in the BoF last =
week and later discussion with Sean Turner. Comments, praise, scorn, etc., =
are welcome.<br>
<br>
--Paul and Richard<br>
<br>
Javascript Object Signing and Encrypting (jose)<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<u></u>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<b=
r>
<br>
Background<br>
----------<br>
<br>
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 s=
erializing 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 and digital s=
ignatures for data that is being carried in JSON format.<br>

<br>
Different proposals for providing such security services have already been =
defined and implemented. This Working Group&#39;s task is to standardize tw=
o security services, encrypting and digitally signing, in order to increase=
 interoperability of security features between protocols that use JSON. =A0=
The Working Group will base its work on well-known message security primiti=
ves (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 corre=
ct.<br>

<br>
This group is chartered to work on four documents:<br>
<br>
1) A Standards Track document specifying how to apply a JSON-structured dig=
ital signature to data, including (but not limited to) JSON data structures=
. &quot;Digital signature&quot; is defined as a hash operation followed by =
a signature operation using asymmetric keys.<br>

<br>
2) A Standards Track document specifying how to apply a JSON-structured enc=
ryption to data, including (but not limited to) JSON data structures.<br>
<br>
3) A Standards Track document specifying how to encode public keys as JSON-=
structured objects.<br>
<br>
4) A Standards Track document specifying mandatory-to-implement algorithms =
for the other three documents.<br>
<br>
The working group may decide to address one or more of these goals in a sin=
gle document, in which case the concrete milestones for signing/encryption =
below will both be satisfied by the single document.<br>
<br>
Goals and Milestones<br>
--------------------<br>
<br>
Aug 2011 =A0 =A0Submit JSON object signing document as a WG item.<br>
<br>
Aug 2011 =A0 =A0Submit JSON object encryption document as a WG item.<br>
<br>
Aug 2011 =A0 =A0Submit JSON key format document as a WG item.<br>
<br>
Aug 2011 =A0 =A0Submit JSON algoritm document as a WG item.<br>
<br>
Jan 2012 =A0 =A0Start Working Group Last Call on JSON object signing docume=
nt.<br>
<br>
Jan 2012 =A0 =A0Start Working Group Last Call on JSON object encryption doc=
ument.<br>
<br>
Jan 2012 =A0 =A0Start Working Group Last Call on JSON key format document.<=
br>
<br>
Jan 2012 =A0 =A0Start Working Group Last Call on JSON algorithm document.<b=
r>
<br>
Feb 2012 =A0 =A0Submit JSON object signing document to IESG for considerati=
on as<br>
Standards Track document.<br>
<br>
Feb 2012 =A0 =A0Submit JSON object encryption document to IESG for consider=
ation<br>
as Standards Track document.<br>
<br>
Feb 2012 =A0 =A0Submit JSON key format document to IESG for consideration<b=
r>
as Standards Track document.<br>
<br>
Feb 2012 =A0 =A0Submit JSON algorithm document to IESG for consideration<br=
>
as Standards Track document.<br>
<br>
______________________________<u></u>_________________<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/woes</a><br>
</blockquote>
______________________________<u></u>_________________<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/woes</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/woes</a><br>
<br>
</blockquote>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--00163691fc2d69f0cb04a9c6bf4b--

Date: Fri, 5 Aug 2011 14:49:37 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--001636c9274c2e7d9604a9c68f49
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <[email-masked]> wrote:

> On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:
>
>> Question: What exactly is a 'raw key' in any case?
>>
>
> I believe the people that want this are trying to avoid X.509.  I'd bet a
> $1 it won't end up just being the 'raw key' there's going to be parameters,
> etc.  If you look at what Mike's proposing in http://datatracker.ietf.org/
> **doc/draft-jones-json-web-key/<http://datatracker.ietf.org/doc/draft-jones-json-web-key/>which I believe is one draft on offer as input, it already includes more
> than just the key - as it should.

At some point he will add a criticality flag but call it something else.
Like Conditions. There was some guy who did that in SAML...

I am not even opposed to eventually creating a whole new cert format. Just
as long as we don't fool ourselves into thinking that this is the easy
option, its not.

> I have never assumed that the charter item for a 'raw key' implied that it
> was *the* way to convey the public key in the resulting JSON-structures for
> signatures/encryption.  I have always assumed there would be some faction
> that would want an option to refer to|point to|include a certificate.
>

Given the way certain charters have been used to lay claim to 'own' certain
issues in the recent past I would like this to be explicit in the charter. I
don't want to end up having a four month argument as to whether to do it.

> We can fight about what the required mechanism is when we actually write
> the spec.  I've gotten the impression that regardless of the choice that
> wins a 'bare key' JSON format is needed - hence the charter item.
>

No, I don't think that there should be a required mechanism as I don't think
this is going to be used on its own.

Specifically for my protocol, Web Confirmation Protocol (WCP) support for
certificates is definitely going to be a MUST for authenticating inbound
confirmation requests. But support for raw keys is going to be a MUST for
interaction between the service and the client.

-- 
Website: http://hallambaker.com/

--001636c9274c2e7d9604a9c68f49
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 2:13 PM, Sean Tur=
ner <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_bl=
ank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">

<div>On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Question: What exactly is a &#39;raw key&#39; in any case?<br>
</blockquote>
<br></div>
I believe the people that want this are trying to avoid X.509. =A0I&#39;d b=
et a $1 it won&#39;t end up just being the &#39;raw key&#39; there&#39;s go=
ing to be parameters, etc. =A0If you look at what Mike&#39;s proposing in <=
a href=3D"http://datatracker.ietf.org/doc/draft-jones-json-web-key/" target=
=3D"_blank">http://datatracker.ietf.org/<u></u>doc/draft-jones-json-web-key=
/</a> which I believe is one draft on offer as input, it already includes m=
ore than just the key - as it should.</blockquote>

<div><br></div><div>At some point he will add a criticality flag but call i=
t something else. Like Conditions. There was some guy who did that in SAML.=
..</div><div><br></div><div>I am not even opposed to eventually creating a =
whole new cert format. Just as long as we don&#39;t fool ourselves into thi=
nking that this is the easy option, its not.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div><br></div>
I have never assumed that the charter item for a &#39;raw key&#39; implied =
that it was *the* way to convey the public key in the resulting JSON-struct=
ures for signatures/encryption. =A0I have always assumed there would be som=
e faction that would want an option to refer to|point to|include a certific=
ate.<br>
</blockquote><div><br></div><div>Given the way certain charters have been u=
sed to lay claim to &#39;own&#39; certain issues in the recent past I would=
 like this to be explicit in the charter. I don&#39;t want to end up having=
 a four month argument as to whether to do it.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We can fight about what the required mechanism is when we actually write th=
e spec. =A0I&#39;ve gotten the impression that regardless of the choice tha=
t wins a &#39;bare key&#39; JSON format is needed - hence the charter item.=
<br>
</blockquote><div><br></div><div>No, I don&#39;t think that there should be=
 a required mechanism as I don&#39;t think this is going to be used on its =
own.</div><div><br></div><div>Specifically for my protocol, Web Confirmatio=
n Protocol (WCP) support for certificates is definitely going to be a MUST =
for authenticating inbound confirmation requests. But support for raw keys =
is going to be a MUST for interaction between the service and the client.</=
div>
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/" tar=
get=3D"_blank">http://hallambaker.com/</a><br><br>

--001636c9274c2e7d9604a9c68f49--

Date: Fri, 05 Aug 2011 14:45:09 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Cc: Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

On 8/4/11 4:41 PM, Hal Lockhart wrote:
> +1
>
>> -----Original Message-----
>> From: Paul Hoffman [mailto:[email-masked]]
>> Sent: Thursday, August 04, 2011 12:03 PM
>> To: Eric Rescorla
>> Cc: [email-masked]
>> Subject: Re: [woes] Proposed charter, post-Quebec edition
>>
>>
>>
>> On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
>>
>>> IMO, symmetric integrity protection is a useful primitive, and it's
>>> already part of the
>>> JWT spec. I think all that's required here in the charter is to
>>> wordsmith it to separate
>>> out symmetric from asymmetric integrity algorithms,
>>
>> Current:
>> 1) A Standards Track document specifying how to apply a
>> JSON-structured digital signature to data, including (but not
>> limited to) JSON data structures. "Digital signature" is
>> defined as a hash operation followed by a signature operation
>> using asymmetric keys.
>>
>> It sounds like you would prefer something like:
>> 1) A Standards Track document specifying how to apply
>> integrity protection to data, including (but not limited to)
>> JSON data structures. This integrity protection can be
>> achieved with both symmetric and asymmetric algorithms.
>>
>> Is that right?

I'm liking what Paul B. suggested but tweaked ever so slightly:

1) A Standards Track document specifying how to ensure the integrity 
and/or authenticity of data, including (but not limited to) JSON data 
structures.  HMAC-based (RFC 2104) and Asymmetric cryptographic 
algorithms both need to be supported.

I'd like to not just call out integrity - and we should just call out 
the HMAC-based algs because that's what folks really want to use (or 
have I gotten this wrong?).

Any violent objections to this?

spt

Date: Fri, 05 Aug 2011 14:26:54 -0400
From: Sean Turner <[email-masked]>
To: Jeremy Laurenson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

The AD did push back on the dates ;)

Part of the process to get buy-in is progressing the charter.  It'll go 
out for two weeks internally to the IETF and then probably another two 
externally (W3C, etc.).  I'll make sure to bring it up with the W3C 
liaison (shocked if he's not on this list).  We (Stpehen and I) are also 
keeping the Apps ADs in the loop (both Pete and Peter were at the 
WOES/JOSE session).  There's also other IETF areas monitoring what's 
going on.

As to the deliverable dates, I think we should try to be somewhat 
aggressive.  I'd rather not build in 'wait time.'  Getting something 
through the IESG by March (as I suggested) is going to be a challenge.

spt

On 8/4/11 2:18 PM, Jeremy Laurenson wrote:
> Agree - I would think the ADs would agree and push back.
>
> On Aug 4, 2011, at 12:11 AM, Phillip Hallam-Baker wrote:
>
>> Is the object here to arrive at an RFC or to arrive at a standard with a broad base of support in the web services apps community?
>>
>> If the latter the I suggest much more time so as to have the ability to get buy in from the relevant community.
>>
>>
>> Sent from my angry birds pad
>>
>> On Aug 2, 2011, at 19:13, Paul Hoffman<[email-masked]>  wrote:
>>
>>> Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.
>>>
>>> --Paul and Richard
>>>
>>> Javascript Object Signing and Encrypting (jose)
>>> ===============================================
>>>
>>> Background
>>> ----------
>>>
>>> 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 and digital signatures 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 two security services, encrypting and digitally signing, 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 four documents:
>>>
>>> 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.
>>>
>>> 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.
>>>
>>> 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
>>>
>>> 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.
>>>
>>> The working group may decide to address one or more 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.
>>>
>>> Aug 2011    Submit JSON key format document as a WG item.
>>>
>>> Aug 2011    Submit JSON algoritm document as a WG item.
>>>
>>> Jan 2012    Start Working Group Last Call on JSON object signing document.
>>>
>>> Jan 2012    Start Working Group Last Call on JSON object encryption document.
>>>
>>> Jan 2012    Start Working Group Last Call on JSON key format document.
>>>
>>> Jan 2012    Start Working Group Last Call on JSON algorithm document.
>>>
>>> Feb 2012    Submit JSON object signing document to IESG for consideration as
>>> Standards Track document.
>>>
>>> Feb 2012    Submit JSON object encryption document to IESG for consideration
>>> as Standards Track document.
>>>
>>> Feb 2012    Submit JSON key format document to IESG for consideration
>>> as Standards Track document.
>>>
>>> Feb 2012    Submit JSON algorithm document to IESG for consideration
>>> as Standards Track document.
>>>
>>> _______________________________________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/woes
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

Date: Fri, 05 Aug 2011 14:16:30 -0400
From: Sean Turner <[email-masked]>
To: John Bradley <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

So I'll bite on this ;)

I think we can write the spec to require a particular algorithm choice, 
but it might make more sense to define the options and then allow the 
environment in which the solution will be used to specify it's 
requirements.  But, I believe that is a discussion we'll have while 
writing the spec.

spt

On 8/4/11 9:29 AM, John Bradley wrote:
> HMAC is requirement for adoption in the JWS use cases.
>
> If we want to describe it as something other than a "Qualified Digital
> Signature", that is fine as long as it is MTI:)
>
> John B.
>
>
> On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:
>
>>
>>
>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     On 8/2/11 7:13 PM, Paul Hoffman wrote:
>>
>>         Here is a proposal for the charter based on the discussion in
>>         the BoF last week and later discussion with Sean Turner.
>>         Comments, praise, scorn, etc., are welcome.
>>
>>         --Paul and Richard
>>
>>         Javascript Object Signing and Encrypting (jose)
>>         ==============================__=================
>>
>>         Background
>>         ----------
>>
>>         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 and
>>         digital signatures 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 two security services, encrypting and
>>         digitally signing, 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 four documents:
>>
>>         1) A Standards Track document specifying how to apply a
>>         JSON-structured digital signature to data, including (but not
>>         limited to) JSON data structures. "Digital signature" is
>>         defined as a hash operation followed by a signature operation
>>         using asymmetric keys.
>>
>>
>>     I just want to make sure that we agree now that a digital
>>     signature is a hash followed by a signature algorithm (e.g., RSA
>>     with SHA-256). I've seen a couple of drafts that tried to say an
>>     HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a
>>     symmetric key based digital signature algorithm (note this phrase
>>     didn't get through the IESG).
>>
>>
>> An HMAC is not a digital signature, but the spec definitely needs to
>> be able to cover MAC based authentication.
>>
>>
>> I know that public key is getting easier as far as computation goes.
>> But for many applications the non-repudiation you get in digital
>> signatures is actually undesirable.
>>
>> There are interesting tricks you can do with symmetric crypto that are
>> much harder to do in public key and end up with some scheme that only
>> 50 academics in the world can follow and has a security proof that
>> rest on rather esoteric assumptions.
>>
>> --
>> Website: http://hallambaker.com/
>>
>> _______________________________________________
>> woes mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/woes
>

Date: Fri, 05 Aug 2011 14:13:23 -0400
From: Sean Turner <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:
> Question: What exactly is a 'raw key' in any case?

I believe the people that want this are trying to avoid X.509.  I'd bet 
a $1 it won't end up just being the 'raw key' there's going to be 
parameters, etc.  If you look at what Mike's proposing in 
http://datatracker.ietf.org/doc/draft-jones-json-web-key/ which I 
believe is one draft on offer as input, it already includes more than 
just the key - as it should.

> Anything that the group does is going to require some commitment to a
> specific serialization of the key information. A public key is an
> abstract data structure and you can't put an abstract structure on the
> wire. There has to be some mapping from the abstract structure to the bits.
>
>
> Eric and myself are not trying to be difficult here. OK, I can't speak
> for Eric, maybe he is. But we have both tried to do what is being
> presented as the 'easy' case and it wasn't.
>
> Raw key can simplify things if offered as an option. If it is the only
> option it is going to make things harder, not easier in my view.

I have never assumed that the charter item for a 'raw key' implied that 
it was *the* way to convey the public key in the resulting 
JSON-structures for signatures/encryption.  I have always assumed there 
would be some faction that would want an option to refer to|point 
to|include a certificate.

We can fight about what the required mechanism is when we actually write 
the spec.  I've gotten the impression that regardless of the choice that 
wins a 'bare key' JSON format is needed - hence the charter item.

spt

> On Fri, Aug 5, 2011 at 10:07 AM, Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Aug 4, 2011 at 9:34 PM, Joe Hildebrand
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      > On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      >>> 3) A Standards Track document specifying how to encode public
>      >>> keys as JSON-structured objects.
>      >>>
>      >>
>      >> I would like to push back on the idea of only supporting naked
>     public keys. It
>      >> is my understanding that common cryto libraries, e.g. OpenSSL,
>     expect public
>      >> keys to be in certificates and the coding to get them to accept
>     a naked key as
>      >> input is ugly. I don't think they care if the cert is self
>     signed or even
>      >> signed at all, its just a format issue.
>      >
>      > Just doing the math yourself, from scratch, is pretty easy if you
>     have the
>      > bare key.  It's nigh-on trivial if you have a bigint library.
>       Solution:
>      > don't use OpenSSL.  I propose we don't get bogged down in the
>     certificate
>      > problem for the moment.
>
>     Cryptographer's warning: do not do this. Hard hat area ahead.
>
>     -Ekr
>     _______________________________________________
>     woes mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/woes
>
>
>
>
> --
> Website: http://hallambaker.com/
>
>
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Aug 2011 09:43:37 -0700
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On Fri, Aug 5, 2011 at 7:42 AM, Leif Johansson <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>> Just doing the math yourself, from scratch, is pretty easy if you have =
the
>>> bare key. =A0It's nigh-on trivial if you have a bigint library. =A0Solu=
tion:
>>> don't use OpenSSL. =A0I propose we don't get bogged down in the certifi=
cate
>>> problem for the moment.
>>
>> Cryptographer's warning: do not do this. Hard hat area ahead.
>>
>
> That is advice for implementors and not for spec writers, right?

Correct. Getting the implementation right is tricky.

-Ekr

Date: Fri, 5 Aug 2011 12:27:36 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--001636c5bbf345ff4e04a9c49346
Content-Type: text/plain; charset=ISO-8859-1

Question: What exactly is a 'raw key' in any case?

Anything that the group does is going to require some commitment to a
specific serialization of the key information. A public key is an abstract
data structure and you can't put an abstract structure on the wire. There
has to be some mapping from the abstract structure to the bits.

Eric and myself are not trying to be difficult here. OK, I can't speak for
Eric, maybe he is. But we have both tried to do what is being presented as
the 'easy' case and it wasn't.

Raw key can simplify things if offered as an option. If it is the only
option it is going to make things harder, not easier in my view.

On Fri, Aug 5, 2011 at 10:07 AM, Eric Rescorla <[email-masked]> wrote:

> On Thu, Aug 4, 2011 at 9:34 PM, Joe Hildebrand <[email-masked]>
> wrote:
> > On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]> wrote:
> >
> >>> 3) A Standards Track document specifying how to encode public
> >>> keys as JSON-structured objects.
> >>>
> >>
> >> I would like to push back on the idea of only supporting naked public
> keys. It
> >> is my understanding that common cryto libraries, e.g. OpenSSL, expect
> public
> >> keys to be in certificates and the coding to get them to accept a naked
> key as
> >> input is ugly. I don't think they care if the cert is self signed or
> even
> >> signed at all, its just a format issue.
> >
> > Just doing the math yourself, from scratch, is pretty easy if you have
> the
> > bare key.  It's nigh-on trivial if you have a bigint library.  Solution:
> > don't use OpenSSL.  I propose we don't get bogged down in the certificate
> > problem for the moment.
>
> Cryptographer's warning: do not do this. Hard hat area ahead.
>
> -Ekr
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

-- 
Website: http://hallambaker.com/

--001636c5bbf345ff4e04a9c49346
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Question: What exactly is a &#39;raw key&#39; in any case?<div><br></div><d=
iv>Anything that the group does is going to require some commitment to a sp=
ecific serialization of the key information. A public key is an abstract da=
ta structure and you can&#39;t put an abstract structure on the wire. There=
 has to be some mapping from the abstract structure to the bits.</div>
<div><br></div><div><br></div><div>Eric and myself are not trying to be dif=
ficult here. OK, I can&#39;t speak for Eric, maybe he is. But we have both =
tried to do what is being presented as the &#39;easy&#39; case and it wasn&=
#39;t.</div>
<div><br></div><div>Raw key can simplify things if offered as an option. If=
 it is the only option it is going to make things harder, not easier in my =
view.</div><div><br></div><div><br><br><div class=3D"gmail_quote">On Fri, A=
ug 5, 2011 at 10:07 AM, Eric Rescorla <span dir=3D"ltr">&lt;<a href=3D"mail=
to:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Thu, Aug 4, 2011 at 9:=
34 PM, Joe Hildebrand &lt;<a href=3D"mailto:[email-masked]">joe.h=
[email-masked]</a>&gt; wrote:<br>

&gt; On 8/4/11 4:48 PM, &quot;Hal Lockhart&quot; &lt;<a href=3D"mailto:hal.=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;&gt; 3) A Standards Track document specifying how to encode public<=
br>
&gt;&gt;&gt; keys as JSON-structured objects.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I would like to push back on the idea of only supporting naked pub=
lic keys. It<br>
&gt;&gt; is my understanding that common cryto libraries, e.g. OpenSSL, exp=
ect public<br>
&gt;&gt; keys to be in certificates and the coding to get them to accept a =
naked key as<br>
&gt;&gt; input is ugly. I don&#39;t think they care if the cert is self sig=
ned or even<br>
&gt;&gt; signed at all, its just a format issue.<br>
&gt;<br>
&gt; Just doing the math yourself, from scratch, is pretty easy if you have=
 the<br>
&gt; bare key. =A0It&#39;s nigh-on trivial if you have a bigint library. =
=A0Solution:<br>
&gt; don&#39;t use OpenSSL. =A0I propose we don&#39;t get bogged down in th=
e certificate<br>
&gt; problem for the moment.<br>
<br>
</div>Cryptographer&#39;s warning: do not do this. Hard hat area ahead.<br>
<br>
-Ekr<br>
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/woes</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001636c5bbf345ff4e04a9c49346--

Date: Fri, 5 Aug 2011 12:10:13 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--00163691ff511e573e04a9c455d2
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 5, 2011 at 8:43 AM, Leif Johansson <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/05/2011 02:11 PM, Phillip Hallam-Baker wrote:
> > Support for naked keys is useful.
> >
> > Lack of support for certificates where needed would be unacceptable and
> > render the format unsuited for many of the applications we need it for.
> >
> > Certificates are pretty simple to deal with. The problems that they are
> used
> > to address are not simple.
>
> I also think you need both. Sometimes you need to use a key for both
> signing and TLS for instance.
>
> >
> > Whatever you thought of the 'Trust Router' proposal made at last IETF, it
> is
> > certainly no simpler than the PKI based approach and that is before they
> > have put it in operation and found the operational requirements.
>
> I don't think that proposal is targeted for anything that comes even
> remotely close to signed objects. Lets not go there.

Which is exactly what I am arguing for.

If the group decided it is 'only' going to do raw key it would inevitably
end up going there because the problems are going to take it there.

The way to avoid going there is to build on the infrastructure already
designed to go there and let people hook into that infrastructure where it
is useful.

Otherwise we are like the office that decides not to build a loading dock
because handling deliveries of office supplies requires too much manual
effort. If you need the office supplies you are going to be dealing with the
deliveries.

-- 
Website: http://hallambaker.com/

--00163691ff511e573e04a9c455d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 8:43 AM, Leif Joh=
ansson <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div class=3D"im">On 08/05/2011 02:11 PM, Phillip Hallam-Baker wrote:=
<br>
&gt; Support for naked keys is useful.<br>
&gt;<br>
&gt; Lack of support for certificates where needed would be unacceptable an=
d<br>
&gt; render the format unsuited for many of the applications we need it for=
.<br>
&gt;<br>
&gt; Certificates are pretty simple to deal with. The problems that they ar=
e used<br>
&gt; to address are not simple.<br>
<br>
</div>I also think you need both. Sometimes you need to use a key for both<=
br>
signing and TLS for instance.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; Whatever you thought of the &#39;Trust Router&#39; proposal made at la=
st IETF, it is<br>
&gt; certainly no simpler than the PKI based approach and that is before th=
ey<br>
&gt; have put it in operation and found the operational requirements.<br>
<br>
</div>I don&#39;t think that proposal is targeted for anything that comes e=
ven<br>
remotely close to signed objects. Lets not go there.</blockquote><div><br><=
/div><div>Which is exactly what I am arguing for.</div><div><br></div><div>=
If the group decided it is &#39;only&#39; going to do raw key it would inev=
itably end up going there because the problems are going to take it there.<=
/div>
<div><br></div><div>The way to avoid going there is to build on the infrast=
ructure already designed to go there and let people hook into that infrastr=
ucture where it is useful.=A0</div><div><br></div><div><br></div><div>Other=
wise we are like the office that decides not to build a loading dock becaus=
e handling deliveries of office supplies requires too much manual effort. I=
f you need the office supplies you are going to be dealing with the deliver=
ies.</div>
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br><br>

--00163691ff511e573e04a9c455d2--

Date: Fri, 05 Aug 2011 16:42:32 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

>> Just doing the math yourself, from scratch, is pretty easy if you have the
>> bare key.  It's nigh-on trivial if you have a bigint library.  Solution:
>> don't use OpenSSL.  I propose we don't get bogged down in the certificate
>> problem for the moment.
> 
> Cryptographer's warning: do not do this. Hard hat area ahead.
> 

That is advice for implementors and not for spec writers, right?

	Cheers Leif

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Aug 2011 07:07:43 -0700
To: Joe Hildebrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On Thu, Aug 4, 2011 at 9:34 PM, Joe Hildebrand <[email-masked]> w=
rote:
> On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]> wrote:
>
>>> 3) A Standards Track document specifying how to encode public
>>> keys as JSON-structured objects.
>>>
>>
>> I would like to push back on the idea of only supporting naked public ke=
ys. It
>> is my understanding that common cryto libraries, e.g. OpenSSL, expect pu=
blic
>> keys to be in certificates and the coding to get them to accept a naked =
key as
>> input is ugly. I don't think they care if the cert is self signed or eve=
n
>> signed at all, its just a format issue.
>
> Just doing the math yourself, from scratch, is pretty easy if you have th=
e
> bare key. =A0It's nigh-on trivial if you have a bigint library. =A0Soluti=
on:
> don't use OpenSSL. =A0I propose we don't get bogged down in the certifica=
te
> problem for the moment.

Cryptographer's warning: do not do this. Hard hat area ahead.

-Ekr

From: John Bradley <[email-masked]>
Date: Fri, 5 Aug 2011 09:33:38 -0400
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--Apple-Mail=_E5C6DD9A-5D66-4AD0-943F-A25826362BFB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

JWS and JWE specified both.   I agree both need to be supported.

John B.
On 2011-08-05, at 8:43 AM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 08/05/2011 02:11 PM, Phillip Hallam-Baker wrote:
>> Support for naked keys is useful.
>>=20
>> Lack of support for certificates where needed would be unacceptable =
and
>> render the format unsuited for many of the applications we need it =
for.
>>=20
>> Certificates are pretty simple to deal with. The problems that they =
are used
>> to address are not simple.
>=20
> I also think you need both. Sometimes you need to use a key for both
> signing and TLS for instance.
>=20
>>=20
>> Whatever you thought of the 'Trust Router' proposal made at last =
IETF, it is
>> certainly no simpler than the PKI based approach and that is before =
they
>> have put it in operation and found the operational requirements.
>=20
> I don't think that proposal is targeted for anything that comes even
> remotely close to signed objects. Lets not go there.
>=20
> 	Cheers Leif
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAk475XUACgkQ8Jx8FtbMZndQEwCeNnyVkj0xpDRhvDuSNSH4/Mig
> GH8An3R2UeKcGxUzpZhuUG8/Hakfx5z0
> =3DXbMB
> -----END PGP SIGNATURE-----
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_E5C6DD9A-5D66-4AD0-943F-A25826362BFB
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_E5C6DD9A-5D66-4AD0-943F-A25826362BFB--

Date: Fri, 05 Aug 2011 14:43:33 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

On 08/05/2011 02:11 PM, Phillip Hallam-Baker wrote:
> Support for naked keys is useful.
> 
> Lack of support for certificates where needed would be unacceptable and
> render the format unsuited for many of the applications we need it for.
> 
> Certificates are pretty simple to deal with. The problems that they are used
> to address are not simple.

I also think you need both. Sometimes you need to use a key for both
signing and TLS for instance.

> 
> Whatever you thought of the 'Trust Router' proposal made at last IETF, it is
> certainly no simpler than the PKI based approach and that is before they
> have put it in operation and found the operational requirements.

I don't think that proposal is targeted for anything that comes even
remotely close to signed objects. Lets not go there.

	Cheers Leif

Date: Fri, 5 Aug 2011 08:11:02 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Joe Hildebrand <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

--001636c5bbf3bd3eef04a9c0fde3
Content-Type: text/plain; charset=ISO-8859-1

Support for naked keys is useful.

Lack of support for certificates where needed would be unacceptable and
render the format unsuited for many of the applications we need it for.

Certificates are pretty simple to deal with. The problems that they are used
to address are not simple.

Whatever you thought of the 'Trust Router' proposal made at last IETF, it is
certainly no simpler than the PKI based approach and that is before they
have put it in operation and found the operational requirements.

For my application I need certificates and will use them. The question then
is not whether the spec will use them, it is whether the way in which they
are used is standardized or not.

On Fri, Aug 5, 2011 at 12:34 AM, Joe Hildebrand <[email-masked]>wrote:

> On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]> wrote:
>
> >> 3) A Standards Track document specifying how to encode public
> >> keys as JSON-structured objects.
> >>
> >
> > I would like to push back on the idea of only supporting naked public
> keys. It
> > is my understanding that common cryto libraries, e.g. OpenSSL, expect
> public
> > keys to be in certificates and the coding to get them to accept a naked
> key as
> > input is ugly. I don't think they care if the cert is self signed or even
> > signed at all, its just a format issue.
>
> Just doing the math yourself, from scratch, is pretty easy if you have the
> bare key.  It's nigh-on trivial if you have a bigint library.  Solution:
> don't use OpenSSL.  I propose we don't get bogged down in the certificate
> problem for the moment.
>
> --
> Joe Hildebrand
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

-- 
Website: http://hallambaker.com/

--001636c5bbf3bd3eef04a9c0fde3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Support for naked keys is useful.<div><br></div><div>Lack of support for ce=
rtificates where needed would be unacceptable and render the format unsuite=
d for many of the applications we need it for.</div><div><br></div><div>
Certificates are pretty simple to deal with. The problems that they are use=
d to address are not simple.=A0</div><div><br></div><div>Whatever you thoug=
ht of the &#39;Trust Router&#39; proposal made at last IETF, it is certainl=
y no simpler than the PKI based approach and that is before they have put i=
t in operation and found the operational requirements.</div>
<div><br></div><div><br></div><div>For my application I need certificates a=
nd will use them. The question then is not whether the spec will use them, =
it is whether the way in which they are used is standardized or not.</div>
<div><br><br><div class=3D"gmail_quote">On Fri, Aug 5, 2011 at 12:34 AM, Jo=
e Hildebrand <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
om">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;">
<div class=3D"im">On 8/4/11 4:48 PM, &quot;Hal Lockhart&quot; &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<=
br>
<br>
&gt;&gt; 3) A Standards Track document specifying how to encode public<br>
&gt;&gt; keys as JSON-structured objects.<br>
&gt;&gt;<br>
&gt;<br>
&gt; I would like to push back on the idea of only supporting naked public =
keys. It<br>
&gt; is my understanding that common cryto libraries, e.g. OpenSSL, expect =
public<br>
&gt; keys to be in certificates and the coding to get them to accept a nake=
d key as<br>
&gt; input is ugly. I don&#39;t think they care if the cert is self signed =
or even<br>
&gt; signed at all, its just a format issue.<br>
<br>
</div>Just doing the math yourself, from scratch, is pretty easy if you hav=
e the<br>
bare key. =A0It&#39;s nigh-on trivial if you have a bigint library. =A0Solu=
tion:<br>
don&#39;t use OpenSSL. =A0I propose we don&#39;t get bogged down in the cer=
tificate<br>
problem for the moment.<br>
<br>
--<br>
<font color=3D"#888888">Joe Hildebrand<br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
woes mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/woes</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001636c5bbf3bd3eef04a9c0fde3--

Date: Fri, 05 Aug 2011 10:26:55 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [woes] Naked Public Key, was: RE:  Proposed charter, post-Quebec edition

On 08/04/2011 10:48 PM, Hal Lockhart wrote:
>  
>> 3) A Standards Track document specifying how to encode public 
>> keys as JSON-structured objects.
>>
> 
> I would like to push back on the idea of only supporting naked public keys. It is my understanding that common cryto libraries, e.g. OpenSSL, expect public keys to be in certificates and the coding to get them to accept a naked key as input is ugly. I don't think they care if the cert is self signed or even signed at all, its just a format issue.

There is a huge difference between a crypto library and a PKIX stack.

Libraries like OpenSSL are mostly about implementing PKIX, the crypto
being a comparatively small part.

Carrying something like OpenSSL just to be able to sign stuff when
you don't require the semantics of a PKIX stack is an unnecessary
requirement.

Having the ability to do raw keys is useful.

	Cheers Leif

Date: Fri, 05 Aug 2011 00:34:32 -0400
From: Joe Hildebrand <[email-masked]>
To: Hal Lockhart <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE:  Proposed charter, post-Quebec edition

On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]> wrote:

>> 3) A Standards Track document specifying how to encode public
>> keys as JSON-structured objects.
>> 
> 
> I would like to push back on the idea of only supporting naked public keys. It
> is my understanding that common cryto libraries, e.g. OpenSSL, expect public
> keys to be in certificates and the coding to get them to accept a naked key as
> input is ugly. I don't think they care if the cert is self signed or even
> signed at all, its just a format issue.

Just doing the math yourself, from scratch, is pretty easy if you have the
bare key.  It's nigh-on trivial if you have a bigint library.  Solution:
don't use OpenSSL.  I propose we don't get bogged down in the certificate
problem for the moment.

-- 
Joe Hildebrand

Date: Fri, 05 Aug 2011 00:32:34 -0400
From: Joe Hildebrand <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>, "Paul C. Bryan" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

That was the original intent, yes.  Any octets, including UTF-8 serialized
JSON, XML, or a picture of a cat.  A *very secure* picture of a cat.

On 8/4/11 3:25 PM, "Richard L. Barnes" <[email-masked]> wrote:

> My understanding was that a JOSE data structure would protect a sequence of
> octets, which could be whatever the signer/encryptor desires.
> 
> JOSE:JSON::CMS:ASN.1
> 
> --Richard 
> 
> 
> On Aug 3, 2011, at 5:13 PM, Paul C. Bryan wrote:
> 
>> On Wed, 2011-08-03 at 14:35 -0600, Matt Miller wrote:
>>> On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:
>>> 
>>>> Paul,
>>>> 
>>>> Looks good.
>>>> 
>>>> Just my clarification, looking at 1) and 2) does it mean that the
>>>> resulting JOSE WG specifications can be applied to non-JSON data
>>>> structures? (I'm ok with this).
>>> 
>>> Yes; at least one of the desired uses is to sign/encrypt XMPP stanzas! (-:
>>> 
>> 
>> For my edification, why would JOSE want to concern itself with
>> representations of other media types, rather than allowing other
>> transformations to deal with this?
>> 
>> Put another way, if there were a method of encapsulating and encoding
>> non-JSON media types in a JSON structure, would JOSE seek to reinvent such a
>> thing, or merely defer to using it?
>> 
>> Paul
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

-- 
Joe Hildebrand

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Aug 2011 13:50:43 -0700
To: Hal Lockhart <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

This is true for TLS, but in general you can get OpenSSL to accept keys tha=
t are
in PKCS #1 format.

Best,
-Ekr

On Thu, Aug 4, 2011 at 1:48 PM, Hal Lockhart <[email-masked]> wrot=
e:
>
>> 3) A Standards Track document specifying how to encode public
>> keys as JSON-structured objects.
>>
>
> I would like to push back on the idea of only supporting naked public key=
s. It is my understanding that common cryto libraries, e.g. OpenSSL, expect=
 public keys to be in certificates and the coding to get them to accept a n=
aked key as input is ugly. I don't think they care if the cert is self sign=
ed or even signed at all, its just a format issue.
>
> Hal
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

Date: Thu, 4 Aug 2011 13:48:08 -0700 (PDT)
From: Hal Lockhart <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked]
Subject: [woes] Naked Public Key, was: RE:  Proposed charter, post-Quebec edition

=20
> 3) A Standards Track document specifying how to encode public=20
> keys as JSON-structured objects.
>=20

I would like to push back on the idea of only supporting naked public keys.=
 It is my understanding that common cryto libraries, e.g. OpenSSL, expect p=
ublic keys to be in certificates and the coding to get them to accept a nak=
ed key as input is ugly. I don't think they care if the cert is self signed=
 or even signed at all, its just a format issue.

Hal

Date: Thu, 4 Aug 2011 13:41:54 -0700 (PDT)
From: Hal Lockhart <[email-masked]>
To: Paul Hoffman <[email-masked]>, Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

+1

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Thursday, August 04, 2011 12:03 PM
> To: Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [woes] Proposed charter, post-Quebec edition
>=20
>=20
>=20
> On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
>=20
> > IMO, symmetric integrity protection is a useful primitive, and it's
> > already part of the
> > JWT spec. I think all that's required here in the charter is to
> > wordsmith it to separate
> > out symmetric from asymmetric integrity algorithms,
>=20
> Current:
> 1) A Standards Track document specifying how to apply a=20
> JSON-structured digital signature to data, including (but not=20
> limited to) JSON data structures. "Digital signature" is=20
> defined as a hash operation followed by a signature operation=20
> using asymmetric keys.
>=20
> It sounds like you would prefer something like:
> 1) A Standards Track document specifying how to apply=20
> integrity protection to data, including (but not limited to)=20
> JSON data structures. This integrity protection can be=20
> achieved with both symmetric and asymmetric algorithms.
>=20
> Is that right?
>=20
> --Paul Hoffman
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 4 Aug 2011 15:25:28 -0400
To: Paul C. Bryan <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

My understanding was that a JOSE data structure would protect a sequence =
of octets, which could be whatever the signer/encryptor desires. =20

JOSE:JSON::CMS:ASN.1

--Richard=20

On Aug 3, 2011, at 5:13 PM, Paul C. Bryan wrote:

> On Wed, 2011-08-03 at 14:35 -0600, Matt Miller wrote:
>> On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:
>>=20
>> > Paul,
>> >=20
>> > Looks good.
>> >=20
>> > Just my clarification, looking at 1) and 2) does it mean that the
>> > resulting JOSE WG specifications can be applied to non-JSON data
>> > structures? (I'm ok with this).
>>=20
>> Yes; at least one of the desired uses is to sign/encrypt XMPP =
stanzas! (-:
>>=20
>=20
> For my edification, why would JOSE want to concern itself with =
representations of other media types, rather than allowing other =
transformations to deal with this?
>=20
> Put another way, if there were a method of encapsulating and encoding =
non-JSON media types in a JSON structure, would JOSE seek to reinvent =
such a thing, or merely defer to using it?
>=20
> Paul
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: Jeremy Laurenson <[email-masked]>
Date: Thu, 4 Aug 2011 14:18:34 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

Agree - I would think the ADs would agree and push back.

On Aug 4, 2011, at 12:11 AM, Phillip Hallam-Baker wrote:

> Is the object here to arrive at an RFC or to arrive at a standard with =
a broad base of support in the web services apps community?
>=20
> If the latter the I suggest much more time so as to have the ability =
to get buy in from the relevant community.
>=20
>=20
> Sent from my angry birds pad
>=20
> On Aug 2, 2011, at 19:13, Paul Hoffman <[email-masked]> wrote:
>=20
>> Here is a proposal for the charter based on the discussion in the BoF =
last week and later discussion with Sean Turner. Comments, praise, =
scorn, etc., are welcome.
>>=20
>> --Paul and Richard
>>=20
>> Javascript Object Signing and Encrypting (jose)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> Background=20
>> ----------
>>=20
>> 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 and digital signatures for data that is being carried =
in JSON format.
>>=20
>> Different proposals for providing such security services have already =
been defined and implemented. This Working Group's task is to =
standardize two security services, encrypting and digitally signing, 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.
>>=20
>> This group is chartered to work on four documents:
>>=20
>> 1) A Standards Track document specifying how to apply a =
JSON-structured digital signature to data, including (but not limited =
to) JSON data structures. "Digital signature" is defined as a hash =
operation followed by a signature operation using asymmetric keys.
>>=20
>> 2) A Standards Track document specifying how to apply a =
JSON-structured encryption to data, including (but not limited to) JSON =
data structures.
>>=20
>> 3) A Standards Track document specifying how to encode public keys as =
JSON-structured objects.
>>=20
>> 4) A Standards Track document specifying mandatory-to-implement =
algorithms for the other three documents.
>>=20
>> The working group may decide to address one or more 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.
>>=20
>> Goals and Milestones=20
>> --------------------
>>=20
>> Aug 2011    Submit JSON object signing document as a WG item.
>>=20
>> Aug 2011    Submit JSON object encryption document as a WG item.
>>=20
>> Aug 2011    Submit JSON key format document as a WG item.
>>=20
>> Aug 2011    Submit JSON algoritm document as a WG item.
>>=20
>> Jan 2012    Start Working Group Last Call on JSON object signing =
document.
>>=20
>> Jan 2012    Start Working Group Last Call on JSON object encryption =
document.
>>=20
>> Jan 2012    Start Working Group Last Call on JSON key format =
document.
>>=20
>> Jan 2012    Start Working Group Last Call on JSON algorithm document.
>>=20
>> Feb 2012    Submit JSON object signing document to IESG for =
consideration as=20
>> Standards Track document.
>>=20
>> Feb 2012    Submit JSON object encryption document to IESG for =
consideration=20
>> as Standards Track document.
>>=20
>> Feb 2012    Submit JSON key format document to IESG for consideration=20=

>> as Standards Track document.
>>=20
>> Feb 2012    Submit JSON algorithm document to IESG for consideration=20=

>> as Standards Track document.
>>=20
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Thu, 04 Aug 2011 09:19:10 -0700
Subject: Re: [woes] Proposed charter, post-Quebec edition

--=-L1j9zVnfoJ2wyMfa5/F5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Thu, 2011-08-04 at 09:02 -0700, Paul Hoffman wrote:

> On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:
> 
> > IMO, symmetric integrity protection is a useful primitive, and it's
> > already part of the
> > JWT spec. I think all that's required here in the charter is to
> > wordsmith it to separate
> > out symmetric from asymmetric integrity algorithms,
> 
> Current:
> 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.
> 
> It sounds like you would prefer something like:
> 1) A Standards Track document specifying how to apply integrity protection to data, including (but not limited to) JSON data structures. This integrity protection can be achieved with both symmetric and asymmetric algorithms.

+1, or even possibly:

1) A Standards Track document specifying how to ensure the integrity
and/or authenticity of data, including (but not limited to) JSON data
structures. This can be achieved with both symmetric and asymmetric
cryptographic algorithms.

> Is that right?
> 
> --Paul Hoffman
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--=-L1j9zVnfoJ2wyMfa5/F5
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
On Thu, 2011-08-04 at 09:02 -0700, Paul Hoffman wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:

&gt; IMO, symmetric integrity protection is a useful primitive, and it's
&gt; already part of the
&gt; JWT spec. I think all that's required here in the charter is to
&gt; wordsmith it to separate
&gt; out symmetric from asymmetric integrity algorithms,

Current:
1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. &quot;Digital signature&quot; is defined as a hash operation followed by a signature operation using asymmetric keys.

It sounds like you would prefer something like:
1) A Standards Track document specifying how to apply integrity protection to data, including (but not limited to) JSON data structures. This integrity protection can be achieved with both symmetric and asymmetric algorithms.
</PRE>
</BLOCKQUOTE>
<BR>
+1, or even possibly:<BR>
<BR>
1) A Standards Track document specifying how to ensure the integrity and/or authenticity of data, including (but not limited to) JSON data structures. This can be achieved with both symmetric and asymmetric cryptographic algorithms.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Is that right?

--Paul Hoffman

_______________________________________________
woes mailing list
<A HREF="mailto:[email-masked]">[email-masked]</A>
<A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>

--=-L1j9zVnfoJ2wyMfa5/F5--

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 09:02:51 -0700
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

On Aug 4, 2011, at 8:52 AM, Eric Rescorla wrote:

> IMO, symmetric integrity protection is a useful primitive, and it's
> already part of the
> JWT spec. I think all that's required here in the charter is to
> wordsmith it to separate
> out symmetric from asymmetric integrity algorithms,

Current:
1) A Standards Track document specifying how to apply a JSON-structured =
digital signature to data, including (but not limited to) JSON data =
structures. "Digital signature" is defined as a hash operation followed =
by a signature operation using asymmetric keys.

It sounds like you would prefer something like:
1) A Standards Track document specifying how to apply integrity =
protection to data, including (but not limited to) JSON data structures. =
This integrity protection can be achieved with both symmetric and =
asymmetric algorithms.

Is that right?

--Paul Hoffman

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Aug 2011 08:52:32 -0700
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

IMO, symmetric integrity protection is a useful primitive, and it's
already part of the
JWT spec. I think all that's required here in the charter is to
wordsmith it to separate
out symmetric from asymmetric integrity algorithms,

-Ekr

On Thu, Aug 4, 2011 at 8:48 AM, Paul Hoffman <[email-masked]> wrote:
> On Aug 4, 2011, at 8:41 AM, Paul C. Bryan wrote:
>
>> On Thu, 2011-08-04 at 09:03 -0400, Sean Turner wrote:
>>>
>>> I just want to make sure that we agree now that a digital signature is =
a
>>> hash followed by a signature algorithm (e.g., RSA with SHA-256). =A0I'v=
e
>>> seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256)
>>> was a digital signature; one called it a symmetric key based digital
>>> signature algorithm (note this phrase didn't get through the IESG).
>>>
>>
>> I don't agree.
>
> You don't agree with his definition? Where do you see HMACs defined as "d=
igital signatures"?
>
>> I believe we should be able to use this useful plumbing to ensure integr=
ity/authenticity without having to rely exclusively on public key cryptogra=
phy.
>
> That is a separate issue. Are you asking that a fifth item be added to th=
e charter, to define HMAC'd content?
>
> --Paul Hoffman
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 08:48:56 -0700
To: "Paul C. Bryan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

On Aug 4, 2011, at 8:41 AM, Paul C. Bryan wrote:

> On Thu, 2011-08-04 at 09:03 -0400, Sean Turner wrote:
>>=20
>> I just want to make sure that we agree now that a digital signature =
is a=20
>> hash followed by a signature algorithm (e.g., RSA with SHA-256).  =
I've=20
>> seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256)=20=

>> was a digital signature; one called it a symmetric key based digital=20=

>> signature algorithm (note this phrase didn't get through the IESG).
>>=20
>=20
> I don't agree.

You don't agree with his definition? Where do you see HMACs defined as =
"digital signatures"?

> I believe we should be able to use this useful plumbing to ensure =
integrity/authenticity without having to rely exclusively on public key =
cryptography.

That is a separate issue. Are you asking that a fifth item be added to =
the charter, to define HMAC'd content?

--Paul Hoffman

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Thu, 04 Aug 2011 08:41:27 -0700
Subject: Re: [woes] Proposed charter, post-Quebec edition

--=-AEEjo8C29cMgxVn742Hk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Thu, 2011-08-04 at 09:03 -0400, Sean Turner wrote:

> On 8/2/11 7:13 PM, Paul Hoffman wrote:
> > Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.
> >
> > --Paul and Richard
> >
> > Javascript Object Signing and Encrypting (jose)
> > ===============================================
> >
> > Background
> > ----------
> >
> > 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 and digital signatures 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 two security services, encrypting and digitally signing, 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 four documents:
> >
> > 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.
> 
> I just want to make sure that we agree now that a digital signature is a 
> hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've 
> seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) 
> was a digital signature; one called it a symmetric key based digital 
> signature algorithm (note this phrase didn't get through the IESG).

I don't agree. I believe we should be able to use this useful plumbing
to ensure integrity/authenticity without having to rely exclusively on
public key cryptography.

> > 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.
> >
> > 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
> >
> > 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.
> 
> I think this addition is good.  In the past we've bundled the MTI 
> algorithms with the protocol and then reving the MTI algorithms caused 
> unnecessary churn on the protocol even if the protocol is stable.
> 
> I also think this draft need not only include MTI algorithms, but the 
> draft definitely needs to say which ones are the MTI algorithms.
> 
> > The working group may decide to address one or more 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.
> >
> > Aug 2011    Submit JSON key format document as a WG item.
> >
> > Aug 2011    Submit JSON algoritm document as a WG item.
> >
> > Jan 2012    Start Working Group Last Call on JSON object signing document.
> >
> > Jan 2012    Start Working Group Last Call on JSON object encryption document.
> >
> > Jan 2012    Start Working Group Last Call on JSON key format document.
> >
> > Jan 2012    Start Working Group Last Call on JSON algorithm document.
> >
> > Feb 2012    Submit JSON object signing document to IESG for consideration as
> > Standards Track document.
> >
> > Feb 2012    Submit JSON object encryption document to IESG for consideration
> > as Standards Track document.
> >
> > Feb 2012    Submit JSON key format document to IESG for consideration
> > as Standards Track document.
> >
> > Feb 2012    Submit JSON algorithm document to IESG for consideration
> > as Standards Track document.
> 
> The dates are little ambitious.  Just based on the process, I doubt this 
> can be charter by the end of August.  I'd swap Aug->Oct, Jan->Mar, and 
> leave Feb as-is.

I agree, though IMO the sooner we can get strawman drafts out to start
taking shots at, the better.

> spt
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--=-AEEjo8C29cMgxVn742Hk
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
On Thu, 2011-08-04 at 09:03 -0400, Sean Turner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 8/2/11 7:13 PM, Paul Hoffman wrote:
&gt; Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.
&gt;
&gt; --Paul and Richard
&gt;
&gt; Javascript Object Signing and Encrypting (jose)
&gt; ===============================================
&gt;
&gt; Background
&gt; ----------
&gt;
&gt; 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 and digital signatures for data that is being carried in JSON format.
&gt;
&gt; Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, encrypting and digitally signing, 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.
&gt;
&gt; This group is chartered to work on four documents:
&gt;
&gt; 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. &quot;Digital signature&quot; is defined as a hash operation followed by a signature operation using asymmetric keys.

I just want to make sure that we agree now that a digital signature is a 
hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've 
seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) 
was a digital signature; one called it a symmetric key based digital 
signature algorithm (note this phrase didn't get through the IESG).
</PRE>
</BLOCKQUOTE>
<BR>
I don't agree. I believe we should be able to use this useful plumbing to ensure integrity/authenticity without having to rely exclusively on public key cryptography.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
&gt; 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.
&gt;
&gt; 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
&gt;
&gt; 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.

I think this addition is good.  In the past we've bundled the MTI 
algorithms with the protocol and then reving the MTI algorithms caused 
unnecessary churn on the protocol even if the protocol is stable.

I also think this draft need not only include MTI algorithms, but the 
draft definitely needs to say which ones are the MTI algorithms.

&gt; The working group may decide to address one or more 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.
&gt;
&gt; Goals and Milestones
&gt; --------------------
&gt;
&gt; Aug 2011    Submit JSON object signing document as a WG item.
&gt;
&gt; Aug 2011    Submit JSON object encryption document as a WG item.
&gt;
&gt; Aug 2011    Submit JSON key format document as a WG item.
&gt;
&gt; Aug 2011    Submit JSON algoritm document as a WG item.
&gt;
&gt; Jan 2012    Start Working Group Last Call on JSON object signing document.
&gt;
&gt; Jan 2012    Start Working Group Last Call on JSON object encryption document.
&gt;
&gt; Jan 2012    Start Working Group Last Call on JSON key format document.
&gt;
&gt; Jan 2012    Start Working Group Last Call on JSON algorithm document.
&gt;
&gt; Feb 2012    Submit JSON object signing document to IESG for consideration as
&gt; Standards Track document.
&gt;
&gt; Feb 2012    Submit JSON object encryption document to IESG for consideration
&gt; as Standards Track document.
&gt;
&gt; Feb 2012    Submit JSON key format document to IESG for consideration
&gt; as Standards Track document.
&gt;
&gt; Feb 2012    Submit JSON algorithm document to IESG for consideration
&gt; as Standards Track document.

The dates are little ambitious.  Just based on the process, I doubt this 
can be charter by the end of August.  I'd swap Aug-&gt;Oct, Jan-&gt;Mar, and 
leave Feb as-is.
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
I agree, though IMO the sooner we can get strawman drafts out to start taking shots at, the better.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
spt
_______________________________________________
woes mailing list
<A HREF="mailto:[email-masked]">[email-masked]</A>
<A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>

--=-AEEjo8C29cMgxVn742Hk--

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 10:07:39 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail=_072583CE-E940-440C-8DB1-B3E3DE558819
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8FCA2675-4F52-4A30-A819-61EB70DAADAA"

--Apple-Mail=_8FCA2675-4F52-4A30-A819-61EB70DAADAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

The URL safe serialization in JWS/JWE is period separated base64url =
encoded strings.
Envalope.payload.signature  as an example.

For JWE the encryption is performed on the raw object, and the result of =
that is base64 encoded.

One of the requirements for signing is to avoid double base64 encoding.  =
 That is why the body is separate from the envelope and signature.

We seem to be keen to get on with the work, and that is good. =20

However for the moment we should probably concentrate on the charter.

So are there specific things you want in the charter to be able to =
address a proposed use case?

John B.

On 2011-08-04, at 9:38 AM, Phillip Hallam-Baker wrote:

> Since we are doing encryption as well, there are two problems needing =
a common solution.=20
>=20
>=20
> Let us say we are encrypting a blob of data - 200K or so. Do we really =
want to have a JSON structure with the data blob JSON encoded?
>=20
> For that and for the signing case I think we are going to want a =
structure that is something like:
>=20
> Package
>     [Type=3DJSON Length=3D203 bytes]
>         <Encryption stuff>
>     [ID=3D2as9uas9u9 Length=3D293939933 bytes]
>         <Binary blob>=20
>   =20
> Ascii encoding for control data is good, it helps debugging etc. But =
Ascii encoding JPEG bytes does not really help me much.
>=20
> The package could even be as simple as a JSON control block that gives =
the length of a data blob that is to follow immediately.
>=20
>=20
> On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <[email-masked]> =
wrote:
> XPath is NOT the way to go.  No argument from me.
>=20
> The JWS spec has admittedly been focused on allowing JSON to be used =
as tokens for OAuth and openID.
>=20
> Those need to be passed around in a URL safe way,  so we need a =
serialization that supports that.
>=20
> In Quebec we did touch on alternate serializations that may be more =
suitable for other use cases.
>=20
> I suspect that signing a manifest/reference is something we should be =
able to support in the JOSE spec. =20
>=20
> Finding the best way to accommodate they without complicating the =
simpler cases is something that should be explored.
>=20
> John B.
>=20
> On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:
>=20
>>=20
>>=20
>> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email-masked]> =
wrote:
>> In the JWS/JWE drafts the goal was to provide JSON envelopes for =
base64url encoded blobs.
>>=20
>> In most cased we intend for those to be JSON, but nothing prevents =
this from being used with XML similar to the failed SAML simple sign.
>>=20
>> With JSON payloads we really wanted to avoid touching the payload.  =
Inserting elements, canonicalization  and other things that touch the =
payload are highly problematic.
>>=20
>> I really want to avoid C18N as well. The problem is how to do it.
>>=20
>> If the data object is small it is no big deal base64 encoding it and =
storing it as an attribute.
>>=20
>> But if the data object is larger (XML document, image, etc.) then =
some form of indirection is going to be necessary. For example take the =
digest of the data and sign that or if multiple objects are involved =
some sort of manifest scheme.
>>=20
>>=20
>> I really don't want to have to BASE64 a multimedia stream. So I think =
I am going to need some MIME like packaging scheme that allows us to =
send a JSON structure with attachments. I think that is going to be a =
very common requirement for others as well and I would like that to be a =
part of the standards toolkit rather than have to re-invent it for each =
protocol.=20
>>=20
>>=20
>> Another very common corner case that is related is how to take a =
standard data object such as a JPEG, sign it and then attach the =
signature inside the data object.=20
>>=20
>> The blunder committed in XML Signature was to use XPath for that =
which introduced a mechanism for arbitrary transformations - yuk!
>>=20
>> I really don't want to specify the precise means of embedding =
signatures in various media types but I certainly need an approach that =
makes it possible to use the spec as a basis for doing that.=20
>>=20
>>=20
>> --=20
>> Website: http://hallambaker.com/
>>=20
>=20
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

--Apple-Mail=_8FCA2675-4F52-4A30-A819-61EB70DAADAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">The&nbsp;URL safe&nbsp;serialization in JWS/JWE is period separated =
base64url encoded strings.<div>Envalope.payload.signature &nbsp;as an =
example.</div><div><br></div><div>For JWE the encryption is performed on =
the raw object, and the result of that is base64 =
encoded.</div><div><br></div><div>One of the requirements for signing is =
to avoid double base64 encoding. &nbsp; That is why the body is separate =
from the envelope and signature.</div><div><br></div><div>We seem to be =
keen to get on with the work, and that is good. =
&nbsp;</div><div><br></div><div>However for the moment we should =
probably concentrate on the charter.</div><div><br></div><div>So are =
there specific things you want in the charter to be able to address a =
proposed use case?</div><div><br></div><div>John =
B.</div><div><br><div><div>On 2011-08-04, at 9:38 AM, Phillip =
Hallam-Baker wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Since we =
are doing encryption as well, there are two problems needing a common =
solution.&nbsp;<div><br></div><div><br></div><div>Let us say we are =
encrypting a blob of data - 200K or so. Do we really want to have a JSON =
structure with the data blob JSON encoded?</div>
<div><br></div><div>For that and for the signing case I think we are =
going to want a structure that is something =
like:</div><div><br></div><div><font class=3D"Apple-style-span" =
face=3D"'courier new', monospace">Package</font></div>
<div><font class=3D"Apple-style-span" face=3D"'courier new', =
monospace">&nbsp; &nbsp; [Type=3DJSON Length=3D203 =
bytes]</font></div><div><font class=3D"Apple-style-span" face=3D"'courier =
new', monospace">&nbsp; &nbsp; &nbsp; &nbsp; &lt;Encryption =
stuff&gt;</font></div>
<div><font class=3D"Apple-style-span" face=3D"'courier new', =
monospace">&nbsp; &nbsp; [ID=3D2as9uas9u9 Length=3D293939933 =
bytes]</font></div><div><font class=3D"Apple-style-span" face=3D"'courier =
new', monospace">&nbsp; &nbsp; &nbsp; &nbsp; &lt;Binary =
blob&gt;&nbsp;</font></div>
<div>&nbsp; &nbsp;</div><div>Ascii encoding for control data is good, it =
helps debugging etc. But Ascii encoding JPEG bytes does not really help =
me much.<br><br></div><div>The package could even be as simple as a JSON =
control block that gives the length of a data blob that is to follow =
immediately.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 =
at 9:25 AM, John Bradley <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word">XPath is NOT the way to go. &nbsp;No =
argument from me.<div><br></div><div>The JWS spec has admittedly been =
focused on allowing JSON to be used as tokens for OAuth and =
openID.</div><div><br></div>
<div>Those need to be passed around in a URL safe way, &nbsp;so we need =
a serialization that supports that.</div><div><br></div><div>In Quebec =
we did touch on alternate serializations that may be more suitable for =
other use cases.</div>
<div><br></div><div>I suspect that signing a manifest/reference is =
something we should be able to support in the JOSE spec. =
&nbsp;</div><div><br></div><div>Finding the best way to accommodate they =
without complicating the simpler cases is something that should be =
explored.</div>
<div><br></div><div>John B.<div><div></div><div =
class=3D"h5"><br><div><div>On 2011-08-04, at 9:03 AM, Phillip =
Hallam-Baker wrote:</div><br><blockquote type=3D"cite"><br><br><div =
class=3D"gmail_quote">On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <span =
dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" =
target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
In the JWS/JWE drafts the goal was to provide JSON envelopes for =
base64url encoded blobs.<br>
<br>
In most cased we intend for those to be JSON, but nothing prevents this =
from being used with XML similar to the failed SAML simple sign.<br>
<br>
With JSON payloads we really wanted to avoid touching the payload. =
&nbsp;Inserting elements, canonicalization &nbsp;and other things that =
touch the payload are highly =
problematic.<br></blockquote><div><br></div><div>I really want to avoid =
C18N as well. The problem is how to do it.</div>

<div><br></div><div>If the data object is small it is no big deal base64 =
encoding it and storing it as an attribute.</div><div><br></div><div>But =
if the data object is larger (XML document, image, etc.) then some form =
of indirection is going to be necessary. For example take the digest of =
the data and sign that or if multiple objects are involved some sort of =
manifest scheme.</div>

<div><br></div><div><br></div><div>I really don't want to have to BASE64 =
a multimedia stream. So I think I am going to need some MIME like =
packaging scheme that allows us to send a JSON structure with =
attachments. I think that is going to be a very common requirement for =
others as well and I would like that to be a part of the standards =
toolkit rather than have to re-invent it for each protocol.&nbsp;</div>

<div><br></div><div><br></div><div>Another very common corner case that =
is related is how to take a standard data object such as a JPEG, sign it =
and then attach the signature inside the data =
object.&nbsp;</div><div><br></div>
<div>
The blunder committed in XML Signature was to use XPath for that which =
introduced a mechanism for arbitrary transformations - =
yuk!</div><div><br></div><div>I really don't want to specify the precise =
means of embedding signatures in various media types but I certainly =
need an approach that makes it possible to use the spec as a basis for =
doing that.&nbsp;</div>

<div><br></div><div><br></div></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/" =
target=3D"_blank">http://hallambaker.com/</a><br><br>
=
</blockquote></div><br></div></div></div></div></blockquote></div><br><br =
clear=3D"all"><br>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>
</blockquote></div><br></div></body></html>=

--Apple-Mail=_8FCA2675-4F52-4A30-A819-61EB70DAADAA--

--Apple-Mail=_072583CE-E940-440C-8DB1-B3E3DE558819
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_072583CE-E940-440C-8DB1-B3E3DE558819--

From: Matt Miller <[email-masked]>
Date: Thu, 4 Aug 2011 08:03:33 -0600
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail-16--848035747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Aug 4, 2011, at 07:38, Phillip Hallam-Baker wrote:

> Since we are doing encryption as well, there are two problems needing =
a common solution.=20
>=20
>=20
> Let us say we are encrypting a blob of data - 200K or so. Do we really =
want to have a JSON structure with the data blob JSON encoded?
>=20
> For that and for the signing case I think we are going to want a =
structure that is something like:
>=20
> Package
>     [Type=3DJSON Length=3D203 bytes]
>         <Encryption stuff>
>     [ID=3D2as9uas9u9 Length=3D293939933 bytes]
>         <Binary blob>=20
>   =20
> Ascii encoding for control data is good, it helps debugging etc. But =
Ascii encoding JPEG bytes does not really help me much.
>=20
> The package could even be as simple as a JSON control block that gives =
the length of a data blob that is to follow immediately.
>=20
>=20

We need to be *VERY* careful if the data ends up outside of the =
envelope.  There are lots and lots of use cases where the data to be =
transferred is somewhat small (<1k), and there isn't a good mechanism =
for holding onto that outside data.

We can't make the assumption that the only transport is HTTP!

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

> On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <[email-masked]> =
wrote:
> XPath is NOT the way to go.  No argument from me.
>=20
> The JWS spec has admittedly been focused on allowing JSON to be used =
as tokens for OAuth and openID.
>=20
> Those need to be passed around in a URL safe way,  so we need a =
serialization that supports that.
>=20
> In Quebec we did touch on alternate serializations that may be more =
suitable for other use cases.
>=20
> I suspect that signing a manifest/reference is something we should be =
able to support in the JOSE spec. =20
>=20
> Finding the best way to accommodate they without complicating the =
simpler cases is something that should be explored.
>=20
> John B.
>=20
> On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:
>=20
>>=20
>>=20
>> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email-masked]> =
wrote:
>> In the JWS/JWE drafts the goal was to provide JSON envelopes for =
base64url encoded blobs.
>>=20
>> In most cased we intend for those to be JSON, but nothing prevents =
this from being used with XML similar to the failed SAML simple sign.
>>=20
>> With JSON payloads we really wanted to avoid touching the payload.  =
Inserting elements, canonicalization  and other things that touch the =
payload are highly problematic.
>>=20
>> I really want to avoid C18N as well. The problem is how to do it.
>>=20
>> If the data object is small it is no big deal base64 encoding it and =
storing it as an attribute.
>>=20
>> But if the data object is larger (XML document, image, etc.) then =
some form of indirection is going to be necessary. For example take the =
digest of the data and sign that or if multiple objects are involved =
some sort of manifest scheme.
>>=20
>>=20
>> I really don't want to have to BASE64 a multimedia stream. So I think =
I am going to need some MIME like packaging scheme that allows us to =
send a JSON structure with attachments. I think that is going to be a =
very common requirement for others as well and I would like that to be a =
part of the standards toolkit rather than have to re-invent it for each =
protocol.=20
>>=20
>>=20
>> Another very common corner case that is related is how to take a =
standard data object such as a JPEG, sign it and then attach the =
signature inside the data object.=20
>>=20
>> The blunder committed in XML Signature was to use XPath for that =
which introduced a mechanism for arbitrary transformations - yuk!
>>=20
>> I really don't want to specify the precise means of embedding =
signatures in various media types but I certainly need an approach that =
makes it possible to use the spec as a basis for doing that.=20
>>=20
>>=20
>> --=20
>> Website: http://hallambaker.com/
>>=20
>=20
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail-16--848035747
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-16--848035747--

Date: Thu, 4 Aug 2011 09:38:42 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: John Bradley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--0016e6d26d726a2ebd04a9ae19aa
Content-Type: text/plain; charset=ISO-8859-1

Since we are doing encryption as well, there are two problems needing a
common solution.

Let us say we are encrypting a blob of data - 200K or so. Do we really want
to have a JSON structure with the data blob JSON encoded?

For that and for the signing case I think we are going to want a structure
that is something like:

Package
    [Type=JSON Length=203 bytes]
        <Encryption stuff>
    [ID=2as9uas9u9 Length=293939933 bytes]
        <Binary blob>

Ascii encoding for control data is good, it helps debugging etc. But Ascii
encoding JPEG bytes does not really help me much.

The package could even be as simple as a JSON control block that gives the
length of a data blob that is to follow immediately.

On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <[email-masked]> wrote:

> XPath is NOT the way to go.  No argument from me.
>
> The JWS spec has admittedly been focused on allowing JSON to be used as
> tokens for OAuth and openID.
>
> Those need to be passed around in a URL safe way,  so we need a
> serialization that supports that.
>
> In Quebec we did touch on alternate serializations that may be more
> suitable for other use cases.
>
> I suspect that signing a manifest/reference is something we should be able
> to support in the JOSE spec.
>
> Finding the best way to accommodate they without complicating the simpler
> cases is something that should be explored.
>
> John B.
>
> On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:
>
>
>
> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email-masked]> wrote:
>
>> In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url
>> encoded blobs.
>>
>> In most cased we intend for those to be JSON, but nothing prevents this
>> from being used with XML similar to the failed SAML simple sign.
>>
>> With JSON payloads we really wanted to avoid touching the payload.
>>  Inserting elements, canonicalization  and other things that touch the
>> payload are highly problematic.
>>
>
> I really want to avoid C18N as well. The problem is how to do it.
>
> If the data object is small it is no big deal base64 encoding it and
> storing it as an attribute.
>
> But if the data object is larger (XML document, image, etc.) then some form
> of indirection is going to be necessary. For example take the digest of the
> data and sign that or if multiple objects are involved some sort of manifest
> scheme.
>
>
> I really don't want to have to BASE64 a multimedia stream. So I think I am
> going to need some MIME like packaging scheme that allows us to send a JSON
> structure with attachments. I think that is going to be a very common
> requirement for others as well and I would like that to be a part of the
> standards toolkit rather than have to re-invent it for each protocol.
>
>
> Another very common corner case that is related is how to take a standard
> data object such as a JPEG, sign it and then attach the signature inside the
> data object.
>
> The blunder committed in XML Signature was to use XPath for that which
> introduced a mechanism for arbitrary transformations - yuk!
>
> I really don't want to specify the precise means of embedding signatures in
> various media types but I certainly need an approach that makes it possible
> to use the spec as a basis for doing that.
>
>
> --
> Website: http://hallambaker.com/
>
>
>

-- 
Website: http://hallambaker.com/

--0016e6d26d726a2ebd04a9ae19aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Since we are doing encryption as well, there are two problems needing a com=
mon solution.=A0<div><br></div><div><br></div><div>Let us say we are encryp=
ting a blob of data - 200K or so. Do we really want to have a JSON structur=
e with the data blob JSON encoded?</div>
<div><br></div><div>For that and for the signing case I think we are going =
to want a structure that is something like:</div><div><br></div><div><font =
class=3D"Apple-style-span" face=3D"&#39;courier new&#39;, monospace">Packag=
e</font></div>
<div><font class=3D"Apple-style-span" face=3D"&#39;courier new&#39;, monosp=
ace">=A0 =A0 [Type=3DJSON Length=3D203 bytes]</font></div><div><font class=
=3D"Apple-style-span" face=3D"&#39;courier new&#39;, monospace">=A0 =A0 =A0=
 =A0 &lt;Encryption stuff&gt;</font></div>
<div><font class=3D"Apple-style-span" face=3D"&#39;courier new&#39;, monosp=
ace">=A0 =A0 [ID=3D2as9uas9u9 Length=3D293939933 bytes]</font></div><div><f=
ont class=3D"Apple-style-span" face=3D"&#39;courier new&#39;, monospace">=
=A0 =A0 =A0 =A0 &lt;Binary blob&gt;=A0</font></div>
<div>=A0 =A0</div><div>Ascii encoding for control data is good, it helps de=
bugging etc. But Ascii encoding JPEG bytes does not really help me much.<br=
><br></div><div>The package could even be as simple as a JSON control block=
 that gives the length of a data blob that is to follow immediately.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 at 9=
:25 AM, John Bradley <span dir=3D"ltr">&lt;<a href=3D"mailto:ve7jtb@ve7jtb.=
com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
<div style=3D"word-wrap:break-word">XPath is NOT the way to go. =A0No argum=
ent from me.<div><br></div><div>The JWS spec has admittedly been focused on=
 allowing JSON to be used as tokens for OAuth and openID.</div><div><br></d=
iv>
<div>Those need to be passed around in a URL safe way, =A0so we need a seri=
alization that supports that.</div><div><br></div><div>In Quebec we did tou=
ch on alternate serializations that may be more suitable for other use case=
s.</div>
<div><br></div><div>I suspect that signing a manifest/reference is somethin=
g we should be able to support in the JOSE spec. =A0</div><div><br></div><d=
iv>Finding the best way to accommodate they without complicating the simple=
r cases is something that should be explored.</div>
<div><br></div><div>John B.<div><div></div><div class=3D"h5"><br><div><div>=
On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:</div><br><blockquote=
 type=3D"cite"><br><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 at 8:=
52 AM, John Bradley <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
om" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url =
encoded blobs.<br>
<br>
In most cased we intend for those to be JSON, but nothing prevents this fro=
m being used with XML similar to the failed SAML simple sign.<br>
<br>
With JSON payloads we really wanted to avoid touching the payload. =A0Inser=
ting elements, canonicalization =A0and other things that touch the payload =
are highly problematic.<br></blockquote><div><br></div><div>I really want t=
o avoid C18N as well. The problem is how to do it.</div>

<div><br></div><div>If the data object is small it is no big deal base64 en=
coding it and storing it as an attribute.</div><div><br></div><div>But if t=
he data object is larger (XML document, image, etc.) then some form of indi=
rection is going to be necessary. For example take the digest of the data a=
nd sign that or if multiple objects are involved some sort of manifest sche=
me.</div>

<div><br></div><div><br></div><div>I really don&#39;t want to have to BASE6=
4 a multimedia stream. So I think I am going to need some MIME like packagi=
ng scheme that allows us to send a JSON structure with attachments. I think=
 that is going to be a very common requirement for others as well and I wou=
ld like that to be a part of the standards toolkit rather than have to re-i=
nvent it for each protocol.=A0</div>

<div><br></div><div><br></div><div>Another very common corner case that is =
related is how to take a standard data object such as a JPEG, sign it and t=
hen attach the signature inside the data object.=A0</div><div><br></div>
<div>
The blunder committed in XML Signature was to use XPath for that which intr=
oduced a mechanism for arbitrary transformations - yuk!</div><div><br></div=
><div>I really don&#39;t want to specify the precise means of embedding sig=
natures in various media types but I certainly need an approach that makes =
it possible to use the spec as a basis for doing that.=A0</div>

<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/" target=3D"_blank">http://hallambaker.com/</a><br><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br c=
lear=3D"all"><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http:/=
/hallambaker.com/</a><br><br>
</div>

--0016e6d26d726a2ebd04a9ae19aa--

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 09:29:46 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail=_D43A7525-9DB0-4A93-8597-4D548C657C49
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B5B29FA0-DC5C-482A-9CB5-69C6E4654A3C"

--Apple-Mail=_B5B29FA0-DC5C-482A-9CB5-69C6E4654A3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

HMAC is requirement for adoption in the JWS use cases.

If we want to describe it as something other than a "Qualified Digital =
Signature",  that is fine as long as it is MTI:)

John B.

On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:

>=20
>=20
> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]> wrote:
> On 8/2/11 7:13 PM, Paul Hoffman wrote:
> Here is a proposal for the charter based on the discussion in the BoF =
last week and later discussion with Sean Turner. Comments, praise, =
scorn, etc., are welcome.
>=20
> --Paul and Richard
>=20
> Javascript Object Signing and Encrypting (jose)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Background
> ----------
>=20
> 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 and digital signatures for data that is being carried =
in JSON format.
>=20
> Different proposals for providing such security services have already =
been defined and implemented. This Working Group's task is to =
standardize two security services, encrypting and digitally signing, 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.
>=20
> This group is chartered to work on four documents:
>=20
> 1) A Standards Track document specifying how to apply a =
JSON-structured digital signature to data, including (but not limited =
to) JSON data structures. "Digital signature" is defined as a hash =
operation followed by a signature operation using asymmetric keys.
>=20
> I just want to make sure that we agree now that a digital signature is =
a hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've =
seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) =
was a digital signature; one called it a symmetric key based digital =
signature algorithm (note this phrase didn't get through the IESG).
>=20
> An HMAC is not a digital signature, but the spec definitely needs to =
be able to cover MAC based authentication.
>=20
>=20
> I know that public key is getting easier as far as computation goes. =
But for many applications the non-repudiation you get in digital =
signatures is actually undesirable.
>=20
> There are interesting tricks you can do with symmetric crypto that are =
much harder to do in public key and end up with some scheme that only 50 =
academics in the world can follow and has a security proof that rest on =
rather esoteric assumptions.
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_B5B29FA0-DC5C-482A-9CB5-69C6E4654A3C
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">HMAC is requirement for adoption in the JWS use cases.<div><br></div><div>If we want to describe it as something other than a "Qualified Digital Signature", &nbsp;that is fine as long as it is MTI:)</div><div><br></div><div>John B.</div><div><br></div><div><br><div><div>On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 8/2/11 7:13 PM, Paul Hoffman wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.<br>
<br>
--Paul and Richard<br>
<br>
Javascript Object Signing and Encrypting (jose)<br>
==============================<u></u>=================<br>
<br>
Background<br>
----------<br>
<br>
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 and digital signatures for data that is being carried in JSON format.<br>

<br>
Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, encrypting and digitally signing, in order to increase interoperability of security features between protocols that use JSON. &nbsp;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.<br>

<br>
This group is chartered to work on four documents:<br>
<br>
1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.<br>

</blockquote>
<br></div>
I just want to make sure that we agree now that a digital signature is a hash followed by a signature algorithm (e.g., RSA with SHA-256). &nbsp;I've seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a symmetric key based digital signature algorithm (note this phrase didn't get through the IESG).</blockquote>
<div><br></div><div>An HMAC is not a digital signature, but the spec definitely needs to be able to cover MAC based authentication.</div><div><br></div><div><br></div><div>I know that public key is getting easier as far as computation goes. But for many applications the non-repudiation you get in digital signatures is actually undesirable.</div>
<div><br></div><div>There are interesting tricks you can do with symmetric crypto that are much harder to do in public key and end up with some scheme that only 50 academics in the world can follow and has a security proof that rest on rather esoteric assumptions.</div>
<div><br></div></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
_______________________________________________<br>woes mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/woes<br></blockquote></div><br></div></body></html>
--Apple-Mail=_B5B29FA0-DC5C-482A-9CB5-69C6E4654A3C--

--Apple-Mail=_D43A7525-9DB0-4A93-8597-4D548C657C49
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_D43A7525-9DB0-4A93-8597-4D548C657C49--

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 09:25:17 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail=_5F9D3F7B-9020-4CD7-AC91-52B6997A60AD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_630B7ECC-7A13-477E-9416-EC65D555EBC1"

--Apple-Mail=_630B7ECC-7A13-477E-9416-EC65D555EBC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

XPath is NOT the way to go.  No argument from me.

The JWS spec has admittedly been focused on allowing JSON to be used as =
tokens for OAuth and openID.

Those need to be passed around in a URL safe way,  so we need a =
serialization that supports that.

In Quebec we did touch on alternate serializations that may be more =
suitable for other use cases.

I suspect that signing a manifest/reference is something we should be =
able to support in the JOSE spec. =20

Finding the best way to accommodate they without complicating the =
simpler cases is something that should be explored.

John B.
On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:

>=20
>=20
> On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email-masked]> =
wrote:
> In the JWS/JWE drafts the goal was to provide JSON envelopes for =
base64url encoded blobs.
>=20
> In most cased we intend for those to be JSON, but nothing prevents =
this from being used with XML similar to the failed SAML simple sign.
>=20
> With JSON payloads we really wanted to avoid touching the payload.  =
Inserting elements, canonicalization  and other things that touch the =
payload are highly problematic.
>=20
> I really want to avoid C18N as well. The problem is how to do it.
>=20
> If the data object is small it is no big deal base64 encoding it and =
storing it as an attribute.
>=20
> But if the data object is larger (XML document, image, etc.) then some =
form of indirection is going to be necessary. For example take the =
digest of the data and sign that or if multiple objects are involved =
some sort of manifest scheme.
>=20
>=20
> I really don't want to have to BASE64 a multimedia stream. So I think =
I am going to need some MIME like packaging scheme that allows us to =
send a JSON structure with attachments. I think that is going to be a =
very common requirement for others as well and I would like that to be a =
part of the standards toolkit rather than have to re-invent it for each =
protocol.=20
>=20
>=20
> Another very common corner case that is related is how to take a =
standard data object such as a JPEG, sign it and then attach the =
signature inside the data object.=20
>=20
> The blunder committed in XML Signature was to use XPath for that which =
introduced a mechanism for arbitrary transformations - yuk!
>=20
> I really don't want to specify the precise means of embedding =
signatures in various media types but I certainly need an approach that =
makes it possible to use the spec as a basis for doing that.=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

--Apple-Mail=_630B7ECC-7A13-477E-9416-EC65D555EBC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">XPath =
is NOT the way to go. &nbsp;No argument from me.<div><br></div><div>The =
JWS spec has admittedly been focused on allowing JSON to be used as =
tokens for OAuth and openID.</div><div><br></div><div>Those need to be =
passed around in a URL safe way, &nbsp;so we need a serialization that =
supports that.</div><div><br></div><div>In Quebec we did touch on =
alternate serializations that may be more suitable for other use =
cases.</div><div><br></div><div>I suspect that signing a =
manifest/reference is something we should be able to support in the JOSE =
spec. &nbsp;</div><div><br></div><div>Finding the best way to =
accommodate they without complicating the simpler cases is something =
that should be explored.</div><div><br></div><div>John =
B.<br><div><div>On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><br><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 at =
8:52 AM, John Bradley <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
In the JWS/JWE drafts the goal was to provide JSON envelopes for =
base64url encoded blobs.<br>
<br>
In most cased we intend for those to be JSON, but nothing prevents this =
from being used with XML similar to the failed SAML simple sign.<br>
<br>
With JSON payloads we really wanted to avoid touching the payload. =
&nbsp;Inserting elements, canonicalization &nbsp;and other things that =
touch the payload are highly =
problematic.<br></blockquote><div><br></div><div>I really want to avoid =
C18N as well. The problem is how to do it.</div>
<div><br></div><div>If the data object is small it is no big deal base64 =
encoding it and storing it as an attribute.</div><div><br></div><div>But =
if the data object is larger (XML document, image, etc.) then some form =
of indirection is going to be necessary. For example take the digest of =
the data and sign that or if multiple objects are involved some sort of =
manifest scheme.</div>
<div><br></div><div><br></div><div>I really don't want to have to BASE64 =
a multimedia stream. So I think I am going to need some MIME like =
packaging scheme that allows us to send a JSON structure with =
attachments. I think that is going to be a very common requirement for =
others as well and I would like that to be a part of the standards =
toolkit rather than have to re-invent it for each protocol.&nbsp;</div>
<div><br></div><div><br></div><div>Another very common corner case that =
is related is how to take a standard data object such as a JPEG, sign it =
and then attach the signature inside the data =
object.&nbsp;</div><div><br></div><div>
The blunder committed in XML Signature was to use XPath for that which =
introduced a mechanism for arbitrary transformations - =
yuk!</div><div><br></div><div>I really don't want to specify the precise =
means of embedding signatures in various media types but I certainly =
need an approach that makes it possible to use the spec as a basis for =
doing that.&nbsp;</div>
<div><br></div><div><br></div></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</blockquote></div><br></div></body></html>=

--Apple-Mail=_630B7ECC-7A13-477E-9416-EC65D555EBC1--

--Apple-Mail=_5F9D3F7B-9020-4CD7-AC91-52B6997A60AD
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_5F9D3F7B-9020-4CD7-AC91-52B6997A60AD--

Date: Thu, 4 Aug 2011 09:12:57 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

--00163691fc2d5892d704a9adbd84
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]> wrote:

> On 8/2/11 7:13 PM, Paul Hoffman wrote:
>
>> Here is a proposal for the charter based on the discussion in the BoF last
>> week and later discussion with Sean Turner. Comments, praise, scorn, etc.,
>> are welcome.
>>
>> --Paul and Richard
>>
>> Javascript Object Signing and Encrypting (jose)
>> ==============================**=================
>>
>> Background
>> ----------
>>
>> 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 and digital
>> signatures 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 two
>> security services, encrypting and digitally signing, 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 four documents:
>>
>> 1) A Standards Track document specifying how to apply a JSON-structured
>> digital signature to data, including (but not limited to) JSON data
>> structures. "Digital signature" is defined as a hash operation followed by a
>> signature operation using asymmetric keys.
>>
>
> I just want to make sure that we agree now that a digital signature is a
> hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've seen
> a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a
> digital signature; one called it a symmetric key based digital signature
> algorithm (note this phrase didn't get through the IESG).

An HMAC is not a digital signature, but the spec definitely needs to be able
to cover MAC based authentication.

I know that public key is getting easier as far as computation goes. But for
many applications the non-repudiation you get in digital signatures is
actually undesirable.

There are interesting tricks you can do with symmetric crypto that are much
harder to do in public key and end up with some scheme that only 50
academics in the world can follow and has a security proof that rest on
rather esoteric assumptions.

-- 
Website: http://hallambaker.com/

--00163691fc2d5892d704a9adbd84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 at 9:03 AM, Sean Tur=
ner <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">turners@ieca.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 8/2/11 7:13 PM, Paul Hoffman wrote:<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is a proposal for the charter based on the discussion in the BoF last =
week and later discussion with Sean Turner. Comments, praise, scorn, etc., =
are welcome.<br>
<br>
--Paul and Richard<br>
<br>
Javascript Object Signing and Encrypting (jose)<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D<u></u>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<b=
r>
<br>
Background<br>
----------<br>
<br>
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 s=
erializing 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 and digital s=
ignatures for data that is being carried in JSON format.<br>

<br>
Different proposals for providing such security services have already been =
defined and implemented. This Working Group&#39;s task is to standardize tw=
o security services, encrypting and digitally signing, in order to increase=
 interoperability of security features between protocols that use JSON. =A0=
The Working Group will base its work on well-known message security primiti=
ves (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 corre=
ct.<br>

<br>
This group is chartered to work on four documents:<br>
<br>
1) A Standards Track document specifying how to apply a JSON-structured dig=
ital signature to data, including (but not limited to) JSON data structures=
. &quot;Digital signature&quot; is defined as a hash operation followed by =
a signature operation using asymmetric keys.<br>

</blockquote>
<br></div>
I just want to make sure that we agree now that a digital signature is a ha=
sh followed by a signature algorithm (e.g., RSA with SHA-256). =A0I&#39;ve =
seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a=
 digital signature; one called it a symmetric key based digital signature a=
lgorithm (note this phrase didn&#39;t get through the IESG).</blockquote>
<div><br></div><div>An HMAC is not a digital signature, but the spec defini=
tely needs to be able to cover MAC based authentication.</div><div><br></di=
v><div><br></div><div>I know that public key is getting easier as far as co=
mputation goes. But for many applications the non-repudiation you get in di=
gital signatures is actually undesirable.</div>
<div><br></div><div>There are interesting tricks you can do with symmetric =
crypto that are much harder to do in public key and end up with some scheme=
 that only 50 academics in the world can follow and has a security proof th=
at rest on rather esoteric assumptions.</div>
<div><br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br><br>

--00163691fc2d5892d704a9adbd84--

Date: Thu, 4 Aug 2011 09:03:31 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: John Bradley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--00163691ff518f981b04a9ad9b9b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email-masked]> wrote:

> In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url
> encoded blobs.
>
> In most cased we intend for those to be JSON, but nothing prevents this
> from being used with XML similar to the failed SAML simple sign.
>
> With JSON payloads we really wanted to avoid touching the payload.
>  Inserting elements, canonicalization  and other things that touch the
> payload are highly problematic.
>

I really want to avoid C18N as well. The problem is how to do it.

If the data object is small it is no big deal base64 encoding it and storing
it as an attribute.

But if the data object is larger (XML document, image, etc.) then some form
of indirection is going to be necessary. For example take the digest of the
data and sign that or if multiple objects are involved some sort of manifest
scheme.

I really don't want to have to BASE64 a multimedia stream. So I think I am
going to need some MIME like packaging scheme that allows us to send a JSON
structure with attachments. I think that is going to be a very common
requirement for others as well and I would like that to be a part of the
standards toolkit rather than have to re-invent it for each protocol.

Another very common corner case that is related is how to take a standard
data object such as a JPEG, sign it and then attach the signature inside the
data object.

The blunder committed in XML Signature was to use XPath for that which
introduced a mechanism for arbitrary transformations - yuk!

I really don't want to specify the precise means of embedding signatures in
various media types but I certainly need an approach that makes it possible
to use the spec as a basis for doing that.

-- 
Website: http://hallambaker.com/

--00163691ff518f981b04a9ad9b9b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 at 8:52 AM, John Bra=
dley <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ve7jtb@ve7j=
tb.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url =
encoded blobs.<br>
<br>
In most cased we intend for those to be JSON, but nothing prevents this fro=
m being used with XML similar to the failed SAML simple sign.<br>
<br>
With JSON payloads we really wanted to avoid touching the payload. =A0Inser=
ting elements, canonicalization =A0and other things that touch the payload =
are highly problematic.<br></blockquote><div><br></div><div>I really want t=
o avoid C18N as well. The problem is how to do it.</div>
<div><br></div><div>If the data object is small it is no big deal base64 en=
coding it and storing it as an attribute.</div><div><br></div><div>But if t=
he data object is larger (XML document, image, etc.) then some form of indi=
rection is going to be necessary. For example take the digest of the data a=
nd sign that or if multiple objects are involved some sort of manifest sche=
me.</div>
<div><br></div><div><br></div><div>I really don&#39;t want to have to BASE6=
4 a multimedia stream. So I think I am going to need some MIME like packagi=
ng scheme that allows us to send a JSON structure with attachments. I think=
 that is going to be a very common requirement for others as well and I wou=
ld like that to be a part of the standards toolkit rather than have to re-i=
nvent it for each protocol.=A0</div>
<div><br></div><div><br></div><div>Another very common corner case that is =
related is how to take a standard data object such as a JPEG, sign it and t=
hen attach the signature inside the data object.=A0</div><div><br></div><di=
v>
The blunder committed in XML Signature was to use XPath for that which intr=
oduced a mechanism for arbitrary transformations - yuk!</div><div><br></div=
><div>I really don&#39;t want to specify the precise means of embedding sig=
natures in various media types but I certainly need an approach that makes =
it possible to use the spec as a basis for doing that.=A0</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--00163691ff518f981b04a9ad9b9b--

Date: Thu, 04 Aug 2011 09:03:01 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

On 8/2/11 7:13 PM, Paul Hoffman wrote:
> Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.
>
> --Paul and Richard
>
> Javascript Object Signing and Encrypting (jose)
> ===============================================
>
> Background
> ----------
>
> 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 and digital signatures 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 two security services, encrypting and digitally signing, 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 four documents:
>
> 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.

I just want to make sure that we agree now that a digital signature is a 
hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've 
seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) 
was a digital signature; one called it a symmetric key based digital 
signature algorithm (note this phrase didn't get through the IESG).

> 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.
>
> 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
>
> 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.

I think this addition is good.  In the past we've bundled the MTI 
algorithms with the protocol and then reving the MTI algorithms caused 
unnecessary churn on the protocol even if the protocol is stable.

I also think this draft need not only include MTI algorithms, but the 
draft definitely needs to say which ones are the MTI algorithms.

> The working group may decide to address one or more 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.
>
> Aug 2011    Submit JSON key format document as a WG item.
>
> Aug 2011    Submit JSON algoritm document as a WG item.
>
> Jan 2012    Start Working Group Last Call on JSON object signing document.
>
> Jan 2012    Start Working Group Last Call on JSON object encryption document.
>
> Jan 2012    Start Working Group Last Call on JSON key format document.
>
> Jan 2012    Start Working Group Last Call on JSON algorithm document.
>
> Feb 2012    Submit JSON object signing document to IESG for consideration as
> Standards Track document.
>
> Feb 2012    Submit JSON object encryption document to IESG for consideration
> as Standards Track document.
>
> Feb 2012    Submit JSON key format document to IESG for consideration
> as Standards Track document.
>
> Feb 2012    Submit JSON algorithm document to IESG for consideration
> as Standards Track document.

The dates are little ambitious.  Just based on the process, I doubt this 
can be charter by the end of August.  I'd swap Aug->Oct, Jan->Mar, and 
leave Feb as-is.

spt

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 09:02:48 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail=_CF8C71FD-F4AE-48A1-9002-B79A8A135982
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_33D5AFDC-776D-42FD-838D-2523BF26BBA2"

--Apple-Mail=_33D5AFDC-776D-42FD-838D-2523BF26BBA2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Good info.

This particular company is currently more on the asserting there IPR =
portfolio end of the spectrum at the moment. =20
That perhaps makes them more aware of the risks.

Thanks
John B.
On 2011-08-04, at 8:52 AM, Phillip Hallam-Baker wrote:

>=20
>=20
> On Thu, Aug 4, 2011 at 8:39 AM, John Bradley <[email-masked]> =
wrote:
> Yes I was getting some grief from one of the large venders about =
openID Connect being based on JSON because it is not a standard like =
XML.
>=20
> They were just being general prats about IPR things.
>=20
> This might be the reason for the concern:
>=20
> =
http://www.virginiaiplaw.com/2011/03/articles/patent-litigation/judge-brin=
kema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-patent-case/
>=20
>=20
> I can't go into the details of the case as I was a defense expert for =
another defendant.
> =20
> --=20
> Website: http://hallambaker.com/
>=20

--Apple-Mail=_33D5AFDC-776D-42FD-838D-2523BF26BBA2
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Good info.<div><br></div><div>This particular company is currently more on the asserting there IPR portfolio end of the spectrum at the moment. &nbsp;</div><div>That perhaps makes them more aware of the risks.</div><div><br></div><div>Thanks</div><div>John B.<br><div><div>On 2011-08-04, at 8:52 AM, Phillip Hallam-Baker wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Aug 4, 2011 at 8:39 AM, John Bradley <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yes I was getting some grief from one of the large venders about openID Connect being based on JSON because it is not a standard like XML.<br>
<br>
They were just being general prats about IPR things.<br></blockquote><div><br></div><div>This might be the reason for the concern:</div><div><br></div><div><a href="http://www.virginiaiplaw.com/2011/03/articles/patent-litigation/judge-brinkema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-patent-case/">http://www.virginiaiplaw.com/2011/03/articles/patent-litigation/judge-brinkema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-patent-case/</a></div>
<div><br></div><div><br></div><div>I can't go into the details of the case as I was a defense expert for another defendant.</div><div>&nbsp;</div></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>
</blockquote></div><br></div></body></html>
--Apple-Mail=_33D5AFDC-776D-42FD-838D-2523BF26BBA2--

--Apple-Mail=_CF8C71FD-F4AE-48A1-9002-B79A8A135982
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_CF8C71FD-F4AE-48A1-9002-B79A8A135982--

Date: Thu, 4 Aug 2011 08:52:48 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: John Bradley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--00163691ff513dad7004a9ad75e5
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 4, 2011 at 8:39 AM, John Bradley <[email-masked]> wrote:

> Yes I was getting some grief from one of the large venders about openID
> Connect being based on JSON because it is not a standard like XML.
>
> They were just being general prats about IPR things.
>

This might be the reason for the concern:

http://www.virginiaiplaw.com/2011/03/articles/patent-litigation/judge-brinkema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-patent-case/

I can't go into the details of the case as I was a defense expert for
another defendant.

-- 
Website: http://hallambaker.com/

--00163691ff513dad7004a9ad75e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Aug 4, 2011 at 8:39 AM, John Bra=
dley <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ve7jtb@ve7j=
tb.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yes I was getting some grief from one of the large venders about openID Con=
nect being based on JSON because it is not a standard like XML.<br>
<br>
They were just being general prats about IPR things.<br></blockquote><div><=
br></div><div>This might be the reason for the concern:</div><div><br></div=
><div><a href=3D"http://www.virginiaiplaw.com/2011/03/articles/patent-litig=
ation/judge-brinkema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-=
patent-case/">http://www.virginiaiplaw.com/2011/03/articles/patent-litigati=
on/judge-brinkema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-pat=
ent-case/</a></div>
<div><br></div><div><br></div><div>I can&#39;t go into the details of the c=
ase as I was a defense expert for another defendant.</div><div>=A0</div></d=
iv>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.c=
om/</a><br>
<br>

--00163691ff513dad7004a9ad75e5--

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 08:52:54 -0400
To: Peter Saint-Andre <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail=_E2DA9D5B-8CC8-4A96-879F-0BE0EE4BC0AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

In the JWS/JWE drafts the goal was to provide JSON envelopes for =
base64url encoded blobs.  =20

In most cased we intend for those to be JSON, but nothing prevents this =
from being used with XML similar to the failed SAML simple sign.

With JSON payloads we really wanted to avoid touching the payload.  =
Inserting elements, canonicalization  and other things that touch the =
payload are highly problematic.

John B.

On 2011-08-03, at 4:50 PM, Peter Saint-Andre wrote:

> On 8/3/11 2:49 PM, Peter Saint-Andre wrote:
>> On 8/3/11 2:33 PM, Thomas Hardjono wrote:
>>=20
>>> Also, will RFC4627 be "upgraded" to standards track?
>>=20
>> There's no real need -- most of the media type registration RFCs are
>> informational. However, we might want to look at the entire "stack" =
of
>> JSON-related specs and move them all to standards track (media type,
>> schema, etc.).
>=20
> Clarification: by "we" I do *not* mean the (presumptive) JOSE WG.
>=20
> /psa
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_E2DA9D5B-8CC8-4A96-879F-0BE0EE4BC0AD
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_E2DA9D5B-8CC8-4A96-879F-0BE0EE4BC0AD--

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 08:39:23 -0400
To: Peter Saint-Andre <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail=_7D9364E4-5A19-4A68-994A-ECC4C59012DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Yes I was getting some grief from one of the large venders about openID =
Connect being based on JSON because it is not a standard like XML.

They were just being general prats about IPR things. =20

However at some point someone (not JOSE) should look at the overall =
status of the JSON stack.
It is not a prerequisite for any JOSE work however.

John Bradley
On 2011-08-03, at 4:50 PM, Peter Saint-Andre wrote:

> On 8/3/11 2:49 PM, Peter Saint-Andre wrote:
>> On 8/3/11 2:33 PM, Thomas Hardjono wrote:
>>=20
>>> Also, will RFC4627 be "upgraded" to standards track?
>>=20
>> There's no real need -- most of the media type registration RFCs are
>> informational. However, we might want to look at the entire "stack" =
of
>> JSON-related specs and move them all to standards track (media type,
>> schema, etc.).
>=20
> Clarification: by "we" I do *not* mean the (presumptive) JOSE WG.
>=20
> /psa
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_7D9364E4-5A19-4A68-994A-ECC4C59012DD
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_7D9364E4-5A19-4A68-994A-ECC4C59012DD--

Date: Thu, 4 Aug 2011 08:24:18 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--005045017caa5a7c3304a9ad0f76
Content-Type: text/plain; charset=ISO-8859-1

Based on experience of DANE, I think that the whole process will go a lot
faster if there isn't an attempt to rush through a scheme.

I can't see any technical issues in this case but my experience of DANE has
been that we argue for several months on whether to consider an issue that
could be addressed in a couple of weeks if it was accepted as a technical
matter. And at the end the issue is still not resolved.

Trying to make a consensus building process go faster than consensus can be
built is a sure recipe for disaster.

These schedules are nonsense.

On Thu, Aug 4, 2011 at 12:11 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> Is the object here to arrive at an RFC or to arrive at a standard with a
> broad base of support in the web services apps community?
>
> If the latter the I suggest much more time so as to have the ability to get
> buy in from the relevant community.
>
>
> Sent from my angry birds pad
>
> On Aug 2, 2011, at 19:13, Paul Hoffman <[email-masked]> wrote:
>
> > Here is a proposal for the charter based on the discussion in the BoF
> last week and later discussion with Sean Turner. Comments, praise, scorn,
> etc., are welcome.
> >
> > --Paul and Richard
> >
> > Javascript Object Signing and Encrypting (jose)
> > ===============================================
> >
> > Background
> > ----------
> >
> > 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 and digital
> signatures 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
> two security services, encrypting and digitally signing, 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 four documents:
> >
> > 1) A Standards Track document specifying how to apply a JSON-structured
> digital signature to data, including (but not limited to) JSON data
> structures. "Digital signature" is defined as a hash operation followed by a
> signature operation using asymmetric keys.
> >
> > 2) A Standards Track document specifying how to apply a JSON-structured
> encryption to data, including (but not limited to) JSON data structures.
> >
> > 3) A Standards Track document specifying how to encode public keys as
> JSON-structured objects.
> >
> > 4) A Standards Track document specifying mandatory-to-implement
> algorithms for the other three documents.
> >
> > The working group may decide to address one or more 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.
> >
> > Aug 2011    Submit JSON key format document as a WG item.
> >
> > Aug 2011    Submit JSON algoritm document as a WG item.
> >
> > Jan 2012    Start Working Group Last Call on JSON object signing
> document.
> >
> > Jan 2012    Start Working Group Last Call on JSON object encryption
> document.
> >
> > Jan 2012    Start Working Group Last Call on JSON key format document.
> >
> > Jan 2012    Start Working Group Last Call on JSON algorithm document.
> >
> > Feb 2012    Submit JSON object signing document to IESG for consideration
> as
> > Standards Track document.
> >
> > Feb 2012    Submit JSON object encryption document to IESG for
> consideration
> > as Standards Track document.
> >
> > Feb 2012    Submit JSON key format document to IESG for consideration
> > as Standards Track document.
> >
> > Feb 2012    Submit JSON algorithm document to IESG for consideration
> > as Standards Track document.
> >
> > _______________________________________________
> > woes mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/woes
>

-- 
Website: http://hallambaker.com/

--005045017caa5a7c3304a9ad0f76
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Based on experience of DANE, I think that the whole process will go a lot f=
aster if there isn&#39;t an attempt to rush through a scheme.<div><br></div=
><div>I can&#39;t see any technical issues in this case but my experience o=
f DANE has been that we argue for several months on whether to consider an =
issue that could be addressed in a couple of weeks if it was accepted as a =
technical matter. And at the end the issue is still not resolved.</div>
<div><br><br></div><div>Trying to make a consensus building process go fast=
er than consensus can be built is a sure recipe for disaster.</div><div><br=
></div><div>These schedules are nonsense.=A0</div><div><br><div class=3D"gm=
ail_quote">
On Thu, Aug 4, 2011 at 12:11 AM, Phillip Hallam-Baker <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex;">
Is the object here to arrive at an RFC or to arrive at a standard with a br=
oad base of support in the web services apps community?<br>
<br>
If the latter the I suggest much more time so as to have the ability to get=
 buy in from the relevant community.<br>
<br>
<br>
Sent from my angry birds pad<br>
<div><div></div><div class=3D"h5"><br>
On Aug 2, 2011, at 19:13, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@v=
pnc.org">[email-masked]</a>&gt; wrote:<br>
<br>
&gt; Here is a proposal for the charter based on the discussion in the BoF =
last week and later discussion with Sean Turner. Comments, praise, scorn, e=
tc., are welcome.<br>
&gt;<br>
&gt; --Paul and Richard<br>
&gt;<br>
&gt; Javascript Object Signing and Encrypting (jose)<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br=
>
&gt;<br>
&gt; Background<br>
&gt; ----------<br>
&gt;<br>
&gt; Javascript Object Notation (JSON) is a text format for the serializati=
on 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, t=
here is now a desire to offer security services such as encryption and digi=
tal signatures for data that is being carried in JSON format.<br>

&gt;<br>
&gt; Different proposals for providing such security services have already =
been defined and implemented. This Working Group&#39;s task is to standardi=
ze two security services, encrypting and digitally signing, in order to inc=
rease interoperability of security features between protocols that use JSON=
. =A0The Working Group will base its work on well-known message security pr=
imitives (e.g., CMS), and will solicit input from the rest of the IETF Secu=
rity Area to be sure that the security functionality in the JSON format is =
correct.<br>

&gt;<br>
&gt; This group is chartered to work on four documents:<br>
&gt;<br>
&gt; 1) A Standards Track document specifying how to apply a JSON-structure=
d digital signature to data, including (but not limited to) JSON data struc=
tures. &quot;Digital signature&quot; is defined as a hash operation followe=
d by a signature operation using asymmetric keys.<br>

&gt;<br>
&gt; 2) A Standards Track document specifying how to apply a JSON-structure=
d encryption to data, including (but not limited to) JSON data structures.<=
br>
&gt;<br>
&gt; 3) A Standards Track document specifying how to encode public keys as =
JSON-structured objects.<br>
&gt;<br>
&gt; 4) A Standards Track document specifying mandatory-to-implement algori=
thms for the other three documents.<br>
&gt;<br>
&gt; The working group may decide to address one or more of these goals in =
a single document, in which case the concrete milestones for signing/encryp=
tion below will both be satisfied by the single document.<br>
&gt;<br>
&gt; Goals and Milestones<br>
&gt; --------------------<br>
&gt;<br>
&gt; Aug 2011 =A0 =A0Submit JSON object signing document as a WG item.<br>
&gt;<br>
&gt; Aug 2011 =A0 =A0Submit JSON object encryption document as a WG item.<b=
r>
&gt;<br>
&gt; Aug 2011 =A0 =A0Submit JSON key format document as a WG item.<br>
&gt;<br>
&gt; Aug 2011 =A0 =A0Submit JSON algoritm document as a WG item.<br>
&gt;<br>
&gt; Jan 2012 =A0 =A0Start Working Group Last Call on JSON object signing d=
ocument.<br>
&gt;<br>
&gt; Jan 2012 =A0 =A0Start Working Group Last Call on JSON object encryptio=
n document.<br>
&gt;<br>
&gt; Jan 2012 =A0 =A0Start Working Group Last Call on JSON key format docum=
ent.<br>
&gt;<br>
&gt; Jan 2012 =A0 =A0Start Working Group Last Call on JSON algorithm docume=
nt.<br>
&gt;<br>
&gt; Feb 2012 =A0 =A0Submit JSON object signing document to IESG for consid=
eration as<br>
&gt; Standards Track document.<br>
&gt;<br>
&gt; Feb 2012 =A0 =A0Submit JSON object encryption document to IESG for con=
sideration<br>
&gt; as Standards Track document.<br>
&gt;<br>
&gt; Feb 2012 =A0 =A0Submit JSON key format document to IESG for considerat=
ion<br>
&gt; as Standards Track document.<br>
&gt;<br>
&gt; Feb 2012 =A0 =A0Submit JSON algorithm document to IESG for considerati=
on<br>
&gt; as Standards Track document.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; woes mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/woes" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/woes</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--005045017caa5a7c3304a9ad0f76--

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 00:11:12 -0400
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

Is the object here to arrive at an RFC or to arrive at a standard with a bro=
ad base of support in the web services apps community?

If the latter the I suggest much more time so as to have the ability to get b=
uy in from the relevant community.

Sent from my angry birds pad

On Aug 2, 2011, at 19:13, Paul Hoffman <[email-masked]> wrote:

> Here is a proposal for the charter based on the discussion in the BoF last=
 week and later discussion with Sean Turner. Comments, praise, scorn, etc., a=
re welcome.
>=20
> --Paul and Richard
>=20
> Javascript Object Signing and Encrypting (jose)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Background=20
> ----------
>=20
> Javascript Object Notation (JSON) is a text format for the serialization o=
f structured data described in RFC 4627. The JSON format is often used for s=
erializing and transmitting structured data over a network connection. With t=
he increased usage of JSON in protocols in the IETF and elsewhere, there is n=
ow a desire to offer security services such as encryption and digital signat=
ures for data that is being carried in JSON format.
>=20
> Different proposals for providing such security services have already been=
 defined and implemented. This Working Group's task is to standardize two se=
curity services, encrypting and digitally signing, in order to increase inte=
roperability of security features between protocols that use JSON.  The Work=
ing 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.
>=20
> This group is chartered to work on four documents:
>=20
> 1) A Standards Track document specifying how to apply a JSON-structured di=
gital signature to data, including (but not limited to) JSON data structures=
. "Digital signature" is defined as a hash operation followed by a signature=
 operation using asymmetric keys.
>=20
> 2) A Standards Track document specifying how to apply a JSON-structured en=
cryption to data, including (but not limited to) JSON data structures.
>=20
> 3) A Standards Track document specifying how to encode public keys as JSON=
-structured objects.
>=20
> 4) A Standards Track document specifying mandatory-to-implement algorithms=
 for the other three documents.
>=20
> The working group may decide to address one or more of these goals in a si=
ngle document, in which case the concrete milestones for signing/encryption b=
elow will both be satisfied by the single document.
>=20
> Goals and Milestones=20
> --------------------
>=20
> Aug 2011    Submit JSON object signing document as a WG item.
>=20
> Aug 2011    Submit JSON object encryption document as a WG item.
>=20
> Aug 2011    Submit JSON key format document as a WG item.
>=20
> Aug 2011    Submit JSON algoritm document as a WG item.
>=20
> Jan 2012    Start Working Group Last Call on JSON object signing document.=

>=20
> Jan 2012    Start Working Group Last Call on JSON object encryption docume=
nt.
>=20
> Jan 2012    Start Working Group Last Call on JSON key format document.
>=20
> Jan 2012    Start Working Group Last Call on JSON algorithm document.
>=20
> Feb 2012    Submit JSON object signing document to IESG for consideration a=
s=20
> Standards Track document.
>=20
> Feb 2012    Submit JSON object encryption document to IESG for considerati=
on=20
> as Standards Track document.
>=20
> Feb 2012    Submit JSON key format document to IESG for consideration=20
> as Standards Track document.
>=20
> Feb 2012    Submit JSON algorithm document to IESG for consideration=20
> as Standards Track document.
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 15:33:00 -0600
To: "Paul C. Bryan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail-13--907468616
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Aug 3, 2011, at 15:13, Paul C. Bryan wrote:

> On Wed, 2011-08-03 at 14:35 -0600, Matt Miller wrote:
>> On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:
>>=20
>> > Paul,
>> >=20
>> > Looks good.
>> >=20
>> > Just my clarification, looking at 1) and 2) does it mean that the
>> > resulting JOSE WG specifications can be applied to non-JSON data
>> > structures? (I'm ok with this).
>>=20
>> Yes; at least one of the desired uses is to sign/encrypt XMPP =
stanzas! (-:
>>=20
>=20
> For my edification, why would JOSE want to concern itself with =
representations of other media types, rather than allowing other =
transformations to deal with this?
>=20
> Put another way, if there were a method of encapsulating and encoding =
non-JSON media types in a JSON structure, would JOSE seek to reinvent =
such a thing, or merely defer to using it?
>=20

I think there's real benefit to having JSON as the envelope, and serious =
problems forcing all other structures to encode/decode as JSON.  At =
least for XMPP, a JSON representation can turn out to be larger than the =
original XML.  I imagine there's other data formats this is the case.

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

--Apple-Mail-13--907468616
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-13--907468616--

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Wed, 03 Aug 2011 14:13:48 -0700
Subject: Re: [woes] Proposed charter, post-Quebec edition

--=-zoKmXg9GwgXEVl8WT2qS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Wed, 2011-08-03 at 14:35 -0600, Matt Miller wrote:

> On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:
> 
> > Paul,
> > 
> > Looks good.
> > 
> > Just my clarification, looking at 1) and 2) does it mean that the
> > resulting JOSE WG specifications can be applied to non-JSON data
> > structures? (I'm ok with this).
> 
> Yes; at least one of the desired uses is to sign/encrypt XMPP stanzas! (-:

For my edification, why would JOSE want to concern itself with
representations of other media types, rather than allowing other
transformations to deal with this?

Put another way, if there were a method of encapsulating and encoding
non-JSON media types in a JSON structure, would JOSE seek to reinvent
such a thing, or merely defer to using it?

Paul

--=-zoKmXg9GwgXEVl8WT2qS
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY>
On Wed, 2011-08-03 at 14:35 -0600, Matt Miller wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:

&gt; Paul,
&gt; 
&gt; Looks good.
&gt; 
&gt; Just my clarification, looking at 1) and 2) does it mean that the
&gt; resulting JOSE WG specifications can be applied to non-JSON data
&gt; structures? (I'm ok with this).

Yes; at least one of the desired uses is to sign/encrypt XMPP stanzas! (-:
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
For my edification, why would JOSE want to concern itself with representations of other media types, rather than allowing other transformations to deal with this?<BR>
<BR>
Put another way, if there were a method of encapsulating and encoding non-JSON media types in a JSON structure, would JOSE seek to reinvent such a thing, or merely defer to using it?<BR>
<BR>
Paul
</BODY>
</HTML>

--=-zoKmXg9GwgXEVl8WT2qS--

Date: Wed, 03 Aug 2011 14:50:11 -0600
From: Peter Saint-Andre <[email-masked]>
To: Thomas Hardjono <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

On 8/3/11 2:49 PM, Peter Saint-Andre wrote:
> On 8/3/11 2:33 PM, Thomas Hardjono wrote:
> 
>> Also, will RFC4627 be "upgraded" to standards track?
> 
> There's no real need -- most of the media type registration RFCs are
> informational. However, we might want to look at the entire "stack" of
> JSON-related specs and move them all to standards track (media type,
> schema, etc.).

Clarification: by "we" I do *not* mean the (presumptive) JOSE WG.

/psa

Date: Wed, 03 Aug 2011 14:49:16 -0600
From: Peter Saint-Andre <[email-masked]>
To: Thomas Hardjono <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

On 8/3/11 2:33 PM, Thomas Hardjono wrote:

> Also, will RFC4627 be "upgraded" to standards track?

There's no real need -- most of the media type registration RFCs are
informational. However, we might want to look at the entire "stack" of
JSON-related specs and move them all to standards track (media type,
schema, etc.).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

From: Thomas Hardjono <[email-masked]>
To: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 16:40:11 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

------=_NextPart_000_00B7_01CC51FC.0328DD80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks Matt -- the broader use of JOSE, the better :)

/thomas/

__________________________________________

> -----Original Message-----
> From: Matt Miller [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2011 4:36 PM
> To: Thomas Hardjono
> Cc: Paul Hoffman; [email-masked]
> Subject: Re: [woes] Proposed charter, post-Quebec edition
> 
> On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:
> 
> > Paul,
> >
> > Looks good.
> >
> > Just my clarification, looking at 1) and 2) does it mean that the
> > resulting JOSE WG specifications can be applied to non-JSON data
> > structures? (I'm ok with this).
> 
> Yes; at least one of the desired uses is to sign/encrypt XMPP
stanzas!
> (-:
> 
> 
> - m&m
> 
> Matt Miller - <[email-masked]>
> Collaboration Software Group - Cisco Systems, Inc.
> 

------=_NextPart_000_00B7_01CC51FC.0328DD80
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_00B7_01CC51FC.0328DD80--

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 14:35:42 -0600
To: Thomas Hardjono <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail-10--910906460
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Aug 3, 2011, at 14:33, Thomas Hardjono wrote:

> Paul,
> 
> Looks good.
> 
> Just my clarification, looking at 1) and 2) does it mean that the
> resulting JOSE WG specifications can be applied to non-JSON data
> structures? (I'm ok with this).

Yes; at least one of the desired uses is to sign/encrypt XMPP stanzas! (-:

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

--Apple-Mail-10--910906460
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-10--910906460--

From: Thomas Hardjono <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 3 Aug 2011 16:33:55 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [woes] Proposed charter, post-Quebec edition

------=_NextPart_000_0051_01CC51FB.23043060
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Paul,

Looks good.

Just my clarification, looking at 1) and 2) does it mean that the
resulting JOSE WG specifications can be applied to non-JSON data
structures? (I'm ok with this).

Also, will RFC4627 be "upgraded" to standards track?

Thanks.

/thomas/

__________________________________________

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Paul Hoffman
> Sent: Tuesday, August 02, 2011 7:14 PM
> To: [email-masked]
> Subject: [woes] Proposed charter, post-Quebec edition
> 
> Here is a proposal for the charter based on the discussion in the
BoF
> last week and later discussion with Sean Turner. Comments, praise,
> scorn, etc., are welcome.
> 
> --Paul and Richard
> 
> Javascript Object Signing and Encrypting (jose)
> ===============================================
> 
> Background
> ----------
> 
> 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 and digital signatures 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 two security services, encrypting and digitally signing,
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 four documents:
> 
> 1) A Standards Track document specifying how to apply a
JSON-structured
> digital signature to data, including (but not limited to) JSON data
> structures. "Digital signature" is defined as a hash operation
followed
> by a signature operation using asymmetric keys.
> 
> 2) A Standards Track document specifying how to apply a
JSON-structured
> encryption to data, including (but not limited to) JSON data
> structures.
> 
> 3) A Standards Track document specifying how to encode public keys
as
> JSON-structured objects.
> 
> 4) A Standards Track document specifying mandatory-to-implement
> algorithms for the other three documents.
> 
> The working group may decide to address one or more 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.
> 
> Aug 2011    Submit JSON key format document as a WG item.
> 
> Aug 2011    Submit JSON algoritm document as a WG item.
> 
> Jan 2012    Start Working Group Last Call on JSON object signing
> document.
> 
> Jan 2012    Start Working Group Last Call on JSON object encryption
> document.
> 
> Jan 2012    Start Working Group Last Call on JSON key format
document.
> 
> Jan 2012    Start Working Group Last Call on JSON algorithm
document.
> 
> Feb 2012    Submit JSON object signing document to IESG for
> consideration as
> Standards Track document.
> 
> Feb 2012    Submit JSON object encryption document to IESG for
> consideration
> as Standards Track document.
> 
> Feb 2012    Submit JSON key format document to IESG for
consideration
> as Standards Track document.
> 
> Feb 2012    Submit JSON algorithm document to IESG for consideration
> as Standards Track document.
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

------=_NextPart_000_0051_01CC51FB.23043060
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_0051_01CC51FB.23043060--

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 14:17:09 -0600
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

--Apple-Mail-9--912019444
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think it looks good, too.  I also think the schedule might be a bit =
too aggressive.  Given my interactions with one of the authors of one of =
the existing specs, I have doubts much will get done before the end of =
the month (-:

Also, I'd like to thank Paul and Richard for chairing the BoF.

- m&m
On Aug 2, 2011, at 17:13, Paul Hoffman wrote:

> Here is a proposal for the charter based on the discussion in the BoF =
last week and later discussion with Sean Turner. Comments, praise, =
scorn, etc., are welcome.
>=20
> --Paul and Richard
>=20
> Javascript Object Signing and Encrypting (jose)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Background=20
> ----------
>=20
> 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 and digital signatures for data that is being carried =
in JSON format.
>=20
> Different proposals for providing such security services have already =
been defined and implemented. This Working Group's task is to =
standardize two security services, encrypting and digitally signing, 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.
>=20
> This group is chartered to work on four documents:
>=20
> 1) A Standards Track document specifying how to apply a =
JSON-structured digital signature to data, including (but not limited =
to) JSON data structures. "Digital signature" is defined as a hash =
operation followed by a signature operation using asymmetric keys.
>=20
> 2) A Standards Track document specifying how to apply a =
JSON-structured encryption to data, including (but not limited to) JSON =
data structures.
>=20
> 3) A Standards Track document specifying how to encode public keys as =
JSON-structured objects.
>=20
> 4) A Standards Track document specifying mandatory-to-implement =
algorithms for the other three documents.
>=20
> The working group may decide to address one or more 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.
>=20
> Goals and Milestones=20
> --------------------
>=20
> Aug 2011    Submit JSON object signing document as a WG item.
>=20
> Aug 2011    Submit JSON object encryption document as a WG item.
>=20
> Aug 2011    Submit JSON key format document as a WG item.
>=20
> Aug 2011    Submit JSON algoritm document as a WG item.
>=20
> Jan 2012    Start Working Group Last Call on JSON object signing =
document.
>=20
> Jan 2012    Start Working Group Last Call on JSON object encryption =
document.
>=20
> Jan 2012    Start Working Group Last Call on JSON key format document.
>=20
> Jan 2012    Start Working Group Last Call on JSON algorithm document.
>=20
> Feb 2012    Submit JSON object signing document to IESG for =
consideration as=20
> Standards Track document.
>=20
> Feb 2012    Submit JSON object encryption document to IESG for =
consideration=20
> as Standards Track document.
>=20
> Feb 2012    Submit JSON key format document to IESG for consideration=20=

> as Standards Track document.
>=20
> Feb 2012    Submit JSON algorithm document to IESG for consideration=20=

> as Standards Track document.
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail-9--912019444
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-9--912019444--

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Aug 2011 06:45:03 -0700
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

On Aug 2, 2011, at 7:23 PM, Peter Saint-Andre wrote:

> Looks good, although the dates seem a mite aggressive, especially =
since
> it's doubtful that the WG would be approved this month (given the need
> for internal IESG review, external review, and an IESG decision).

There is nothing stopping the two sets of authors from working together =
pre-WG. :-)

--Paul Hoffman

Date: Tue, 02 Aug 2011 20:23:07 -0600
From: Peter Saint-Andre <[email-masked]>
To: Paul Hoffman <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked]
Subject: Re: [woes] Proposed charter, post-Quebec edition

Looks good, although the dates seem a mite aggressive, especially since
it's doubtful that the WG would be approved this month (given the need
for internal IESG review, external review, and an IESG decision).

On 8/2/11 5:13 PM, Paul Hoffman wrote:
> Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.
> 
> --Paul and Richard
> 
> Javascript Object Signing and Encrypting (jose)
> ===============================================
> 
> Background 
> ----------
> 
> 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 and digital signatures 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 two security services, encrypting and digitally signing, 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 four documents:
> 
> 1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.
> 
> 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.
> 
> 3) A Standards Track document specifying how to encode public keys as JSON-structured objects.
> 
> 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.
> 
> The working group may decide to address one or more 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.
> 
> Aug 2011    Submit JSON key format document as a WG item.
> 
> Aug 2011    Submit JSON algoritm document as a WG item.
> 
> Jan 2012    Start Working Group Last Call on JSON object signing document.
> 
> Jan 2012    Start Working Group Last Call on JSON object encryption document.
> 
> Jan 2012    Start Working Group Last Call on JSON key format document.
> 
> Jan 2012    Start Working Group Last Call on JSON algorithm document.
> 
> Feb 2012    Submit JSON object signing document to IESG for consideration as 
> Standards Track document.
> 
> Feb 2012    Submit JSON object encryption document to IESG for consideration 
> as Standards Track document.
> 
> Feb 2012    Submit JSON key format document to IESG for consideration 
> as Standards Track document.
> 
> Feb 2012    Submit JSON algorithm document to IESG for consideration 
> as Standards Track document.

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 16:13:53 -0700
To: [email-masked]
Subject: [woes] Proposed charter, post-Quebec edition

Here is a proposal for the charter based on the discussion in the BoF =
last week and later discussion with Sean Turner. Comments, praise, =
scorn, etc., are welcome.

--Paul and Richard

Javascript Object Signing and Encrypting (jose)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Background=20
----------

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 and digital signatures 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 two security services, encrypting and digitally signing, 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 four documents:

1) A Standards Track document specifying how to apply a JSON-structured =
digital signature to data, including (but not limited to) JSON data =
structures. "Digital signature" is defined as a hash operation followed =
by a signature operation using asymmetric keys.

2) A Standards Track document specifying how to apply a JSON-structured =
encryption to data, including (but not limited to) JSON data structures.

3) A Standards Track document specifying how to encode public keys as =
JSON-structured objects.

4) A Standards Track document specifying mandatory-to-implement =
algorithms for the other three documents.

The working group may decide to address one or more 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=20
--------------------

Aug 2011    Submit JSON object signing document as a WG item.

Aug 2011    Submit JSON object encryption document as a WG item.

Aug 2011    Submit JSON key format document as a WG item.

Aug 2011    Submit JSON algoritm document as a WG item.

Jan 2012    Start Working Group Last Call on JSON object signing =
document.

Jan 2012    Start Working Group Last Call on JSON object encryption =
document.

Jan 2012    Start Working Group Last Call on JSON key format document.

Jan 2012    Start Working Group Last Call on JSON algorithm document.

Feb 2012    Submit JSON object signing document to IESG for =
consideration as=20
Standards Track document.

Feb 2012    Submit JSON object encryption document to IESG for =
consideration=20
as Standards Track document.

Feb 2012    Submit JSON key format document to IESG for consideration=20
as Standards Track document.

Feb 2012    Submit JSON algorithm document to IESG for consideration=20
as Standards Track document.