Subject: Re: [woes] naming
From: Lucy Lynch <[email-masked]>
To: "Manger, James H" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jul 2011 05:35:28 -0700 (PDT)
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>

On Thu, 28 Jul 2011, Manger, James H wrote:

> +1 JSONsec

if we're going that road... j0ze!#

+1 to JOSE or JOES

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

From: Phillip Hunt <[email-masked]>
Date: Thu, 28 Jul 2011 00:07:43 -0400
To: "Manger, James H" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] naming

Even better. +1

Phil

On 2011-07-27, at 23:45, "Manger, James H" <[email-masked]>=
 wrote:

> +1 JSONsec
>=20
> --
> James Manger
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jul 2011 13:45:06 +1000
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Subject: Re: [woes] naming

+1 JSONsec

--
James Manger

From: Jeremy Laurenson <[email-masked]>
Date: Wed, 27 Jul 2011 23:42:27 -0400
To: [email-masked]
Subject: Re: [woes] naming

+1 JOES/JOSE

On Jul 27, 2011, at 8:41 PM, Phillip Hunt wrote:

> +1 on joes or jose as well.=20
>=20
> Phil
>=20
> On 2011-07-27, at 20:00, Thomas Hardjono <[email-masked]> wrote:
>=20
>>=20
>> +1 JOSE or JOES
>>=20
>> ________________________________________
>> From: [email-masked] [[email-masked]] On Behalf Of John =
Bradley [[email-masked]]
>> Sent: Wednesday, July 27, 2011 4:56 PM
>> To: Leif Johansson
>> Cc: [email-masked]
>> Subject: Re: [woes] naming
>>=20
>> +1 JOSE
>>=20
>> On 2011-07-27, at 4:54 PM, Leif Johansson wrote:
>>=20
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>=20
>>> On 07/27/2011 10:13 PM, Paul C. Bryan wrote:
>>>> +0 to ESJA
>>>> +1 to JOSE or JOES.
>>>> -1 to WOES.
>>>=20
>>> SCHMOES ?
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>=20
>>> iEYEARECAAYFAk4wevMACgkQ8Jx8FtbMZncqmQCfS9hLhQzuduhsqmfYBvgsw/pG
>>> WQkAn2CNYOhqo3vgwkQAlGoy8zaYKtrT
>>> =3DVimg
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> 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
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: Phillip Hunt <[email-masked]>
Date: Wed, 27 Jul 2011 20:41:02 -0400
To: Thomas Hardjono <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] naming

+1 on joes or jose as well.=20

Phil

On 2011-07-27, at 20:00, Thomas Hardjono <[email-masked]> wrote:

>=20
> +1 JOSE or JOES
>=20
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of John Brad=
ley [[email-masked]]
> Sent: Wednesday, July 27, 2011 4:56 PM
> To: Leif Johansson
> Cc: [email-masked]
> Subject: Re: [woes] naming
>=20
> +1 JOSE
>=20
> On 2011-07-27, at 4:54 PM, Leif Johansson wrote:
>=20
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>=20
>> On 07/27/2011 10:13 PM, Paul C. Bryan wrote:
>>> +0 to ESJA
>>> +1 to JOSE or JOES.
>>> -1 to WOES.
>>=20
>> SCHMOES ?
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>=20
>> iEYEARECAAYFAk4wevMACgkQ8Jx8FtbMZncqmQCfS9hLhQzuduhsqmfYBvgsw/pG
>> WQkAn2CNYOhqo3vgwkQAlGoy8zaYKtrT
>> =3DVimg
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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

From: Thomas Hardjono <[email-masked]>
To: John Bradley <[email-masked]>
Date: Wed, 27 Jul 2011 20:00:44 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] naming

+1 JOSE or JOES

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of John Bradl=
ey [[email-masked]]
Sent: Wednesday, July 27, 2011 4:56 PM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [woes] naming

+1 JOSE

On 2011-07-27, at 4:54 PM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/27/2011 10:13 PM, Paul C. Bryan wrote:
>> +0 to ESJA
>> +1 to JOSE or JOES.
>> -1 to WOES.
>
> SCHMOES ?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4wevMACgkQ8Jx8FtbMZncqmQCfS9hLhQzuduhsqmfYBvgsw/pG
> WQkAn2CNYOhqo3vgwkQAlGoy8zaYKtrT
> =3DVimg
> -----END PGP SIGNATURE-----
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: John Bradley <[email-masked]>
Date: Wed, 27 Jul 2011 16:56:05 -0400
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] naming

--Apple-Mail=_93ABDF0B-6910-4F76-9FDA-7691C9E329E0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

+1 JOSE 

On 2011-07-27, at 4:54 PM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/27/2011 10:13 PM, Paul C. Bryan wrote:
>> +0 to ESJA
>> +1 to JOSE or JOES.
>> -1 to WOES.
> 
> SCHMOES ?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk4wevMACgkQ8Jx8FtbMZncqmQCfS9hLhQzuduhsqmfYBvgsw/pG
> WQkAn2CNYOhqo3vgwkQAlGoy8zaYKtrT
> =Vimg
> -----END PGP SIGNATURE-----
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_93ABDF0B-6910-4F76-9FDA-7691C9E329E0
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_93ABDF0B-6910-4F76-9FDA-7691C9E329E0--

Date: Wed, 27 Jul 2011 22:54:11 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [woes] naming

On 07/27/2011 10:13 PM, Paul C. Bryan wrote:
> +0 to ESJA
> +1 to JOSE or JOES.
> -1 to WOES.

SCHMOES ?

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Wed, 27 Jul 2011 13:13:57 -0700
Subject: Re: [woes] naming

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

+0 to ESJA
+1 to JOSE or JOES.
-1 to WOES.

Paul

On Wed, 2011-07-27 at 14:49 -0400, Matt Miller wrote:

> On Jul 27, 2011, at 14:43, Peter Saint-Andre wrote:
> 
> > Encryption and Signing for JavaScript Applications = ESJA?
> > 
> > Pronounced "essjay" (Wikipedia users might get the joke)...
> > 
> > _______________________________________________
> > woes mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/woes
> 
> I was becoming partial to Javascript Object Signing and Encrypting (JOSE)...
> 
> 
> - m&m
> 
> Matt Miller - <[email-masked]>
> Collaboration Software Group - Cisco Systems, Inc.
> 
> 
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--=-/bCuWg3RBiWiCkaPRfLY
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>
+0 to ESJA<BR>
+1 to JOSE or JOES.<BR>
-1 to WOES.<BR>
<BR>
Paul<BR>
<BR>
On Wed, 2011-07-27 at 14:49 -0400, Matt Miller wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Jul 27, 2011, at 14:43, Peter Saint-Andre wrote:

&gt; Encryption and Signing for JavaScript Applications = ESJA?
&gt; 
&gt; Pronounced &quot;essjay&quot; (Wikipedia users might get the joke)...
&gt; 
&gt; _______________________________________________
&gt; woes mailing list
&gt; <A HREF="mailto:[email-masked]">[email-masked]</A>
&gt; <A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>

I was becoming partial to Javascript Object Signing and Encrypting (JOSE)...

- m&amp;m

Matt Miller - &lt;<A HREF="mailto:[email-masked]">[email-masked]</A>&gt;
Collaboration Software Group - Cisco Systems, Inc.

_______________________________________________
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>

--=-/bCuWg3RBiWiCkaPRfLY--

From: Dick Hardt <[email-masked]>
Date: Wed, 27 Jul 2011 12:58:28 -0700
To: Mike Jones <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] naming

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

+2 for JOES
+1 for JOSE

On 2011-07-27, at 12:30 PM, Mike Jones wrote:

> +1 to either JOSE or JOES
> =20
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of John Bradley
> Sent: Wednesday, July 27, 2011 12:02 PM
> To: Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [woes] naming
> =20
> Woes makes me think of a Muddy Waters song.=20
> =20
> Javascript Object Signing and Encrypting (JOSE)
> =20
> Works for us South Americans.  Though I will insist on pronouncing it =
correctly.
> =20
> John B.
> On 2011-07-27, at 2:43 PM, Peter Saint-Andre wrote:
>=20
>=20
> Encryption and Signing for JavaScript Applications =3D ESJA?
>=20
> Pronounced "essjay" (Wikipedia users might get the joke)...
>=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-21-629543320
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><base href=3D"x-msg://261/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">+2 for JOES<div>+1 for =
JOSE</div><div><br><div><div>On 2011-07-27, at 12:30 PM, Mike Jones =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(0, 32, 96); ">+1 to =
either JOSE or JOES<o:p></o:p></span></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(0, 32, 96); "><o:p>&nbsp;</o:p></span></div><div><div =
style=3D"border-right-style: none; border-bottom-style: none; =
border-left-style: none; border-width: initial; border-color: initial; =
border-top-style: solid; border-top-color: rgb(181, 196, 223); =
border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; =
padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; =
">From:</span></b><span style=3D"font-size: 10pt; font-family: Tahoma, =
sans-serif; "><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><span =
class=3D"Apple-converted-space">&nbsp;</span>[mailto:[email-masked]=
]<span class=3D"Apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></b>John =
Bradley<br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Wednesday, July 27, 2011 =
12:02 PM<br><b>To:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Peter =
Saint-Andre<br><b>Cc:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; text-decoration: =
underline; ">[email-masked]</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: [woes] =
naming<o:p></o:p></span></div></div></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">Woes makes me think of a Muddy =
Waters song.&nbsp;<o:p></o:p></div><div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><blockquote style=3D"margin-top: =
5pt; margin-bottom: 5pt; "><div style=3D"margin-top: 0in; margin-right: =
0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-family: =
'Courier New'; ">Javascript Object Signing and Encrypting =
(JOSE)<o:p></o:p></span></div></blockquote><div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Works for us South =
Americans. &nbsp;Though I will insist on pronouncing it =
correctly.<o:p></o:p></div></div><div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">John =
B.<o:p></o:p></div><div><div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">On 2011-07-27, at 2:43 =
PM, Peter Saint-Andre wrote:<o:p></o:p></div></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><br><br><o:p></o:p></div><div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">Encryption and =
Signing for JavaScript Applications =3D ESJA?<br><br>Pronounced "essjay" =
(Wikipedia users might get the =
joke)...<br><br>_______________________________________________<br>woes =
mailing list<br><a href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/woes" style=3D"color: =
blue; text-decoration: underline; =
">https://www.ietf.org/mailman/listinfo/woes</a><o:p></o:p></div></div></d=
iv><div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; =
"><o:p>&nbsp;</o:p></div></div></div>_____________________________________=
__________<br>woes mailing list<br><a href=3D"mailto:[email-masked]" =
style=3D"color: blue; text-decoration: underline; =
">[email-masked]</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/woes" style=3D"color: =
blue; text-decoration: underline; =
">https://www.ietf.org/mailman/listinfo/woes</a><br></div></span></blockqu=
ote></div><br></div></body></html>=

--Apple-Mail-21-629543320--

From: Mike Jones <[email-masked]>
To: John Bradley <[email-masked]>, Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Jul 2011 19:30:17 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] naming

--_000_4E1F6AAD24975D4BA5B1680429673943498719C7TK5EX14MBXC202r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1 to either JOSE or JOES

From: [email-masked] [mailto:[email-masked]] On Behalf Of Joh=
n Bradley
Sent: Wednesday, July 27, 2011 12:02 PM
To: Peter Saint-Andre
Cc: [email-masked]
Subject: Re: [woes] naming

Woes makes me think of a Muddy Waters song.

Javascript Object Signing and Encrypting (JOSE)

Works for us South Americans.  Though I will insist on pronouncing it corre=
ctly.

John B.
On 2011-07-27, at 2:43 PM, Peter Saint-Andre wrote:

Encryption and Signing for JavaScript Applications =3D ESJA?

Pronounced "essjay" (Wikipedia users might get the joke)...

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

--_000_4E1F6AAD24975D4BA5B1680429673943498719C7TK5EX14MBXC202r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#002060;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#002060">&#43;1 to either JOSE or =
JOES<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#002060"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> woes-bou=
[email-masked] [mailto:[email-masked]]
<b>On Behalf Of </b>John Bradley<br>
<b>Sent:</b> Wednesday, July 27, 2011 12:02 PM<br>
<b>To:</b> Peter Saint-Andre<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [woes] naming<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Woes makes me think of a Muddy Waters song.&nbsp;<o:=
p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
Javascript Object Signing and Encrypting (JOSE)<o:p></o:p></span></p>
</blockquote>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p class=3D"MsoNormal">Works for us South Americans. &nbsp;Though I will in=
sist on pronouncing it correctly.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">John B.<o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal">On 2011-07-27, at 2:43 PM, Peter Saint-Andre wrote:<=
o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">Encryption and Signing for JavaScript Applications =
=3D ESJA?<br>
<br>
Pronounced &quot;essjay&quot; (Wikipedia users might get the joke)...<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">https://www.ietf.org=
/mailman/listinfo/woes</a><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_4E1F6AAD24975D4BA5B1680429673943498719C7TK5EX14MBXC202r_--

From: John Bradley <[email-masked]>
Date: Wed, 27 Jul 2011 15:02:18 -0400
To: Peter Saint-Andre <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] naming

--Apple-Mail=_C6BDCA27-42A7-40D9-8534-C10C7DC38D67
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_024041DD-CEB6-448A-8668-0A0C733A43C5"

--Apple-Mail=_024041DD-CEB6-448A-8668-0A0C733A43C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Woes makes me think of a Muddy Waters song.=20

> Javascript Object Signing and Encrypting (JOSE)

Works for us South Americans.  Though I will insist on pronouncing it =
correctly.

John B.
On 2011-07-27, at 2:43 PM, Peter Saint-Andre wrote:

> Encryption and Signing for JavaScript Applications =3D ESJA?
>=20
> Pronounced "essjay" (Wikipedia users might get the joke)...
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--Apple-Mail=_024041DD-CEB6-448A-8668-0A0C733A43C5
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Woes makes me think of a Muddy Waters song.&nbsp;<div><br></div><div><blockquote type="cite" style="font-family: monospace; ">Javascript Object Signing and Encrypting (JOSE)</blockquote><div><br></div>Works for us South Americans. &nbsp;Though I will insist on pronouncing it correctly.</div><div><br></div><div>John B.<br><div><div>On 2011-07-27, at 2:43 PM, Peter Saint-Andre wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Encryption and Signing for JavaScript Applications = ESJA?<br><br>Pronounced "essjay" (Wikipedia users might get the joke)...<br><br>_______________________________________________<br>woes mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/woes<br></div></blockquote></div><br></div></body></html>
--Apple-Mail=_024041DD-CEB6-448A-8668-0A0C733A43C5--

--Apple-Mail=_C6BDCA27-42A7-40D9-8534-C10C7DC38D67
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail=_C6BDCA27-42A7-40D9-8534-C10C7DC38D67--

Date: Wed, 27 Jul 2011 14:56:59 -0400
From: Peter Saint-Andre <[email-masked]>
To: Matt Miller <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked]
Subject: Re: [woes] naming

On 7/27/11 2:49 PM, Matt Miller wrote:
> On Jul 27, 2011, at 14:43, Peter Saint-Andre wrote:
> 
>> Encryption and Signing for JavaScript Applications = ESJA?
>>
>> Pronounced "essjay" (Wikipedia users might get the joke)...
>>
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
> 
> I was becoming partial to Javascript Object Signing and Encrypting (JOSE)...

Jose, can you see?

Works for me.

From: Matt Miller <[email-masked]>
Date: Wed, 27 Jul 2011 14:49:58 -0400
To: [email-masked]
Subject: Re: [woes] naming

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

On Jul 27, 2011, at 14:43, Peter Saint-Andre wrote:

> Encryption and Signing for JavaScript Applications = ESJA?
> 
> Pronounced "essjay" (Wikipedia users might get the joke)...
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

I was becoming partial to Javascript Object Signing and Encrypting (JOSE)...

- m&m

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

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

--Apple-Mail-2-625433270--

Date: Wed, 27 Jul 2011 14:43:47 -0400
From: Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Subject: [woes] naming

Encryption and Signing for JavaScript Applications = ESJA?

Pronounced "essjay" (Wikipedia users might get the joke)...

Date: Mon, 25 Jul 2011 22:04:19 +0200
From: Leif Johansson <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 07/25/2011 09:44 PM, Peter Saint-Andre wrote:
> On 7/25/11 3:42 PM, Stephen Farrell wrote:
> 
>> The idea with "basing on" CMS as I understand it is to avoid
>> starting over with analysis of the basic concepts and features
>> (cutting things out is fine) and was not to say "use ASN.1
>> encoding".
> 
> That was my understanding as well: "let's not define utterly new semantics".
> 
> Peter
> 

OK so maybe we were bikesheding on the term after all ;-)

Date: Mon, 25 Jul 2011 15:44:03 -0400
From: Peter Saint-Andre <[email-masked]>
To: Stephen Farrell <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 7/25/11 3:42 PM, Stephen Farrell wrote:

> The idea with "basing on" CMS as I understand it is to avoid
> starting over with analysis of the basic concepts and features
> (cutting things out is fine) and was not to say "use ASN.1
> encoding".

That was my understanding as well: "let's not define utterly new semantics".

Peter

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

Date: Mon, 25 Jul 2011 20:42:13 +0100
From: Stephen Farrell <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 25/07/11 19:37, Leif Johansson wrote:
> On 07/25/2011 08:19 PM, Dave CROCKER wrote:
> 
>> On 7/25/2011 1:16 PM, Leif Johansson wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>>>> I now find myself hoping this is not the beginning someone making a case 
>>>> for ASN.1 encoding in WOES.
>>>>
>>>> For my edification, can someone comment on how CMS would likely be
>>>> referenced in WOES? Would it likely be a normative reference (i.e. key
>>>> transport/wrapping, as it is in xmlenc-core), or otherwise would it
>>>> probably be just informational?
>>>
>>> We seem to be bike-shedding on the words "based on" in the charter.
>>> Perhaps it helps if we say something to the effect that WOES draws
>>> upon experience from CMS and XML-dsig/enc and leave it at that.
> 
> 
>> 1. There is considerably more than a bikeshedding difference between
> 
>>    a) normative dependence on a protocol, where the new exercise is
>> merely a syntactic re-coding"
> 
>> vs, for example
> 
>>    b) "take the ideas from the existing work and use them as a basis for
>> writing a new protocol."
> 
>> 2. There is a significant constituency in the current topic that are
>> using language that sounds very much like option a) above.
> 
> The '+1's today seem to indicate there is significant support for (2)
> but I'm not so sure the difference is all that big.
> 
> I propose that the asn.1->json technology change is big enough (if you
> take things like tooling, development models etc into account) so as
> to make a literal 1-1 translation unlikely.
> 
> WOES will (imho) have to make intelligent choices about what to keep
> from cms and what it doesn't need. That to me sounds more like "drawing
> experience from" rather than "basing on".

FWIW, my understanding of "basing on" matches Leif's above.

The idea with "basing on" CMS as I understand it is to avoid
starting over with analysis of the basic concepts and features
(cutting things out is fine) and was not to say "use ASN.1
encoding".

Maybe "basing on" wasn't a good term. Whatever.

S.

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

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 25 Jul 2011 11:48:22 -0700
Subject: Re: [woes] New WOES charter proposal

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

On Mon, 2011-07-25 at 14:19 -0400, Dave CROCKER wrote:

> 1. There is considerably more than a bikeshedding difference between
> 
>     a) normative dependence on a protocol, where the new exercise is merely a 
> syntactic re-coding"
> 
> vs, for example
> 
>     b) "take the ideas from the existing work and use them as a basis for 
> writing a new protocol."

I have serious doubts that we should accept a) on its face as the
objective of this working group. I suggest that building the charter on
b) will not negate actually implementing a) if it turns out—after
productive discussion—that it makes sense to take such a direction.

> 2. There is a significant constituency in the current topic that are using 
> language that sounds very much like option a) above.
> 
> That is, I believe there is a meaningful split between an established security 
> community view for this topic, versus the views of the json-oriented folk.
> 
> What is perhaps missing is a clear and shared understanding of the exact uses 
> that are intended for the current work.

Chicken, meet egg; requirements, meet charter. As I see it, the
objective is to get a reasonably succinct—yet not too restrictive—
charter adopted such that analysis and discussion can begin in earnest.

> 
> For example "must be able to encode it in a URL" is a rather meaningful and 
> substantial constraint.

Should we be diving into such details, making them critical path items
to getting the charter in place? If so, I project a significant
deviation from the proposed roadmap, time-wise. I would prefer to avoid
creating extra burdens to completing the charter.

Paul

--=-2T7hkwGEbXDhuW7kBgZz
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-07-25 at 14:19 -0400, Dave CROCKER wrote:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
1. There is considerably more than a bikeshedding difference between

    a) normative dependence on a protocol, where the new exercise is merely a 
syntactic re-coding&quot;

vs, for example

    b) &quot;take the ideas from the existing work and use them as a basis for 
writing a new protocol.&quot;
</PRE>
</BLOCKQUOTE>
<BR>
I have serious doubts that we should accept a) on its face as the objective of this working group. I suggest that building the charter on b) will not negate actually implementing a) if it turns out&#8212;after productive discussion&#8212;that it makes sense to take such a direction.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
2. There is a significant constituency in the current topic that are using 
language that sounds very much like option a) above.

That is, I believe there is a meaningful split between an established security 
community view for this topic, versus the views of the json-oriented folk.

What is perhaps missing is a clear and shared understanding of the exact uses 
that are intended for the current work.
</PRE>
</BLOCKQUOTE>
<BR>
Chicken, meet egg; requirements, meet charter. As I see it, the objective is to get a reasonably succinct&#8212;yet not too restrictive&#8212;charter adopted such that analysis and discussion can begin in earnest.
<BLOCKQUOTE TYPE=CITE>
<PRE>

For example &quot;must be able to encode it in a URL&quot; is a rather meaningful and 
substantial constraint.
</PRE>
</BLOCKQUOTE>
<BR>
Should we be diving into such details, making them critical path items to getting the charter in place? If so, I project a significant deviation from the proposed roadmap, time-wise. I would prefer to avoid creating extra burdens to completing the charter.<BR>
<BR>
Paul
</BODY>
</HTML>

--=-2T7hkwGEbXDhuW7kBgZz--

Date: Mon, 25 Jul 2011 20:37:46 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 07/25/2011 08:19 PM, Dave CROCKER wrote:
> 
> On 7/25/2011 1:16 PM, Leif Johansson wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>>> I now find myself hoping this is not the beginning someone making a case 
>>> for ASN.1 encoding in WOES.
>>>
>>> For my edification, can someone comment on how CMS would likely be
>>> referenced in WOES? Would it likely be a normative reference (i.e. key
>>> transport/wrapping, as it is in xmlenc-core), or otherwise would it
>>> probably be just informational?
>>
>> We seem to be bike-shedding on the words "based on" in the charter.
>> Perhaps it helps if we say something to the effect that WOES draws
>> upon experience from CMS and XML-dsig/enc and leave it at that.
> 
> 
> 1. There is considerably more than a bikeshedding difference between
> 
>    a) normative dependence on a protocol, where the new exercise is
> merely a syntactic re-coding"
> 
> vs, for example
> 
>    b) "take the ideas from the existing work and use them as a basis for
> writing a new protocol."
> 
> 2. There is a significant constituency in the current topic that are
> using language that sounds very much like option a) above.

The '+1's today seem to indicate there is significant support for (2)
but I'm not so sure the difference is all that big.

I propose that the asn.1->json technology change is big enough (if you
take things like tooling, development models etc into account) so as
to make a literal 1-1 translation unlikely.

WOES will (imho) have to make intelligent choices about what to keep
from cms and what it doesn't need. That to me sounds more like "drawing
experience from" rather than "basing on".

	Cheers Leif

Date: Mon, 25 Jul 2011 14:19:43 -0400
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal
Reply-To: [email-masked]

On 7/25/2011 1:16 PM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>> I now find myself hoping this is not the beginning someone making a case
>> for ASN.1 encoding in WOES.
>>
>> For my edification, can someone comment on how CMS would likely be
>> referenced in WOES? Would it likely be a normative reference (i.e. key
>> transport/wrapping, as it is in xmlenc-core), or otherwise would it
>> probably be just informational?
>
> We seem to be bike-shedding on the words "based on" in the charter.
> Perhaps it helps if we say something to the effect that WOES draws
> upon experience from CMS and XML-dsig/enc and leave it at that.

1. There is considerably more than a bikeshedding difference between

    a) normative dependence on a protocol, where the new exercise is merely a 
syntactic re-coding"

vs, for example

    b) "take the ideas from the existing work and use them as a basis for 
writing a new protocol."

2. There is a significant constituency in the current topic that are using 
language that sounds very much like option a) above.

That is, I believe there is a meaningful split between an established security 
community view for this topic, versus the views of the json-oriented folk.

What is perhaps missing is a clear and shared understanding of the exact uses 
that are intended for the current work.

For example "must be able to encode it in a URL" is a rather meaningful and 
substantial constraint.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Mike Jones <[email-masked]>
To: Eric Rescorla <[email-masked]>, Matt Miller <[email-masked]>
Date: Mon, 25 Jul 2011 18:07:13 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eri=
c Rescorla
Sent: Monday, July 25, 2011 10:29 AM
To: Matt Miller
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

That works for me. Certainly when I talk about basing something on CMS, wha=
t I mean is that I'm imitating CMS, not that there is a normative dependenc=
y.

-Ekr

On Mon, Jul 25, 2011 at 1:18 PM, Matt Miller <[email-masked]> wrote:
>
> On Jul 25, 2011, at 13:16, Leif Johansson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>>> I now find myself hoping this is not the beginning someone making a=20
>>> case for ASN.1 encoding in WOES.
>>>
>>> For my edification, can someone comment on how CMS would likely be=20
>>> referenced in WOES? Would it likely be a normative reference (i.e.=20
>>> key transport/wrapping, as it is in xmlenc-core), or otherwise would=20
>>> it probably be just informational?
>>
>> We seem to be bike-shedding on the words "based on" in the charter.
>> Perhaps it helps if we say something to the effect that WOES draws=20
>> upon experience from CMS and XML-dsig/enc and leave it at that.
>>
>
> +1
>
>
> - m&m
>
> Matt Miller - <[email-masked]>
> Collaboration Software Group - Cisco Systems, Inc.
>
>
>
>
> _______________________________________________
> 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: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jul 2011 13:36:30 -0400
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

Basically, yeah, although it may be handy to incorporate some parts of =
CMS by reference (semantics/definitions of certain fields, say). =20

--Richard

On Jul 25, 2011, at 1:28 PM, Eric Rescorla wrote:

> That works for me. Certainly when I talk about basing something on
> CMS, what I mean
> is that I'm imitating CMS, not that there is a normative dependency.
>=20
> -Ekr
>=20
>=20
> On Mon, Jul 25, 2011 at 1:18 PM, Matt Miller <[email-masked]> =
wrote:
>>=20
>> On Jul 25, 2011, at 13:16, Leif Johansson wrote:
>>=20
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>=20
>>> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>>>> I now find myself hoping this is not the beginning someone making a =
case
>>>> for ASN.1 encoding in WOES.
>>>>=20
>>>> For my edification, can someone comment on how CMS would likely be
>>>> referenced in WOES? Would it likely be a normative reference (i.e. =
key
>>>> transport/wrapping, as it is in xmlenc-core), or otherwise would it
>>>> probably be just informational?
>>>=20
>>> We seem to be bike-shedding on the words "based on" in the charter.
>>> Perhaps it helps if we say something to the effect that WOES draws
>>> upon experience from CMS and XML-dsig/enc and leave it at that.
>>>=20
>>=20
>> +1
>>=20
>>=20
>> - m&m
>>=20
>> Matt Miller - <[email-masked]>
>> Collaboration Software Group - Cisco Systems, Inc.
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>>=20
>>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

Date: Mon, 25 Jul 2011 19:32:35 +0200
From: Leif Johansson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 07/25/2011 07:28 PM, Eric Rescorla wrote:
> That works for me. Certainly when I talk about basing something on
> CMS, what I mean
> is that I'm imitating CMS, not that there is a normative dependency.

I personally think that is the right way to think about this.

	Cheers Leif

Date: Mon, 25 Jul 2011 13:28:59 -0400
From: Eric Rescorla <[email-masked]>
To: Matt Miller <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

That works for me. Certainly when I talk about basing something on
CMS, what I mean
is that I'm imitating CMS, not that there is a normative dependency.

-Ekr

On Mon, Jul 25, 2011 at 1:18 PM, Matt Miller <[email-masked]> wrote:
>
> On Jul 25, 2011, at 13:16, Leif Johansson wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>>> I now find myself hoping this is not the beginning someone making a case
>>> for ASN.1 encoding in WOES.
>>>
>>> For my edification, can someone comment on how CMS would likely be
>>> referenced in WOES? Would it likely be a normative reference (i.e. key
>>> transport/wrapping, as it is in xmlenc-core), or otherwise would it
>>> probably be just informational?
>>
>> We seem to be bike-shedding on the words "based on" in the charter.
>> Perhaps it helps if we say something to the effect that WOES draws
>> upon experience from CMS and XML-dsig/enc and leave it at that.
>>
>
> +1
>
>
> - m&m
>
> Matt Miller - <[email-masked]>
> Collaboration Software Group - Cisco Systems, Inc.
>
>
>
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>
>

Date: Mon, 25 Jul 2011 13:20:58 -0400
From: Torsten Lodderstedt <[email-masked]>
To: "Paul C. Bryan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

This is a multi-part message in MIME format.
--------------000103010508050007010900
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

+1

Am 25.07.2011 13:18, schrieb Paul C. Bryan:
> On Mon, 2011-07-25 at 19:16 +0200, Leif Johansson wrote:
>
>> We seem to be bike-shedding on the words "based on" in the charter.
>> Perhaps it helps if we say something to the effect that WOES draws
>> upon experience from CMS and XML-dsig/enc and leave it at that.
>
> +1
>
> Paul
>
>
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

--------------000103010508050007010900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    +1<br>
    <br>
    Am 25.07.2011 13:18, schrieb Paul C. Bryan:
    <blockquote cite="mid:1311614319.28852.61.camel@dynamo" type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="GENERATOR" content="GtkHTML/3.30.3">
      On Mon, 2011-07-25 at 19:16 +0200, Leif Johansson wrote:<br>
      <br>
      <blockquote type="CITE">
        <pre>We seem to be bike-shedding on the words "based on" in the charter.
Perhaps it helps if we say something to the effect that WOES draws
upon experience from CMS and XML-dsig/enc and leave it at that.
</pre>
      </blockquote>
      <br>
      +1<br>
      <br>
      Paul
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
woes mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</a>
</pre>
    </blockquote>
  </body>
</html>

--------------000103010508050007010900--

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 25 Jul 2011 10:18:39 -0700
Subject: Re: [woes] New WOES charter proposal

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

On Mon, 2011-07-25 at 19:16 +0200, Leif Johansson wrote:

> We seem to be bike-shedding on the words "based on" in the charter.
> Perhaps it helps if we say something to the effect that WOES draws
> upon experience from CMS and XML-dsig/enc and leave it at that.

+1

Paul

--=-UyWUWjbhquUKE/kfS/gQ
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-07-25 at 19:16 +0200, Leif Johansson wrote:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
We seem to be bike-shedding on the words &quot;based on&quot; in the charter.
Perhaps it helps if we say something to the effect that WOES draws
upon experience from CMS and XML-dsig/enc and leave it at that.
</PRE>
</BLOCKQUOTE>
<BR>
+1<BR>
<BR>
Paul
</BODY>
</HTML>

--=-UyWUWjbhquUKE/kfS/gQ--

From: Matt Miller <[email-masked]>
Date: Mon, 25 Jul 2011 13:18:16 -0400
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

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

On Jul 25, 2011, at 13:16, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
>> I now find myself hoping this is not the beginning someone making a case
>> for ASN.1 encoding in WOES.
>> 
>> For my edification, can someone comment on how CMS would likely be
>> referenced in WOES? Would it likely be a normative reference (i.e. key
>> transport/wrapping, as it is in xmlenc-core), or otherwise would it
>> probably be just informational?
> 
> We seem to be bike-shedding on the words "based on" in the charter.
> Perhaps it helps if we say something to the effect that WOES draws
> upon experience from CMS and XML-dsig/enc and leave it at that.
> 

+1

- m&m

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

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

--Apple-Mail-5-447130758--

Date: Mon, 25 Jul 2011 19:16:05 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 07/25/2011 06:59 PM, Paul C. Bryan wrote:
> I now find myself hoping this is not the beginning someone making a case
> for ASN.1 encoding in WOES.
> 
> For my edification, can someone comment on how CMS would likely be
> referenced in WOES? Would it likely be a normative reference (i.e. key
> transport/wrapping, as it is in xmlenc-core), or otherwise would it
> probably be just informational?

We seem to be bike-shedding on the words "based on" in the charter.
Perhaps it helps if we say something to the effect that WOES draws
upon experience from CMS and XML-dsig/enc and leave it at that.

	Cheers Leif

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 25 Jul 2011 09:59:58 -0700
Subject: Re: [woes] New WOES charter proposal

--=-a6Z+OixzDqHn34C/7TcF
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

I now find myself hoping this is not the beginning someone making a case
for ASN.1 encoding in WOES.

For my edification, can someone comment on how CMS would likely be
referenced in WOES? Would it likely be a normative reference (i.e. key
transport/wrapping, as it is in xmlenc-core), or otherwise would it
probably be just informational?

Paul

On Mon, 2011-07-25 at 10:21 -0400, Richard L. Barnes wrote:

> <hat type="individual"/>
> 
> It's not clear to me what practical difference this requirement makes.  I would expect that the DER encoding of CMS is probably more compact than a comparable JSON format, so you're not optimizing length by using JSON.  And JSON doesn't define a URL-safe encoding.  If minimizing the size of something in a URL is really your goal, it seems likely that size(base64(cms)) < size(urlencode(json)).
> 
> Or, if you're willing to take the JSON penalty in byte-efficiency, are you trying to argue that there are fields that should be left out relative to CMS?  Could you point to some examples?
> 
> --Richard
> 
> 
> 
> On Jul 15, 2011, at 9:13 PM, Mike Jones wrote:
> 
> > Some use cases require a compact, URL-safe data representation.  For instance, this is needed when the data is passed in a URL query parameter - particularly for feature phone browsers that may limit URLs to 1024 or sometimes even 256 characters.  That's one concrete example of something not covered by CMS.
> > 
> > Some end-to-end use cases require a JSON key representation and ways of referring to them.  That's another concrete example of something not covered in CMS.
> > 
> > 				-- Mike
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > Sent: Friday, July 15, 2011 5:36 PM
> > To: Dave CROCKER
> > Cc: [email-masked]
> > Subject: Re: [woes] New WOES charter proposal
> > 
> > 
> > 
> > On 16/07/11 01:23, Dave CROCKER wrote:
> >> 
> >> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
> >>>> The first requirement is for proponents to provide much more 
> >>>> explicit details about what is being proposed in the use of CMS.
> >> ...
> >>> Well, I don't really follow your logic there, but we're not aiming to 
> >>> do a new thing here.
> >> ...
> >>> Anyway the path for developing yet another crypto format is a pretty 
> >>> well trodden one and IMO CMS is the best current starting point for 
> >>> that process, so I think its entirely reasonable to ask people why 
> >>> they disagree with that.
> >>> 
> >>> It does of course presume familiarity with CMS, but then that should 
> >>> be a prerequisite for working on woes, really.
> >> 
> >> 
> >> Steve,
> >> 
> >> Oh.  This working group is merely a CMS encoding exercise?  That was 
> >> not at all clear previously.
> >> 
> >> I suspect I am not the only one who missed this as the anchoring and 
> >> inflexible premise to the work.  (For reference, that requires even 
> >> stronger language than is in the current draft.)
> > 
> > Maybe you could put [] around the sarcasm, given that this is JSON related? :-)
> > 
> > I asked for examples of what's not covered by CMS but is needed here. I did that actually wanting to get an answer since I may well be missing something. (So far, no substantive answer has been offered.) I was not trying to score some rhetorical points.
> > 
> > S.
> > _______________________________________________
> > 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

--=-a6Z+OixzDqHn34C/7TcF
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>
I now find myself hoping this is not the beginning someone making a case for ASN.1 encoding in WOES.<BR>
<BR>
For my edification, can someone comment on how CMS would likely be referenced in WOES? Would it likely be a normative reference (i.e. key transport/wrapping, as it is in xmlenc-core), or otherwise would it probably be just informational?<BR>
<BR>
Paul<BR>
<BR>
On Mon, 2011-07-25 at 10:21 -0400, Richard L. Barnes wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
&lt;hat type=&quot;individual&quot;/&gt;

It's not clear to me what practical difference this requirement makes.  I would expect that the DER encoding of CMS is probably more compact than a comparable JSON format, so you're not optimizing length by using JSON.  And JSON doesn't define a URL-safe encoding.  If minimizing the size of something in a URL is really your goal, it seems likely that size(base64(cms)) &lt; size(urlencode(json)).

Or, if you're willing to take the JSON penalty in byte-efficiency, are you trying to argue that there are fields that should be left out relative to CMS?  Could you point to some examples?

--Richard

On Jul 15, 2011, at 9:13 PM, Mike Jones wrote:

&gt; Some use cases require a compact, URL-safe data representation.  For instance, this is needed when the data is passed in a URL query parameter - particularly for feature phone browsers that may limit URLs to 1024 or sometimes even 256 characters.  That's one concrete example of something not covered by CMS.
&gt; 
&gt; Some end-to-end use cases require a JSON key representation and ways of referring to them.  That's another concrete example of something not covered in CMS.
&gt; 
&gt; 				-- Mike
&gt; 
&gt; -----Original Message-----
&gt; From: <A HREF="mailto:[email-masked]">[email-masked]</A> [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] On Behalf Of Stephen Farrell
&gt; Sent: Friday, July 15, 2011 5:36 PM
&gt; To: Dave CROCKER
&gt; Cc: <A HREF="mailto:[email-masked]">[email-masked]</A>
&gt; Subject: Re: [woes] New WOES charter proposal
&gt; 
&gt; 
&gt; 
&gt; On 16/07/11 01:23, Dave CROCKER wrote:
&gt;&gt; 
&gt;&gt; On 7/14/2011 1:45 PM, Stephen Farrell wrote:
&gt;&gt;&gt;&gt; The first requirement is for proponents to provide much more 
&gt;&gt;&gt;&gt; explicit details about what is being proposed in the use of CMS.
&gt;&gt; ...
&gt;&gt;&gt; Well, I don't really follow your logic there, but we're not aiming to 
&gt;&gt;&gt; do a new thing here.
&gt;&gt; ...
&gt;&gt;&gt; Anyway the path for developing yet another crypto format is a pretty 
&gt;&gt;&gt; well trodden one and IMO CMS is the best current starting point for 
&gt;&gt;&gt; that process, so I think its entirely reasonable to ask people why 
&gt;&gt;&gt; they disagree with that.
&gt;&gt;&gt; 
&gt;&gt;&gt; It does of course presume familiarity with CMS, but then that should 
&gt;&gt;&gt; be a prerequisite for working on woes, really.
&gt;&gt; 
&gt;&gt; 
&gt;&gt; Steve,
&gt;&gt; 
&gt;&gt; Oh.  This working group is merely a CMS encoding exercise?  That was 
&gt;&gt; not at all clear previously.
&gt;&gt; 
&gt;&gt; I suspect I am not the only one who missed this as the anchoring and 
&gt;&gt; inflexible premise to the work.  (For reference, that requires even 
&gt;&gt; stronger language than is in the current draft.)
&gt; 
&gt; Maybe you could put [] around the sarcasm, given that this is JSON related? :-)
&gt; 
&gt; I asked for examples of what's not covered by CMS but is needed here. I did that actually wanting to get an answer since I may well be missing something. (So far, no substantive answer has been offered.) I was not trying to score some rhetorical points.
&gt; 
&gt; S.
&gt; _______________________________________________
&gt; woes mailing list
&gt; <A HREF="mailto:[email-masked]">[email-masked]</A>
&gt; <A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>
&gt; 
&gt; _______________________________________________
&gt; woes mailing list
&gt; <A HREF="mailto:[email-masked]">[email-masked]</A>
&gt; <A HREF="https://www.ietf.org/mailman/listinfo/woes">https://www.ietf.org/mailman/listinfo/woes</A>

_______________________________________________
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>

--=-a6Z+OixzDqHn34C/7TcF--

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jul 2011 10:21:08 -0400
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

<hat type=3D"individual"/>

It's not clear to me what practical difference this requirement makes.  =
I would expect that the DER encoding of CMS is probably more compact =
than a comparable JSON format, so you're not optimizing length by using =
JSON.  And JSON doesn't define a URL-safe encoding.  If minimizing the =
size of something in a URL is really your goal, it seems likely that =
size(base64(cms)) < size(urlencode(json)).

Or, if you're willing to take the JSON penalty in byte-efficiency, are =
you trying to argue that there are fields that should be left out =
relative to CMS?  Could you point to some examples?

--Richard

On Jul 15, 2011, at 9:13 PM, Mike Jones wrote:

> Some use cases require a compact, URL-safe data representation.  For =
instance, this is needed when the data is passed in a URL query =
parameter - particularly for feature phone browsers that may limit URLs =
to 1024 or sometimes even 256 characters.  That's one concrete example =
of something not covered by CMS.
>=20
> Some end-to-end use cases require a JSON key representation and ways =
of referring to them.  That's another concrete example of something not =
covered in CMS.
>=20
> 				-- Mike
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Stephen Farrell
> Sent: Friday, July 15, 2011 5:36 PM
> To: Dave CROCKER
> Cc: [email-masked]
> Subject: Re: [woes] New WOES charter proposal
>=20
>=20
>=20
> On 16/07/11 01:23, Dave CROCKER wrote:
>>=20
>> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>>> The first requirement is for proponents to provide much more=20
>>>> explicit details about what is being proposed in the use of CMS.
>> ...
>>> Well, I don't really follow your logic there, but we're not aiming =
to=20
>>> do a new thing here.
>> ...
>>> Anyway the path for developing yet another crypto format is a pretty=20=

>>> well trodden one and IMO CMS is the best current starting point for=20=

>>> that process, so I think its entirely reasonable to ask people why=20=

>>> they disagree with that.
>>>=20
>>> It does of course presume familiarity with CMS, but then that should=20=

>>> be a prerequisite for working on woes, really.
>>=20
>>=20
>> Steve,
>>=20
>> Oh.  This working group is merely a CMS encoding exercise?  That was=20=

>> not at all clear previously.
>>=20
>> I suspect I am not the only one who missed this as the anchoring and=20=

>> inflexible premise to the work.  (For reference, that requires even=20=

>> stronger language than is in the current draft.)
>=20
> Maybe you could put [] around the sarcasm, given that this is JSON =
related? :-)
>=20
> I asked for examples of what's not covered by CMS but is needed here. =
I did that actually wanting to get an answer since I may well be missing =
something. (So far, no substantive answer has been offered.) I was not =
trying to score some rhetorical points.
>=20
> S.
> _______________________________________________
> 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

From: Mike Jones <[email-masked]>
To: John Bradley <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Sat, 16 Jul 2011 04:57:48 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Dave CROCKER <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

As John points out, there's a significant anti-X.509/ASN.1 bias among web d=
evelopers at this point.  It may not be "reasonable" or "fair", but it's no=
netheless in play - in part because essentially all modern development tool=
s and languages can parse JSON, whereas the same can't be said of ASN.1 (or=
 XML, for that matter).  For us to succeed in winning developer mindshare e=
nd-to-end, we need to address the need to represent keys in formats they're=
 comfortable with.

Have a look at the JSON Web Key (JWK):  http://tools.ietf.org/html/draft-jo=
nes-json-web-key spec.  It's about as simple a JSON representation of publi=
c keys as you can get.  It doesn't do everything.  (But then, that's kind o=
f the point!)

Looking forward to seeing most of you in Quebec!

				-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]]=20
Sent: Friday, July 15, 2011 7:10 PM
To: Stephen Farrell
Cc: Mike Jones; [email-masked]; Dave CROCKER
Subject: Re: [woes] New WOES charter proposal

In SAML meta-data using keyinfo is not uncommon in a number of federations.=
 =20

Some use self signed x.509 certs but that is recommended against by some fe=
derations.

If we look at existing examples of JSON encryption/signature they all avoid=
 or provide options to having to parse a x.509 certificate.

The anti x.509 bias amongst some developer communities can be a real roadbl=
ock in my experience.

John Bradley

On 2011-07-15, at 9:56 PM, Stephen Farrell wrote:

>=20
> Hi Mike,
>=20
> On 16/07/11 02:13, Mike Jones wrote:
>> Some use cases require a compact, URL-safe data representation.  For ins=
tance, this is needed when the data is passed in a URL query parameter - pa=
rticularly for feature phone browsers that may limit URLs to 1024 or someti=
mes even 256 characters.  That's one concrete example of something not cove=
red by CMS.
>=20
> Note that no-one afaik is suggesting using ASN.1 encoding, so any JSON=20
> specific payload encoding stuff has to be work for woes to do. I would=20
> assume that that's up for debate all right, but don't see that it has=20
> anything to do with CMS, same as CMS doesn't itself say anything about=20
> MIME body parts which is handled in another S/MIME RFC entirely.
>=20
> So, unless I'm missing something this is not a missing bit of CMS but=20
> rather an additional, payload-related (from the crypto p-o-v)=20
> requirement that you're expressing.
>=20
>> Some end-to-end use cases require a JSON key representation and ways of =
referring to them.  That's another concrete example of something not covere=
d in CMS.
>=20
> So some way to identify keys is clearly needed all right and I tend to=20
> agree that that's an area where CMS is too X.509 specific in that CMS=20
> dives inside the X.509 structure.
>=20
> But there are well known choices, as I mentioned in a mail yesterday,=20
> so I still don't see that there's a real need for a JSON=20
> representation for keys, (though it might still be sensible), can you=20
> clarify when you'd need to say refer to an RSA public exponent=20
> specifically, or to an ECC parameter?
>=20
> While I think XMLDSIG's KeyInfo is better than IssuerAndSerialNumber,=20
> I'm not at all sure anyone really uses the <Exponent> element for=20
> anything that wouldn't work just as well with the base64 encoding of=20
> an X.509 blob. But its been a while, so maybe RSAKeyValue is more=20
> useful than I recall.
>=20
> If there's never a need to refer to the RSA public exponent or=20
> equivalents for other algorithms, then you don't need a way to=20
> represent keys in JSON, but rather a way to put some key=20
> representation or key identifier inside square brackets in a well=20
> defined way. The latter, done smartly, should take a whole lot less=20
> effort to get right would be my guess.
>=20
> S.
>=20
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf=20
>> Of Stephen Farrell
>> Sent: Friday, July 15, 2011 5:36 PM
>> To: Dave CROCKER
>> Cc: [email-masked]
>> Subject: Re: [woes] New WOES charter proposal
>>=20
>>=20
>>=20
>> On 16/07/11 01:23, Dave CROCKER wrote:
>>>=20
>>> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>>>> The first requirement is for proponents to provide much more=20
>>>>> explicit details about what is being proposed in the use of CMS.
>>> ...
>>>> Well, I don't really follow your logic there, but we're not aiming=20
>>>> to do a new thing here.
>>> ...
>>>> Anyway the path for developing yet another crypto format is a=20
>>>> pretty well trodden one and IMO CMS is the best current starting=20
>>>> point for that process, so I think its entirely reasonable to ask=20
>>>> people why they disagree with that.
>>>>=20
>>>> It does of course presume familiarity with CMS, but then that=20
>>>> should be a prerequisite for working on woes, really.
>>>=20
>>>=20
>>> Steve,
>>>=20
>>> Oh.  This working group is merely a CMS encoding exercise?  That was=20
>>> not at all clear previously.
>>>=20
>>> I suspect I am not the only one who missed this as the anchoring and=20
>>> inflexible premise to the work.  (For reference, that requires even=20
>>> stronger language than is in the current draft.)
>>=20
>> Maybe you could put [] around the sarcasm, given that this is JSON=20
>> related? :-)
>>=20
>> I asked for examples of what's not covered by CMS but is needed here. I =
did that actually wanting to get an answer since I may well be missing some=
thing. (So far, no substantive answer has been offered.) I was not trying t=
o score some rhetorical points.
>>=20
>> S.
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>>=20
>>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: John Bradley <[email-masked]>
Date: Fri, 15 Jul 2011 22:09:41 -0400
To: Stephen Farrell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dave CROCKER <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

In SAML meta-data using keyinfo is not uncommon in a number of =
federations. =20

Some use self signed x.509 certs but that is recommended against by some =
federations.

If we look at existing examples of JSON encryption/signature they all =
avoid or provide options to having to parse a x.509 certificate.

The anti x.509 bias amongst some developer communities can be a real =
roadblock in my experience.

John Bradley

On 2011-07-15, at 9:56 PM, Stephen Farrell wrote:

>=20
> Hi Mike,
>=20
> On 16/07/11 02:13, Mike Jones wrote:
>> Some use cases require a compact, URL-safe data representation.  For =
instance, this is needed when the data is passed in a URL query =
parameter - particularly for feature phone browsers that may limit URLs =
to 1024 or sometimes even 256 characters.  That's one concrete example =
of something not covered by CMS.
>=20
> Note that no-one afaik is suggesting using ASN.1 encoding, so
> any JSON specific payload encoding stuff has to be work for woes
> to do. I would assume that that's up for debate all right, but
> don't see that it has anything to do with CMS, same as CMS
> doesn't itself say anything about MIME body parts which is
> handled in another S/MIME RFC entirely.
>=20
> So, unless I'm missing something this is not a missing bit
> of CMS but rather an additional, payload-related (from the
> crypto p-o-v) requirement that you're expressing.
>=20
>> Some end-to-end use cases require a JSON key representation and ways =
of referring to them.  That's another concrete example of something not =
covered in CMS.
>=20
> So some way to identify keys is clearly needed all right and I tend
> to agree that that's an area where CMS is too X.509 specific in that
> CMS dives inside the X.509 structure.
>=20
> But there are well known choices, as I mentioned in a mail yesterday,
> so I still don't see that there's a real need for a JSON
> representation for keys, (though it might still be sensible), can
> you clarify when you'd need to say refer to an RSA public exponent
> specifically, or to an ECC parameter?
>=20
> While I think XMLDSIG's KeyInfo is better than IssuerAndSerialNumber,
> I'm not at all sure anyone really uses the <Exponent> element for
> anything that wouldn't work just as well with the base64 encoding
> of an X.509 blob. But its been a while, so maybe RSAKeyValue is more
> useful than I recall.
>=20
> If there's never a need to refer to the RSA public exponent or
> equivalents for other algorithms, then you don't need a way to
> represent keys in JSON, but rather a way to put some key
> representation or key identifier inside square brackets in a
> well defined way. The latter, done smartly, should take a whole
> lot less effort to get right would be my guess.
>=20
> S.
>=20
>>=20
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf =
Of Stephen Farrell
>> Sent: Friday, July 15, 2011 5:36 PM
>> To: Dave CROCKER
>> Cc: [email-masked]
>> Subject: Re: [woes] New WOES charter proposal
>>=20
>>=20
>>=20
>> On 16/07/11 01:23, Dave CROCKER wrote:
>>>=20
>>> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>>>> The first requirement is for proponents to provide much more=20
>>>>> explicit details about what is being proposed in the use of CMS.
>>> ...
>>>> Well, I don't really follow your logic there, but we're not aiming =
to=20
>>>> do a new thing here.
>>> ...
>>>> Anyway the path for developing yet another crypto format is a =
pretty=20
>>>> well trodden one and IMO CMS is the best current starting point for=20=

>>>> that process, so I think its entirely reasonable to ask people why=20=

>>>> they disagree with that.
>>>>=20
>>>> It does of course presume familiarity with CMS, but then that =
should=20
>>>> be a prerequisite for working on woes, really.
>>>=20
>>>=20
>>> Steve,
>>>=20
>>> Oh.  This working group is merely a CMS encoding exercise?  That was=20=

>>> not at all clear previously.
>>>=20
>>> I suspect I am not the only one who missed this as the anchoring and=20=

>>> inflexible premise to the work.  (For reference, that requires even=20=

>>> stronger language than is in the current draft.)
>>=20
>> Maybe you could put [] around the sarcasm, given that this is JSON =
related? :-)
>>=20
>> I asked for examples of what's not covered by CMS but is needed here. =
I did that actually wanting to get an answer since I may well be missing =
something. (So far, no substantive answer has been offered.) I was not =
trying to score some rhetorical points.
>>=20
>> S.
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>>=20
>>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

Date: Sat, 16 Jul 2011 02:56:09 +0100
From: Stephen Farrell <[email-masked]>
To: Mike Jones <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dave CROCKER <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

Hi Mike,

On 16/07/11 02:13, Mike Jones wrote:
> Some use cases require a compact, URL-safe data representation.  For instance, this is needed when the data is passed in a URL query parameter - particularly for feature phone browsers that may limit URLs to 1024 or sometimes even 256 characters.  That's one concrete example of something not covered by CMS.

Note that no-one afaik is suggesting using ASN.1 encoding, so
any JSON specific payload encoding stuff has to be work for woes
to do. I would assume that that's up for debate all right, but
don't see that it has anything to do with CMS, same as CMS
doesn't itself say anything about MIME body parts which is
handled in another S/MIME RFC entirely.

So, unless I'm missing something this is not a missing bit
of CMS but rather an additional, payload-related (from the
crypto p-o-v) requirement that you're expressing.

> Some end-to-end use cases require a JSON key representation and ways of referring to them.  That's another concrete example of something not covered in CMS.

So some way to identify keys is clearly needed all right and I tend
to agree that that's an area where CMS is too X.509 specific in that
CMS dives inside the X.509 structure.

But there are well known choices, as I mentioned in a mail yesterday,
so I still don't see that there's a real need for a JSON
representation for keys, (though it might still be sensible), can
you clarify when you'd need to say refer to an RSA public exponent
specifically, or to an ECC parameter?

While I think XMLDSIG's KeyInfo is better than IssuerAndSerialNumber,
I'm not at all sure anyone really uses the <Exponent> element for
anything that wouldn't work just as well with the base64 encoding
of an X.509 blob. But its been a while, so maybe RSAKeyValue is more
useful than I recall.

If there's never a need to refer to the RSA public exponent or
equivalents for other algorithms, then you don't need a way to
represent keys in JSON, but rather a way to put some key
representation or key identifier inside square brackets in a
well defined way. The latter, done smartly, should take a whole
lot less effort to get right would be my guess.

S.

> 
> 				-- Mike
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, July 15, 2011 5:36 PM
> To: Dave CROCKER
> Cc: [email-masked]
> Subject: Re: [woes] New WOES charter proposal
> 
> 
> 
> On 16/07/11 01:23, Dave CROCKER wrote:
>>
>> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>>> The first requirement is for proponents to provide much more 
>>>> explicit details about what is being proposed in the use of CMS.
>> ...
>>> Well, I don't really follow your logic there, but we're not aiming to 
>>> do a new thing here.
>> ...
>>> Anyway the path for developing yet another crypto format is a pretty 
>>> well trodden one and IMO CMS is the best current starting point for 
>>> that process, so I think its entirely reasonable to ask people why 
>>> they disagree with that.
>>>
>>> It does of course presume familiarity with CMS, but then that should 
>>> be a prerequisite for working on woes, really.
>>
>>
>> Steve,
>>
>> Oh.  This working group is merely a CMS encoding exercise?  That was 
>> not at all clear previously.
>>  
>> I suspect I am not the only one who missed this as the anchoring and 
>> inflexible premise to the work.  (For reference, that requires even 
>> stronger language than is in the current draft.)
> 
> Maybe you could put [] around the sarcasm, given that this is JSON related? :-)
> 
> I asked for examples of what's not covered by CMS but is needed here. I did that actually wanting to get an answer since I may well be missing something. (So far, no substantive answer has been offered.) I was not trying to score some rhetorical points.
> 
> S.
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
> 
> 

From: Mike Jones <[email-masked]>
To: Stephen Farrell <[email-masked]>, Dave CROCKER <[email-masked]>
Date: Sat, 16 Jul 2011 01:13:22 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

Some use cases require a compact, URL-safe data representation.  For instan=
ce, this is needed when the data is passed in a URL query parameter - parti=
cularly for feature phone browsers that may limit URLs to 1024 or sometimes=
 even 256 characters.  That's one concrete example of something not covered=
 by CMS.

Some end-to-end use cases require a JSON key representation and ways of ref=
erring to them.  That's another concrete example of something not covered i=
n CMS.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ste=
phen Farrell
Sent: Friday, July 15, 2011 5:36 PM
To: Dave CROCKER
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 16/07/11 01:23, Dave CROCKER wrote:
>=20
> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>> The first requirement is for proponents to provide much more=20
>>> explicit details about what is being proposed in the use of CMS.
> ...
>> Well, I don't really follow your logic there, but we're not aiming to=20
>> do a new thing here.
> ...
>> Anyway the path for developing yet another crypto format is a pretty=20
>> well trodden one and IMO CMS is the best current starting point for=20
>> that process, so I think its entirely reasonable to ask people why=20
>> they disagree with that.
>>
>> It does of course presume familiarity with CMS, but then that should=20
>> be a prerequisite for working on woes, really.
>=20
>=20
> Steve,
>=20
> Oh.  This working group is merely a CMS encoding exercise?  That was=20
> not at all clear previously.
> =20
> I suspect I am not the only one who missed this as the anchoring and=20
> inflexible premise to the work.  (For reference, that requires even=20
> stronger language than is in the current draft.)

Maybe you could put [] around the sarcasm, given that this is JSON related?=
 :-)

I asked for examples of what's not covered by CMS but is needed here. I did=
 that actually wanting to get an answer since I may well be missing somethi=
ng. (So far, no substantive answer has been offered.) I was not trying to s=
core some rhetorical points.

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

Date: Sat, 16 Jul 2011 01:36:27 +0100
From: Stephen Farrell <[email-masked]>
To: Dave CROCKER <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 16/07/11 01:23, Dave CROCKER wrote:
> 
> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>> The first requirement is for proponents to provide much more explicit
>>> details about what is being proposed in the use of CMS.
> ...
>> Well, I don't really follow your logic there, but we're not
>> aiming to do a new thing here.
> ...
>> Anyway the path for developing yet another crypto format
>> is a pretty well trodden one and IMO CMS is the best current
>> starting point for that process, so I think its entirely
>> reasonable to ask people why they disagree with that.
>>
>> It does of course presume familiarity with CMS, but then
>> that should be a prerequisite for working on woes, really.
> 
> 
> Steve,
> 
> Oh.  This working group is merely a CMS encoding exercise?  That was not
> at all clear previously.
>  
> I suspect I am not the only one who missed this as the anchoring and
> inflexible premise to the work.  (For reference, that requires even
> stronger language than is in the current draft.)

Maybe you could put [] around the sarcasm, given that
this is JSON related? :-)

I asked for examples of what's not covered by CMS but
is needed here. I did that actually wanting to get an
answer since I may well be missing something. (So far,
no substantive answer has been offered.) I was not
trying to score some rhetorical points.

S.

Date: Fri, 15 Jul 2011 17:23:58 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>> The first requirement is for proponents to provide much more explicit
>> details about what is being proposed in the use of CMS.
...
> Well, I don't really follow your logic there, but we're not
> aiming to do a new thing here.
...
> Anyway the path for developing yet another crypto format
> is a pretty well trodden one and IMO CMS is the best current
> starting point for that process, so I think its entirely
> reasonable to ask people why they disagree with that.
>
> It does of course presume familiarity with CMS, but then
> that should be a prerequisite for working on woes, really.

Steve,

Oh.  This working group is merely a CMS encoding exercise?  That was not at all 
clear previously.

I suspect I am not the only one who missed this as the anchoring and inflexible 
premise to the work.  (For reference, that requires even stronger language than 
is in the current draft.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 14 Jul 2011 21:45:51 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

Hi Dave,

(Sorry for the slow response, I've been offline for
a week.)

On 08/07/11 16:02, Dave CROCKER wrote:
> 
> 
> On 7/7/2011 4:42 PM, Stephen Farrell wrote:
>> On 08/07/11 00:21, Mike Jones wrote:
>>> There are other requirements not met by CMS for many of our use
>>> cases.  For instance, having a compact representation and having a
>>> URL-safe implementation.
>>>
>>> I'm fine with CMS being *one* of the input documents, but I believe
>>> it's too strong a statement to say that we've decided up-front that
>>> the goal is to "JSONize CMS" or to have the charter reflect that
>>> narrowing of the mission.
>>
>> Can you say what is not in CMS that might be needed here?
>> I find it hard to think of anything myself, but if there
>> are things, (specific features, that is) that'd be good
>> to know.
> 
> 
> Stephen,
> 
> From the standpoint of argumentation process, your question is literally
> out of order.  That is, out of sequence.
> 
> It calls for criticizing details that have not been stated.
> 
> The first requirement is for proponents to provide much more explicit
> details about what is being proposed in the use of CMS.  After that,
> critics can point to missing details or details that they believe should
> not apply here, or alternatives with better details, or...

Well, I don't really follow your logic there, but we're not
aiming to do a new thing here.

A few years ago, we did the CMS->XML thing as Paul pointed
out. Before that there were a number of other formats (X.400
security, EDIFACT/ANSI X9.42, MOSS, PGP, PEM) some aspects
of which influenced CMS as I recall. (But didn't check back
so the failing memory excuse may be needed in a bit:-)

Anyway the path for developing yet another crypto format
is a pretty well trodden one and IMO CMS is the best current
starting point for that process, so I think its entirely
reasonable to ask people why they disagree with that.

It does of course presume familiarity with CMS, but then
that should be a prerequisite for working on woes, really.

S.

> Richard's response is along the lines of what is first needed, but there
> needs to be agreement on whatever is meant.
> 
> I think there should be some explicit debate about the choices for
> conceptual, semantic, syntactic, software, whatever highest point of
> departure that will be used.  There are choices and the differences are
> meaningful.
> 
> d/
> 

Date: Thu, 14 Jul 2011 21:33:34 +0100
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] "Basing" on CMS

On 13/07/11 18:42, Paul Hoffman wrote:
> On Jul 13, 2011, at 10:27 AM, Mike Jones wrote:
> 
>> I strongly disagree with the "basing on CMS" wording.  I'd be OK with wording more like "drawing upon existing inputs such as CMS, XMLDSIG, and XMLENC".
>>
>> There's a lot to reuse from these documents.  But it's prejudicial to have a discussion that starts from the assumption that we are basing this work on CMS.
> 
> As someone who participated in the early XMLDSIG and XMLENC work, I have to ask: what do they have for this JSON work that CMS doesn't? That is, there was a conscious attempt to mirror CMS structures in them. Where they strayed (such as on namespaces), they went to hell.
> 
> One or two examples here would really help.

Indeed. I think the KeyInfo from XMLDSIG is maybe a
slightly better model than (almost) forcing
IssuerAndSerialNumber from 5280 as is done in CMS.
That's the level at which I think we need to have
the discussion to understand what people are claiming
is wrong with basing on CMS.

For me, other than that example, I really fail to
see anything wrong with basing on CMS, so some
examples would be very good, even if they only
come two weeks after I first asked.

(Or, maybe all the disquiet on this topic is
really format-wars yet again and from the security
p-o-v, content-free;-)

S.

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

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jul 2011 10:42:20 -0700
To: Mike Jones <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [woes] "Basing" on CMS

On Jul 13, 2011, at 10:27 AM, Mike Jones wrote:

> I strongly disagree with the "basing on CMS" wording.  I'd be OK with =
wording more like "drawing upon existing inputs such as CMS, XMLDSIG, =
and XMLENC".
>=20
> There's a lot to reuse from these documents.  But it's prejudicial to =
have a discussion that starts from the assumption that we are basing =
this work on CMS.

As someone who participated in the early XMLDSIG and XMLENC work, I have =
to ask: what do they have for this JSON work that CMS doesn't? That is, =
there was a conscious attempt to mirror CMS structures in them. Where =
they strayed (such as on namespaces), they went to hell.

One or two examples here would really help.

--Paul Hoffman

From: Mike Jones <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 13 Jul 2011 17:27:26 +0000
Accept-Language: en-US
Subject: Re: [woes] Proposed BoF agenda

I strongly disagree with the "basing on CMS" wording.  I'd be OK with wordi=
ng more like "drawing upon existing inputs such as CMS, XMLDSIG, and XMLENC=
".

There's a lot to reuse from these documents.  But it's prejudicial to have =
a discussion that starts from the assumption that we are basing this work o=
n CMS.

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pau=
l Hoffman
Sent: Wednesday, July 13, 2011 9:57 AM
To: [email-masked]
Subject: [woes] Proposed BoF agenda

Greetings again. Richard and I propose the following agenda for our meeting=
 that is in less than two weeks:

Agenda for WOES BoF, IETF 81, Quebec
Richard Barnes and Paul Hoffman, temporary BoF chairs

Agenda bashing, blue shee launching - 5 min Maining list history of the pro=
posed charter (Richard/Paul) - 15 minutes A word from our sponsor (Stephen/=
Sean) - 5 minutes Charter issue 1: key format - 20 minutes Charter issue 2:=
 basing on CMS - 20 minutes Other charter issues - rest of time

(We will post this to the IETF agenda site later when they allow us to.)

Suggested changes to the agenda are welcome. More discussion of the charter=
 in the coming two weeks is even more welcome.

--Paul Hoffman

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

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jul 2011 09:57:16 -0700
To: [email-masked]
Subject: [woes] Proposed BoF agenda

Greetings again. Richard and I propose the following agenda for our =
meeting that is in less than two weeks:

Agenda for WOES BoF, IETF 81, Quebec
Richard Barnes and Paul Hoffman, temporary BoF chairs

Agenda bashing, blue shee launching - 5 min
Maining list history of the proposed charter (Richard/Paul) - 15 minutes
A word from our sponsor (Stephen/Sean) - 5 minutes
Charter issue 1: key format - 20 minutes
Charter issue 2: basing on CMS - 20 minutes
Other charter issues - rest of time

(We will post this to the IETF agenda site later when they allow us to.)

Suggested changes to the agenda are welcome. More discussion of the =
charter in the coming two weeks is even more welcome.

--Paul Hoffman

From: Anthony Nadalin <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Jul 2011 16:15:52 +0000
Accept-Language: en-US
Cc: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

So I don't expect that equivalence would have to be ASN.1 structures or DER=
/BER encodings. I would also not to have to support full objects like Signe=
dData.

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]]=20
Sent: Friday, July 08, 2011 7:38 AM
To: Anthony Nadalin
Cc: Paul Hoffman; Hannes Tschofenig; [email-masked]
Subject: Re: [woes] New WOES charter proposal

<hat type=3D"individual"/>

As I read that part of the charter, I understood it to suggest that there s=
hould be some sort of logical equivalence between the two encodings -- that=
 the parts of the WOES object should correspond to some subset of the parts=
 in a CMS object.  Kind of like the JSMS proposal does now. =20

It seems like this gets around Sean's concern about re-designing a security=
 protocol, and actually saves some design work, because you can push hard t=
hings off to RFC 5652.  At the same time, it keeps you free to make a compa=
ct encoding; you can use "s" instead of "Signer" as long as you say so in t=
he spec.

--Richard

On Jul 7, 2011, at 9:18 PM, Anthony Nadalin wrote:

> Concern is if folks think that the same formats have to be preserved and =
same algorithms, etc. If it is simply signing and encrypting and that can b=
e done in any format and algorithms then I think we are fine, but it should=
 be made a little clearer and say something like "similar signing and encry=
pting function that CMS provides"
>=20
> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]=20
> Sent: Thursday, July 07, 2011 4:18 PM
> To: Hannes Tschofenig
> Cc: Anthony Nadalin; [email-masked]
> Subject: Re: [woes] New WOES charter proposal
>=20
> On Jul 7, 2011, at 4:06 PM, Hannes Tschofenig wrote:
>=20
>> And what does it mean to "base it on CMS"?=20
>>=20
>> It could, for example, mean that=20
>> 1) the same functionality as CMS has to be provided (but with a JSON enc=
oding)
>> 2) folks should look at CMS to get inspired
>> 3) for a chosen subset of CMS that the JSON-based realization must be se=
mantically equivalent (for example, to make translation easy or so)
>> 4) re-use of parts is encouraged (such as registries, etc.)=20
>>=20
>> What did you had in mind, Paul?=20
>=20
> I was reflecting an earlier message from our AD. On Jun 14, 2011, at 9:31=
 AM, Sean Turner wrote:
>=20
>> In Prague, I thought the goal was pretty straightforward: JSONize CMS.
>=20
>=20
> That seems clear to me. It's closer to your #1 above, but the rest of the=
 proposed charter makes it clear that it is a subset of CMS, namely signing=
 and encrypting.
>=20
> --Paul Hoffman
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

Date: Fri, 08 Jul 2011 08:02:56 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal
Reply-To: [email-masked]

On 7/7/2011 4:42 PM, Stephen Farrell wrote:
> On 08/07/11 00:21, Mike Jones wrote:
>> There are other requirements not met by CMS for many of our use cases.  For instance, having a compact representation and having a URL-safe implementation.
>>
>> I'm fine with CMS being *one* of the input documents, but I believe it's too strong a statement to say that we've decided up-front that the goal is to "JSONize CMS" or to have the charter reflect that narrowing of the mission.
>
> Can you say what is not in CMS that might be needed here?
> I find it hard to think of anything myself, but if there
> are things, (specific features, that is) that'd be good
> to know.

Stephen,

 From the standpoint of argumentation process, your question is literally out of 
order.  That is, out of sequence.

It calls for criticizing details that have not been stated.

The first requirement is for proponents to provide much more explicit details 
about what is being proposed in the use of CMS.  After that, critics can point 
to missing details or details that they believe should not apply here, or 
alternatives with better details, or...

Richard's response is along the lines of what is first needed, but there needs 
to be agreement on whatever is meant.

I think there should be some explicit debate about the choices for conceptual, 
semantic, syntactic, software, whatever highest point of departure that will be 
used.  There are choices and the differences are meaningful.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 08 Jul 2011 08:02:50 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal
Reply-To: [email-masked]

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

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

I suggestion:

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

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

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

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

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

As an example of the debate:

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

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

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

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

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

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

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Jul 2011 10:37:42 -0400
To: Anthony Nadalin <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

<hat type=3D"individual"/>

As I read that part of the charter, I understood it to suggest that =
there should be some sort of logical equivalence between the two =
encodings -- that the parts of the WOES object should correspond to some =
subset of the parts in a CMS object.  Kind of like the JSMS proposal =
does now. =20

It seems like this gets around Sean's concern about re-designing a =
security protocol, and actually saves some design work, because you can =
push hard things off to RFC 5652.  At the same time, it keeps you free =
to make a compact encoding; you can use "s" instead of "Signer" as long =
as you say so in the spec.

--Richard

On Jul 7, 2011, at 9:18 PM, Anthony Nadalin wrote:

> Concern is if folks think that the same formats have to be preserved =
and same algorithms, etc. If it is simply signing and encrypting and =
that can be done in any format and algorithms then I think we are fine, =
but it should be made a little clearer and say something like "similar =
signing and encrypting function that CMS provides"
>=20
> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]=20
> Sent: Thursday, July 07, 2011 4:18 PM
> To: Hannes Tschofenig
> Cc: Anthony Nadalin; [email-masked]
> Subject: Re: [woes] New WOES charter proposal
>=20
> On Jul 7, 2011, at 4:06 PM, Hannes Tschofenig wrote:
>=20
>> And what does it mean to "base it on CMS"?=20
>>=20
>> It could, for example, mean that=20
>> 1) the same functionality as CMS has to be provided (but with a JSON =
encoding)
>> 2) folks should look at CMS to get inspired
>> 3) for a chosen subset of CMS that the JSON-based realization must be =
semantically equivalent (for example, to make translation easy or so)
>> 4) re-use of parts is encouraged (such as registries, etc.)=20
>>=20
>> What did you had in mind, Paul?=20
>=20
> I was reflecting an earlier message from our AD. On Jun 14, 2011, at =
9:31 AM, Sean Turner wrote:
>=20
>> In Prague, I thought the goal was pretty straightforward: JSONize =
CMS.
>=20
>=20
> That seems clear to me. It's closer to your #1 above, but the rest of =
the proposed charter makes it clear that it is a subset of CMS, namely =
signing and encrypting.
>=20
> --Paul Hoffman
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: Anthony Nadalin <[email-masked]>
To: Paul Hoffman <[email-masked]>, Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jul 2011 01:18:58 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

Concern is if folks think that the same formats have to be preserved and sa=
me algorithms, etc. If it is simply signing and encrypting and that can be =
done in any format and algorithms then I think we are fine, but it should b=
e made a little clearer and say something like "similar signing and encrypt=
ing function that CMS provides"

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]=20
Sent: Thursday, July 07, 2011 4:18 PM
To: Hannes Tschofenig
Cc: Anthony Nadalin; [email-masked]
Subject: Re: [woes] New WOES charter proposal

On Jul 7, 2011, at 4:06 PM, Hannes Tschofenig wrote:

> And what does it mean to "base it on CMS"?=20
>=20
> It could, for example, mean that=20
> 1) the same functionality as CMS has to be provided (but with a JSON enco=
ding)
> 2) folks should look at CMS to get inspired
> 3) for a chosen subset of CMS that the JSON-based realization must be sem=
antically equivalent (for example, to make translation easy or so)
> 4) re-use of parts is encouraged (such as registries, etc.)=20
>=20
> What did you had in mind, Paul?=20

I was reflecting an earlier message from our AD. On Jun 14, 2011, at 9:31 A=
M, Sean Turner wrote:

> In Prague, I thought the goal was pretty straightforward: JSONize CMS.

That seems clear to me. It's closer to your #1 above, but the rest of the p=
roposed charter makes it clear that it is a subset of CMS, namely signing a=
nd encrypting.

--Paul Hoffman

Date: Thu, 07 Jul 2011 21:02:54 -0400
From: Sean Turner <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

I'm always reminded by the warning found in RFC 5406:

   Security protocols are very hard to design;

Trying to get a new security protocol through the standardization hoops 
is much harder than starting with a known protocol profiling it down to 
what you want.  If you start from scratch, you end up in the whole let's 
pick from one of the competing options, but before you can do that you 
need to generate some requirements.

spt

On 7/7/11 7:06 PM, Hannes Tschofenig wrote:
> And what does it mean to "base it on CMS"?
>
> It could, for example, mean that
> 1) the same functionality as CMS has to be provided (but with a JSON encoding)
> 2) folks should look at CMS to get inspired
> 3) for a chosen subset of CMS that the JSON-based realization must be semantically equivalent (for example, to make translation easy or so)
> 4) re-use of parts is encouraged (such as registries, etc.)
>
> What did you had in mind, Paul?
>
> On Jul 8, 2011, at 12:17 AM, Anthony Nadalin wrote:
>
>> Why do we need to base this on CMS, that should be an open.
>>
>> -----Original Message-----
>> From: Paul Hoffman [mailto:[email-masked]]
>> Sent: Thursday, July 07, 2011 10:55 AM
>> To: [email-masked]
>> Subject: Re: [woes] New WOES charter proposal
>>
>> More comments, please.
>>
>> On Jul 5, 2011, at 1:44 PM, Paul Hoffman wrote:
>>
>>> Greetings again. After discussion with our ADs about having a much more limited charter than what was initially proposed, Richard Barnes and I have come up with the following. We would like this discussed as much as possible on the list before the Quebec meeting so that the meeting can be about finalizing the charter. Thus, comments are welcome.
>>>
>>> We also note that the WG might want to change its name to JOES (JavaScript Object Encryption and Signing) to make its work clearer to people who don't read the first paragraph of the charter.
>>>
>>> Web Object Encryption and Signing (woes)
>>> ========================================
>>>
>>> Background
>>> ----------
>>>
>>> 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 object encryption and message signing 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 the Cryptographic Message Syntax (CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct.
>>
>>>
>>> This group is chartered to work on one or two 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.
>>>
>>> 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.
>>>
>>> The working group may decide to address both of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document.
>>>
>>> Goals and Milestones
>>> --------------------
>>>
>>> Aug 2011    Submit JSON object signing document as a WG item.
>>>
>>> Aug 2011    Submit JSON object encryption document as a WG item.
>>>
>>> Jan 2012    Start Working Group Last Call on JSON object signing document.
>>>
>>> Jan 2012    Start Working Group Last Call on JSON object encryption 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.
>>>
>>> --Paul Hoffman
>>>
>>> _______________________________________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/woes
>>>
>>>
>>
>> --Paul Hoffman
>>
>>
>>
>> _______________________________________________
>> 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, 08 Jul 2011 00:42:13 +0100
From: Stephen Farrell <[email-masked]>
To: Mike Jones <[email-masked]>
Cc: Anthony Nadalin <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

On 08/07/11 00:21, Mike Jones wrote:
> There are other requirements not met by CMS for many of our use cases.  For instance, having a compact representation and having a URL-safe implementation.
> 
> I'm fine with CMS being *one* of the input documents, but I believe it's too strong a statement to say that we've decided up-front that the goal is to "JSONize CMS" or to have the charter reflect that narrowing of the mission.

Can you say what is not in CMS that might be needed here?
I find it hard to think of anything myself, but if there
are things, (specific features, that is) that'd be good
to know.

S.

> 
> 				-- Mike
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, July 07, 2011 4:18 PM
> To: Hannes Tschofenig
> Cc: Anthony Nadalin; [email-masked]
> Subject: Re: [woes] New WOES charter proposal
> 
> On Jul 7, 2011, at 4:06 PM, Hannes Tschofenig wrote:
> 
>> And what does it mean to "base it on CMS"? 
>>
>> It could, for example, mean that 
>> 1) the same functionality as CMS has to be provided (but with a JSON encoding)
>> 2) folks should look at CMS to get inspired
>> 3) for a chosen subset of CMS that the JSON-based realization must be semantically equivalent (for example, to make translation easy or so)
>> 4) re-use of parts is encouraged (such as registries, etc.) 
>>
>> What did you had in mind, Paul? 
> 
> I was reflecting an earlier message from our AD. On Jun 14, 2011, at 9:31 AM, Sean Turner wrote:
> 
>> In Prague, I thought the goal was pretty straightforward: JSONize CMS.
> 
> 
> That seems clear to me. It's closer to your #1 above, but the rest of the proposed charter makes it clear that it is a subset of CMS, namely signing and encrypting.
> 
> --Paul Hoffman
> 
> _______________________________________________
> 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: Mike Jones <[email-masked]>
To: Paul Hoffman <[email-masked]>, Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jul 2011 23:21:40 +0000
Accept-Language: en-US
Cc: Anthony Nadalin <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

There are other requirements not met by CMS for many of our use cases.  For=
 instance, having a compact representation and having a URL-safe implementa=
tion.

I'm fine with CMS being *one* of the input documents, but I believe it's to=
o strong a statement to say that we've decided up-front that the goal is to=
 "JSONize CMS" or to have the charter reflect that narrowing of the mission=
.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pau=
l Hoffman
Sent: Thursday, July 07, 2011 4:18 PM
To: Hannes Tschofenig
Cc: Anthony Nadalin; [email-masked]
Subject: Re: [woes] New WOES charter proposal

On Jul 7, 2011, at 4:06 PM, Hannes Tschofenig wrote:

> And what does it mean to "base it on CMS"?=20
>=20
> It could, for example, mean that=20
> 1) the same functionality as CMS has to be provided (but with a JSON enco=
ding)
> 2) folks should look at CMS to get inspired
> 3) for a chosen subset of CMS that the JSON-based realization must be sem=
antically equivalent (for example, to make translation easy or so)
> 4) re-use of parts is encouraged (such as registries, etc.)=20
>=20
> What did you had in mind, Paul?=20

I was reflecting an earlier message from our AD. On Jun 14, 2011, at 9:31 A=
M, Sean Turner wrote:

> In Prague, I thought the goal was pretty straightforward: JSONize CMS.

That seems clear to me. It's closer to your #1 above, but the rest of the p=
roposed charter makes it clear that it is a subset of CMS, namely signing a=
nd encrypting.

--Paul Hoffman

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

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 16:17:59 -0700
To: Hannes Tschofenig <[email-masked]>
Cc: Anthony Nadalin <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

On Jul 7, 2011, at 4:06 PM, Hannes Tschofenig wrote:

> And what does it mean to "base it on CMS"?=20
>=20
> It could, for example, mean that=20
> 1) the same functionality as CMS has to be provided (but with a JSON =
encoding)
> 2) folks should look at CMS to get inspired
> 3) for a chosen subset of CMS that the JSON-based realization must be =
semantically equivalent (for example, to make translation easy or so)
> 4) re-use of parts is encouraged (such as registries, etc.)=20
>=20
> What did you had in mind, Paul?=20

I was reflecting an earlier message from our AD. On Jun 14, 2011, at =
9:31 AM, Sean Turner wrote:

> In Prague, I thought the goal was pretty straightforward: JSONize CMS.

That seems clear to me. It's closer to your #1 above, but the rest of =
the proposed charter makes it clear that it is a subset of CMS, namely =
signing and encrypting.

--Paul Hoffman

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jul 2011 02:06:22 +0300
To: Anthony Nadalin <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

And what does it mean to "base it on CMS"?=20

It could, for example, mean that=20
1) the same functionality as CMS has to be provided (but with a JSON =
encoding)
2) folks should look at CMS to get inspired
3) for a chosen subset of CMS that the JSON-based realization must be =
semantically equivalent (for example, to make translation easy or so)
4) re-use of parts is encouraged (such as registries, etc.)=20

What did you had in mind, Paul?=20

On Jul 8, 2011, at 12:17 AM, Anthony Nadalin wrote:

> Why do we need to base this on CMS, that should be an open.
>=20
> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]=20
> Sent: Thursday, July 07, 2011 10:55 AM
> To: [email-masked]
> Subject: Re: [woes] New WOES charter proposal
>=20
> More comments, please.
>=20
> On Jul 5, 2011, at 1:44 PM, Paul Hoffman wrote:
>=20
>> Greetings again. After discussion with our ADs about having a much =
more limited charter than what was initially proposed, Richard Barnes =
and I have come up with the following. We would like this discussed as =
much as possible on the list before the Quebec meeting so that the =
meeting can be about finalizing the charter. Thus, comments are welcome.
>>=20
>> We also note that the WG might want to change its name to JOES =
(JavaScript Object Encryption and Signing) to make its work clearer to =
people who don't read the first paragraph of the charter.
>>=20
>> Web Object Encryption and Signing (woes)=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
>> 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 object encryption and =
message signing 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 the =
Cryptographic Message Syntax (CMS), and will solicit input from the rest =
of the IETF Security Area to be sure that the security functionality in =
the JSON format is correct.
>=20
>>=20
>> This group is chartered to work on one or two 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.
>>=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
>> The working group may decide to address both of these goals in a =
single document, in which case the concrete milestones for =
signing/encryption below will both be satisfied by the single document.
>>=20
>> Goals and Milestones
>> --------------------
>>=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
>> 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
>> 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
>> --Paul Hoffman
>>=20
>> _______________________________________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/woes
>>=20
>>=20
>=20
> --Paul Hoffman
>=20
>=20
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

From: Matt Miller <[email-masked]>
Date: Thu, 7 Jul 2011 15:49:40 -0600
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

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

On Jul 7, 2011, at 11:58 , Paul Hoffman wrote:

> On Jul 5, 2011, at 2:55 PM, Mike Jones wrote:
>=20
>> I'm still going to hold out for inclusion of the third document or =
capability needed for end-to-end JSON-based signing and encryption:
>>=20
>> 3) A Standards Track document specifying how to represent public keys =
as JSON data structures.
>>=20
>> I know, for instance that the JSON Web Signature (JWS) doc needs to =
contain a reference to the JSON Web Key (JWK) format, so that also needs =
to be defined.
>=20
> The question is what is the value of defining it in this WG. Why is =
the key format important for interoperability with the signing and =
encrypting specs? If we have a strong answer for that, the ADs might be =
more amenable to adding it; otherwise, it probably falls into the "might =
be nice to have in the future" category.
>=20

I agree with Mike Jones.  Without a common key format, distributing keys =
becomes much more difficult, which makes implementation and deployment =
much more difficult.

- m&m

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

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

--Apple-Mail-1-1055699005--

From: Anthony Nadalin <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 7 Jul 2011 21:17:38 +0000
Accept-Language: en-US
Subject: Re: [woes] New WOES charter proposal

Why do we need to base this on CMS, that should be an open.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]=20
Sent: Thursday, July 07, 2011 10:55 AM
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal

More comments, please.

On Jul 5, 2011, at 1:44 PM, Paul Hoffman wrote:

> Greetings again. After discussion with our ADs about having a much more l=
imited charter than what was initially proposed, Richard Barnes and I have =
come up with the following. We would like this discussed as much as possibl=
e on the list before the Quebec meeting so that the meeting can be about fi=
nalizing the charter. Thus, comments are welcome.
>=20
> We also note that the WG might want to change its name to JOES (JavaScrip=
t Object Encryption and Signing) to make its work clearer to people who don=
't read the first paragraph of the charter.
>=20
> Web Object Encryption and Signing (woes)=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
> 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 JSO=
N in protocols in the IETF and elsewhere, there is now a desire to offer se=
curity services such as object encryption and message signing for data that=
 is being carried in JSON format.
>=20
> Different proposals for providing such security services have already bee=
n defined and implemented. This Working Group's task is to standardize two =
security services, encrypting and digitally signing, in order to increase i=
nteroperability of security features between protocols that use JSON. The W=
orking Group will base its work on the Cryptographic Message Syntax (CMS), =
and will solicit input from the rest of the IETF Security Area to be sure t=
hat the security functionality in the JSON format is correct.

>=20
> This group is chartered to work on one or two documents:
>=20
> 1) A Standards Track document specifying how to apply a JSON-structured d=
igital signature to data, including (but not limited to) JSON data structur=
es.
>=20
> 2) A Standards Track document specifying how to apply a JSON-structured e=
ncryption to data, including (but not limited to) JSON data structures.
>=20
> The working group may decide to address both of these goals in a single d=
ocument, in which case the concrete milestones for signing/encryption below=
 will both be satisfied by the single document.
>=20
> Goals and Milestones
> --------------------
>=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
> Jan 2012    Start Working Group Last Call on JSON object signing document=
.
>=20
> Jan 2012    Start Working Group Last Call on JSON object encryption docum=
ent.
>=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 considerat=
ion=20
> as Standards Track document.
>=20
> --Paul Hoffman
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>=20
>=20

--Paul Hoffman

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 10:58:29 -0700
To: Mike Jones <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [woes] New WOES charter proposal

On Jul 5, 2011, at 2:55 PM, Mike Jones wrote:

> I'm still going to hold out for inclusion of the third document or =
capability needed for end-to-end JSON-based signing and encryption:
>=20
> 3) A Standards Track document specifying how to represent public keys =
as JSON data structures.
>=20
> I know, for instance that the JSON Web Signature (JWS) doc needs to =
contain a reference to the JSON Web Key (JWK) format, so that also needs =
to be defined.

The question is what is the value of defining it in this WG. Why is the =
key format important for interoperability with the signing and =
encrypting specs? If we have a strong answer for that, the ADs might be =
more amenable to adding it; otherwise, it probably falls into the "might =
be nice to have in the future" category.

--Paul Hoffman

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 10:55:00 -0700
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal

More comments, please.

On Jul 5, 2011, at 1:44 PM, Paul Hoffman wrote:

> Greetings again. After discussion with our ADs about having a much =
more limited charter than what was initially proposed, Richard Barnes =
and I have come up with the following. We would like this discussed as =
much as possible on the list before the Quebec meeting so that the =
meeting can be about finalizing the charter. Thus, comments are welcome.
>=20
> We also note that the WG might want to change its name to JOES =
(JavaScript Object Encryption and Signing) to make its work clearer to =
people who don't read the first paragraph of the charter.
>=20
> Web Object Encryption and Signing (woes)=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
> 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 object encryption and =
message signing 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 the =
Cryptographic Message Syntax (CMS), and will solicit input from the rest =
of the IETF Security Area to be sure that the security functionality in =
the JSON format is correct.
>=20
> This group is chartered to work on one or two 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.
>=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
> The working group may decide to address both of these goals in a =
single document, in which case the concrete milestones for =
signing/encryption below will both be satisfied by the single document.
>=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
> 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
> 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
> --Paul Hoffman
>=20
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes
>=20
>=20

--Paul Hoffman

From: Mike Jones <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 5 Jul 2011 21:55:21 +0000
Accept-Language: en-US
Subject: Re: [woes] New WOES charter proposal

I'm still going to hold out for inclusion of the third document or capabili=
ty needed for end-to-end JSON-based signing and encryption:

3) A Standards Track document specifying how to represent public keys as JS=
ON data structures.

I know, for instance that the JSON Web Signature (JWS) doc needs to contain=
 a reference to the JSON Web Key (JWK) format, so that also needs to be def=
ined.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pau=
l Hoffman
Sent: Tuesday, July 05, 2011 1:44 PM
To: [email-masked]
Subject: [woes] New WOES charter proposal

Greetings again. After discussion with our ADs about having a much more lim=
ited charter than what was initially proposed, Richard Barnes and I have co=
me up with the following. We would like this discussed as much as possible =
on the list before the Quebec meeting so that the meeting can be about fina=
lizing the charter. Thus, comments are welcome.

We also note that the WG might want to change its name to JOES (JavaScript =
Object Encryption and Signing) to make its work clearer to people who don't=
 read the first paragraph of the charter.

Web Object Encryption and Signing (woes) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=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
----------

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 s=
tructured 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 secu=
rity services such as object encryption and message signing for data that i=
s 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 se=
curity services, encrypting and digitally signing, in order to increase int=
eroperability of security features between protocols that use JSON. The Wor=
king Group will base its work on the Cryptographic Message Syntax (CMS), an=
d will solicit input from the rest of the IETF Security Area to be sure tha=
t the security functionality in the JSON format is correct.

This group is chartered to work on one or two documents:

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=
.

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

The working group may decide to address both of these goals in a single doc=
ument, in which case the concrete milestones for signing/encryption below w=
ill 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.

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

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

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

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

--Paul Hoffman

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

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2011 13:44:07 -0700
To: [email-masked]
Subject: [woes] New WOES charter proposal

Greetings again. After discussion with our ADs about having a much more =
limited charter than what was initially proposed, Richard Barnes and I =
have come up with the following. We would like this discussed as much as =
possible on the list before the Quebec meeting so that the meeting can =
be about finalizing the charter. Thus, comments are welcome.

We also note that the WG might want to change its name to JOES =
(JavaScript Object Encryption and Signing) to make its work clearer to =
people who don't read the first paragraph of the charter.

Web Object Encryption and Signing (woes)=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
----------

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 object encryption and =
message signing 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 the =
Cryptographic Message Syntax (CMS), and will solicit input from the rest =
of the IETF Security Area to be sure that the security functionality in =
the JSON format is correct.

This group is chartered to work on one or two 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.

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

The working group may decide to address both of these goals in a single =
document, in which case the concrete milestones for signing/encryption =
below will both be satisfied by the single document.

Goals and Milestones=20
--------------------

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

Aug 2011    Submit JSON object encryption 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.

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.

--Paul Hoffman