Subject: [woes] Fwd: Javascript Cryptography Considered Harmful
From: Peter Saint-Andre <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 12 Sep 2011 10:34:15 -0600
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>

Perhaps of interest here...

-------- Original Message --------
Subject: Javascript Cryptography Considered Harmful
Resent-Date: Mon, 12 Sep 2011 14:36:47 +0000
Resent-From: [email-masked]
Date: Mon, 12 Sep 2011 16:36:15 +0200
From: Henry Story <[email-masked]>
To: WebID XG <[email-masked]>

An interesting article
http://www.matasano.com/articles/javascript-cryptography/

WHAT DO YOU MEAN, "JAVASCRIPT CRYPTOGRAPHY"?
============================================

We mean attempts to implement security features in browsers using
cryptographic algoritms implemented in whole or in part in Javascript.

You may now be asking yourself, "What about Node.js? What about
non-browser Javascript?". Non-browser Javascript cryptography is
perilous, but not doomed. For the rest of this document, we're referring
to browser Javascript when we discuss Javascript cryptography.

WHAT ARE SOME EXAMPLES OF "DOOMED" BROWSER CRYPTOGRAPHY?
========================================================

You have a web application. People log in to it with usernames and
passwords. You'd rather they didn't send their passwords in the clear,
where attackers can capture them. You could use SSL/TLS to solve this
problem, but that's expensive and complicated. So instead, you create a
challenge-response protocol, where the application sends Javascript to
user browsers that gets them to send HMAC-SHA1(password, nonce) to prove
they know a password without ever transmitting the password.

Or, you have a different application, where users edit private notes
stored on a server. You'd like to offer your users the feature of
knowing that their notes can't be read by the server. So you generate an
AES key for each note, send it to the user's browser to store locally,
forget the key, and let the user wrap and unwrap their data.

[...]

Henry

Social Web Architect
http://bblfish.net/

From: "Paul C. Bryan" <[email-masked]>
To: [email-masked]
Date: Mon, 12 Sep 2011 08:48:20 -0700
Subject: Re: [woes] First draft of JSON Web Encryption (JWE) spec published

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

 On Wed, 2011-09-07 at 04:37 +0000, Mike Jones wrote:
> I’m pleased to announce the publication of the first draft of the JSON
> Web Encryption (JWE) specification. It enables JSON-based encryption
> of content in a parallel manner to how the JSON Web Signature (JWS)
> specification enables JSON-based signing of content.

My comments, on excerpts from the text:

> JSON Web Encryption (JWE) is a compact encryption format intended for
> space constrained environments such as HTTP Authorization headers and
> URI query parameters.
Is there a target document size you're aiming for here (and hence can
test whether such objectives can even be met), or just
as-small-as-possible so it has the best possible chance to fit into such
environments? If it turns out that JSON is not suitable to meet these
objectives, which shall be sacrificed: JSON or compactness?

> JWE provides a wrapper for encrypted content using JSON data
> structures and base64url encoding. The representation consists of
> three parts: the JWT Header, the JWE Encrypted Key, and the JWE
> Ciphertext. The three parts are base64url-encoded for transmission,
> and typically represented as the concatenation of the encoded strings
> in that order, with the three strings being separated by period ('.')
> characters, as is done when used in JSON Web Tokens (JWTs)

You've invented a whole new structure that is not JSON. Sure, it
leverages JSON in the header, which is then base64-encoded (which I
point out also contains base64-encoded values itself, so this results in
double-base64-encoding of some values). I would argue that there should
at least be a representation that remains JSON-proper, which contains
the encrypted key and ciphertext.

> epk string String

JSON provides for the intuitive representation structured data. Why are
you choosing to encode a structured value in a string? If your answer is
"compactness" then I think we need to either rethink the use of JSON or
rethink this objective of compactness.

> jku string URL

What are the rules for accessing such keys? Can this be a URL relative
to the encrypted document, if it has a known location?

> Omitting this [kid] parameter is equivalent to setting it to an empty
> string.

Why are you allowing for empty string? What is the semantic of having it
be empty string? What about null?

> x5u string URL

Same question here as for jku.

> typ String String

Is this meant to the the Internet media type?

> For GCM, the random 64-bit IV is prepended to the ciphertext.

Isn't the "iv" property in the header already being used for this
purpose?

> 10. IANA Considerations

I recommend that a media type also be proposed, such as "application/jwe
+json".

Paul

--=-qTC7Wzfk/IRwC8uvgWQG
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 LINK="#0000ff">
 On Wed, 2011-09-07 at 04:37 +0000, Mike Jones wrote:
<BLOCKQUOTE TYPE=CITE>
    I&#8217;m pleased to announce the publication of the <A HREF="http://self-issued.info/docs/draft-jones-json-web-encryption-00.html">first draft</A> of the <A HREF="http://self-issued.info/docs/draft-jones-json-web-encryption.html">JSON Web Encryption (JWE)</A> specification. It enables JSON-based encryption of content in a parallel manner to how the <A HREF="http://self-issued.info/docs/draft-jones-json-web-signature.html">JSON Web Signature (JWS)</A> specification enables JSON-based signing of content.<BR>
</BLOCKQUOTE>
<BR>
My comments, on excerpts from the text:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    JSON Web Encryption (JWE) is a compact encryption format intended for space constrained environments such as HTTP Authorization headers and URI query parameters.
</BLOCKQUOTE>
Is there a target document size you're aiming for here (and hence can test whether such objectives can even be met), or just as-small-as-possible so it has the best possible chance to fit into such environments? If it turns out that JSON is not suitable to meet these objectives, which shall be sacrificed: JSON or compactness?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    JWE provides a wrapper for encrypted content using JSON data structures and base64url encoding. The representation consists of three parts: the JWT Header, the JWE Encrypted Key, and the JWE Ciphertext. The three parts are base64url-encoded for transmission, and typically represented as the concatenation of the encoded strings in that order, with the three strings being separated by period ('.') characters, as is done when used in JSON Web Tokens (JWTs)<BR>
</BLOCKQUOTE>
You've invented a whole new structure that is <I>not</I> JSON. Sure, it <I>leverages</I> JSON in the header, which is then base64-encoded (which I point out also contains base64-encoded values itself, so this results in double-base64-encoding of some values). I would argue that there should at least be a representation that remains JSON-proper, which <I>contains</I> the encrypted key and ciphertext.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    epk string String<BR>
</BLOCKQUOTE>
JSON provides for the intuitive representation structured data. Why are you choosing to encode a structured value in a string? If your answer is &quot;compactness&quot; then I think we need to either rethink the use of JSON or rethink this objective of compactness.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    jku string URL<BR>
</BLOCKQUOTE>
What are the rules for accessing such keys? Can this be a URL relative to the encrypted document, if it has a known location?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    Omitting this [kid] parameter is equivalent to setting it to an empty string.<BR>
</BLOCKQUOTE>
Why are you allowing for empty string? What is the semantic of having it be empty string? What about null?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    x5u string URL<BR>
</BLOCKQUOTE>
Same question here as for jku.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    typ String String<BR>
</BLOCKQUOTE>
Is this meant to the the Internet media type?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    For GCM, the random 64-bit IV is prepended to the ciphertext.<BR>
</BLOCKQUOTE>
Isn't the &quot;iv&quot; property in the header already being used for this purpose?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    10. IANA Considerations<BR>
</BLOCKQUOTE>
I recommend that a media type also be proposed, such as &quot;application/jwe+json&quot;.<BR>
<BR>
Paul<BR>
<BR>
</BODY>
</HTML>

--=-qTC7Wzfk/IRwC8uvgWQG--

From: "Thomson, Martin" <[email-masked]>
To: Mike Jones <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 7 Sep 2011 14:16:37 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Nat Sakimura <[email-masked]>
Subject: Re: [woes] First draft of JSON Web Encryption (JWE) spec published

Or to add another link for the rest of us:

http://tools.ietf.org/html/draft-jones-json-web-encryption

I found the presentation to be a little sketchy.  The table is difficult to=
 parse.  I think that the table is constraining how you describe the parame=
ters, and I'm concerned that underspecification here will hurt.  The second=
 and third columns don't seem to add much over the description (the second =
column is all "string").  I'd suggest that you give each parameter a number=
ed section.  That way, they appear in the TOC.

The x5u parameter identifies what exactly?  Is it the URI for a resource th=
at, upon retrieval (e.g., HTTP GET), produces an X.509 certificate (chain)?=
  I think that's what you mean.  The example seems to use base64url encodin=
g, which seems pointless.

"Utilizing TLS" also needs to be expanded.  You obviously need to ensure th=
at the authority providing the resource is authenticated and that the repre=
sentation you retrieve is free from modification, so say that.

The "typ" parameter seems a little underspecified.

The epk parameter isn't a string by its description, though the table indic=
ates that it is.  ...unless you wanted to base64url encode the JSON object.

The alg and enc parameters use StringOrURI as their definition.  There are =
no URIs defined for either.  I suspect that there is something in there you=
 are wanting to get at, but I recommend that just "String" is sufficient.  =
After all, someone is going to have to decide if "alg": "http://foo" is equ=
al to "alg": "HTTP://FOO" and I don't want to have to be that guy.  Saying =
that you character-wise compare the strings for equality is really, really =
good.

That doesn't preclude the definition of a scheme where URIs are used to pre=
vent collisions in the namespace, but I suspect that your existing text on =
public/private use of codes is sufficient.

BTW, I like your decision to make all parameters mandatory.  This is less a=
 concern with encryption as it is with signature, but it seems like it's be=
tter to be consistent across the two.

--Martin

On 2011-09-07 at 14:37:56, Mike Jones wrote:
> I'm pleased to announce the publication of the first draft=20
> <http://self-issued.info/docs/draft-jones-json-web-encryption-00.html>
> of the JSON Web Encryption (JWE)
> <http://self-issued.info/docs/draft-jones-json-web-encryption.html>
> specification. It enables JSON-based encryption of content in a=20
> parallel manner to how the JSON Web Signature (JWS) <http://self-=20
> issued.info/docs/draft-jones-json-web-signature.html>
> specification enables JSON-based signing of content.
>=20
> My thanks to John Bradley, Nat Sakimura, Eric Rescorla, and Joe=20
> Hildebrand for helping make this initial version a reality!
>=20
> The specification is available at these locations:
>=20
> *
> http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption-
> 00.t
> xt
>=20
> *
> http://www.ietf.org/internet-drafts/draft-jones-json-web-encryption-
> 00.x
> ml
>=20
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption-00.html
>=20
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption-00.txt
>=20
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption-00.xml
>=20
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption.html
> (will point to new versions as they are posted)
>=20
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption.txt (will=20
> point to new versions as they are posted)
>=20
> *
> http://self-issued.info/docs/draft-jones-json-web-encryption.xml (will=20
> point to new versions as they are posted)
>=20
> *
> http://svn.openid.net/repos/specifications/json_web_encryption/1.0/
> (Subversion repository, with html, txt, and html versions available)
>=20
>=20
>=20
> I also posted about this at http://self-issued.info/?p=3D538=20
> <http://self-issued.info/?p=3D538> .
>=20
>=20
>=20
>                                                             -- Mike
>=20
>=20

From: Mike Jones <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Sep 2011 04:37:56 +0000
Accept-Language: en-US
Cc: Nat Sakimura <[email-masked]>
Subject: [woes] First draft of JSON Web Encryption (JWE) spec published

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

I'm pleased to announce the publication of the first draft<http://self-issu=
ed.info/docs/draft-jones-json-web-encryption-00.html> of the JSON Web Encry=
ption (JWE)<http://self-issued.info/docs/draft-jones-json-web-encryption.ht=
ml> specification. It enables JSON-based encryption of content in a paralle=
l manner to how the JSON Web Signature (JWS)<http://self-issued.info/docs/d=
raft-jones-json-web-signature.html> specification enables JSON-based signin=
g of content.
My thanks to John Bradley, Nat Sakimura, Eric Rescorla, and Joe Hildebrand =
for helping make this initial version a reality!
The specification is available at these locations:

*        http://www.ietf.org/internet-drafts/draft-jones-json-web-encryptio=
n-00.txt

*        http://www.ietf.org/internet-drafts/draft-jones-json-web-encryptio=
n-00.xml

*        http://self-issued.info/docs/draft-jones-json-web-encryption-00.ht=
ml

*        http://self-issued.info/docs/draft-jones-json-web-encryption-00.tx=
t

*        http://self-issued.info/docs/draft-jones-json-web-encryption-00.xm=
l

*        http://self-issued.info/docs/draft-jones-json-web-encryption.html =
(will point to new versions as they are posted)

*        http://self-issued.info/docs/draft-jones-json-web-encryption.txt (=
will point to new versions as they are posted)

*        http://self-issued.info/docs/draft-jones-json-web-encryption.xml (=
will point to new versions as they are posted)

*        http://svn.openid.net/repos/specifications/json_web_encryption/1.0=
/ (Subversion repository, with html, txt, and html versions available)

I also posted about this at http://self-issued.info/?p=3D538.

                                                            -- Mike

--_000_4E1F6AAD24975D4BA5B16804296739435B782D23TK5EX14MBXC203r_
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:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1131559463;
	mso-list-type:hybrid;
	mso-list-template-ids:1206393086 67698689 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></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">I&#8217;m pleased to announce the publication of the=
 <a href=3D"http://self-issued.info/docs/draft-jones-json-web-encryption-00=
.html">
first draft</a> of the <a href=3D"http://self-issued.info/docs/draft-jones-=
json-web-encryption.html">
JSON Web Encryption (JWE)</a> specification. It enables JSON-based encrypti=
on of content in a parallel manner to how the
<a href=3D"http://self-issued.info/docs/draft-jones-json-web-signature.html=
">JSON Web Signature (JWS)</a> specification enables JSON-based signing of =
content.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">My thanks to John Bradley, Nat Sakimura, Eric Rescor=
la, and Joe Hildebrand for helping make this initial version a reality!<o:p=
></o:p></p>
<p class=3D"MsoNormal"><o:p></o:p></p>
<p class=3D"MsoNormal">The specification is available at these locations:<o=
:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://www.ietf.org/internet-draf=
ts/draft-jones-json-web-encryption-00.txt">http://www.ietf.org/internet-dra=
fts/draft-jones-json-web-encryption-00.txt</a><o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://www.ietf.org/internet-draf=
ts/draft-jones-json-web-encryption-00.xml">http://www.ietf.org/internet-dra=
fts/draft-jones-json-web-encryption-00.xml</a><o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://self-issued.info/docs/draf=
t-jones-json-web-encryption-00.html">http://self-issued.info/docs/draft-jon=
es-json-web-encryption-00.html</a><o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://self-issued.info/docs/draf=
t-jones-json-web-encryption-00.txt">http://self-issued.info/docs/draft-jone=
s-json-web-encryption-00.txt</a><o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://self-issued.info/docs/draf=
t-jones-json-web-encryption-00.xml">http://self-issued.info/docs/draft-jone=
s-json-web-encryption-00.xml</a><o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://self-issued.info/docs/draf=
t-jones-json-web-encryption.html">http://self-issued.info/docs/draft-jones-=
json-web-encryption.html</a> (will point to new versions as they are posted=
)<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://self-issued.info/docs/draf=
t-jones-json-web-encryption.txt">http://self-issued.info/docs/draft-jones-j=
son-web-encryption.txt</a> (will point to new versions as they are posted)<=
o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://self-issued.info/docs/draf=
t-jones-json-web-encryption.xml">http://self-issued.info/docs/draft-jones-j=
son-web-encryption.xml</a> (will point to new versions as they are posted)<=
o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"font-family:Symbol"><span style=
=3D"mso-list:Ignore">&middot;<span style=3D"font:7.0pt &quot;Times New Roma=
n&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><a href=3D"http://svn.openid.net/repos/speci=
fications/json_web_encryption/1.0/">http://svn.openid.net/repos/specificati=
ons/json_web_encryption/1.0/</a> (Subversion repository, with html, txt, an=
d html versions available)<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I also posted about this at <a href=3D"http://self-i=
ssued.info/?p=3D538">
http://self-issued.info/?p=3D538</a>.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; -- Mike<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_4E1F6AAD24975D4BA5B16804296739435B782D23TK5EX14MBXC203r_--

From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Date: Fri, 2 Sep 2011 13:05:50 -0700
Subject: [woes] Scope of this work

I am still trying to get my head on the things that people do and do not
think are going to be needed for this work.  Specifically I am trying to
figure out what are the set of features that people want to see.

I think that it would be useful if someone were to write a throw away draft
that did the following.

Taking the current CMS structures that we thing should be mapped -
AuthenticatedEnvelopedData, SignedData and AuthenicatedData.
Walk through each of the fields in these structures and write a one line
summary of the function of the field.
Make a statement that this is or is not a feature that should be followed in
the WOES work.

Examples:

SignedData.digestAlgorithms - provides a list of content digest algorithms
to allow for one pass processing.  WOES does not need one pass processing

SignedData.signerInfos - provides a list of different signers for the data.
WOES does not need to support multiple signers

SignedData.encapContentInfo.eContent - optional field allowing the signed
content to either be embedded in the structure or detached from the
structure.  WOES will not support detached content.

We can then determine which of the features are to be supported and are not
to be supported.  There may be other fields from different structures that
also needed to be looked at.  However I believe that it is universally
stated that we don't want to do the transforms of XMLDigsig, although it
might be that canonicalization may need to be looked at.

Note - arguments that could be added to the above would be:

The digestAlgorithms field provides for the ability for one pass processing
for both senders and recipients.  Given that senders only do things once and
recipients do things multiple times it might be useful to enable one pass
processing for recipients and state that it does not exist for senders.
Doing this does not mean that we need to have this field, it could instead
be supported by placing the data contained in the signerInfo field before
the encapsulated content.  Options would be No One Pass Processing, One Pass
Processing for both, One Pass Processing for Sender, One Pass Processing for
Recipient.

Jim

Date: Thu, 01 Sep 2011 09:11:29 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: [woes] mailing list name change

I just sent in the request to rename [email-masked] to [email-masked]. 
I'll get them to copy over the membership so people that are on the list 
shouldn't have to do anything.  I'll also get them to retain the archives.

spt

From [email-masked]  Fri Sep 23 14:39:16 2011
From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Date: Fri, 23 Sep 2011 14:39:16 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked]
Subject: [jose] WG Action: Javascript Object Signing and Encryption (jose)

A new IETF working group has been formed in the Security Area.  
For additional information, please contact the Area Directors or the WG Chairs.

Javascript Object Signing and Encryption (jose)
=================================================
Status: Active Working Group

Chairs
    Tony Hansen ([email-masked])
    Jim Schaad ([email-masked])

Security Area Directors:
    Stephen Farrell ([email-masked])
    Sean Turner ([email-masked])

Security Area Advisor:
    Sean Turner ([email-masked])

Mailing Lists:
   General Discussion: [email-masked]
   To Subscribe: <https://www.ietf.org/mailman/listinfo/jose>
   Archive: <http://www.ietf.org/mail-archive/web/jose/>

Description of Working Group
----------------------------

Javascript Object Notation (JSON) is a text format for the serialization 
of structured data described in RFC 4627. The JSON format is often used 
for serializing and transmitting structured data over a network 
connection. With the increased usage of JSON in protocols in the IETF 
and elsewhere, there is now a desire to offer security services such as 
encryption, digital signatures, and message authentication codes (MACs) 
for data that is being carried in JSON format.

Different proposals for providing such security services have already 
been defined and implemented. This Working Group's task is to 
standardize two security services, integrity protection (signature and 
MAC) and encryption, in order to increase interoperability of security 
features between protocols that use JSON.  The Working Group will base 
its work on well-known message security primitives (e.g., CMS), and will 
solicit input from the rest of the IETF Security Area to be sure that 
the security functionality in the JSON format is correct.

This group is chartered to work on four documents:

1) A Standards Track document specifying how to apply JSON-structured 
integrity protection to data, including (but not limited to) JSON data 
structures.  "Integrity protection" includes public-key digital 
signatures as well as symmetric-key MACs.

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

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

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

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

Goals and Milestones
--------------------

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

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

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

Jan 2012    Submit JSON algorithm document as a WG item.

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

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

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

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

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

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

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

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

From [email-masked]  Fri Sep 30 14:10:44 2011
Date: Fri, 30 Sep 2011 15:13:37 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=https://stpeter.im/stpeter.asc
Subject: [jose] meeting in Taipei?

Is the JOSE WG meeting at IETF 82? Inquiring minds want to know. :)

/psa

From [email-masked]  Fri Sep 30 14:12:29 2011
From: Mike Jones <[email-masked]>
To: Peter Saint-Andre <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 30 Sep 2011 21:15:22 +0000
Accept-Language: en-US
Subject: Re: [jose] meeting in Taipei?

Hope so!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pet=
er Saint-Andre
Sent: Friday, September 30, 2011 2:14 PM
To: [email-masked]
Subject: [jose] meeting in Taipei?

Is the JOSE WG meeting at IETF 82? Inquiring minds want to know. :)

/psa

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

From [email-masked]  Fri Sep 30 14:25:05 2011
Date: Fri, 30 Sep 2011 17:27:56 -0400
From: Sean Turner <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [jose] meeting in Taipei?

I have received the sessions request.  So it's looks like a go modulo 
the agenda being agreed.

spt

On 9/30/11 5:13 PM, Peter Saint-Andre wrote:
> Is the JOSE WG meeting at IETF 82? Inquiring minds want to know. :)
>
> /psa
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>