Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5CB3A6A20; Wed, 30 Mar 2011 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCBUOkIX0f7y; Wed, 30 Mar 2011 08:35:45 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 15EFA28C131; Wed, 30 Mar 2011 08:35:44 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Mar 2011 08:37:22 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0270.002; Wed, 30 Mar 2011 08:37:21 -0700 From: Mike Jones To: Bob Gregory Thread-Topic: [OAUTH-WG] JSON Web Token (JWT) Draft -04 Thread-Index: AcvuuIVAmFKf4FToR3mJsYxJZdQlsgAckiCAAA6ifnA= Date: Wed, 30 Mar 2011 15:37:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252BA221@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252B2BB6@TK5EX14MBXC203.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252BA221TK5EX14MBXC203r_" MIME-Version: 1.0 Cc: "openid-specs-ab@lists.openid.net" , "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [woes] [OAUTH-WG] JSON Web Token (JWT) Draft -04 X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:35:53 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252BA221TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Bob. That's great to hear! I look forward to your feedback on the spec based upon your actual use. -- Mike From: Bob Gregory [mailto:pathogenix@gmail.com] Sent: Wednesday, March 30, 2011 8:36 AM To: Mike Jones Cc: woes@ietf.org; oauth@ietf.org; openid-specs-ab@lists.openid.net; openid= -specs@lists.openid.net Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04 I've just uploaded a .Net implementation of JWT issuance and consumption to= GitHub @ https://github.com/BobFromHuddle/Jwt4Net This is no way ready for public release, but is in use in a production syst= em. It's based on draft 1, and I'll try and update it to draft 4 compliance= next week. We're intending to provide full coverage of the JWT spec as it matures, th= e major block for us at the moment is the lack of a specification for the "= jku" key encoding scheme. Until that's decided, we're using .Net's default = serialization of private keys which is based on RFC 4050. -- Bob Gregory On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones > wrote: Draft -04 of the JSON Web Token (JWT) specification is available. It corrects a typo fo= und by John Bradley in -03. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.= txt * http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.= xml * http://self-issued.info/docs/draft-jones-json-web-token-04.html * http://self-issued.info/docs/draft-jones-json-web-token-04.txt * http://self-issued.info/docs/draft-jones-json-web-token-04.xml * http://self-issued.info/docs/draft-jones-json-web-token.html (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted) * http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted) * http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Su= bversion repository, with html, txt, and html versions available) -- Mike -- An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers. --_000_4E1F6AAD24975D4BA5B1680429673943252BA221TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Bob.  That&#= 8217;s great to hear!

 <= /p>

I look forward to your fe= edback on the spec based upon your actual use.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: Bob Greg= ory [mailto:pathogenix@gmail.com]
Sent: Wednesday, March 30, 2011 8:36 AM
To: Mike Jones
Cc: woes@ietf.org; oauth@ietf.org; openid-specs-ab@lists.openid.net;= openid-specs@lists.openid.net
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Draft -04

 

I've just uploaded a .Net implementation of JWT issu= ance and consumption to GitHub @ https://github.com/BobFromHuddle/Jwt4Net

 

This is no way ready for public release, but is in u= se in a production system. It's based on draft 1, and I'll try and update i= t to draft 4 compliance next week.

 

We're intending to provide full coverage of  th= e JWT spec as it matures, the major block for us at the moment is the lack = of a specification for the "jku" key encoding scheme. Until that'= s decided, we're using .Net's default serialization of private keys which is based on RFC 4050.

 

 -- Bob Gregory

 

On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

Draft -04 of the JSON Web Token (JWT) specification is available.  It corrects a ty= po found by John Bradley in -03.

 

The draft is available at these locations:

·        http://www.ietf.org/internet-drafts/draft-j= ones-json-web-token-04.txt

·        http://www.ietf.org/internet-drafts/draft-j= ones-json-web-token-04.xml

·        http://self-issued.info/docs/draft-jones-json-web= -token-04.html

·        http://self-issued.info/docs/draft-jones-json-web-= token-04.txt

·        http://self-issued.info/docs/draft-jones-json-web-= token-04.xml

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

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

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

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

 

           =             &nb= sp;            =              &n= bsp;          -- Mike

 




--
An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The = bartender says "You're all idiots", and pours two beers.

--_000_4E1F6AAD24975D4BA5B1680429673943252BA221TK5EX14MBXC203r_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DA23A6B68; Wed, 30 Mar 2011 08:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZB4oNLpUy8x; Wed, 30 Mar 2011 08:34:05 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1922F3A69C0; Wed, 30 Mar 2011 08:34:05 -0700 (PDT) Received: by qwg5 with SMTP id 5so1044842qwg.31 for ; Wed, 30 Mar 2011 08:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=czBfwkEGD9mZvL/bMJ7PY2ezGC1zM5rMYUXtBOgOJeE=; b=smeJVM+dJmExfNFKfQ32jAXpstXvhrTZj9hG1QhvaLbpHE/EWUE1s7ZPl5KQ66wJhL /lpzyJYAoPQCcW/ed4uXG9e26RMZSWKS69Y7ecM+lMBaryDHievlybNyOK21mkm5O4d+ Iuzxr0i/yVNQZAZJ4aePtWS+KnwHw3cPRDnNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nnGxdjentjvyqZNiL/Ch5puDcBSr6Mlcnl/7cvE5skAWWdE8+Ga68cVbtp6fGTYxjf 9qySUVaHIzOSzZV5AF6IeiUJHdWxvr+3s4tK/K1GUKy/GSt+f+Qsh2ugNjFRcaS5rTW8 IBuR4/QhhwYQ9igoQ7u8x63ntDzJLlKg6/o0A= MIME-Version: 1.0 Received: by 10.229.97.213 with SMTP id m21mr1162525qcn.288.1301499343734; Wed, 30 Mar 2011 08:35:43 -0700 (PDT) Received: by 10.229.11.136 with HTTP; Wed, 30 Mar 2011 08:35:43 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252B2BB6@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252B2BB6@TK5EX14MBXC203.redmond.corp.microsoft.com> Date: Wed, 30 Mar 2011 16:35:43 +0100 Message-ID: From: Bob Gregory To: Mike Jones Content-Type: multipart/alternative; boundary=00163683259e0f094a049fb4eecf X-Mailman-Approved-At: Wed, 30 Mar 2011 09:10:50 -0700 Cc: "openid-specs-ab@lists.openid.net" , "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [woes] [OAUTH-WG] JSON Web Token (JWT) Draft -04 X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:34:08 -0000 --00163683259e0f094a049fb4eecf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've just uploaded a .Net implementation of JWT issuance and consumption to GitHub @ https://github.com/BobFromHuddle/Jwt4Net This is no way ready for public release, but is in use in a production system. It's based on draft 1, and I'll try and update it to draft 4 compliance next week. We're intending to provide full coverage of the JWT spec as it matures, th= e major block for us at the moment is the lack of a specification for the "jku" key encoding scheme. Until that's decided, we're using .Net's default serialization of private keys which is based on RFC 4050. -- Bob Gregory On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones wr= ote: > Draft -04 of the JSON Web Token (JWT)specification is available. It corrects a typo = found by John Bradley in > -03. > > > > The draft is available at these locations: > > =B7 > http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.txt > > =B7 > http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.xml > > =B7 http://self-issued.info/docs/draft-jones-json-web-token-04.htm= l > > =B7 http://self-issued.info/docs/draft-jones-json-web-token-04.txt > > =B7 http://self-issued.info/docs/draft-jones-json-web-token-04.xml > > =B7 http://self-issued.info/docs/draft-jones-json-web-token.html(w= ill point to new versions as they are posted) > > =B7 http://self-issued.info/docs/draft-jones-json-web-token.txt (w= ill > point to new versions as they are posted) > > =B7 http://self-issued.info/docs/draft-jones-json-web-token.xml (w= ill > point to new versions as they are posted) > > =B7 http://svn.openid.net/repos/specifications/json_web_token/1.0/= (Subversion repository, with html, txt, and html versions available) > > > > -- Mike > > > --=20 An infinite number of mathematicians walk into a bar. The first one orders = a beer. The second orders half a beer. The third, a quarter of a beer. The bartender says "You're all idiots", and pours two beers. --00163683259e0f094a049fb4eecf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've just uploaded a .Net implementation of JWT issuance and consumptio= n to GitHub @=A0https:= //github.com/BobFromHuddle/Jwt4Net

This is no way ready for public rel= ease, but is in use in a production system. It's based on draft 1, and = I'll try and update it to draft 4 compliance next week.

We're intending to provide full coverage of =A0the = JWT spec as it matures, the major block for us at the moment is the lack of= a specification for the "jku" key encoding scheme. Until that= 9;s decided, we're using .Net's default serialization of private ke= ys which is based on RFC 4050.

=A0-- Bob Gregory

On Wed, Mar 30, 2011 at 9:57 AM, Mike Jones <Michael.Jones@microsoft.com>= wrote:

Draft -04 of the JSON Web Token (JWT) specification is available.=A0 It corrects a typo = found by John Bradley in -03.

=A0

The draft is available at these locations:

=B7=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-= drafts/draft-jones-json-web-token-04.txt

=B7=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-= drafts/draft-jones-json-web-token-04.xml

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-= jones-json-web-token-04.html

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-j= ones-json-web-token-04.txt

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-j= ones-json-web-token-04.xml

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jon= es-json-web-token.html (will point to new versions as they are posted)<= /p>

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jone= s-json-web-token.txt (will point to new versions as they are posted)

=B7=A0=A0=A0=A0=A0=A0=A0 http://self-issued.info/docs/draft-jone= s-json-web-token.xml (will point to new versions as they are posted)

=B7=A0=A0=A0=A0=A0=A0=A0 http://svn.openid.net/repos/specific= ations/json_web_token/1.0/ (Subversion repository, with html, txt, and = html versions available)

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0




--
An infinite number of m= athematicians walk into a bar. The first one orders a beer. The second orde= rs half a beer. The third, a quarter of a beer. The bartender says "Yo= u're all idiots", and pours two beers.
--00163683259e0f094a049fb4eecf-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEC328C116; Wed, 30 Mar 2011 01:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek-C6i+ZAF1X; Wed, 30 Mar 2011 01:56:04 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0874A28C115; Wed, 30 Mar 2011 01:56:03 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Mar 2011 01:57:42 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.38]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0270.002; Wed, 30 Mar 2011 01:57:42 -0700 From: Mike Jones To: "woes@ietf.org" , "oauth@ietf.org" , "openid-specs-ab@lists.openid.net" Thread-Topic: JSON Web Token (JWT) Draft -04 Thread-Index: AcvuuIVAmFKf4FToR3mJsYxJZdQlsg== Date: Wed, 30 Mar 2011 08:57:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252B2BB6@TK5EX14MBXC203.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252B2BB6TK5EX14MBXC203r_" MIME-Version: 1.0 Cc: "openid-specs@lists.openid.net" Subject: [woes] JSON Web Token (JWT) Draft -04 X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:56:05 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252B2BB6TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -04 of the JSON Web Token (JWT) specification is available. It corrects a typo fo= und by John Bradley in -03. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.= txt * http://www.ietf.org/internet-drafts/draft-jones-json-web-token-04.= xml * http://self-issued.info/docs/draft-jones-json-web-token-04.html * http://self-issued.info/docs/draft-jones-json-web-token-04.txt * http://self-issued.info/docs/draft-jones-json-web-token-04.xml * http://self-issued.info/docs/draft-jones-json-web-token.html (will= point to new versions as they are posted) * http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted) * http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted) * http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Su= bversion repository, with html, txt, and html versions available) -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943252B2BB6TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -04 of the JSON Web Token (JWT) specification is available.  It corrects a ty= po found by John Bradley in -03.

 

The draft is available at these locations:

·        http://www.ietf.org/internet-drafts/d= raft-jones-json-web-token-04.txt

·        http://www.ietf.org/internet-drafts/d= raft-jones-json-web-token-04.xml

·        http://self-issued.info/docs/draft-jones-js= on-web-token-04.html

·        http://self-issued.info/docs/draft-jones-jso= n-web-token-04.txt

·        http://self-issued.info/docs/draft-jones-jso= n-web-token-04.xml

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

·        http://self-issued.info/docs/draft-jones-json-w= eb-token.txt (will point to new versions as they are posted)=

·        http://self-issued.info/docs/draft-jones-json-w= eb-token.xml (will point to new versions as they are posted)=

·        http://svn.openid.net/repos/specifications/j= son_web_token/1.0/ (Subversion repository, with html, txt, and html ver= sions available)

 

        &nbs= p;            &= nbsp;           &nbs= p;             =              --= Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943252B2BB6TK5EX14MBXC203r_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D3C3A6919 for ; Tue, 29 Mar 2011 00:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.124 X-Spam-Level: X-Spam-Status: No, score=-102.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds4D3DDrgBjj for ; Tue, 29 Mar 2011 00:57:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A825C3A68E1 for ; Tue, 29 Mar 2011 00:57:20 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (dhcp-12cb.meeting.ietf.org [130.129.18.203]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DAEC340022 for ; Tue, 29 Mar 2011 02:00:37 -0600 (MDT) Message-ID: <4D919140.7050205@stpeter.im> Date: Tue, 29 Mar 2011 09:58:56 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: woes@ietf.org References: <255B9BB34FB7D647A506DC292726F6E112815DCB0D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112815DCB0D@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060707060607070808040303" Subject: Re: [woes] Comments on draft-rescorla-jsms-00 X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:57:21 -0000 This is a cryptographically signed message in MIME format. --------------ms060707060607070808040303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/29/11 8:25 AM, Manger, James H wrote: > 2. URI in cert >=20 > Requiring a certificate to include a > subjectAltName.uniformResourceIdentifier (san.uri) seems to exclude a > lots of potential certs, without a great reason. >=20 > Do XMPP ids typically get put in certs as URIs > (san.uri=3Dxmpp:romeo@example.net), or as a dedicated name-form > (san.other.xmpp=3Dromeo@example.net)? There is an OID called "id-on-XmppAddr", but you're right that it could be a URI. > An email address can be expressed as a URI (eg > mailto:romeo@example.net), but a corresponding certificate is likely to= > include a san.rfc822 value, not a san.uri. Correct. It would be nice to standardize on one subjectAlternativeName extension, but I don't think that's very likely given wide deployment of things like rfc822name. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060707060607070808040303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy OTA3NTg1NlowIwYJKoZIhvcNAQkEMRYEFNWZY0+7ZlxMSxLlsz+YlCvk10b4MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCA9gq88n2gOZMR0igMOLWtFDn7+PEY55gERJ2BdxCxiRP3NbHn5ZlmbiOx B/b1ukLUfPUAFdrDdeJBF7l0xz7DIs0ixf8SC/fbmlMlLF8MB5ryRdsW3EdUCyDiAkpbD5Tx fiVLa4I5aVbVZGdHjy8lY8NOJxMictxWwEU6bLA6UFsjyKNQT5HaMwFtOc8SIwqCSQQB05lI W7sJEey21IBdRLpX6TKFJ3iRiK/bBIPqNOHWmepftR3b26bMLeRmdkAmNq9bEgf7sTQiWjS5 JfyCU6lEV+4AOKYVA8WNLzjFyPsmiIA+P3u5dMP894Wo4mKFFX3MneTnhWDJEgfq2/UKAAAA AAAA --------------ms060707060607070808040303-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8393A6802 for ; Mon, 28 Mar 2011 23:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sev1Lw3TNQau for ; Mon, 28 Mar 2011 23:24:09 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 246513A67EF for ; Mon, 28 Mar 2011 23:24:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,260,1299416400"; d="scan'208,217";a="32710917" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 29 Mar 2011 17:25:46 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6299"; a="22643766" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 29 Mar 2011 17:25:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 29 Mar 2011 17:25:46 +1100 From: "Manger, James H" To: "woes@ietf.org" Date: Tue, 29 Mar 2011 17:25:45 +1100 Thread-Topic: Comments on draft-rescorla-jsms-00 Thread-Index: Acvt2iLdwyxVuRUFRcmyzdinq/0UKQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E112815DCB0D@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E112815DCB0DWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [woes] Comments on draft-rescorla-jsms-00 X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:24:15 -0000 --_000_255B9BB34FB7D647A506DC292726F6E112815DCB0DWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The JavaScript Message Security Format (JSMS) is quite a nice piece of work= . 1. Signer as URI Uhm... 2. URI in cert Requiring a certificate to include a subjectAltName.uniformResourceIdentifi= er (san.uri) seems to exclude a lots of potential certs, without a great re= ason. Do XMPP ids typically get put in certs as URIs (san.uri=3Dxmpp:romeo@exampl= e.net), or as a dedicated name-form (san.other.xmpp=3Dromeo@example.net)? An email address can be expressed as a URI (eg mailto:romeo@example.net), b= ut a corresponding certificate is likely to include a san.rfc822 value, not= a san.uri. 3. Signer =3D cert.san.uri Why does the cert have to match the Signer field? In TLS-with-client-auth or S/MIME you have the cert, but no separate Signer= id (though I guess S/MIME has a separate email address). 4. Examples The example certificate [4.4.2.1] doesn't verify the example signature [4.4= ]. It would be a nice test vector if it did verify. 5. Base64 I would prefer to use base64url without terminators, instead of original ba= se64. The "outer" layer of JSMS is a JSON dictionary, but I expect it will often = be encoded for transmission and that encoding should be consistent with the= encoding of content within JSMS. Avoiding + / and =3D characters removes an unnecessary layer of escaping wh= en values are used in URIs, form POSTs, HTTP headers etc. 6. MAC Supporting a symmetric MAC would cover another useful set of use cases. 7. WOES It would be helpful to explicitly mention in future drafts where discussion= should occur, ie on the WOES list. Typos: Section 4.4.1. "Signature Computation", point 2. WRONG "feed the literal octets of the signature into the digest" RIGHT "feed the literal octets of X into the digest" -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E112815DCB0DWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The JavaScript Message Security Format (JSMS) is qui= te a nice piece of work.

 

1. Signer as URI

Uhm…

 

2. URI in cert

Requiring a certificate to include a subjectAltName.= uniformResourceIdentifier (san.uri) seems to exclude a lots of potential ce= rts, without a great reason.

Do XMPP ids typically get put in certs as URIs (san.= uri=3Dxmpp:romeo@example.net), or as a dedicated name-form (san.other.xmpp= =3Dromeo@example.net)?

An email address can be expressed as a URI (eg mailto:romeo@example.net), but a corresponding certificate is likely to= include a san.rfc822 value, not a san.uri.

 

3. Signer =3D cert.san.uri

Why does the cert have to match the Signer field?

In TLS-with-client-auth or S/MIME you have the cert,= but no separate Signer id (though I guess S/MIME has a separate email addr= ess).

 

4. Examples

The example certificate [4.4.2.1] doesn’t veri= fy the example signature [4.4]. It would be a nice test vector if it did ve= rify.

 

5. Base64

I would prefer to use base64url without terminators,= instead of original base64.

The “outer” layer of JSMS is a JSON dict= ionary, but I expect it will often be encoded for transmission and that enc= oding should be consistent with the encoding of content within JSMS.

Avoiding + / and =3D characters removes an unnec= essary layer of escaping when values are used in URIs, form POSTs, HTTP hea= ders etc.

 

6. MAC

Supporting a symmetric MAC would cover another usefu= l set of use cases.

 

7. WOES

It would be helpful to explicitly mention in future = drafts where discussion should occur, ie on the WOES list.

 

 

Typos:

Section 4.4.1. “Signature Computation”, = point 2.

WRONG “feed the literal octets of the signatur= e into the digest”

RIGHT    “feed the literal octe= ts of X into the digest”

 

--

James Manger

 

--_000_255B9BB34FB7D647A506DC292726F6E112815DCB0DWSMSG3153Vsrv_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA3B3A6A7F; Mon, 28 Mar 2011 15:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEq6Xrld-mQp; Mon, 28 Mar 2011 15:03:19 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7668C3A6A6B; Mon, 28 Mar 2011 15:03:18 -0700 (PDT) Received: by gyf3 with SMTP id 3so1544965gyf.31 for ; Mon, 28 Mar 2011 15:04:55 -0700 (PDT) Received: by 10.150.67.5 with SMTP id p5mr92326yba.428.1301349895693; Mon, 28 Mar 2011 15:04:55 -0700 (PDT) Received: from [192.168.1.4] ([190.22.48.168]) by mx.google.com with ESMTPS id f5sm1554028ybh.13.2011.03.28.15.04.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 15:04:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-104-920142689; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252AAB0D@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Mon, 28 Mar 2011 18:04:49 -0400 Message-Id: <54DB0AB3-EB0E-4BDD-94E1-A220148FBF29@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943252A9198@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252AA329@TK5EX14MBXC207.redmond.corp.microsoft.com> <1C42267D-9BE0-45E7-8007-A05B6937082D@ve7jtb.com> <4E1F6AAD24975D4BA5B1680429673943252AAB0D@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 29 Mar 2011 00:25:32 -0700 Cc: "openid-specs-ab@lists.openid.net" , "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [woes] [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:03:20 -0000 --Apple-Mail-104-920142689 Content-Type: multipart/alternative; boundary=Apple-Mail-103-920142598 --Apple-Mail-103-920142598 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I just spotted that further down. I am OK with no pad character as long as that isn't going to mess up = string parsing in some situations. =20 The empty string is arguably more compact. John B. On 2011-03-28, at 6:02 PM, Mike Jones wrote: > Correct =96 good catch. I=92ll update the draft. The intent was for = there to be no pad character in that case. > =20 > = -- Mike > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Monday, March 28, 2011 3:00 PM > To: Mike Jones > Cc: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net; = openid-specs@lists.openid.net > Subject: Re: [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and = JSON Web Signature (JWS) now in separate specs > =20 > Mike in JWT 6.7 if the alg is none. > =20 > Otherwise, if the "alg" value > is ""none"", the JWT Claim Segment is the empty string. > I may be missing something. If the Alg is none then the Claim segment = is still the claim segment. It is the Crypto segment that would just = be padding to maintain the format. > =20 > In 8 10 the decoding has it correct. > =20 > So in the event the signature alg is none do we make the cripto = segment a pad character? > =20 > So normally it would be=20 > xxxxxxx.xxxxxxxx.xxxxx > =20 > Dropping the cripto segment looks like > xxxxxxx.xxxxxxxx. > =20 > Or with a pad char to be ignored=20 > xxxxxxx.xxxxxxxxx.0 > =20 > Or something like that. > =20 > John B. > On 2011-03-28, at 5:28 AM, Mike Jones wrote: >=20 >=20 > These are now published as IETF drafts. The IETF .txt version links = are: > = http://www.ietf.org/id/draft-jones-json-web-token-03.txt > = http://www.ietf.org/id/draft-jones-json-web-signature-01.txt > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Friday, March 25, 2011 10:26 PM > To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net > Cc: openid-specs@lists.openid.net > Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) = now in separate specs > =20 > As promised, I have split the contents of the JWT spec = draft-jones-json-web-token-01 into two simpler specs: > draft-jones-json-web-token-02 > draft-jones-json-web-signature-00 > These should have introduced no semantic changes from the previous = spec. > =20 > I then applied the feedback that I received since JWT -01 and created = revised versions of the split specs: > draft-jones-json-web-token-03 > draft-jones-json-web-signature-01 > The only breaking change introduced was that x5t (X.509 Certificate = Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather = than a SHA-256 has, as SHA-1 is the prevailing existing practice for = certificate thumbprint calculations. See the Document History sections = for details on each change made. > =20 > .txt and .xml versions are also available. I plan to publish these as = IETF drafts once the submission window re-opens on Monday. Feedback = welcome! > =20 > -- Mike > =20 > P.S. Yes, work on the companion encryption spec is now under way=85 > =20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab > =20 --Apple-Mail-103-920142598 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I just spotted that further = down.

I am OK with no pad character as long as that = isn't going to mess up string parsing in some situations. =  

The empty string is arguably more = compact.

John B.
On 2011-03-28, at = 6:02 PM, Mike Jones wrote:

Correct = =96 good catch.  I=92ll update the draft.  The intent was for = there to be no pad character in that case.
 
From: John Bradley = [mailto:ve7jtb@ve7jtb.com] 
Sent: Monday, March 28, 2011 3:00 = PM
To: Mike = Jones
Cc: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net;  
Re: [Openid-specs-ab] = [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in = separate specs
Otherwise, if the "alg" value
I may be missing = something.  If the Alg is none then the Claim segment is still the = claim segment.   It is the Crypto segment that would just be = padding to maintain the format.
In 8 10 the decoding has it = correct.
So in the event the signature alg = is none do we make the cripto segment a pad = character?
So normally it would = be 
Dropping the cripto segment looks = like
Or with a pad char to be = ignored 
Or something like = that.
 
John = B.
On 2011-03-28, at 5:28 = AM, Mike Jones wrote:
These = are now published as IETF drafts.  The IETF .txt version links = are:
 
, "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [woes] [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:01:02 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252AAB0DTK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correct - good catch. I'll update the draft. The intent was for there to = be no pad character in that case. = -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Monday, March 28, 2011 3:00 PM To: Mike Jones Cc: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net; openid= -specs@lists.openid.net Subject: Re: [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and JSON Web= Signature (JWS) now in separate specs Mike in JWT 6.7 if the alg is none. Otherwise, if the "alg" value is ""none"", the JWT Claim Segment is the empty string. I may be missing something. If the Alg is none then the Claim segment is s= till the claim segment. It is the Crypto segment that would just be paddi= ng to maintain the format. In 8 10 the decoding has it correct. So in the event the signature alg is none do we make the cripto segment a p= ad character? So normally it would be xxxxxxx.xxxxxxxx.xxxxx Dropping the cripto segment looks like xxxxxxx.xxxxxxxx. Or with a pad char to be ignored xxxxxxx.xxxxxxxxx.0 Or something like that. John B. On 2011-03-28, at 5:28 AM, Mike Jones wrote: These are now published as IETF drafts. The IETF .txt version links are: http://www.ietf.org/id/draft-jones-json-web-token-03.txt http://www.ietf.org/id/draft-jones-json-web-signature-01.txt -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, March 25, 2011 10:26 PM To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net Cc: openid-specs@lists.openid.net Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now i= n separate specs As promised, I have split the contents of the JWT spec draft-jones-json-web= -token-01 = into two simpler specs: draft-jones-json-web-token-02 draft-jones-json-web-signature-00 These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revis= ed versions of the split specs: draft-jones-json-web-token-03 draft-jones-json-web-signature-01 The only breaking change introduced was that x5t (X.509 Certificate Thumbpr= int) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-= 256 has, as SHA-1 is the prevailing existing practice for certificate thumb= print calculations. See the Document History sections for details on each = change made. .txt and .xml versions are also available. I plan to publish these as IETF= drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... _______________________________________________ Openid-specs-ab mailing list Openid-specs-ab@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs-ab --_000_4E1F6AAD24975D4BA5B1680429673943252AAB0DTK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correct – good catc= h.  I’ll update the draft.  The intent was for there to be = no pad character in that case.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        -- Mike

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Monday, March 28, 2011 3:00 PM
To: Mike Jones
Cc: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net;= openid-specs@lists.openid.net
Subject: Re: [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and J= SON Web Signature (JWS) now in separate specs

 

Mike in JWT 6.7 if the alg is none.

 

Otherwise, if the=
 "alg" value
       is ""none"", =
the JWT Claim Segment is the empty string.

I may be missing something.  If the Alg is none then the C= laim segment is still the claim segment.   It is the Crypto segment th= at would just be padding to maintain the format.

 

In 8 10 the decoding has it correct.

 

So in the event the signature alg is none do we make the cripto= segment a pad character?

 

So normally it would be 

xxxxxxx.xxxxxxxx.xxxxx

 

Dropping the cripto segment looks like

xxxxxxx.xxxxxxxx.

 

Or with a pad char to be ignored 

xxxxxxx.xxxxxxxxx.0

 

Or something like that.

 

John B.

On 2011-03-28, at 5:28 AM, Mike Jones wrote:



These are now published a= s IETF drafts.  The IETF .txt version links are:

 

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike=

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones=
Sent: Friday, Marc= h 25, 2011 10:26 PM
To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net
Cc: openid-specs@lists.openid.net
Subject: [OAUTH-WG= ] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs

 

As promised, I have split the contents = of the JWT spec draft-= jones-json-web-token-01 into two simpler specs:

      &nb= sp;         draft-jones-json-web-token-02

      &nb= sp;         draft-jones-json-web-signature-00<= /o:p>

These should have introduced no semanti= c changes from the previous spec.

 

I then applied the feedback that I rece= ived since JWT -01 and created revised versions of the split specs:

      &nb= sp;         draft-jones-json-web-token-03

      &nb= sp;         draft-jones-json-web-signature-01<= /o:p>

The only breaking change introduced was= that x5t (X.509 Certificate Thumbprint) is now a SHA-1 hash of the DER-enc= oded certificate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practice for certificate thumbprint calculations.&= nbsp; See the Document History sections for details on each change made.

 

.txt and .xml versions are also availab= le.  I plan to publish these as IETF drafts once the submission window= re-opens on Monday.  Feedback welcome!

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

P.S.  Yes, work on the companion e= ncryption spec is now under way…

 

_____________________________________= __________
Openid-specs-ab mailing list
Openid-specs-ab@lists.o= penid.net
http:/= /lists.openid.net/mailman/listinfo/openid-specs-ab

 

--_000_4E1F6AAD24975D4BA5B1680429673943252AAB0DTK5EX14MBXC207r_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896903A67B1; Mon, 28 Mar 2011 14:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2bBGO2aqm9s; Mon, 28 Mar 2011 14:58:03 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 363CC3A695B; Mon, 28 Mar 2011 14:58:02 -0700 (PDT) Received: by yxk30 with SMTP id 30so1557800yxk.31 for ; Mon, 28 Mar 2011 14:59:40 -0700 (PDT) Received: by 10.101.59.16 with SMTP id m16mr245200ank.150.1301349580563; Mon, 28 Mar 2011 14:59:40 -0700 (PDT) Received: from [192.168.1.4] ([190.22.48.168]) by mx.google.com with ESMTPS id r8sm1678028anf.29.2011.03.28.14.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 14:59:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-102-919825435; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252AA329@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Mon, 28 Mar 2011 17:59:32 -0400 Message-Id: <1C42267D-9BE0-45E7-8007-A05B6937082D@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943252A9198@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252AA329@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 29 Mar 2011 00:25:32 -0700 Cc: "openid-specs-ab@lists.openid.net" , "woes@ietf.org" , "oauth@ietf.org" , "openid-specs@lists.openid.net" Subject: Re: [woes] [Openid-specs-ab] [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:58:05 -0000 --Apple-Mail-102-919825435 Content-Type: multipart/alternative; boundary=Apple-Mail-101-919825316 --Apple-Mail-101-919825316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Mike in JWT 6.7 if the alg is none. Otherwise, if the "alg" value is ""none"", the JWT Claim Segment is the empty string. I may be missing something. If the Alg is none then the Claim segment = is still the claim segment. It is the Crypto segment that would just = be padding to maintain the format. In 8 10 the decoding has it correct. So in the event the signature alg is none do we make the cripto segment = a pad character? So normally it would be=20 xxxxxxx.xxxxxxxx.xxxxx Dropping the cripto segment looks like xxxxxxx.xxxxxxxx. Or with a pad char to be ignored=20 xxxxxxx.xxxxxxxxx.0 Or something like that. John B. On 2011-03-28, at 5:28 AM, Mike Jones wrote: > These are now published as IETF drafts. The IETF .txt version links = are: > = http://www.ietf.org/id/draft-jones-json-web-token-03.txt > = http://www.ietf.org/id/draft-jones-json-web-signature-01.txt > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Friday, March 25, 2011 10:26 PM > To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net > Cc: openid-specs@lists.openid.net > Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) = now in separate specs > =20 > As promised, I have split the contents of the JWT spec = draft-jones-json-web-token-01 into two simpler specs: > draft-jones-json-web-token-02 > draft-jones-json-web-signature-00 > These should have introduced no semantic changes from the previous = spec. > =20 > I then applied the feedback that I received since JWT -01 and created = revised versions of the split specs: > draft-jones-json-web-token-03 > draft-jones-json-web-signature-01 > The only breaking change introduced was that x5t (X.509 Certificate = Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather = than a SHA-256 has, as SHA-1 is the prevailing existing practice for = certificate thumbprint calculations. See the Document History sections = for details on each change made. > =20 > .txt and .xml versions are also available. I plan to publish these as = IETF drafts once the submission window re-opens on Monday. Feedback = welcome! > =20 > -- Mike > =20 > P.S. Yes, work on the companion encryption spec is now under way=85 > =20 > _______________________________________________ > Openid-specs-ab mailing list > Openid-specs-ab@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab --Apple-Mail-101-919825316 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Mike in JWT 6.7 if the alg is = none.

Otherwise, if the "alg" value
       is ""none"", the JWT Claim Segment is the empty string.
I may be missing something.  If the Alg is none then the = Claim segment is still the claim segment.   It is the Crypto = segment that would just be padding to maintain the = format.

In 8 10 the decoding has it = correct.

So in the event the signature alg is = none do we make the cripto segment a pad = character?

So normally it would = be 
xxxxxxx.xxxxxxxx.xxxxx

Droppin= g the cripto segment looks = like
xxxxxxx.xxxxxxxx.

Or with a pad = char to be = ignored 
xxxxxxx.xxxxxxxxx.0

Or = something like that.

John = B.
On 2011-03-28, at 5:28 AM, Mike Jones = wrote:

These are now published as IETF drafts.  The IETF .txt = version links are:
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Mike = Jones
Sent: Friday, March 25, 2011 = 10:26 PM
To: oauth@ietf.org; woes@ietf.org;   [OAUTH-WG] JSON Web Token = (JWT) and JSON Web Signature (JWS) now in separate = specs
Openid-specs-ab@lists.openid.net
, "woes@ietf.org" , "openid-specs-ab@lists.openid.net" Thread-Topic: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs Thread-Index: AcvrdjytBVRrDTgeReCPOh8gPYdaIgBs7JIw Date: Mon, 28 Mar 2011 09:28:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252AA329@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252A9198@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252A9198@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252AA329TK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "openid-specs@lists.openid.net" Subject: Re: [woes] [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:27:17 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252AA329TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are now published as IETF drafts. The IETF .txt version links are: http://www.ietf.org/id/draft-jones-json-web-token-03.txt http://www.ietf.org/id/draft-jones-json-web-signature-01.txt -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, March 25, 2011 10:26 PM To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net Cc: openid-specs@lists.openid.net Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now i= n separate specs As promised, I have split the contents of the JWT spec draft-jones-json-web= -token-01 = into two simpler specs: draft-jones-json-web-token-02 draft-jones-json-web-signature-00 These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revis= ed versions of the split specs: draft-jones-json-web-token-03 draft-jones-json-web-signature-01 The only breaking change introduced was that x5t (X.509 Certificate Thumbpr= int) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-= 256 has, as SHA-1 is the prevailing existing practice for certificate thumb= print calculations. See the Document History sections for details on each = change made. .txt and .xml versions are also available. I plan to publish these as IETF= drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... --_000_4E1F6AAD24975D4BA5B1680429673943252AA329TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These are now publishe= d as IETF drafts.  The IETF .txt version links are:<= /p>

   &nbs= p;           http://www.ietf.org/id/draft-jones-json-web-token-03.txt

   &nbs= p;           http://www.ietf.org/id/draft-jones-json-web-signature-01.txt=

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, March 25, 2011 10:26 PM
To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net<= br> Cc: openid-specs@lists.openid.net
Subject: [OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS= ) now in separate specs

 

As promised, I have split the contents of the JWT sp= ec draft-jones-json-web-token-01 into two simpler specs:

        &nbs= p;       draft-jones-json-web-token-02

        &nbs= p;       draft-jones-json-web-signature-00

These should have introduced no semantic changes fro= m the previous spec.

 

I then applied the feedback that I received since JW= T -01 and created revised versions of the split specs:

        &nbs= p;       draft-jones-json-web-token-03

        &nbs= p;       draft-jones-json-web-signature-01

The only breaking change introduced was that x5t (X.= 509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certific= ate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practic= e for certificate thumbprint calculations.  See the Document History sections for details on each change made.

 

.txt and .xml versions are also available.  I p= lan to publish these as IETF drafts once the submission window re-opens on = Monday.  Feedback welcome!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

P.S.  Yes, work on the companion encryption spe= c is now under way…

 

--_000_4E1F6AAD24975D4BA5B1680429673943252AA329TK5EX14MBXC207r_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2FC3A683C for ; Mon, 28 Mar 2011 01:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMEZm5ioVLnz for ; Mon, 28 Mar 2011 01:20:05 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by core3.amsl.com (Postfix) with SMTP id 53C953A68EE for ; Mon, 28 Mar 2011 01:20:05 -0700 (PDT) Received: from [98.139.91.70] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 08:21:38 -0000 Received: from [98.139.91.5] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 08:21:38 -0000 Received: from [127.0.0.1] by omp1005.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 08:21:38 -0000 X-Yahoo-Newman-Id: 147169.71206.bm@omp1005.mail.sp2.yahoo.com Received: (qmail 43295 invoked from network); 28 Mar 2011 08:21:38 -0000 Received: from dhcp-1598.meeting.ietf.org (turners@198.180.150.234 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 28 Mar 2011 01:21:37 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 0ea__o4VM1l3lgd5bmiLP2Pkr1fsY6bLPGl7Ii9zjZVa_Yt EdteMKhA6NY2wRzV3PkJLX5PlZtXArubeW.Iv9Z4GUnyrMS8bBhOMRQ_6Z0W _3Zn7A504SrTE698KkRAfG88IpmHkbJJSq9fMKwGArvDTbEQIyEvHskRqVTH IAew_JKQsvoig4ZH3L1M5mNxMtVpeOiYvfN8JaSkcvbOMQ9ziYarajiLrS7m 26XfaANA6a0AuUf_5oGX7OsL7iF1dV6gn5QCCFinapXqaFCHAqfEeWTqErOK JGkY33BeHJpek8YjUNKtpJ98sCQ6wNs.6MhPR.9MZAolRuqfHFAwrZJJy9Ws .bT3PdnODHqJH9zjzIj3gtI_ZtCycvSVEEm2l2B92qD8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D90450F.30804@ieca.com> Date: Mon, 28 Mar 2011 10:21:35 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: woes@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [woes] Why the trail of WOES X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:20:06 -0000 Personally, I think that the format question is not the one we should be focusing on. There's some smart people involved in this space and I have no doubt that in the end it'll be fine.*,** Granted it seems that there are two camps I've talked to: one camp is like duh of course we need this and the other camp is like why on earth do we need this at all. So.... (being selfish here) What I need to know is why this is needed. I don't want to rat hole on all use cases, but I'd like to have some of them articulated on the list so everybody can get on the same page. Assuming the plan would be to go for WG eventually, then answering this will also help an AD explain to other IESG members who will no doubt ask why one of the other 3-4 solutions out there (for some value of out there) can't be used. I've heard a couple of things like ASN.1 sucks, XML Dsig/Enc sucks, there are no "good" tools for either, and there's no access to the "goodies" in browsers. Why is doing this going to take over the Web application space? Is the next generation of coders just going to dump it and say JSON' is better (i.e., this isn't a NIH kind of thing). (I might have this all wrong so please correct me if I'm wrong) My understanding is that in a client-server scenario (understand that this work will likely also support server-to-server comms), the client/sever will exchange these messages, the client is provided the JavaScript to process the message (including algorithms) and that this exchange is probably done over a TLS protected link. Is the javaScript signed or are we going to rely on the TLS protected link? If it's signed, then does it verify back to a trust anchor in the browser? I guess I'm pulling at this thread because there's all this wonderfully FIPS evaluated crypto code in Mozilla and IE (and presumably Chrome/Opera at some point) being used for TLS and now we're going to instead use some other code. Has anybody actually asked whether an API could be developed to access the crypto, ASN.1, cert handling, etc? Looking forward to figuring this all out. spt * I'd note that personally, I'd prefer ** I'd note that as RFC 5406 points out: Security protocols are very hard to design; rolling out a new one will require extensive theoretical and practical work to confirm its security properties and will incur both delay and uncertainty. For me this translates to profiling something that we already understand as opposed to doing something completely new. Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD24D3A68E5 for ; Sun, 27 Mar 2011 02:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aya7uEMltOWP for ; Sun, 27 Mar 2011 02:39:27 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id 1491F3A6906 for ; Sun, 27 Mar 2011 02:39:26 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p2R9ewHe097612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Mar 2011 02:40:58 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p2R9ewmv097609; Sun, 27 Mar 2011 02:40:58 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Sun, 27 Mar 2011 02:40:58 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252A9B03@TK5EX14MBXC207.redmond.corp.microsoft.com> Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943252A9B03@TK5EX14MBXC207.redmond.corp.microsoft.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============0051734881==" Cc: "woes@ietf.org" Subject: Re: [woes] FW: JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 09:39:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============0051734881== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII On Sun, 27 Mar 2011, Mike Jones wrote: > Resending to WOES to make sure that it goes through, as I didn't receive > my copy from the list. Thanks, and I got this the first time > From: Mike Jones > Sent: Friday, March 25, 2011 10:26 PM > To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net > Cc: openid-specs@lists.openid.net > Subject: JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs > > As promised, I have split the contents of the JWT spec draft-jones-json-web-token-01 into two simpler specs: > draft-jones-json-web-token-02 > draft-jones-json-web-signature-00 > These should have introduced no semantic changes from the previous spec. diff here: http://tools.ietf.org/rfcdiff?url1=http://self-issued.info/docs/draft-jones-json-web-token-02.txt&url2=http://self-issued.info/docs/draft-jones-json-web-token-03.txt > I then applied the feedback that I received since JWT -01 and created revised versions of the split specs: > draft-jones-json-web-token-03 > draft-jones-json-web-signature-01 > The only breaking change introduced was that x5t (X.509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practice for certificate thumbprint calculations. See the Document History sections for details on each change made. diff here: http://tools.ietf.org/rfcdiff?url1=http://self-issued.info/docs/draft-jones-json-web-signature-00.txt&url2=http://self-issued.info/docs/draft-jones-json-web-signature-01.txt > .txt and .xml versions are also available. I plan to publish these as IETF drafts once the submission window re-opens on Monday. Feedback welcome! > > -- Mike > > P.S. Yes, work on the companion encryption spec is now under way... > > --===============0051734881== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ woes mailing list woes@ietf.org https://www.ietf.org/mailman/listinfo/woes --===============0051734881==-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C17D3A68F5 for ; Sun, 27 Mar 2011 02:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6tTWuJOVpQl for ; Sun, 27 Mar 2011 02:08:31 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 634863A68F4 for ; Sun, 27 Mar 2011 02:08:31 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 27 Mar 2011 02:10:07 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Sun, 27 Mar 2011 02:10:07 -0700 From: Mike Jones To: "woes@ietf.org" Thread-Topic: JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs Thread-Index: AcvrdjytBVRrDTgeReCPOh8gPYdaIgA6G3wA Date: Sun, 27 Mar 2011 09:10:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252A9B03@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252A9B03TK5EX14MBXC207r_" MIME-Version: 1.0 Subject: [woes] FW: JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 09:08:40 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252A9B03TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending to WOES to make sure that it goes through, as I didn't receive my= copy from the list. From: Mike Jones Sent: Friday, March 25, 2011 10:26 PM To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net Cc: openid-specs@lists.openid.net Subject: JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate = specs As promised, I have split the contents of the JWT spec draft-jones-json-web= -token-01 = into two simpler specs: draft-jones-json-web-token-02 draft-jones-json-web-signature-00 These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revis= ed versions of the split specs: draft-jones-json-web-token-03 draft-jones-json-web-signature-01 The only breaking change introduced was that x5t (X.509 Certificate Thumbpr= int) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-= 256 has, as SHA-1 is the prevailing existing practice for certificate thumb= print calculations. See the Document History sections for details on each = change made. .txt and .xml versions are also available. I plan to publish these as IETF= drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... --_000_4E1F6AAD24975D4BA5B1680429673943252A9B03TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending to WOES to m= ake sure that it goes through, as I didn’t receive my copy from the l= ist.

 

From: Mike Jon= es
Sent: Friday, March 25, 2011 10:26 PM
To: oauth@ietf.org; woes@ietf.org; openid-specs-ab@lists.openid.net<= br> Cc: openid-specs@lists.openid.net
Subject: JSON Web Token (JWT) and JSON Web Signature (JWS) now in se= parate specs

 

As promised, I have split the contents of the JWT sp= ec draft-jones-json-web-token-01 into two simpler specs:

        &nbs= p;       draft-jones-json-web-token-02

        &nbs= p;       draft-jones-json-web-signature-00

These should have introduced no semantic changes fro= m the previous spec.

 

I then applied the feedback that I received since JW= T -01 and created revised versions of the split specs:

        &nbs= p;       draft-jones-json-web-token-03

        &nbs= p;       draft-jones-json-web-signature-01

The only breaking change introduced was that x5t (X.= 509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certific= ate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practic= e for certificate thumbprint calculations.  See the Document History sections for details on each change made.

 

.txt and .xml versions are also available.  I p= lan to publish these as IETF drafts once the submission window re-opens on = Monday.  Feedback welcome!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

P.S.  Yes, work on the companion encryption spe= c is now under way…

 

--_000_4E1F6AAD24975D4BA5B1680429673943252A9B03TK5EX14MBXC207r_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D77928C0D0 for ; Sat, 26 Mar 2011 17:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.451 X-Spam-Level: X-Spam-Status: No, score=-104.451 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvJKMP6H4iSw for ; Sat, 26 Mar 2011 17:22:43 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id 38A2228C0E4 for ; Sat, 26 Mar 2011 17:22:41 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 17:24:18 -0700 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Sun, 27 Mar 2011 00:24:17 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sat, 26 Mar 2011 18:24:28 -0600 From: Joe Hildebrand To: Bryan Geraghty , Mike Jones Message-ID: Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: AcvsFVVQlTlRZgJ7ckyuILwajiXTqw== In-Reply-To: IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Mar 2011 00:24:18.0064 (UTC) FILETIME=[4F646900:01CBEC15] Cc: "woes@ietf.org" , Paul Hoffman , Dick Hardt Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 00:22:45 -0000 Keep in mind, there's always sign(sign(plaintext)), which means that signing can still be a simple operation. We're still at the point of seeing if there are enough people interested in having the discussion, so it's way to early to assume that there have been any decisions made about what is a common use case or not. On 3/26/11 12:10 PM, "Bryan Geraghty" wrote: > I'm one of these "advocates". The use case has been defined and > acknowledged. Having to duplicate a document merely because the engineers of > the signing protocol decided that multiple signatures isn't a common enough > use case seems ridiculous. > > The best security concepts are simple. So requiring the implementor to come > up with an external strategy for verifying that the signed documents are > identical, and managing the relationships between copies of the document > signed *by n* signers sounds like an implementation nightmare. If it were > me, I'd be hard-pressed to chose this system. > > Doesn't a single copy of a document with multiple signatures attached seem > like a much simpler and more elegant solution? > > Bryan > > On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones > wrote: > >> That is a potential representation for the concept. I believe that its >> advocates would argue that repeating the payload in each message is >> redundant and not space-efficient, but I'm not personally taking a position >> on this use case either way. >> >> -- Mike >> >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Tuesday, March 22, 2011 2:29 PM >> To: Mike Jones >> Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org >> Subject: Re: [woes] Preparation for the WOES meeting >> >> >> On 2011-03-22, at 2:19 PM, Mike Jones wrote: >> >>> The use case for this comes from the OpenID Contract Exchange >> specification, where they want multiple parties to have signed the same >> plaintext in no particular order. This occurs in real life, for instance, >> when both parties have to sign the same business or real estate contract. >> >> Why not solve this infrequent use case with multiple identical messages >> signed separately? >> _______________________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes >> > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5A228C0DD for ; Sat, 26 Mar 2011 14:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcx5X5EfhOwv for ; Sat, 26 Mar 2011 14:21:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9C32528C0E1 for ; Sat, 26 Mar 2011 14:21:40 -0700 (PDT) Received: by pwi5 with SMTP id 5so452831pwi.31 for ; Sat, 26 Mar 2011 14:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=UEx9gFQJ5ind+wp0UdaLkbmta16E0ExFxqgkaDcXjBc=; b=mqDbLmSo3nQgClybAFYTeZqdTmfPcDkHl/OK1SxshCtGrm4LkSTbGn4vRTWrl9g+Ug F7lzwanz56dvWpZkS67sYGLYXWCJhZYeyXycJTVGFl+KK6qgICtZb+K14j6bCDJJYBbu os+bZa2FwhFvFxPwXS5PaeowmYUmanFmBNTTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=P+umtVwyeomhi1or3LwY2mNLFsbf3SmwYyzeBG8gNrsEVZfG+Ycs40/XrVzM2mwIGU IYtT8RIdDpJvhWgOXIyf2fP/sEYIefLB3LyBzn+mYTjxPvCB0SpssCR6FiTJLQafqzpA XQ7FrWkGfjPu9c8/Bqft2PSndLqfyaCCcAJSE= Received: by 10.142.232.13 with SMTP id e13mr1972449wfh.128.1301174596823; Sat, 26 Mar 2011 14:23:16 -0700 (PDT) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id y2sm3354628wfd.20.2011.03.26.14.23.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 14:23:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-744845032 From: Dick Hardt In-Reply-To: Date: Sat, 26 Mar 2011 14:23:12 -0700 Message-Id: <702B3499-8D1B-4DC7-8D10-71A8FE461933@gmail.com> References: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252A34C5@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252A3572@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Bryan Geraghty X-Mailer: Apple Mail (2.1084) Cc: "woes@ietf.org" , Paul Hoffman , Dick Hardt Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:21:42 -0000 --Apple-Mail-2-744845032 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd be interested to see your simple and elegant approach to having = multiple signatures that provides nominal additional complexity for the = single signature use case. -- Dick On 2011-03-26, at 11:10 AM, Bryan Geraghty wrote: > I'm one of these "advocates". The use case has been defined and = acknowledged. Having to duplicate a document merely because the = engineers of the signing protocol decided that multiple signatures isn't = a common enough use case seems ridiculous. >=20 > The best security concepts are simple. So requiring the implementor to = come up with an external strategy for verifying that the signed = documents are identical, and managing the relationships between copies = of the document signed by n signers sounds like an implementation = nightmare. If it were me, I'd be hard-pressed to chose this system. >=20 > Doesn't a single copy of a document with multiple signatures attached = seem like a much simpler and more elegant solution? >=20 > Bryan >=20 > On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones = wrote: > That is a potential representation for the concept. I believe that = its advocates would argue that repeating the payload in each message is = redundant and not space-efficient, but I'm not personally taking a = position on this use case either way. >=20 > -- Mike >=20 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Tuesday, March 22, 2011 2:29 PM > To: Mike Jones > Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org > Subject: Re: [woes] Preparation for the WOES meeting >=20 >=20 > On 2011-03-22, at 2:19 PM, Mike Jones wrote: >=20 > > The use case for this comes from the OpenID Contract Exchange = specification, where they want multiple parties to have signed the same = plaintext in no particular order. This occurs in real life, for = instance, when both parties have to sign the same business or real = estate contract. >=20 > Why not solve this infrequent use case with multiple identical = messages signed separately? > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes >=20 --Apple-Mail-2-744845032 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I'd be interested to see your simple and elegant approach to having multiple signatures that provides nominal additional complexity for the single signature use case.

-- Dick

On 2011-03-26, at 11:10 AM, Bryan Geraghty wrote:

I'm one of these "advocates". The use case has been defined and acknowledged. Having to duplicate a document merely because the engineers of the signing protocol decided that multiple signatures isn't a common enough use case seems ridiculous.

The best security concepts are simple. So requiring the implementor to come up with an external strategy for verifying that the signed documents are identical, and managing the relationships between copies of the document signed by n signers sounds like an implementation nightmare. If it were me, I'd be hard-pressed to chose this system.

Doesn't a single copy of a document with multiple signatures attached seem like a much simpler and more elegant solution?

Bryan

On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
That is a potential representation for the concept.  I believe that its advocates would argue that repeating the payload in each message is redundant and not space-efficient, but I'm not personally taking a position on this use case either way.

                               -- Mike

-----Original Message-----
From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, March 22, 2011 2:29 PM
To: Mike Jones
Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org
Subject: Re: [woes] Preparation for the WOES meeting


On 2011-03-22, at 2:19 PM, Mike Jones wrote:

> The use case for this comes from the OpenID Contract Exchange specification, where they want multiple parties to have signed the same plaintext in no particular order.  This occurs in real life, for instance, when both parties have to sign the same business or real estate contract.

Why not solve this infrequent use case with multiple identical messages signed separately?
_______________________________________________
woes mailing list
woes@ietf.org
https://www.ietf.org/mailman/listinfo/woes


--Apple-Mail-2-744845032-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA233A67F0 for ; Sat, 26 Mar 2011 11:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmEIdxvh-jTF for ; Sat, 26 Mar 2011 11:08:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1CEF83A67B2 for ; Sat, 26 Mar 2011 11:08:37 -0700 (PDT) Received: by iye19 with SMTP id 19so1851986iye.31 for ; Sat, 26 Mar 2011 11:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6aD644Lrx0LTLptCzcdsGH8+AyeW+kTf7xXiLXBTskg=; b=uX4nRWrTmovrvtSqq2Au9Pi78ZrBta+hoERJbOOjDuWoPPysIRr3tD7xnPw5UsE7LL f9dk6A9BWzmGPI/NmMbHrsvfokgluUBVnsQlgcRDS0dgjkWnrGXJvUU/t27Cq2itQ3Qv UuWBAlk3jbg4/gNLIMqCKwA3HSrWU3fBxOFh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Mht6JC4Vkbmoee8s7JOhgLZ4f8tX239fax3wNh3ADlZvM1lhfdgH3jpdhRSw4ivLHQ BSzEA8pdinVlbKr8kOCAMGsiYZTm1Z9z+WcYrQMW/phc33u/PsPIaRdzMqgIrNN30HOG ukxUh1/PpV98Pc8ZreLyQjcZgPNQd5V8nPqkY= MIME-Version: 1.0 Received: by 10.42.131.72 with SMTP id y8mr3289947ics.283.1301163013093; Sat, 26 Mar 2011 11:10:13 -0700 (PDT) Sender: archwisp@gmail.com Received: by 10.42.139.198 with HTTP; Sat, 26 Mar 2011 11:10:13 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252A3572@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252A34C5@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252A3572@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Sat, 26 Mar 2011 13:10:13 -0500 X-Google-Sender-Auth: GCYmoe0VZjTiStyawrXQ2oyLd4o Message-ID: From: Bryan Geraghty To: Mike Jones Content-Type: multipart/alternative; boundary=90e6ba21246f30b87f049f669f38 Cc: "woes@ietf.org" , Paul Hoffman , Dick Hardt Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 18:10:45 -0000 --90e6ba21246f30b87f049f669f38 Content-Type: text/plain; charset=ISO-8859-1 I'm one of these "advocates". The use case has been defined and acknowledged. Having to duplicate a document merely because the engineers of the signing protocol decided that multiple signatures isn't a common enough use case seems ridiculous. The best security concepts are simple. So requiring the implementor to come up with an external strategy for verifying that the signed documents are identical, and managing the relationships between copies of the document signed *by n* signers sounds like an implementation nightmare. If it were me, I'd be hard-pressed to chose this system. Doesn't a single copy of a document with multiple signatures attached seem like a much simpler and more elegant solution? Bryan On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones wrote: > That is a potential representation for the concept. I believe that its > advocates would argue that repeating the payload in each message is > redundant and not space-efficient, but I'm not personally taking a position > on this use case either way. > > -- Mike > > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Tuesday, March 22, 2011 2:29 PM > To: Mike Jones > Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org > Subject: Re: [woes] Preparation for the WOES meeting > > > On 2011-03-22, at 2:19 PM, Mike Jones wrote: > > > The use case for this comes from the OpenID Contract Exchange > specification, where they want multiple parties to have signed the same > plaintext in no particular order. This occurs in real life, for instance, > when both parties have to sign the same business or real estate contract. > > Why not solve this infrequent use case with multiple identical messages > signed separately? > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes > --90e6ba21246f30b87f049f669f38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm one of these "advocates". The use case has been defined a= nd=20 acknowledged. Having to duplicate a document merely because the=20 engineers of the signing protocol decided that multiple signatures isn'= t a common enough use case seems ridiculous.

The best security conce= pts are simple. So requiring the implementor to come up with an external st= rategy for verifying that the signed documents are identical, and managing = the relationships between copies of the document signed by n signers= sounds like an implementation nightmare. If it were me, I'd be hard-pr= essed to chose this system.

Doesn't a single copy of a document with multiple signatures attach= ed seem like a much simpler and more elegant solution?

Bryan

=
On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones <Michael.Jo= nes@microsoft.com> wrote:
That is a potential representation for the = concept. =A0I believe that its advocates would argue that repeating the pay= load in each message is redundant and not space-efficient, but I'm not = personally taking a position on this use case either way.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike

-----Original Message-----
From: Dick Hardt [mailto:dick.hardt= @gmail.com]
Sent: Tuesday, March 22, 2011 2:29 PM
To: Mike Jones
Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org
Subject: Re: [woes] Preparation for the WOES meeting


On 2011-03-22, at 2:19 PM, Mike Jon= es wrote:

> The use case for this comes from the OpenID Contract Exchange specific= ation, where they want multiple parties to have signed the same plaintext i= n no particular order. =A0This occurs in real life, for instance, when both= parties have to sign the same business or real estate contract.

Why not solve this infrequent use case with multiple identical messages sig= ned separately?
_______________________________________________
woes mailing list
woes@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/woes

--90e6ba21246f30b87f049f669f38-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344083A6805; Fri, 25 Mar 2011 22:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HvIeJ3rv-No; Fri, 25 Mar 2011 22:24:08 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9BBDD3A68D2; Fri, 25 Mar 2011 22:24:07 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Mar 2011 22:25:37 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Fri, 25 Mar 2011 22:25:37 -0700 From: Mike Jones To: "oauth@ietf.org" , "woes@ietf.org" , "openid-specs-ab@lists.openid.net" Thread-Topic: JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs Thread-Index: AcvrdjytBVRrDTgeReCPOh8gPYdaIg== Date: Sat, 26 Mar 2011 05:25:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252A9198@TK5EX14MBXC207.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943252A9198TK5EX14MBXC207r_" MIME-Version: 1.0 Cc: "openid-specs@lists.openid.net" Subject: [woes] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 05:24:13 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943252A9198TK5EX14MBXC207r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As promised, I have split the contents of the JWT spec draft-jones-json-web= -token-01 = into two simpler specs: draft-jones-json-web-token-02 draft-jones-json-web-signature-00 These should have introduced no semantic changes from the previous spec. I then applied the feedback that I received since JWT -01 and created revis= ed versions of the split specs: draft-jones-json-web-token-03 draft-jones-json-web-signature-01 The only breaking change introduced was that x5t (X.509 Certificate Thumbpr= int) is now a SHA-1 hash of the DER-encoded certificate, rather than a SHA-= 256 has, as SHA-1 is the prevailing existing practice for certificate thumb= print calculations. See the Document History sections for details on each = change made. .txt and .xml versions are also available. I plan to publish these as IETF= drafts once the submission window re-opens on Monday. Feedback welcome! -- Mike P.S. Yes, work on the companion encryption spec is now under way... --_000_4E1F6AAD24975D4BA5B1680429673943252A9198TK5EX14MBXC207r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As promised, I have split the contents of the JWT sp= ec draft-jones-json-web-token-01 into two simpler specs:

        &nbs= p;       draft-jones-json-web-token-02

        &nbs= p;       draft-jones-json-web-signature-00

These should have introduced no semantic changes fro= m the previous spec.

 

I then applied the feedback that I received since JW= T -01 and created revised versions of the split specs:

        &nbs= p;       draft-jones-json-web-token-03

        &nbs= p;       draft-jones-json-web-signature-01

The only breaking change introduced was that x5t (X.= 509 Certificate Thumbprint) is now a SHA-1 hash of the DER-encoded certific= ate, rather than a SHA-256 has, as SHA-1 is the prevailing existing practic= e for certificate thumbprint calculations.  See the Document History sections for details on each change made.

 

.txt and .xml versions are also available.  I p= lan to publish these as IETF drafts once the submission window re-opens on = Monday.  Feedback welcome!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

P.S.  Yes, work on the companion encryption spe= c is now under way…

 

--_000_4E1F6AAD24975D4BA5B1680429673943252A9198TK5EX14MBXC207r_-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EAA28C176 for ; Tue, 22 Mar 2011 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 887A5z9jL9EY for ; Tue, 22 Mar 2011 14:30:32 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 42AA928C169 for ; Tue, 22 Mar 2011 14:30:32 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Mar 2011 14:32:05 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 14:32:05 -0700 From: Mike Jones To: Dick Hardt Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: AQHL5dIseUugizkYSUq/Ogp/sZyFSJQ1lhOAgAQarJCAAC+7o4AAANDQgAB4s4D//4sYEA== Date: Tue, 22 Mar 2011 21:32:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252A3572@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252A34C5@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "woes@ietf.org" , Paul Hoffman Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:30:33 -0000 That is a potential representation for the concept. I believe that its adv= ocates would argue that repeating the payload in each message is redundant = and not space-efficient, but I'm not personally taking a position on this u= se case either way. -- Mike -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Tuesday, March 22, 2011 2:29 PM To: Mike Jones Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org Subject: Re: [woes] Preparation for the WOES meeting On 2011-03-22, at 2:19 PM, Mike Jones wrote: > The use case for this comes from the OpenID Contract Exchange specificati= on, where they want multiple parties to have signed the same plaintext in n= o particular order. This occurs in real life, for instance, when both part= ies have to sign the same business or real estate contract. Why not solve this infrequent use case with multiple identical messages sig= ned separately? Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AB528C15D for ; Tue, 22 Mar 2011 14:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coGNtdYDkmAj for ; Tue, 22 Mar 2011 14:27:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1C3C128C0D9 for ; Tue, 22 Mar 2011 14:27:24 -0700 (PDT) Received: by iwl42 with SMTP id 42so9277510iwl.31 for ; Tue, 22 Mar 2011 14:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=cGFyTx5SNkl1QoQnjVV3axzKszK8LJafgoiIWB5KAGc=; b=S/TPBBxjht0Al4+nTAkHJr547l5o6sFOv85CusUaizbM+UjYANkfrZ4N1W5HKo0dEj uZ+RSo280JS0mSJgIrGt3Ih7Q7qx5YfxMNXemEQgugvHAAGdZsbBekvqqOfRWkfYrBns tykyyHM2kNtwR3+9NdvT/wkOZvmqaMZ6JYfEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eHZUaNxoqwlh6R7Kcrviz+2TPf02LxYHYGkplmx0ZQijJC5gJfc3NdzPbBZX5dh8wd 2CXN3kiStPQSYlgr8eGr5IIyZ/u76NuBTrDfO6sB+4Fsu2NdO5WBLMU+HT9dSipnCvOa lsRGrpdvXHV+0AzvtkO3OYw6IjDVpR4ezXrT8= Received: by 10.42.65.73 with SMTP id k9mr75606ici.427.1300829337581; Tue, 22 Mar 2011 14:28:57 -0700 (PDT) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id gy41sm3475721ibb.22.2011.03.22.14.28.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2011 14:28:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252A34C5@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Tue, 22 Mar 2011 14:28:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943252A34C5@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) Cc: "woes@ietf.org" , Paul Hoffman Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:27:25 -0000 On 2011-03-22, at 2:19 PM, Mike Jones wrote: > The use case for this comes from the OpenID Contract Exchange = specification, where they want multiple parties to have signed the same = plaintext in no particular order. This occurs in real life, for = instance, when both parties have to sign the same business or real = estate contract. Why not solve this infrequent use case with multiple identical messages = signed separately?= Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584A53A68B1 for ; Tue, 22 Mar 2011 14:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EuGUKObkQ5c for ; Tue, 22 Mar 2011 14:17:45 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5834E3A67CC for ; Tue, 22 Mar 2011 14:17:44 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Mar 2011 14:19:17 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 14:19:17 -0700 From: Mike Jones To: Joe Hildebrand , Paul Hoffman , "woes@ietf.org" Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: AQHL5dIseUugizkYSUq/Ogp/sZyFSJQ1lhOAgAQarJCAAC+7o4AAANDQ Date: Tue, 22 Mar 2011 21:19:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252A34C5@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:17:46 -0000 The use case for this comes from the OpenID Contract Exchange specification= , where they want multiple parties to have signed the same plaintext in no = particular order. This occurs in real life, for instance, when both partie= s have to sign the same business or real estate contract. This is being move to an extension, rather than being in the core spec, bec= ause we don't believe it's a predominant use case. I also understand the value of sign(sign(plaintext)), which is also achieva= ble. -- Mike -----Original Message----- From: Joe Hildebrand [mailto:joe.hildebrand@webex.com]=20 Sent: Tuesday, March 22, 2011 2:14 PM To: Mike Jones; Paul Hoffman; woes@ietf.org Subject: Re: [woes] Preparation for the WOES meeting On 3/22/11 12:23 PM, "Mike Jones" wrote: > Anticipated extensions: > - multiple signers on the same plaintext Would you be ok with multiple signers being sign(sign(plaintext)), rather t= han plaintext, signature, signature? That allows us to stick with a single= signer in each operation, and not have to worry as much about canonicaliza= tion. -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF9728C0D9 for ; Tue, 22 Mar 2011 14:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.445 X-Spam-Level: X-Spam-Status: No, score=-104.445 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V14ukuw060F for ; Tue, 22 Mar 2011 14:12:25 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 53C853A688F for ; Tue, 22 Mar 2011 14:12:25 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 14:13:58 -0700 Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.11]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Mar 2011 21:13:57 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 22 Mar 2011 15:13:59 -0600 From: Joe Hildebrand To: Mike Jones , Paul Hoffman , "woes@ietf.org" Message-ID: Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: AQHL5dIseUugizkYSUq/Ogp/sZyFSJQ1lhOAgAQarJCAAC+7ow== In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2011 21:13:58.0836 (UTC) FILETIME=[0F597F40:01CBE8D6] Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:12:26 -0000 On 3/22/11 12:23 PM, "Mike Jones" wrote: > Anticipated extensions: > - multiple signers on the same plaintext Would you be ok with multiple signers being sign(sign(plaintext)), rather than plaintext, signature, signature? That allows us to stick with a single signer in each operation, and not have to worry as much about canonicalization. -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6D23A688F for ; Tue, 22 Mar 2011 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-4LGBpEnsH0 for ; Tue, 22 Mar 2011 14:08:27 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5F7093A67CC for ; Tue, 22 Mar 2011 14:08:27 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Mar 2011 14:10:00 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 14:10:00 -0700 From: Mike Jones To: Dick Hardt Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: AQHL5dIseUugizkYSUq/Ogp/sZyFSJQ1lhOAgAQarJCAAKNUgP//i0JQ Date: Tue, 22 Mar 2011 21:09:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252A34A5@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <000FD2BC-F027-4DBB-9420-7516EC2F8BA4@vpnc.org> <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> <0A32B0EF-86D9-4A2B-967D-0D8C9CAD8503@gmail.com> In-Reply-To: <0A32B0EF-86D9-4A2B-967D-0D8C9CAD8503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "woes@ietf.org" , Paul Hoffman Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:08:29 -0000 Agreed -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Tuesday, March 22, 2011 2:08 PM To: Mike Jones Cc: Joe Hildebrand; Paul Hoffman; woes@ietf.org Subject: Re: [woes] Preparation for the WOES meeting I'd add URL safe encoding as a goal. Alleviates mismatched encoding / decod= ing bugs. On 2011-03-22, at 11:23 AM, Mike Jones wrote: > Thanks, Paul and Joe, for helping frame the discussions. I thought I'd a= dd the perspective of those working on the JSON Web Token (JWT) format in t= he way that Joe did for the JSMS format: >=20 > Goals: > - minimized wire size - enabling use in space-constrained=20 > environments, such as mobile browser query strings > - implementable easily from scratch in multiple different languages > - both signing and encryption specified > - algorithm agility, but a small set of standard algorithms defined=20 > for each agile point to start with > - no canonicalization of platonic ideals into octet streams > - easy discoverability by new implementers (view source approach) > - very limited extensibility >=20 > Anticipated extensions: > - multiple signers on the same plaintext >=20 > Non-Goals: > - optimistic signing > - backward compatibility with existing standards > - compatibility between instantiations of the format (e.g. XML, JSON,=20 > BSON) > - minimized memory > - minimized CPU > - multiple recipients for a single encrypted payload > - self-describing type structure for data structures >=20 > The primary difference is that using a compact representation is a key go= al of the JWT spec. >=20 > Looking forward to talking with many of you next week! >=20 > -- Mike >=20 > -----Original Message----- > From: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On Behalf=20 > Of Joe Hildebrand > Sent: Saturday, March 19, 2011 1:43 PM > To: Paul Hoffman; woes@ietf.org > Subject: Re: [woes] Preparation for the WOES meeting >=20 > Paul, this is a very helpful starting point - thanks. >=20 > From my perspective (ekr can chime in on his own) there is nothing about = the JSMS format that we need to "win". There are some things I'd like to t= o see in the eventual format(s): >=20 > - implementable easily from scratch in multiple different languages > - both signing and encryption specified > - algorithm agility, but *one* (or as close to one as possible)=20 > algorithm defined for each agile point to start with > - no canonicalization of platonic ideals into octet streams > - multiple recipients for a single encrypted payload > - easy discoverability by new implementers (view source approach) > - very limited extensibility >=20 > Things that I don't see as priorities: > - multiple signers on the same plaintext (one signature can wrap=20 > another) > - optimistic signing > - backward compatibility with existing standards > - compatibility between instantiations of the format (e.g. XML, JSON,=20 > BSON) > - mimimized wire size > - minimized memory > - minimized CPU >=20 > On 3/18/11 7:08 PM, "Paul Hoffman" wrote: >=20 >> Greetings. We would like to set the tone for the WOES=20 >> meeting-that-is-not-a-BoF that will happen on Monday, March 28, in=20 >> Prague. The meeting will be from 2000 to 2130 in the Karlin I room. >> Sean Turner has asked us (Lucy and Paul) to be the co-chairs for this=20 >> meeting, and in turn we have assured him that neither of us want to=20 >> chair an eventual WG, if it is chartered. >>=20 >> We believe that a reasonable schedule might be: >>=20 >> 10 min introduction by Lucy and Paul >> 20 min discussion / presentation on draft-rescorla-jsms >> 20 min discussion / presentation on draft-jones-json-web-token >> 40 min discussion on what the rest of the community wants >> and how it wants to proceed >>=20 >> For this meeting, we would like to talk almost exclusively about the=20 >> format, not the many different places where such formatted objects=20 >> might be used. This is based on an assumption that as long as the=20 >> eventual format has just enough building blocks plus some well-scoped=20 >> and well-designed extensibility, the discussion of where it can be=20 >> used is actually better had in the respective WGs, not here. >>=20 >> We note that the two proposed formats should probably be called "the=20 >> first two proposed formats": it is possible that there are others.=20 >> The group needs to decide over time whether the desired outcome is=20 >> one format or more than one format; history in the IETF indicates that t= his will not be an easy decision. >> Another discussion topic is what kinds of documents are needed other=20 >> than format documents: is a requirements document (and possibly other=20 >> non-format >> documents) needed? >>=20 >> We note that this is not a formal BoF, and we will not be the=20 >> eventual leaders, so we are keeping this "agenda" informal as well.=20 >> Please let us know what you think of this. >>=20 >> -- Lucy Lynch and Paul Hoffman >>=20 >> _______________________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes >=20 > -- > Joe Hildebrand >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE2328C0D7 for ; Tue, 22 Mar 2011 14:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXk+CZ5RMxdU for ; Tue, 22 Mar 2011 14:06:15 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BB0683A67CC for ; Tue, 22 Mar 2011 14:06:15 -0700 (PDT) Received: by pwi5 with SMTP id 5so1382523pwi.31 for ; Tue, 22 Mar 2011 14:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Wlbf83gKvl+Eejcc9lKdOq6fcr6PTw0OVOzzK+ch3to=; b=t7kdKlxSwo5dmiViumHM8ygm6F5O9LAId6CsYxzj1Qk1deb6O6uviF20f1yMH2a0zX QCwumYtlGTYBsGE/rweZbXf9sithknrfOAsIQ7F4gZ0o5QrVOq393rhRGz2iNQTeecqT a2CnK+tQ+eFM5XLwbkCn4T2eP2fKSYy/62xfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CUUxfZwbJ85pgPyI5hx75lskTlaLgOtLEz11FvHzsMSGKHyHzuhShbijbReWQT171Y EFwA20ur7OYT+EsQAVXElQJmu2LOuE8M91OxEf+84ikWS2aZn9UCR+eXEhkkeyGUvyUY /r+O65tiqIbqMVtMtpjR0LhXs7N+FCRgAz1SM= Received: by 10.142.171.16 with SMTP id t16mr4184569wfe.402.1300828069282; Tue, 22 Mar 2011 14:07:49 -0700 (PDT) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id 25sm9118192wfb.10.2011.03.22.14.07.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2011 14:07:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> Date: Tue, 22 Mar 2011 14:07:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A32B0EF-86D9-4A2B-967D-0D8C9CAD8503@gmail.com> References: <000FD2BC-F027-4DBB-9420-7516EC2F8BA4@vpnc.org> <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) Cc: "woes@ietf.org" , Paul Hoffman Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 21:06:16 -0000 I'd add URL safe encoding as a goal. Alleviates mismatched encoding / = decoding bugs. On 2011-03-22, at 11:23 AM, Mike Jones wrote: > Thanks, Paul and Joe, for helping frame the discussions. I thought = I'd add the perspective of those working on the JSON Web Token (JWT) = format in the way that Joe did for the JSMS format: >=20 > Goals: > - minimized wire size - enabling use in space-constrained = environments, such as mobile browser query strings > - implementable easily from scratch in multiple different languages > - both signing and encryption specified > - algorithm agility, but a small set of standard algorithms defined = for each agile point to start with > - no canonicalization of platonic ideals into octet streams > - easy discoverability by new implementers (view source approach) > - very limited extensibility >=20 > Anticipated extensions: > - multiple signers on the same plaintext >=20 > Non-Goals: > - optimistic signing > - backward compatibility with existing standards > - compatibility between instantiations of the format (e.g. XML, JSON, = BSON) > - minimized memory > - minimized CPU > - multiple recipients for a single encrypted payload > - self-describing type structure for data structures >=20 > The primary difference is that using a compact representation is a key = goal of the JWT spec. >=20 > Looking forward to talking with many of you next week! >=20 > -- Mike >=20 > -----Original Message----- > From: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On Behalf = Of Joe Hildebrand > Sent: Saturday, March 19, 2011 1:43 PM > To: Paul Hoffman; woes@ietf.org > Subject: Re: [woes] Preparation for the WOES meeting >=20 > Paul, this is a very helpful starting point - thanks. >=20 > =46rom my perspective (ekr can chime in on his own) there is nothing = about the JSMS format that we need to "win". There are some things I'd = like to to see in the eventual format(s): >=20 > - implementable easily from scratch in multiple different languages > - both signing and encryption specified > - algorithm agility, but *one* (or as close to one as possible) = algorithm defined for each agile point to start with > - no canonicalization of platonic ideals into octet streams > - multiple recipients for a single encrypted payload > - easy discoverability by new implementers (view source approach) > - very limited extensibility >=20 > Things that I don't see as priorities: > - multiple signers on the same plaintext (one signature can wrap = another) > - optimistic signing > - backward compatibility with existing standards > - compatibility between instantiations of the format (e.g. XML, JSON, = BSON) > - mimimized wire size > - minimized memory > - minimized CPU >=20 > On 3/18/11 7:08 PM, "Paul Hoffman" wrote: >=20 >> Greetings. We would like to set the tone for the WOES=20 >> meeting-that-is-not-a-BoF that will happen on Monday, March 28, in=20 >> Prague. The meeting will be from 2000 to 2130 in the Karlin I room.=20= >> Sean Turner has asked us (Lucy and Paul) to be the co-chairs for this=20= >> meeting, and in turn we have assured him that neither of us want to=20= >> chair an eventual WG, if it is chartered. >>=20 >> We believe that a reasonable schedule might be: >>=20 >> 10 min introduction by Lucy and Paul >> 20 min discussion / presentation on draft-rescorla-jsms >> 20 min discussion / presentation on draft-jones-json-web-token >> 40 min discussion on what the rest of the community wants >> and how it wants to proceed >>=20 >> For this meeting, we would like to talk almost exclusively about the=20= >> format, not the many different places where such formatted objects=20 >> might be used. This is based on an assumption that as long as the=20 >> eventual format has just enough building blocks plus some well-scoped=20= >> and well-designed extensibility, the discussion of where it can be=20 >> used is actually better had in the respective WGs, not here. >>=20 >> We note that the two proposed formats should probably be called "the=20= >> first two proposed formats": it is possible that there are others. = The=20 >> group needs to decide over time whether the desired outcome is one=20 >> format or more than one format; history in the IETF indicates that = this will not be an easy decision. >> Another discussion topic is what kinds of documents are needed other=20= >> than format documents: is a requirements document (and possibly other=20= >> non-format >> documents) needed? >>=20 >> We note that this is not a formal BoF, and we will not be the = eventual=20 >> leaders, so we are keeping this "agenda" informal as well. Please let=20= >> us know what you think of this. >>=20 >> -- Lucy Lynch and Paul Hoffman >>=20 >> _______________________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes >=20 > -- > Joe Hildebrand >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910153A68B3 for ; Tue, 22 Mar 2011 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK17YrWcJM8P for ; Tue, 22 Mar 2011 11:22:22 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1F9623A68BC for ; Tue, 22 Mar 2011 11:22:21 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Mar 2011 11:23:52 -0700 Received: from TK5EX14MBXC207.redmond.corp.microsoft.com ([169.254.7.102]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 11:23:52 -0700 From: Mike Jones To: Joe Hildebrand , Paul Hoffman , "woes@ietf.org" Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: AQHL5dIseUugizkYSUq/Ogp/sZyFSJQ1lhOAgAQarJA= Date: Tue, 22 Mar 2011 18:23:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943252A2FDE@TK5EX14MBXC207.redmond.corp.microsoft.com> References: <000FD2BC-F027-4DBB-9420-7516EC2F8BA4@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 18:22:23 -0000 Thanks, Paul and Joe, for helping frame the discussions. I thought I'd add= the perspective of those working on the JSON Web Token (JWT) format in the= way that Joe did for the JSMS format: Goals: - minimized wire size - enabling use in space-constrained environments, suc= h as mobile browser query strings - implementable easily from scratch in multiple different languages - both signing and encryption specified - algorithm agility, but a small set of standard algorithms defined for eac= h agile point to start with - no canonicalization of platonic ideals into octet streams - easy discoverability by new implementers (view source approach) - very limited extensibility Anticipated extensions: - multiple signers on the same plaintext Non-Goals: - optimistic signing - backward compatibility with existing standards - compatibility between instantiations of the format (e.g. XML, JSON, BSON) - minimized memory - minimized CPU - multiple recipients for a single encrypted payload - self-describing type structure for data structures The primary difference is that using a compact representation is a key goal= of the JWT spec. Looking forward to talking with many of you next week! -- Mike -----Original Message----- From: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On Behalf Of Joe= Hildebrand Sent: Saturday, March 19, 2011 1:43 PM To: Paul Hoffman; woes@ietf.org Subject: Re: [woes] Preparation for the WOES meeting Paul, this is a very helpful starting point - thanks. >From my perspective (ekr can chime in on his own) there is nothing about th= e JSMS format that we need to "win". There are some things I'd like to to = see in the eventual format(s): - implementable easily from scratch in multiple different languages - both signing and encryption specified - algorithm agility, but *one* (or as close to one as possible) algorithm d= efined for each agile point to start with - no canonicalization of platonic ideals into octet streams - multiple recipients for a single encrypted payload - easy discoverability by new implementers (view source approach) - very limited extensibility Things that I don't see as priorities: - multiple signers on the same plaintext (one signature can wrap another) - optimistic signing - backward compatibility with existing standards - compatibility between instantiations of the format (e.g. XML, JSON, BSON) - mimimized wire size - minimized memory - minimized CPU On 3/18/11 7:08 PM, "Paul Hoffman" wrote: > Greetings. We would like to set the tone for the WOES=20 > meeting-that-is-not-a-BoF that will happen on Monday, March 28, in=20 > Prague. The meeting will be from 2000 to 2130 in the Karlin I room.=20 > Sean Turner has asked us (Lucy and Paul) to be the co-chairs for this=20 > meeting, and in turn we have assured him that neither of us want to=20 > chair an eventual WG, if it is chartered. >=20 > We believe that a reasonable schedule might be: >=20 > 10 min introduction by Lucy and Paul > 20 min discussion / presentation on draft-rescorla-jsms > 20 min discussion / presentation on draft-jones-json-web-token > 40 min discussion on what the rest of the community wants > and how it wants to proceed >=20 > For this meeting, we would like to talk almost exclusively about the=20 > format, not the many different places where such formatted objects=20 > might be used. This is based on an assumption that as long as the=20 > eventual format has just enough building blocks plus some well-scoped=20 > and well-designed extensibility, the discussion of where it can be=20 > used is actually better had in the respective WGs, not here. >=20 > We note that the two proposed formats should probably be called "the=20 > first two proposed formats": it is possible that there are others. The=20 > group needs to decide over time whether the desired outcome is one=20 > format or more than one format; history in the IETF indicates that this w= ill not be an easy decision. > Another discussion topic is what kinds of documents are needed other=20 > than format documents: is a requirements document (and possibly other=20 > non-format > documents) needed? >=20 > We note that this is not a formal BoF, and we will not be the eventual=20 > leaders, so we are keeping this "agenda" informal as well. Please let=20 > us know what you think of this. >=20 > -- Lucy Lynch and Paul Hoffman >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand _______________________________________________ woes mailing list woes@ietf.org https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94F13A691D for ; Sat, 19 Mar 2011 13:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.438 X-Spam-Level: X-Spam-Status: No, score=-104.438 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpLhvVAXRGBF for ; Sat, 19 Mar 2011 13:41:13 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id 033533A6A04 for ; Sat, 19 Mar 2011 13:41:09 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 19 Mar 2011 13:42:40 -0700 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.11]) with Microsoft Exchange Server HTTP-DAV ; Sat, 19 Mar 2011 20:42:40 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sat, 19 Mar 2011 14:42:39 -0600 From: Joe Hildebrand To: Paul Hoffman , "woes@ietf.org" Message-ID: Thread-Topic: [woes] Preparation for the WOES meeting Thread-Index: Acvmdi+kqCSs6aRWLUihXV70Vxp52w== In-Reply-To: <000FD2BC-F027-4DBB-9420-7516EC2F8BA4@vpnc.org> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Mar 2011 20:42:40.0341 (UTC) FILETIME=[3070A850:01CBE676] Subject: Re: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 20:41:13 -0000 Paul, this is a very helpful starting point - thanks. >From my perspective (ekr can chime in on his own) there is nothing about the JSMS format that we need to "win". There are some things I'd like to to see in the eventual format(s): - implementable easily from scratch in multiple different languages - both signing and encryption specified - algorithm agility, but *one* (or as close to one as possible) algorithm defined for each agile point to start with - no canonicalization of platonic ideals into octet streams - multiple recipients for a single encrypted payload - easy discoverability by new implementers (view source approach) - very limited extensibility Things that I don't see as priorities: - multiple signers on the same plaintext (one signature can wrap another) - optimistic signing - backward compatibility with existing standards - compatibility between instantiations of the format (e.g. XML, JSON, BSON) - mimimized wire size - minimized memory - minimized CPU On 3/18/11 7:08 PM, "Paul Hoffman" wrote: > Greetings. We would like to set the tone for the WOES > meeting-that-is-not-a-BoF that will happen on Monday, March 28, in Prague. The > meeting will be from 2000 to 2130 in the Karlin I room. Sean Turner has asked > us (Lucy and Paul) to be the co-chairs for this meeting, and in turn we have > assured him that neither of us want to chair an eventual WG, if it is > chartered. > > We believe that a reasonable schedule might be: > > 10 min introduction by Lucy and Paul > 20 min discussion / presentation on draft-rescorla-jsms > 20 min discussion / presentation on draft-jones-json-web-token > 40 min discussion on what the rest of the community wants > and how it wants to proceed > > For this meeting, we would like to talk almost exclusively about the format, > not the many different places where such formatted objects might be used. This > is based on an assumption that as long as the eventual format has just enough > building blocks plus some well-scoped and well-designed extensibility, the > discussion of where it can be used is actually better had in the respective > WGs, not here. > > We note that the two proposed formats should probably be called "the first two > proposed formats": it is possible that there are others. The group needs to > decide over time whether the desired outcome is one format or more than one > format; history in the IETF indicates that this will not be an easy decision. > Another discussion topic is what kinds of documents are needed other than > format documents: is a requirements document (and possibly other non-format > documents) needed? > > We note that this is not a formal BoF, and we will not be the eventual > leaders, so we are keeping this "agenda" informal as well. Please let us know > what you think of this. > > -- Lucy Lynch and Paul Hoffman > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396353A69B9 for ; Fri, 18 Mar 2011 18:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCRtp8jqbYK1 for ; Fri, 18 Mar 2011 18:06:58 -0700 (PDT) Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id F065B3A6A19 for ; Fri, 18 Mar 2011 18:06:57 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2J18JJX074706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Mar 2011 18:08:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 18 Mar 2011 18:08:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <000FD2BC-F027-4DBB-9420-7516EC2F8BA4@vpnc.org> References: To: woes@ietf.org X-Mailer: Apple Mail (2.1082) Subject: [woes] Preparation for the WOES meeting X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 01:06:59 -0000 Greetings. We would like to set the tone for the WOES = meeting-that-is-not-a-BoF that will happen on Monday, March 28, in = Prague. The meeting will be from 2000 to 2130 in the Karlin I room. Sean = Turner has asked us (Lucy and Paul) to be the co-chairs for this = meeting, and in turn we have assured him that neither of us want to = chair an eventual WG, if it is chartered. We believe that a reasonable schedule might be: 10 min introduction by Lucy and Paul 20 min discussion / presentation on draft-rescorla-jsms 20 min discussion / presentation on draft-jones-json-web-token 40 min discussion on what the rest of the community wants and how it wants to proceed For this meeting, we would like to talk almost exclusively about the = format, not the many different places where such formatted objects might = be used. This is based on an assumption that as long as the eventual = format has just enough building blocks plus some well-scoped and = well-designed extensibility, the discussion of where it can be used is = actually better had in the respective WGs, not here. We note that the two proposed formats should probably be called "the = first two proposed formats": it is possible that there are others. The = group needs to decide over time whether the desired outcome is one = format or more than one format; history in the IETF indicates that this = will not be an easy decision. Another discussion topic is what kinds of = documents are needed other than format documents: is a requirements = document (and possibly other non-format documents) needed? We note that this is not a formal BoF, and we will not be the eventual = leaders, so we are keeping this "agenda" informal as well. Please let us = know what you think of this. -- Lucy Lynch and Paul Hoffman Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55B63A6B61 for ; Thu, 10 Mar 2011 12:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.421 X-Spam-Level: X-Spam-Status: No, score=-104.421 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5PIuUQW2a46 for ; Thu, 10 Mar 2011 12:16:38 -0800 (PST) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id C85163A6923 for ; Thu, 10 Mar 2011 12:16:37 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 12:17:56 -0800 Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Mar 2011 20:17:55 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 10 Mar 2011 13:17:58 -0700 From: Joe Hildebrand To: Dick Hardt , Peter Saint-Andre Message-ID: Thread-Topic: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt Thread-Index: AcvfYD8tEed1DLA4WkmzAejFQ37UZQ== In-Reply-To: <81D3C959-0C75-4033-9645-F6425FA55DF3@gmail.com> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Mar 2011 20:17:56.0035 (UTC) FILETIME=[3E01C930:01CBDF60] Cc: "woes@ietf.org" Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:16:38 -0000 The WOES list is probably the best place to discuss. By the way, you're not subscribed, which is why it took a while for me to find the admin password and get your messages through. On 3/9/11 4:56 PM, "Dick Hardt" wrote: > Hi Peter > > Is there a different WG working on this draft, or is this draft part of this > WG? > > It is unclear to me where comments would be posted. > > -- Dick > > On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: > >> FYI. >> >> -------- Original Message -------- >> Subject: I-D Action:draft-rescorla-jsms-00.txt >> Date: Mon, 07 Mar 2011 15:30:03 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : JavaScript Message Security Format >> Author(s) : E. Rescorla, J. Hildebrand >> Filename : draft-rescorla-jsms-00.txt >> Pages : 24 >> Date : 2011-03-07 >> >> Many applications require the ability to send cryptographically >> secured messages. While the IETF has defined a number of formats for >> such messages (e.g. CMS) those formats use encodings which are not >> congenial for Web applications. This document describes a new >> cryptographic message format which is based on JavaScript Object >> Notation (JSON) and thus is easy for Web applications to generate and >> parse. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> > Part.txt>_______________________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2E93A6814 for ; Thu, 10 Mar 2011 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.41 X-Spam-Level: X-Spam-Status: No, score=-104.41 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvJWi65rfJQm for ; Thu, 10 Mar 2011 12:15:53 -0800 (PST) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id A20F73A6962 for ; Thu, 10 Mar 2011 12:15:52 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 12:17:10 -0800 Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Mar 2011 20:17:10 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 10 Mar 2011 13:17:13 -0700 From: Joe Hildebrand To: Dick Hardt , Eric Rescorla Message-ID: Thread-Topic: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt Thread-Index: AcvfYCRbYCN2UM9Iz0Cyc4dfiLH79g== In-Reply-To: <2B1CCAC9-9315-4246-BDCA-79D5E942E42E@gmail.com> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Mar 2011 20:17:10.0973 (UTC) FILETIME=[2325DED0:01CBDF60] Cc: "woes@ietf.org" Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:15:54 -0000 We cut a couple of corners to make the -00 deadline, sorry. More to come. On 3/9/11 5:17 PM, "Dick Hardt" wrote: > Eric > > An example or commentary explaining going from a JSON message to signing would > be useful. > > I read over the document twice and I cannot figure out how it all fits > together. > > -- Dick > > On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: > >> FYI. >> >> -------- Original Message -------- >> Subject: I-D Action:draft-rescorla-jsms-00.txt >> Date: Mon, 07 Mar 2011 15:30:03 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : JavaScript Message Security Format >> Author(s) : E. Rescorla, J. Hildebrand >> Filename : draft-rescorla-jsms-00.txt >> Pages : 24 >> Date : 2011-03-07 >> >> Many applications require the ability to send cryptographically >> secured messages. While the IETF has defined a number of formats for >> such messages (e.g. CMS) those formats use encodings which are not >> congenial for Web applications. This document describes a new >> cryptographic message format which is based on JavaScript Object >> Notation (JSON) and thus is easy for Web applications to generate and >> parse. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> > Part.txt>_______________________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA83C3A6911 for ; Thu, 10 Mar 2011 09:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.358 X-Spam-Level: X-Spam-Status: No, score=-104.358 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4EwzEGTS-FW for ; Thu, 10 Mar 2011 09:09:40 -0800 (PST) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id E240F3A68AF for ; Thu, 10 Mar 2011 09:09:40 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 09:10:58 -0800 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Mar 2011 17:10:58 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 10 Mar 2011 10:11:01 -0700 From: Joe Hildebrand To: Sean Turner , "woes@ietf.org" Message-ID: Thread-Topic: [woes] BAR BOF Time Thread-Index: AcvfRiFTREdmtOq7nEajGrsq4OXgZA== In-Reply-To: <4D7905DF.2080705@ieca.com> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Mar 2011 17:10:58.0865 (UTC) FILETIME=[200D7A10:01CBDF46] Subject: Re: [woes] BAR BOF Time X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:09:41 -0000 Thanks! On 3/10/11 10:09 AM, "Sean Turner" wrote: > We've secured Karlin I at 2000 on Monday. This will give us some time > to talk it out during the week. > > spt > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D95C3A6A25 for ; Thu, 10 Mar 2011 09:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zEIAD0-ru8d for ; Thu, 10 Mar 2011 09:08:38 -0800 (PST) Received: from nm18-vm0.bullet.mail.ne1.yahoo.com (nm18-vm0.bullet.mail.ne1.yahoo.com [98.138.91.37]) by core3.amsl.com (Postfix) with SMTP id 50B7C3A68AF for ; Thu, 10 Mar 2011 09:08:38 -0800 (PST) Received: from [98.138.90.53] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 10 Mar 2011 17:09:53 -0000 Received: from [98.138.89.234] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 10 Mar 2011 17:09:53 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 10 Mar 2011 17:09:53 -0000 X-Yahoo-Newman-Id: 420613.1430.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 38710 invoked from network); 10 Mar 2011 17:09:52 -0000 Received: from thunderfish.local (turners@71.191.12.218 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 10 Mar 2011 09:09:52 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: F9SsGpsVM1mbaOcgZlT3c.Ad8flsgVbPZPhZLOwdjDOGAJy aRqNt3qMFma_i7B_jEBrEVJGclLpgBo1C5f0NxTc6QQq4TjZ4KGD7kpPwRra BsNaOfMCN6J0XivZIZwTMzZRvizdzQFkeekNLnJrIsG0fvctWhtfwUsrojDH OWtrDWd3.ZUkXBehM8sGRiTzZN9LL.Gca2pttqW_tc.g_Uh2F_9yU3Iin1QG PXbHtSKjDY3a3y49Heq7h0rDY11s5PpK3aH5eVW0BoosyiDhorqdF9BI1A1B r_J7Q0AvXbA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D7905DF.2080705@ieca.com> Date: Thu, 10 Mar 2011 12:09:51 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: woes@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [woes] BAR BOF Time X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:08:39 -0000 We've secured Karlin I at 2000 on Monday. This will give us some time to talk it out during the week. spt Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77FB3A69E4 for ; Thu, 10 Mar 2011 07:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.329 X-Spam-Level: X-Spam-Status: No, score=-104.329 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYEI1ZJ98yxP for ; Thu, 10 Mar 2011 07:04:47 -0800 (PST) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id DD41B3A69E0 for ; Thu, 10 Mar 2011 07:04:47 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 07:06:05 -0800 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Mar 2011 15:06:05 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 10 Mar 2011 08:06:07 -0700 From: Joe Hildebrand To: , Peter Saint-Andre , Message-ID: Thread-Topic: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt Thread-Index: Acvet2bMmcjMjxc/Q5KBgvo/bRlZ2QARc/PgAA3d/U0= In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA305BE0283@S4DE9JSAAID.ost.t-com.de> IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Mar 2011 15:06:05.0793 (UTC) FILETIME=[ADD56D10:01CBDF34] Cc: Eric Rescorla , "woes@ietf.org" Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 15:04:49 -0000 We actually are aware of that draft. What we had agreed was that they would both be inputs to the WOES bar BoF in Prague, where we can talk about scope and layering. On 3/10/11 1:31 AM, "Axel.Nennker@telekom.de" wrote: > It seems that the authors of the new draft do not know about > http://self-issued.info/docs/draft-jones-json-web-token-01.html > > -Axel > >> -----Original Message----- >> From: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On >> Behalf Of Peter Saint-Andre >> Sent: Thursday, March 10, 2011 1:09 AM >> To: Dick Hardt >> Cc: woes@ietf.org >> Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt >> >> There is no WG yet, but yes I think the woes@ietf.org list is the best >> place to discuss this proposal. >> >> On 3/9/11 4:56 PM, Dick Hardt wrote: >>> Hi Peter >>> >>> Is there a different WG working on this draft, or is this >> draft part of this WG? >>> >>> It is unclear to me where comments would be posted. >>> >>> -- Dick >>> >>> On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: >>> >>>> FYI. >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action:draft-rescorla-jsms-00.txt >>>> Date: Mon, 07 Mar 2011 15:30:03 -0800 >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : JavaScript Message Security Format >>>> Author(s) : E. Rescorla, J. Hildebrand >>>> Filename : draft-rescorla-jsms-00.txt >>>> Pages : 24 >>>> Date : 2011-03-07 >>>> >>>> Many applications require the ability to send cryptographically >>>> secured messages. While the IETF has defined a number of >> formats for >>>> such messages (e.g. CMS) those formats use encodings which are not >>>> congenial for Web applications. This document describes a new >>>> cryptographic message format which is based on JavaScript Object >>>> Notation (JSON) and thus is easy for Web applications to >> generate and >>>> parse. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> > Part.txt>_______________________________________________ >>>> woes mailing list >>>> woes@ietf.org >>>> https://www.ietf.org/mailman/listinfo/woes >>> >> >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> >> -- Joe Hildebrand Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044F03A686A for ; Thu, 10 Mar 2011 00:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCXufnNpnCwa for ; Thu, 10 Mar 2011 00:31:03 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 6BAB23A67EF for ; Thu, 10 Mar 2011 00:31:03 -0800 (PST) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 10 Mar 2011 09:31:47 +0100 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 09:31:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 09:31:47 +0100 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA305BE0283@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <4D7816A7.8050707@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt Thread-Index: Acvet2bMmcjMjxc/Q5KBgvo/bRlZ2QARc/Pg References: <4D77FACB.9080800@stpeter.im><81D3C959-0C75-4033-9645-F6425FA55DF3@gmail.com> <4D7816A7.8050707@stpeter.im> From: To: , X-OriginalArrivalTime: 10 Mar 2011 08:31:47.0666 (UTC) FILETIME=[987DBB20:01CBDEFD] Cc: ekr@rtfm.com, woes@ietf.org, jhildebr@cisco.com Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 08:31:05 -0000 It seems that the authors of the new draft do not know about=20 http://self-issued.info/docs/draft-jones-json-web-token-01.html -Axel=20 > -----Original Message----- > From: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On=20 > Behalf Of Peter Saint-Andre > Sent: Thursday, March 10, 2011 1:09 AM > To: Dick Hardt > Cc: woes@ietf.org > Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt >=20 > There is no WG yet, but yes I think the woes@ietf.org list is the best > place to discuss this proposal. >=20 > On 3/9/11 4:56 PM, Dick Hardt wrote: > > Hi Peter > >=20 > > Is there a different WG working on this draft, or is this=20 > draft part of this WG? > >=20 > > It is unclear to me where comments would be posted. > >=20 > > -- Dick > >=20 > > On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: > >=20 > >> FYI. > >> > >> -------- Original Message -------- > >> Subject: I-D Action:draft-rescorla-jsms-00.txt > >> Date: Mon, 07 Mar 2011 15:30:03 -0800 > >> From: Internet-Drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> Title : JavaScript Message Security Format > >> Author(s) : E. Rescorla, J. Hildebrand > >> Filename : draft-rescorla-jsms-00.txt > >> Pages : 24 > >> Date : 2011-03-07 > >> > >> Many applications require the ability to send cryptographically > >> secured messages. While the IETF has defined a number of=20 > formats for > >> such messages (e.g. CMS) those formats use encodings which are not > >> congenial for Web applications. This document describes a new > >> cryptographic message format which is based on JavaScript Object > >> Notation (JSON) and thus is easy for Web applications to=20 > generate and > >> parse. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> Part.txt>_______________________________________________ > >> woes mailing list > >> woes@ietf.org > >> https://www.ietf.org/mailman/listinfo/woes > >=20 >=20 >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555DB3A6A88 for ; Wed, 9 Mar 2011 16:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r7EG7EJLmyW for ; Wed, 9 Mar 2011 16:15:56 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 63D3A3A67D9 for ; Wed, 9 Mar 2011 16:15:56 -0800 (PST) Received: by gyc15 with SMTP id 15so593993gyc.31 for ; Wed, 09 Mar 2011 16:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=tXxOJvd1RVjuwxzD71IsCcPgGS8KFSnBH26EpmbPIiU=; b=gwsNvO9Yd+lzfyr1tJmw4Cwl0eQQKSW0jfH7tRFpAPSNfTZWhV0B0GUnTjBOgO3AjM aYv1QXINHXtbCEZ+yI/19GbgAwdyADxkgu7k3pn8uraoPekVOwYy+NJw7YeQEotA9pXF KD1gCTWGgVHHoGxW3civXdYIs3OuZmxSQFyl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Q2GpCBiaj1VBPvyeKMVQymdGZmIWGtNGu/X5XIfM/yQNBU9gDNaRTQY11D4sSd12Bf yvb+3x720L6pQJQqvwc4YGNHbpUWkY/KDxtPtflWvtQcpEJdLhktf3ULJdEw/lmp0+sd 7C4/84fGmUgo9CuZCcG9KQcVhkFFAxQe3aAyM= Received: by 10.150.74.12 with SMTP id w12mr116031yba.183.1299716232535; Wed, 09 Mar 2011 16:17:12 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id w1sm1832181ybl.9.2011.03.09.16.17.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2011 16:17:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4D77FACB.9080800@stpeter.im> Date: Wed, 9 Mar 2011 16:17:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B1CCAC9-9315-4246-BDCA-79D5E942E42E@gmail.com> References: <4D77FACB.9080800@stpeter.im> To: Eric Rescorla X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 10 Mar 2011 12:14:03 -0800 Cc: woes@ietf.org Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:15:57 -0000 Eric An example or commentary explaining going from a JSON message to signing = would be useful.=20 I read over the document twice and I cannot figure out how it all fits = together. -- Dick On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: > FYI. >=20 > -------- Original Message -------- > Subject: I-D Action:draft-rescorla-jsms-00.txt > Date: Mon, 07 Mar 2011 15:30:03 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : JavaScript Message Security Format > Author(s) : E. Rescorla, J. Hildebrand > Filename : draft-rescorla-jsms-00.txt > Pages : 24 > Date : 2011-03-07 >=20 > Many applications require the ability to send cryptographically > secured messages. While the IETF has defined a number of formats for > such messages (e.g. CMS) those formats use encodings which are not > congenial for Web applications. This document describes a new > cryptographic message format which is based on JavaScript Object > Notation (JSON) and thus is easy for Web applications to generate and > parse. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F893A6A88 for ; Wed, 9 Mar 2011 16:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP0uBGDDKO5b for ; Wed, 9 Mar 2011 16:07:56 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3F2203A67D9 for ; Wed, 9 Mar 2011 16:07:56 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D7E894011B; Wed, 9 Mar 2011 17:29:14 -0700 (MST) Message-ID: <4D7816A7.8050707@stpeter.im> Date: Wed, 09 Mar 2011 17:09:11 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dick Hardt References: <4D77FACB.9080800@stpeter.im> <81D3C959-0C75-4033-9645-F6425FA55DF3@gmail.com> In-Reply-To: <81D3C959-0C75-4033-9645-F6425FA55DF3@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080400020908000703050804" Cc: "woes@ietf.org" Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:07:57 -0000 This is a cryptographically signed message in MIME format. --------------ms080400020908000703050804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is no WG yet, but yes I think the woes@ietf.org list is the best place to discuss this proposal. On 3/9/11 4:56 PM, Dick Hardt wrote: > Hi Peter >=20 > Is there a different WG working on this draft, or is this draft part of= this WG? >=20 > It is unclear to me where comments would be posted. >=20 > -- Dick >=20 > On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: >=20 >> FYI. >> >> -------- Original Message -------- >> Subject: I-D Action:draft-rescorla-jsms-00.txt >> Date: Mon, 07 Mar 2011 15:30:03 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : JavaScript Message Security Format >> Author(s) : E. Rescorla, J. Hildebrand >> Filename : draft-rescorla-jsms-00.txt >> Pages : 24 >> Date : 2011-03-07 >> >> Many applications require the ability to send cryptographically >> secured messages. While the IETF has defined a number of formats for >> such messages (e.g. CMS) those formats use encodings which are not >> congenial for Web applications. This document describes a new >> cryptographic message format which is based on JavaScript Object >> Notation (JSON) and thus is easy for Web applications to generate and >> parse. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________= ________________________________ >> woes mailing list >> woes@ietf.org >> https://www.ietf.org/mailman/listinfo/woes >=20 --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080400020908000703050804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMx MDAwMDkxMVowIwYJKoZIhvcNAQkEMRYEFMcd9M1drVSUfLyTEWa5BI9YFdhOMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAOXJVRL0HxqO1yo5zds4TnSjhAb1Mz08p8W+IdkTB2WEeu0r1mh/QIcRBf QnDMq15ttLDKXY8qkxagedIwJPyQCeQYPcBDf4VBn7Rh/TAEGqqdGpI6tbEIxDxYToaY8LrU fAF7atgX4rShs4F+1tu6JyOIspuxYcOvjalVXr4NwY7v1cmmi5eJ9VVn2/KUuEwyUxjsD5R8 3ndrDDGfJu4BHjFYNQzy+2mSaE7W+0aKR879MOpGkRNFmJcG/fS3B2sgZtdP6qZjuMsWuOh7 C5tYGtw90+HDpNboiSuPB5ifMTrgm3yyi5dYZU52/BwMZ30i55tgAxKKBTIZcSLCInd/AAAA AAAA --------------ms080400020908000703050804-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FEE3A6AF6 for ; Wed, 9 Mar 2011 16:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Sfs88jnXCpc for ; Wed, 9 Mar 2011 16:02:24 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 2D6393A67D9 for ; Wed, 9 Mar 2011 16:02:24 -0800 (PST) Received: by gxk5 with SMTP id 5so553749gxk.31 for ; Wed, 09 Mar 2011 16:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=YGYsWEFdMiyIdjBTC7Vf2sec68KrDUk2L69ULMhngOQ=; b=AV1MOEryvsvqzsDRE/kfeTJpMikjt0aUbvVoIeBk0rbdocJGk0QxrhFz1UGP/fL5fq XVsGgJXk84ZImmgAX92bardmblGZgNE1uZ39UaJShDGGCLoy2WFFPJXw/2uMZBZCkQAZ 7F8AAcVD6vyOpaJbxLrarMH2A8XqgiQDGqYQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Wac1DSqLpT8IUIIjGqkfDKnA134xo8FMy7Pna3pNu/wmlRoCjQEDr978C0JUyDYF7z bi6NEos0vBN2DZEE1EiiGXokpYAhMczuh7O2e+ApCCnBBY/VYcizOdJQfIvACpjEdGkL baT6j53TQaLPahwBEF/dYXybYNwNBNhNJwEn8= Received: by 10.150.176.9 with SMTP id y9mr82864ybe.429.1299715420792; Wed, 09 Mar 2011 16:03:40 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id i60sm1666044yhj.17.2011.03.09.16.03.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2011 16:03:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4D77FACB.9080800@stpeter.im> Date: Wed, 9 Mar 2011 16:03:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6239AF3F-D094-4ECD-934F-C9FFBB426F37@gmail.com> References: <4D77FACB.9080800@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 10 Mar 2011 12:14:03 -0800 Cc: "woes@ietf.org" Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:02:24 -0000 Hi Peter Is there a different WG working on this draft, or is this draft part of = this WG? It is unclear to me where comments would be posted. -- Dick On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: > FYI. >=20 > -------- Original Message -------- > Subject: I-D Action:draft-rescorla-jsms-00.txt > Date: Mon, 07 Mar 2011 15:30:03 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : JavaScript Message Security Format > Author(s) : E. Rescorla, J. Hildebrand > Filename : draft-rescorla-jsms-00.txt > Pages : 24 > Date : 2011-03-07 >=20 > Many applications require the ability to send cryptographically > secured messages. While the IETF has defined a number of formats for > such messages (e.g. CMS) those formats use encodings which are not > congenial for Web applications. This document describes a new > cryptographic message format which is based on JavaScript Object > Notation (JSON) and thus is easy for Web applications to generate and > parse. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C583A6AF9 for ; Wed, 9 Mar 2011 15:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ2O95lFsqOk for ; Wed, 9 Mar 2011 15:55:33 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 16B783A677C for ; Wed, 9 Mar 2011 15:55:33 -0800 (PST) Received: by pwi5 with SMTP id 5so421331pwi.31 for ; Wed, 09 Mar 2011 15:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=YGYsWEFdMiyIdjBTC7Vf2sec68KrDUk2L69ULMhngOQ=; b=AMd4GxQRCHTikOygsSM/ylVjnCSM/NClBGKlrwXea4LShVsH2K/Oln16IpyzpdxnTb BGZ5Rm7uDyeHOE2HvAYzRbHTgvvH9zL8TTg/7aHbiB+9Q4y3zYppz2HghropXZyWTLkh dzMl9NbB6Z7neAXi8XcXYnQt83hy8Q670RkRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MeB7X2n1Q9qKFio5n/DZ5H82V0f1Ik63YsCglYgdSh2TZQ1R4ztbcxbDcOyq3uYC8H CfvUAKOBvGque/zRG0vUgMubHVVGY5qpmUgJB4QLzH31UAwrV9LM1g/4GxNsk+Poq+yk +9uNnQvrWZHp+LVtUs/yVpKGXs7vuAcELby0c= Received: by 10.142.62.42 with SMTP id k42mr5948583wfa.230.1299715010044; Wed, 09 Mar 2011 15:56:50 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id w11sm3099385wfh.18.2011.03.09.15.56.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2011 15:56:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4D77FACB.9080800@stpeter.im> Date: Wed, 9 Mar 2011 15:56:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <81D3C959-0C75-4033-9645-F6425FA55DF3@gmail.com> References: <4D77FACB.9080800@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 10 Mar 2011 12:13:45 -0800 Cc: "woes@ietf.org" Subject: Re: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:55:34 -0000 Hi Peter Is there a different WG working on this draft, or is this draft part of = this WG? It is unclear to me where comments would be posted. -- Dick On 2011-03-09, at 2:10 PM, Peter Saint-Andre wrote: > FYI. >=20 > -------- Original Message -------- > Subject: I-D Action:draft-rescorla-jsms-00.txt > Date: Mon, 07 Mar 2011 15:30:03 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : JavaScript Message Security Format > Author(s) : E. Rescorla, J. Hildebrand > Filename : draft-rescorla-jsms-00.txt > Pages : 24 > Date : 2011-03-07 >=20 > Many applications require the ability to send cryptographically > secured messages. While the IETF has defined a number of formats for > such messages (e.g. CMS) those formats use encodings which are not > congenial for Web applications. This document describes a new > cryptographic message format which is based on JavaScript Object > Notation (JSON) and thus is easy for Web applications to generate and > parse. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726263A6768 for ; Wed, 9 Mar 2011 14:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7HW0NA8HB-S for ; Wed, 9 Mar 2011 14:16:49 -0800 (PST) Received: from nm28.bullet.mail.sp2.yahoo.com (nm28.bullet.mail.sp2.yahoo.com [98.139.91.98]) by core3.amsl.com (Postfix) with SMTP id CCD943A6452 for ; Wed, 9 Mar 2011 14:16:49 -0800 (PST) Received: from [98.139.91.70] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 09 Mar 2011 22:18:04 -0000 Received: from [98.139.91.4] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 09 Mar 2011 22:18:04 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 09 Mar 2011 22:18:04 -0000 X-Yahoo-Newman-Id: 561759.96324.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 35659 invoked from network); 9 Mar 2011 22:18:04 -0000 Received: from thunderfish.local (turners@71.191.3.104 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 09 Mar 2011 14:18:03 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 0gZjGOQVM1m2n0ZT5tdRZUpOQ9tvdMCzBUdEPPXbW5qTbPT Fkj6nBCvxHR8SQ3916QWqZUQq7_0mJIrw6ZCmWeIIlKDh3J6P3zv1RVvq0Ys ydw0WuYAE4n8bSAv0_XmtKJHT0oAhV3K_thQ9juiKtS3xMC42blhMBapr2sH i38vQeZDDh8uNEHWnIAXNhBGCo4pp6N_azMpdp06yf.0fJh37lwk1rZZ.5ro PFIMF2Iqn1IHsaHulJ1z6sEOT5HO8ZEb_9FaDf9X_PEKsA_E72Z3gzx2fXg1 NP6iKvJxTyKn5w7d7P0aNbqg6YvyfUlTqUC6gmy7_zv2i X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D77FC9B.7060408@ieca.com> Date: Wed, 09 Mar 2011 17:18:03 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D77FB16.4030803@stpeter.im> In-Reply-To: <4D77FB16.4030803@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "woes@ietf.org" Subject: Re: [woes] meeting particulars X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:16:50 -0000 I have not heard back from the room schedulers. I pinged them just the other day. spt On 3/9/11 5:11 PM, Peter Saint-Andre wrote: > I don't think anyone has posted particulars of the side meeting to be > held in Prague. What is the date, time, and location? My schedule is > filling up fast. :) > > Peter > > > > > _______________________________________________ > woes mailing list > woes@ietf.org > https://www.ietf.org/mailman/listinfo/woes Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29703A6AEF for ; Wed, 9 Mar 2011 14:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81KRfajcQ0uj for ; Wed, 9 Mar 2011 14:10:18 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A0D3B3A6AEB for ; Wed, 9 Mar 2011 14:10:18 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 12C454011B for ; Wed, 9 Mar 2011 15:31:36 -0700 (MST) Message-ID: <4D77FB16.4030803@stpeter.im> Date: Wed, 09 Mar 2011 15:11:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "woes@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070602050809090600000107" Subject: [woes] meeting particulars X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:10:19 -0000 This is a cryptographically signed message in MIME format. --------------ms070602050809090600000107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think anyone has posted particulars of the side meeting to be held in Prague. What is the date, time, and location? My schedule is filling up fast. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070602050809090600000107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw OTIyMTEzNFowIwYJKoZIhvcNAQkEMRYEFPzJVn/4PSgQ8nFfoaAH4WvdGHCAMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCHsyctKw9bX1SofiV/yXMvVVFlCd1rjwo2JeMa2m4JXm94lHwT83y7Y3ZX vza/4GVf5NgUOXA6QJ799ZbsZwFsO0H9WWDxN8YMtyPz3Ih4W/RkY9dNFLcaV3cpe7SJQ7pi vz7YAFlXVCYc1mxzNUPx6pX7pYz32FCU3AOaoUTGhvX25PIyooWSO0gs4EFQT/nXlZOLmz+G qCTNmEQqrrvqfq38DxqaEsRi0qLwo7WLTT5MGC8wHrV0ScWL2ZPWR/SuZZKrWetjqDqyl1nM 7/Ki+rTm7stfym/nNX3WBiugthS8yEcDpHUk9E1M5tdmixD+eVZlQhVnH/RLK74s1jRJAAAA AAAA --------------ms070602050809090600000107-- Return-Path: X-Original-To: woes@core3.amsl.com Delivered-To: woes@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640C93A6AB0 for ; Wed, 9 Mar 2011 14:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eavsChJbiqPb for ; Wed, 9 Mar 2011 14:09:05 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7F9913A677E for ; Wed, 9 Mar 2011 14:09:05 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 569424011B for ; Wed, 9 Mar 2011 15:30:23 -0700 (MST) Message-ID: <4D77FACB.9080800@stpeter.im> Date: Wed, 09 Mar 2011 15:10:19 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "woes@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080309080900060804000303" Subject: [woes] Fwd: I-D Action:draft-rescorla-jsms-00.txt X-BeenThere: woes@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:09:06 -0000 This is a cryptographically signed message in MIME format. --------------ms080309080900060804000303 Content-Type: multipart/mixed; boundary="------------040002090201030101070504" This is a multi-part message in MIME format. --------------040002090201030101070504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. -------- Original Message -------- Subject: I-D Action:draft-rescorla-jsms-00.txt Date: Mon, 07 Mar 2011 15:30:03 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : JavaScript Message Security Format Author(s) : E. Rescorla, J. Hildebrand Filename : draft-rescorla-jsms-00.txt Pages : 24 Date : 2011-03-07 Many applications require the ability to send cryptographically secured messages. While the IETF has defined a number of formats for such messages (e.g. CMS) those formats use encodings which are not congenial for Web applications. This document describes a new cryptographic message format which is based on JavaScript Object Notation (JSON) and thus is easy for Web applications to generate and parse. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------040002090201030101070504 Content-Type: Message/External-body; name="draft-rescorla-jsms-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-rescorla-jsms-00.txt" Content-Type: text/plain Content-ID: <2011-03-07152929.I-D@ietf.org> --------------040002090201030101070504 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------040002090201030101070504-- --------------ms080309080900060804000303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMw OTIyMTAxOVowIwYJKoZIhvcNAQkEMRYEFLMSn5EarAKSbIAtSAt4dTKTuBACMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCTgNdS5Dyjh3Y6bmEk43oFxss5o6D41lKV2+SppnQOTUqA/puvOQChZToZ ObOmT908JjulCiaaqZFUbmueY1L2W2YNkYpVATZ4ACM7Qzwbp0o435sAPM7bJdIzOcNrtAEV lKPCrhS6PwAzh40CyNFW7y/gb66GpTj5hMd33Fs1Eaijw/KWjix9s/lA+LZ+WZwgOsRl2LQp bzIQpeqdvbk4Qq7Mh4qamj8McHN5a09FEPmgBzyguyUyqXo6xnYPItJdT0xZq8RU/Q9yJZ9j ryC/Kko3hWYTK2zlZ50AEoWVeGOXr06ExPpp2rtX8eDW4fgSI0yQIglZzTOIXNV66eQ1AAAA AAAA --------------ms080309080900060804000303--