From odonoghue@isoc.org Wed Feb 5 07:55:42 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E7D1A01BC for ; Wed, 5 Feb 2014 07:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lem8HTNhBZL for ; Wed, 5 Feb 2014 07:55:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4A31A01BB for ; Wed, 5 Feb 2014 07:55:40 -0800 (PST) Received: from kodonog-mac.local (74.214.48.55) by DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 15:55:38 +0000 Message-ID: <52F25EF7.2030006@isoc.org> Date: Wed, 5 Feb 2014 10:55:35 -0500 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "jose@ietf.org" References: <52E0AB85.1070409@isoc.org> In-Reply-To: <52E0AB85.1070409@isoc.org> X-Forwarded-Message-Id: <52E0AB85.1070409@isoc.org> Content-Type: multipart/alternative; boundary="------------070901040008070104010101" X-Originating-IP: [74.214.48.55] X-ClientProxiedBy: BLUPR01CA007.prod.exchangelabs.com (10.255.223.165) To DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) X-Forefront-PRVS: 01136D2D90 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(13464003)(199002)(189002)(12213003)(36756003)(90146001)(83072002)(93516002)(92566001)(86362001)(56816005)(94946001)(64126003)(46102001)(15975445006)(76482001)(74366001)(83506001)(69226001)(76786001)(74662001)(54316002)(16236675002)(85852003)(81686001)(74876001)(77096001)(85306002)(56776001)(76796001)(94316002)(53806001)(51856001)(79102001)(74706001)(47446002)(74502001)(33656001)(81342001)(54356001)(81542001)(71186001)(47736001)(63696002)(87976001)(31966008)(93136001)(59766001)(512934002)(42186004)(50986001)(47976001)(92726001)(80316001)(80976001)(66066001)(65956001)(19580405001)(49866001)(83322001)(80022001)(59896001)(81816001)(77982001)(4396001)(65806001)(19580395003)(84326002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR06MB591; H:kodonog-mac.local; CLIP:74.214.48.55; FPR:FCCB7134.AC949CF6.1D48CF0.C0EC93F0.201CA; InfoNoRecordsA:1; MX:1; LANG:en; X-OriginatorOrg: isoc.org Subject: [jose] REMINDER: WGLC for JWA, JWE, JWK, and JWS X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:55:42 -0000 --------------070901040008070104010101 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Folks, Just a quick reminder that we are almost two weeks into our three week WGLC, and I haven't seen any traffic on the mailing list yet regarding these documents. Ideally, I'd like to see something along the lines of the following: - I have reviewed the (JWA/JWE/JWK/JSW) document(s) - I believe this document IS or IS NOT ready to be sent to the IESG - I have the following comments... Deadline is 13 February! Karen -------- Original Message -------- Subject: [jose] WGLC for JWA, JWE, JWK, and JWS Date: Thu, 23 Jan 2014 00:41:25 -0500 From: Karen O'Donoghue To: jose@ietf.org Folks, This message initiates three week WGLCs for the four JOSE WG specifications referenced below: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ Please review and comment on the documents and put any issues in the JOSE WG issue tracker. The WGLC will end on 13 February 2014. Regards, JOSE WG co-chairs _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --------------070901040008070104010101 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Folks,

Just a quick reminder that we are almost two weeks into our three week WGLC,
and I haven't seen any traffic on the mailing list yet regarding these documents.

Ideally, I'd like to see something along the lines of the following:

- I have reviewed the (JWA/JWE/JWK/JSW) document(s)
- I believe this document IS or IS NOT ready to be sent to the IESG
- I have the following comments...

Deadline is 13 February!
Karen

-------- Original Message --------
Subject: [jose] WGLC for JWA, JWE, JWK, and JWS
Date: Thu, 23 Jan 2014 00:41:25 -0500
From: Karen O'Donoghue <odonoghue@isoc.org>
To: jose@ietf.org <jose@ietf.org>


Folks,

This message initiates three week WGLCs for the four JOSE WG specifications
referenced below:

https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/

Please review and comment on the documents and put any issues in the
JOSE WG issue tracker. The WGLC will end on 13 February 2014.

Regards,
JOSE WG co-chairs

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


--------------070901040008070104010101-- From watsonm@netflix.com Wed Feb 5 15:01:03 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A99B1A016B for ; Wed, 5 Feb 2014 15:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ircp3FQK2Il for ; Wed, 5 Feb 2014 15:01:02 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E081E1A0233 for ; Wed, 5 Feb 2014 15:01:01 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id y1so885711lam.13 for ; Wed, 05 Feb 2014 15:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=AUNwT6i2T16dPAqxCxJsdFyeSNOa2E3HQ1f1CgOW0j8=; b=DL8ZMhN96ungIWxslja8yXhaD1BsdJCxnOBXhCNly5zxJhYvTY+lqH+V0DfL+mEtkD 7Xj8M3n14nOgshVjelb9KEjU5cojxlYCgmQJi2yfdPpMObB2u0CJUZZCRiMYvHws1t00 RvG9lT5xnH6hvaQDhoCaO0c6tcIdV8ywYWN1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=AUNwT6i2T16dPAqxCxJsdFyeSNOa2E3HQ1f1CgOW0j8=; b=da0ZLgqqU3Q//Ty05Ybw5mkw1LfX4SwV5+u8RRWf4BzhfTTq/krw7p5XYlMF9CoSiF Bgf4oeA/45MuE4lnYOqTKWttyfO+H+fcAPDX0g2BP6XrDEAxuUFfJUP+1hJTy0RgGIxG OrFirOW7AdwZ9CieBqRNwNmhopGNdUEri5pNKvrQRvHxxg4vZxBgP5XUKRixapvh13MP c7YKEx2y2WEShiB9FmMknmu2nfGVka4GVuIUfOnIL+QskGiMQjMXfVryRrajC0Ajddg+ PzmqWuwNv4RgX/R8mNmW/Yf/F/A+kePmUJP6cvifcAcFTzIyKJ7sSNkXIQUxoMFby1F6 lWrQ== X-Gm-Message-State: ALoCoQlhgwFLpuDEeyjsSpctxt8NWuYrxaIvWBM34pNb5nES/mpP9Z0Hd3lTzlCY4V+k8y7BRz+k MIME-Version: 1.0 X-Received: by 10.152.23.132 with SMTP id m4mr2848785laf.34.1391641260201; Wed, 05 Feb 2014 15:01:00 -0800 (PST) Received: by 10.112.255.75 with HTTP; Wed, 5 Feb 2014 15:01:00 -0800 (PST) Date: Wed, 5 Feb 2014 15:01:00 -0800 Message-ID: From: Mark Watson To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=089e0160b5eef828e004f1b0ba11 Subject: [jose] Naming of JWK key_ops values for wrap and unwrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:01:03 -0000 --089e0160b5eef828e004f1b0ba11 Content-Type: text/plain; charset=ISO-8859-1 All, Since JWK key_ops was added primarily to accurately represent WebCrypto keys, would it be possible to amend the values for "wrap" and "unwrap" to "wrapKey" and "unwrapKey" to align with the WebCrypto naming ? ...Mark --089e0160b5eef828e004f1b0ba11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All= ,

Since JWK key_ops was a= dded primarily to accurately represent WebCrypto keys, would it be possible= to amend the values for "wrap" and "unwrap" to "w= rapKey" and "unwrapKey" to align with the WebCrypto naming ?=

...Mark
--089e0160b5eef828e004f1b0ba11-- From Michael.Jones@microsoft.com Wed Feb 5 15:06:48 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF221A029F for ; Wed, 5 Feb 2014 15:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxTVXkbidSVV for ; Wed, 5 Feb 2014 15:06:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id 458AB1A029C for ; Wed, 5 Feb 2014 15:06:43 -0800 (PST) Received: from BL2PR03CA018.namprd03.prod.outlook.com (10.141.66.26) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 23:06:40 +0000 Received: from BN1BFFO11FD020.protection.gbl (2a01:111:f400:7c10::1:154) by BL2PR03CA018.outlook.office365.com (2a01:111:e400:c1b::26) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Wed, 5 Feb 2014 23:06:40 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD020.mail.protection.outlook.com (10.58.144.83) with Microsoft SMTP Server (TLS) id 15.0.856.14 via Frontend Transport; Wed, 5 Feb 2014 23:06:40 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Wed, 5 Feb 2014 23:06:04 +0000 From: Mike Jones To: Mark Watson , "jose@ietf.org" Thread-Topic: [jose] Naming of JWK key_ops values for wrap and unwrap Thread-Index: AQHPIsY6bdsPh25mGkiUXaqQOsdAq5qnR5zg Date: Wed, 5 Feb 2014 23:06:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B1562CD@TK5EX14MBXC288.redmond.corp.microsoft.com> References: 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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B1562CDTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(199002)(189002)(51884002)(377454003)(74366001)(93136001)(63696002)(81542001)(81342001)(74502001)(74706001)(84326002)(71186001)(55846006)(74662001)(59766001)(83322001)(44976005)(49866001)(4396001)(47736001)(2656002)(80976001)(81686001)(19300405004)(87266001)(19580395003)(31966008)(19580405001)(66066001)(65816001)(20776003)(77982001)(15202345003)(47976001)(80022001)(92726001)(47446002)(94316002)(51856001)(46102001)(74876001)(81816001)(512954002)(15975445006)(79102001)(33656001)(93516002)(54356001)(69226001)(85852003)(92566001)(56816005)(86362001)(50986001)(90146001)(77096001)(56776001)(87936001)(76796001)(94946001)(76482001)(6806004)(53806001)(16236675002)(86612001)(54316002)(85306002)(76786001)(83072002)(95416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB210; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:1854D95E.D5148C1.91F1B078.566C55DC.2013F; InfoDomainNonexistentA:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01136D2D90 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Naming of JWK key_ops values for wrap and unwrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:06:48 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B1562CDTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that we should make this change, since it aligns with the WebCryp= to editor's draft at https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec= /Overview.html. I believe that the names "wrap" and "unwrap" came from the= older draft at http://www.w3.org/TR/WebCryptoAPI/. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mark Watson Sent: Wednesday, February 05, 2014 3:01 PM To: jose@ietf.org Subject: [jose] Naming of JWK key_ops values for wrap and unwrap All, Since JWK key_ops was added primarily to accurately represent WebCrypto key= s, would it be possible to amend the values for "wrap" and "unwrap" to "wra= pKey" and "unwrapKey" to align with the WebCrypto naming ? ...Mark --_000_4E1F6AAD24975D4BA5B16804296739438B1562CDTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe that we should = make this change, since it aligns with the WebCrypto editor’s draft a= t https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html<= /a>.  I believe that the names “wrap” and “unwrap= 221; came from the older draft at http://www.w3.org/TR/WebCryp= toAPI/.

 <= /p>

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

 <= /p>

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mark Watson
Sent: Wednesday, February 05, 2014 3:01 PM
To: jose@ietf.org
Subject: [jose] Naming of JWK key_ops values for wrap and unwrap

 

All,

 

Since JWK key_ops was added primarily to accurately = represent WebCrypto keys, would it be possible to amend the values for &quo= t;wrap" and "unwrap" to "wrapKey" and "unwrap= Key" to align with the WebCrypto naming ?

 

...Mark

--_000_4E1F6AAD24975D4BA5B16804296739438B1562CDTK5EX14MBXC288r_-- From ve7jtb@ve7jtb.com Wed Feb 5 15:08:04 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5581A0275 for ; Wed, 5 Feb 2014 15:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUvws7QoaRiL for ; Wed, 5 Feb 2014 15:07:59 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC1121A0224 for ; Wed, 5 Feb 2014 15:07:59 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id w5so1653532qac.31 for ; Wed, 05 Feb 2014 15:07:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=KrbwVtTdFy0o47LN2/d7ys49o/orj/wiPU94OVINMos=; b=GR2FtGeUZzVvApbb9wQ4QLfmESKDoyD3xPi3PIoWkub4Gf1c0sxi/O9U6wtjLcw+D9 1/TyL2K11kkFzNnsTcL0qBZFc0LIM5afQ6SI6Ly06Jjsf4KI9kQEPmOy5RQDqqxjFbb8 ckrC0ekWD6NBIDJS0ZFevsURKoso4d153J+FH2uBTv5+eXuHjSeX1KR2zT1bR6kye0ia oHq+QVUO5MNAbbJJOs5E+NDZLp5gCPYPlIjCNSRkEXx4WmSjQY4FjaywLp42qQbGw/QT IX/EDPZ80U8mMRVR5S1zIPaXzJgbEcyiPMgMwGtVoi0/NW46pbZgjXxcz4hJKQOO+fsk dWPA== X-Gm-Message-State: ALoCoQlT+ZxtNDrtHAR/ZFjRXKHasWfFX2lwJyBZSqBVSaavlxsbXXTK/MeBTcNgQh1aAZVKP1LY X-Received: by 10.140.101.162 with SMTP id u31mr6786206qge.107.1391641678607; Wed, 05 Feb 2014 15:07:58 -0800 (PST) Received: from [192.168.0.200] ([201.188.15.242]) by mx.google.com with ESMTPSA id a5sm81340697qae.2.2014.02.05.15.07.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 15:07:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_48C9B584-B2FE-4E67-BFA8-0ADF949A4BAC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B1562CD@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 5 Feb 2014 20:07:33 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739438B1562CD@TK5EX14MBXC288.redmond.corp.microsoft.com> To: Michael Jones X-Mailer: Apple Mail (2.1827) Cc: Mark Watson , "jose@ietf.org" Subject: Re: [jose] Naming of JWK key_ops values for wrap and unwrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:08:04 -0000 --Apple-Mail=_48C9B584-B2FE-4E67-BFA8-0ADF949A4BAC Content-Type: multipart/alternative; boundary="Apple-Mail=_9BB95154-F781-47EA-BE82-75F9B19ECE9C" --Apple-Mail=_9BB95154-F781-47EA-BE82-75F9B19ECE9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am fine with that. On Feb 5, 2014, at 8:06 PM, Mike Jones = wrote: > I believe that we should make this change, since it aligns with the = WebCrypto editor=92s draft at = https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html. I = believe that the names =93wrap=94 and =93unwrap=94 came from the older = draft athttp://www.w3.org/TR/WebCryptoAPI/. > =20 > -- Mike > =20 > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mark Watson > Sent: Wednesday, February 05, 2014 3:01 PM > To: jose@ietf.org > Subject: [jose] Naming of JWK key_ops values for wrap and unwrap > =20 > All, > =20 > Since JWK key_ops was added primarily to accurately represent = WebCrypto keys, would it be possible to amend the values for "wrap" and = "unwrap" to "wrapKey" and "unwrapKey" to align with the WebCrypto naming = ? > =20 > ...Mark > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_9BB95154-F781-47EA-BE82-75F9B19ECE9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = fine with that.


On Feb 5, 2014, at 8:06 = PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I believe that we should make this change, since it = aligns with the WebCrypto editor=92s draft at https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overvie= w.html.  I believe that the names =93wrap=94 and =93unwrap=94 = came from the older draft athttp://www.w3.org/TR/WebCryptoAPI/.
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike
 
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mark = Watson
Sent: Wednesday, February 05, = 2014 3:01 PM
To: jose@ietf.org
Subject: [jose] Naming of JWK = key_ops values for wrap and unwrap
 
All,
 
Since = JWK key_ops was added primarily to accurately represent WebCrypto keys, = would it be possible to amend the values for "wrap" and "unwrap" to = "wrapKey" and "unwrapKey" to align with the WebCrypto naming = ?
 
...Mark
________________________= _______________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_9BB95154-F781-47EA-BE82-75F9B19ECE9C-- --Apple-Mail=_48C9B584-B2FE-4E67-BFA8-0ADF949A4BAC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjA1MjMwNzM0WjAjBgkqhkiG9w0BCQQxFgQUkwzTHxj/ z546cG18djGgLk1+VEwwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAOMHHdg0i/iQsDEf3QHV63x6Yv0DMXlCw+dRs+Zvp EUk+xr5t62DYa7nHdMOcS7L2dYpoC/EjrdwIeQfgGjhLWvc7X7IgCDfKCY8H3kA8g5TjxPX59vl6 /0TvSze6G3ExKJELUZrumMTn3lfsoQWburauQs2Goi+/6IluRBIZ6ftm6K04tKZx75Qz/acOaiFv vX8OvJJnTOZj0ODtB8LW0hqBvkyyxXUWOF8SWVO8LRDnR+F+zB1pU4bKH+MhunDaKVjV7tOYiJji TZCw3eOb5ZjwcqS7LUlOKuXUHKJTWwotehSIC33DF9aOjmjzxhgZUa/nkzTDLyq3VxMzNXqUegAA AAAAAA== --Apple-Mail=_48C9B584-B2FE-4E67-BFA8-0ADF949A4BAC-- From bcampbell@pingidentity.com Wed Feb 5 15:10:52 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921A71A02B9 for ; Wed, 5 Feb 2014 15:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZnU3WfaFFtU for ; Wed, 5 Feb 2014 15:10:44 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id CF6491A02B4 for ; Wed, 5 Feb 2014 15:10:38 -0800 (PST) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUvLE7cLkPbWY44odJ5ZG8pYtAmZTxqqK@postini.com; Wed, 05 Feb 2014 15:10:38 PST Received: by mail-ig0-f177.google.com with SMTP id k19so4525170igc.4 for ; Wed, 05 Feb 2014 15:10:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nd6opb8nuN0lbBzGL7mnoiakgkRZ5nNc4dRxoCtvLjM=; b=OyVYNgnK2JaMRTgSxhDySIJAqLDe95thypxyO8XkqxdbaGEsYVNifxY+HkgwIfrioK nQ2ZdM3MFkc6mARCtjBjfqF6LEPREQ4A7Y3ZXbAtI2gmXHRNA/JXtef92X404ou16pJg ZRlgyrAlsKXdHc9jFGwyumlMJyysVtk9EdBTEh3pOYJ/Ul/Y23Xm85OCl5siWe7PwsCO 63n8LZtJhGMmeoC5DUbvMrt/vXl/c+hUv6XYCadd/FhpK4FOvPpz6X8mkbJjUV+i1hLJ 3xrOm99iQUR4LGSRMUv31a1eP8mXXOosWR21W6P/JUiSCZ94I7agB+gZZKEfjJZ+4qE8 o5lQ== X-Received: by 10.50.50.137 with SMTP id c9mr25876512igo.42.1391641836083; Wed, 05 Feb 2014 15:10:36 -0800 (PST) X-Gm-Message-State: ALoCoQlNSjpKJnk2qTwF+ALQBBJLozEfzXw2+jKXdp5u0q3amAXbCJUwgFruznE0Qp3qwbDsvvwfKZFK61Q0WT9SeqTDQD0UF8WZmZs3v5PcpgrpVikrtpvbOhiON5GAE0Jw0qNQzzQDe+bUimCIjSj+7iYRbHVtdg== MIME-Version: 1.0 X-Received: by 10.50.50.137 with SMTP id c9mr25876131igo.42.1391641834221; Wed, 05 Feb 2014 15:10:34 -0800 (PST) Received: by 10.50.65.4 with HTTP; Wed, 5 Feb 2014 15:10:33 -0800 (PST) Received: by 10.50.65.4 with HTTP; Wed, 5 Feb 2014 15:10:33 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B1562CD@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739438B1562CD@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 5 Feb 2014 16:10:33 -0700 Message-ID: From: Brian Campbell To: Mike Jones Content-Type: multipart/alternative; boundary=047d7bdc07b23afc5f04f1b0dddd Cc: Mark Watson , jose@ietf.org Subject: Re: [jose] Naming of JWK key_ops values for wrap and unwrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:10:52 -0000 --047d7bdc07b23afc5f04f1b0dddd Content-Type: text/plain; charset=ISO-8859-1 +1 On Feb 5, 2014 4:06 PM, "Mike Jones" wrote: > I believe that we should make this change, since it aligns with the > WebCrypto editor's draft at > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html. I > believe that the names "wrap" and "unwrap" came from the older draft at > http://www.w3.org/TR/WebCryptoAPI/. > > > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mark Watson > *Sent:* Wednesday, February 05, 2014 3:01 PM > *To:* jose@ietf.org > *Subject:* [jose] Naming of JWK key_ops values for wrap and unwrap > > > > All, > > > > Since JWK key_ops was added primarily to accurately represent WebCrypto > keys, would it be possible to amend the values for "wrap" and "unwrap" to > "wrapKey" and "unwrapKey" to align with the WebCrypto naming ? > > > > ...Mark > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7bdc07b23afc5f04f1b0dddd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1

On Feb 5, 2014 4:06 PM, "Mike Jones" &= lt;Michael.Jones@microsoft.c= om> wrote:

I believe that we should = make this change, since it aligns with the WebCrypto editor’s draft a= t https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/s= pec/Overview.html.  I believe that the names “wrap” an= d “unwrap” came from the older draft at http://www= .w3.org/TR/WebCryptoAPI/.

 

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

 

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mark Watson
Sent: Wednesday, February 05, 2014 3:01 PM
To: jose@ietf.org=
Subject: [jose] Naming of JWK key_ops values for wrap and unwrap<= /u>

 

All,

 

Since JWK key_ops was added primarily to accurately = represent WebCrypto keys, would it be possible to amend the values for &quo= t;wrap" and "unwrap" to "wrapKey" and "unwrap= Key" to align with the WebCrypto naming ?

 

...Mark


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--047d7bdc07b23afc5f04f1b0dddd-- From rlb@ipv.sx Wed Feb 5 15:36:54 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499EB1A0210 for ; Wed, 5 Feb 2014 15:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcaojuucQIMP for ; Wed, 5 Feb 2014 15:36:51 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id C58A41A0141 for ; Wed, 5 Feb 2014 15:36:51 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id va2so1305017obc.26 for ; Wed, 05 Feb 2014 15:36:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DELHKVZZjOQqvwEmM1sXVm7Tittqn4sDWtNeXhLIFYI=; b=MhujVc1SN4ef0DQaNrXfVz/cmDaz0KWN6CeK8SncWCyGCo1ADBfRmHtiYrYncWXNBi buG2aDYfUCfcia0iYTYBTLryC6JNLGmIrQlpttZP56++lHMbqJYBxj6luIw0e18adVRU x/MwcZekZ6NZGfmvGMmqLtkeMfQVjNRcuZm9M78JadjM4vx5Kw6Ss+QNivrlcJ5ZeV+m K4ODcgS+p+ECQKRkhf3SWrr6V5CvYK3cGE/hopPfyNsNTUUejKxlYHPO//dt26eYqIRz egnB0kvAyMJYAYfKX6zczyROIaEkzt0eUWn/xRoJwvwV1ax9/NlJElnXLMesbG0GQ6Nh BnrA== X-Gm-Message-State: ALoCoQks4uYYop4wLVO2R3PjFtttV0mkxp8rqNKV2b8RKEl/UVzb4olXr9wPjSVj7/ASDPeQMBhs MIME-Version: 1.0 X-Received: by 10.182.160.102 with SMTP id xj6mr3853622obb.19.1391643410548; Wed, 05 Feb 2014 15:36:50 -0800 (PST) Received: by 10.60.69.102 with HTTP; Wed, 5 Feb 2014 15:36:50 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739438B1562CD@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 5 Feb 2014 18:36:50 -0500 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=bcaec5396c1623e8f704f1b13b9c Cc: Mike Jones , Mark Watson , "jose@ietf.org" Subject: Re: [jose] Naming of JWK key_ops values for wrap and unwrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:36:54 -0000 --bcaec5396c1623e8f704f1b13b9c Content-Type: text/plain; charset=ISO-8859-1 +1 On Wed, Feb 5, 2014 at 6:10 PM, Brian Campbell wrote: > +1 > On Feb 5, 2014 4:06 PM, "Mike Jones" wrote: > >> I believe that we should make this change, since it aligns with the >> WebCrypto editor's draft at >> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html. I >> believe that the names "wrap" and "unwrap" came from the older draft at >> http://www.w3.org/TR/WebCryptoAPI/. >> >> >> >> -- Mike >> >> >> >> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mark Watson >> *Sent:* Wednesday, February 05, 2014 3:01 PM >> *To:* jose@ietf.org >> *Subject:* [jose] Naming of JWK key_ops values for wrap and unwrap >> >> >> >> All, >> >> >> >> Since JWK key_ops was added primarily to accurately represent WebCrypto >> keys, would it be possible to amend the values for "wrap" and "unwrap" to >> "wrapKey" and "unwrapKey" to align with the WebCrypto naming ? >> >> >> >> ...Mark >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec5396c1623e8f704f1b13b9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1



=
On Wed, Feb 5, 2014 at 6:10 PM, Brian Campbell <= span dir=3D"ltr"><bcampbell@pingidentity.com> wrote:

+1

On Feb 5, 2014 4:06 PM, &= quot;Mike Jones" <Michael.Jones@microsoft.com> wrote:

I believe that we should = make this change, since it aligns with the WebCrypto editor’s draft a= t https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/s= pec/Overview.html.  I believe that the names “wrap” an= d “unwrap” came from the older draft at http://www= .w3.org/TR/WebCryptoAPI/.

 

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

 

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mark Watson
Sent: Wednesday, February 05, 2014 3:01 PM
To: jose@ietf.org=
Subject: [jose] Naming of JWK key_ops values for wrap and unwrap<= /u>

 

All,

 

Since JWK key_ops was added primarily to accurately = represent WebCrypto keys, would it be possible to amend the values for &quo= t;wrap" and "unwrap" to "wrapKey" and "unwrap= Key" to align with the WebCrypto naming ?

 

...Mark


_________________________________________= ______
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec5396c1623e8f704f1b13b9c-- From ietf@augustcellars.com Fri Feb 7 10:31:59 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D51C1ACCDE for ; Fri, 7 Feb 2014 10:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzVH7ENfCwly for ; Fri, 7 Feb 2014 10:31:56 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC91A03E1 for ; Fri, 7 Feb 2014 10:31:56 -0800 (PST) Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id EE6CE2CA24; Fri, 7 Feb 2014 10:31:55 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 7 Feb 2014 10:30:15 -0800 Message-ID: <008401cf2432$a6644e70$f32ceb50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01CF23EF.98441BB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kLW8KAhQ9LkffT2ucYYJTmRRjOA== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Issue #121 - Section 7.2 JWS JSON Serialization X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 18:31:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0085_01CF23EF.98441BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is an improvement over the previous version, however there are a number of changes that can be done to make things better. 1. Move the requirement language into the list. Thus "This member MUST be present." Should be part of the payload and signatures and signature list items and the separate paragraph can be removed 2. Suggested text for signatures element: The type of this element is an array of objects. Each object represents a separate signature or MAC computation over the payload. This element MUST be present. The following members are defined for the JSON object for each signature: contains the value BAES64URL(UTF8(JWS Protected Header)). The value MUST be absent if there is no protected header. contains a JSON object. The member of the object consist of the unprotected header name/value pairs. This value MUST be absent if there are no unprotected header members. contains the value BASE64URL(JWS Signature). This value MUST be present. 3. A note that one of protected and header will be present because the alg header parameter is required could be added, but I don't know that it is really necessary. 4. If the paragraph starting with "The contents of the JWS Payload and JWS Signature values are" is required here, then it should also be in section 7.1 5. I don't understand what the paragraph starting with "Each JWS Signature value is computed on the JWS Signing Input" is trying to say. I think it could probably be said in a clearer and terser manner however. ------=_NextPart_000_0085_01CF23EF.98441BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is an = improvement over the previous version, however there are a number of = changes that can be done to make things better.

 

1.       =  Move the  requirement language into = the list.  Thus “This member MUST be present.” Should = be part of the payload and signatures and signature list items and the = separate paragraph can be removed

2.       = Suggested text for signatures element: =

<t hangText=3D”signatures”/>The type of this = element is an array of objects.  Each object represents a separate = signature or MAC computation over the payload.  This element MUST = be present.
<vspace line=3D”1”/>
The following = members are defined for the JSON object for each signature:
<list = style=3D”hanging”/>

<t = hangText=3D”protected”>contains the value = BAES64URL(UTF8(JWS Protected Header)).  The value MUST be absent if = there is no protected header.</t>

<t = hangText=3D”header”>contains a JSON object.  The = member of the object consist of the unprotected header name/value = pairs.  This value MUST be absent if there are no unprotected = header members.</t>

<t = hangText=3D”signature”>contains the value BASE64URL(JWS = Signature).  This value MUST be present.

</list>

</t>

 

3.       A = note that one of protected and header will be present because the alg = header parameter is required could be added, but I don’t know that = it is really necessary.

4.  If =
the paragraph starting with “The contents of the JWS Payload and =
JWS Signature values are” is required here, then it should also be =
in section 7.1
5.  I =
don’t understand what the paragraph starting with “Each JWS =
Signature value is computed on the JWS Signing Input” is trying to =
say.  I think it could probably be said in a clearer and terser =
manner =
however.
 
 
------=_NextPart_000_0085_01CF23EF.98441BB0-- From ietf@augustcellars.com Fri Feb 7 11:42:20 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4931ACCE8 for ; Fri, 7 Feb 2014 11:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96lZ-mrIXkZs for ; Fri, 7 Feb 2014 11:42:17 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32C861A0420 for ; Fri, 7 Feb 2014 11:42:17 -0800 (PST) Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 891472C9C5; Fri, 7 Feb 2014 11:42:16 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 7 Feb 2014 11:40:37 -0800 Message-ID: <00a701cf243c$7a061390$6e123ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CF23F9.6BE5E0D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kMuInu3Nae2teSpS0dLfg13yDfg== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Issue #178 - JWE JSON Serialization X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:42:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A8_01CF23F9.6BE5E0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is improved over the last version, however there are still some issues to be addressed: 1. The description of unprotected is incorrect. It describes the contents as being both a string an and object. 2. For aad - the note should be moved to the initial description of JWE AAD and not placed here. (Alternatively it should be in the compact serialization since it is an issue there not here.) 3. See the re-write in the JWS that I suggested. I find the current text to be very difficult to read for header and encrypted_key. 4. Move MUST be present text into each member description. 5. The sentence "The . members MUST be present when . are non-empty." can be removed. This is not adding any content. 6. Several of the MUST be present statements can be simplified. For example - in recipients - This array MUST be absent if the number of elements would be zero. Moving this into the individual elements should help sharpen this text. 7. The paragraph starting with "Not all Header Parameters are." should be moved to the description of the header parameters and not buried here. 8. The paragraph starting "The Header Parameter values." needs to be cleaned up. On the first reading I assumed that all of the per-recipient unprotected header values would be in the union and I know this is wrong. 9. The paragraph starting "The contents of the ." should either be removed or duplicated in section 7.1 10. The paragraph starting "All recipients.." can be deleted - all of this is implicit in the how do you encrypt section. ------=_NextPart_000_00A8_01CF23F9.6BE5E0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is = improved over the last version, however there are still some issues to = be addressed:

 

1.       The = description of unprotected is incorrect.  It describes the contents = as being both a string an and object.

2.       For = aad – the note should be moved to the initial description of JWE = AAD and not placed here.  (Alternatively it should be in the = compact serialization since it is an issue there not = here.)

3.       See = the re-write in the JWS that I suggested.  I find the current text = to be very difficult to read for header and = encrypted_key.

4.       = Move MUST be present text into each member = description.

5.       The = sentence “The … members MUST be present when … are = non-empty.” can be removed.  This is not adding any = content.

6.       = Several of the MUST be present statements can be = simplified.  For example – in recipients – This array = MUST be absent if the number of elements would be zero.  Moving = this into the individual elements should help sharpen this = text.

7.       The = paragraph starting with “Not all Header Parameters = are…” should be moved to the description of the header = parameters and not buried here.

8.       The = paragraph starting “The Header Parameter values…” = needs to be cleaned up.  On the first reading I assumed that all of = the per-recipient unprotected header values would be in the union and I = know this is wrong.

9.       The = paragraph starting “The contents of the …” should = either be removed or duplicated in section 7.1

10.   = The paragraph starting “All = recipients..” can be deleted – all of this is implicit in = the how do  you encrypt section.

 

 

 

------=_NextPart_000_00A8_01CF23F9.6BE5E0D0-- From ietf@augustcellars.com Fri Feb 7 14:16:00 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84A1A0514 for ; Fri, 7 Feb 2014 14:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlfkLIVCM74G for ; Fri, 7 Feb 2014 14:15:58 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF66E1A021E for ; Fri, 7 Feb 2014 14:15:57 -0800 (PST) Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 56DE02C9FD for ; Fri, 7 Feb 2014 14:15:57 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 7 Feb 2014 14:14:17 -0800 Message-ID: <00d301cf2451$f1eb6300$d5c22900$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01CF240E.E3CB3040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kQEcqgfgwtF27TKCQMnD+74lR9w== Content-Language: en-us Subject: [jose] Issue #90 - Section 9 References X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:16:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D4_01CF240E.E3CB3040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'll start with a quote from the RFC Editor "Instructions to Request for Comments (RFC) Authors" Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it provides only additional information. For example, an informative reference might provide background or historical information. Material in an informative reference is not required to implement the technology in the RFC. Based on the above criteria, there are a number of references which I believe are not in the correct bucket. I would ask the authors to review this prior to WGLC ending and re-evaluate based on the above criteria Examples of things that I think are misplaced: Algorithms draft - - RFC 5116 - this reference is going to disappear since it is just used in the changes section. - RFC 5226 - Don't know why implementers would ever care about this - McGrew-aed-aes-cbc-hmac-sha2 - you need to know how to do this in order to implement - thus it should be normative Signature Draft - Some of the drafts here are not reference in long term text Is ECMAScript something that needs to be understood? Is 3986 really a normative reference? ------=_NextPart_000_00D4_01CF240E.E3CB3040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I’ll start with a =
quote from the RFC Editor “Instructions to Request for Comments =
(RFC) Authors”

 

Normative = references specify documents that must be read to understand or = implement the technology in the new RFC, or whose technology must be = present for the technology in the new RFC to work.  An informative = reference is not normative; rather, it provides only additional = information. For example, an informative reference might provide = background or historical information.  Material in an informative = reference is not required to implement the technology in the = RFC.

 

Based on the above criteria, there are a number of = references which I believe are not in the correct bucket.  I would = ask the authors to review this prior to WGLC ending and re-evaluate = based on the above criteria

 

Examples of = things that I think are misplaced:

 

Algorithms = draft –

-          = RFC 5116 – this reference is going to = disappear since it is just used in the changes section.

-          = RFC 5226 – Don’t know why = implementers would ever care about this

-          = McGrew-aed-aes-cbc-hmac-sha2 – you need to = know how to do this in order to implement – thus it should be = normative

 

Signature Draft

-          = Some of the drafts here are not reference in = long term text

 

Is = ECMAScript something that needs to be understood?

Is 3986 really a normative reference?

 

------=_NextPart_000_00D4_01CF240E.E3CB3040-- From Michael.Jones@microsoft.com Fri Feb 7 15:40:22 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622271AD682 for ; Fri, 7 Feb 2014 15:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgjcJhJGsD2Y for ; Fri, 7 Feb 2014 15:40:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 590B81A0566 for ; Fri, 7 Feb 2014 15:40:18 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB426.namprd03.prod.outlook.com (10.141.141.140) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 7 Feb 2014 23:40:16 +0000 Received: from BY2PR03CA079.namprd03.prod.outlook.com (10.141.249.52) by BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) with Microsoft SMTP Server (TLS) id 15.0.868.8; Fri, 7 Feb 2014 23:40:15 +0000 Received: from BN1AFFO11FD057.protection.gbl (2a01:111:f400:7c10::109) by BY2PR03CA079.outlook.office365.com (2a01:111:e400:2c5d::52) with Microsoft SMTP Server (TLS) id 15.0.859.15 via Frontend Transport; Fri, 7 Feb 2014 23:40:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD057.mail.protection.outlook.com (10.58.53.72) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Fri, 7 Feb 2014 23:40:14 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0174.002; Fri, 7 Feb 2014 23:39:42 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Issue #90 - Section 9 References Thread-Index: Ac8kQEcqgfgwtF27TKCQMnD+74lR9wAGwBBg Date: Fri, 7 Feb 2014 23:39:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B189C26@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <00d301cf2451$f1eb6300$d5c22900$@augustcellars.com> In-Reply-To: <00d301cf2451$f1eb6300$d5c22900$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B189C26TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(377454003)(5383001)(71186001)(49866001)(66066001)(65816001)(80022001)(20776003)(69226001)(16236675002)(86362001)(19300405004)(94316002)(93136001)(87266001)(81342001)(94946001)(85306002)(93516002)(54316002)(56776001)(81542001)(84326002)(76482001)(54356001)(74706001)(55846006)(47736001)(47976001)(50986001)(15202345003)(4396001)(74366001)(51856001)(53806001)(74876001)(46102001)(31966008)(74502001)(74662001)(79102001)(63696002)(80976001)(33656001)(77982001)(59766001)(2656002)(87936001)(76796001)(77096001)(83322001)(19580405001)(44976005)(6806004)(19580395003)(81686001)(47446002)(81816001)(15975445006)(512954002)(85852003)(83072002)(86612001)(95416001)(76786001)(92726001)(92566001)(56816005)(90146001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB128; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:DE76D495.ACD6D5D1.78C37F67.46ECDA7D.203C8; InfoDomainNonexistentA:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 011579F31F X-OriginatorOrg: microsoft.com Subject: Re: [jose] Issue #90 - Section 9 References X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 23:40:22 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B189C26TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 5116 is used in the JWA security considerations. I believe that securi= ty considerations are normative, correct? (RESPONSE TO THIS QUESTION REQUE= STED) Otherwise this can be moved to the set of informative references. The "Specification Required" in RFC 5226 is required to be understood by pe= ople registering registry values, and therefore seems normative to me - at = least for those using the registry. This imposes a normative requirement o= n specification writers. draft-mcgrew-aead-aes-cbc-hmac-sha2 is definitely not required by implement= ers, since all the relevant normative content has been copied into JWA. Th= e reference is there for background or historical reasons only - clearly fi= tting the criteria for informative references. In fact, the draft appears = to have been abandoned - having expired, despite specific requests for spec= ific changes that would make it more JOSE-friendly having been communicated= to the author quite a while ago. What specific references in JWS do you believe will not be present in the f= inal text? If the will not be present in the final text, I agree that they= should be non-normative. Yes, section 15.12 (The JSON Object) of ECMAScript must be understood by im= plementers, since it specifies the "lexically last duplicate member name" s= emantics, which are required by JOSE. RFC 3986 defines URI and the specs use URIs - therefore I believe that this= is a normative reference. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 2:14 PM To: jose@ietf.org Subject: [jose] Issue #90 - Section 9 References I'll start with a quote from the RFC Editor "Instructions to Request for Co= mments (RFC) Authors" Normative references specify documents that must be read to understand or i= mplement the technology in the new RFC, or whose technology must be present= for the technology in the new RFC to work. An informative reference is no= t normative; rather, it provides only additional information. For example, = an informative reference might provide background or historical information= . Material in an informative reference is not required to implement the te= chnology in the RFC. Based on the above criteria, there are a number of references which I belie= ve are not in the correct bucket. I would ask the authors to review this p= rior to WGLC ending and re-evaluate based on the above criteria Examples of things that I think are misplaced: Algorithms draft - - RFC 5116 - this reference is going to disappear since it is just= used in the changes section. - RFC 5226 - Don't know why implementers would ever care about thi= s - McGrew-aed-aes-cbc-hmac-sha2 - you need to know how to do this i= n order to implement - thus it should be normative Signature Draft - Some of the drafts here are not reference in long term text Is ECMAScript something that needs to be understood? Is 3986 really a normative reference? --_000_4E1F6AAD24975D4BA5B16804296739438B189C26TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 5116 is used in th= e JWA security considerations.  I believe that security considerations= are normative, correct?  (RESPONSE TO THIS QUESTION REQUESTED)  = Otherwise this can be moved to the set of informative references.

 

The “Specificati= on Required” in RFC 5226 is required to be understood by people regis= tering registry values, and therefore seems normative to me – at leas= t for those using the registry.  This imposes a normative requirement on specification writers.

 

draft-mcgrew-aead-aes-= cbc-hmac-sha2 is definitely not required by implementers, since all the rel= evant normative content has been copied into JWA.  The reference is th= ere for background or historical reasons only – clearly fitting the criteria for informative references. = ; In fact, the draft appears to have been abandoned – having expired,= despite specific requests for specific changes that would make it more JOS= E-friendly having been communicated to the author quite a while ago.

 

What specific referenc= es in JWS do you believe will not be present in the final text?  If th= e will not be present in the final text, I agree that they should be non-no= rmative.

 

Yes, section 15.12 (Th= e JSON Object) of ECMAScript must be understood by implementers, since it s= pecifies the “lexically last duplicate member name” semantics, = which are required by JOSE.

 

RFC 3986 defines URI a= nd the specs use URIs – therefore I believe that this is a normative = reference.

 

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

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 2:14 PM
To: jose@ietf.org
Subject: [jose] Issue #90 - Section 9 References

 

I’ll start with a quote from the RFC Editor “Instructions =
to Request for Comments (RFC) Authors”

 

Normative references specify documents that must be read t= o understand or implement the technology in the new RFC, or whose technolog= y must be present for the technology in the new RFC to work.  An informative reference is not normative; rather, it p= rovides only additional information. For example, an informative reference = might provide background or historical information.  Material in an in= formative reference is not required to implement the technology in the RFC.

 

Based on the above criteria, there are a number of r= eferences which I believe are not in the correct bucket.  I would ask = the authors to review this prior to WGLC ending and re-evaluate based on th= e above criteria

 

Examples of things that I think are misplaced:<= /o:p>

 

Algorithms draft –

-     &= nbsp;    RFC 5116 – this reference is going to disappe= ar since it is just used in the changes section.

-     &= nbsp;    RFC 5226 – Don’t know why implementers = would ever care about this

-     &= nbsp;    McGrew-aed-aes-cbc-hmac-sha2 – you need to kn= ow how to do this in order to implement – thus it should be normative=

 

Signature Draft

-     &= nbsp;    Some of the drafts here are not reference in long t= erm text

 

Is ECMAScript something that needs to be understood?=

Is 3986 really a normative reference?

 

--_000_4E1F6AAD24975D4BA5B16804296739438B189C26TK5EX14MBXC288r_-- From Michael.Jones@microsoft.com Fri Feb 7 16:33:52 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02651AD8DA for ; Fri, 7 Feb 2014 16:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VISCZJNnlrY5 for ; Fri, 7 Feb 2014 16:33:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id B34721A051A for ; Fri, 7 Feb 2014 16:33:49 -0800 (PST) Received: from DM2PR03CA005.namprd03.prod.outlook.com (10.141.52.153) by DM2PR03MB383.namprd03.prod.outlook.com (10.141.55.17) with Microsoft SMTP Server (TLS) id 15.0.873.15; Sat, 8 Feb 2014 00:33:48 +0000 Received: from BL2FFO11FD042.protection.gbl (2a01:111:f400:7c09::108) by DM2PR03CA005.outlook.office365.com (2a01:111:e400:2414::25) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Sat, 8 Feb 2014 00:33:48 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD042.mail.protection.outlook.com (10.173.161.138) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 8 Feb 2014 00:33:48 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0174.002; Sat, 8 Feb 2014 00:33:20 +0000 From: Mike Jones To: Matt Miller Thread-Topic: [jose] PBE salt should include alg id Thread-Index: Ac7cHLJnGKhPO+FXRQOSbPZhHYsMrBByoyuAAA4Qt4AAJMTEgAFsIV3A Date: Sat, 8 Feb 2014 00:33:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B189EBF@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11536158EAB@WSMSG3153V.srv.dir.telstra.com> <52EA96BD.1070000@cisco.com> <255B9BB34FB7D647A506DC292726F6E11539FEE229@WSMSG3153V.srv.dir.telstra.com> <52EBEBE1.9060009@cisco.com> In-Reply-To: <52EBEBE1.9060009@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(377454003)(479174003)(199002)(189002)(517040?= =?us-ascii?Q?05)(54524002)(13464003)(24454002)(76482001)(80022001)(439600?= =?us-ascii?Q?1)(54356001)(33656001)(65816001)(50986001)(47976001)(4773600?= =?us-ascii?Q?1)(49866001)(53806001)(51856001)(81816001)(77096001)(7679600?= =?us-ascii?Q?1)(81686001)(92566001)(66066001)(92726001)(46102001)(1597544?= =?us-ascii?Q?5006)(20776003)(47776003)(74706001)(23726002)(69226001)(6369?= =?us-ascii?Q?6002)(79102001)(50466002)(81342001)(81542001)(74366001)(7487?= =?us-ascii?Q?6001)(87266001)(76786001)(59766001)(83072002)(85852003)(7798?= =?us-ascii?Q?2001)(55846006)(90146001)(56816005)(15202345003)(31966008)(7?= =?us-ascii?Q?4662001)(56776001)(54316002)(2656002)(85306002)(47446002)(93?= =?us-ascii?Q?136001)(87936001)(74502001)(86362001)(46406003)(93516002)(94?= =?us-ascii?Q?946001)(86612001)(19580405001)(83322001)(19580395003)(575784?= =?us-ascii?Q?001)(44976005)(95416001)(6806004)(94316002)(80976001);DIR:OU?= =?us-ascii?Q?T;SFP:1101;SCL:1;SRVR:DM2PR03MB383;H:mail.microsoft.com;CLIP?= =?us-ascii?Q?:131.107.125.37;FPR:3E4EF1FD.83F0404D.33D1BDBF.65BE1B2.2062B?= =?us-ascii?Q?;InfoDomainNonexistentA:1;MX:1;LANG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01165471DB X-OriginatorOrg: microsoft.com Cc: "" Subject: Re: [jose] PBE salt should include alg id X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 00:33:52 -0000 Hi Matt, Since no one has objected to the breaking change, could you please update t= he example PBE computation in http://tools.ietf.org/html/draft-ietf-jose-js= on-web-key-20#appendix-C to use a salt value that is the concatenation of (= the UTF-8 "alg" value "PBES2-HS256+A128KW" || 0x00 || base64url_decode(p2s)= ) and send me the step-by-step results to include in the -21 versions of th= e specs? Ideally, only the salt value used would change from the current e= xample. Also, if you could also send me the intermediate result from the PBES2-HS25= 6 computation, before applying A128KW, I'd like to include that in the exam= ple as well, since it might help implementers when trying to reproduce the = result. Thanks a bunch, -- Mike -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Matt Miller Sent: Friday, January 31, 2014 10:31 AM To: Manger, James; Subject: Re: [jose] PBE salt should include alg id -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 1/30/14, 5:58 PM, Manger, James wrote: >> On 11/7/13, 5:51 PM, Manger, James H wrote: >>> JWA section 4.9 ?Key Encryption with PBES2? should follow the=20 >>> recommendation of the PBES2 spec [RFC 2898 section 4.1 ?Salt?] by=20 >>> including in the salt ?data that explicitly distinguishes between=20 >>> different operations and different key lengths?. >>>=20 >>> We can do this quite easily in JWA by including the alg value (eg=20 >>> ?PBES2-HS384+A192KW?) in the salt. I suggest: >>>=20 >>> salt =3D UTF8(alg) || 0x00 || BASE64URL_DECODE(p2s) >=20 >=20 > Matt replied: >> When I read and interpreted that section, it came across as a=20 >> consideration for applications using PBES2 in JOSE. I probably=20 >> should have pointed that out in my initial work on this. C'est la=20 >> vie. >>=20 >> That said, I personally don't have a problem with this change.=20 >> However, it does break existing implementations. Given the stage=20 >> these drafts are in, it might be less disruptive to include=20 >> considerations and recommendations for applications. >=20 >=20 > Matt, >=20 > I'm not sure what you mean by "include considerations and=20 > recommendations for applications". Do you mean JWA section 4.8.1.1. > "p2s (PBES2 salt) Parameter" should say: "A salt MUST include 8 or=20 > more random octets, and can include the "alg" value" >=20 > I don't think that helps. The issue is that the JOSE *recipient* needs=20 > to ensure the correct "alg" value is in the salt. >=20 > Or are you suggesting app-specific profiles of JOSE can add a > requirement: "A salt MUST include the "alg" value and 8 or more random=20 > octets. A recipient MUST confirm that the "p2s" value (after > base64url-decoding) starts with the "alg" value." >=20 > That would theoretically work, except that it adds about 30 bytes to=20 > messages, is easily ignored, and is awkward to implement as it=20 > requires an app-specific rule to be enforced deep inside app-agnostic=20 > JOSE libraries. >=20 > "p2s" has only been in the drafts for 6 months. Can't we fix it=20 > properly? >=20 > -- James Manger >=20 I was suggesting that app-specific profiles can add a requirement, as suits= their needs -- maybe it's what you wrote, maybe it's something else. That= 's why I think there's two parts to that section in RFC 2898. I don't think it requires app-agnostic libraries to enforce. It does requi= re the application to enforce it's own policies, although how awkward it is= depends on how accessible this information out of the JOSE library. But this might all be moot if no one objects to the breaking change. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS6+vhAAoJEDWi+S0W7cO1r3QIAJg84Jfbn2XLs/n71arXAd/x kF6+pAVlJYxHjbxL5mp9KRHjNiA56XrncnFoeQs2pgFnnexpDB9EXNiVyxR75mG6 BKYZB8T/cGADW8gv9f6yu4PyoZeyM76qhXzMoOVeXIEKrNQNg+pBUtv/wLATs6Qq I2K4r2LlaopVy1gwkhlsKsU/x2dWZVSXCgqwwxGXZVpXmKTp5TY1XoFhTS+Lk2OC hHDLbvkxGrlKKHofLaTDc+K77NGt40uHgnhJ+3CVGeu8PU9dZB3YbukrDf3PSh7A bdGkqGoMWOB72+cdav3kXPITfQFEB5IffVT2xG8O0pdfT6zU0+UbO25Xq6u+R3A=3D =3DdJsJ -----END PGP SIGNATURE----- _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Fri Feb 7 16:35:59 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53121A0574 for ; Fri, 7 Feb 2014 16:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDeQXGcFMLeW for ; Fri, 7 Feb 2014 16:35:56 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0B91A051A for ; Fri, 7 Feb 2014 16:35:56 -0800 (PST) Received: from Philemon (50-39-223-207.bvtn.or.frontiernet.net [50.39.223.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 6546A2CA57; Fri, 7 Feb 2014 16:35:55 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" , References: <00d301cf2451$f1eb6300$d5c22900$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B189C26@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B189C26@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Fri, 7 Feb 2014 16:34:15 -0800 Message-ID: <00ff01cf2465$7f9016c0$7eb04440$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0100_01CF2422.716FE400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCzg2NGcA/DlTxVMpKzvnUIqaRrCAH0MdUGnNIaUGA= Content-Language: en-us Subject: Re: [jose] Issue #90 - Section 9 References X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 00:36:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0100_01CF2422.716FE400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 3:40 PM To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Issue #90 - Section 9 References RFC 5116 is used in the JWA security considerations. I believe that security considerations are normative, correct? (RESPONSE TO THIS QUESTION REQUESTED) Otherwise this can be moved to the set of informative references. [JLS] No they are not considered normative. They can be either normative or informative depending on what and how much of the document needs to be understood in order to correctly implement the current protocol. It is always a value judgment. The "Specification Required" in RFC 5226 is required to be understood by people registering registry values, and therefore seems normative to me - at least for those using the registry. This imposes a normative requirement on specification writers. [JLS] So - do I need to understand RFC 5226 in order to either understand or implement JOSE? draft-mcgrew-aead-aes-cbc-hmac-sha2 is definitely not required by implementers, since all the relevant normative content has been copied into JWA. The reference is there for background or historical reasons only - clearly fitting the criteria for informative references. In fact, the draft appears to have been abandoned - having expired, despite specific requests for specific changes that would make it more JOSE-friendly having been communicated to the author quite a while ago. [JLS] In that case - why have the reference at all? What specific references in JWS do you believe will not be present in the final text? If the will not be present in the final text, I agree that they should be non-normative. Yes, section 15.12 (The JSON Object) of ECMAScript must be understood by implementers, since it specifies the "lexically last duplicate member name" semantics, which are required by JOSE. [JLS] And you have stated that explicitly in the document - so why make the reference at all - except to say that this is the same thing they do? That is not normative. RFC 3986 defines URI and the specs use URIs - therefore I believe that this is a normative reference. [JLSJ] In order to implement JOSE - do I need to understand all of the details of URIs or can I just treat them as opaque strings? -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 2:14 PM To: jose@ietf.org Subject: [jose] Issue #90 - Section 9 References I'll start with a quote from the RFC Editor "Instructions to Request for Comments (RFC) Authors" Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it provides only additional information. For example, an informative reference might provide background or historical information. Material in an informative reference is not required to implement the technology in the RFC. Based on the above criteria, there are a number of references which I believe are not in the correct bucket. I would ask the authors to review this prior to WGLC ending and re-evaluate based on the above criteria Examples of things that I think are misplaced: Algorithms draft - - RFC 5116 - this reference is going to disappear since it is just used in the changes section. - RFC 5226 - Don't know why implementers would ever care about this - McGrew-aed-aes-cbc-hmac-sha2 - you need to know how to do this in order to implement - thus it should be normative Signature Draft - Some of the drafts here are not reference in long term text Is ECMAScript something that needs to be understood? Is 3986 really a normative reference? ------=_NextPart_000_0100_01CF2422.716FE400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = February 07, 2014 3:40 PM
To: Jim Schaad; = jose@ietf.org
Subject: RE: [jose] Issue #90 - Section 9 = References

 

RFC 5116 is used in the JWA security = considerations.  I believe that security considerations are = normative, correct?  (RESPONSE TO THIS QUESTION REQUESTED)  = Otherwise this can be moved to the set of informative = references.

 

[JLS] No they are not = considered normative.  They can be either normative or informative = depending on what and how much of the document needs to be understood in = order to correctly implement the current protocol.  It is always a = value judgment.

 

The “Specification = Required” in RFC 5226 is required to be understood by people = registering registry values, and therefore seems normative to me – = at least for those using the registry.  This imposes a normative = requirement on specification writers.

 

[JLS] So – do I = need to understand RFC 5226 in order to either understand or implement = JOSE?

 

draft-mcgrew-aead-aes-cbc-hmac-sha2 is = definitely not required by implementers, since all the relevant = normative content has been copied into JWA.  The reference is there = for background or historical reasons only – clearly fitting the = criteria for informative references.  In fact, the draft appears to = have been abandoned – having expired, despite specific requests = for specific changes that would make it more JOSE-friendly having been = communicated to the author quite a while ago.

[JLS] In that case = – why have the reference at all?

 

What specific references = in JWS do you believe will not be present in the final text?  If = the will not be present in the final text, I agree that they should be = non-normative.

 

Yes, section 15.12 (The = JSON Object) of ECMAScript must be understood by implementers, since it = specifies the “lexically last duplicate member name” = semantics, which are required by JOSE.

[JLS] And you have = stated that explicitly in the document – so why make the reference = at all – except to say that this is the same thing they do? That = is not normative.

 

RFC 3986 defines URI and = the specs use URIs – therefore I believe that this is a normative = reference.

[JLSJ] In order to implement JOSE – do I = need to understand all of the details of URIs or can I just treat them = as opaque strings?

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike

 

From:= = jose [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 = 2:14 PM
To: jose@ietf.org
Subject: = [jose] Issue #90 - Section 9 = References

 

I’ll start with a =
quote from the RFC Editor “Instructions to Request for Comments =
(RFC) Authors”

 

Normative = references specify documents that must be read to understand or = implement the technology in the new RFC, or whose technology must be = present for the technology in the new RFC to work.  An informative = reference is not normative; rather, it provides only additional = information. For example, an informative reference might provide = background or historical information.  Material in an informative = reference is not required to implement the technology in the = RFC.

 

Based on the above criteria, there are a number of = references which I believe are not in the correct bucket.  I would = ask the authors to review this prior to WGLC ending and re-evaluate = based on the above criteria

 

Examples of = things that I think are misplaced:

 

Algorithms = draft –

-          = RFC 5116 – this reference is going to = disappear since it is just used in the changes section.

-          = RFC 5226 – Don’t know why = implementers would ever care about this

-          = McGrew-aed-aes-cbc-hmac-sha2 – you need to = know how to do this in order to implement – thus it should be = normative

 

Signature Draft

-          = Some of the drafts here are not reference in = long term text

 

Is = ECMAScript something that needs to be understood?

Is 3986 really a normative reference?

 

------=_NextPart_000_0100_01CF2422.716FE400-- From Michael.Jones@microsoft.com Fri Feb 7 16:46:55 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1822C1AD8E1 for ; Fri, 7 Feb 2014 16:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4zFPhWYl0oN for ; Fri, 7 Feb 2014 16:46:50 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) by ietfa.amsl.com (Postfix) with ESMTP id 518221A056C for ; Fri, 7 Feb 2014 16:46:50 -0800 (PST) Received: from BLUPR03CA032.namprd03.prod.outlook.com (10.141.30.25) by BLUPR03MB003.namprd03.prod.outlook.com (10.255.208.37) with Microsoft SMTP Server (TLS) id 15.0.868.8; Sat, 8 Feb 2014 00:46:47 +0000 Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:172) by BLUPR03CA032.outlook.office365.com (2a01:111:e400:879::25) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Sat, 8 Feb 2014 00:46:48 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 8 Feb 2014 00:46:47 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Sat, 8 Feb 2014 00:46:18 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Issue #90 - Section 9 References Thread-Index: Ac8kQEcqgfgwtF27TKCQMnD+74lR9wAGwBBgAAKNxoAAACBoEA== Date: Sat, 8 Feb 2014 00:46:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B189F1C@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <00d301cf2451$f1eb6300$d5c22900$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B189C26@TK5EX14MBXC288.redmond.corp.microsoft.com> <00ff01cf2465$7f9016c0$7eb04440$@augustcellars.com> In-Reply-To: <00ff01cf2465$7f9016c0$7eb04440$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B189F1CTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(57704003)(189002)(199002)(5383001)(377454003)(19300405004)(20776003)(94946001)(74706001)(79102001)(80976001)(47446002)(81542001)(93136001)(77096001)(74502001)(47976001)(74662001)(76786001)(33656001)(76796001)(6806004)(74366001)(49866001)(47736001)(50986001)(63696002)(15202345003)(19580405001)(4396001)(19580395003)(83322001)(77982001)(59766001)(83072002)(92726001)(44976005)(92566001)(55846006)(86612001)(85852003)(31966008)(90146001)(80022001)(65816001)(66066001)(94316002)(95416001)(74876001)(56816005)(69226001)(51856001)(85306002)(87266001)(2656002)(81816001)(71186001)(16236675002)(15975445006)(76482001)(54316002)(512954002)(56776001)(53806001)(54356001)(46102001)(81686001)(84326002)(81342001)(87936001)(86362001)(93516002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB003; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:DE7ED465.ACD6D191.B8F3B58B.4AACDA7D.204E6; InfoDomainNonexistentMX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01165471DB X-OriginatorOrg: microsoft.com Subject: Re: [jose] Issue #90 - Section 9 References X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 00:46:55 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B189F1CTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline marked [mbj]... From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 4:34 PM To: Mike Jones; jose@ietf.org Subject: Re: [jose] Issue #90 - Section 9 References From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 3:40 PM To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Issue #90 - Section 9 References RFC 5116 is used in the JWA security considerations. I believe that securi= ty considerations are normative, correct? (RESPONSE TO THIS QUESTION REQUE= STED) Otherwise this can be moved to the set of informative references. [JLS] No they are not considered normative. They can be either normative o= r informative depending on what and how much of the document needs to be un= derstood in order to correctly implement the current protocol. It is alway= s a value judgment. [mbj] OK, if the security consideration references aren't normative, I'll m= ove them to the Informative References section. The "Specification Required" in RFC 5226 is required to be understood by pe= ople registering registry values, and therefore seems normative to me - at = least for those using the registry. This imposes a normative requirement o= n specification writers. [JLS] So - do I need to understand RFC 5226 in order to either understand o= r implement JOSE? [mbj] If the criteria is only normative requirements on implementers, versu= s normative requirements on people using the registries defined, I'll move = them to the Informative References section. draft-mcgrew-aead-aes-cbc-hmac-sha2 is definitely not required by implement= ers, since all the relevant normative content has been copied into JWA. Th= e reference is there for background or historical reasons only - clearly fi= tting the criteria for informative references. In fact, the draft appears = to have been abandoned - having expired, despite specific requests for spec= ific changes that would make it more JOSE-friendly having been communicated= to the author quite a while ago. [JLS] In that case - why have the reference at all? [mbj] To give credit where credit is due (and in hopes that David will even= tually apply the requested updates so we don't have to continue duplicating= the normative text). What specific references in JWS do you believe will not be present in the f= inal text? If the will not be present in the final text, I agree that they= should be non-normative. Yes, section 15.12 (The JSON Object) of ECMAScript must be understood by im= plementers, since it specifies the "lexically last duplicate member name" s= emantics, which are required by JOSE. [JLS] And you have stated that explicitly in the document - so why make the= reference at all - except to say that this is the same thing they do? That= is not normative. [mbj] This seems like a judgment call to me, since ECMASCript defines the "= lexically last duplicate member name semantics" and JOSE requires its use. = That seems normative to me, even if we paraphrase the requirement in the J= OSE specs. RFC 3986 defines URI and the specs use URIs - therefore I believe that this= is a normative reference. [JLSJ] In order to implement JOSE - do I need to understand all of the deta= ils of URIs or can I just treat them as opaque strings? [mbj] This seems like another judgment call. We're using URIs in normative= definitions, so a normative reference seems appropriate to me. What do ot= hers think in this case? -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 2:14 PM To: jose@ietf.org Subject: [jose] Issue #90 - Section 9 References I'll start with a quote from the RFC Editor "Instructions to Request for Co= mments (RFC) Authors" Normative references specify documents that must be read to understand or i= mplement the technology in the new RFC, or whose technology must be present= for the technology in the new RFC to work. An informative reference is no= t normative; rather, it provides only additional information. For example, = an informative reference might provide background or historical information= . Material in an informative reference is not required to implement the te= chnology in the RFC. Based on the above criteria, there are a number of references which I belie= ve are not in the correct bucket. I would ask the authors to review this p= rior to WGLC ending and re-evaluate based on the above criteria Examples of things that I think are misplaced: Algorithms draft - - RFC 5116 - this reference is going to disappear since it is just= used in the changes section. - RFC 5226 - Don't know why implementers would ever care about thi= s - McGrew-aed-aes-cbc-hmac-sha2 - you need to know how to do this i= n order to implement - thus it should be normative Signature Draft - Some of the drafts here are not reference in long term text Is ECMAScript something that needs to be understood? Is 3986 really a normative reference? --_000_4E1F6AAD24975D4BA5B16804296739438B189F1CTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Replies inline marked = [mbj]…

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 4:34 PM
To: Mike Jones; jose@ietf.org
Subject: Re: [jose] Issue #90 - Section 9 References

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Friday, February 07, 2014 3:40 PM
To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Issue #90 - Section 9 References

 

RFC 5116 is used in th= e JWA security considerations.  I believe that security considerations= are normative, correct?  (RESPONSE TO THIS QUESTION REQUESTED)  = Otherwise this can be moved to the set of informative references.

 

[JLS] No they are not = considered normative.  They can be either normative or informative dep= ending on what and how much of the document needs to be understood in order= to correctly implement the current protocol.  It is always a value judgment.

 

[mbj] OK, if the secur= ity consideration references aren’t normative, I’ll move them t= o the Informative References section.

 

The “Specificati= on Required” in RFC 5226 is required to be understood by people regis= tering registry values, and therefore seems normative to me – at leas= t for those using the registry.  This imposes a normative requirement on specification writers.

 

[JLS] So – do I = need to understand RFC 5226 in order to either understand or implement JOSE= ?

 

[mbj] If the criteria = is only normative requirements on implementers, versus normative requiremen= ts on people using the registries defined, I’ll move them to the Info= rmative References section.

 

draft-mcgrew-aead-aes-= cbc-hmac-sha2 is definitely not required by implementers, since all the rel= evant normative content has been copied into JWA.  The reference is th= ere for background or historical reasons only – clearly fitting the criteria for informative references. = ; In fact, the draft appears to have been abandoned – having expired,= despite specific requests for specific changes that would make it more JOS= E-friendly having been communicated to the author quite a while ago.

[JLS] In that case = 211; why have the reference at all?

 

[mbj] To give credit w= here credit is due (and in hopes that David will eventually apply the reque= sted updates so we don’t have to continue duplicating the normative t= ext).

 

What specific referenc= es in JWS do you believe will not be present in the final text?  If th= e will not be present in the final text, I agree that they should be non-no= rmative.

 

Yes, section 15.12 (Th= e JSON Object) of ECMAScript must be understood by implementers, since it s= pecifies the “lexically last duplicate member name” semantics, = which are required by JOSE.

[JLS] And you have sta= ted that explicitly in the document – so why make the reference at al= l – except to say that this is the same thing they do? That is not no= rmative.

 

[mbj] This seems like = a judgment call to me, since ECMASCript defines the “lexically last d= uplicate member name semantics” and JOSE requires its use.  That= seems normative to me, even if we paraphrase the requirement in the JOSE specs.

 

RFC 3986 defines URI a= nd the specs use URIs – therefore I believe that this is a normative = reference.

[JLSJ] In order to imp= lement JOSE – do I need to understand all of the details of URIs or c= an I just treat them as opaque strings?

 

[mbj] This seems like = another judgment call.  We’re using URIs in normative definition= s, so a normative reference seems appropriate to me.  What do others t= hink in this case?

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 2:14 PM
To: jose@ietf.org
Subject: [jose] Issue #90 - Section 9 References

 

I’ll start with a quote from the RFC Editor “Instructions =
to Request for Comments (RFC) Authors”

 

Normative references specify documents that must be read t= o understand or implement the technology in the new RFC, or whose technolog= y must be present for the technology in the new RFC to work.  An informative reference is not normative; rather, it p= rovides only additional information. For example, an informative reference = might provide background or historical information.  Material in an in= formative reference is not required to implement the technology in the RFC.

 

Based on the above criteria, there are a number of r= eferences which I believe are not in the correct bucket.  I would ask = the authors to review this prior to WGLC ending and re-evaluate based on th= e above criteria

 

Examples of things that I think are misplaced:<= /o:p>

 

Algorithms draft –

-     &= nbsp;    RFC 5116 – this reference is going to disappe= ar since it is just used in the changes section.

-     &= nbsp;    RFC 5226 – Don’t know why implementers = would ever care about this

-     &= nbsp;    McGrew-aed-aes-cbc-hmac-sha2 – you need to kn= ow how to do this in order to implement – thus it should be normative=

 

Signature Draft

-     &= nbsp;    Some of the drafts here are not reference in long t= erm text

 

Is ECMAScript something that needs to be understood?=

Is 3986 really a normative reference?

 

--_000_4E1F6AAD24975D4BA5B16804296739438B189F1CTK5EX14MBXC288r_-- From trac+jose@trac.tools.ietf.org Fri Feb 7 17:06:45 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5131A0475 for ; Fri, 7 Feb 2014 17:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MYWa1BWFIaN for ; Fri, 7 Feb 2014 17:06:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C90B11A01E6 for ; Fri, 7 Feb 2014 17:06:43 -0800 (PST) Received: from localhost ([127.0.0.1]:36124 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WBwNQ-0007Ih-SV; Sat, 08 Feb 2014 02:06:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, watsonm@netflix.com, michael.jones@microsoft.com, ietf@augustcellars.com X-Trac-Project: jose Date: Sat, 08 Feb 2014 01:06:36 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:6 Message-ID: <073.23ebeee071335ba528a4caa8dccfb8d2@trac.tools.ietf.org> References: <058.64f03fe454a282c927565cd8ad72d563@trac.tools.ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <058.64f03fe454a282c927565cd8ad72d563@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, watsonm@netflix.com, michael.jones@microsoft.com, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Cc: jose@ietf.org Subject: Re: [jose] #187: Allow registration of non-JWE/JWS algorithms for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 01:06:46 -0000 #187: Allow registration of non-JWE/JWS algorithms for JWK Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- watsonm@netflix.com | algorithms@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: json-web- | Version: algorithms | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From Michael.Jones@microsoft.com Fri Feb 7 18:05:02 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D781ACCEB for ; Fri, 7 Feb 2014 18:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-FEmCfmAqyB for ; Fri, 7 Feb 2014 18:04:56 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id A9CF31A01BC for ; Fri, 7 Feb 2014 18:04:56 -0800 (PST) Received: from BLUPR03CA035.namprd03.prod.outlook.com (10.141.30.28) by BLUPR03MB003.namprd03.prod.outlook.com (10.255.208.37) with Microsoft SMTP Server (TLS) id 15.0.868.8; Sat, 8 Feb 2014 02:04:55 +0000 Received: from BL2FFO11FD055.protection.gbl (2a01:111:f400:7c09::162) by BLUPR03CA035.outlook.office365.com (2a01:111:e400:879::28) with Microsoft SMTP Server (TLS) id 15.0.868.8 via Frontend Transport; Sat, 8 Feb 2014 02:04:55 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD055.mail.protection.outlook.com (10.173.161.183) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 8 Feb 2014 02:04:54 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0174.002; Sat, 8 Feb 2014 02:04:26 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Appendix D in draft -20 Thread-Index: Ac8YdVFWIkzAvGyyToOm/dHc3J4hWQL+/UKw Date: Sat, 8 Feb 2014 02:04:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> In-Reply-To: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B18A416TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(51914003)(377454003)(189002)(199002)(69226001)(74876001)(56816005)(87266001)(85306002)(51856001)(80022001)(65816001)(90146001)(95416001)(66066001)(94316002)(2656002)(54356001)(53806001)(86362001)(87936001)(93516002)(81686001)(84326002)(81342001)(46102001)(15975445006)(16236675002)(71186001)(81816001)(54316002)(512954002)(56776001)(76482001)(47976001)(74662001)(6806004)(74502001)(77096001)(33656001)(76796001)(76786001)(80976001)(47446002)(93136001)(81542001)(50986001)(47736001)(49866001)(74366001)(19300405004)(20776003)(79102001)(74706001)(94946001)(86612001)(92566001)(55846006)(31966008)(85852003)(19580395003)(4396001)(83322001)(19580405001)(15202345003)(63696002)(83072002)(44976005)(92726001)(77982001)(59766001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB003; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:EA63F1D5.A3325791.BDF3BD4B.42E4D931.205D2; InfoDomainNonexistentMX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01165471DB X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 02:05:02 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B18A416TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I've updated my working draft to attempt to address all of your comments be= low. Thanks for the thorough read - as always. Are there any specific rem= aining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms would typically include these steps: 1. Collect a set of potentially applicable keys. Sources of keys may incl= ude: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter= . o Other applicable keys available to the application. 2. Filter the set of collected keys. For instance, only keys referenced b= y kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might= be tried by the application. Keys with inappropriate alg (algorithm), use = (public key use), or key_ops (key operations) values would likewise typical= ly be excluded if the application uses those parameters. Keys might be filt= ered to include or exclude keys with certain other member values. For some = applications, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before other keys. Likewise, keys with certain member values might be o= rdered before keys with other member values. For some applications, no orde= ring will be applied. 4. Make trust decisions about the keys. Keys not meeting the application'= s trust criteria would not be used. Such criteria might include, but is not= limited to the source of the key, whether the TLS certificate validates fo= r keys retrieved from URLs, whether a key in an X.509 certificate is backed= by a valid certificate chain, and other information known by the applicati= on. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any wa= y optional in this algorithm. The concept of not gathering keys, filtering= out keys that cannot possibly be correct and not checking the signature of= keys makes absolutely no sense to me. If these steps are to be considered= optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain= would be eligible for inclusion in the key set. If this is not true then = it needs to clarified in the description of x5u. If it is true then s/keys= /key/ in that description. I need to have a much better understanding of the statement that you can or= der based on the value of the kty value. As it stands I have no idea what = this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to t= hose keys which are reasonable to look at rather than looking at the entire= building of keys. As part of this I would move the number of keys from cu= rrent step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algo= rithm), "use" (public key use), or "key_ops" (key operations) values = would likewise typically be excluded." Then you need to provide text = to tell me under what circumstances I would not be excluding them. My unde= rstanding is that they would always be excluded and thus this text makes no= sense to me. I would move the kty filter into the previous sentence. It them make sense= to talk about applications filtering based on other values that might be m= ore application specific. I would like to see the trust statement moved to a separate item in the lis= t of steps. Again this is something that needs to be done, but it can be d= one after step 4 rather than in the filter process. The trust statement ca= n be made to be more general that what is current stated. That is the trus= t decision may be made based on internal application information, generic i= nformation or an external certificate validation process. In some cases th= e trust decision may be determined to be implicit based on the source of th= e key. I would make this general rather than specific. That is to say I= would say that a binding of trust needs to be made, and the following item= s should be considered in the list of things to be included. This should n= ot and would not be presented as an exhaustive list but should be somewhat = complete. That is getting this from a jku has a degree of trust that a jkw= does not have. Jim --_000_4E1F6AAD24975D4BA5B16804296739438B18A416TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  Thank= s for the thorough read – as always.  Are there any specific rem= aining edits you’d like to see applied to the following text?

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms would typically include these steps= :

1.=    Collect a set of potenti= ally applicable keys. Sources of keys may include:

o    Keys supplied by the app= lication protocol being used.

o    Keys referenced by the jku (JWK Set URL) Header Parameter.

o    The key provided by the jwk (JSON Web Key) Header Parameter.

o    The key referenced by th= e x5u (X.509 URL) Header Parameter.

o    The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o    Other applicable keys av= ailable to the application.

2.=    Filter the set of collec= ted keys. For instance, only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might be t= ried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops= (key operations) values would likewise typically be ex= cluded if the application uses those parameters. Keys might be filtered to include or exclude keys with certain other member values. F= or some applications, no filtering will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before other keys. Likewise, keys with certain member values might be ordered before keys with other member values. For some applicatio= ns, no ordering will be applied.

4.=    Make trust decisions abo= ut the keys. Keys not meeting the application's trust criteria would not be= used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retr= ieved from URLs, whether a key in an X.509 certificate is backed by a valid= certificate chain, and other information known by the application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

 

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

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: draft-ietf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: [jose] Appendix D in draft -20

 

I am only marginally happier with this draft of the = document.

 

I do not see how one can possibly state that steps 1= , 3 and 4 are in any way optional in this algorithm.  The concept of n= ot gathering keys, filtering out keys that cannot possibly be correct and n= ot checking the signature of keys makes absolutely no sense to me.  If these steps are to be considered optio= nal then the reason for them being option must be clearly documented.<= /o:p>

 

My understanding of x5u says that only a single key = referenced by the chain would be eligible for inclusion in the key set.&nbs= p; If this is not true then it needs to clarified in the description of x5u= .  If it is true then s/keys/key/ in that description.

 

I need to have a much better understanding of the st= atement that you can order based on the value of the kty value.  As it= stands I have no idea what this means and why one would do such an orderin= g.

 

I would probably swap steps 2 and 3 so that one can = order with respect to those keys which are reasonable to look at rather tha= n looking at the entire building of keys.  As part of this I would mov= e the number of keys from current step 3 to step 4.

 

If you are going to make the statement “Keys=
 with inappropriate "alg" (algorithm), "use" (public ke=
y       use), or "key_ops" (key ope=
rations) values would likewise       typicall=
y be excluded.” Then you need to provide text to tell me=
 under what circumstances I would not be excluding them.  My understan=
ding is that they would always be excluded and thus this text makes no sens=
e to me.
 
I would move the kty filter into the previous sentence.&n=
bsp; It them make sense to talk about applications filtering based on other=
 values that might be more application specific.
 
I would like to see the trust statement moved to a separa=
te item in the list of steps.  Again this is something that needs to b=
e done, but it can be done after step 4 rather than in the filter process.&=
nbsp; The trust statement can be made to be more general that what is curre=
nt stated.  That is the trust decision may be made based on internal a=
pplication information, generic information or an external certificate vali=
dation process.  In some cases the trust decision may be determined to=
 be implicit based on the source of the key.    I would make=
 this general rather than specific.  That is to say I would say that a=
 binding of trust needs to be made, and the following items should be consi=
dered in the list of things to be included.  This should not and would=
 not be presented as an exhaustive list but should be somewhat complete.&nb=
sp; That is getting this from a jku has a degree of trust that a jkw does n=
ot have.
 
Jim
 
 

 

--_000_4E1F6AAD24975D4BA5B16804296739438B18A416TK5EX14MBXC288r_-- From jaredhanson@gmail.com Wed Feb 12 10:17:13 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378D81A0676 for ; Wed, 12 Feb 2014 10:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn9qgQawwtvm for ; Wed, 12 Feb 2014 10:17:10 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7560D1A0654 for ; Wed, 12 Feb 2014 10:17:10 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so6257233wes.40 for ; Wed, 12 Feb 2014 10:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pHzR+oN26tJKd55t0ijW29FKjHtZbzWhpzOEDxcOcMo=; b=fPGxLVfek2frG1MMsH2bnA+bvWHgRafn/yklE32haOwiYgjceYfnxZDpWIL6ImAJOF fCqYHOtEccbxihef3UdEU94amOIamEoqj6fYF6oc3BpywmKC9TLzp3AGdQHX0y1e7kDC 2HU6M5faQUWG8KAeXJc78ayGYVkPt6pLkm6BtOSFOePg0o6WHbu81blIjpwKdNZvhw9a +snda0VtpSQzoDpusD8r2OKL5KN52uSHDKmlrpfjAq+eO1of2kAsn1LxjLKth7VTCf2R 4xOoSVTRGjSXSFBmm+zTY0BhrMQhJOAiyZjvsonfm9Tv7sLOvvdbWZj/XmQtZnm4x8b3 ferg== MIME-Version: 1.0 X-Received: by 10.180.82.193 with SMTP id k1mr3203097wiy.15.1392229029162; Wed, 12 Feb 2014 10:17:09 -0800 (PST) Received: by 10.180.7.106 with HTTP; Wed, 12 Feb 2014 10:17:09 -0800 (PST) Date: Wed, 12 Feb 2014 10:17:09 -0800 Message-ID: From: Jared Hanson To: jose@ietf.org Content-Type: multipart/alternative; boundary=f46d044304b8badf3004f2399436 Subject: [jose] Correct use of jku claims in JWT/JWS bearer assertions X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 18:17:13 -0000 --f46d044304b8badf3004f2399436 Content-Type: text/plain; charset=ISO-8859-1 I'm wondering if there is any guidance on including "jku", "jwk", "x5u", and "x5c" claims in a JWT/JWS used as a bearer assertion for authentication. Specifically, in the case of service-to-service authentication, where the "iss" is set to the service acting as a client, say "https://client.example.net/" making a request to "https://api.example.com/", and the assertion is signed using client.example.net's private key. In this situation, api.example.com authenticates the assertion by finding the corresponding public key (possibly in a JWK set, the location of which can be obtained by something like OpenID Provider Configuration [1]). It is clear that any claims in the assertion are self-asserted until validated, including both the "iss" and any keys or URLs to keys. Thus, when a service validates the assertion, it *must not* use the values of "jku", etc to validate the signature. Instead it should use some trusted channel to obtain the keys directly from the issuer. If this were not done, a malicious entity could freely generate assertions claiming to be client.example.net, using any private key and including a malicious reference to its own public key using a "jku" set to " https://malicious.com/jwks.json" This security consideration is not called out anywhere that I've noticed, which I've seen leading to insecure implementations and/or bad examples. For example, this example on Gluu's wiki: http://ox.gluu.org/doku.php?id=oxauth:jwt is blindly using the value of "jku" to fetch the key used to validate the signature, without any way to validate that the URL itself belongs to the issuer. I'm raising this point hoping that guidance can be clarified and included in the specification. Thanks, Jared Hanson [1] http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig -- Jared Hanson --f46d044304b8badf3004f2399436 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm wondering if there is any guidance on includi= ng "jku", "jwk", "x5u", and "x5c"
claims in a JWT/JWS used as a bearer assertion for authentication.=

Specifically, in the case of service-to-service authent= ication, where the "iss" is
set to the service acting a= s a client, say "https://clien= t.example.net/" making a
request to "https://api.exam= ple.com/", and the assertion is signed using
client.example.net's private key.
<= div>
In this situation, api.ex= ample.com authenticates the assertion by finding the
correspo= nding public key (possibly in a JWK set, the location of which can be
obtained by something like OpenID Provider Configuration [1]).

It is clear that any claims in the assertion are self-ass= erted until validated,
including both the "iss" and any= keys or URLs to keys. =A0Thus, when a service
validates the assertion, it *must not* use the values of "jku&quo= t;, etc to validate
the signature. =A0Instead it should use some = trusted channel to obtain the keys
directly from the issuer.

If this were not done, a malicious entity could freely = generate assertions
claiming to be client.example.net, using any private key and including a malic= ious
reference to its own public key using a "jku" set to "<= a href=3D"https://malicious.com/jwks.json">https://malicious.com/jwks.json<= /a>"

This security consideration is not calle= d out anywhere that I've noticed, which
I've seen leading to insecure implementations and/or bad examples.= =A0For example,
this example on Gluu's wiki: http://ox.gluu.org/doku.php?id=3Do= xauth:jwt is blindly
using the value of "jku" to fetch the key used to validate t= he signature, without
any way to validate that the URL itself bel= ongs to the issuer.

I'm raising this point hop= ing that guidance can be clarified and included in the
specification.

Thanks,
Jared Hanson=


--
Jared Hanson <= http://jaredhanson.net/>
--f46d044304b8badf3004f2399436-- From ietf@augustcellars.com Wed Feb 12 15:07:00 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1121A001F for ; Wed, 12 Feb 2014 15:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf12xhauGZ7g for ; Wed, 12 Feb 2014 15:06:55 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4371A0026 for ; Wed, 12 Feb 2014 15:06:55 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B7D5D38F1D; Wed, 12 Feb 2014 15:06:53 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 12 Feb 2014 15:05:12 -0800 Message-ID: <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A7_01CF2803.D4B728E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdLd98cNMq+Zl1SjX4G1guFv/McwI03bP+m4RFaZA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:07:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A7_01CF2803.D4B728E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Hi Jim, I've updated my working draft to attempt to address all of your comments below. Thanks for the thorough read - as always. Are there any specific remaining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts. The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification). These algorithms would typically include these steps. (Note: The steps can be performed in any order and do not need to be treated as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found): 1. Collect a the set of potentially applicable keys. Sources of keys may include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order of looking at key sources is frequently application dependent both for order and inclusion. Frequently all keys from a one set of locations, such as local caches, will be checked before looking at other locations. 2. Filter the set of collected keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might be tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Keys not meeting the application's trust criteria would not be used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption. It is reasonable to do the signature validation prior to doing the trust validation steps as items which do not validate do not need to have a trust decision made. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any way optional in this algorithm. The concept of not gathering keys, filtering out keys that cannot possibly be correct and not checking the signature of keys makes absolutely no sense to me. If these steps are to be considered optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain would be eligible for inclusion in the key set. If this is not true then it needs to clarified in the description of x5u. If it is true then s/keys/key/ in that description. I need to have a much better understanding of the statement that you can order based on the value of the kty value. As it stands I have no idea what this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to those keys which are reasonable to look at rather than looking at the entire building of keys. As part of this I would move the number of keys from current step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algorithm), "use" (public key use), or "key_ops" (key operations) values would likewise typically be excluded." Then you need to provide text to tell me under what circumstances I would not be excluding them. My understanding is that they would always be excluded and thus this text makes no sense to me. I would move the kty filter into the previous sentence. It them make sense to talk about applications filtering based on other values that might be more application specific. I would like to see the trust statement moved to a separate item in the list of steps. Again this is something that needs to be done, but it can be done after step 4 rather than in the filter process. The trust statement can be made to be more general that what is current stated. That is the trust decision may be made based on internal application information, generic information or an external certificate validation process. In some cases the trust decision may be determined to be implicit based on the source of the key. I would make this general rather than specific. That is to say I would say that a binding of trust needs to be made, and the following items should be considered in the list of things to be included. This should not and would not be presented as an exhaustive list but should be somewhat complete. That is getting this from a jku has a degree of trust that a jkw does not have. Jim ------=_NextPart_000_01A7_01CF2803.D4B728E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = February 07, 2014 6:04 PM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: RE: [jose] Appendix D in draft = -20

 

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  = Thanks for the thorough read – as always.  Are there any = specific remaining edits you’d like to see applied to the = following text?

 

Appendix D.  Notes on Key = Selection

This appendix = describes a set of possible algorithms for selecting the key to be used = to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance = describes a family of possible algorithms, rather than a single = algorithm, because in different contexts, not all the sources of keys = will be used, they can be tried in different orders, and sometimes not = all the collected keys will be tried; hence, different algorithms will = be used in different application contexts. =

The steps below = are described for illustration purposes only; specific applications can = and are likely to use different algorithms or perform some of the steps = in different orders. Specific applications will frequently have a much = simpler method of determining the keys to use, as there may be one or = two key selection methods that are profiled for the application's use. = This appendix supplements the normative information on key location in = Section 6 (Key = Identification).

These = algorithms would typically include these steps.  = (Note: The steps can be performed in any order and do not need to be = treated as distinct, that is keys can be tested as soon as they are = found rather than waiting for all keys to be found): =

1.   Collect =  a= the set = of potentially applicable keys. Sources of keys may include: =

o    Keys = supplied by the application protocol being used. =

o    Keys = referenced by the jku (JWK Set URL) = Header Parameter.

o    The = key provided by the jwk (JSON Web Key) = Header Parameter.

o    The = key referenced by the x5u (X.509 URL) = Header Parameter.

o    The = key provided by the x5c (X.509 = Certificate Chain) Header Parameter.

o    Other = applicable keys available to the application.

The order of = looking at key sources is frequently application dependent both for = order and inclusion.  Frequently all keys from a one set of = locations, such as local caches, will be checked before looking at other = locations. 
 &nbs= p;  

2.   Filter the set = of collected keys. For instance, some applications = will only = use keys = referenced by kid (key ID) or = x5t (X.509 = certificate SHA-1 thumbprint) parameters might be tried by the = application. Keys with inappropriate alg (algorithm), = use (public key = use), or key_ops (key = operations) values would likewise typically be excluded if the = application uses those parameters. Additionally, = keys Keys<= span lang=3DEN style=3D'font-family:"Verdana","sans-serif";color:black'> = might be filtered to include or exclude keys with certain application = specific other = member values. = For some applications, no filtering will be applied. =

3.   Order the set = of collected keys. For instance, keys referenced by kid (Key ID) or = x5t (X.509 = Certificate SHA-1 Thumbprint) parameters might be tried before other = keys trying = keys without a kid value. Likewise, = keys with certain member values might be ordered before keys with other = member values. For some applications, no ordering will be applied. =

4.   Make trust = decisions about the keys. Keys not meeting the application's trust = criteria would not be used. Such criteria might include, but is not = limited to the source of the key, whether the TLS certificate validates = for keys retrieved from URLs, whether a key in an X.509 certificate is = backed by a valid certificate chain, and other information known by the = application.

5.   Attempt = signature or MAC validation for a JWS object or decryption of a JWE = object with some or all of the collected and possibly filtered and/or = ordered keys. A limit on the number of keys to be tried might be = applied. This process will normally terminate following a successful = validation or decryption.

It is reasonable to do the = signature validation prior to doing the trust validation steps as items = which do not validate do not need to have a trust decision = made.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike

 

From:= = jose [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Thursday, January 23, = 2014 12:41 PM
To: draft-i= etf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: = [jose] Appendix D in draft -20

 

I am only = marginally happier with this draft of the document.

 

I do not see = how one can possibly state that steps 1, 3 and 4 are in any way optional = in this algorithm.  The concept of not gathering keys, filtering = out keys that cannot possibly be correct and not checking the signature = of keys makes absolutely no sense to me.  If these steps are to be = considered optional then the reason for them being option must be = clearly documented.

 

My = understanding of x5u says that only a single key referenced by the chain = would be eligible for inclusion in the key set.  If this is not = true then it needs to clarified in the description of x5u.  If it = is true then s/keys/key/ in that description.

 

I need to = have a much better understanding of the statement that you can order = based on the value of the kty value.  As it stands I have no idea = what this means and why one would do such an ordering.

 

I would = probably swap steps 2 and 3 so that one can order with respect to those = keys which are reasonable to look at rather than looking at the entire = building of keys.  As part of this I would move the number of keys = from current step 3 to step 4.

 

If you are =
going to make the statement “Keys with inappropriate =
"alg" (algorithm), "use" (public =
key       use), or "key_ops" =
(key operations) values would =
likewise       typically be =
excluded.” Then you =
need to provide text to tell me under what circumstances I would not be =
excluding them.  My understanding is that they would always be =
excluded and thus this text makes no sense to =
me.
 =
I would =
move the kty filter into the previous sentence.  It them make sense =
to talk about applications filtering based on other values that might be =
more application specific.
 =
I would =
like to see the trust statement moved to a separate item in the list of =
steps.  Again this is something that needs to be done, but it can =
be done after step 4 rather than in the filter process.  The trust =
statement can be made to be more general that what is current stated. =
 That is the trust decision may be made based on internal =
application information, generic information or an external certificate =
validation process.  In some cases the trust decision may be =
determined to be implicit based on the source of the key.  =
  I would make this general rather than specific.  That =
is to say I would say that a binding of trust needs to be made, and the =
following items should be considered in the list of things to be =
included.  This should not and would not be presented as an =
exhaustive list but should be somewhat complete.  That is getting =
this from a jku has a degree of trust that a jkw does not =
have.
 =
Jim
 =
 

 

------=_NextPart_000_01A7_01CF2803.D4B728E0-- From bcampbell@pingidentity.com Wed Feb 12 15:58:51 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E436A1A0032 for ; Wed, 12 Feb 2014 15:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh2oEqiZ6IFX for ; Wed, 12 Feb 2014 15:58:49 -0800 (PST) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id AED041A002F for ; Wed, 12 Feb 2014 15:58:49 -0800 (PST) Received: from mail-ig0-f182.google.com ([209.85.213.182]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUvwKuIxfaP+N5qumnGIUoF8LMovLFULC@postini.com; Wed, 12 Feb 2014 15:58:49 PST Received: by mail-ig0-f182.google.com with SMTP id uy17so11985400igb.3 for ; Wed, 12 Feb 2014 15:58:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=mThsfKu9WXkq9fN0qM8zrCyqrAXq/9V6gG2SMGNyUZk=; b=dx7LBs6kyzD0wJhtdpB/2dM66APITWVA/zK0Vyo2Vr2CYOg92Rjn0Zunr3+/obdWoA MtIqfhbVWKe6IuCILLWXzV+2ATXKCNB0e4UMh5KeGN4cFbdfLuxABYSQgFkXNkR72A6M LPZWeggyBkpK0JdU2IicIN1EjiG6a17RSn+a54GmiNq35jbU6K0t64qD4KZGn3I+tfRl xc+1423RM26MTSCC/FQMM/xMcpAhE6444YdAqzsBG9QurjPNzyTORkwwKSZOAhrNBCWb 10KNhDyyWvwHPFa+Cu/H0ucD+n57ejNn7Oy9Eow+hWKaJsxut5FTq8VUTlEQADi6O1cO hkoQ== X-Gm-Message-State: ALoCoQlGuqPA6bbXtafmz7LNl/f4JpwZ6IYF7xgX82a9WwW8dSiXvJINe+rYMNKePZtvfUTWWhuBJEtitaZ58vEkgEklnz/fD08jAr63LAAmPyuIntjXQI3yOaYoVeyGIGPT3qBnVjeIe5ubkjv1zMccrZ+Nl4D37A== X-Received: by 10.50.137.100 with SMTP id qh4mr865972igb.4.1392249528470; Wed, 12 Feb 2014 15:58:48 -0800 (PST) X-Received: by 10.50.137.100 with SMTP id qh4mr865959igb.4.1392249528340; Wed, 12 Feb 2014 15:58:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.65.4 with HTTP; Wed, 12 Feb 2014 15:58:17 -0800 (PST) From: Brian Campbell Date: Wed, 12 Feb 2014 16:58:17 -0700 Message-ID: To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=001a11c31f749379bd04f23e5a3c Subject: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:58:52 -0000 --001a11c31f749379bd04f23e5a3c Content-Type: text/plain; charset=ISO-8859-1 Could anyone in this fine WG explain (probably again, I missed it the first time) the rational behind the text 'The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X and Y Coordinate parameters for EC keys in JWA [1]? This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an off list message indicate that both the jose4j and Nimbus JOSE+JWT implementations aren't following spec on the length of the octet string being the full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems with certain EC JWKs. I'm just trying to wrap my head around the issue so any help in that would be appreciated. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 --001a11c31f749379bd04f23e5a3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Could anyone in this fine WG explain (probably again,= I missed it the first time) the rational behind the text 'The length o= f this octet string MUST be the full size of a coordinate for the curve spe= cified in the "crv" parameter.', which is in the definitions = of the X and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/w= eb/jose/current/msg03901.html and an off list message indicate that bot= h the jose4j and Nimbus JOSE+JWT implementations aren't following spec = on the length of the octet string being the full size of a coordinate for t= he curve. Which suggests that there maybe potential interoperability proble= ms with certain EC JWKs.=A0

I'm just trying to wrap my head around the issue so any = help in that would be appreciated.
--001a11c31f749379bd04f23e5a3c-- From rlb@ipv.sx Wed Feb 12 16:28:29 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8001A005F for ; Wed, 12 Feb 2014 16:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe2H0A4Pypmz for ; Wed, 12 Feb 2014 16:28:27 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD81A007F for ; Wed, 12 Feb 2014 16:28:26 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wp4so11412770obc.16 for ; Wed, 12 Feb 2014 16:28:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=isztLzta7YitPE2llK0CIkycFZNSl6gI9Hco/HhojDw=; b=UY7YDCRwk5e8PFM2oAItNxETc03EJRdIN3hdWzPOpdGPHirVkFRRuq0xgFDd2S72YD mYyLm1vLJtFTSnz4/BL7pKcaf9dew7WOq5U+DcglJYxSBZsYJTGI1nCvOK5MsrtzYAfe MuNf8dCLQoENUUzBK6ELzaCbL94AwmmBbQVKGuYj8C38IROjL+LxmHMu9kndm6fRW6SI q6QO8hnZuRs6iumi6sXuOvAhy9Lau3/LjgHMqRWso5Ffpy8wIJqmaCIpKvteVqfoIKb2 pGh44RtaiBOvPHDk6KTXjCS+6ytWXhGTHZpmbpoRU5xdvvzyCol4yVFuaqbkIL/k/xaJ uRPw== X-Gm-Message-State: ALoCoQk1nK9uxAOxYQVeIpWUNagla8xCowB+tTV9mB1lImT79yvoQKSHQOnW1nc1+EwTv/BSlH1j MIME-Version: 1.0 X-Received: by 10.182.122.133 with SMTP id ls5mr4139157obb.52.1392251305809; Wed, 12 Feb 2014 16:28:25 -0800 (PST) Received: by 10.60.69.102 with HTTP; Wed, 12 Feb 2014 16:28:25 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Feb 2014 19:28:25 -0500 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=001a1134a7e485775104f23ec445 Cc: "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 00:28:29 -0000 --001a1134a7e485775104f23ec445 Content-Type: text/plain; charset=ISO-8859-1 That would make sense only for binary curves, but most of the curves people use today are integer curves, in which case truncation is totally sensible. I've been told that some Microsoft crypto libraries use fixed-length buffers for these things, but there should be a problem copying a shorter value into that buffer. Net of that, I would be in favor of saying that the coordinates MUST be full-length for binary curves, and MAY be zero-padded to full length for integer curves. --Richard On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell wrote: > Could anyone in this fine WG explain (probably again, I missed it the > first time) the rational behind the text 'The length of this octet string > MUST be the full size of a coordinate for the curve specified in the "crv" > parameter.', which is in the definitions of the X and Y Coordinate > parameters for EC keys in JWA [1]? > > This message last month on the list > http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an > off list message indicate that both the jose4j and Nimbus JOSE+JWT > implementations aren't following spec on the length of the octet string > being the full size of a coordinate for the curve. Which suggests that > there maybe potential interoperability problems with certain EC JWKs. > > I'm just trying to wrap my head around the issue so any help in that would > be appreciated. > > [1] > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a1134a7e485775104f23ec445 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That would make sense only for binary curves, but most of = the curves people use today are integer curves, in which case truncation is= totally sensible. =A0

I've been told that some Micr= osoft crypto libraries use fixed-length buffers for these things, but there= should be a problem copying a shorter value into that buffer.

Net of that, I would be in favor of saying that the coo= rdinates MUST be full-length for binary curves, and MAY be zero-padded to f= ull length for integer curves.

--Richard


On Wed, Feb 12, 2014 at 6:58 PM, Brian C= ampbell <bcampbell@pingidentity.com> wrote:
Could anyone in this fine WG explain (probably again,= I missed it the first time) the rational behind the text 'The length o= f this octet string MUST be the full size of a coordinate for the curve spe= cified in the "crv" parameter.', which is in the definitions = of the X and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.= org/mail-archive/web/jose/current/msg03901.html and an off list message= indicate that both the jose4j and Nimbus JOSE+JWT implementations aren'= ;t following spec on the length of the octet string being the full size of = a coordinate for the curve. Which suggests that there maybe potential inter= operability problems with certain EC JWKs.=A0

I'm just trying to wrap my head around the issue so any = help in that would be appreciated.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--001a1134a7e485775104f23ec445-- From Michael.Jones@microsoft.com Wed Feb 12 16:35:22 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209261A007F for ; Wed, 12 Feb 2014 16:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtszMPZc8alF for ; Wed, 12 Feb 2014 16:35:17 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0811A0073 for ; Wed, 12 Feb 2014 16:35:17 -0800 (PST) Received: from BY2PR03CA066.namprd03.prod.outlook.com (10.141.249.39) by BY2PR03MB012.namprd03.prod.outlook.com (10.255.240.38) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 13 Feb 2014 00:35:14 +0000 Received: from BN1AFFO11FD025.protection.gbl (2a01:111:f400:7c10::164) by BY2PR03CA066.outlook.office365.com (2a01:111:e400:2c5d::39) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Thu, 13 Feb 2014 00:35:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD025.mail.protection.outlook.com (10.58.52.85) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 00:35:13 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 00:34:46 +0000 From: Mike Jones To: Richard Barnes , Brian Campbell Thread-Topic: [jose] question about the size of coordinate parameters in EC JWKs Thread-Index: AQHPKFKMI0FKZmhOwki0+egbZwxPZJqyVQ2w Date: Thu, 13 Feb 2014 00:34:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B1928FC@TK5EX14MBXC288.redmond.corp.microsoft.com> References: 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.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B1928FCTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(377454003)(189002)(199002)(24454002)(16236675002)(477?= =?us-ascii?Q?36001)(49866001)(74366001)(4396001)(47976001)(50986001)(8793?= =?us-ascii?Q?6001)(81542001)(76786001)(16297215004)(224303002)(224313003)?= =?us-ascii?Q?(81816001)(77096001)(81342001)(81686001)(83322001)(195803950?= =?us-ascii?Q?03)(69226001)(15975445006)(44976005)(19580405001)(6806004)(1?= =?us-ascii?Q?5202345003)(2656002)(80976001)(56776001)(92566001)(76796001)?= =?us-ascii?Q?(54316002)(71186001)(63696002)(20776003)(93136001)(54356001)?= =?us-ascii?Q?(94316002)(65816001)(53806001)(94946001)(19300405004)(746620?= =?us-ascii?Q?01)(31966008)(74706001)(74502001)(74876001)(47446002)(512954?= =?us-ascii?Q?002)(86612001)(95416001)(85306002)(84326002)(76482001)(95666?= =?us-ascii?Q?001)(80022001)(56816005)(90146001)(33656001)(66066001)(92726?= =?us-ascii?Q?001)(51856001)(83072002)(85852003)(55846006)(87266001)(59766?= =?us-ascii?Q?001)(93516002)(86362001)(79102001)(77982001)(46102001);DIR:O?= =?us-ascii?Q?UT;SFP:1101;SCL:1;SRVR:BY2PR03MB012;H:mail.microsoft.com;CLI?= =?us-ascii?Q?P:131.107.125.37;FPR:EC70F53F.A7F251E1.71F37DBB.4AE9DB41.203?= =?us-ascii?Q?98;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 00:35:22 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B1928FCTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The MAY would result in interop problems, since some implementations would = correctly handle short values and some wouldn't. It's the way it is so tha= t there's a consistent and unambiguous rule. And it's not hard to implemen= t (especially when using underlying libraries, such as the ones that Richar= d cites, that already provide fixed-length representations of these values)= . If you're using a library with variable-length value representations, ju= st zero the whole array and copy the bytes provided in a right-justified ma= nner into the array. I really don't think we should add conditionals that implementations would = have to handle here, as they could only hurt interop. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, February 12, 2014 4:28 PM To: Brian Campbell Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC = JWKs That would make sense only for binary curves, but most of the curves people= use today are integer curves, in which case truncation is totally sensible= . I've been told that some Microsoft crypto libraries use fixed-length buffer= s for these things, but there should be a problem copying a shorter value i= nto that buffer. Net of that, I would be in favor of saying that the coordinates MUST be ful= l-length for binary curves, and MAY be zero-padded to full length for integ= er curves. --Richard On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell > wrote: Could anyone in this fine WG explain (probably again, I missed it the first= time) the rational behind the text 'The length of this octet string MUST b= e the full size of a coordinate for the curve specified in the "crv" parame= ter.', which is in the definitions of the X and Y Coordinate parameters for= EC keys in JWA [1]? This message last month on the list http://www.ietf.org/mail-archive/web/jo= se/current/msg03901.html and an off list message indicate that both the jos= e4j and Nimbus JOSE+JWT implementations aren't following spec on the length= of the octet string being the full size of a coordinate for the curve. Whi= ch suggests that there maybe potential interoperability problems with certa= in EC JWKs. I'm just trying to wrap my head around the issue so any help in that would = be appreciated. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#secti= on-6.2 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739438B1928FCTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The MAY would result in i= nterop problems, since some implementations would correctly handle short va= lues and some wouldn’t.  It’s the way it is so that there&= #8217;s a consistent and unambiguous rule.  And it’s not hard to implem= ent (especially when using underlying libraries, such as the ones that Rich= ard cites, that already provide fixed-length representations of these value= s).  If you’re using a library with variable-length value representations, just zero the whole array and copy the bytes provid= ed in a right-justified manner into the array.

 <= /p>

I really don’t thin= k we should add conditionals that implementations would have to handle here= , as they could only hurt interop.

 <= /p>

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

 <= /p>

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto libraries = use fixed-length buffers for these things, but there should be a problem co= pying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size of a = coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X and = Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT impl= ementations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue so = any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739438B1928FCTK5EX14MBXC288r_-- From Michael.Jones@microsoft.com Wed Feb 12 16:38:18 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739681A0054 for ; Wed, 12 Feb 2014 16:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVSPdYMv1rqX for ; Wed, 12 Feb 2014 16:38:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6C81A0047 for ; Wed, 12 Feb 2014 16:38:15 -0800 (PST) Received: from BY2PR03CA046.namprd03.prod.outlook.com (10.141.249.19) by BY2PR03MB224.namprd03.prod.outlook.com (10.242.36.151) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 00:38:12 +0000 Received: from BN1AFFO11FD016.protection.gbl (2a01:111:f400:7c10::160) by BY2PR03CA046.outlook.office365.com (2a01:111:e400:2c5d::19) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Thu, 13 Feb 2014 00:38:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD016.mail.protection.outlook.com (10.58.52.76) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 00:38:11 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 00:37:41 +0000 From: Mike Jones To: Brian Campbell , "jose@ietf.org" Thread-Topic: [jose] question about the size of coordinate parameters in EC JWKs Thread-Index: AQHPKE5uEdeffs7RXEm4FoBGHnnaGJqyVjeg Date: Thu, 13 Feb 2014 00:37:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19295D@TK5EX14MBXC288.redmond.corp.microsoft.com> References: 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.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19295DTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(199002)(189002)(377454003)(74662001)(74706001)(31966008)(74876001)(74502001)(47446002)(19300405004)(94946001)(95416001)(84326002)(85306002)(512954002)(86612001)(65816001)(94316002)(20776003)(63696002)(66066001)(93136001)(53806001)(86362001)(93516002)(59766001)(77982001)(79102001)(55846006)(87266001)(83072002)(85852003)(46102001)(56816005)(90146001)(33656001)(95666001)(76482001)(54356001)(51856001)(92726001)(80022001)(16297215004)(76786001)(81816001)(81542001)(77096001)(76796001)(87936001)(16236675002)(4396001)(74366001)(50986001)(47976001)(49866001)(47736001)(56776001)(81342001)(80976001)(15202345003)(2656002)(71186001)(54316002)(92566001)(81686001)(83322001)(6806004)(44976005)(19580405001)(15975445006)(69226001)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB224; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:CCFCF5BF.AF3203C9.35F37D73.46E51F4D.20224; InfoDomainNonexistentA:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: Vladimir Dzhuvinov Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 00:38:18 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B19295DTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd file a bug against Numbus... Or maybe Vladimir, could you do that? -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Brian Campbell Sent: Wednesday, February 12, 2014 3:58 PM To: jose@ietf.org Subject: [jose] question about the size of coordinate parameters in EC JWKs Could anyone in this fine WG explain (probably again, I missed it the first= time) the rational behind the text 'The length of this octet string MUST b= e the full size of a coordinate for the curve specified in the "crv" parame= ter.', which is in the definitions of the X and Y Coordinate parameters for= EC keys in JWA [1]? This message last month on the list http://www.ietf.org/mail-archive/web/jo= se/current/msg03901.html and an off list message indicate that both the jos= e4j and Nimbus JOSE+JWT implementations aren't following spec on the length= of the octet string being the full size of a coordinate for the curve. Whi= ch suggests that there maybe potential interoperability problems with certa= in EC JWKs. I'm just trying to wrap my head around the issue so any help in that would = be appreciated. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#secti= on-6.2 --_000_4E1F6AAD24975D4BA5B16804296739438B19295DTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d file a bug agai= nst Numbus…  Or maybe Vladimir, could you do that?

 <= /p>

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

 <= /p>

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, February 12, 2014 3:58 PM
To: jose@ietf.org
Subject: [jose] question about the size of coordinate parameters in = EC JWKs

 

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size of a = coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X and = Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT impl= ementations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue so = any help in that would be appreciated.

--_000_4E1F6AAD24975D4BA5B16804296739438B19295DTK5EX14MBXC288r_-- From Michael.Jones@microsoft.com Wed Feb 12 17:08:33 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231631A00B3 for ; Wed, 12 Feb 2014 17:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPFiHmyUPFu8 for ; Wed, 12 Feb 2014 17:08:22 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id A75981A0079 for ; Wed, 12 Feb 2014 17:08:20 -0800 (PST) Received: from BL2PR03CA018.namprd03.prod.outlook.com (10.141.66.26) by BL2PR03MB276.namprd03.prod.outlook.com (10.255.231.25) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 01:08:17 +0000 Received: from BL2FFO11FD031.protection.gbl (2a01:111:f400:7c09::140) by BL2PR03CA018.outlook.office365.com (2a01:111:e400:c1b::26) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Thu, 13 Feb 2014 01:08:17 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD031.mail.protection.outlook.com (10.173.160.71) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 01:08:16 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 01:07:16 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Appendix D in draft -20 Thread-Index: Ac8YdVFWIkzAvGyyToOm/dHc3J4hWQL+/UKwAPVm4gAAA+qcYA== Date: Thu, 13 Feb 2014 01:07:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B192B02@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> In-Reply-To: <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B192B02TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(51914003)(189002)(199002)(377454003)(86362001)(47446002)(77096001)(74502001)(93516002)(93136001)(31966008)(74662001)(76786001)(76796001)(95416001)(55846006)(86612001)(59766001)(77982001)(56776001)(94316002)(20776003)(94946001)(63696002)(79102001)(33656001)(74706001)(74876001)(74366001)(16236675002)(15202345003)(54316002)(81686001)(85852003)(81816001)(87936001)(53806001)(56816005)(76482001)(19300405004)(81342001)(4396001)(512954002)(92726001)(81542001)(80976001)(51856001)(85306002)(84326002)(46102001)(90146001)(83072002)(54356001)(15975445006)(49866001)(47736001)(2656002)(92566001)(69226001)(6806004)(44976005)(66066001)(47976001)(80022001)(65816001)(95666001)(50986001)(71186001)(19580395003)(83322001)(19580405001)(87266001)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB276; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:EA63F1D7.A33A5791.BDF1BDBB.42E49931.206D7; MLV:nspm; InfoDomainNonexistentMX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:08:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B192B02TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the useful comments, Jim. I've incorporated them, sometimes wit= h small wording changes, in the version below. Hopefully this version will= get us to a draft we both like (or at least, can live with :)). Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms include the following steps. Note that the steps can be pe= rformed in any order and do not need to be treated as distinct. For example= , keys can be tried as soon as they are found, rather than collecting all t= he keys before trying any. 1. Collect the set of potentially applicable keys. Sources of keys may in= clude: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order for collecting and trying keys from different key sources is typi= cally application dependent. For example, frequently all keys from a one se= t of locations, such as local caches, will be tried before collecting and t= rying keys from other locations. 2. Filter the set of collected keys. For instance, some applications will= use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 t= humbprint) parameters. If the application uses the alg (algorithm), use (pu= blic key use), or key_ops (key operations) parameters, keys with keys with = inappropriate values of those parameters would be excluded. Additionally, k= eys might be filtered to include or exclude keys with certain other member = values in an application specific manner. For some applications, no filteri= ng will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before keys with neither of these values. Likewise, keys with certain m= ember values might be ordered before keys with other member values. For som= e applications, no ordering will be applied. 4. Make trust decisions about the keys. Signatures made with keys not mee= ting the application's trust criteria would not be accepted. Such criteria = might include, but is not limited to the source of the key, whether the TLS= certificate validates for keys retrieved from URLs, whether a key in an X.= 509 certificate is backed by a valid certificate chain, and other informati= on known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. Note that it is reasonable for some applications to perform signature or MA= C validation prior to making a trust decision about a key, since keys for w= hich the validation fails need no trust decision. The only suggested action I didn't apply was deleting the sentence "For som= e applications, no filtering will be applied". I didn't delete it because = it's true. For example, an application might specify that all potentially = applicable keys are retrieved from a particular JWK Set, it might specify t= hat only applicable keys may be present there, and that the keys are to be = tried until one succeeds. That's very simple. Such an application doesn't= need, and wouldn't use any of the optional key attribute parameters. They= 'd just use key values, and would try keys until one works. No filtering i= s performed. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 3:05 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Hi Jim, I've updated my working draft to attempt to address all of your comments be= low. Thanks for the thorough read - as always. Are there any specific rem= aining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms would typically include these steps. (Note: The steps can= be performed in any order and do not need to be treated as distinct, that = is keys can be tested as soon as they are found rather than waiting for all= keys to be found): 1. Collect a the set of potentially applicable keys. Sources of keys may= include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order of looking at key sources is frequently application dependent bot= h for order and inclusion. Frequently all keys from a one set of locations= , such as local caches, will be checked before looking at other locations. 2. Filter the set of collected keys. For instance, some applications will= only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 t= humbprint) parameters might be tried by the application. Keys with inapprop= riate alg (algorithm), use (public key use), or key_ops (key operations) va= lues would likewise typically be excluded if the application uses those par= ameters. Additionally, keys Keys might be filtered to include or exclude ke= ys with certain application specific other member values. For some applicat= ions, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before other keys trying keys without a kid value. Likewise, keys with = certain member values might be ordered before keys with other member values= . For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Keys not meeting the application'= s trust criteria would not be used. Such criteria might include, but is not= limited to the source of the key, whether the TLS certificate validates fo= r keys retrieved from URLs, whether a key in an X.509 certificate is backed= by a valid certificate chain, and other information known by the applicati= on. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. It is reasonable to do the signature validation prior to doing the trust va= lidation steps as items which do not validate do not need to have a trust d= ecision made. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any wa= y optional in this algorithm. The concept of not gathering keys, filtering= out keys that cannot possibly be correct and not checking the signature of= keys makes absolutely no sense to me. If these steps are to be considered= optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain= would be eligible for inclusion in the key set. If this is not true then = it needs to clarified in the description of x5u. If it is true then s/keys= /key/ in that description. I need to have a much better understanding of the statement that you can or= der based on the value of the kty value. As it stands I have no idea what = this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to t= hose keys which are reasonable to look at rather than looking at the entire= building of keys. As part of this I would move the number of keys from cu= rrent step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algo= rithm), "use" (public key use), or "key_ops" (key operations) values = would likewise typically be excluded." Then you need to provide text = to tell me under what circumstances I would not be excluding them. My unde= rstanding is that they would always be excluded and thus this text makes no= sense to me. I would move the kty filter into the previous sentence. It them make sense= to talk about applications filtering based on other values that might be m= ore application specific. I would like to see the trust statement moved to a separate item in the lis= t of steps. Again this is something that needs to be done, but it can be d= one after step 4 rather than in the filter process. The trust statement ca= n be made to be more general that what is current stated. That is the trus= t decision may be made based on internal application information, generic i= nformation or an external certificate validation process. In some cases th= e trust decision may be determined to be implicit based on the source of th= e key. I would make this general rather than specific. That is to say I= would say that a binding of trust needs to be made, and the following item= s should be considered in the list of things to be included. This should n= ot and would not be presented as an exhaustive list but should be somewhat = complete. That is getting this from a jku has a degree of trust that a jkw= does not have. Jim --_000_4E1F6AAD24975D4BA5B16804296739438B192B02TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the useful = comments, Jim.  I’ve incorporated them, sometimes with small wor= ding changes, in the version below.  Hopefully this version will get u= s to a draft we both like (or at least, can live with J).

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms include the following steps. Note t= hat the steps can be performed in any order and do not need to be treated a= s distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any.

1.=    Collect the set of poten= tially applicable keys. Sources of keys may include:

o   Keys supplied by the app= lication protocol being used.

o   Keys referenced by the jku (JWK Set URL) Header Parameter.

o   The key provided by the jwk (JSON Web Key) Header Parameter.

o   The key referenced by th= e x5u (X.509 URL) Header Parameter.

o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o   Other applicable keys av= ailable to the application.

The order for collecting and trying keys from different= key sources is typically application dependent. For example, frequently al= l keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations.

2.=    Filter the set of collec= ted keys. For instance, some applications will use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters. If the ap= plication uses the alg (algorithm), use (public key use), or key_ops= (key operations) parameters, keys with keys with inapp= ropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other membe= r values in an application specific manner. For some applications, no filte= ring will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member = values. For some applications, no ordering will be applied.

4.=    Make trust decisions abo= ut the keys. Signatures made with keys not meeting the application's trust = criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate v= alidates for keys retrieved from URLs, whether a key in an X.509 certificat= e is backed by a valid certificate chain, and other information known by th= e application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

Note that it is reasonable for some applications to = perform signature or MAC validation prior to making a trust decision about = a key, since keys for which the validation fails need no trust decision.

 

The only suggested act= ion I didn’t apply was deleting the sentence “For some applications, no filtering will be applied”.  I didn’t delete it because it’s true.  For example, an ap= plication might specify that all potentially applicable keys are retrieved = from a particular JWK Set, it might specify that only applicable keys may b= e present there, and that the keys are to be tried until one succeeds.  That’s very simple.  Such an applicat= ion doesn’t need, and wouldn’t use any of the optional key attr= ibute parameters.  They’d just use key values, and would try key= s until one works.  No filtering is performed.

 

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

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 3:05 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] Appendix D in draft -20

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Friday, February 07, 2014 6:04 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  Thank= s for the thorough read – as always.  Are there any specific rem= aining edits you’d like to see applied to the following text?

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms would typically include these steps.  = (Note: The steps can be performed in any order and do not need to be treate= d as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found):

1.=    Collect  a the set of potentially = applicable keys. Sources of keys may include:

o   Keys supplied by the app= lication protocol being used.

o   Keys referenced by the jku (JWK Set URL) Header Parameter.

o   The key provided by the jwk (JSON Web Key) Header Parameter.

o   The key referenced by th= e x5u (X.509 URL) Header Parameter.

o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o   Other applicable keys av= ailable to the application.

The order of looking at key sources is frequently applica= tion dependent both for order and inclusion.  Frequently all keys from= a one set of locations, such as local caches, will be checked before looking at other locations. 
    

2.=    Filter the set of collec= ted keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might b= e tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops= (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be = filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered befo= re keys with other member values. For some applications, no ordering will be appli= ed.

4.=    Make trust decisions abo= ut the keys. Keys not meeting the application's trust criteria would not be= used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retr= ieved from URLs, whether a key in an X.509 certificate is backed by a valid= certificate chain, and other information known by the application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

It is reasonable to do the signature = validation prior to doing the trust validation steps as items which do not = validate do not need to have a trust decision made.

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: draft-ietf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: [jose] Appendix D in draft -20

 

I am only marginally happier with this draft of the = document.

 

I do not see how one can possibly state that steps 1= , 3 and 4 are in any way optional in this algorithm.  The concept of n= ot gathering keys, filtering out keys that cannot possibly be correct and n= ot checking the signature of keys makes absolutely no sense to me.  If these steps are to be considered optio= nal then the reason for them being option must be clearly documented.<= /o:p>

 

My understanding of x5u says that only a single key = referenced by the chain would be eligible for inclusion in the key set.&nbs= p; If this is not true then it needs to clarified in the description of x5u= .  If it is true then s/keys/key/ in that description.

 

I need to have a much better understanding of the st= atement that you can order based on the value of the kty value.  As it= stands I have no idea what this means and why one would do such an orderin= g.

 

I would probably swap steps 2 and 3 so that one can = order with respect to those keys which are reasonable to look at rather tha= n looking at the entire building of keys.  As part of this I would mov= e the number of keys from current step 3 to step 4.

 

If you are going to make the statement “Keys=
 with inappropriate "alg" (algorithm), "use" (public ke=
y       use), or "key_ops" (key ope=
rations) values would likewise       typicall=
y be excluded.” Then you need to provide text to tell me=
 under what circumstances I would not be excluding them.  My understan=
ding is that they would always be excluded and thus this text makes no sens=
e to me.
 
I would move the kty filter into the previous sentence.&n=
bsp; It them make sense to talk about applications filtering based on other=
 values that might be more application specific.
 
I would like to see the trust statement moved to a separa=
te item in the list of steps.  Again this is something that needs to b=
e done, but it can be done after step 4 rather than in the filter process.&=
nbsp; The trust statement can be made to be more general that what is curre=
nt stated.  That is the trust decision may be made based on internal a=
pplication information, generic information or an external certificate vali=
dation process.  In some cases the trust decision may be determined to=
 be implicit based on the source of the key.    I would make=
 this general rather than specific.  That is to say I would say that a=
 binding of trust needs to be made, and the following items should be consi=
dered in the list of things to be included.  This should not and would=
 not be presented as an exhaustive list but should be somewhat complete.&nb=
sp; That is getting this from a jku has a degree of trust that a jkw does n=
ot have.
 
Jim
 
 

 

--_000_4E1F6AAD24975D4BA5B16804296739438B192B02TK5EX14MBXC288r_-- From ietf@augustcellars.com Wed Feb 12 17:51:19 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787D31A00B6 for ; Wed, 12 Feb 2014 17:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imeUo3ymfoKZ for ; Wed, 12 Feb 2014 17:51:16 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A751E1A00AF for ; Wed, 12 Feb 2014 17:51:16 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8B33F2CA0E; Wed, 12 Feb 2014 17:51:15 -0800 (PST) From: "Jim Schaad" To: "'Richard Barnes'" , "'Brian Campbell'" References: In-Reply-To: Date: Wed, 12 Feb 2014 17:49:34 -0800 Message-ID: <01ee01cf285d$d8df34d0$8a9d9e70$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EF_01CF281A.CABDC990" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI9Avo3zUCG21RAMUGWO2jnhuMYVwHWf6zzmcgBekA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:51:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EF_01CF281A.CABDC990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Would it be possible for somebody to give me a better reference pointer to the document that is begin reference? From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, February 12, 2014 4:28 PM To: Brian Campbell Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs That would make sense only for binary curves, but most of the curves people use today are integer curves, in which case truncation is totally sensible. I've been told that some Microsoft crypto libraries use fixed-length buffers for these things, but there should be a problem copying a shorter value into that buffer. Net of that, I would be in favor of saying that the coordinates MUST be full-length for binary curves, and MAY be zero-padded to full length for integer curves. --Richard On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell wrote: Could anyone in this fine WG explain (probably again, I missed it the first time) the rational behind the text 'The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X and Y Coordinate parameters for EC keys in JWA [1]? This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an off list message indicate that both the jose4j and Nimbus JOSE+JWT implementations aren't following spec on the length of the octet string being the full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems with certain EC JWKs. I'm just trying to wrap my head around the issue so any help in that would be appreciated. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6. 2 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_01EF_01CF281A.CABDC990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would it be possible for somebody to give me a better reference = pointer to the document that is begin reference?

 

From:= = jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Wednesday, February 12, 2014 4:28 = PM
To: Brian Campbell
Cc: = jose@ietf.org
Subject: Re: [jose] question about the size of = coordinate parameters in EC JWKs

 

That = would make sense only for binary curves, but most of the curves people = use today are integer curves, in which case truncation is totally = sensible.  

 

I've been told that some Microsoft crypto libraries = use fixed-length buffers for these things, but there should be a problem = copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be = zero-padded to full length for integer = curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

Could anyone in this fine WG explain = (probably again, I missed it the first time) the rational behind the = text 'The length of this octet string MUST be the full size of a = coordinate for the curve specified in the "crv" parameter.', = which is in the definitions of the X and Y Coordinate parameters for EC = keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03= 901.html and an off list message indicate that both the jose4j and = Nimbus JOSE+JWT implementations aren't following spec on the length of = the octet string being the full size of a coordinate for the curve. = Which suggests that there maybe potential interoperability problems with = certain EC JWKs. 

I'm just trying to wrap my head around the issue so = any help in that would be appreciated.


______________________________________= _________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

------=_NextPart_000_01EF_01CF281A.CABDC990-- From ietf@augustcellars.com Wed Feb 12 17:57:27 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D731A00AF for ; Wed, 12 Feb 2014 17:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjTB-ssTTuKe for ; Wed, 12 Feb 2014 17:57:20 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2331A00AB for ; Wed, 12 Feb 2014 17:57:20 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8AB6A38F39; Wed, 12 Feb 2014 17:57:19 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B192B02@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B192B02@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 12 Feb 2014 17:55:38 -0800 Message-ID: <01f301cf285e$b1cc5930$15650b90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F4_01CF281B.A3AF81D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdLd98cNMq+Zl1SjX4G1guFv/McwI03bP+AngbUiABerBx2ptlI6wA Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:57:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F4_01CF281B.A3AF81D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, February 12, 2014 5:07 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Thanks for the useful comments, Jim. I've incorporated them, sometimes with small wording changes, in the version below. Hopefully this version will get us to a draft we both like (or at least, can live with J). Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts. The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification). These algorithms include the following steps. Note that the steps can be performed in any order and do not need to be treated as distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any. 1. Collect the set of potentially applicable keys. Sources of keys may include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order for collecting and trying keys from different key sources is typically application dependent. For example, frequently all keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations. 2. Filter the set of collected keys. For instance, some applications will use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters. If the application uses the alg (algorithm), use (public key use), or key_ops (key operations) parameters, keys with keys with inappropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other member values in an application specific manner. For some applications, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption. Note that it is reasonable for some applications to perform signature or MAC validation prior to making a trust decision about a key, since keys for which the validation fails need no trust decision. The only suggested action I didn't apply was deleting the sentence "For some applications, no filtering will be applied". I didn't delete it because it's true. For example, an application might specify that all potentially applicable keys are retrieved from a particular JWK Set, it might specify that only applicable keys may be present there, and that the keys are to be tried until one succeeds. That's very simple. Such an application doesn't need, and wouldn't use any of the optional key attribute parameters. They'd just use key values, and would try keys until one works. No filtering is performed. That is not really true statement - and what happens if key is in the list which is does not follow the rules? Then either things go boom or the filtering step is applied, it is just applied in a really bad way at some later step. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 3:05 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Hi Jim, I've updated my working draft to attempt to address all of your comments below. Thanks for the thorough read - as always. Are there any specific remaining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts. The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification). These algorithms would typically include these steps. (Note: The steps can be performed in any order and do not need to be treated as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found): 1. Collect a the set of potentially applicable keys. Sources of keys may include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order of looking at key sources is frequently application dependent both for order and inclusion. Frequently all keys from a one set of locations, such as local caches, will be checked before looking at other locations. 2. Filter the set of collected keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might be tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Keys not meeting the application's trust criteria would not be used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption. It is reasonable to do the signature validation prior to doing the trust validation steps as items which do not validate do not need to have a trust decision made. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any way optional in this algorithm. The concept of not gathering keys, filtering out keys that cannot possibly be correct and not checking the signature of keys makes absolutely no sense to me. If these steps are to be considered optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain would be eligible for inclusion in the key set. If this is not true then it needs to clarified in the description of x5u. If it is true then s/keys/key/ in that description. I need to have a much better understanding of the statement that you can order based on the value of the kty value. As it stands I have no idea what this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to those keys which are reasonable to look at rather than looking at the entire building of keys. As part of this I would move the number of keys from current step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algorithm), "use" (public key use), or "key_ops" (key operations) values would likewise typically be excluded." Then you need to provide text to tell me under what circumstances I would not be excluding them. My understanding is that they would always be excluded and thus this text makes no sense to me. I would move the kty filter into the previous sentence. It them make sense to talk about applications filtering based on other values that might be more application specific. I would like to see the trust statement moved to a separate item in the list of steps. Again this is something that needs to be done, but it can be done after step 4 rather than in the filter process. The trust statement can be made to be more general that what is current stated. That is the trust decision may be made based on internal application information, generic information or an external certificate validation process. In some cases the trust decision may be determined to be implicit based on the source of the key. I would make this general rather than specific. That is to say I would say that a binding of trust needs to be made, and the following items should be considered in the list of things to be included. This should not and would not be presented as an exhaustive list but should be somewhat complete. That is getting this from a jku has a degree of trust that a jkw does not have. Jim ------=_NextPart_000_01F4_01CF281B.A3AF81D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, February 12, 2014 5:07 PM
To: Jim = Schaad
Cc: jose@ietf.org
Subject: RE: [jose] = Appendix D in draft -20

 

Thanks for the useful comments, Jim.  = I’ve incorporated them, sometimes with small wording changes, in = the version below.  Hopefully this version will get us to a draft = we both like (or at least, can live with J).

 

Appendix D.  Notes on Key = Selection

This appendix = describes a set of possible algorithms for selecting the key to be used = to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance = describes a family of possible algorithms, rather than a single = algorithm, because in different contexts, not all the sources of keys = will be used, they can be tried in different orders, and sometimes not = all the collected keys will be tried; hence, different algorithms will = be used in different application contexts. =

The steps below = are described for illustration purposes only; specific applications can = and are likely to use different algorithms or perform some of the steps = in different orders. Specific applications will frequently have a much = simpler method of determining the keys to use, as there may be one or = two key selection methods that are profiled for the application's use. = This appendix supplements the normative information on key location in = Section 6 (Key Identification).

These = algorithms include the following steps. Note that the steps can be = performed in any order and do not need to be treated as distinct. For = example, keys can be tried as soon as they are found, rather than = collecting all the keys before trying any.

1.   Collect the set = of potentially applicable keys. Sources of keys may include: =

o    Keys = supplied by the application protocol being used. =

o    Keys = referenced by the jku (JWK Set URL) = Header Parameter.

o    The = key provided by the jwk (JSON Web Key) = Header Parameter.

o    The = key referenced by the x5u (X.509 URL) = Header Parameter.

o    The = key provided by the x5c (X.509 = Certificate Chain) Header Parameter.

o    Other = applicable keys available to the application.

The order for = collecting and trying keys from different key sources is typically = application dependent. For example, frequently all keys from a one set = of locations, such as local caches, will be tried before collecting and = trying keys from other locations.

2.   Filter the set = of collected keys. For instance, some applications will use only keys = referenced by kid (key ID) or = x5t (X.509 = certificate SHA-1 thumbprint) parameters. If the application uses = the alg (algorithm), = use (public key = use), or key_ops (key = operations) parameters, keys with keys with inappropriate values of = those parameters would be excluded. Additionally, keys might be filtered = to include or exclude keys with certain other member values in an = application specific manner. For some applications, no filtering will be = applied.

3.   Order the set = of collected keys. For instance, keys referenced by kid (Key ID) or = x5t (X.509 = Certificate SHA-1 Thumbprint) parameters might be tried before keys with = neither of these values. Likewise, keys with certain member values might = be ordered before keys with other member values. For some applications, = no ordering will be applied.

4.   Make trust = decisions about the keys. Signatures made with keys not meeting the = application's trust criteria would not be accepted. Such criteria might = include, but is not limited to the source of the key, whether the TLS = certificate validates for keys retrieved from URLs, whether a key in an = X.509 certificate is backed by a valid certificate chain, and other = information known by the application.

5.   Attempt = signature or MAC validation for a JWS object or decryption of a JWE = object with some or all of the collected and possibly filtered and/or = ordered keys. A limit on the number of keys to be tried might be = applied. This process will normally terminate following a successful = validation or decryption.

Note that it is = reasonable for some applications to perform signature or MAC validation = prior to making a trust decision about a key, since keys for which the = validation fails need no trust decision.

 

The only suggested = action I didn’t apply was deleting the sentence = “For some = applications, no filtering will be applied”.  I didn’t delete it because = it’s true.  For example, an application might specify that = all potentially applicable keys are retrieved from a particular JWK Set, = it might specify that only applicable keys may be present there, and = that the keys are to be tried until one succeeds.  That’s = very simple.  Such an application doesn’t need, and = wouldn’t use any of the optional key attribute parameters.  = They’d just use key values, and would try keys until one = works.  No filtering is performed.

 

That is not really  = true statement – and what happens if  key is in the list = which is does not follow the rules?  Then either things go boom or = the filtering step is applied, it is just applied in a really bad way at = some later step.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   -- Mike

 

From:= = jose [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Wednesday, February 12, = 2014 3:05 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: = [jose] Appendix D in draft -20

 

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Friday, February 07, 2014 6:04 = PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: = [jose] Appendix D in draft -20

 

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  = Thanks for the thorough read – as always.  Are there any = specific remaining edits you’d like to see applied to the = following text?

 

Appendix D.  Notes on Key = Selection

This appendix = describes a set of possible algorithms for selecting the key to be used = to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance = describes a family of possible algorithms, rather than a single = algorithm, because in different contexts, not all the sources of keys = will be used, they can be tried in different orders, and sometimes not = all the collected keys will be tried; hence, different algorithms will = be used in different application contexts. =

The steps below = are described for illustration purposes only; specific applications can = and are likely to use different algorithms or perform some of the steps = in different orders. Specific applications will frequently have a much = simpler method of determining the keys to use, as there may be one or = two key selection methods that are profiled for the application's use. = This appendix supplements the normative information on key location in = Section 6 (Key = Identification).

These = algorithms would typically include these steps.  = (Note: The steps can be performed in any order and do not need to be = treated as distinct, that is keys can be tested as soon as they are = found rather than waiting for all keys to be found): =

1.   Collect =  a= the set = of potentially applicable keys. Sources of keys may include: =

o    Keys = supplied by the application protocol being used. =

o    Keys = referenced by the jku (JWK Set URL) = Header Parameter.

o    The = key provided by the jwk (JSON Web Key) = Header Parameter.

o    The = key referenced by the x5u (X.509 URL) = Header Parameter.

o    The = key provided by the x5c (X.509 = Certificate Chain) Header Parameter.

o    Other = applicable keys available to the application.

The order of = looking at key sources is frequently application dependent both for = order and inclusion.  Frequently all keys from a one set of = locations, such as local caches, will be checked before looking at other = locations. 
 &nbs= p;  

2.   Filter the set = of collected keys. For instance, some applications = will only = use keys = referenced by kid (key ID) or = x5t (X.509 = certificate SHA-1 thumbprint) parameters might be tried by the = application. Keys with inappropriate alg (algorithm), = use (public key = use), or key_ops (key = operations) values would likewise typically be excluded if the = application uses those parameters. Additionally, = keys Keys<= span lang=3DEN style=3D'font-family:"Verdana","sans-serif";color:black'> = might be filtered to include or exclude keys with certain application = specific other = member values. = For some applications, no filtering will be applied. =

3.   Order the set = of collected keys. For instance, keys referenced by kid (Key ID) or = x5t (X.509 = Certificate SHA-1 Thumbprint) parameters might be tried before other = keys trying = keys without a kid value. Likewise, = keys with certain member values might be ordered before keys with other = member values. For some applications, no ordering will be applied. =

4.   Make trust = decisions about the keys. Keys not meeting the application's trust = criteria would not be used. Such criteria might include, but is not = limited to the source of the key, whether the TLS certificate validates = for keys retrieved from URLs, whether a key in an X.509 certificate is = backed by a valid certificate chain, and other information known by the = application.

5.   Attempt = signature or MAC validation for a JWS object or decryption of a JWE = object with some or all of the collected and possibly filtered and/or = ordered keys. A limit on the number of keys to be tried might be = applied. This process will normally terminate following a successful = validation or decryption.

It is reasonable to do the = signature validation prior to doing the trust validation steps as items = which do not validate do not need to have a trust decision = made.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike

 

From:= = jose [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Thursday, January 23, = 2014 12:41 PM
To: draft-i= etf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: = [jose] Appendix D in draft -20

 

I am only = marginally happier with this draft of the document.

 

I do not see = how one can possibly state that steps 1, 3 and 4 are in any way optional = in this algorithm.  The concept of not gathering keys, filtering = out keys that cannot possibly be correct and not checking the signature = of keys makes absolutely no sense to me.  If these steps are to be = considered optional then the reason for them being option must be = clearly documented.

 

My = understanding of x5u says that only a single key referenced by the chain = would be eligible for inclusion in the key set.  If this is not = true then it needs to clarified in the description of x5u.  If it = is true then s/keys/key/ in that description.

 

I need to = have a much better understanding of the statement that you can order = based on the value of the kty value.  As it stands I have no idea = what this means and why one would do such an ordering.

 

I would = probably swap steps 2 and 3 so that one can order with respect to those = keys which are reasonable to look at rather than looking at the entire = building of keys.  As part of this I would move the number of keys = from current step 3 to step 4.

 

If you are =
going to make the statement “Keys with inappropriate =
"alg" (algorithm), "use" (public =
key       use), or "key_ops" =
(key operations) values would =
likewise       typically be =
excluded.” Then you =
need to provide text to tell me under what circumstances I would not be =
excluding them.  My understanding is that they would always be =
excluded and thus this text makes no sense to =
me.
 =
I would =
move the kty filter into the previous sentence.  It them make sense =
to talk about applications filtering based on other values that might be =
more application specific.
 =
I would =
like to see the trust statement moved to a separate item in the list of =
steps.  Again this is something that needs to be done, but it can =
be done after step 4 rather than in the filter process.  The trust =
statement can be made to be more general that what is current stated. =
 That is the trust decision may be made based on internal =
application information, generic information or an external certificate =
validation process.  In some cases the trust decision may be =
determined to be implicit based on the source of the key.  =
  I would make this general rather than specific.  That =
is to say I would say that a binding of trust needs to be made, and the =
following items should be considered in the list of things to be =
included.  This should not and would not be presented as an =
exhaustive list but should be somewhat complete.  That is getting =
this from a jku has a degree of trust that a jkw does not =
have.
 =
Jim
 =
 

 

------=_NextPart_000_01F4_01CF281B.A3AF81D0-- From Michael.Jones@microsoft.com Wed Feb 12 22:09:47 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B92A1A0102 for ; Wed, 12 Feb 2014 22:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGAB0Wrh3TtE for ; Wed, 12 Feb 2014 22:09:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 29EAA1A00F5 for ; Wed, 12 Feb 2014 22:09:38 -0800 (PST) Received: from BY2PR03CA036.namprd03.prod.outlook.com (10.242.234.157) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 13 Feb 2014 06:09:34 +0000 Received: from BL2FFO11FD044.protection.gbl (2a01:111:f400:7c09::144) by BY2PR03CA036.outlook.office365.com (2a01:111:e400:2c2c::29) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Thu, 13 Feb 2014 06:09:34 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD044.mail.protection.outlook.com (10.173.161.140) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 06:09:34 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 06:09:03 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Appendix D in draft -20 Thread-Index: Ac8YdVFWIkzAvGyyToOm/dHc3J4hWQL+/UKwAPVm4gAAA+qcYAACCS8AAAiJDzA= Date: Thu, 13 Feb 2014 06:09:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B1932D1@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B192B02@TK5EX14MBXC288.redmond.corp.microsoft.com> <01f301cf285e$b1cc5930$15650b90$@augustcellars.com> In-Reply-To: <01f301cf285e$b1cc5930$15650b90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B1932D1TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(189002)(199002)(51914003)(377454003)(74876001)(94946001)(93516002)(76482001)(71186001)(93136001)(15975445006)(55846006)(46102001)(53806001)(54356001)(86612001)(74706001)(81542001)(51856001)(6806004)(83072002)(85852003)(69226001)(94316002)(81342001)(56816005)(90146001)(86362001)(74366001)(74662001)(92566001)(20776003)(63696002)(31966008)(84326002)(66066001)(76786001)(76796001)(19580395003)(65816001)(80022001)(85306002)(47446002)(33656001)(15202345003)(59766001)(87936001)(79102001)(512954002)(80976001)(77982001)(2656002)(74502001)(92726001)(4396001)(56776001)(54316002)(47736001)(49866001)(19300405004)(87266001)(44976005)(95416001)(81816001)(95666001)(16236675002)(81686001)(50986001)(77096001)(19580405001)(47976001)(83322001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:EA23F1D4.A33A5791.BDD1BDBB.42669911.20782; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 06:09:47 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B1932D1TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A key being in the list that doesn't follow the application's rules is real= ly just an example of illegal input. Well-written programs handle and reje= ct illegal inputs, whether they be malformed JSON syntax, RSA keys with no = "e" parameter, "kty" values not supported by the application, etc. You can= stretch and try to call error handling "filtering" if you want, but they'r= e really not the same thing. You may think I'm splitting hairs, but I really don't think I am. In the r= eal world, there will be perfectly good apps that just try all the keys. S= ome keys won't work because the signatures don't validate. Some may not wo= rk because the key type isn't supported. Some won't work for other reasons= that perhaps neither of us have thought of. That doesn't make these simpl= e applications broken or non-conformant because they didn't have a key filt= ering step. Thus, there's nothing incorrect or particularly dire about say= ing "For some applications, no filtering will be applied". -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, February 12, 2014 5:56 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, February 12, 2014 5:07 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Thanks for the useful comments, Jim. I've incorporated them, sometimes wit= h small wording changes, in the version below. Hopefully this version will= get us to a draft we both like (or at least, can live with :)). Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms include the following steps. Note that the steps can be pe= rformed in any order and do not need to be treated as distinct. For example= , keys can be tried as soon as they are found, rather than collecting all t= he keys before trying any. 1. Collect the set of potentially applicable keys. Sources of keys may in= clude: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order for collecting and trying keys from different key sources is typi= cally application dependent. For example, frequently all keys from a one se= t of locations, such as local caches, will be tried before collecting and t= rying keys from other locations. 2. Filter the set of collected keys. For instance, some applications will= use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 t= humbprint) parameters. If the application uses the alg (algorithm), use (pu= blic key use), or key_ops (key operations) parameters, keys with keys with = inappropriate values of those parameters would be excluded. Additionally, k= eys might be filtered to include or exclude keys with certain other member = values in an application specific manner. For some applications, no filteri= ng will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before keys with neither of these values. Likewise, keys with certain m= ember values might be ordered before keys with other member values. For som= e applications, no ordering will be applied. 4. Make trust decisions about the keys. Signatures made with keys not mee= ting the application's trust criteria would not be accepted. Such criteria = might include, but is not limited to the source of the key, whether the TLS= certificate validates for keys retrieved from URLs, whether a key in an X.= 509 certificate is backed by a valid certificate chain, and other informati= on known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. Note that it is reasonable for some applications to perform signature or MA= C validation prior to making a trust decision about a key, since keys for w= hich the validation fails need no trust decision. The only suggested action I didn't apply was deleting the sentence "For som= e applications, no filtering will be applied". I didn't delete it because = it's true. For example, an application might specify that all potentially = applicable keys are retrieved from a particular JWK Set, it might specify t= hat only applicable keys may be present there, and that the keys are to be = tried until one succeeds. That's very simple. Such an application doesn't= need, and wouldn't use any of the optional key attribute parameters. They= 'd just use key values, and would try keys until one works. No filtering i= s performed. That is not really true statement - and what happens if key is in the lis= t which is does not follow the rules? Then either things go boom or the fi= ltering step is applied, it is just applied in a really bad way at some lat= er step. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 3:05 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Hi Jim, I've updated my working draft to attempt to address all of your comments be= low. Thanks for the thorough read - as always. Are there any specific rem= aining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms would typically include these steps. (Note: The steps can= be performed in any order and do not need to be treated as distinct, that = is keys can be tested as soon as they are found rather than waiting for all= keys to be found): 1. Collect a the set of potentially applicable keys. Sources of keys may= include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order of looking at key sources is frequently application dependent bot= h for order and inclusion. Frequently all keys from a one set of locations= , such as local caches, will be checked before looking at other locations. 2. Filter the set of collected keys. For instance, some applications will= only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 t= humbprint) parameters might be tried by the application. Keys with inapprop= riate alg (algorithm), use (public key use), or key_ops (key operations) va= lues would likewise typically be excluded if the application uses those par= ameters. Additionally, keys Keys might be filtered to include or exclude ke= ys with certain application specific other member values. For some applicat= ions, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before other keys trying keys without a kid value. Likewise, keys with = certain member values might be ordered before keys with other member values= . For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Keys not meeting the application'= s trust criteria would not be used. Such criteria might include, but is not= limited to the source of the key, whether the TLS certificate validates fo= r keys retrieved from URLs, whether a key in an X.509 certificate is backed= by a valid certificate chain, and other information known by the applicati= on. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. It is reasonable to do the signature validation prior to doing the trust va= lidation steps as items which do not validate do not need to have a trust d= ecision made. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any wa= y optional in this algorithm. The concept of not gathering keys, filtering= out keys that cannot possibly be correct and not checking the signature of= keys makes absolutely no sense to me. If these steps are to be considered= optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain= would be eligible for inclusion in the key set. If this is not true then = it needs to clarified in the description of x5u. If it is true then s/keys= /key/ in that description. I need to have a much better understanding of the statement that you can or= der based on the value of the kty value. As it stands I have no idea what = this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to t= hose keys which are reasonable to look at rather than looking at the entire= building of keys. As part of this I would move the number of keys from cu= rrent step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algo= rithm), "use" (public key use), or "key_ops" (key operations) values = would likewise typically be excluded." Then you need to provide text = to tell me under what circumstances I would not be excluding them. My unde= rstanding is that they would always be excluded and thus this text makes no= sense to me. I would move the kty filter into the previous sentence. It them make sense= to talk about applications filtering based on other values that might be m= ore application specific. I would like to see the trust statement moved to a separate item in the lis= t of steps. Again this is something that needs to be done, but it can be d= one after step 4 rather than in the filter process. The trust statement ca= n be made to be more general that what is current stated. That is the trus= t decision may be made based on internal application information, generic i= nformation or an external certificate validation process. In some cases th= e trust decision may be determined to be implicit based on the source of th= e key. I would make this general rather than specific. That is to say I= would say that a binding of trust needs to be made, and the following item= s should be considered in the list of things to be included. This should n= ot and would not be presented as an exhaustive list but should be somewhat = complete. That is getting this from a jku has a degree of trust that a jkw= does not have. Jim --_000_4E1F6AAD24975D4BA5B16804296739438B1932D1TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A key being in the lis= t that doesn’t follow the application’s rules is really just an= example of illegal input.  Well-written programs handle and reject il= legal inputs, whether they be malformed JSON syntax, RSA keys with no “e” parameter, “kty” values not s= upported by the application, etc.  You can stretch and try to call err= or handling “filtering” if you want, but they’re really n= ot the same thing.

 

You may think I’= m splitting hairs, but I really don’t think I am.  In the real w= orld, there will be perfectly good apps that just try all the keys.  S= ome keys won’t work because the signatures don’t validate. = ; Some may not work because the key type isn’t supported.  Some w= on’t work for other reasons that perhaps neither of us have thought o= f.  That doesn’t make these simple applications broken or non-co= nformant because they didn’t have a key filtering step.  Thus, there’s nothing incorrect or particularly dire about saying “<= /span>For some applications, no filter= ing will be applied”.=

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Wednesday, February 12, 2014 5:56 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Wednesday, February 12, 2014 5:07 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

Thanks for the useful = comments, Jim.  I’ve incorporated them, sometimes with small wor= ding changes, in the version below.  Hopefully this version will get u= s to a draft we both like (or at least, can live with J).

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms include the following steps. Note t= hat the steps can be performed in any order and do not need to be treated a= s distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any.

1.=    Collect the set of poten= tially applicable keys. Sources of keys may include:

o   Keys supplied by the app= lication protocol being used.

o   Keys referenced by the jku (JWK Set URL) Header Parameter.

o   The key provided by the jwk (JSON Web Key) Header Parameter.

o   The key referenced by th= e x5u (X.509 URL) Header Parameter.

o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o   Other applicable keys av= ailable to the application.

The order for collecting and trying keys from different= key sources is typically application dependent. For example, frequently al= l keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations.

2.=    Filter the set of collec= ted keys. For instance, some applications will use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters. If the= application uses the alg (algorithm), use (public key use), or key_ops= (key operations) parameters, keys with keys with inapp= ropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other membe= r values in an application specific manner. For some applications, no filte= ring will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member = values. For some applications, no ordering will be applied.

4.=    Make trust decisions abo= ut the keys. Signatures made with keys not meeting the application's trust = criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate v= alidates for keys retrieved from URLs, whether a key in an X.509 certificat= e is backed by a valid certificate chain, and other information known by th= e application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

Note that it is reasonable for some applications to = perform signature or MAC validation prior to making a trust decision about = a key, since keys for which the validation fails need no trust decision.

 

The only suggested act= ion I didn’t apply was deleting the sentence “For some applications, no filtering will be applied”.  I didn’t delete it because it’s true.  For example, an ap= plication might specify that all potentially applicable keys are retrieved = from a particular JWK Set, it might specify that only applicable keys may b= e present there, and that the keys are to be tried until one succeeds.  That’s very simple.  Such an applicat= ion doesn’t need, and wouldn’t use any of the optional key attr= ibute parameters.  They’d just use key values, and would try key= s until one works.  No filtering is performed.

 

That is not really  t= rue statement – and what happens if  key is in the list which is= does not follow the rules?  Then either things go boom or the filteri= ng step is applied, it is just applied in a really bad way at some later step.

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 3:05 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] Appendix D in draft -20

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Friday, February 07, 2014 6:04 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  Thank= s for the thorough read – as always.  Are there any specific rem= aining edits you’d like to see applied to the following text?

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms would typically include these steps.  = (Note: The steps can be performed in any order and do not need to be treate= d as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found):

1.=    Collect  a the set of potentially = applicable keys. Sources of keys may include:

o   Keys supplied by the app= lication protocol being used.

o   Keys referenced by the jku (JWK Set URL) Header Parameter.

o   The key provided by the jwk (JSON Web Key) Header Parameter.

o   The key referenced by th= e x5u (X.509 URL) Header Parameter.

o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o   Other applicable keys av= ailable to the application.

The order of looking at key sources is frequently applica= tion dependent both for order and inclusion.  Frequently all keys from= a one set of locations, such as local caches, will be checked before looking at other locations. 
    

2.=    Filter the set of collec= ted keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might b= e tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops= (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be = filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered befo= re keys with other member values. For some applications, no ordering will be appli= ed.

4.=    Make trust decisions abo= ut the keys. Keys not meeting the application's trust criteria would not be= used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retr= ieved from URLs, whether a key in an X.509 certificate is backed by a valid= certificate chain, and other information known by the application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

It is reasonable to do the signature = validation prior to doing the trust validation steps as items which do not = validate do not need to have a trust decision made.

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: draft-ietf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: [jose] Appendix D in draft -20

 

I am only marginally happier with this draft of the = document.

 

I do not see how one can possibly state that steps 1= , 3 and 4 are in any way optional in this algorithm.  The concept of n= ot gathering keys, filtering out keys that cannot possibly be correct and n= ot checking the signature of keys makes absolutely no sense to me.  If these steps are to be considered optio= nal then the reason for them being option must be clearly documented.<= /o:p>

 

My understanding of x5u says that only a single key = referenced by the chain would be eligible for inclusion in the key set.&nbs= p; If this is not true then it needs to clarified in the description of x5u= .  If it is true then s/keys/key/ in that description.

 

I need to have a much better understanding of the st= atement that you can order based on the value of the kty value.  As it= stands I have no idea what this means and why one would do such an orderin= g.

 

I would probably swap steps 2 and 3 so that one can = order with respect to those keys which are reasonable to look at rather tha= n looking at the entire building of keys.  As part of this I would mov= e the number of keys from current step 3 to step 4.

 

If you are going to make the statement “Keys=
 with inappropriate "alg" (algorithm), "use" (public ke=
y       use), or "key_ops" (key ope=
rations) values would likewise       typicall=
y be excluded.” Then you need to provide text to tell me=
 under what circumstances I would not be excluding them.  My understan=
ding is that they would always be excluded and thus this text makes no sens=
e to me.
 
I would move the kty filter into the previous sentence.&n=
bsp; It them make sense to talk about applications filtering based on other=
 values that might be more application specific.
 
I would like to see the trust statement moved to a separa=
te item in the list of steps.  Again this is something that needs to b=
e done, but it can be done after step 4 rather than in the filter process.&=
nbsp; The trust statement can be made to be more general that what is curre=
nt stated.  That is the trust decision may be made based on internal a=
pplication information, generic information or an external certificate vali=
dation process.  In some cases the trust decision may be determined to=
 be implicit based on the source of the key.    I would make=
 this general rather than specific.  That is to say I would say that a=
 binding of trust needs to be made, and the following items should be consi=
dered in the list of things to be included.  This should not and would=
 not be presented as an exhaustive list but should be somewhat complete.&nb=
sp; That is getting this from a jku has a degree of trust that a jkw does n=
ot have.
 
Jim
 
 

 

--_000_4E1F6AAD24975D4BA5B16804296739438B1932D1TK5EX14MBXC288r_-- From ietf@augustcellars.com Wed Feb 12 23:04:29 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4E21A010F for ; Wed, 12 Feb 2014 23:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG7NLhDGYcB9 for ; Wed, 12 Feb 2014 23:04:20 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8C41A0125 for ; Wed, 12 Feb 2014 23:04:20 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 5FC9338F02; Wed, 12 Feb 2014 23:04:19 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B192B02@TK5EX14MBXC288.redmond.corp.microsoft.com> <01f301cf285e$b1cc5930$15650b90$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B1932D1@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B1932D1@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 12 Feb 2014 23:02:38 -0800 Message-ID: <022a01cf2889$94b7ae50$be270af0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022B_01CF2846.869C3680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdLd98cNMq+Zl1SjX4G1guFv/McwI03bP+AngbUiABerBx2gJ3lRJFApUjREKbPRP6EA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 07:04:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022B_01CF2846.869C3680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit And it would appear that you do not care about problems such as the Bleichenbacher attack. From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, February 12, 2014 10:09 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 A key being in the list that doesn't follow the application's rules is really just an example of illegal input. Well-written programs handle and reject illegal inputs, whether they be malformed JSON syntax, RSA keys with no "e" parameter, "kty" values not supported by the application, etc. You can stretch and try to call error handling "filtering" if you want, but they're really not the same thing. You may think I'm splitting hairs, but I really don't think I am. In the real world, there will be perfectly good apps that just try all the keys. Some keys won't work because the signatures don't validate. Some may not work because the key type isn't supported. Some won't work for other reasons that perhaps neither of us have thought of. That doesn't make these simple applications broken or non-conformant because they didn't have a key filtering step. Thus, there's nothing incorrect or particularly dire about saying "For some applications, no filtering will be applied". -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, February 12, 2014 5:56 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, February 12, 2014 5:07 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Thanks for the useful comments, Jim. I've incorporated them, sometimes with small wording changes, in the version below. Hopefully this version will get us to a draft we both like (or at least, can live with J). Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts. The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification). These algorithms include the following steps. Note that the steps can be performed in any order and do not need to be treated as distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any. 1. Collect the set of potentially applicable keys. Sources of keys may include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order for collecting and trying keys from different key sources is typically application dependent. For example, frequently all keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations. 2. Filter the set of collected keys. For instance, some applications will use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters. If the application uses the alg (algorithm), use (public key use), or key_ops (key operations) parameters, keys with keys with inappropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other member values in an application specific manner. For some applications, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption. Note that it is reasonable for some applications to perform signature or MAC validation prior to making a trust decision about a key, since keys for which the validation fails need no trust decision. The only suggested action I didn't apply was deleting the sentence "For some applications, no filtering will be applied". I didn't delete it because it's true. For example, an application might specify that all potentially applicable keys are retrieved from a particular JWK Set, it might specify that only applicable keys may be present there, and that the keys are to be tried until one succeeds. That's very simple. Such an application doesn't need, and wouldn't use any of the optional key attribute parameters. They'd just use key values, and would try keys until one works. No filtering is performed. That is not really true statement - and what happens if key is in the list which is does not follow the rules? Then either things go boom or the filtering step is applied, it is just applied in a really bad way at some later step. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 3:05 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Hi Jim, I've updated my working draft to attempt to address all of your comments below. Thanks for the thorough read - as always. Are there any specific remaining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts. The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6 (Key Identification). These algorithms would typically include these steps. (Note: The steps can be performed in any order and do not need to be treated as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found): 1. Collect a the set of potentially applicable keys. Sources of keys may include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order of looking at key sources is frequently application dependent both for order and inclusion. Frequently all keys from a one set of locations, such as local caches, will be checked before looking at other locations. 2. Filter the set of collected keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might be tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Keys not meeting the application's trust criteria would not be used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of a JWE object with some or all of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption. It is reasonable to do the signature validation prior to doing the trust validation steps as items which do not validate do not need to have a trust decision made. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any way optional in this algorithm. The concept of not gathering keys, filtering out keys that cannot possibly be correct and not checking the signature of keys makes absolutely no sense to me. If these steps are to be considered optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain would be eligible for inclusion in the key set. If this is not true then it needs to clarified in the description of x5u. If it is true then s/keys/key/ in that description. I need to have a much better understanding of the statement that you can order based on the value of the kty value. As it stands I have no idea what this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to those keys which are reasonable to look at rather than looking at the entire building of keys. As part of this I would move the number of keys from current step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algorithm), "use" (public key use), or "key_ops" (key operations) values would likewise typically be excluded." Then you need to provide text to tell me under what circumstances I would not be excluding them. My understanding is that they would always be excluded and thus this text makes no sense to me. I would move the kty filter into the previous sentence. It them make sense to talk about applications filtering based on other values that might be more application specific. I would like to see the trust statement moved to a separate item in the list of steps. Again this is something that needs to be done, but it can be done after step 4 rather than in the filter process. The trust statement can be made to be more general that what is current stated. That is the trust decision may be made based on internal application information, generic information or an external certificate validation process. In some cases the trust decision may be determined to be implicit based on the source of the key. I would make this general rather than specific. That is to say I would say that a binding of trust needs to be made, and the following items should be considered in the list of things to be included. This should not and would not be presented as an exhaustive list but should be somewhat complete. That is getting this from a jku has a degree of trust that a jkw does not have. Jim ------=_NextPart_000_022B_01CF2846.869C3680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And it would appear that you do not care about = problems such as the Bleichenbacher attack.

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, February 12, 2014 10:09 PM
To: Jim = Schaad
Cc: jose@ietf.org
Subject: RE: [jose] = Appendix D in draft -20

 

A key being in the list that doesn’t = follow the application’s rules is really just an example of = illegal input.  Well-written programs handle and reject illegal = inputs, whether they be malformed JSON syntax, RSA keys with no = “e” parameter, “kty” values not supported by the = application, etc.  You can stretch and try to call error handling = “filtering” if you want, but they’re really not the = same thing.

 

You may think I’m = splitting hairs, but I really don’t think I am.  In the real = world, there will be perfectly good apps that just try all the = keys.  Some keys won’t work because the signatures = don’t validate.  Some may not work because the key type = isn’t supported.  Some won’t work for other reasons = that perhaps neither of us have thought of.  That doesn’t = make these simple applications broken or non-conformant because they = didn’t have a key filtering step.  Thus, there’s = nothing incorrect or particularly dire about saying “For some applications, no filtering will be applied”.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   -- Mike

 

From:= = Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Wednesday, February 12, 2014 5:56 PM
To: = Mike Jones
Cc: jose@ietf.org
Subject: RE: = [jose] Appendix D in draft -20

 

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Wednesday, February 12, 2014 5:07 = PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: = [jose] Appendix D in draft -20

 

Thanks for the useful comments, Jim.  = I’ve incorporated them, sometimes with small wording changes, in = the version below.  Hopefully this version will get us to a draft = we both like (or at least, can live with J).

 

Appendix D.  Notes on Key = Selection

This appendix = describes a set of possible algorithms for selecting the key to be used = to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance = describes a family of possible algorithms, rather than a single = algorithm, because in different contexts, not all the sources of keys = will be used, they can be tried in different orders, and sometimes not = all the collected keys will be tried; hence, different algorithms will = be used in different application contexts. =

The steps below = are described for illustration purposes only; specific applications can = and are likely to use different algorithms or perform some of the steps = in different orders. Specific applications will frequently have a much = simpler method of determining the keys to use, as there may be one or = two key selection methods that are profiled for the application's use. = This appendix supplements the normative information on key location in = Section 6 (Key Identification).

These = algorithms include the following steps. Note that the steps can be = performed in any order and do not need to be treated as distinct. For = example, keys can be tried as soon as they are found, rather than = collecting all the keys before trying any.

1.   Collect the set = of potentially applicable keys. Sources of keys may include: =

o    Keys = supplied by the application protocol being used. =

o    Keys = referenced by the jku (JWK Set URL) = Header Parameter.

o    The = key provided by the jwk (JSON Web Key) = Header Parameter.

o    The = key referenced by the x5u (X.509 URL) = Header Parameter.

o    The = key provided by the x5c (X.509 = Certificate Chain) Header Parameter.

o    Other = applicable keys available to the application.

The order for = collecting and trying keys from different key sources is typically = application dependent. For example, frequently all keys from a one set = of locations, such as local caches, will be tried before collecting and = trying keys from other locations.

2.   Filter the set = of collected keys. For instance, some applications will use only keys = referenced by kid (key ID) or = x5t (X.509 = certificate SHA-1 thumbprint) parameters. If the application uses = the alg (algorithm), = use (public key = use), or key_ops (key = operations) parameters, keys with keys with inappropriate values of = those parameters would be excluded. Additionally, keys might be filtered = to include or exclude keys with certain other member values in an = application specific manner. For some applications, no filtering will be = applied.

3.   Order the set = of collected keys. For instance, keys referenced by kid (Key ID) or = x5t (X.509 = Certificate SHA-1 Thumbprint) parameters might be tried before keys with = neither of these values. Likewise, keys with certain member values might = be ordered before keys with other member values. For some applications, = no ordering will be applied.

4.   Make trust = decisions about the keys. Signatures made with keys not meeting the = application's trust criteria would not be accepted. Such criteria might = include, but is not limited to the source of the key, whether the TLS = certificate validates for keys retrieved from URLs, whether a key in an = X.509 certificate is backed by a valid certificate chain, and other = information known by the application.

5.   Attempt = signature or MAC validation for a JWS object or decryption of a JWE = object with some or all of the collected and possibly filtered and/or = ordered keys. A limit on the number of keys to be tried might be = applied. This process will normally terminate following a successful = validation or decryption.

Note that it is = reasonable for some applications to perform signature or MAC validation = prior to making a trust decision about a key, since keys for which the = validation fails need no trust decision.

 

The only suggested = action I didn’t apply was deleting the sentence = “For some = applications, no filtering will be applied”.  I didn’t delete it because = it’s true.  For example, an application might specify that = all potentially applicable keys are retrieved from a particular JWK Set, = it might specify that only applicable keys may be present there, and = that the keys are to be tried until one succeeds.  That’s = very simple.  Such an application doesn’t need, and = wouldn’t use any of the optional key attribute parameters.  = They’d just use key values, and would try keys until one = works.  No filtering is performed.

 

That is not really  = true statement – and what happens if  key is in the list = which is does not follow the rules?  Then either things go boom or = the filtering step is applied, it is just applied in a really bad way at = some later step.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   -- Mike

 

From:= = jose [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Wednesday, February 12, = 2014 3:05 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: = [jose] Appendix D in draft -20

 

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Friday, February 07, 2014 6:04 = PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: = [jose] Appendix D in draft -20

 

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  = Thanks for the thorough read – as always.  Are there any = specific remaining edits you’d like to see applied to the = following text?

 

Appendix D.  Notes on Key = Selection

This appendix = describes a set of possible algorithms for selecting the key to be used = to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance = describes a family of possible algorithms, rather than a single = algorithm, because in different contexts, not all the sources of keys = will be used, they can be tried in different orders, and sometimes not = all the collected keys will be tried; hence, different algorithms will = be used in different application contexts. =

The steps below = are described for illustration purposes only; specific applications can = and are likely to use different algorithms or perform some of the steps = in different orders. Specific applications will frequently have a much = simpler method of determining the keys to use, as there may be one or = two key selection methods that are profiled for the application's use. = This appendix supplements the normative information on key location in = Section 6 (Key = Identification).

These = algorithms would typically include these steps.  = (Note: The steps can be performed in any order and do not need to be = treated as distinct, that is keys can be tested as soon as they are = found rather than waiting for all keys to be found): =

1.   Collect =  a= the set = of potentially applicable keys. Sources of keys may include: =

o    Keys = supplied by the application protocol being used. =

o    Keys = referenced by the jku (JWK Set URL) = Header Parameter.

o    The = key provided by the jwk (JSON Web Key) = Header Parameter.

o    The = key referenced by the x5u (X.509 URL) = Header Parameter.

o    The = key provided by the x5c (X.509 = Certificate Chain) Header Parameter.

o    Other = applicable keys available to the application.

The order of = looking at key sources is frequently application dependent both for = order and inclusion.  Frequently all keys from a one set of = locations, such as local caches, will be checked before looking at other = locations. 
 &nbs= p;  

2.   Filter the set = of collected keys. For instance, some applications = will only = use keys = referenced by kid (key ID) or = x5t (X.509 = certificate SHA-1 thumbprint) parameters might be tried by the = application. Keys with inappropriate alg (algorithm), = use (public key = use), or key_ops (key = operations) values would likewise typically be excluded if the = application uses those parameters. Additionally, = keys Keys<= span lang=3DEN style=3D'font-family:"Verdana","sans-serif";color:black'> = might be filtered to include or exclude keys with certain application = specific other = member values. = For some applications, no filtering will be applied. =

3.   Order the set = of collected keys. For instance, keys referenced by kid (Key ID) or = x5t (X.509 = Certificate SHA-1 Thumbprint) parameters might be tried before other = keys trying = keys without a kid value. Likewise, = keys with certain member values might be ordered before keys with other = member values. For some applications, no ordering will be applied. =

4.   Make trust = decisions about the keys. Keys not meeting the application's trust = criteria would not be used. Such criteria might include, but is not = limited to the source of the key, whether the TLS certificate validates = for keys retrieved from URLs, whether a key in an X.509 certificate is = backed by a valid certificate chain, and other information known by the = application.

5.   Attempt = signature or MAC validation for a JWS object or decryption of a JWE = object with some or all of the collected and possibly filtered and/or = ordered keys. A limit on the number of keys to be tried might be = applied. This process will normally terminate following a successful = validation or decryption.

It is reasonable to do the = signature validation prior to doing the trust validation steps as items = which do not validate do not need to have a trust decision = made.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike

 

From:= = jose [mailto:jose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Thursday, January 23, = 2014 12:41 PM
To: draft-i= etf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: = [jose] Appendix D in draft -20

 

I am only = marginally happier with this draft of the document.

 

I do not see = how one can possibly state that steps 1, 3 and 4 are in any way optional = in this algorithm.  The concept of not gathering keys, filtering = out keys that cannot possibly be correct and not checking the signature = of keys makes absolutely no sense to me.  If these steps are to be = considered optional then the reason for them being option must be = clearly documented.

 

My = understanding of x5u says that only a single key referenced by the chain = would be eligible for inclusion in the key set.  If this is not = true then it needs to clarified in the description of x5u.  If it = is true then s/keys/key/ in that description.

 

I need to = have a much better understanding of the statement that you can order = based on the value of the kty value.  As it stands I have no idea = what this means and why one would do such an ordering.

 

I would = probably swap steps 2 and 3 so that one can order with respect to those = keys which are reasonable to look at rather than looking at the entire = building of keys.  As part of this I would move the number of keys = from current step 3 to step 4.

 

If you are =
going to make the statement “Keys with inappropriate =
"alg" (algorithm), "use" (public =
key       use), or "key_ops" =
(key operations) values would =
likewise       typically be =
excluded.” Then you =
need to provide text to tell me under what circumstances I would not be =
excluding them.  My understanding is that they would always be =
excluded and thus this text makes no sense to =
me.
 =
I would =
move the kty filter into the previous sentence.  It them make sense =
to talk about applications filtering based on other values that might be =
more application specific.
 =
I would =
like to see the trust statement moved to a separate item in the list of =
steps.  Again this is something that needs to be done, but it can =
be done after step 4 rather than in the filter process.  The trust =
statement can be made to be more general that what is current stated. =
 That is the trust decision may be made based on internal =
application information, generic information or an external certificate =
validation process.  In some cases the trust decision may be =
determined to be implicit based on the source of the key.  =
  I would make this general rather than specific.  That =
is to say I would say that a binding of trust needs to be made, and the =
following items should be considered in the list of things to be =
included.  This should not and would not be presented as an =
exhaustive list but should be somewhat complete.  That is getting =
this from a jku has a degree of trust that a jkw does not =
have.
 =
Jim
 =
 

 

------=_NextPart_000_022B_01CF2846.869C3680-- From Michael.Jones@microsoft.com Wed Feb 12 23:19:05 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D001B1A0132 for ; Wed, 12 Feb 2014 23:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILw0mdfT6P0i for ; Wed, 12 Feb 2014 23:18:56 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id C70B61A0136 for ; Wed, 12 Feb 2014 23:18:55 -0800 (PST) Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 13 Feb 2014 07:18:47 +0000 Received: from BN1BFFO11FD019.protection.gbl (2a01:111:f400:7c10::1:116) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Thu, 13 Feb 2014 07:18:46 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD019.mail.protection.outlook.com (10.58.144.82) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 07:18:46 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 07:18:20 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Appendix D in draft -20 Thread-Index: Ac8YdVFWIkzAvGyyToOm/dHc3J4hWQL+/UKwAPVm4gAAA+qcYAACCS8AAAiJDzAAAi+8AAAAcbCQ Date: Thu, 13 Feb 2014 07:18:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19349F@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <026601cf187b$6b8bc5c0$42a35140$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B18A416@TK5EX14MBXC288.redmond.corp.microsoft.com> <01a601cf2846$e2d49c80$a87dd580$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B192B02@TK5EX14MBXC288.redmond.corp.microsoft.com> <01f301cf285e$b1cc5930$15650b90$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B1932D1@TK5EX14MBXC288.redmond.corp.microsoft.com> <022a01cf2889$94b7ae50$be270af0$@augustcellars.com> In-Reply-To: <022a01cf2889$94b7ae50$be270af0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19349FTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(189002)(199002)(51914003)(377454003)(74876001)(94946001)(93516002)(76482001)(93136001)(71186001)(15975445006)(55846006)(46102001)(54356001)(86612001)(53806001)(81542001)(74706001)(51856001)(6806004)(83072002)(85852003)(69226001)(94316002)(81342001)(56816005)(90146001)(86362001)(74366001)(74662001)(20776003)(92566001)(63696002)(31966008)(84326002)(66066001)(76786001)(76796001)(19580395003)(65816001)(80022001)(85306002)(47446002)(33656001)(15202345003)(59766001)(87936001)(79102001)(512954002)(80976001)(77982001)(2656002)(74502001)(92726001)(4396001)(56776001)(54316002)(47736001)(49866001)(19300405004)(87266001)(44976005)(95416001)(81816001)(95666001)(16236675002)(81686001)(50986001)(77096001)(19580405001)(47976001)(83322001)(559001)(569005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:EA23F3D4.A33A5791.BDD1BDBB.42E69911.207B1; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Appendix D in draft -20 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 07:19:06 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B19349FTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, I'm asserting that there exist constrained application scenarios in whi= ch the preconditions for the Bleichenbacher attack cannot occur. Are you r= eally asserting that no such constrained use cases are possible? From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 11:03 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 And it would appear that you do not care about problems such as the Bleiche= nbacher attack. From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, February 12, 2014 10:09 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 A key being in the list that doesn't follow the application's rules is real= ly just an example of illegal input. Well-written programs handle and reje= ct illegal inputs, whether they be malformed JSON syntax, RSA keys with no = "e" parameter, "kty" values not supported by the application, etc. You can= stretch and try to call error handling "filtering" if you want, but they'r= e really not the same thing. You may think I'm splitting hairs, but I really don't think I am. In the r= eal world, there will be perfectly good apps that just try all the keys. S= ome keys won't work because the signatures don't validate. Some may not wo= rk because the key type isn't supported. Some won't work for other reasons= that perhaps neither of us have thought of. That doesn't make these simpl= e applications broken or non-conformant because they didn't have a key filt= ering step. Thus, there's nothing incorrect or particularly dire about say= ing "For some applications, no filtering will be applied". -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, February 12, 2014 5:56 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, February 12, 2014 5:07 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Thanks for the useful comments, Jim. I've incorporated them, sometimes wit= h small wording changes, in the version below. Hopefully this version will= get us to a draft we both like (or at least, can live with :)). Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms include the following steps. Note that the steps can be pe= rformed in any order and do not need to be treated as distinct. For example= , keys can be tried as soon as they are found, rather than collecting all t= he keys before trying any. 1. Collect the set of potentially applicable keys. Sources of keys may in= clude: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order for collecting and trying keys from different key sources is typi= cally application dependent. For example, frequently all keys from a one se= t of locations, such as local caches, will be tried before collecting and t= rying keys from other locations. 2. Filter the set of collected keys. For instance, some applications will= use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 t= humbprint) parameters. If the application uses the alg (algorithm), use (pu= blic key use), or key_ops (key operations) parameters, keys with keys with = inappropriate values of those parameters would be excluded. Additionally, k= eys might be filtered to include or exclude keys with certain other member = values in an application specific manner. For some applications, no filteri= ng will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before keys with neither of these values. Likewise, keys with certain m= ember values might be ordered before keys with other member values. For som= e applications, no ordering will be applied. 4. Make trust decisions about the keys. Signatures made with keys not mee= ting the application's trust criteria would not be accepted. Such criteria = might include, but is not limited to the source of the key, whether the TLS= certificate validates for keys retrieved from URLs, whether a key in an X.= 509 certificate is backed by a valid certificate chain, and other informati= on known by the application. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. Note that it is reasonable for some applications to perform signature or MA= C validation prior to making a trust decision about a key, since keys for w= hich the validation fails need no trust decision. The only suggested action I didn't apply was deleting the sentence "For som= e applications, no filtering will be applied". I didn't delete it because = it's true. For example, an application might specify that all potentially = applicable keys are retrieved from a particular JWK Set, it might specify t= hat only applicable keys may be present there, and that the keys are to be = tried until one succeeds. That's very simple. Such an application doesn't= need, and wouldn't use any of the optional key attribute parameters. They= 'd just use key values, and would try keys until one works. No filtering i= s performed. That is not really true statement - and what happens if key is in the lis= t which is does not follow the rules? Then either things go boom or the fi= ltering step is applied, it is just applied in a really bad way at some lat= er step. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 3:05 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Appendix D in draft -20 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 6:04 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Appendix D in draft -20 Hi Jim, I've updated my working draft to attempt to address all of your comments be= low. Thanks for the thorough read - as always. Are there any specific rem= aining edits you'd like to see applied to the following text? Appendix D. Notes on Key Selection This appendix describes a set of possible algorithms for selecting the key = to be used to validate the digital signature or MAC of a JWS object or for = selecting the key to be used to decrypt a JWE object. This guidance describ= es a family of possible algorithms, rather than a single algorithm, because= in different contexts, not all the sources of keys will be used, they can = be tried in different orders, and sometimes not all the collected keys will= be tried; hence, different algorithms will be used in different applicatio= n contexts. The steps below are described for illustration purposes only; specific appl= ications can and are likely to use different algorithms or perform some of = the steps in different orders. Specific applications will frequently have a= much simpler method of determining the keys to use, as there may be one or= two key selection methods that are profiled for the application's use. Thi= s appendix supplements the normative information on key location in Section= 6 (Key Identification). These algorithms would typically include these steps. (Note: The steps can= be performed in any order and do not need to be treated as distinct, that = is keys can be tested as soon as they are found rather than waiting for all= keys to be found): 1. Collect a the set of potentially applicable keys. Sources of keys may= include: o Keys supplied by the application protocol being used. o Keys referenced by the jku (JWK Set URL) Header Parameter. o The key provided by the jwk (JSON Web Key) Header Parameter. o The key referenced by the x5u (X.509 URL) Header Parameter. o The key provided by the x5c (X.509 Certificate Chain) Header Parameter. o Other applicable keys available to the application. The order of looking at key sources is frequently application dependent bot= h for order and inclusion. Frequently all keys from a one set of locations= , such as local caches, will be checked before looking at other locations. 2. Filter the set of collected keys. For instance, some applications will= only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 t= humbprint) parameters might be tried by the application. Keys with inapprop= riate alg (algorithm), use (public key use), or key_ops (key operations) va= lues would likewise typically be excluded if the application uses those par= ameters. Additionally, keys Keys might be filtered to include or exclude ke= ys with certain application specific other member values. For some applicat= ions, no filtering will be applied. 3. Order the set of collected keys. For instance, keys referenced by kid = (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be tr= ied before other keys trying keys without a kid value. Likewise, keys with = certain member values might be ordered before keys with other member values= . For some applications, no ordering will be applied. 4. Make trust decisions about the keys. Keys not meeting the application'= s trust criteria would not be used. Such criteria might include, but is not= limited to the source of the key, whether the TLS certificate validates fo= r keys retrieved from URLs, whether a key in an X.509 certificate is backed= by a valid certificate chain, and other information known by the applicati= on. 5. Attempt signature or MAC validation for a JWS object or decryption of = a JWE object with some or all of the collected and possibly filtered and/or= ordered keys. A limit on the number of keys to be tried might be applied. = This process will normally terminate following a successful validation or d= ecryption. It is reasonable to do the signature validation prior to doing the trust va= lidation steps as items which do not validate do not need to have a trust d= ecision made. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, January 23, 2014 12:41 PM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Appendix D in draft -20 I am only marginally happier with this draft of the document. I do not see how one can possibly state that steps 1, 3 and 4 are in any wa= y optional in this algorithm. The concept of not gathering keys, filtering= out keys that cannot possibly be correct and not checking the signature of= keys makes absolutely no sense to me. If these steps are to be considered= optional then the reason for them being option must be clearly documented. My understanding of x5u says that only a single key referenced by the chain= would be eligible for inclusion in the key set. If this is not true then = it needs to clarified in the description of x5u. If it is true then s/keys= /key/ in that description. I need to have a much better understanding of the statement that you can or= der based on the value of the kty value. As it stands I have no idea what = this means and why one would do such an ordering. I would probably swap steps 2 and 3 so that one can order with respect to t= hose keys which are reasonable to look at rather than looking at the entire= building of keys. As part of this I would move the number of keys from cu= rrent step 3 to step 4. If you are going to make the statement "Keys with inappropriate "alg" (algo= rithm), "use" (public key use), or "key_ops" (key operations) values = would likewise typically be excluded." Then you need to provide text = to tell me under what circumstances I would not be excluding them. My unde= rstanding is that they would always be excluded and thus this text makes no= sense to me. I would move the kty filter into the previous sentence. It them make sense= to talk about applications filtering based on other values that might be m= ore application specific. I would like to see the trust statement moved to a separate item in the lis= t of steps. Again this is something that needs to be done, but it can be d= one after step 4 rather than in the filter process. The trust statement ca= n be made to be more general that what is current stated. That is the trus= t decision may be made based on internal application information, generic i= nformation or an external certificate validation process. In some cases th= e trust decision may be determined to be implicit based on the source of th= e key. I would make this general rather than specific. That is to say I= would say that a binding of trust needs to be made, and the following item= s should be considered in the list of things to be included. This should n= ot and would not be presented as an exhaustive list but should be somewhat = complete. That is getting this from a jku has a degree of trust that a jkw= does not have. Jim --_000_4E1F6AAD24975D4BA5B16804296739438B19349FTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I’m assertin= g that there exist constrained application scenarios in which the precondit= ions for the Bleichenbacher attack cannot occur.  Are you really asser= ting that no such constrained use cases are possible?

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 11:03 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] Appendix D in draft -20

 

And it would appear th= at you do not care about problems such as the Bleichenbacher attack.

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Wednesday, February 12, 2014 10:09 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

A key being in the lis= t that doesn’t follow the application’s rules is really just an= example of illegal input.  Well-written programs handle and reject il= legal inputs, whether they be malformed JSON syntax, RSA keys with no “e” parameter, “kty” values not s= upported by the application, etc.  You can stretch and try to call err= or handling “filtering” if you want, but they’re really n= ot the same thing.

 

You may think I’= m splitting hairs, but I really don’t think I am.  In the real w= orld, there will be perfectly good apps that just try all the keys.  S= ome keys won’t work because the signatures don’t validate. = ; Some may not work because the key type isn’t supported.  Some w= on’t work for other reasons that perhaps neither of us have thought o= f.  That doesn’t make these simple applications broken or non-co= nformant because they didn’t have a key filtering step.  Thus, there’s nothing incorrect or particularly dire about saying “<= /span>For some applications, no filter= ing will be applied”.=

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com= ]
Sent: Wednesday, February 12, 2014 5:56 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Wednesday, February 12, 2014 5:07 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

Thanks for the useful = comments, Jim.  I’ve incorporated them, sometimes with small wor= ding changes, in the version below.  Hopefully this version will get u= s to a draft we both like (or at least, can live with J).

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms include the following steps. Note t= hat the steps can be performed in any order and do not need to be treated a= s distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any.

1.=    Collect the set of poten= tially applicable keys. Sources of keys may include:

o   Keys supplied by the app= lication protocol being used.

o   Keys referenced by the jku (JWK Set URL) Header Parameter.

o   The key provided by the jwk (JSON Web Key) Header Parameter.

o   The key referenced by th= e x5u (X.509 URL) Header Parameter.

o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o   Other applicable keys av= ailable to the application.

The order for collecting and trying keys from different= key sources is typically application dependent. For example, frequently al= l keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations.

2.=    Filter the set of collec= ted keys. For instance, some applications will use only keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters. If the= application uses the alg (algorithm), use (public key use), or key_ops= (key operations) parameters, keys with keys with inapp= ropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other membe= r values in an application specific manner. For some applications, no filte= ring will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member = values. For some applications, no ordering will be applied.

4.=    Make trust decisions abo= ut the keys. Signatures made with keys not meeting the application's trust = criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate v= alidates for keys retrieved from URLs, whether a key in an X.509 certificat= e is backed by a valid certificate chain, and other information known by th= e application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

Note that it is reasonable for some applications to = perform signature or MAC validation prior to making a trust decision about = a key, since keys for which the validation fails need no trust decision.

 

The only suggested act= ion I didn’t apply was deleting the sentence “For some applications, no filtering will be applied”.  I didn’t delete it because it’s true.  For example, an ap= plication might specify that all potentially applicable keys are retrieved = from a particular JWK Set, it might specify that only applicable keys may b= e present there, and that the keys are to be tried until one succeeds.  That’s very simple.  Such an applicat= ion doesn’t need, and wouldn’t use any of the optional key attr= ibute parameters.  They’d just use key values, and would try key= s until one works.  No filtering is performed.

 

That is not really  t= rue statement – and what happens if  key is in the list which is= does not follow the rules?  Then either things go boom or the filteri= ng step is applied, it is just applied in a really bad way at some later step.

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 3:05 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] Appendix D in draft -20

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Friday, February 07, 2014 6:04 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Appendix D in draft -20

 

Hi Jim,

 

I’ve updated my = working draft to attempt to address all of your comments below.  Thank= s for the thorough read – as always.  Are there any specific rem= aining edits you’d like to see applied to the following text?

 

Appendix D.  Notes on Key Selection

This appendix describes a set of possible algorithms= for selecting the key to be used to validate the digital signature or MAC = of a JWS object or for selecting the key to be used to decrypt a JWE object. This guidance describes a family of possible algorithms, rat= her than a single algorithm, because in different contexts, not all the sou= rces of keys will be used, they can be tried in different orders, and somet= imes not all the collected keys will be tried; hence, different algorithms will be used in different appli= cation contexts.

The steps below are described for illustration purpo= ses only; specific applications can and are likely to use different algorit= hms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the= keys to use, as there may be one or two key selection methods that are pro= filed for the application's use. This appendix supplements the normative in= formation on key location in Section 6 (Key Identification).

These algorithms would typically include these steps.  = (Note: The steps can be performed in any order and do not need to be treate= d as distinct, that is keys can be tested as soon as they are found rather than waiting for all keys to be found):

1.=    Collect  a the set of potentially = applicable keys. Sources of keys may include:

o   Keys supplied by the app= lication protocol being used.

o   Keys referenced by the jku (JWK Set URL) Header Parameter.

o   The key provided by the jwk (JSON Web Key) Header Parameter.

o   The key referenced by th= e x5u (X.509 URL) Header Parameter.

o   The key provided by the x5c (X.509 Certificate Chain) Header Parameter.

o   Other applicable keys av= ailable to the application.

The order of looking at key sources is frequently applica= tion dependent both for order and inclusion.  Frequently all keys from= a one set of locations, such as local caches, will be checked before looking at other locations. 
    

2.=    Filter the set of collec= ted keys. For instance, some applications will only use keys referenced by kid (key ID) or x5t (X.509 certificate SHA-1 thumbprint) parameters might b= e tried by the application. Keys with inappropriate alg (algorithm), use (public key use), or key_ops= (key operations) values would likewise typically be excluded if the application uses those parameters. Additionally, keys Keys might be = filtered to include or exclude keys with certain application specific other member values. For some applications, no filtering will be applied.

3.=    Order the set of collect= ed keys. For instance, keys referenced by kid (Key ID) or x5t (X.509 Certificate SHA-1 Thumbprint) parameters might be t= ried before other keys trying keys without a kid value. Likewise, keys with certain member values might be ordered befo= re keys with other member values. For some applications, no ordering will be appli= ed.

4.=    Make trust decisions abo= ut the keys. Keys not meeting the application's trust criteria would not be= used. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retr= ieved from URLs, whether a key in an X.509 certificate is backed by a valid= certificate chain, and other information known by the application.

5.=    Attempt signature or MAC= validation for a JWS object or decryption of a JWE object with some or all= of the collected and possibly filtered and/or ordered keys. A limit on the number of keys to be tried might be applied. This process w= ill normally terminate following a successful validation or decryption.

It is reasonable to do the signature = validation prior to doing the trust validation steps as items which do not = validate do not need to have a trust decision made.

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, January 23, 2014 12:41 PM
To: draft-ietf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: [jose] Appendix D in draft -20

 

I am only marginally happier with this draft of the = document.

 

I do not see how one can possibly state that steps 1= , 3 and 4 are in any way optional in this algorithm.  The concept of n= ot gathering keys, filtering out keys that cannot possibly be correct and n= ot checking the signature of keys makes absolutely no sense to me.  If these steps are to be considered optio= nal then the reason for them being option must be clearly documented.<= /o:p>

 

My understanding of x5u says that only a single key = referenced by the chain would be eligible for inclusion in the key set.&nbs= p; If this is not true then it needs to clarified in the description of x5u= .  If it is true then s/keys/key/ in that description.

 

I need to have a much better understanding of the st= atement that you can order based on the value of the kty value.  As it= stands I have no idea what this means and why one would do such an orderin= g.

 

I would probably swap steps 2 and 3 so that one can = order with respect to those keys which are reasonable to look at rather tha= n looking at the entire building of keys.  As part of this I would mov= e the number of keys from current step 3 to step 4.

 

If you are going to make the statement “Keys=
 with inappropriate "alg" (algorithm), "use" (public ke=
y       use), or "key_ops" (key ope=
rations) values would likewise       typicall=
y be excluded.” Then you need to provide text to tell me=
 under what circumstances I would not be excluding them.  My understan=
ding is that they would always be excluded and thus this text makes no sens=
e to me.
 
I would move the kty filter into the previous sentence.&n=
bsp; It them make sense to talk about applications filtering based on other=
 values that might be more application specific.
 
I would like to see the trust statement moved to a separa=
te item in the list of steps.  Again this is something that needs to b=
e done, but it can be done after step 4 rather than in the filter process.&=
nbsp; The trust statement can be made to be more general that what is curre=
nt stated.  That is the trust decision may be made based on internal a=
pplication information, generic information or an external certificate vali=
dation process.  In some cases the trust decision may be determined to=
 be implicit based on the source of the key.    I would make=
 this general rather than specific.  That is to say I would say that a=
 binding of trust needs to be made, and the following items should be consi=
dered in the list of things to be included.  This should not and would=
 not be presented as an exhaustive list but should be somewhat complete.&nb=
sp; That is getting this from a jku has a degree of trust that a jkw does n=
ot have.
 
Jim
 
 

 

--_000_4E1F6AAD24975D4BA5B16804296739438B19349FTK5EX14MBXC288r_-- From Michael.Jones@microsoft.com Wed Feb 12 23:29:47 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9679E1A013C for ; Wed, 12 Feb 2014 23:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDsTzieodKjU for ; Wed, 12 Feb 2014 23:29:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id E6BE91A013A for ; Wed, 12 Feb 2014 23:29:44 -0800 (PST) Received: from DM2PR03CA004.namprd03.prod.outlook.com (10.141.52.152) by BN1PR03MB053.namprd03.prod.outlook.com (10.255.225.149) with Microsoft SMTP Server (TLS) id 15.0.883.10; Thu, 13 Feb 2014 07:29:42 +0000 Received: from BN1BFFO11FD009.protection.gbl (2a01:111:f400:7c10::1:114) by DM2PR03CA004.outlook.office365.com (2a01:111:e400:2414::24) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Thu, 13 Feb 2014 07:29:42 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD009.mail.protection.outlook.com (10.58.144.72) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 07:29:42 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 07:29:10 +0000 From: Mike Jones To: Jim Schaad , 'Richard Barnes' , "'Brian Campbell'" Thread-Topic: [jose] question about the size of coordinate parameters in EC JWKs Thread-Index: AQHPKF4lBT/5khFCvU2VE8rpF+FGMJqyyQgg Date: Thu, 13 Feb 2014 07:29:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19352A@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <01ee01cf285d$d8df34d0$8a9d9e70$@augustcellars.com> In-Reply-To: <01ee01cf285d$d8df34d0$8a9d9e70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19352ATK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(377454003)(24454002)(199002)(189002)(51884002)(162972?= =?us-ascii?Q?15004)(15202345003)(81542001)(74366001)(74706001)(76796001)(?= =?us-ascii?Q?76786001)(74876001)(6806004)(80022001)(65816001)(71186001)(5?= =?us-ascii?Q?5846006)(79102001)(59766001)(74662001)(47446002)(31966008)(6?= =?us-ascii?Q?3696002)(19300405004)(44976005)(53806001)(512954002)(5431600?= =?us-ascii?Q?2)(46102001)(51856001)(76482001)(54356001)(56776001)(7798200?= =?us-ascii?Q?1)(20776003)(66066001)(86362001)(93516002)(77096001)(9431600?= =?us-ascii?Q?2)(80976001)(93136001)(16236675002)(19580395003)(83322001)(1?= =?us-ascii?Q?9580405001)(74502001)(95416001)(94946001)(85306002)(69226001?= =?us-ascii?Q?)(2656002)(81342001)(47976001)(49866001)(47736001)(81816001)?= =?us-ascii?Q?(81686001)(92566001)(15975445006)(33656001)(56816005)(927260?= =?us-ascii?Q?01)(95666001)(87936001)(90146001)(4396001)(86612001)(5098600?= =?us-ascii?Q?1)(224303002)(224313003)(83072002)(87266001)(84326002);DIR:O?= =?us-ascii?Q?UT;SFP:1101;SCL:1;SRVR:BN1PR03MB053;H:mail.microsoft.com;CLI?= =?us-ascii?Q?P:131.107.125.37;FPR:EC70F5BF.A73241E9.71F37D7B.4EE99B40.203?= =?us-ascii?Q?23;MLV:sfv;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 07:29:48 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B19352ATK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure. See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-2= 0#section-6.2.1.2 and 6.2.1.3. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 5:50 PM To: 'Richard Barnes'; 'Brian Campbell' Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC = JWKs Would it be possible for somebody to give me a better reference pointer to = the document that is begin reference? From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, February 12, 2014 4:28 PM To: Brian Campbell Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC = JWKs That would make sense only for binary curves, but most of the curves people= use today are integer curves, in which case truncation is totally sensible= . I've been told that some Microsoft crypto libraries use fixed-length buffer= s for these things, but there should be a problem copying a shorter value i= nto that buffer. Net of that, I would be in favor of saying that the coordinates MUST be ful= l-length for binary curves, and MAY be zero-padded to full length for integ= er curves. --Richard On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell > wrote: Could anyone in this fine WG explain (probably again, I missed it the first= time) the rational behind the text 'The length of this octet string MUST b= e the full size of a coordinate for the curve specified in the "crv" parame= ter.', which is in the definitions of the X and Y Coordinate parameters for= EC keys in JWA [1]? This message last month on the list http://www.ietf.org/mail-archive/web/jo= se/current/msg03901.html and an off list message indicate that both the jos= e4j and Nimbus JOSE+JWT implementations aren't following spec on the length= of the octet string being the full size of a coordinate for the curve. Whi= ch suggests that there maybe potential interoperability problems with certa= in EC JWKs. I'm just trying to wrap my head around the issue so any help in that would = be appreciated. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#secti= on-6.2 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739438B19352ATK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 <= /p>

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

 <= /p>

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible for = somebody to give me a better reference pointer to the document that is begi= n reference?

 <= /p>

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto libraries = use fixed-length buffers for these things, but there should be a problem co= pying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size of a = coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X and = Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT impl= ementations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue so = any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739438B19352ATK5EX14MBXC288r_-- From Michael.Jones@microsoft.com Wed Feb 12 23:40:09 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC81A0141 for ; Wed, 12 Feb 2014 23:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFApo7sJgtNu for ; Wed, 12 Feb 2014 23:40:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id C277A1A0140 for ; Wed, 12 Feb 2014 23:40:04 -0800 (PST) Received: from BLUPR03CA036.namprd03.prod.outlook.com (10.141.30.29) by BLUPR03MB003.namprd03.prod.outlook.com (10.255.208.37) with Microsoft SMTP Server (TLS) id 15.0.878.16; Thu, 13 Feb 2014 07:40:02 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::194) by BLUPR03CA036.outlook.office365.com (2a01:111:e400:879::29) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Thu, 13 Feb 2014 07:40:02 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 07:40:01 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 07:39:37 +0000 From: Mike Jones To: Jim Schaad , 'Richard Barnes' , 'Brian Campbell' Thread-Topic: [jose] question about the size of coordinate parameters in EC JWKs Thread-Index: Ac8ojrvYquw8QpZWR5aaaKI/3Uexgg== Date: Thu, 13 Feb 2014 07:39:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19359D@TK5EX14MBXC288.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.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19359DTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(24454002)(243025003)(199002)(189002)(51884002)(377454?= =?us-ascii?Q?003)(65816001)(63696002)(20776003)(512954002)(47736001)(4396?= =?us-ascii?Q?001)(50986001)(47976001)(49866001)(19300405004)(81686001)(56?= =?us-ascii?Q?816005)(90146001)(80022001)(95666001)(66066001)(77096001)(15?= =?us-ascii?Q?975445006)(87936001)(69226001)(85306002)(81816001)(76176001)?= =?us-ascii?Q?(81542001)(93136001)(16236675002)(44976005)(71186001)(935160?= =?us-ascii?Q?02)(31966008)(76796001)(81342001)(87266001)(46102001)(925660?= =?us-ascii?Q?01)(2656002)(95416001)(94316002)(86362001)(94946001)(9272600?= =?us-ascii?Q?1)(54356001)(51856001)(53806001)(54316002)(33656001)(5584600?= =?us-ascii?Q?6)(74366001)(79102001)(86612001)(76482001)(76786001)(5976600?= =?us-ascii?Q?1)(77982001)(84326002)(19580405001)(74706001)(19580395003)(8?= =?us-ascii?Q?3322001)(6806004)(83072002)(74876001)(80976001)(47446002)(74?= =?us-ascii?Q?662001)(74502001)(16297215004)(56776001)(15202345003);DIR:OU?= =?us-ascii?Q?T;SFP:1101;SCL:1;SRVR:BLUPR03MB003;H:mail.microsoft.com;CLIP?= =?us-ascii?Q?:131.107.125.37;FPR:2C70F1BC.AB3251C9.71F37DBB.4EE9DB43.203B?= =?us-ascii?Q?C;MLV:sfv;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 07:40:09 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B19359DTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) req= uires that the full octet string be present, and we decided to base our rep= resentation on SEC1. For instance, SEC1 says: 2.1. Convert the field element xP to an octet string X of length ceiling(lo= g2 q/8) octets using the conversion routine specified in Section 2.3.5. and in SEC1 2.3.5: Input: An element a of the field Fq. Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets. There's no compelling reason to special-case the situation in which some of= the leading bits in the field element are zeros. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, February 12, 2014 11:29 PM To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell' Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC = JWKs Sure. See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-2= 0#section-6.2.1.2 and 6.2.1.3. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, February 12, 2014 5:50 PM To: 'Richard Barnes'; 'Brian Campbell' Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC = JWKs Would it be possible for somebody to give me a better reference pointer to = the document that is begin reference? From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, February 12, 2014 4:28 PM To: Brian Campbell Cc: jose@ietf.org Subject: Re: [jose] question about the size of coordinate parameters in EC = JWKs That would make sense only for binary curves, but most of the curves people= use today are integer curves, in which case truncation is totally sensible= . I've been told that some Microsoft crypto libraries use fixed-length buffer= s for these things, but there should be a problem copying a shorter value i= nto that buffer. Net of that, I would be in favor of saying that the coordinates MUST be ful= l-length for binary curves, and MAY be zero-padded to full length for integ= er curves. --Richard On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell > wrote: Could anyone in this fine WG explain (probably again, I missed it the first= time) the rational behind the text 'The length of this octet string MUST b= e the full size of a coordinate for the curve specified in the "crv" parame= ter.', which is in the definitions of the X and Y Coordinate parameters for= EC keys in JWA [1]? This message last month on the list http://www.ietf.org/mail-archive/web/jo= se/current/msg03901.html and an off list message indicate that both the jos= e4j and Nimbus JOSE+JWT implementations aren't following spec on the length= of the octet string being the full size of a coordinate for the curve. Whi= ch suggests that there maybe potential interoperability problems with certa= in EC JWKs. I'm just trying to wrap my head around the issue so any help in that would = be appreciated. [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#secti= on-6.2 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739438B19359DTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll also add that = SEC1 (http://www.= secg.org/collateral/sec1_final.pdf) requires that the full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 <= /p>

2.1. Convert the field= element xP to an octet string = X of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 <= /p>

and in SEC1 2.3.5:

 <= /p>

Input: An eleme= nt a of the field Fq.

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.

 <= /p>

There’s no compelli= ng reason to special-case the situation in which some of the leading bits i= n the field element are zeros.

 <= /p>

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

 <= /p>

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 <= /p>

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

 <= /p>

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible for = somebody to give me a better reference pointer to the document that is begi= n reference?

 <= /p>

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto libraries = use fixed-length buffers for these things, but there should be a problem co= pying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size of a = coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X and = Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT impl= ementations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue so = any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739438B19359DTK5EX14MBXC288r_-- From rlb@ipv.sx Thu Feb 13 07:45:33 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7B41A020D for ; Thu, 13 Feb 2014 07:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNuL6CiT76WQ for ; Thu, 13 Feb 2014 07:45:30 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF451A01F7 for ; Thu, 13 Feb 2014 07:45:30 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id va2so12464264obc.12 for ; Thu, 13 Feb 2014 07:45:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PiWXF9TzZO3NRqztrgwRLA6y/kuzdh8dvB2a9hxhJSo=; b=Axj8oJ2V+fYQvvHQIv33gJBecdtLdceUR4KiUaLl477lz2k+ZjR/XvD/7eNI5g8F6B cFn1rhiA8CT1essmlCAlLqSVIm6FaRe+Zkj1Qu3TcM+ZqlsZKEpE9qiyv7XBihR5VC6t O4N55tzQoeAqrx09Si8gTIHXly/i152+6T8LzwvNqXYrexNPEDJ6Rnz1XQPrc3FlSSxv 02dv41rugV/MC6CiTrP/KPBu4RJzQUunMhowSQZVxJFquUiBR/zlXSu8o7I977YZo6bd kdw5d7hg78ao17McUGbQ9RKjKaE6kTUbfQpTPy8RDopUy1LZC0nROnzQM3gSKLkzNq5x BBsw== X-Gm-Message-State: ALoCoQl+GsumqwX7DiL10jg7Slzkn6hFKhI4Bd6F8ci/bJ+Ps4XTkWp3nYLWRAECBOc6cFF53Pd6 MIME-Version: 1.0 X-Received: by 10.182.241.8 with SMTP id we8mr1794300obc.62.1392306328729; Thu, 13 Feb 2014 07:45:28 -0800 (PST) Received: by 10.60.69.102 with HTTP; Thu, 13 Feb 2014 07:45:28 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B19359D@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739438B19359D@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Thu, 13 Feb 2014 10:45:28 -0500 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c322c024950e04f24b9431 Cc: Jim Schaad , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:45:33 -0000 --001a11c322c024950e04f24b9431 Content-Type: text/plain; charset=ISO-8859-1 Consistency with SEC1 seems like a compelling enough argument to me. On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones wrote: > I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) > requires that the full octet string be present, and we decided to base our > representation on SEC1. For instance, SEC1 says: > > > > 2.1. Convert the field element * x**P *to an octet string *X *of length > ceiling(log2 *q*/8) octets using the conversion > > routine specified in Section 2.3.5. > > > > and in SEC1 2.3.5: > > > > *Input: *An element *a * of the field F*q*. > > *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) > octets. > > > > There's no compelling reason to special-case the situation in which some > of the leading bits in the field element are zeros. > > > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Wednesday, February 12, 2014 11:29 PM > *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' > > *Cc:* jose@ietf.org > *Subject:* Re: [jose] question about the size of coordinate parameters in > EC JWKs > > > > Sure. See > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. > > > > -- Mike > > > > *From:* jose [mailto:jose-bounces@ietf.org ] *On > Behalf Of *Jim Schaad > *Sent:* Wednesday, February 12, 2014 5:50 PM > *To:* 'Richard Barnes'; 'Brian Campbell' > *Cc:* jose@ietf.org > *Subject:* Re: [jose] question about the size of coordinate parameters in > EC JWKs > > > > Would it be possible for somebody to give me a better reference pointer to > the document that is begin reference? > > > > *From:* jose [mailto:jose-bounces@ietf.org ] *On > Behalf Of *Richard Barnes > *Sent:* Wednesday, February 12, 2014 4:28 PM > *To:* Brian Campbell > *Cc:* jose@ietf.org > *Subject:* Re: [jose] question about the size of coordinate parameters in > EC JWKs > > > > That would make sense only for binary curves, but most of the curves > people use today are integer curves, in which case truncation is totally > sensible. > > > > I've been told that some Microsoft crypto libraries use fixed-length > buffers for these things, but there should be a problem copying a shorter > value into that buffer. > > > > Net of that, I would be in favor of saying that the coordinates MUST be > full-length for binary curves, and MAY be zero-padded to full length for > integer curves. > > > > --Richard > > > > On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > Could anyone in this fine WG explain (probably again, I missed it the > first time) the rational behind the text 'The length of this octet string > MUST be the full size of a coordinate for the curve specified in the "crv" > parameter.', which is in the definitions of the X and Y Coordinate > parameters for EC keys in JWA [1]? > > This message last month on the list > http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an > off list message indicate that both the jose4j and Nimbus JOSE+JWT > implementations aren't following spec on the length of the octet string > being the full size of a coordinate for the curve. Which suggests that > there maybe potential interoperability problems with certain EC JWKs. > > I'm just trying to wrap my head around the issue so any help in that would > be appreciated. > > > [1] > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > --001a11c322c024950e04f24b9431 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:

I’ll also add that = SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires that the= full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 

2.1. Convert the field= element xP to an octet string = X of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 

and in SEC1 2.3.5:=

 

Input: An eleme= nt a of the field Fq.

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.<= /p>

 

There’s no compelli= ng reason to special-case the situation in which some of the leading bits i= n the field element are zeros.

 

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

 

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 

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

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible for = somebody to give me a better reference pointer to the document that is begi= n reference?

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 <= /p>

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size o= f a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 


--001a11c322c024950e04f24b9431-- From nobody Thu Feb 13 12:00:31 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E001A04EB for ; Thu, 13 Feb 2014 12:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GudsdCzpp8v2 for ; Thu, 13 Feb 2014 12:00:24 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 545791A04B3 for ; Thu, 13 Feb 2014 12:00:17 -0800 (PST) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUv0kUPLmnMcHcTmDNLDOaj8VHPO5hck+@postini.com; Thu, 13 Feb 2014 12:00:16 PST Received: by mail-ie0-f180.google.com with SMTP id ar20so494828iec.39 for ; Thu, 13 Feb 2014 12:00:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZtZnKYmmJ3TFheyAaCaKH5SAi4HZbz1iCjbTUZkZaOA=; b=kd0uGgCY+KucidWvhf4xFfUU+V5m0NilMM7YmBgcYShO4HOE3nMRHGdrX3zwA0+XHt lKbZlO0Od29fAbX//eQ1J6UQwIi9vbf8etgZBZjtD39opwj13V625Qa2GIKA6q1ChFJw y6ONxTsIc3loSlUUWJG0BngqEa22KWhiA8Y57O/ak1cHJGPE0asvB0zHL4koIqSYjCur uKkgYKfKQ7d+hnY4umvypQCSsgg9a4dOHW0CYGU6Ys77TinbqiETXNDjTDaHKVbFrSUp X93CvOEoD5ZmN3xGgoRRVy+HEX94KDgRsxFQpxEtPlq9JnYeOQm4kqORlqLSjnlYmjIt JoLw== X-Gm-Message-State: ALoCoQmp8V72DBeroWo9Ygki7Su11lvul42Tiw7gUgNKoEgINgF9qeFyBD+6JSFr2Fk6S/79oJ1yWZXpFBH7UbkROsvinMns8mIgdMOBPZ0amD/1/uMquu3keP3A5vE1l8+kvcQ3i/mFjEAx20ar6YNAbJFU408BkQ== X-Received: by 10.50.47.110 with SMTP id c14mr5307217ign.4.1392321615309; Thu, 13 Feb 2014 12:00:15 -0800 (PST) X-Received: by 10.50.47.110 with SMTP id c14mr5307198ign.4.1392321614941; Thu, 13 Feb 2014 12:00:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.65.4 with HTTP; Thu, 13 Feb 2014 11:59:44 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739438B19359D@TK5EX14MBXC288.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 13 Feb 2014 12:59:44 -0700 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=089e013d0dca45b48204f24f23fb Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Ja_h-PU3jXPkale_F2irIVJvXIo Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:00:31 -0000 --089e013d0dca45b48204f24f23fb Content-Type: text/plain; charset=ISO-8859-1 I wasn't necessarily looking to make a change. Though interoperability is in sometimes in the eye of the beholder. Yes, I realize it's a defect but my implementation currently emits the coordinate value omitting the left zero padding bytes but will accept either input. So the MAY that Richard proposed would likely improve interoperability for me. It's not a hill I want to die on though so I'll zero-pad some arrays in my implementation. On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes wrote: > Consistency with SEC1 seems like a compelling enough argument to me. > > > On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones wrote: > >> I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) >> requires that the full octet string be present, and we decided to base our >> representation on SEC1. For instance, SEC1 says: >> >> >> >> 2.1. Convert the field element * x**P *to an octet string *X *of length >> ceiling(log2 *q*/8) octets using the conversion >> >> routine specified in Section 2.3.5. >> >> >> >> and in SEC1 2.3.5: >> >> >> >> *Input: *An element *a * of the field F*q*. >> >> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) >> octets. >> >> >> >> There's no compelling reason to special-case the situation in which some >> of the leading bits in the field element are zeros. >> >> >> >> -- Mike >> >> >> >> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >> *Sent:* Wednesday, February 12, 2014 11:29 PM >> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >> >> *Cc:* jose@ietf.org >> *Subject:* Re: [jose] question about the size of coordinate parameters >> in EC JWKs >> >> >> >> Sure. See >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. >> >> >> >> -- Mike >> >> >> >> *From:* jose [mailto:jose-bounces@ietf.org ] *On >> Behalf Of *Jim Schaad >> *Sent:* Wednesday, February 12, 2014 5:50 PM >> *To:* 'Richard Barnes'; 'Brian Campbell' >> *Cc:* jose@ietf.org >> *Subject:* Re: [jose] question about the size of coordinate parameters >> in EC JWKs >> >> >> >> Would it be possible for somebody to give me a better reference pointer >> to the document that is begin reference? >> >> >> >> *From:* jose [mailto:jose-bounces@ietf.org ] *On >> Behalf Of *Richard Barnes >> *Sent:* Wednesday, February 12, 2014 4:28 PM >> *To:* Brian Campbell >> *Cc:* jose@ietf.org >> *Subject:* Re: [jose] question about the size of coordinate parameters >> in EC JWKs >> >> >> >> That would make sense only for binary curves, but most of the curves >> people use today are integer curves, in which case truncation is totally >> sensible. >> >> >> >> I've been told that some Microsoft crypto libraries use fixed-length >> buffers for these things, but there should be a problem copying a shorter >> value into that buffer. >> >> >> >> Net of that, I would be in favor of saying that the coordinates MUST be >> full-length for binary curves, and MAY be zero-padded to full length for >> integer curves. >> >> >> >> --Richard >> >> >> >> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> Could anyone in this fine WG explain (probably again, I missed it the >> first time) the rational behind the text 'The length of this octet string >> MUST be the full size of a coordinate for the curve specified in the "crv" >> parameter.', which is in the definitions of the X and Y Coordinate >> parameters for EC keys in JWA [1]? >> >> This message last month on the list >> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an >> off list message indicate that both the jose4j and Nimbus JOSE+JWT >> implementations aren't following spec on the length of the octet string >> being the full size of a coordinate for the curve. Which suggests that >> there maybe potential interoperability problems with certain EC JWKs. >> >> I'm just trying to wrap my head around the issue so any help in that >> would be appreciated. >> >> >> [1] >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> > > --089e013d0dca45b48204f24f23fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I wasn't necessarily looking to make a change. Though = interoperability is in sometimes in the eye of the beholder. Yes, I realize= it's a defect but my implementation currently emits the coordinate val= ue omitting the left zero padding bytes but will accept either input. So th= e MAY that Richard proposed would likely improve interoperability for me. I= t's not a hill I want to die on though so I'll zero-pad some arrays= in my implementation.


On Thu,= Feb 13, 2014 at 8:45 AM, Richard Barnes <rlb@ipv.sx> wrote:
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM,= Mike Jones <Michael.Jones@microsoft.com> wrote:

I’ll also add that = SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires that the= full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 

2.1. Convert the field= element xP to an octet string = X of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 

and in SEC1 2.3.5:=

 

Input: An eleme= nt a of the field Fq.

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.<= /p>

 

There’s no compelli= ng reason to special-case the situation in which some of the leading bits i= n the field element are zeros.

 

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

 

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 

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

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible for = somebody to give me a better reference pointer to the document that is begi= n reference?

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 <= /p>

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size o= f a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 



--089e013d0dca45b48204f24f23fb-- From nobody Thu Feb 13 12:33:10 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F02C1A04BF for ; Thu, 13 Feb 2014 12:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlQvdVNYB5wZ for ; Thu, 13 Feb 2014 12:33:05 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C3D851A046C for ; Thu, 13 Feb 2014 12:33:05 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wm4so12977392obc.27 for ; Thu, 13 Feb 2014 12:33:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+yGkU9P7dUzP8PCj7mDTsj57hE+bE/dLgJriU59ufZA=; b=DWZmMCgJhS07503cmrW1cqFB2yIAveWvlel23pOGyvcecrbDkbeYsKgYTZ6HAINVDD lRSViyaGNoBUsfoaa2JYIYL7gcrpwwlAEoaHENnlKsUgWm0uqgquY0WOEfB0KTWh5dhG hsP+ZK0DJN/atIBuO/hMOFgQnPAEgmFQagwPw7AoCMsbz2cW+TAwI01yzDVc6Qn0VsT2 SNHGQeciaJ0ago931SeUV6sGZeCn0sSkIuvKarjr+oj4KzodjeyIknWeuXgW79EFgnCg 4OdzL0FDvK40hBMZPmB3HrjQSNBfUC3FXL/QePmvElyJ4B2DtJwRcCX/TjfKLS9EuRx8 E5dw== X-Gm-Message-State: ALoCoQniD6sRL4iRdUK3LPTABCKb0wgV1hYS+kOWti6l9OH1w/CS8olNpZ46m4cG1FLIrt68rHoN MIME-Version: 1.0 X-Received: by 10.182.117.195 with SMTP id kg3mr2831053obb.17.1392323582020; Thu, 13 Feb 2014 12:33:02 -0800 (PST) Received: by 10.60.69.102 with HTTP; Thu, 13 Feb 2014 12:33:01 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739438B19359D@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Thu, 13 Feb 2014 15:33:01 -0500 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=089e0149c50684e34c04f24f98e6 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/cs9mmzF3Ggr0iX5rP1pWAzvhQBA Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:33:08 -0000 --089e0149c50684e34c04f24f98e6 Content-Type: text/plain; charset=ISO-8859-1 It sounds to me like your approach is the best behavior for an implementation. Postel's law and all. On Thu, Feb 13, 2014 at 2:59 PM, Brian Campbell wrote: > I wasn't necessarily looking to make a change. Though interoperability is > in sometimes in the eye of the beholder. Yes, I realize it's a defect but > my implementation currently emits the coordinate value omitting the left > zero padding bytes but will accept either input. So the MAY that Richard > proposed would likely improve interoperability for me. It's not a hill I > want to die on though so I'll zero-pad some arrays in my implementation. > > > On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes wrote: > >> Consistency with SEC1 seems like a compelling enough argument to me. >> >> >> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones wrote: >> >>> I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) >>> requires that the full octet string be present, and we decided to base our >>> representation on SEC1. For instance, SEC1 says: >>> >>> >>> >>> 2.1. Convert the field element * x**P *to an octet string *X *of length >>> ceiling(log2 *q*/8) octets using the conversion >>> >>> routine specified in Section 2.3.5. >>> >>> >>> >>> and in SEC1 2.3.5: >>> >>> >>> >>> *Input: *An element *a * of the field F*q*. >>> >>> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) >>> octets. >>> >>> >>> >>> There's no compelling reason to special-case the situation in which some >>> of the leading bits in the field element are zeros. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >>> *Sent:* Wednesday, February 12, 2014 11:29 PM >>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >>> >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] question about the size of coordinate parameters >>> in EC JWKs >>> >>> >>> >>> Sure. See >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>> Behalf Of *Jim Schaad >>> *Sent:* Wednesday, February 12, 2014 5:50 PM >>> *To:* 'Richard Barnes'; 'Brian Campbell' >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] question about the size of coordinate parameters >>> in EC JWKs >>> >>> >>> >>> Would it be possible for somebody to give me a better reference pointer >>> to the document that is begin reference? >>> >>> >>> >>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>> Behalf Of *Richard Barnes >>> *Sent:* Wednesday, February 12, 2014 4:28 PM >>> *To:* Brian Campbell >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] question about the size of coordinate parameters >>> in EC JWKs >>> >>> >>> >>> That would make sense only for binary curves, but most of the curves >>> people use today are integer curves, in which case truncation is totally >>> sensible. >>> >>> >>> >>> I've been told that some Microsoft crypto libraries use fixed-length >>> buffers for these things, but there should be a problem copying a shorter >>> value into that buffer. >>> >>> >>> >>> Net of that, I would be in favor of saying that the coordinates MUST be >>> full-length for binary curves, and MAY be zero-padded to full length for >>> integer curves. >>> >>> >>> >>> --Richard >>> >>> >>> >>> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> Could anyone in this fine WG explain (probably again, I missed it the >>> first time) the rational behind the text 'The length of this octet string >>> MUST be the full size of a coordinate for the curve specified in the "crv" >>> parameter.', which is in the definitions of the X and Y Coordinate >>> parameters for EC keys in JWA [1]? >>> >>> This message last month on the list >>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an >>> off list message indicate that both the jose4j and Nimbus JOSE+JWT >>> implementations aren't following spec on the length of the octet string >>> being the full size of a coordinate for the curve. Which suggests that >>> there maybe potential interoperability problems with certain EC JWKs. >>> >>> I'm just trying to wrap my head around the issue so any help in that >>> would be appreciated. >>> >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >> >> > --089e0149c50684e34c04f24f98e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It sounds to me like your approach is the best behavior fo= r an implementation.  Postel's law and all.


On Thu, Feb 13, 2014 at 2:59 P= M, Brian Campbell <bcampbell@pingidentity.com> wrot= e:
I wasn't necessarily lo= oking to make a change. Though interoperability is in sometimes in the eye = of the beholder. Yes, I realize it's a defect but my implementation cur= rently emits the coordinate value omitting the left zero padding bytes but = will accept either input. So the MAY that Richard proposed would likely imp= rove interoperability for me. It's not a hill I want to die on though s= o I'll zero-pad some arrays in my implementation.

On Thu, Feb 13, 2014 at 8:45 AM, Richard B= arnes <rlb@ipv.sx> wrote:
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones = <Michae= l.Jones@microsoft.com> wrote:

I’ll also add that = SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires that the= full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 

2.1. Convert the field= element xP to an octet string = X of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 

and in SEC1 2.3.5:=

 

Input: An eleme= nt a of the field Fq.

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.<= /p>

 

There’s no compelli= ng reason to special-case the situation in which some of the leading bits i= n the field element are zeros.

 

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

 

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 

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

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible for = somebody to give me a better reference pointer to the document that is begi= n reference?

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 <= /p>

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size o= f a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 




--089e0149c50684e34c04f24f98e6-- From nobody Thu Feb 13 12:37:16 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF291A04D0 for ; Thu, 13 Feb 2014 12:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig3AJK1cGoRu for ; Thu, 13 Feb 2014 12:37:11 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 819181A0482 for ; Thu, 13 Feb 2014 12:37:10 -0800 (PST) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKUv0s9Y64g1nlvN9smgtRempug4a5d+G8@postini.com; Thu, 13 Feb 2014 12:37:09 PST Received: by mail-ie0-f180.google.com with SMTP id ar20so524183iec.11 for ; Thu, 13 Feb 2014 12:37:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+LLV8yAQnHklI5QNP0rOgdKW50OJDVZQMvMuBpukOAY=; b=bNdiQZyPQS1G5cb0nd1OyqEEoJkWxPNDiMkiyS0ezlSOENm6lFeSPMz0NYEH6IQ6ru /JFSwA9dSU+ngsakZgmDjV5S/OJZbP3bsrmGd4U9rbxyYqgDQOAcz3FRyi3tDBhQ7HZa MfLUB5olS+8PoHwKqUki3Xi6h2cENY4hDS86fWt3D42mzcmEH06u/dwMbZGpNJjO6cHR 6m80SOxRzrlt5c8hAprAPnlZHqScwpgaV7Eq8bXufn33fVh0+K1Zw4Y2HUT7bMwmzCC6 5InPumb5tq9Tc8j+tNJSnfwJrbosYR58nIBbqBsmnFqd4/gcW7otP2Pgbb05/zflZ5C9 dK5A== X-Gm-Message-State: ALoCoQnVqDprzLjnmlUCbqJuxmOon2T8kUUE+LXad7snj19YBz/l5UPLFhleC9J+nfHruskZtwZRHcJf7hh+o/AfPK6jnhm7QHsvvkE7rF0abAkGQTfLrNjKM7/SP+dfVYWajpfS71Y3XAnG2cEzZSOVqijKZVWJ+Q== X-Received: by 10.43.49.132 with SMTP id va4mr2313045icb.79.1392323826377; Thu, 13 Feb 2014 12:37:06 -0800 (PST) X-Received: by 10.43.49.132 with SMTP id va4mr2313032icb.79.1392323826242; Thu, 13 Feb 2014 12:37:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.65.4 with HTTP; Thu, 13 Feb 2014 12:36:36 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739438B19359D@TK5EX14MBXC288.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 13 Feb 2014 13:36:36 -0700 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=bcaec5299ff9139e5004f24fa775 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Yj4DHR36otwzebEyD7bi-IxOF08 Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] question about the size of coordinate parameters in EC JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:37:15 -0000 --bcaec5299ff9139e5004f24fa775 Content-Type: text/plain; charset=ISO-8859-1 Once I fix the output to conform to the MUST in the spec, I agree with you :) But yes, in honor of Postel, I'll leave it so that it'll still accept either way as input. Thanks, by the way, for your replies to this thread. On Thu, Feb 13, 2014 at 1:33 PM, Richard Barnes wrote: > It sounds to me like your approach is the best behavior for an > implementation. Postel's law and all. > > > On Thu, Feb 13, 2014 at 2:59 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I wasn't necessarily looking to make a change. Though interoperability is >> in sometimes in the eye of the beholder. Yes, I realize it's a defect but >> my implementation currently emits the coordinate value omitting the left >> zero padding bytes but will accept either input. So the MAY that Richard >> proposed would likely improve interoperability for me. It's not a hill I >> want to die on though so I'll zero-pad some arrays in my implementation. >> >> >> On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes wrote: >> >>> Consistency with SEC1 seems like a compelling enough argument to me. >>> >>> >>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones >> > wrote: >>> >>>> I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) >>>> requires that the full octet string be present, and we decided to base our >>>> representation on SEC1. For instance, SEC1 says: >>>> >>>> >>>> >>>> 2.1. Convert the field element * x**P *to an octet string *X *of >>>> length ceiling(log2 *q*/8) octets using the conversion >>>> >>>> routine specified in Section 2.3.5. >>>> >>>> >>>> >>>> and in SEC1 2.3.5: >>>> >>>> >>>> >>>> *Input: *An element *a * of the field F*q*. >>>> >>>> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) >>>> octets. >>>> >>>> >>>> >>>> There's no compelling reason to special-case the situation in which >>>> some of the leading bits in the field element are zeros. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >>>> *Sent:* Wednesday, February 12, 2014 11:29 PM >>>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >>>> >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] question about the size of coordinate parameters >>>> in EC JWKs >>>> >>>> >>>> >>>> Sure. See >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>>> Behalf Of *Jim Schaad >>>> *Sent:* Wednesday, February 12, 2014 5:50 PM >>>> *To:* 'Richard Barnes'; 'Brian Campbell' >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] question about the size of coordinate parameters >>>> in EC JWKs >>>> >>>> >>>> >>>> Would it be possible for somebody to give me a better reference pointer >>>> to the document that is begin reference? >>>> >>>> >>>> >>>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>>> Behalf Of *Richard Barnes >>>> *Sent:* Wednesday, February 12, 2014 4:28 PM >>>> *To:* Brian Campbell >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] question about the size of coordinate parameters >>>> in EC JWKs >>>> >>>> >>>> >>>> That would make sense only for binary curves, but most of the curves >>>> people use today are integer curves, in which case truncation is totally >>>> sensible. >>>> >>>> >>>> >>>> I've been told that some Microsoft crypto libraries use fixed-length >>>> buffers for these things, but there should be a problem copying a shorter >>>> value into that buffer. >>>> >>>> >>>> >>>> Net of that, I would be in favor of saying that the coordinates MUST be >>>> full-length for binary curves, and MAY be zero-padded to full length for >>>> integer curves. >>>> >>>> >>>> >>>> --Richard >>>> >>>> >>>> >>>> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>> Could anyone in this fine WG explain (probably again, I missed it the >>>> first time) the rational behind the text 'The length of this octet string >>>> MUST be the full size of a coordinate for the curve specified in the "crv" >>>> parameter.', which is in the definitions of the X and Y Coordinate >>>> parameters for EC keys in JWA [1]? >>>> >>>> This message last month on the list >>>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an >>>> off list message indicate that both the jose4j and Nimbus JOSE+JWT >>>> implementations aren't following spec on the length of the octet string >>>> being the full size of a coordinate for the curve. Which suggests that >>>> there maybe potential interoperability problems with certain EC JWKs. >>>> >>>> I'm just trying to wrap my head around the issue so any help in that >>>> would be appreciated. >>>> >>>> >>>> [1] >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> >>>> >>> >>> >> > --bcaec5299ff9139e5004f24fa775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Once I fix the output to conform to the MUST in the s= pec, I agree with you :) But yes, in honor of Postel, I'll leave it so = that it'll still accept either way as input.

Thanks, by t= he way, for your replies to this thread.


On Thu,= Feb 13, 2014 at 1:33 PM, Richard Barnes <rlb@ipv.sx> wrote:
It sounds to me like your approach is the best behavior fo= r an implementation.  Postel's law and all.


On Thu, Feb 13, 2014 at 2:59 PM, Brian Campbell <bcampbell@pingid= entity.com> wrote:
I wasn't necessarily lo= oking to make a change. Though interoperability is in sometimes in the eye = of the beholder. Yes, I realize it's a defect but my implementation cur= rently emits the coordinate value omitting the left zero padding bytes but = will accept either input. So the MAY that Richard proposed would likely imp= rove interoperability for me. It's not a hill I want to die on though s= o I'll zero-pad some arrays in my implementation.


On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes <rlb@ipv.sx> wro= te:
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones = <Michae= l.Jones@microsoft.com> wrote:

I’ll also add that = SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires that the= full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 

2.1. Convert the field= element xP to an octet string = X of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 

and in SEC1 2.3.5:=

 

Input: An eleme= nt a of the field Fq.

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.<= /p>

 

There’s no compelli= ng reason to special-case the situation in which some of the leading bits i= n the field element are zeros.

 

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

 

From: jose [ma= ilto:jose-bounce= s@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 

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

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible for = somebody to give me a better reference pointer to the document that is begi= n reference?

 

From: jose [mailto:jose-bounce= s@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 <= /p>

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this = fine WG explain (probably again, I missed it the first time) the rational b= ehind the text 'The length of this octet string MUST be the full size o= f a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 





--bcaec5299ff9139e5004f24fa775-- From nobody Thu Feb 13 13:04:32 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF02A1A0500 for ; Thu, 13 Feb 2014 13:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnFAiDTp827V for ; Thu, 13 Feb 2014 13:04:22 -0800 (PST) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1699C1A04FC for ; Thu, 13 Feb 2014 13:04:22 -0800 (PST) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKUv0zVVryS5hZwjArn4BSIknShR9nUthO@postini.com; Thu, 13 Feb 2014 13:04:21 PST Received: by mail-ie0-f180.google.com with SMTP id ar20so542400iec.39 for ; Thu, 13 Feb 2014 13:04:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=XR1zt8d+DwsbIh7CMUSprgNiCsVMaJ/GhvSXuLP85qs=; b=FRVLHACGHPN7MaObR33dDbViwDAp0h9Z30Xmv/iY9cXMB4bUYYP/fRiWOFlbladOR6 fDuclsC6MCdPEKLi5AFocsL5BsXeI1pIEVQiTU1LIQRWpNvhfo2OESyktksBR5tM6yfl rKFeWrpRBHZDHIU/obyenZcddlEm9bWntG8BWcRvcz/rmFoyXA+oHjWiUiHLUY/PMY3S PUfp47BzJ5IUcBnd6l+bqnxwvMCxBSsi48ULnolYFsZyPZwkwYrhSbVFHllnrXIgEgCd QPaJmjpyOIsmxBi+ctH8SjQhHKamUlSWyMasQ4ljCcDa5Hko2vZ1PmJN/7+DV9aB0P+m Cj3w== X-Gm-Message-State: ALoCoQn/C23dzJU7nI8VqApiIRFBQclU4B28dMGOAmRhDMu5VNDtTJns1Bcrj2JvX9By7emfxLAohCytfUU8PjaYb6Hp1WfjLfRqNlmLn1bpn9bGzDRo34boUfYwbiEHrjz3McpINusEuTL+cBl8mkQMnBpxIJredg== X-Received: by 10.50.47.110 with SMTP id c14mr5581395ign.4.1392325460743; Thu, 13 Feb 2014 13:04:20 -0800 (PST) X-Received: by 10.50.47.110 with SMTP id c14mr5581379ign.4.1392325460587; Thu, 13 Feb 2014 13:04:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.65.4 with HTTP; Thu, 13 Feb 2014 13:03:50 -0800 (PST) From: Brian Campbell Date: Thu, 13 Feb 2014 14:03:50 -0700 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=089e013d0dca7d94b504f2500841 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/2cuauwm1Zrnvqy1Sm7QEqXmWpSs Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: [jose] ECC Private Key (was Re: question about the size of coordinate parameters in EC JWKs) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:04:31 -0000 --089e013d0dca7d94b504f2500841 Content-Type: text/plain; charset=ISO-8859-1 Somewhat related, could anyone be so kind as to try and explain in somewhat more plain English what's meant by the definition of the ECC Private Key Parameter d (text from JWA 6.2.2.1 copied below)? As well as how and why it's different than the x and y representations. My implementation is (maybe naively) doing the same thing to convert d as it does for x and y. Which is what it was doing before the SEC1 references were introduced to the draft. I remember being assured that SEC1 usage wasn't a breaking change. When I read the text in 6.2.2.1, I'm not totally confident with things. Maybe it's a moral failing on my part but I find SEC1 a little hard to read. C.4, for example, has version and parameters and public key that I think should be ignored in the JWK/A context but I'm not sure. As always, I appreciate any help or guidance folks can provide. "6.2.2.1. "d" (ECC Private Key) Parameter The "d" (ECC private key) member contains the Elliptic Curve private key value. It is represented as the base64url encoding of the octet string representation of the private key value, as defined in Sections C.4 and 2.3.7 of SEC1 [SEC1]. The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve)." - from http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.2.1 On Thu, Feb 13, 2014 at 12:59 PM, Brian Campbell wrote: > I wasn't necessarily looking to make a change. Though interoperability is > in sometimes in the eye of the beholder. Yes, I realize it's a defect but > my implementation currently emits the coordinate value omitting the left > zero padding bytes but will accept either input. So the MAY that Richard > proposed would likely improve interoperability for me. It's not a hill I > want to die on though so I'll zero-pad some arrays in my implementation. > > > On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes wrote: > >> Consistency with SEC1 seems like a compelling enough argument to me. >> >> >> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones wrote: >> >>> I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) >>> requires that the full octet string be present, and we decided to base our >>> representation on SEC1. For instance, SEC1 says: >>> >>> >>> >>> 2.1. Convert the field element * x**P *to an octet string *X *of length >>> ceiling(log2 *q*/8) octets using the conversion >>> >>> routine specified in Section 2.3.5. >>> >>> >>> >>> and in SEC1 2.3.5: >>> >>> >>> >>> *Input: *An element *a * of the field F*q*. >>> >>> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) >>> octets. >>> >>> >>> >>> There's no compelling reason to special-case the situation in which some >>> of the leading bits in the field element are zeros. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >>> *Sent:* Wednesday, February 12, 2014 11:29 PM >>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >>> >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] question about the size of coordinate parameters >>> in EC JWKs >>> >>> >>> >>> Sure. See >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>> Behalf Of *Jim Schaad >>> *Sent:* Wednesday, February 12, 2014 5:50 PM >>> *To:* 'Richard Barnes'; 'Brian Campbell' >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] question about the size of coordinate parameters >>> in EC JWKs >>> >>> >>> >>> Would it be possible for somebody to give me a better reference pointer >>> to the document that is begin reference? >>> >>> >>> >>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>> Behalf Of *Richard Barnes >>> *Sent:* Wednesday, February 12, 2014 4:28 PM >>> *To:* Brian Campbell >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] question about the size of coordinate parameters >>> in EC JWKs >>> >>> >>> >>> That would make sense only for binary curves, but most of the curves >>> people use today are integer curves, in which case truncation is totally >>> sensible. >>> >>> >>> >>> I've been told that some Microsoft crypto libraries use fixed-length >>> buffers for these things, but there should be a problem copying a shorter >>> value into that buffer. >>> >>> >>> >>> Net of that, I would be in favor of saying that the coordinates MUST be >>> full-length for binary curves, and MAY be zero-padded to full length for >>> integer curves. >>> >>> >>> >>> --Richard >>> >>> >>> >>> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>> Could anyone in this fine WG explain (probably again, I missed it the >>> first time) the rational behind the text 'The length of this octet string >>> MUST be the full size of a coordinate for the curve specified in the "crv" >>> parameter.', which is in the definitions of the X and Y Coordinate >>> parameters for EC keys in JWA [1]? >>> >>> This message last month on the list >>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an >>> off list message indicate that both the jose4j and Nimbus JOSE+JWT >>> implementations aren't following spec on the length of the octet string >>> being the full size of a coordinate for the curve. Which suggests that >>> there maybe potential interoperability problems with certain EC JWKs. >>> >>> I'm just trying to wrap my head around the issue so any help in that >>> would be appreciated. >>> >>> >>> [1] >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >> >> > --089e013d0dca7d94b504f2500841 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Somewhat related, could anyone be so kind as to try a= nd explain in somewhat more plain English what's meant by the definitio= n of the ECC Private Key Parameter d (text from JWA 6.2.2.1 copied below)? = As well as how and why it's different than the x and y representations.=

My implementation is (maybe naively) doing the same thing to convert d = as it does for x and y. Which is what it was doing before the SEC1 referenc= es were introduced to the draft. I remember being assured that SEC1 usage w= asn't a breaking change. When I read the text in 6.2.2.1, I'm not t= otally confident with things.

Maybe it's a moral failing on my part but I f= ind SEC1 a little hard to read. C.4, for example, has version and parameter= s and public key that I think should be ignored in the JWK/A context but I&= #39;m not sure. 

As always, I appreciate any help or guidance folk= s can provide.


"6.2.2.1.  "d" (EC= C Private Key) Parameter

   The "d" (ECC private= key) member contains the Elliptic Curve private
   key value.  It is represented as the base64url encoding o= f the octet
   string representation of the private key value,= as defined in
   Sections C.4 and 2.3.7 of SEC1 [SEC1].  = ;The length of this octet
   string MUST be ceiling(log-base-2= (n)/8) octets (where n is the order
   of the curve)."  - from http://to= ols.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.2.1



On Thu, Feb 13, 2014 at 12:59 PM, Br= ian Campbell <bcampbell@pingidentity.com> wrote:
I wasn't necessarily looking to make a change. Though = interoperability is in sometimes in the eye of the beholder. Yes, I realize= it's a defect but my implementation currently emits the coordinate val= ue omitting the left zero padding bytes but will accept either input. So th= e MAY that Richard proposed would likely improve interoperability for me. I= t's not a hill I want to die on though so I'll zero-pad some arrays= in my implementation.


=
On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes = <rlb@i= pv.sx> wrote:
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones = <Michae= l.Jones@microsoft.com> wrote:

I’ll also add = that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires tha= t the full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 =

2.1. Convert the field= element xP to an octet string X = of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 =

and in SEC1 2.3.5:

 =

Input: An eleme= nt a of the field Fq.<= /p>

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.

 =

There’s no com= pelling reason to special-case the situation in which some of the leading b= its in the field element are zeros.

 =

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 =

From: jose [mailto= :jose-bounces@ie= tf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 =

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 =

From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible= for somebody to give me a better reference pointer to the document that is= begin reference?

 =

From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this fi= ne WG explain (probably again, I missed it the first time) the rational beh= ind the text 'The length of this octet string MUST be the full size of = a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 




--089e013d0dca7d94b504f2500841-- From nobody Thu Feb 13 13:23:39 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6126C1A050D for ; Thu, 13 Feb 2014 13:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_7Tjvo65G9P for ; Thu, 13 Feb 2014 13:23:27 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id B65A01A0429 for ; Thu, 13 Feb 2014 13:23:27 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i7so13441701oag.36 for ; Thu, 13 Feb 2014 13:23:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Tq71qhUS7vl3eemGTbxIveunPeTXSu2/TEh+0K2xjW0=; b=gSlLs7id77kye34wzWV7cM86/P6ykbVVWqlIHbECB5zJ+gQp6T4xpajj9JfwD2Wb1o TSuqdwf7+dNeupud/ul866eKea+fGToE6CUqgtTaD7vrOEeXznDXv7/dF+N5iI14gi/+ o+RlAQJ07LiW59sOob7GaIOT7SAQPmFuAfaVR5TRfinDCIjIWGkk2VM38LNZHEIgSWQt cImNcV+C4d7JfEdt1Sv0E2flmkpatlfZBIYakARKCuqRiVNM13PFu5OgTCoFW7M+xY1f QOQyrKgJs/q0Vo33xiCq5XNv4iaiyBVhVJDZXmEkb8hI4RMHWiP5PkQVu2ZRnyY8PkiJ oLOg== X-Gm-Message-State: ALoCoQl7pXLOyHsUH1FKxXzIQrFZrWw3W2EH/TKis1OUqCixk12S9XL4fNbhL6Wa8GR/YbPpZiRv MIME-Version: 1.0 X-Received: by 10.182.117.195 with SMTP id kg3mr3027843obb.17.1392326606169; Thu, 13 Feb 2014 13:23:26 -0800 (PST) Received: by 10.60.69.102 with HTTP; Thu, 13 Feb 2014 13:23:26 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 16:23:26 -0500 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=089e0149c506c5c0e504f2504cca Archived-At: http://mailarchive.ietf.org/arch/msg/jose/DMzuCiJEsDQZnpltYn6LlFNJVfo Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] ECC Private Key (was Re: question about the size of coordinate parameters in EC JWKs) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:23:31 -0000 --089e0149c506c5c0e504f2504cca Content-Type: text/plain; charset=ISO-8859-1 In plain English: "d" is always an integer, while "x" and "y" can be more exotic things. So in practice, it depends on the type of the curve. For "integer" curves, "x", "y", and "d" are all integers, and you can treat them the same. For "binary" curves, "x" and "y" are different. IIRC, though, all of the curves we have defined right now are integer curves. On Thu, Feb 13, 2014 at 4:03 PM, Brian Campbell wrote: > Somewhat related, could anyone be so kind as to try and explain in > somewhat more plain English what's meant by the definition of the ECC > Private Key Parameter d (text from JWA 6.2.2.1 copied below)? As well as > how and why it's different than the x and y representations. > > My implementation is (maybe naively) doing the same thing to convert d as > it does for x and y. Which is what it was doing before the SEC1 references > were introduced to the draft. I remember being assured that SEC1 usage > wasn't a breaking change. When I read the text in 6.2.2.1, I'm not totally > confident with things. > > Maybe it's a moral failing on my part but I find SEC1 a little hard to > read. C.4, for example, has version and parameters and public key that I > think should be ignored in the JWK/A context but I'm not sure. > > As always, I appreciate any help or guidance folks can provide. > > > "6.2.2.1. "d" (ECC Private Key) Parameter > > The "d" (ECC private key) member contains the Elliptic Curve private > key value. It is represented as the base64url encoding of the octet > string representation of the private key value, as defined in > Sections C.4 and 2.3.7 of SEC1 [SEC1]. The length of this octet > string MUST be ceiling(log-base-2(n)/8) octets (where n is the order > of the curve)." - from > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.2.1 > > > > On Thu, Feb 13, 2014 at 12:59 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> I wasn't necessarily looking to make a change. Though interoperability is >> in sometimes in the eye of the beholder. Yes, I realize it's a defect but >> my implementation currently emits the coordinate value omitting the left >> zero padding bytes but will accept either input. So the MAY that Richard >> proposed would likely improve interoperability for me. It's not a hill I >> want to die on though so I'll zero-pad some arrays in my implementation. >> >> >> On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes wrote: >> >>> Consistency with SEC1 seems like a compelling enough argument to me. >>> >>> >>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones >> > wrote: >>> >>>> I'll also add that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) >>>> requires that the full octet string be present, and we decided to base our >>>> representation on SEC1. For instance, SEC1 says: >>>> >>>> >>>> >>>> 2.1. Convert the field element * x**P *to an octet string *X *of >>>> length ceiling(log2 *q*/8) octets using the conversion >>>> >>>> routine specified in Section 2.3.5. >>>> >>>> >>>> >>>> and in SEC1 2.3.5: >>>> >>>> >>>> >>>> *Input: *An element *a * of the field F*q*. >>>> >>>> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) >>>> octets. >>>> >>>> >>>> >>>> There's no compelling reason to special-case the situation in which >>>> some of the leading bits in the field element are zeros. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >>>> *Sent:* Wednesday, February 12, 2014 11:29 PM >>>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >>>> >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] question about the size of coordinate parameters >>>> in EC JWKs >>>> >>>> >>>> >>>> Sure. See >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>>> Behalf Of *Jim Schaad >>>> *Sent:* Wednesday, February 12, 2014 5:50 PM >>>> *To:* 'Richard Barnes'; 'Brian Campbell' >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] question about the size of coordinate parameters >>>> in EC JWKs >>>> >>>> >>>> >>>> Would it be possible for somebody to give me a better reference pointer >>>> to the document that is begin reference? >>>> >>>> >>>> >>>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>>> Behalf Of *Richard Barnes >>>> *Sent:* Wednesday, February 12, 2014 4:28 PM >>>> *To:* Brian Campbell >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] question about the size of coordinate parameters >>>> in EC JWKs >>>> >>>> >>>> >>>> That would make sense only for binary curves, but most of the curves >>>> people use today are integer curves, in which case truncation is totally >>>> sensible. >>>> >>>> >>>> >>>> I've been told that some Microsoft crypto libraries use fixed-length >>>> buffers for these things, but there should be a problem copying a shorter >>>> value into that buffer. >>>> >>>> >>>> >>>> Net of that, I would be in favor of saying that the coordinates MUST be >>>> full-length for binary curves, and MAY be zero-padded to full length for >>>> integer curves. >>>> >>>> >>>> >>>> --Richard >>>> >>>> >>>> >>>> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>> Could anyone in this fine WG explain (probably again, I missed it the >>>> first time) the rational behind the text 'The length of this octet string >>>> MUST be the full size of a coordinate for the curve specified in the "crv" >>>> parameter.', which is in the definitions of the X and Y Coordinate >>>> parameters for EC keys in JWA [1]? >>>> >>>> This message last month on the list >>>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an >>>> off list message indicate that both the jose4j and Nimbus JOSE+JWT >>>> implementations aren't following spec on the length of the octet string >>>> being the full size of a coordinate for the curve. Which suggests that >>>> there maybe potential interoperability problems with certain EC JWKs. >>>> >>>> I'm just trying to wrap my head around the issue so any help in that >>>> would be appreciated. >>>> >>>> >>>> [1] >>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> >>>> >>> >>> >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --089e0149c506c5c0e504f2504cca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In plain English: "d" is always an integer, whil= e "x" and "y" can be more exotic things.

=
So in practice, it depends on the type of the curve.  For "i= nteger" curves, "x", "y", and "d" are al= l integers, and you can treat them the same.  For "binary" c= urves, "x" and "y" are different.  IIRC, though, a= ll of the curves we have defined right now are integer curves.


On Thu,= Feb 13, 2014 at 4:03 PM, Brian Campbell <bcampbell@pingidentity.= com> wrote:
Somewhat related, coul= d anyone be so kind as to try and explain in somewhat more plain English wh= at's meant by the definition of the ECC Private Key Parameter d (text f= rom JWA 6.2.2.1 copied below)? As well as how and why it's different th= an the x and y representations.

My implementation is (maybe naively) doing the same thing to convert d = as it does for x and y. Which is what it was doing before the SEC1 referenc= es were introduced to the draft. I remember being assured that SEC1 usage w= asn't a breaking change. When I read the text in 6.2.2.1, I'm not t= otally confident with things.

Maybe it's a moral failing on my part but I f= ind SEC1 a little hard to read. C.4, for example, has version and parameter= s and public key that I think should be ignored in the JWK/A context but I&= #39;m not sure. 

As always, I appreciate any help or guidance folk= s can provide.


"6.2.2.1.  "d" (EC= C Private Key) Parameter

   The "d" (ECC private= key) member contains the Elliptic Curve private
   key value.  It is represented as the base64url encoding o= f the octet
   string representation of the private key value,= as defined in
   Sections C.4 and 2.3.7 of SEC1 [SEC1].  = ;The length of this octet
   string MUST be ceiling(log-base-2= (n)/8) octets (where n is the order
   of the curve)."  - from http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#= section-6.2.2.1



On Thu, Feb 13, 2014 at 12:59 PM, Br= ian Campbell <bcampbell@pingidentity.com> wrote:
I wasn't necessarily looking to make a change. Though = interoperability is in sometimes in the eye of the beholder. Yes, I realize= it's a defect but my implementation currently emits the coordinate val= ue omitting the left zero padding bytes but will accept either input. So th= e MAY that Richard proposed would likely improve interoperability for me. I= t's not a hill I want to die on though so I'll zero-pad some arrays= in my implementation.


On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes <rlb@ipv.sx> wro= te:
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones = <Michae= l.Jones@microsoft.com> wrote:

I’ll also add = that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires tha= t the full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 =

2.1. Convert the field= element xP to an octet string X = of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 =

and in SEC1 2.3.5:

 =

Input: An eleme= nt a of the field Fq.<= /p>

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.

 =

There’s no com= pelling reason to special-case the situation in which some of the leading b= its in the field element are zeros.

 =

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 =

From: jose [mailto= :jose-bounces@ie= tf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 =

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 =

From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible= for somebody to give me a better reference pointer to the document that is= begin reference?

 =

From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this fi= ne WG explain (probably again, I missed it the first time) the rational beh= ind the text 'The length of this octet string MUST be the full size of = a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 





_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--089e0149c506c5c0e504f2504cca-- From nobody Thu Feb 13 13:49:35 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B237B1A0047 for ; Thu, 13 Feb 2014 13:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcR0yyflFRmu for ; Thu, 13 Feb 2014 13:49:28 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 12FF91A0029 for ; Thu, 13 Feb 2014 13:49:27 -0800 (PST) Received: from mail-ig0-f180.google.com ([209.85.213.180]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUv095t+DcwZBNQXsQUD2KPI/21RK/grP@postini.com; Thu, 13 Feb 2014 13:49:27 PST Received: by mail-ig0-f180.google.com with SMTP id m12so13705138iga.1 for ; Thu, 13 Feb 2014 13:49:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bgBS7mORSTLVFbMM5jsa5hNVV4jVBvnu7yHpwQ+6AmI=; b=i7JU8jDMI9XLh7yJMzk1rIWIf9O21w2U3KTfkbaK0+uJ58bRv5anqhlsUVWEJMWWEq E6pCsJFTDhOZ1YPS16tRMyfXYaFrPpKVrP/UjUgIgC1aKwzC/qGeti+hhq29yE2ZPMMz fzFPci2ST4LeQwyK5o2ZAzeunmvYqyf2rbCh1Qg9WnQajgkUGPtHyx+aBSx2Rgxp8r8I 3pCXpGEF4P6+7+Zg3IkvzQzcTJGj9v5A207FPlUM+aLyPIBeZNYBXOurv+YLEFP7c8Pg KnuJpdp96IOrwsYEZiFmvKMgmG3xQrjklBL5epHmcfOj2bLy9CoUUZrOcnQkX+FDnZZh OjEQ== X-Gm-Message-State: ALoCoQnR1znfh399MkEVybf/8HVo/70QKiLi/G4Rd24X79vozaiXkn0lP5Cr9t6Gkfs8A+AuFPLhOWHl7TED9o5HLAdikTJEcnPw/ymbe3bi5Qrxusq7JlrbFY2AH7oL6c1LNQzRyVTfFAUdT3s2l2WzZ4PLFZ2X5w== X-Received: by 10.42.38.138 with SMTP id c10mr2541782ice.66.1392328166568; Thu, 13 Feb 2014 13:49:26 -0800 (PST) X-Received: by 10.42.38.138 with SMTP id c10mr2541772ice.66.1392328166361; Thu, 13 Feb 2014 13:49:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.65.4 with HTTP; Thu, 13 Feb 2014 13:48:56 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 13 Feb 2014 14:48:56 -0700 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=20cf30334ee5c468b704f250a928 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Ku4p7COkAWUJINlaLOz1eXTecUs Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] ECC Private Key (was Re: question about the size of coordinate parameters in EC JWKs) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:49:32 -0000 --20cf30334ee5c468b704f250a928 Content-Type: text/plain; charset=ISO-8859-1 Thank you Richard (again). And yes, all of the curves we have defined right now are integer curves. On Thu, Feb 13, 2014 at 2:23 PM, Richard Barnes wrote: > In plain English: "d" is always an integer, while "x" and "y" can be more > exotic things. > > So in practice, it depends on the type of the curve. For "integer" > curves, "x", "y", and "d" are all integers, and you can treat them the > same. For "binary" curves, "x" and "y" are different. IIRC, though, all > of the curves we have defined right now are integer curves. > > > On Thu, Feb 13, 2014 at 4:03 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Somewhat related, could anyone be so kind as to try and explain in >> somewhat more plain English what's meant by the definition of the ECC >> Private Key Parameter d (text from JWA 6.2.2.1 copied below)? As well as >> how and why it's different than the x and y representations. >> >> My implementation is (maybe naively) doing the same thing to convert d as >> it does for x and y. Which is what it was doing before the SEC1 references >> were introduced to the draft. I remember being assured that SEC1 usage >> wasn't a breaking change. When I read the text in 6.2.2.1, I'm not totally >> confident with things. >> >> Maybe it's a moral failing on my part but I find SEC1 a little hard to >> read. C.4, for example, has version and parameters and public key that I >> think should be ignored in the JWK/A context but I'm not sure. >> >> As always, I appreciate any help or guidance folks can provide. >> >> >> "6.2.2.1. "d" (ECC Private Key) Parameter >> >> The "d" (ECC private key) member contains the Elliptic Curve private >> key value. It is represented as the base64url encoding of the octet >> string representation of the private key value, as defined in >> Sections C.4 and 2.3.7 of SEC1 [SEC1]. The length of this octet >> string MUST be ceiling(log-base-2(n)/8) octets (where n is the order >> of the curve)." - from >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.2.1 >> >> >> >> On Thu, Feb 13, 2014 at 12:59 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I wasn't necessarily looking to make a change. Though interoperability >>> is in sometimes in the eye of the beholder. Yes, I realize it's a defect >>> but my implementation currently emits the coordinate value omitting the >>> left zero padding bytes but will accept either input. So the MAY that >>> Richard proposed would likely improve interoperability for me. It's not a >>> hill I want to die on though so I'll zero-pad some arrays in my >>> implementation. >>> >>> >>> On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes wrote: >>> >>>> Consistency with SEC1 seems like a compelling enough argument to me. >>>> >>>> >>>> On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> >>>>> I'll also add that SEC1 ( >>>>> http://www.secg.org/collateral/sec1_final.pdf) requires that the full >>>>> octet string be present, and we decided to base our representation on >>>>> SEC1. For instance, SEC1 says: >>>>> >>>>> >>>>> >>>>> 2.1. Convert the field element * x**P *to an octet string *X *of >>>>> length ceiling(log2 *q*/8) octets using the conversion >>>>> >>>>> routine specified in Section 2.3.5. >>>>> >>>>> >>>>> >>>>> and in SEC1 2.3.5: >>>>> >>>>> >>>>> >>>>> *Input: *An element *a * of the field F*q*. >>>>> >>>>> *Output: *An octet string *M *of length *mlen* = ceiling(log2 *q*/8) >>>>> octets. >>>>> >>>>> >>>>> >>>>> There's no compelling reason to special-case the situation in which >>>>> some of the leading bits in the field element are zeros. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones >>>>> *Sent:* Wednesday, February 12, 2014 11:29 PM >>>>> *To:* Jim Schaad; 'Richard Barnes'; 'Brian Campbell' >>>>> >>>>> *Cc:* jose@ietf.org >>>>> *Subject:* Re: [jose] question about the size of coordinate >>>>> parameters in EC JWKs >>>>> >>>>> >>>>> >>>>> Sure. See >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2.1.2and 6.2.1.3. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>>>> Behalf Of *Jim Schaad >>>>> *Sent:* Wednesday, February 12, 2014 5:50 PM >>>>> *To:* 'Richard Barnes'; 'Brian Campbell' >>>>> *Cc:* jose@ietf.org >>>>> *Subject:* Re: [jose] question about the size of coordinate >>>>> parameters in EC JWKs >>>>> >>>>> >>>>> >>>>> Would it be possible for somebody to give me a better reference >>>>> pointer to the document that is begin reference? >>>>> >>>>> >>>>> >>>>> *From:* jose [mailto:jose-bounces@ietf.org ] *On >>>>> Behalf Of *Richard Barnes >>>>> *Sent:* Wednesday, February 12, 2014 4:28 PM >>>>> *To:* Brian Campbell >>>>> *Cc:* jose@ietf.org >>>>> *Subject:* Re: [jose] question about the size of coordinate >>>>> parameters in EC JWKs >>>>> >>>>> >>>>> >>>>> That would make sense only for binary curves, but most of the curves >>>>> people use today are integer curves, in which case truncation is totally >>>>> sensible. >>>>> >>>>> >>>>> >>>>> I've been told that some Microsoft crypto libraries use fixed-length >>>>> buffers for these things, but there should be a problem copying a shorter >>>>> value into that buffer. >>>>> >>>>> >>>>> >>>>> Net of that, I would be in favor of saying that the coordinates MUST >>>>> be full-length for binary curves, and MAY be zero-padded to full length for >>>>> integer curves. >>>>> >>>>> >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>> Could anyone in this fine WG explain (probably again, I missed it the >>>>> first time) the rational behind the text 'The length of this octet string >>>>> MUST be the full size of a coordinate for the curve specified in the "crv" >>>>> parameter.', which is in the definitions of the X and Y Coordinate >>>>> parameters for EC keys in JWA [1]? >>>>> >>>>> This message last month on the list >>>>> http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and >>>>> an off list message indicate that both the jose4j and Nimbus JOSE+JWT >>>>> implementations aren't following spec on the length of the octet string >>>>> being the full size of a coordinate for the curve. Which suggests that >>>>> there maybe potential interoperability problems with certain EC JWKs. >>>>> >>>>> I'm just trying to wrap my head around the issue so any help in that >>>>> would be appreciated. >>>>> >>>>> >>>>> [1] >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6.2 >>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --20cf30334ee5c468b704f250a928 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you Richard (again). And yes, all of the curves we h= ave defined right now are integer curves.
<= br>
On Thu, Feb 13, 2014 at 2:23 PM, Richard = Barnes <rlb@ipv.sx> wrote:
In plain English: "d&q= uot; is always an integer, while "x" and "y" can be mor= e exotic things.

So in practice, it depends on the type of the curve.  F= or "integer" curves, "x", "y", and "d&qu= ot; are all integers, and you can treat them the same.  For "bina= ry" curves, "x" and "y" are different.  IIRC,= though, all of the curves we have defined right now are integer curves.

On Thu, Feb 13, 2014 at 4:03 PM, Brian Cam= pbell <bcampbell@pingidentity.com> wrote:
Somewhat related, coul= d anyone be so kind as to try and explain in somewhat more plain English wh= at's meant by the definition of the ECC Private Key Parameter d (text f= rom JWA 6.2.2.1 copied below)? As well as how and why it's different th= an the x and y representations.

My implementation is (maybe naively) doing the same thing to convert d = as it does for x and y. Which is what it was doing before the SEC1 referenc= es were introduced to the draft. I remember being assured that SEC1 usage w= asn't a breaking change. When I read the text in 6.2.2.1, I'm not t= otally confident with things.

Maybe it's a moral failing on my part but I f= ind SEC1 a little hard to read. C.4, for example, has version and parameter= s and public key that I think should be ignored in the JWK/A context but I&= #39;m not sure. 

As always, I appreciate any help or guidance folk= s can provide.


"6.2.2.1.  "d" (EC= C Private Key) Parameter

   The "d" (ECC private= key) member contains the Elliptic Curve private
   key value.  It is represented as the base64url encoding o= f the octet
   string representation of the private key value,= as defined in
   Sections C.4 and 2.3.7 of SEC1 [SEC1].  = ;The length of this octet
   string MUST be ceiling(log-base-2= (n)/8) octets (where n is the order
   of the curve)."  - from http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#= section-6.2.2.1



On Thu, Feb 13, 2014 at 12:59 PM, Br= ian Campbell <bcampbell@pingidentity.com> wrote:
I wasn't necessarily looking to make a change. Though = interoperability is in sometimes in the eye of the beholder. Yes, I realize= it's a defect but my implementation currently emits the coordinate val= ue omitting the left zero padding bytes but will accept either input. So th= e MAY that Richard proposed would likely improve interoperability for me. I= t's not a hill I want to die on though so I'll zero-pad some arrays= in my implementation.


On Thu, Feb 13, 2014 at 8:45 AM, Richard Barnes <rlb@ipv.sx> wro= te:
Consistency with SEC1 seems like a compelling enough argum= ent to me.


On Thu, Feb 13, 2014 at 2:39 AM, Mike Jones = <Michae= l.Jones@microsoft.com> wrote:

I’ll also add = that SEC1 (http://www.secg.org/collateral/sec1_final.pdf) requires tha= t the full octet string be present, and we decided to base our representation on SEC1. = ; For instance, SEC1 says:

 =

2.1. Convert the field= element xP to an octet string X = of length ceiling(log2 q/8) octets using the conversion

routine specified in Section 2.3.5.

 =

and in SEC1 2.3.5:

 =

Input: An eleme= nt a of the field Fq.<= /p>

Output: An octet string M of length mlen =3D ceiling(log2 q/8) octets.

 =

There’s no com= pelling reason to special-case the situation in which some of the leading b= its in the field element are zeros.

 =

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 =

From: jose [mailto= :jose-bounces@ie= tf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 12, 2014 11:29 PM
To: Jim Schaad; 'Richard Barnes'; 'Brian Campbell'


Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Sure.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6= .2.1.2 and 6.2.1.3.

 =

   &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      -- Mike

 =

From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Jim Schaad
Sent: Wednesday, February 12, 2014 5:50 PM
To: 'Richard Barnes'; 'Brian Campbell'
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

Would it be possible= for somebody to give me a better reference pointer to the document that is= begin reference?

 =

From: jose [mailto:jose-bounces@ie= tf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 12, 2014 4:28 PM
To: Brian Campbell
Cc: jose@ietf.org=
Subject: Re: [jose] question about the size of coordinate parameters= in EC JWKs

 

That would make sense only for binary curves, but mo= st of the curves people use today are integer curves, in which case truncat= ion is totally sensible.  

 

I've been told that some Microsoft crypto librar= ies use fixed-length buffers for these things, but there should be a proble= m copying a shorter value into that buffer.

 

Net of that, I would be in favor of saying that the = coordinates MUST be full-length for binary curves, and MAY be zero-padded t= o full length for integer curves.

 

--Richard

 

On Wed, Feb 12, 2014 at 6:58 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

Could anyone in this fi= ne WG explain (probably again, I missed it the first time) the rational beh= ind the text 'The length of this octet string MUST be the full size of = a coordinate for the curve specified in the "crv" parameter.', which is in the definitions of the X = and Y Coordinate parameters for EC keys in JWA [1]?

This message last month on the list http://www.ietf.org/mail-archive/web/jose/current/msg03901.html and an = off list message indicate that both the jose4j and Nimbus JOSE+JWT implemen= tations aren't following spec on the length of the octet string being t= he full size of a coordinate for the curve. Which suggests that there maybe potential interoperability problems= with certain EC JWKs. 

I'm just trying to wrap my head around the issue= so any help in that would be appreciated.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 





_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--20cf30334ee5c468b704f250a928-- From nobody Fri Feb 14 15:13:39 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4B71A03ED; Fri, 14 Feb 2014 15:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPkpgYjsZXUK; Fri, 14 Feb 2014 15:13:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D01D51A045C; Fri, 14 Feb 2014 15:13:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231319.12588.54774.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:13:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/5w-5UAiQ4UTlnW2bajAPiC-aSu4 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-21.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:13:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF. Title : JSON Web Signature (JWS) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-21.txt Pages : 55 Date : 2014-02-14 Abstract: JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-signature-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 15:14:59 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7194D1A03BA; Fri, 14 Feb 2014 15:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKVQhaDiBxvm; Fri, 14 Feb 2014 15:14:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B01E11A0454; Fri, 14 Feb 2014 15:14:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231442.918.64268.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:14:42 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/FsTLaN_Jwm1L64grXo-jQZ9T8ik Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-21.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:14:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF. Title : JSON Web Encryption (JWE) Authors : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-21.txt Pages : 54 Date : 2014-02-14 Abstract: JSON Web Encryption (JWE) represents encrypted content using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 15:16:10 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3271A0438; Fri, 14 Feb 2014 15:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUa3bGNNmYPb; Fri, 14 Feb 2014 15:16:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 219041A03FB; Fri, 14 Feb 2014 15:16:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231604.892.92308.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:16:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/OH00x_QZCmajFrFlTyBvLtxi1bY Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-21.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:16:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF. Title : JSON Web Key (JWK) Author : Michael B. Jones Filename : draft-ietf-jose-json-web-key-21.txt Pages : 41 Date : 2014-02-14 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-key-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 15:18:27 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00A51A01D4; Fri, 14 Feb 2014 15:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GizFFl3agpb2; Fri, 14 Feb 2014 15:18:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019641A0479; Fri, 14 Feb 2014 15:18:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231809.26934.10606.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:18:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/ruajX8IcE82SfJUw9FsVBbVLK60 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-21.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:18:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-21.txt Pages : 72 Date : 2014-02-14 Abstract: The JSON Web Algorithms (JWA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-algorithms-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 17:06:54 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475E21A00AE for ; Fri, 14 Feb 2014 17:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS8uBdIOoda0 for ; Fri, 14 Feb 2014 17:06:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0158.outbound.protection.outlook.com [207.46.163.158]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4F1A00A7 for ; Fri, 14 Feb 2014 17:06:48 -0800 (PST) Received: from DM2PR03CA008.namprd03.prod.outlook.com (10.141.52.156) by DM2PR03MB383.namprd03.prod.outlook.com (10.141.55.17) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:06:45 +0000 Received: from BL2FFO11FD013.protection.gbl (2a01:111:f400:7c09::132) by DM2PR03CA008.outlook.office365.com (2a01:111:e400:2414::28) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Sat, 15 Feb 2014 01:06:45 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:06:45 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 01:06:11 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JOSE -21 drafts incorporating WGLC feedback Thread-Index: Ac8p6g5i+6VQzEWbTwWC1YAmMT3J7g== Date: Sat, 15 Feb 2014 01:06:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19752A@TK5EX14MBXC288.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.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19752ATK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(189002)(199002)(81542001)(74706001)(19580395003)(6806004)(69226001)(83322001)(71186001)(44976005)(93136001)(85852003)(83072002)(74876001)(76176001)(53806001)(46102001)(16236675002)(81342001)(87936001)(90146001)(54356001)(51856001)(56816005)(85306002)(87266001)(33656001)(63696002)(49866001)(4396001)(92566001)(95666001)(47736001)(95416001)(94316002)(16297215004)(15202345003)(93516002)(79102001)(92726001)(65816001)(94946001)(81686001)(86362001)(74366001)(20776003)(80976001)(50986001)(19300405004)(47976001)(15975445006)(66066001)(84326002)(2656002)(80022001)(76482001)(56776001)(47446002)(77982001)(74662001)(54316002)(59766001)(55846006)(74502001)(81816001)(86612001)(76796001)(512954002)(77096001)(31966008)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR03MB383; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:A643DAB4.A0F2FBD1.61F19548.80ECF550.20253; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/0vWbLmpZaO552dduPwvclvsCaSc Subject: [jose] JOSE -21 drafts incorporating WGLC feedback X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:06:53 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B19752ATK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JSON Object Signing and Encryption (JOSE) drafts have been published that a= ddress the feedback received during Working Group Last Call (WGLC) on the s= pecifications, which ran from January 22 to February 13, 2014. Two breakin= g (but very local) changes were made as a result of working group discussio= ns: * Replaced the JWK key_ops values wrap and unwrap with wrapKey and = unwrapKey to match the KeyUsage values defined in the current Web Cryptogra= phy API editor's draft. * Compute the PBES2 salt parameter as (UTF8(Alg) || 0x00 || Salt In= put), where the p2s Header Parameter encodes the Salt Input value and Alg i= s the alg Header Parameter value. A few editorial changes were also made to improve readability. See the Doc= ument History sections for the issues addressed by these changes. One para= llel editorial change was also made to the JSON Web Token (JWT) specificati= on. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-21 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-21 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-21 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-21 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-16 HTML formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-2= 1.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 21.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-21.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 21.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-16.h= tml Thanks to those of you who provided feedback on the specs during Working Gr= oup Last Call. -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1186 and as= @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739438B19752ATK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JSON Object Signing and Encryption (JOSE) drafts hav= e been published that address the feedback received during Working Group La= st Call (WGLC) on the specifications, which ran from January 22 to February= 13, 2014.  Two breaking (but very local) changes were made as a result of working group discussions:

 

·         Replace= d the JWK key_ops= values wrap and unwrap<= span lang=3D"EN" style=3D"font-size:10.0pt;font-family:"Verdana",= "sans-serif";color:black"> with wrapKey= and unwrapKey to match the KeyUsage values defined in the current Web Cryptography API editor's draft.

·         Compute= the PBES2 salt parameter as (UTF8(Alg) || 0x00 || Salt Input), where the p2s Header Parameter encodes the Salt Input v= alue and Alg is the alg Header Parameter value.

 

A few editorial changes were also made to improve re= adability.  See the Document History sections for the issues addressed= by these changes.  One parallel editorial change was also made to the= JSON Web Token (JWT) specification.

 

The specifications are available at:

·         http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-21

·         http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-21

·         http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-21

·         http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-21

·         http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-16

 

HTML formatted versions are also available at:<= /o:p>

·         http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-21.html

·         http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-21.html

·         http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-21.html

·         http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-21.html

·         http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-16.html

 

Thanks to those of you who provided feedback on the = specs during Working Group Last Call.

 

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

 

P.S.  This note was also posted at http://self-issued.info/?p=3D1186 and as @selfissued.

--_000_4E1F6AAD24975D4BA5B16804296739438B19752ATK5EX14MBXC288r_-- From nobody Fri Feb 14 17:45:26 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153351A00A7 for ; Fri, 14 Feb 2014 17:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhS7E0I7Km_2 for ; Fri, 14 Feb 2014 17:45:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0877F1A0055 for ; Fri, 14 Feb 2014 17:45:20 -0800 (PST) Received: from DM2PR03CA008.namprd03.prod.outlook.com (10.141.52.156) by DM2PR03MB383.namprd03.prod.outlook.com (10.141.55.17) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:45:14 +0000 Received: from BL2FFO11FD013.protection.gbl (2a01:111:f400:7c09::167) by DM2PR03CA008.outlook.office365.com (2a01:111:e400:2414::28) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Sat, 15 Feb 2014 01:45:13 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD013.mail.protection.outlook.com (10.173.160.221) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:45:13 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 01:44:24 +0000 From: Mike Jones To: Karen O'Donoghue , "jose@ietf.org" Thread-Topic: [jose] REMINDER: WGLC for JWA, JWE, JWK, and JWS Thread-Index: AQHPIorLLJHtl+gCa0aib3DBlOyOGJq1mKYg Date: Sat, 15 Feb 2014 01:44:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B198BDD@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <52E0AB85.1070409@isoc.org> <52F25EF7.2030006@isoc.org> In-Reply-To: <52F25EF7.2030006@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B198BDDTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(12213003)(189002)(199002)(377454003)(13464003)(15202345003)(94316002)(94946001)(81686001)(65816001)(92726001)(74366001)(86362001)(93516002)(79102001)(92566001)(4396001)(95666001)(49866001)(63696002)(95416001)(47736001)(55846006)(74502001)(54316002)(59766001)(81816001)(86612001)(77982001)(47446002)(74662001)(31966008)(77096001)(512954002)(76796001)(56776001)(19300405004)(47976001)(66066001)(15975445006)(50986001)(80976001)(20776003)(80022001)(2656002)(76482001)(84326002)(71186001)(44976005)(93136001)(6806004)(69226001)(19580405001)(83322001)(83072002)(85852003)(81542001)(19580395003)(74706001)(51856001)(56816005)(90146001)(87936001)(54356001)(87266001)(33656001)(85306002)(74876001)(16236675002)(81342001)(46102001)(53806001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR03MB383; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:FCFB7134.AC105CFA.1D5BCF0.80ECD3F0.2026A; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/9fo8Egsr88HYtLtNUdWRxTnkKSo Subject: Re: [jose] REMINDER: WGLC for JWA, JWE, JWK, and JWS X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:45:24 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B198BDDTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed the JWS, JWE, JWK, and JWA documents. I believe that the -21 versions of the documents are ready to send to the I= ESG The -21 versions address the comments on the -20 versions that arose during= WGLC. The changes between the -20 and -21 versions are minimal and are di= scussed in the Document History sections of each document, including statin= g which JOSE issue numbers are intended to be addressed by the changes. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue Sent: Wednesday, February 05, 2014 7:56 AM To: jose@ietf.org Subject: [jose] REMINDER: WGLC for JWA, JWE, JWK, and JWS Folks, Just a quick reminder that we are almost two weeks into our three week WGLC= , and I haven't seen any traffic on the mailing list yet regarding these docu= ments. Ideally, I'd like to see something along the lines of the following: - I have reviewed the (JWA/JWE/JWK/JSW) document(s) - I believe this document IS or IS NOT ready to be sent to the IESG - I have the following comments... Deadline is 13 February! Karen -------- Original Message -------- Subject: [jose] WGLC for JWA, JWE, JWK, and JWS Date: Thu, 23 Jan 2014 00:41:25 -0500 From: Karen O'Donoghue To: jose@ietf.org Folks, This message initiates three week WGLCs for the four JOSE WG specifications referenced below: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ Please review and comment on the documents and put any issues in the JOSE WG issue tracker. The WGLC will end on 13 February 2014. Regards, JOSE WG co-chairs _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739438B198BDDTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed the JWS, = JWE, JWK, and JWA documents.

 <= /p>

I believe that the -21 ve= rsions of the documents are ready to send to the IESG

 <= /p>

The -21 versions address = the comments on the -20 versions that arose during WGLC.  The changes = between the -20 and -21 versions are minimal and are discussed in the Document History sections of each document, including stating which= JOSE issue numbers are intended to be addressed by the changes.=

 <= /p>

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

 <= /p>

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Wednesday, February 05, 2014 7:56 AM
To: jose@ietf.org
Subject: [jose] REMINDER: WGLC for JWA, JWE, JWK, and JWS=

 

Folks,

Just a quick reminder that we are almost two weeks into our three week WGLC= ,
and I haven't seen any traffic on the mailing list yet regarding these docu= ments.

Ideally, I'd like to see something along the lines of the following:

- I have reviewed the (JWA/JWE/JWK/JSW) document(s)
- I believe this document IS or IS NOT ready to be sent to the IESG
- I have the following comments...


Deadline is 13 February!
Karen

-------- Original Message --------

Subjec= t:

[jose] WGLC for JWA, JWE, JWK, and JWS

Date: =

Thu, 23 Jan 2014 00:41:25 -0500

From: =

Karen O'Donoghue <odonoghue@isoc.org>

To:

jose@ietf.org <= a href=3D"mailto:jose@ietf.org"> <jose@ietf.org>

 

Folks,
 
This message initiates three week WGLCs for the four JOSE WG specifica=
tions
referenced below:
 
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algor=
ithms/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encry=
ption/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signat=
ure/
 
Please review and comment on the documents and put any issues in the
JOSE WG issue tracker. The WGLC will end on 13 February 2014.
 
Regards,
JOSE WG co-chairs
 
_______________________________________________
jose mailing list
jose@ietf.org
https://www.iet=
f.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B16804296739438B198BDDTK5EX14MBXC288r_-- From nobody Fri Feb 14 17:46:42 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2674D1A0018 for ; Fri, 14 Feb 2014 17:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd3wmO6_Vx1c for ; Fri, 14 Feb 2014 17:46:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 55BAB1A0021 for ; Fri, 14 Feb 2014 17:46:37 -0800 (PST) Received: from BL2PR03CA022.namprd03.prod.outlook.com (10.141.66.30) by BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:46:34 +0000 Received: from BN1AFFO11FD050.protection.gbl (2a01:111:f400:7c10::102) by BL2PR03CA022.outlook.office365.com (2a01:111:e400:c1b::30) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Sat, 15 Feb 2014 01:46:34 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD050.mail.protection.outlook.com (10.58.53.65) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:46:33 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 01:46:06 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-jose-json-web-signature@tools.ietf.org" Thread-Topic: Issue #121 - Section 7.2 JWS JSON Serialization Thread-Index: Ac8kLW8KAhQ9LkffT2ucYYJTmRRjOAFwhkGg Date: Sat, 15 Feb 2014 01:46:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B198DCF@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <008401cf2432$a6644e70$f32ceb50$@augustcellars.com> In-Reply-To: <008401cf2432$a6644e70$f32ceb50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B198DCFTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51914003)(377454003)(5383001)(69226001)(76482001)(87936001)(77096001)(54356001)(46102001)(15202345003)(20776003)(19580405001)(2656002)(87266001)(80976001)(93136001)(19580395003)(6806004)(74662001)(51856001)(53806001)(74876001)(31966008)(56816005)(92726001)(83072002)(81542001)(512954002)(74502001)(54316002)(92566001)(71186001)(47446002)(56776001)(90146001)(74706001)(76796001)(16236675002)(81342001)(77982001)(19300405004)(94946001)(55846006)(93516002)(84326002)(33656001)(86612001)(65816001)(86362001)(63696002)(79102001)(95416001)(85852003)(81686001)(44976005)(81816001)(59766001)(83322001)(80022001)(49866001)(47976001)(4396001)(50986001)(85306002)(15975445006)(74366001)(47736001)(94316002)(66066001)(95666001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB593; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:6A22F01C.2F03DF01.B3E39348.AE5A14D.202EF; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/rDBZ9zrZBCZ7-mMG-OMo0AOsylg Cc: "jose@ietf.org" Subject: Re: [jose] Issue #121 - Section 7.2 JWS JSON Serialization X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:46:41 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B198DCFTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for these useful comments, Jim. They helped make the section much m= ore readable. Please review the revised language in the -21 draft. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, February 07, 2014 10:30 AM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: Issue #121 - Section 7.2 JWS JSON Serialization This is an improvement over the previous version, however there are a numbe= r of changes that can be done to make things better. 1. Move the requirement language into the list. Thus "This member = MUST be present." Should be part of the payload and signatures and signatur= e list items and the separate paragraph can be removed 2. Suggested text for signatures element: The type of this element is an array of objects= . Each object represents a separate signature or MAC computation over the = payload. This element MUST be present. The following members are defined for the JSON object for each signature: contains the value BAES64URL(UTF8(JWS Protected H= eader)). The value MUST be absent if there is no protected header. contains a JSON object. The member of the object co= nsist of the unprotected header name/value pairs. This value MUST be absen= t if there are no unprotected header members. contains the value BASE64URL(JWS Signature). Thi= s value MUST be present. 3. A note that one of protected and header will be present because th= e alg header parameter is required could be added, but I don't know that it= is really necessary. 4. If the paragraph starting with "The contents of the JWS Payload and JWS= Signature values are" is required here, then it should also be in section = 7.1 5. I don't understand what the paragraph starting with "Each JWS Signature= value is computed on the JWS Signing Input" is trying to say. I think it = could probably be said in a clearer and terser manner however. --_000_4E1F6AAD24975D4BA5B16804296739438B198DCFTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for these usefu= l comments, Jim.  They helped make the section much more readable.&nbs= p; Please review the revised language in the -21 draft.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Friday, February 07, 2014 10:30 AM
To: draft-ietf-jose-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: Issue #121 - Section 7.2 JWS JSON Serialization<= /span>

 

This is an improvement over the previous version, ho= wever there are a number of changes that can be done to make things better.=

 

1.     &= nbsp;  Move the  requirement language into the = list.  Thus “This member MUST be present.” Should be part = of the payload and signatures and signature list items and the separate par= agraph can be removed

2.     &= nbsp; Suggested text for signatures element:

<t hangText=3D”signatures”/>The type of this element is a= n array of objects.  Each object represents a separate signature or MA= C computation over the payload.  This element MUST be present.
<vspace line=3D”1”/>
The following members are defined for the JSON object for each signature: <list style=3D”hanging”/>

<t hangText=3D”protected”>c= ontains the value BAES64URL(UTF8(JWS Protected Header)).  The value MU= ST be absent if there is no protected header.</t>

<t hangText=3D”header”>cont= ains a JSON object.  The member of the object consist of the unprotect= ed header name/value pairs.  This value MUST be absent if there are no= unprotected header members.</t>

<t hangText=3D”signature”>c= ontains the value BASE64URL(JWS Signature).  This value MUST be presen= t.

</list>

</t>

 

3.     &= nbsp; A note that one of protected and header will be pre= sent because the alg header parameter is required could be added, but I don= ’t know that it is really necessary.

=
4.  If the pa=
ragraph starting with “The contents of the JWS Payload and JWS Signat=
ure values are” is required here, then it should also be in section 7=
.1
=
5.  I donR=
17;t understand what the paragraph starting with “Each JWS Signature =
value is computed on the JWS Signing Input” is trying to say.  I=
 think it could probably be said in a clearer and terser manner however.
 
 
--_000_4E1F6AAD24975D4BA5B16804296739438B198DCFTK5EX14MBXC288r_-- From nobody Fri Feb 14 17:46:59 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11AC1A0055 for ; Fri, 14 Feb 2014 17:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWoTfFkeqX0D for ; Fri, 14 Feb 2014 17:46:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 70F471A0018 for ; Fri, 14 Feb 2014 17:46:54 -0800 (PST) Received: from BY2PR03CA034.namprd03.prod.outlook.com (10.242.234.155) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:46:51 +0000 Received: from BL2FFO11FD027.protection.gbl (2a01:111:f400:7c09::110) by BY2PR03CA034.outlook.office365.com (2a01:111:e400:2c2c::27) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Sat, 15 Feb 2014 01:46:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:46:51 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 01:46:14 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-jose-json-web-encryption@tools.ietf.org" Thread-Topic: Issue #178 - JWE JSON Serialization Thread-Index: Ac8kMuInu3Nae2teSpS0dLfg13yDfgFvNBLQ Date: Sat, 15 Feb 2014 01:46:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B198DD6@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <00a701cf243c$7a061390$6e123ab0$@augustcellars.com> In-Reply-To: <00a701cf243c$7a061390$6e123ab0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B198DD6TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: =?us-ascii?Q?CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(100?= =?us-ascii?Q?09001)(6009001)(189002)(51914003)(199002)(5383001)(377454003?= =?us-ascii?Q?)(51856001)(85852003)(83072002)(6806004)(93516002)(53806001)?= =?us-ascii?Q?(74876001)(81542001)(46102001)(76482001)(54356001)(94946001)?= =?us-ascii?Q?(74706001)(56816005)(69226001)(94316002)(86612001)(81342001)?= =?us-ascii?Q?(90146001)(86362001)(63696002)(74366001)(92566001)(20776003)?= =?us-ascii?Q?(31966008)(77982001)(74662001)(66066001)(84326002)(195803950?= =?us-ascii?Q?03)(81816001)(76796001)(65816001)(80022001)(85306002)(152023?= =?us-ascii?Q?45003)(47446002)(79102001)(87936001)(19580405001)(4396001)(9?= =?us-ascii?Q?5416001)(80976001)(33656001)(59766001)(49866001)(16236675002?= =?us-ascii?Q?)(512954002)(54316002)(56776001)(92726001)(71186001)(5584600?= =?us-ascii?Q?6)(15975445006)(50986001)(83322001)(77096001)(74502001)(2656?= =?us-ascii?Q?002)(47976001)(87266001)(93136001)(81686001)(19300405004)(47?= =?us-ascii?Q?736001)(95666001)(44976005)(217873001);DIR:OUT;SFP:1101;SCL:?= =?us-ascii?Q?1;SRVR:BY2PR03MB075;H:mail.microsoft.com;CLIP:131.107.125.37?= =?us-ascii?Q?;FPR:2E72C89D.AEFA3701.42D37F8F.46E6B14D.202EB;MLV:sfv;PTR:I?= =?us-ascii?Q?nfoDomainNonexistent;MX:1;A:1;LANG:en;?= X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/ZPY2DZ-r9lOWmz2DPKSUtA6DNI0 Cc: "jose@ietf.org" Subject: Re: [jose] Issue #178 - JWE JSON Serialization X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:46:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B198DD6TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for these useful comments, Jim. They helped make the section much m= ore readable. Please review the revised language in the -21 draft. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, February 07, 2014 11:41 AM To: draft-ietf-jose-json-web-encryption@tools.ietf.org Cc: jose@ietf.org Subject: Issue #178 - JWE JSON Serialization This is improved over the last version, however there are still some issues= to be addressed: 1. The description of unprotected is incorrect. It describes the con= tents as being both a string an and object. 2. For aad - the note should be moved to the initial description of J= WE AAD and not placed here. (Alternatively it should be in the compact ser= ialization since it is an issue there not here.) 3. See the re-write in the JWS that I suggested. I find the current = text to be very difficult to read for header and encrypted_key. 4. Move MUST be present text into each member description. 5. The sentence "The ... members MUST be present when ... are non-emp= ty." can be removed. This is not adding any content. 6. Several of the MUST be present statements can be simplified. For = example - in recipients - This array MUST be absent if the number of elemen= ts would be zero. Moving this into the individual elements should help sha= rpen this text. 7. The paragraph starting with "Not all Header Parameters are..." sho= uld be moved to the description of the header parameters and not buried her= e. 8. The paragraph starting "The Header Parameter values..." needs to b= e cleaned up. On the first reading I assumed that all of the per-recipient= unprotected header values would be in the union and I know this is wrong. 9. The paragraph starting "The contents of the ..." should either be = removed or duplicated in section 7.1 10. The paragraph starting "All recipients.." can be deleted - all of thi= s is implicit in the how do you encrypt section. --_000_4E1F6AAD24975D4BA5B16804296739438B198DD6TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for these usefu= l comments, Jim.  They helped make the section much more readable.&nbs= p; Please review the revised language in the -21 draft.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Friday, February 07, 2014 11:41 AM
To: draft-ietf-jose-json-web-encryption@tools.ietf.org
Cc: jose@ietf.org
Subject: Issue #178 - JWE JSON Serialization

 

This is improved over the last version, however ther= e are still some issues to be addressed:

 

1.     &= nbsp; The description of unprotected is incorrect.  = It describes the contents as being both a string an and object.<= /p>

2.     &= nbsp; For aad – the note should be moved to the ini= tial description of JWE AAD and not placed here.  (Alternatively it sh= ould be in the compact serialization since it is an issue there not here.)<= o:p>

3.     &= nbsp; See the re-write in the JWS that I suggested. = I find the current text to be very difficult to read for header and encryp= ted_key.

4.     &= nbsp; Move MUST be present text into each member descript= ion.

5.     &= nbsp; The sentence “The … members MUST be pre= sent when … are non-empty.” can be removed.  This is not a= dding any content.

6.     &= nbsp; Several of the MUST be present statements can be si= mplified.  For example – in recipients – This array MUST b= e absent if the number of elements would be zero.  Moving this into th= e individual elements should help sharpen this text.

7.     &= nbsp; The paragraph starting with “Not all Header P= arameters are…” should be moved to the description of the heade= r parameters and not buried here.

8.     &= nbsp; The paragraph starting “The Header Parameter = values…” needs to be cleaned up.  On the first reading I a= ssumed that all of the per-recipient unprotected header values would be in = the union and I know this is wrong.

9.     &= nbsp; The paragraph starting “The contents of the &= #8230;” should either be removed or duplicated in section 7.1

10.   The paragraph starting “All recipients..̶= 1; can be deleted – all of this is implicit in the how do  you e= ncrypt section.

 

 

 

--_000_4E1F6AAD24975D4BA5B16804296739438B198DD6TK5EX14MBXC288r_-- From nobody Fri Feb 14 17:47:26 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4581A0021 for ; Fri, 14 Feb 2014 17:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFyWzhYLSsk9 for ; Fri, 14 Feb 2014 17:47:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4639B1A0018 for ; Fri, 14 Feb 2014 17:47:20 -0800 (PST) Received: from BL2PR03CA022.namprd03.prod.outlook.com (10.141.66.30) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:47:17 +0000 Received: from BN1AFFO11FD050.protection.gbl (2a01:111:f400:7c10::102) by BL2PR03CA022.outlook.office365.com (2a01:111:e400:c1b::30) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Sat, 15 Feb 2014 01:47:17 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD050.mail.protection.outlook.com (10.58.53.65) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:47:17 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 01:46:38 +0000 From: Mike Jones To: Mike Jones , Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Issue #90 - Section 9 References Thread-Index: Ac8kQEcqgfgwtF27TKCQMnD+74lR9wAGwBBgAAKNxoAAACBoEAFibmNg Date: Sat, 15 Feb 2014 01:46:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B198DF0@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <00d301cf2451$f1eb6300$d5c22900$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B189C26@TK5EX14MBXC288.redmond.corp.microsoft.com> <00ff01cf2465$7f9016c0$7eb04440$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B189F1C@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B189F1C@TK5EX14MBXC288.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.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B198DF0TK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(57704003)(5383001)(377454003)(189002)(199002)(69226001)(74706001)(87266001)(15975445006)(2656002)(95666001)(71186001)(86612001)(90146001)(56776001)(56816005)(83072002)(81342001)(76482001)(81686001)(74366001)(87936001)(95416001)(512954002)(81816001)(54356001)(85852003)(46102001)(33656001)(55846006)(80022001)(54316002)(74502001)(93516002)(65816001)(76796001)(19580405001)(86362001)(74876001)(81542001)(92726001)(49866001)(20776003)(59766001)(74662001)(83322001)(31966008)(77096001)(84326002)(63696002)(77982001)(19300405004)(44976005)(66066001)(76786001)(6806004)(19580395003)(51856001)(85306002)(15202345003)(79102001)(47736001)(93136001)(47446002)(16236675002)(94946001)(47976001)(94316002)(80976001)(4396001)(1511001)(92566001)(50986001)(53806001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB592; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:DE7ED465.ACD6E181.B8F3B58B.4AACFA4D.204F2; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/ZpSDQ5gWfiBT1VoDFsFwwfTQ2UY Subject: Re: [jose] Issue #90 - Section 9 References X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:47:26 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B198DF0TK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These changes have been applied in the -21 drafts. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, February 07, 2014 4:46 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Issue #90 - Section 9 References Replies inline marked [mbj]... From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 4:34 PM To: Mike Jones; jose@ietf.org Subject: Re: [jose] Issue #90 - Section 9 References From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 07, 2014 3:40 PM To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Issue #90 - Section 9 References RFC 5116 is used in the JWA security considerations. I believe that securi= ty considerations are normative, correct? (RESPONSE TO THIS QUESTION REQUE= STED) Otherwise this can be moved to the set of informative references. [JLS] No they are not considered normative. They can be either normative o= r informative depending on what and how much of the document needs to be un= derstood in order to correctly implement the current protocol. It is alway= s a value judgment. [mbj] OK, if the security consideration references aren't normative, I'll m= ove them to the Informative References section. The "Specification Required" in RFC 5226 is required to be understood by pe= ople registering registry values, and therefore seems normative to me - at = least for those using the registry. This imposes a normative requirement o= n specification writers. [JLS] So - do I need to understand RFC 5226 in order to either understand o= r implement JOSE? [mbj] If the criteria is only normative requirements on implementers, versu= s normative requirements on people using the registries defined, I'll move = them to the Informative References section. draft-mcgrew-aead-aes-cbc-hmac-sha2 is definitely not required by implement= ers, since all the relevant normative content has been copied into JWA. Th= e reference is there for background or historical reasons only - clearly fi= tting the criteria for informative references. In fact, the draft appears = to have been abandoned - having expired, despite specific requests for spec= ific changes that would make it more JOSE-friendly having been communicated= to the author quite a while ago. [JLS] In that case - why have the reference at all? [mbj] To give credit where credit is due (and in hopes that David will even= tually apply the requested updates so we don't have to continue duplicating= the normative text). What specific references in JWS do you believe will not be present in the f= inal text? If the will not be present in the final text, I agree that they= should be non-normative. Yes, section 15.12 (The JSON Object) of ECMAScript must be understood by im= plementers, since it specifies the "lexically last duplicate member name" s= emantics, which are required by JOSE. [JLS] And you have stated that explicitly in the document - so why make the= reference at all - except to say that this is the same thing they do? That= is not normative. [mbj] This seems like a judgment call to me, since ECMASCript defines the "= lexically last duplicate member name semantics" and JOSE requires its use. = That seems normative to me, even if we paraphrase the requirement in the J= OSE specs. RFC 3986 defines URI and the specs use URIs - therefore I believe that this= is a normative reference. [JLSJ] In order to implement JOSE - do I need to understand all of the deta= ils of URIs or can I just treat them as opaque strings? [mbj] This seems like another judgment call. We're using URIs in normative= definitions, so a normative reference seems appropriate to me. What do ot= hers think in this case? -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 2:14 PM To: jose@ietf.org Subject: [jose] Issue #90 - Section 9 References I'll start with a quote from the RFC Editor "Instructions to Request for Co= mments (RFC) Authors" Normative references specify documents that must be read to understand or i= mplement the technology in the new RFC, or whose technology must be present= for the technology in the new RFC to work. An informative reference is no= t normative; rather, it provides only additional information. For example, = an informative reference might provide background or historical information= . Material in an informative reference is not required to implement the te= chnology in the RFC. Based on the above criteria, there are a number of references which I belie= ve are not in the correct bucket. I would ask the authors to review this p= rior to WGLC ending and re-evaluate based on the above criteria Examples of things that I think are misplaced: Algorithms draft - - RFC 5116 - this reference is going to disappear since it is just= used in the changes section. - RFC 5226 - Don't know why implementers would ever care about thi= s - McGrew-aed-aes-cbc-hmac-sha2 - you need to know how to do this i= n order to implement - thus it should be normative Signature Draft - Some of the drafts here are not reference in long term text Is ECMAScript something that needs to be understood? Is 3986 really a normative reference? --_000_4E1F6AAD24975D4BA5B16804296739438B198DF0TK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These changes have bee= n applied in the -21 drafts.

 

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

 

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, February 07, 2014 4:46 PM
To: Jim Schaad; jose@ietf.org
Subject: Re: [jose] Issue #90 - Section 9 References

 

Replies inline marked = [mbj]…

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 4:34 PM
To: Mike Jones; jose@ietf.org Subject: Re: [jose] Issue #90 - Section 9 References

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Friday, February 07, 2014 3:40 PM
To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Issue #90 - Section 9 References

 

RFC 5116 is used in th= e JWA security considerations.  I believe that security considerations= are normative, correct?  (RESPONSE TO THIS QUESTION REQUESTED)  = Otherwise this can be moved to the set of informative references.

 

[JLS] No they are not = considered normative.  They can be either normative or informative dep= ending on what and how much of the document needs to be understood in order= to correctly implement the current protocol.  It is always a value judgment.

 

[mbj] OK, if the secur= ity consideration references aren’t normative, I’ll move them t= o the Informative References section.

 

The “Specificati= on Required” in RFC 5226 is required to be understood by people regis= tering registry values, and therefore seems normative to me – at leas= t for those using the registry.  This imposes a normative requirement on specification writers.

 

[JLS] So – do I = need to understand RFC 5226 in order to either understand or implement JOSE= ?

 

[mbj] If the criteria = is only normative requirements on implementers, versus normative requiremen= ts on people using the registries defined, I’ll move them to the Info= rmative References section.

 

draft-mcgrew-aead-aes-= cbc-hmac-sha2 is definitely not required by implementers, since all the rel= evant normative content has been copied into JWA.  The reference is th= ere for background or historical reasons only – clearly fitting the criteria for informative references. = ; In fact, the draft appears to have been abandoned – having expired,= despite specific requests for specific changes that would make it more JOS= E-friendly having been communicated to the author quite a while ago.

[JLS] In that case = 211; why have the reference at all?

 

[mbj] To give credit w= here credit is due (and in hopes that David will eventually apply the reque= sted updates so we don’t have to continue duplicating the normative t= ext).

 

What specific referenc= es in JWS do you believe will not be present in the final text?  If th= e will not be present in the final text, I agree that they should be non-no= rmative.

 

Yes, section 15.12 (Th= e JSON Object) of ECMAScript must be understood by implementers, since it s= pecifies the “lexically last duplicate member name” semantics, = which are required by JOSE.

[JLS] And you have sta= ted that explicitly in the document – so why make the reference at al= l – except to say that this is the same thing they do? That is not no= rmative.

 

[mbj] This seems like = a judgment call to me, since ECMASCript defines the “lexically last d= uplicate member name semantics” and JOSE requires its use.  That= seems normative to me, even if we paraphrase the requirement in the JOSE specs.

 

RFC 3986 defines URI a= nd the specs use URIs – therefore I believe that this is a normative = reference.

[JLSJ] In order to imp= lement JOSE – do I need to understand all of the details of URIs or c= an I just treat them as opaque strings?

 

[mbj] This seems like = another judgment call.  We’re using URIs in normative definition= s, so a normative reference seems appropriate to me.  What do others t= hink in this case?

 

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

 

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 2:14 PM
To: jose@ietf.org
Subject: [jose] Issue #90 - Section 9 References

 

I’ll start with a quote from the RFC Editor “Instructions =
to Request for Comments (RFC) Authors”

 

Normative references specify documents that must be read t= o understand or implement the technology in the new RFC, or whose technolog= y must be present for the technology in the new RFC to work.  An informative reference is not normative; rather, it p= rovides only additional information. For example, an informative reference = might provide background or historical information.  Material in an in= formative reference is not required to implement the technology in the RFC.

 

Based on the above criteria, there are a number of r= eferences which I believe are not in the correct bucket.  I would ask = the authors to review this prior to WGLC ending and re-evaluate based on th= e above criteria

 

Examples of things that I think are misplaced:<= /o:p>

 

Algorithms draft –

-     &= nbsp;    RFC 5116 – this reference is going to disappe= ar since it is just used in the changes section.

-     &= nbsp;    RFC 5226 – Don’t know why implementers = would ever care about this

-     &= nbsp;    McGrew-aed-aes-cbc-hmac-sha2 – you need to kn= ow how to do this in order to implement – thus it should be normative=

 

Signature Draft

-     &= nbsp;    Some of the drafts here are not reference in long t= erm text

 

Is ECMAScript something that needs to be understood?=

Is 3986 really a normative reference?

 

--_000_4E1F6AAD24975D4BA5B16804296739438B198DF0TK5EX14MBXC288r_-- From nobody Fri Feb 14 17:48:30 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C4A1A0021 for ; Fri, 14 Feb 2014 17:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOPcJj-KXjno for ; Fri, 14 Feb 2014 17:48:27 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0D31A0018 for ; Fri, 14 Feb 2014 17:48:27 -0800 (PST) Received: from BY2PR03CA062.namprd03.prod.outlook.com (10.141.249.35) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:48:24 +0000 Received: from BL2FFO11FD009.protection.gbl (2a01:111:f400:7c09::171) by BY2PR03CA062.outlook.office365.com (2a01:111:e400:2c5d::35) with Microsoft SMTP Server (TLS) id 15.0.873.15 via Frontend Transport; Sat, 15 Feb 2014 01:48:24 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:48:23 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 01:47:40 +0000 From: Mike Jones To: Mark Watson , "jose@ietf.org" Thread-Topic: [jose] Naming of JWK key_ops values for wrap and unwrap Thread-Index: AQHPIsY6bdsPh25mGkiUXaqQOsdAq5q1mi2g Date: Sat, 15 Feb 2014 01:47:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B198EDB@TK5EX14MBXC288.redmond.corp.microsoft.com> References: 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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B198EDBTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51884002)(377454003)(56816005)(6806004)(51856001)(85852003)(94316002)(83072002)(93516002)(74876001)(74706001)(81342001)(76482001)(86612001)(81542001)(94946001)(90146001)(69226001)(86362001)(31966008)(20776003)(74662001)(63696002)(92566001)(55846006)(66066001)(84326002)(19580395003)(81816001)(76796001)(65816001)(80022001)(85306002)(15202345003)(47446002)(79102001)(87936001)(74366001)(19580405001)(95416001)(2656002)(80976001)(33656001)(59766001)(54316002)(49866001)(16236675002)(512954002)(92726001)(56776001)(4396001)(15975445006)(54356001)(71186001)(93136001)(53806001)(46102001)(50986001)(81686001)(83322001)(77096001)(77982001)(47976001)(87266001)(74502001)(19300405004)(95666001)(44976005)(47736001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:3874D95E.D528CC1.A1E1748A.566C792E.2010E; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/o59XdjvdOtQe7xk7tTR1uKcTU4I Subject: Re: [jose] Naming of JWK key_ops values for wrap and unwrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:48:29 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B198EDBTK5EX14MBXC288r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These changes have been applied in the -21 JOSE drafts. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mark Watson Sent: Wednesday, February 05, 2014 3:01 PM To: jose@ietf.org Subject: [jose] Naming of JWK key_ops values for wrap and unwrap All, Since JWK key_ops was added primarily to accurately represent WebCrypto key= s, would it be possible to amend the values for "wrap" and "unwrap" to "wra= pKey" and "unwrapKey" to align with the WebCrypto naming ? ...Mark --_000_4E1F6AAD24975D4BA5B16804296739438B198EDBTK5EX14MBXC288r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These changes have been applied in the -21= JOSE drafts.

 

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

 <= /p>

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mark Watson
Sent: Wednesday, February 05, 2014 3:01 PM
To: jose@ietf.org
Subject: [jose] Naming of JWK key_ops values for wrap and unwrap

 

All,

 

Since JWK key_ops was added primarily to accurately = represent WebCrypto keys, would it be possible to amend the values for &quo= t;wrap" and "unwrap" to "wrapKey" and "unwrap= Key" to align with the WebCrypto naming ?

 

...Mark

--_000_4E1F6AAD24975D4BA5B16804296739438B198EDBTK5EX14MBXC288r_-- From nobody Fri Feb 14 17:51:32 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66711A0021 for ; Fri, 14 Feb 2014 17:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuAw6RhYOrEf for ; Fri, 14 Feb 2014 17:51:28 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4E1A000E for ; Fri, 14 Feb 2014 17:51:28 -0800 (PST) Received: from BY2PR03CA029.namprd03.prod.outlook.com (10.242.234.150) by BY2PR03MB378.namprd03.prod.outlook.com (10.242.237.19) with Microsoft SMTP Server (TLS) id 15.0.878.16; Sat, 15 Feb 2014 01:51:18 +0000 Received: from BL2FFO11FD044.protection.gbl (2a01:111:f400:7c09::191) by BY2PR03CA029.outlook.office365.com (2a01:111:e400:2c2c::22) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Sat, 15 Feb 2014 01:51:18 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD044.mail.protection.outlook.com (10.173.161.140) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Sat, 15 Feb 2014 01:51:17 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.14]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Sat, 15 Feb 2014 01:50:44 +0000 From: Mike Jones To: "Manger, James H" , Matt Miller Thread-Topic: PBE salt should include alg id Thread-Index: Ac7cHLJnGKhPO+FXRQOSbPZhHYsMrBN02oQQ Date: Sat, 15 Feb 2014 01:50:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B19907F@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11536158EAB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11536158EAB@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739438B19907FTK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(377454003)(76796001)(47736001)(47976001)(49866001)(87266001)(55846006)(50986001)(74502001)(74662001)(69226001)(77096001)(83322001)(85306002)(74706001)(31966008)(47446002)(6806004)(4396001)(59766001)(86612001)(56776001)(15975445006)(54316002)(16236675002)(512874002)(53806001)(74876001)(77982001)(84326002)(46102001)(74366001)(54356001)(76482001)(94316002)(51856001)(95666001)(15202345003)(95416001)(81542001)(92566001)(81686001)(71186001)(93516002)(90146001)(56816005)(86362001)(81342001)(2656002)(92726001)(81816001)(65816001)(33656001)(19300405004)(93136001)(80022001)(20776003)(44976005)(19580405001)(80976001)(19580395003)(63696002)(85852003)(87936001)(83072002)(79102001)(66066001)(94946001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB378; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:364ED05C.2C227047.82EE3E83.44CC7D32.201AB; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 012349AD1C X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/t0l-02wzmrmZOCEk97AeoiJRtR4 Cc: "" Subject: Re: [jose] PBE salt should include alg id X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:51:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739438B19907FTK5EX14MBXC288r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlc2UgY2hhbmdlcyBoYXZlIGJlZW4gYXBwbGllZCBpbiB0aGUgLTIxIGRyYWZ0cy4gIFRoYW5r cyB0byBKYW1lcyBmb3IgdGhlIHN1Z2dlc3Rpb24gYW5kIHRoYW5rcyB0byBNYXR0IE1pbGxlciBm b3IgdXBkYXRpbmcgdGhlIGV4YW1wbGUgUEJFUzIgY29tcHV0YXRpb24gaW4gSldLIEFwcGVuZGl4 IEMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hbmdlciwgSmFtZXMgSA0K U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDA3LCAyMDEzIDQ6NTIgUE0NClRvOiA8am9zZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFtqb3NlXSBQQkUgc2FsdCBzaG91bGQgaW5jbHVkZSBhbGcgaWQNCg0K SldBIHNlY3Rpb24gNC45IOKAnEtleSBFbmNyeXB0aW9uIHdpdGggUEJFUzLigJ0gc2hvdWxkIGZv bGxvdyB0aGUgcmVjb21tZW5kYXRpb24gb2YgdGhlIFBCRVMyIHNwZWMgW1JGQyAyODk4IHNlY3Rp b24gNC4xIOKAnFNhbHTigJ1dIGJ5IGluY2x1ZGluZyBpbiB0aGUgc2FsdCDigJxkYXRhIHRoYXQg ZXhwbGljaXRseSBkaXN0aW5ndWlzaGVzIGJldHdlZW4gZGlmZmVyZW50IG9wZXJhdGlvbnMgYW5k IGRpZmZlcmVudCBrZXkgbGVuZ3Roc+KAnS4NCg0KV2UgY2FuIGRvIHRoaXMgcXVpdGUgZWFzaWx5 IGluIEpXQSBieSBpbmNsdWRpbmcgdGhlIGFsZyB2YWx1ZSAoZWcg4oCcUEJFUzItSFMzODQrQTE5 MktX4oCdKSBpbiB0aGUgc2FsdC4gSSBzdWdnZXN0Og0KDQogIHNhbHQgPSBVVEY4KGFsZykgfHwg MHgwMCB8fCBCQVNFNjRVUkxfREVDT0RFKHAycykNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739438B19907FTK5EX14MBXC288r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+VGhlc2UgY2hhbmdlcyBoYXZlIGJlZW4gYXBwbGllZCBpbiB0aGUg LTIxIGRyYWZ0cy4mbmJzcDsgVGhhbmtzIHRvIEphbWVzIGZvciB0aGUgc3VnZ2VzdGlvbiBhbmQg dGhhbmtzIHRvIE1hdHQgTWlsbGVyIGZvciB1cGRhdGluZyB0aGUgZXhhbXBsZSBQQkVTMiBjb21w dXRhdGlvbiBpbiBKV0sgQXBwZW5kaXggQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g am9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5NYW5nZXIsIEphbWVzIEg8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIE5vdmVtYmVyIDA3LCAyMDEzIDQ6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+ICZsdDtqb3NlQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gUEJFIHNhbHQgc2hvdWxkIGlu Y2x1ZGUgYWxnIGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiPkpXQSBzZWN0aW9uIDQuOSDigJxLZXkgRW5jcnlwdGlvbiB3 aXRoIFBCRVMy4oCdIHNob3VsZCBmb2xsb3cgdGhlIHJlY29tbWVuZGF0aW9uIG9mIHRoZSBQQkVT MiBzcGVjIFtSRkMgMjg5OCBzZWN0aW9uIDQuMSDigJxTYWx04oCdXSBieSBpbmNsdWRpbmcgaW4g dGhlIHNhbHQg4oCcZGF0YSB0aGF0IGV4cGxpY2l0bHkgZGlzdGluZ3Vpc2hlcyBiZXR3ZWVuIGRp ZmZlcmVudCBvcGVyYXRpb25zIGFuZA0KIGRpZmZlcmVudCBrZXkgbGVuZ3Roc+KAnS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQVUiPldlIGNhbiBkbyB0aGlzIHF1aXRlIGVhc2lseSBpbiBKV0EgYnkgaW5jbHVk aW5nIHRoZSBhbGcgdmFsdWUgKGVnIOKAnFBCRVMyLUhTMzg0JiM0MztBMTkyS1figJ0pIGluIHRo ZSBzYWx0LiBJIHN1Z2dlc3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIj4mbmJzcDsgc2FsdCA9IFVURjgo YWxnKSB8fCAweDAwIHx8IEJBU0U2NFVSTF9ERUNPREUocDJzKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+ LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1BVSI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739438B19907FTK5EX14MBXC288r_-- From nobody Fri Feb 21 10:31:46 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55F81A053C for ; Fri, 21 Feb 2014 10:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m0YWhY3shS2 for ; Fri, 21 Feb 2014 10:31:42 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40C1A0245 for ; Fri, 21 Feb 2014 10:31:41 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 9DBE12CA15; Fri, 21 Feb 2014 10:31:37 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 21 Feb 2014 10:29:55 -0800 Message-ID: <009401cf2f32$eb3800e0$c1a802a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac8tsMjoM5japsNRQtqud9uY7JnBqQ== Archived-At: http://mailarchive.ietf.org/arch/msg/jose/K9uKEu8F_94s8tE9J0IoqMKwvVw Cc: jose@ietf.org Subject: [jose] Chair Review of Draft-ietf-jose-json-web-signature X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:31:44 -0000 This is a review of the documents from a process point of view. All items here MUST be fixed prior to the document progressing. 1. Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). The "crit" (critical) Header Parameter indicates that extensions to the initial RFC versions of [[ this specification ]] and [JWA] are being used that MUST be understood and processed. Its value is an array listing the Header Parameter names present in the JWS Header that use those extensions. If any of the listed extension Header Parameters are not understood and supported by the receiver, it MUST reject the JWS. Senders must not include Header Parameter names defined by the initial RFC versions of [[ this specification ]] or [JWA] for use with JWS, duplicate names, or names that do not occur as Header Parameter names within the JWS Header in the "crit" list. Senders MUST not use the empty list "[]" as the "crit" value. Recipients MAY reject the JWS if the critical list contains any Header Parameter names defined by the initial RFC versions of [[ this specification ]] or [JWA] for use with JWS, or any other constraints on its use are violated. This Header Parameter MUST be integrity protected, and therefore MUST occur only within the JWS Protected Header, when used. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations. 2. Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) If there is a reason to reference TLS 1.0 rather than the current version of TLS, then there needs to be explicit justification made as to why this is the case. From nobody Fri Feb 21 10:31:56 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1560D1A0550 for ; Fri, 21 Feb 2014 10:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQqU6dofJIjt for ; Fri, 21 Feb 2014 10:31:47 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8623F1A0545 for ; Fri, 21 Feb 2014 10:31:47 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9EDC138F09; Fri, 21 Feb 2014 10:31:43 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 21 Feb 2014 10:30:01 -0800 Message-ID: <009501cf2f32$eecf7f80$cc6e7e80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac8tqoiKQTzfmwlzQPKh8mgeV1R1UQ== Archived-At: http://mailarchive.ietf.org/arch/msg/jose/BiXifsV1o9JTDM91D5p5ZSvmH4s Cc: jose@ietf.org Subject: [jose] Chair Review of Draft-ietf-jose-json-web-algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:31:49 -0000 This is a review of the documents from a process point of view. All items here MUST be fixed prior to the document progressing. 1. The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. From nobody Fri Feb 21 13:04:42 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B99D1A0273 for ; Fri, 21 Feb 2014 13:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuZpzynl9CAo for ; Fri, 21 Feb 2014 13:04:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7971A01F7 for ; Fri, 21 Feb 2014 13:04:37 -0800 (PST) Received: from BLUPR03CA031.namprd03.prod.outlook.com (10.141.30.24) by BLUPR03MB589.namprd03.prod.outlook.com (10.255.124.35) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 21 Feb 2014 21:04:32 +0000 Received: from BN1BFFO11FD051.protection.gbl (2a01:111:f400:7c10::1:163) by BLUPR03CA031.outlook.office365.com (2a01:111:e400:879::24) with Microsoft SMTP Server (TLS) id 15.0.888.9 via Frontend Transport; Fri, 21 Feb 2014 21:04:32 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD051.mail.protection.outlook.com (10.58.145.6) with Microsoft SMTP Server (TLS) id 15.0.878.20 via Frontend Transport; Fri, 21 Feb 2014 21:04:31 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.23]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0174.002; Fri, 21 Feb 2014 21:03:56 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Chair Review of Draft-ietf-jose-json-web-signature Thread-Index: Ac8tsMjoM5japsNRQtqud9uY7JnBqQBl3lFw Date: Fri, 21 Feb 2014 21:03:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739438B1B2FA4@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <009401cf2f32$eb3800e0$c1a802a0$@augustcellars.com> In-Reply-To: <009401cf2f32$eb3800e0$c1a802a0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(13464003)(164054003)(189002)(199002)(377454003)(81342001)(55846006)(54356001)(66066001)(80022001)(65816001)(50466002)(69226001)(77982001)(94316002)(59766001)(47976001)(49866001)(50986001)(47736001)(90146001)(93136001)(76796001)(76786001)(56776001)(56816005)(93516002)(4396001)(20776003)(63696002)(77096001)(46102001)(74876001)(85852003)(53806001)(87936001)(47446002)(79102001)(47776003)(81542001)(54316002)(6806004)(46406003)(92726001)(92566001)(86362001)(86612001)(95416001)(94946001)(74502001)(31966008)(74662001)(81816001)(87266001)(80976001)(74366001)(74706001)(51856001)(85306002)(15975445006)(19580405001)(83322001)(19580395003)(44976005)(76482001)(2656002)(23726002)(81686001)(33656001)(83072002)(95666003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB589; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:AE28C5FE.AC3211C2.3DD3BF4B.8EEAD121.2031B; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 01294F875B X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/jose/B_CRbHgf0__lFoTLGt00okqVejM Cc: "jose@ietf.org" Subject: Re: [jose] Chair Review of Draft-ietf-jose-json-web-signature X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:04:40 -0000 Is there any related feedback on JWE or JWK or are you done with your chair= review of them and no issues were identified? Thanks, -- Mike -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, February 21, 2014 10:30 AM To: draft-ietf-jose-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: [jose] Chair Review of Draft-ietf-jose-json-web-signature This is a review of the documents from a process point of view. All items = here MUST be fixed prior to the document progressing. 1. Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD'= , or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what y= ou mean). The "crit" (critical) Header Parameter indicates that extensions to the initial RFC versions of [[ this specification ]] and [JWA] are bei= ng used that MUST be understood and processed. Its value is an array listing the Header Parameter names present in the JWS Header that use those extensions. If any of the listed extension Header Parameters ar= e not understood and supported by the receiver, it MUST reject the JWS.= =20 Senders must not include Header Parameter names defined by the initial RFC versions of [[ this specification ]] or [JWA] for use with JWS, duplicate names, or names that do not occur as Header Parameter names within the JWS Header in the "crit" list. Senders MUST not use the emp= ty list "[]" as the "crit" value. Recipients MAY reject the JWS if the critical list contains any Header Parameter names defined by the initi= al RFC versions of [[ this specification ]] or [JWA] for use with JWS, or any other constraints on its use are violated. This Header Parameter MUST be integrity protected, and therefore MUST occur only within the = JWS Protected Header, when used. Use of this Header Parameter is OPTIONAL= . This Header Parameter MUST be understood and processed by implementati= ons. 2. Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) If there is a reason to reference TLS 1.0 rather than the current version = of TLS, then there needs to be explicit justification made as to why this i= s the case. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Fri Feb 21 13:38:46 2014 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA101A02D1 for ; Fri, 21 Feb 2014 13:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVZeJ-dFf3Nd for ; Fri, 21 Feb 2014 13:38:43 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 674D91A0135 for ; Fri, 21 Feb 2014 13:38:43 -0800 (PST) Received: from Philemon (unknown [69.33.100.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1A3F038F59; Fri, 21 Feb 2014 13:38:39 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <009401cf2f32$eb3800e0$c1a802a0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739438B1B2FA4@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739438B1B2FA4@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Fri, 21 Feb 2014 13:36:56 -0800 Message-ID: <00d401cf2f4d$0c097f50$241c7df0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQMsTUuOxVWgmLlgxS1EClbsUudztQHxOZDLl/Z1o9A= Archived-At: http://mailarchive.ietf.org/arch/msg/jose/yJM6cnTMrDBeNRdT7w9CO7xl4nI Cc: jose@ietf.org Subject: Re: [jose] Chair Review of Draft-ietf-jose-json-web-signature X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:38:46 -0000 No issues identified on the other two documents. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, February 21, 2014 1:04 PM > To: Jim Schaad > Cc: jose@ietf.org > Subject: RE: [jose] Chair Review of Draft-ietf-jose-json-web-signature > > Is there any related feedback on JWE or JWK or are you done with your chair > review of them and no issues were identified? > > Thanks, > -- Mike > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, February 21, 2014 10:30 AM > To: draft-ietf-jose-json-web-signature@tools.ietf.org > Cc: jose@ietf.org > Subject: [jose] Chair Review of Draft-ietf-jose-json-web-signature > > This is a review of the documents from a process point of view. All items > here MUST be fixed prior to the document progressing. > > > 1. Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', > or 'RECOMMENDED' is not an accepted usage according to RFC 2119. > Please > use uppercase 'NOT' together with RFC 2119 keywords (if that is what you > mean). > > The "crit" (critical) Header Parameter indicates that extensions to > the initial RFC versions of [[ this specification ]] and [JWA] are being > used that MUST be understood and processed. Its value is an array > listing the Header Parameter names present in the JWS Header that use > those extensions. If any of the listed extension Header Parameters are > not understood and supported by the receiver, it MUST reject the JWS. > Senders must not include Header Parameter names defined by the initial > RFC versions of [[ this specification ]] or [JWA] for use with JWS, > duplicate names, or names that do not occur as Header Parameter names > within the JWS Header in the "crit" list. Senders MUST not use the empty > list "[]" as the "crit" value. Recipients MAY reject the JWS if the > critical list contains any Header Parameter names defined by the initial > RFC versions of [[ this specification ]] or [JWA] for use with JWS, or > any other constraints on its use are violated. This Header Parameter > MUST be integrity protected, and therefore MUST occur only within the > JWS > Protected Header, when used. Use of this Header Parameter is > OPTIONAL. > > This Header Parameter MUST be understood and processed by > implementations. > > > 2. Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) > > If there is a reason to reference TLS 1.0 rather than the current > version of TLS, then there needs to be explicit justification made as to why > this is the case. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose