From mamille2@cisco.com Wed Aug 1 08:32:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0391921F89EF for ; Wed, 1 Aug 2012 08:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5pm30bKkDw7 for ; Wed, 1 Aug 2012 08:32:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B1BD821F89ED for ; Wed, 1 Aug 2012 08:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4588; q=dns/txt; s=iport; t=1343835160; x=1345044760; h=from:to:subject:date:message-id:mime-version; bh=GRCpKzYm2h0oRrjbJTrTLsahdhihUaIqGnb2Pz2AGUs=; b=ThOJUosbYfkgBWChtnu98XMgENA/aj4DNyYUrXE4h83fJplW/jK6Qnz9 Fm4jNex6wbs5+LXPMyDdeLurBOfov7GFQQ/KGZZePIEs2CMLGSTkm4lyq IFk8X0Zn+etDjQzYKa4SdA7DNsCysVIHp39RrtqGg5IanyUv5a98Jn/to w=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACRLGVCtJV2a/2dsb2JhbABFgyyCCLNcgQeCJQISAXgBUDAnBBMOFIdrC5sogSigTZFyYAOOV4EghVCOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,694,1336348800"; d="sig'?p7s'?scan'208";a="107462479" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2012 15:32:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q71FWex9013030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Aug 2012 15:32:40 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.93]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 10:32:39 -0500 From: "Matt Miller (mamille2)" To: "jose@ietf.org" Thread-Topic: LAST MINUTE - Updated Slides Thread-Index: AQHNb/riIILYYrSNE02M7wWKg1RyAw== Date: Wed, 1 Aug 2012 15:32:38 +0000 Message-ID: <88F361B6-2462-4590-91EF-ED4D7887BAF0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [10.21.116.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--27.756600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-455737367" MIME-Version: 1.0 Subject: [jose] LAST MINUTE - Updated Slides X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:32:44 -0000 --Apple-Mail-8-455737367 Content-Type: multipart/signed; boundary=Apple-Mail-7-455737366; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-7-455737366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here's a last-minute update to my slides, based on feedback from the = XMPP WG meeting. Sorry for the late delivery! < http://outer-planes.net/ietf/ietf84-josewg-xmpp.pdf > - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-7-455737366 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgwMTE1MzIz N1owIwYJKoZIhvcNAQkEMRYEFNIr5pE5Mo79GndbGhvhUxYZnTpUMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQB8yuPrtXhSXxFnxgp4XL5YCsWnZLe3UQx5shaxNnWEYzZqs9lCjziHYGQt 16s/5N1tu/FWD6rKRwL2OKEEeSL/3mbCUAqUnewJXPdNP/4OLywKOtmaJe2CV5QdjAKltYhav7Zg REqy/tX0zqAeSW8bDIUT4TPqYJG1f/qtIdPqyqi+00l8T5Ay7ojI3wUZzz/jsga83bGkAFwIBCq5 GPwceHfAsd5f+tAF6CYaktL1wmZbP3xeixl1aYMlBGyKBCFm18gYAsLoCmjOK0gnk/uzb3VEvXcb c08Qzuf83/HRc0AIC8dtW/t6/Q+ZNvacvAzBfBDDZ/GHKms6zElC8n3EAAAAAAAA --Apple-Mail-7-455737366-- --Apple-Mail-8-455737367 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQGUwVAAoJEJq6Ou0cgrSP5IoIAKQB/wjJGFWUQHlCBtdvZTp7 UZ14ZH2QHcH3mcN5O6+wSYpb31PLYb0gpODXCSlsXqa7XbaZ9h2V7VaUQMni4d7z AKzuNwEM6VKcNuOnogSEoFZAp8Dcx1obGa1rcnBokmoReNph/ly+yFe80PUxKzVo 8Ind6nMaoZz6/MhLVV1+coZpsj+lr5WnX0AMywTI0Dy/x44z1lBjGCEjXQK6ETFS h6ZVb2AkRCcpqvwp/iDp0Whs+xKJkDplQ4uQhI2E3xBwPiJkNwf9G2vNSFjWbuxV n9qrNmQ7pHd86fDr9mR/6SlpHyXD8rJmjZYwgwLabzRhDcmDAxcM54UBLO4zWws= =2L8K -----END PGP SIGNATURE----- --Apple-Mail-8-455737367-- From ekr@rtfm.com Wed Aug 1 10:09:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C28211E8191 for ; Wed, 1 Aug 2012 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuv0kl9vbPHp for ; Wed, 1 Aug 2012 10:09:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6893811E8117 for ; Wed, 1 Aug 2012 10:09:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7875719vbb.31 for ; Wed, 01 Aug 2012 10:09:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=jZZohHxXETjspKJRGalxr1a5VOaaEpweLyMQjY7CiHg=; b=Gyd7/lFHCSsq7FarjOItUgRKDyO8o82aIjC45JLnQ29AvI2/cpET2/JSSNgLCxwR6A SnHp79mp+Xo5//h8ZiVVwPrQAH5DRThMYuI6YZLNGt5P/gN4RXacOBnvfl7HaRER+PeO p8XQ/G4L6jnl/WyZeflJs3KAGj23stBXxmTGmw31al+AcYMm1xQ4vWjZmRTKq9xha9Ue xmhp2St91ve0YQw2cgkiWwpXV0Ro5ZhgX2h0hyOSR29kC7hWDbEFH2BTcVth5IEw6NxD tAtp+JhZ1DAbqCgsdErkXsXpZcfaY9JAktdHg84BAH2eCcZtgsgTeKw8nX/hjz2AvQYX 26qA== Received: by 10.52.37.233 with SMTP id b9mr1165353vdk.107.1343840954828; Wed, 01 Aug 2012 10:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.103 with HTTP; Wed, 1 Aug 2012 10:08:34 -0700 (PDT) X-Originating-IP: [130.129.85.212] From: Eric Rescorla Date: Wed, 1 Aug 2012 10:08:34 -0700 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm2HUexwVJXcHwxb9cjQv3poGVc/7fE+n2kM1frNTlGlJNKxSWIQ/PgLMmZyeCWUyaQSSJO Subject: [jose] The paper I was citing earlier today X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:09:17 -0000 See this paper: http://www.schneier.com/paper-ssl.html Section 4.4 "The signed params field contains the server=92s sig- nature on a hash of the relevant ServerParams field, but the signature does not cover the KeyExchangeAlgorithm value. Therefore, by mod- ifying the (unprotected) KeyExchangeAlgorithm field, we can abuse the server=92s legitimate signa- ture on a set of Diffie-Hellman parameters and fool the client into thinking the server signed a set of ephemeral RSA parameters. We should point out that particularly cautious im- plementation might not be fooled by such tricks, if they check the length of the ServerParams field carefully. For example, SSLRef 3.0b1 is paranoid enough that it would detect such an attack. How- ever, in general, the specification is silent on the matter, and some compliant implementations could easily be vulnerable." -Ekr From Axel.Nennker@telekom.de Wed Aug 1 13:37:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022A711E82A9 for ; Wed, 1 Aug 2012 13:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKZFR093hdez for ; Wed, 1 Aug 2012 13:37:57 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 91CAC11E829D for ; Wed, 1 Aug 2012 13:37:56 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 01 Aug 2012 22:37:54 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Wed, 1 Aug 2012 22:37:54 +0200 From: To: Date: Wed, 1 Aug 2012 22:37:52 +0200 Thread-Topic: implementing JOSE in Java: jsoncrypto Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5g== Message-ID: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:37:58 -0000 I moved my JOSE implementation out of my openinfocard project into a new re= pository: https://code.google.com/p/jsoncrypto/ One way to dive into this API is to look at the JUNIT test cases. They go t= hrough all the API calls and test the examples provided in the specs. https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/xmldap= /json/WebTokenTest.java Axel https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/xmldap/jso= n/WebToken.java From James.H.Manger@team.telstra.com Wed Aug 1 18:26:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41B111E813A for ; Wed, 1 Aug 2012 18:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0z-Wqpq0VMf0 for ; Wed, 1 Aug 2012 18:26:25 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id CCF7211E810C for ; Wed, 1 Aug 2012 18:26:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,697,1336312800"; d="scan'208";a="84930312" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 02 Aug 2012 11:26:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6790"; a="78854156" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 02 Aug 2012 11:26:22 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 2 Aug 2012 11:26:21 +1000 From: "Manger, James H" To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Date: Thu, 2 Aug 2012 11:26:20 +1000 Thread-Topic: implementing JOSE in Java: jsoncrypto Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5gAJIbgg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:26:26 -0000 QXhlbCwNCg0KPiBJIG1vdmVkIG15IEpPU0UgaW1wbGVtZW50YXRpb24gb3V0IG9mIG15IG9wZW5p bmZvY2FyZCBwcm9qZWN0IGludG8gYQ0KPiBuZXcgcmVwb3NpdG9yeToNCj4gaHR0cHM6Ly9jb2Rl Lmdvb2dsZS5jb20vcC9qc29uY3J5cHRvLw0KDQpJdCBpcyBnb29kIHRvIHNlZSBhbm90aGVyIEpP U0UgaW1wbGVtZW50YXRpb24uDQoNCkRvZXMganNvbmNyeXB0byBpbXBsZW1lbnQgdGhlICJNVVNU IHVuZGVyc3RhbmQgZXZlcnl0aGluZyIgcnVsZT8NCg0KICBbSldFLTA1LCBzZWN0aW9uIDRdDQog IEltcGxlbWVudGF0aW9ucyBNVVNUIHVuZGVyc3RhbmQgdGhlIGVudGlyZSBjb250ZW50cyBvZiB0 aGUNCiAgaGVhZGVyOyBvdGhlcndpc2UsIHRoZSBKV0UgTVVTVCBiZSByZWplY3RlZC4NCg0KICBb SldFLTA1LCBzZWN0aW9uIDZdDQogIDQuIFRoZSByZXN1bHRpbmcgSldFIEhlYWRlciBNVVNUIGJl IHZhbGlkYXRlZCB0byBvbmx5IGluY2x1ZGUNCiAgICAgcGFyYW1ldGVycyBhbmQgdmFsdWVzIHdo b3NlIHN5bnRheCBhbmQgc2VtYW50aWNzIGFyZSBib3RoDQogICAgIHVuZGVyc3Rvb2QgYW5kIHN1 cHBvcnRlZC4NCg0KSnNvbmNyeXB0byBkb2VzIG5vdCBhcHBlYXIgdG8gaW1wbGVtZW50IHRoaXMg cnVsZS4gSXQgYXBwZWFycyB0byB0YWtlIHRoZSBvYnZpb3VzIGFwcHJvYWNoIG9mIGxvb2tpbmcg aW4gdGhlIGhlYWRlciBmb3IgdGhlIGZpZWxkcyBpdCBuZWVkcyAtLSBhbmQgaWdub3JpbmcgYW55 dGhpbmcgZWxzZSB0aGF0IG1pZ2h0IGJlIHRoZXJlLg0KDQpbUmVnYXJkbGVzcyBvZiBhbnkgcG9z c2libGUgbWVyaXQgaW4gYSAiTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmciIHJ1bGUsIHRoZSBm YWN0IHRoYXQgaXQgd2lsbCBvZnRlbiBub3QgYmUgaW1wbGVtZW50ZWQgc2VlbXMgbGlrZSBhIHJl YWxseSBnb29kIHJlYXNvbiB0byBkcm9wIHRoZSBydWxlIHNvIHRoZSBzcGVjIHJlZmxlY3RzIHJl YWxpdHkuXQ0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From Axel.Nennker@telekom.de Wed Aug 1 21:55:36 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1769321F8AAE for ; Wed, 1 Aug 2012 21:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ikbdFxheFoL for ; Wed, 1 Aug 2012 21:55:34 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 492F821F8AAD for ; Wed, 1 Aug 2012 21:55:33 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 02 Aug 2012 06:55:32 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Thu, 2 Aug 2012 06:55:31 +0200 From: To: , Date: Thu, 2 Aug 2012 06:55:30 +0200 Thread-Topic: implementing JOSE in Java: jsoncrypto Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5gAJIbggAAf6HlA= Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 04:55:36 -0000 SSB3YW50ZWQgdG8gd2FpdCBhIGxpdHRsZSBtb3JlIGJlZm9yZSBpbXBsZW1lbnRpbmcgdGhhdCBi ZWNhdXNlIHRoZSBkaXNjdXNzaW9uIGhlcmUgYWJvdXQgaXQgc2VlbXMgdG8gYnJpbmcgdG9vIG1h bnkgY2hhbmdlcyB0byB0aGUgY29kZS4NClRoZXJlIGFyZSBvdGhlciB0aGluZ3MgdG9vIHRoYXQg bmVlZCB0byBiZSBpbXByb3ZlZC4gQnV0IGpzb25jcnlwdG8gaW1wbGVtZW50cyBhbGwgcHJvcG9z ZWQgYWxnIGFuZCBlbmMgdmFsdWVzIG90aGVyIHRoYW4gbm9uZSAod2hpY2ggSSBmaW5kIHN0cmFu Z2UpIGFuZCBkaXIgKHdoaWNoIEkgaGFkIGltcGxlbWVudGVkIGZpcnN0IGJ1dCB0aGUgZ3JvdXAg YXQgdGhhdCB0aW1lIHNlZW1lZCB0byB0aGluayB0aGF0IHRoaXMgbWlnaHQgbWFrZSBpdCB0b28g ZWFzeSBmb3IgZGV2ZWxvcGVycyB0byB1c2UgdGhlIHNhbWUgY2VrIHRvbyBvZnRlbiAoYWx3YXlz KSkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYW5nZXIsIEphbWVzIEgg W21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXSANClNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMDIsIDIwMTIgMzoyNiBBTQ0KVG86IE5lbm5rZXIsIEF4ZWw7IGpvc2VAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBpbXBsZW1lbnRpbmcgSk9TRSBpbiBKYXZhOiBqc29uY3J5cHRvDQoN CkF4ZWwsDQoNCj4gSSBtb3ZlZCBteSBKT1NFIGltcGxlbWVudGF0aW9uIG91dCBvZiBteSBvcGVu aW5mb2NhcmQgcHJvamVjdCBpbnRvIGEgDQo+IG5ldyByZXBvc2l0b3J5Og0KPiBodHRwczovL2Nv ZGUuZ29vZ2xlLmNvbS9wL2pzb25jcnlwdG8vDQoNCkl0IGlzIGdvb2QgdG8gc2VlIGFub3RoZXIg Sk9TRSBpbXBsZW1lbnRhdGlvbi4NCg0KRG9lcyBqc29uY3J5cHRvIGltcGxlbWVudCB0aGUgIk1V U1QgdW5kZXJzdGFuZCBldmVyeXRoaW5nIiBydWxlPw0KDQogIFtKV0UtMDUsIHNlY3Rpb24gNF0N CiAgSW1wbGVtZW50YXRpb25zIE1VU1QgdW5kZXJzdGFuZCB0aGUgZW50aXJlIGNvbnRlbnRzIG9m IHRoZQ0KICBoZWFkZXI7IG90aGVyd2lzZSwgdGhlIEpXRSBNVVNUIGJlIHJlamVjdGVkLg0KDQog IFtKV0UtMDUsIHNlY3Rpb24gNl0NCiAgNC4gVGhlIHJlc3VsdGluZyBKV0UgSGVhZGVyIE1VU1Qg YmUgdmFsaWRhdGVkIHRvIG9ubHkgaW5jbHVkZQ0KICAgICBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMg d2hvc2Ugc3ludGF4IGFuZCBzZW1hbnRpY3MgYXJlIGJvdGgNCiAgICAgdW5kZXJzdG9vZCBhbmQg c3VwcG9ydGVkLg0KDQpKc29uY3J5cHRvIGRvZXMgbm90IGFwcGVhciB0byBpbXBsZW1lbnQgdGhp cyBydWxlLiBJdCBhcHBlYXJzIHRvIHRha2UgdGhlIG9idmlvdXMgYXBwcm9hY2ggb2YgbG9va2lu ZyBpbiB0aGUgaGVhZGVyIGZvciB0aGUgZmllbGRzIGl0IG5lZWRzIC0tIGFuZCBpZ25vcmluZyBh bnl0aGluZyBlbHNlIHRoYXQgbWlnaHQgYmUgdGhlcmUuDQoNCltSZWdhcmRsZXNzIG9mIGFueSBw b3NzaWJsZSBtZXJpdCBpbiBhICJNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZyIgcnVsZSwgdGhl IGZhY3QgdGhhdCBpdCB3aWxsIG9mdGVuIG5vdCBiZSBpbXBsZW1lbnRlZCBzZWVtcyBsaWtlIGEg cmVhbGx5IGdvb2QgcmVhc29uIHRvIGRyb3AgdGhlIHJ1bGUgc28gdGhlIHNwZWMgcmVmbGVjdHMg cmVhbGl0eS5dDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Thu Aug 2 00:16:34 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3C21F87FF for ; Thu, 2 Aug 2012 00:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAJnYjTyRBO2 for ; Thu, 2 Aug 2012 00:16:34 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id DB05C21F8CAD for ; Thu, 2 Aug 2012 00:16:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,699,1336312800"; d="scan'208";a="83497712" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 02 Aug 2012 17:16:32 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6790"; a="80519940" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 02 Aug 2012 17:16:31 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 2 Aug 2012 17:16:31 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 2 Aug 2012 17:16:30 +1000 Thread-Topic: AESWrap vs ECB key wrap Thread-Index: Ac1wfrzy/T+dm17hTSCmvrFUCKSwfg== Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] AESWrap vs ECB key wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:16:35 -0000 SSBub3RpY2VkIGFuICJFQ0Iga2V5IHdyYXAiIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGF0IHRoZSBJ RVRGIG1lZXRpbmcsIGFzIGFuIGFsdGVybmF0aXZlIHRvIEFFU1dyYXAgW1JGQyAzMzk0XS4NCg0K SSBoYWRuJ3QgbG9va2VkIGNsb3NlbHkgYXQgQUVTV3JhcCBiZWZvcmUuIEl0cyBpbXBvcnRhbnQg ZmVhdHVyZXMgc2VlbSB0byBiZToNCjEuIE9ubHkgZGVmaW5lZCBmb3IgY29udGVudCBrZXlzIHRo YXQgYXJlIGEgbXVsdGlwbGUgb2YgNjQtYml0cw0KMi4gQWRkcyBhbiBvdmVyaGVhZCBvZiA2NCBi aXRzICg9IDggYnl0ZXMgPSAxMiBCNjQgY2hhcnMpDQozLiBPZmZlcnMgYSA2NC1iaXQgaW50ZWdy aXR5IGNoZWNrIChmcm9tIHRoZSBvdmVyaGVhZCkNCjQuIFBlcmZvcm1zIDEyIEFFUyBvcGVyYXRp b25zIGZvciBlYWNoIDY0LWJpdHMgb2YgdGhlIGNvbnRlbnQga2V5DQoNCkkgYXNzdW1lIGFuIEVD QiBrZXkgd3JhcCwgaW4gY29udHJhc3QsIHdvdWxkIGF2b2lkIHRoZSA2NC1iaXQgb3ZlcmhlYWQg YnkgZHJvcHBpbmcgdGhlIGludGVncml0eSBjaGVjayBhbmQgb25seSB1c2UgMS8yNHRoIG9mIHRo ZSBBRVMgb3BlcmF0aW9ucy4gV291bGQgaXQgYWxzbyB1c2UsIHNheSwgY2lwaGVydGV4dCBzdGVh bGluZyBzbyB0aGVyZSBpcyBubyBzaXplIG92ZXJoZWFkIGZvciBhbnkgY29udGVudCBrZXkgc2l6 ZT8NCg0KSWYgYSAxMiBieXRlIG92ZXJoZWFkICh3aGVuIGJhc2U2NHVybC1lbmNvZGVkKSBpcyB0 b28gc21hbGwgdG8gd29ycnkgYWJvdXQgKGFuZCBhbiBleHRyYSwgc2F5LCA0NiBBRVMgb3BlcmF0 aW9ucyBpcyBpbW1hdGVyaWFsKSwgdGhlbiBKT1NFIHNob3VsZCBrZWVwIEFFU1dyYXAgYXMgdGhl IG9ubHkgY2hvaWNlLiBJdCBzdGlsbCBuZWVkIHRvIGRlZmluZSBob3cgdG8gdXNlIEFFU1dyYXAg Zm9yIGNvbnRlbnQga2V5cyB0aGF0IGFyZSBub3QgYSBtdWx0aXBsZSBvZiA2NC1iaXRzLiBQZXJo YXBzIG9uZSBieXRlIG9mIHRoZSBpbnRlZ3JpdHkgY2hlY2sgaXMgY2hhbmdlZCB0byBpbmRpY2F0 ZSB0aGUgY29udGVudCBrZXkgbGVuZ3RoPw0KDQpJZiBzaXplIGlzIGdvaW5nIHRvIGJlIGFic29s dXRlbHkgY3J1Y2lhbCBmb3Igc29tZSB1c2UgY2FzZXMsIHRoZW4gYW4gRUNCIGtleSB3cmFwIGNv dWxkIGhlbHAuIFN1Y2ggYSBzaXplLWNvbnN0cmFpbmVkIHNpdHVhdGlvbiB3b3VsZCBwcm9iYWJs eSBuZWVkIG90aGVyIGNoYW5nZXMgYXMgd2VsbCwgc3VjaCBhcyB0aGUgY2hvaWNlIG9mIGEgc2hv cnRlZCBJViBhbmQgaW50ZWdyaXR5IHRhZyBmb3IgQUVTLUdDTSAodGhhbiB0aGUgMTI4LWJpdHMg YW5kIDk2LWJpdHMgcGlja2VkIGluIEpXQSkuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K From James.H.Manger@team.telstra.com Thu Aug 2 00:24:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3768E21F8CF5 for ; Thu, 2 Aug 2012 00:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkN-phom4Fxp for ; Thu, 2 Aug 2012 00:24:00 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6865721F8D03 for ; Thu, 2 Aug 2012 00:24:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,699,1336312800"; d="scan'208";a="83498802" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 02 Aug 2012 17:24:00 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6790"; a="80243038" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 02 Aug 2012 17:23:59 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 2 Aug 2012 17:23:59 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 2 Aug 2012 17:23:58 +1000 Thread-Topic: AESWrap vs ECB key wrap Thread-Index: Ac1wfrzy/T+dm17hTSCmvrFUCKSwfgAAHmgw Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA1E3FAD@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] AESWrap vs ECB key wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:24:01 -0000 PiBJIGhhZG4ndCBsb29rZWQgY2xvc2VseSBhdCBBRVNXcmFwIGJlZm9yZS4gSXRzIGltcG9ydGFu dCBmZWF0dXJlcyBzZWVtDQo+IHRvIGJlOg0KPiAxLiBPbmx5IGRlZmluZWQgZm9yIGNvbnRlbnQg a2V5cyB0aGF0IGFyZSBhIG11bHRpcGxlIG9mIDY0LWJpdHMNCj4NCj4gLi4uW0pPU0VdIHN0aWxs IG5lZWQgdG8gZGVmaW5lIGhvdyB0bw0KPiB1c2UgQUVTV3JhcCBmb3IgY29udGVudCBrZXlzIHRo YXQgYXJlIG5vdCBhIG11bHRpcGxlIG9mIDY0LWJpdHMuDQoNCkkganVzdCBub3RpY2VkIHRoYXQg dGhpcyBoYXMgYWxyZWFkeSBiZWVuIGRvbmU6DQpSRkMgNTY0OSBBRVMgS2V5IFdyYXAgd2l0aCBQ YWRkaW5nIEFsZ29yaXRobQ0KDQpTbyB3ZSBqdXN0IG5lZWQgdG8gcmVmZXJlbmNlIHRoaXMgc3Bl YyBpbiBKV0EuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From Axel.Nennker@telekom.de Thu Aug 2 02:14:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE42F21F8E5A for ; Thu, 2 Aug 2012 02:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svIUSaJZjqKP for ; Thu, 2 Aug 2012 02:14:09 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id DF78921F8E5B for ; Thu, 2 Aug 2012 02:14:07 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 02 Aug 2012 11:14:05 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Thu, 2 Aug 2012 11:14:05 +0200 From: To: , Date: Thu, 2 Aug 2012 11:14:03 +0200 Thread-Topic: implementing JOSE in Java: jsoncrypto Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5gAJIbggAAf6HlAACRcucA== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 09:14:10 -0000 Done. checkHeader function is called in all encrypt, decrypt, sign and verify fun= ctions now. Please keep those improvement suggestions coming. This code is not final. Axel public static void checkHeader(JSONObject jweHeader) throws Exceptio= n { @SuppressWarnings("rawtypes") Iterator iter =3D jweHeader.keys(); while (iter.hasNext()) { String key =3D (String) iter.next(); if ("alg".equals(key)) continue; if ("enc".equals(key)) continue; if ("int".equals(key)) continue; if ("kdf".equals(key)) continue; if ("iv".equals(key)) continue; if ("epk".equals(key)) continue; if ("zip".equals(key)) continue; if ("jku".equals(key)) continue; if ("jwk".equals(key)) continue; if ("x5u".equals(key)) continue; if ("x5t".equals(key)) continue; if ("x5c".equals(key)) continue; if ("kid".equals(key)) continue; if ("typ".equals(key)) continue; if ("cty".equals(key)) continue; if ("jku".equals(key)) continue; if ("jwk".equals(key)) continue; throw new Exception("unknown key in header: " + key= ); } } -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nen= nker, Axel Sent: Thursday, August 02, 2012 6:56 AM To: James.H.Manger@team.telstra.com; jose@ietf.org Subject: Re: [jose] implementing JOSE in Java: jsoncrypto I wanted to wait a little more before implementing that because the discuss= ion here about it seems to bring too many changes to the code. There are other things too that need to be improved. But jsoncrypto impleme= nts all proposed alg and enc values other than none (which I find strange) = and dir (which I had implemented first but the group at that time seemed to= think that this might make it too easy for developers to use the same cek = too often (always)). -----Original Message----- From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 Sent: Thursday, August 02, 2012 3:26 AM To: Nennker, Axel; jose@ietf.org Subject: RE: implementing JOSE in Java: jsoncrypto Axel, > I moved my JOSE implementation out of my openinfocard project into a=20 > new repository: > https://code.google.com/p/jsoncrypto/ It is good to see another JOSE implementation. Does jsoncrypto implement the "MUST understand everything" rule? [JWE-05, section 4] Implementations MUST understand the entire contents of the header; otherwise, the JWE MUST be rejected. [JWE-05, section 6] 4. The resulting JWE Header MUST be validated to only include parameters and values whose syntax and semantics are both understood and supported. Jsoncrypto does not appear to implement this rule. It appears to take the o= bvious approach of looking in the header for the fields it needs -- and ign= oring anything else that might be there. [Regardless of any possible merit in a "MUST understand everything" rule, t= he fact that it will often not be implemented seems like a really good reas= on to drop the rule so the spec reflects reality.] -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Thu Aug 2 06:54:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A338611E80A3 for ; Thu, 2 Aug 2012 06:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFdG-0F7BeDH for ; Thu, 2 Aug 2012 06:54:34 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0705811E80A2 for ; Thu, 2 Aug 2012 06:54:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,701,1336312800"; d="scan'208";a="87118963" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 02 Aug 2012 23:54:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6790"; a="78981990" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbvi.tcif.telstra.com.au with ESMTP; 02 Aug 2012 23:54:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 2 Aug 2012 23:54:30 +1000 From: "Manger, James H" To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Date: Thu, 2 Aug 2012 23:54:28 +1000 Thread-Topic: implementing JOSE in Java: jsoncrypto Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5gAJIbggAAf6HlAACRcucAAH036A Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA1E40F0@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 13:54:35 -0000 PiBEb25lLg0KPiBjaGVja0hlYWRlciBmdW5jdGlvbiBpcyBjYWxsZWQgaW4gYWxsIGVuY3J5cHQs IGRlY3J5cHQsIHNpZ24gYW5kIHZlcmlmeQ0KPiBmdW5jdGlvbnMgbm93Lg0KDQpUaGF0IHdhcyBw cmV0dHkgcXVpY2ssIGJ1dCBhbHNvIHBldHR5IGF3ZnVsLg0KSWYgYW4gYXBwIHVzaW5nIHlvdXIg bGlicmFyeSBub3cgcmVjZWl2ZXMgYSBKV0Ugd2l0aCwgc2F5LCBhICJjcmVhdGlvblRpbWUiIGZp ZWxkIChzdWdnZXN0ZWQgYXQgdGhlIElFVEYgbWVldGluZyBJIHRoaW5rKSBpdCB3aWxsIGZhaWwg dW5uZWNlc3NhcmlseS4gVGhlIGFwcCBuZWVkcyB0byBtb2RpZnkgdGhlICpsaWJyYXJ5IHNvdXJj ZSBjb2RlKiBhbmQgcmVjb21waWxlIHRvIGNvbnRpbnVlLg0KDQpjaGVja0hlYWRlciBhY2NlcHRz IGEgInppcCIgZmllbGQsIGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBqc29uY3J5cHRvIGNvZGUgaW1w bGVtZW50cyB0aGlzIGZpZWxkIChzYW1lIGZvciAia2RmIiwgInR5cCIgZXRjKS4NCg0KY2hlY2tI ZWFkZXIgYWNjZXB0cyBhbiAiZXBrIiBmaWVsZCB3aGVuICJhbGciIGlzICJSU0EtT0FFUCIgZXZl biB0aG91Z2ggaXQgY2Fubm90IHVuZGVyc3RhbmQgc3VjaCBhIGNvbWJpbmF0aW9uIGJlY2F1c2Ug aXQgaGFzbid0IGJlZW4gZGVmaW5lZC4NCg0KY2hlY2tIZWFkZXIgYWNjZXB0cyAia2RmIiBldmVu IGlmIGl0cyB2YWx1ZSBpcyBhbiBvYmplY3QgKGVnICJrZGYiOnsieHl6IjouLi59KSBpbnN0ZWFk IG9mIGhhdmluZyBhIHN0cmluZyB2YWx1ZS4gQWdhaW4sIHdobyBrbm93cyB3aGF0IHRoYXQgbWln aHQgbWVhbj8NCg0KWW91IGhhdmUgaW50cm9kdWNlZCBzb21lIG1vcmUgZmFpbHVyZSBtb2Rlcy4g VGhlcmUgYXJlIHN0aWxsIHBsZW50eSBvZiBKT1NFIG1lc3NhZ2UgdGhhdCB5b3VyIGNvZGUgd2ls bCBhY2NlcHQgZGVzcGl0ZSBub3QgdW5kZXJzdGFuZGluZy4gWW91ciBsaWJyYXJ5IHdhcyBtb3Jl IHVzZWZ1bCB3aXRob3V0IGNoZWNrSGVhZGVyKCkuDQoNCg0KUC5TLiBTbGlnaHRseSBiZXR0ZXIg Y29kZSBtaWdodCBiZToNCmlmICgha25vd25LZXlzU2V0LmNvbnRhaW5zQWxsKGp3ZUhlYWRlci5r ZXlzKCkpIHRocm93IFNvbWVFeGNlcHRpb24oLi4uKQ0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0K PiAgICAgICAgcHVibGljIHN0YXRpYyB2b2lkIGNoZWNrSGVhZGVyKEpTT05PYmplY3QgandlSGVh ZGVyKSB0aHJvd3MNCj4gRXhjZXB0aW9uIHsNCj4gICAgICAgICAgICAgICAgIEBTdXBwcmVzc1dh cm5pbmdzKCJyYXd0eXBlcyIpDQo+ICAgICAgICAgICAgICAgICBJdGVyYXRvciBpdGVyID0gandl SGVhZGVyLmtleXMoKTsNCj4gICAgICAgICAgICAgICAgIHdoaWxlIChpdGVyLmhhc05leHQoKSkg ew0KPiAgICAgICAgICAgICAgICAgICAgICAgICBTdHJpbmcga2V5ID0gKFN0cmluZykgaXRlci5u ZXh0KCk7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgiYWxnIi5lcXVhbHMoa2V5KSkg Y29udGludWU7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgiZW5jIi5lcXVhbHMoa2V5 KSkgY29udGludWU7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgiaW50Ii5lcXVhbHMo a2V5KSkgY29udGludWU7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgia2RmIi5lcXVh bHMoa2V5KSkgY29udGludWU7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgiaXYiLmVx dWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCJlcGsi LmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCJ6 aXAiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgaWYg KCJqa3UiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgICAgICAgICAg aWYgKCJqd2siLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgaWYgKCJ4NXUiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgaWYgKCJ4NXQiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgaWYgKCJ4NWMiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgaWYgKCJraWQiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgaWYgKCJ0eXAiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgaWYgKCJjdHkiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgaWYgKCJqa3UiLmVxdWFscyhrZXkpKSBjb250aW51ZTsNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCJqd2siLmVxdWFscyhrZXkpKSBjb250aW51ZTsN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgdGhyb3cgbmV3IEV4Y2VwdGlvbigidW5rbm93biBr ZXkgaW4gaGVhZGVyOiAiICsNCj4ga2V5KTsNCj4gICAgICAgICAgICAgICAgIH0NCj4gICAgICAg ICB9DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogam9zZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gTmVubmtlciwgQXhlbA0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDAyLCAyMDEyIDY6 NTYgQU0NCj4gVG86IEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb207IGpvc2VAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtqb3NlXSBpbXBsZW1lbnRpbmcgSk9TRSBpbiBKYXZhOiBqc29u Y3J5cHRvDQo+IA0KPiBJIHdhbnRlZCB0byB3YWl0IGEgbGl0dGxlIG1vcmUgYmVmb3JlIGltcGxl bWVudGluZyB0aGF0IGJlY2F1c2UgdGhlDQo+IGRpc2N1c3Npb24gaGVyZSBhYm91dCBpdCBzZWVt cyB0byBicmluZyB0b28gbWFueSBjaGFuZ2VzIHRvIHRoZSBjb2RlLg0KPiBUaGVyZSBhcmUgb3Ro ZXIgdGhpbmdzIHRvbyB0aGF0IG5lZWQgdG8gYmUgaW1wcm92ZWQuIEJ1dCBqc29uY3J5cHRvDQo+ IGltcGxlbWVudHMgYWxsIHByb3Bvc2VkIGFsZyBhbmQgZW5jIHZhbHVlcyBvdGhlciB0aGFuIG5v bmUgKHdoaWNoIEkNCj4gZmluZCBzdHJhbmdlKSBhbmQgZGlyICh3aGljaCBJIGhhZCBpbXBsZW1l bnRlZCBmaXJzdCBidXQgdGhlIGdyb3VwIGF0DQo+IHRoYXQgdGltZSBzZWVtZWQgdG8gdGhpbmsg dGhhdCB0aGlzIG1pZ2h0IG1ha2UgaXQgdG9vIGVhc3kgZm9yDQo+IGRldmVsb3BlcnMgdG8gdXNl IHRoZSBzYW1lIGNlayB0b28gb2Z0ZW4gKGFsd2F5cykpLg0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwMiwgMjAxMiAz OjI2IEFNDQo+IFRvOiBOZW5ua2VyLCBBeGVsOyBqb3NlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJF OiBpbXBsZW1lbnRpbmcgSk9TRSBpbiBKYXZhOiBqc29uY3J5cHRvDQo+IA0KPiBBeGVsLA0KPiAN Cj4gPiBJIG1vdmVkIG15IEpPU0UgaW1wbGVtZW50YXRpb24gb3V0IG9mIG15IG9wZW5pbmZvY2Fy ZCBwcm9qZWN0IGludG8gYQ0KPiA+IG5ldyByZXBvc2l0b3J5Og0KPiA+IGh0dHBzOi8vY29kZS5n b29nbGUuY29tL3AvanNvbmNyeXB0by8NCj4gDQo+IEl0IGlzIGdvb2QgdG8gc2VlIGFub3RoZXIg Sk9TRSBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IERvZXMganNvbmNyeXB0byBpbXBsZW1lbnQgdGhl ICJNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZyIgcnVsZT8NCj4gDQo+ICAgW0pXRS0wNSwgc2Vj dGlvbiA0XQ0KPiAgIEltcGxlbWVudGF0aW9ucyBNVVNUIHVuZGVyc3RhbmQgdGhlIGVudGlyZSBj b250ZW50cyBvZiB0aGUNCj4gICBoZWFkZXI7IG90aGVyd2lzZSwgdGhlIEpXRSBNVVNUIGJlIHJl amVjdGVkLg0KPiANCj4gICBbSldFLTA1LCBzZWN0aW9uIDZdDQo+ICAgNC4gVGhlIHJlc3VsdGlu ZyBKV0UgSGVhZGVyIE1VU1QgYmUgdmFsaWRhdGVkIHRvIG9ubHkgaW5jbHVkZQ0KPiAgICAgIHBh cmFtZXRlcnMgYW5kIHZhbHVlcyB3aG9zZSBzeW50YXggYW5kIHNlbWFudGljcyBhcmUgYm90aA0K PiAgICAgIHVuZGVyc3Rvb2QgYW5kIHN1cHBvcnRlZC4NCj4gDQo+IEpzb25jcnlwdG8gZG9lcyBu b3QgYXBwZWFyIHRvIGltcGxlbWVudCB0aGlzIHJ1bGUuIEl0IGFwcGVhcnMgdG8gdGFrZQ0KPiB0 aGUgb2J2aW91cyBhcHByb2FjaCBvZiBsb29raW5nIGluIHRoZSBoZWFkZXIgZm9yIHRoZSBmaWVs ZHMgaXQgbmVlZHMgLQ0KPiAtIGFuZCBpZ25vcmluZyBhbnl0aGluZyBlbHNlIHRoYXQgbWlnaHQg YmUgdGhlcmUuDQo+IA0KPiBbUmVnYXJkbGVzcyBvZiBhbnkgcG9zc2libGUgbWVyaXQgaW4gYSAi TVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmciDQo+IHJ1bGUsIHRoZSBmYWN0IHRoYXQgaXQgd2ls bCBvZnRlbiBub3QgYmUgaW1wbGVtZW50ZWQgc2VlbXMgbGlrZSBhDQo+IHJlYWxseSBnb29kIHJl YXNvbiB0byBkcm9wIHRoZSBydWxlIHNvIHRoZSBzcGVjIHJlZmxlY3RzIHJlYWxpdHkuXQ0KPiAN Cj4gLS0NCj4gSmFtZXMgTWFuZ2VyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+IGpvc2VAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo= From Axel.Nennker@telekom.de Thu Aug 2 08:57:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2EC11E8087 for ; Thu, 2 Aug 2012 08:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lda6XlIiEyHi for ; Thu, 2 Aug 2012 08:57:58 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEAD21F86F2 for ; Thu, 2 Aug 2012 08:57:57 -0700 (PDT) Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 02 Aug 2012 17:57:54 +0200 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE113598.emea1.cds.t-internal.com (10.125.65.117) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 2 Aug 2012 17:57:54 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113559.emea1.cds.t-internal.com ([2002:7cd:4165::7cd:4165]) with mapi; Thu, 2 Aug 2012 17:57:54 +0200 From: To: , Date: Thu, 2 Aug 2012 17:57:52 +0200 Thread-Topic: implementing JOSE in Java: jsoncrypto Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5gAJIbggAAf6HlAACRcucAAH036AAAWmUQA= Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FA1E40F0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA1E40F0@WSMSG3153V.srv.dir.telstra.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:57:59 -0000 That was the quick "solution" trying to resolve the security issues with un= supported header fields; not the "meaningful" check.=20 I am not sure whether the spec requires that implementations MUST reject he= aders that contain meaningless fields like in your epk example below.=20 BTW: jsoncrypto.org has an issue tracker.=20 I am not sure about the "usefulness" of my library with or without checkHea= der. It only tries to implement the "MUST" unknown-fields-rejection require= ment from the spec not more. Maybe I am reading the spec not sharp enough? Axel Ps: thanks for the suggestion using the Set of know headers. I thought abou= t that too but then decided against it because I feel that I should then im= plement "everything" in data instead of code... knownJwsHeaders, knownJweHe= aders, supportedAEADalgs, etc I suggest to discuss "beautiful code" privately?! E.g. this implementation = currently is not object oriented at all. There could be a class JweHeader t= hat has a constructor that parses the jweHeaderStr and throws if it is not = meaningful... Or a class RSAJwt that knows the header field that make sense= if alg =3D RSA1_5 ... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Thursday, August 02, 2012 3:54 PM To: Nennker, Axel; jose@ietf.org Subject: Re: [jose] implementing JOSE in Java: jsoncrypto > Done. > checkHeader function is called in all encrypt, decrypt, sign and=20 > verify functions now. That was pretty quick, but also petty awful. If an app using your library now receives a JWE with, say, a "creationTime"= field (suggested at the IETF meeting I think) it will fail unnecessarily. = The app needs to modify the *library source code* and recompile to continue= . checkHeader accepts a "zip" field, but I don't think the jsoncrypto code im= plements this field (same for "kdf", "typ" etc). checkHeader accepts an "epk" field when "alg" is "RSA-OAEP" even though it = cannot understand such a combination because it hasn't been defined. checkHeader accepts "kdf" even if its value is an object (eg "kdf":{"xyz":.= ..}) instead of having a string value. Again, who knows what that might mea= n? You have introduced some more failure modes. There are still plenty of JOSE= message that your code will accept despite not understanding. Your library= was more useful without checkHeader(). P.S. Slightly better code might be: if (!knownKeysSet.containsAll(jweHeader.keys()) throw SomeException(...) -- James Manger > public static void checkHeader(JSONObject jweHeader) throws=20 > Exception { > @SuppressWarnings("rawtypes") > Iterator iter =3D jweHeader.keys(); > while (iter.hasNext()) { > String key =3D (String) iter.next(); > if ("alg".equals(key)) continue; > if ("enc".equals(key)) continue; > if ("int".equals(key)) continue; > if ("kdf".equals(key)) continue; > if ("iv".equals(key)) continue; > if ("epk".equals(key)) continue; > if ("zip".equals(key)) continue; > if ("jku".equals(key)) continue; > if ("jwk".equals(key)) continue; > if ("x5u".equals(key)) continue; > if ("x5t".equals(key)) continue; > if ("x5c".equals(key)) continue; > if ("kid".equals(key)) continue; > if ("typ".equals(key)) continue; > if ("cty".equals(key)) continue; > if ("jku".equals(key)) continue; > if ("jwk".equals(key)) continue; > throw new Exception("unknown key in header: "=20 > + key); > } > } >=20 >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Nennker, Axel > Sent: Thursday, August 02, 2012 6:56 AM > To: James.H.Manger@team.telstra.com; jose@ietf.org > Subject: Re: [jose] implementing JOSE in Java: jsoncrypto >=20 > I wanted to wait a little more before implementing that because the=20 > discussion here about it seems to bring too many changes to the code. > There are other things too that need to be improved. But jsoncrypto=20 > implements all proposed alg and enc values other than none (which I=20 > find strange) and dir (which I had implemented first but the group at=20 > that time seemed to think that this might make it too easy for=20 > developers to use the same cek too often (always)). >=20 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Thursday, August 02, 2012 3:26 AM > To: Nennker, Axel; jose@ietf.org > Subject: RE: implementing JOSE in Java: jsoncrypto >=20 > Axel, >=20 > > I moved my JOSE implementation out of my openinfocard project into a=20 > > new repository: > > https://code.google.com/p/jsoncrypto/ >=20 > It is good to see another JOSE implementation. >=20 > Does jsoncrypto implement the "MUST understand everything" rule? >=20 > [JWE-05, section 4] > Implementations MUST understand the entire contents of the > header; otherwise, the JWE MUST be rejected. >=20 > [JWE-05, section 6] > 4. The resulting JWE Header MUST be validated to only include > parameters and values whose syntax and semantics are both > understood and supported. >=20 > Jsoncrypto does not appear to implement this rule. It appears to take=20 > the obvious approach of looking in the header for the fields it needs=20 > - > - and ignoring anything else that might be there. >=20 > [Regardless of any possible merit in a "MUST understand everything" > rule, the fact that it will often not be implemented seems like a=20 > really good reason to drop the rule so the spec reflects reality.] >=20 > -- > James Manger > _______________________________________________ > 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 From Anil.Saldhana@redhat.com Thu Aug 2 09:23:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1236411E80DF for ; Thu, 2 Aug 2012 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPXJs6yl5g3Z for ; Thu, 2 Aug 2012 09:23:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5011E808E for ; Thu, 2 Aug 2012 09:23:45 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q72GNjgN006051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Aug 2012 12:23:45 -0400 Received: from [10.3.237.244] (vpn-237-244.phx2.redhat.com [10.3.237.244]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q72GNiR7009674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 12:23:44 -0400 Message-ID: <501AA990.5070808@redhat.com> Date: Thu, 02 Aug 2012 11:23:44 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org References: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114FA1E40F0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Subject: Re: [jose] implementing JOSE in Java: jsoncrypto X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:23:47 -0000 Axel, thank you very much for an implementation of JOSE in Java. Rather than create an umpteen number of OSS projects, it is better to have one or two conforming implementations that everybody can re-use. In your implementation, rather than check on individual "alg","typ" etc against a key, it is better to just check against a set of allowed parameter set/array (as James mentioned). Regards, Anil On 08/02/2012 10:57 AM, Axel.Nennker@telekom.de wrote: > That was the quick "solution" trying to resolve the security issues with unsupported header fields; not the "meaningful" check. > I am not sure whether the spec requires that implementations MUST reject headers that contain meaningless fields like in your epk example below. > > BTW: jsoncrypto.org has an issue tracker. > > I am not sure about the "usefulness" of my library with or without checkHeader. It only tries to implement the "MUST" unknown-fields-rejection requirement from the spec not more. > Maybe I am reading the spec not sharp enough? > > Axel > > Ps: thanks for the suggestion using the Set of know headers. I thought about that too but then decided against it because I feel that I should then implement "everything" in data instead of code... knownJwsHeaders, knownJweHeaders, supportedAEADalgs, etc > I suggest to discuss "beautiful code" privately?! E.g. this implementation currently is not object oriented at all. There could be a class JweHeader that has a constructor that parses the jweHeaderStr and throws if it is not meaningful... Or a class RSAJwt that knows the header field that make sense if alg = RSA1_5 ... > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H > Sent: Thursday, August 02, 2012 3:54 PM > To: Nennker, Axel; jose@ietf.org > Subject: Re: [jose] implementing JOSE in Java: jsoncrypto > >> Done. >> checkHeader function is called in all encrypt, decrypt, sign and >> verify functions now. > That was pretty quick, but also petty awful. > If an app using your library now receives a JWE with, say, a "creationTime" field (suggested at the IETF meeting I think) it will fail unnecessarily. The app needs to modify the *library source code* and recompile to continue. > > checkHeader accepts a "zip" field, but I don't think the jsoncrypto code implements this field (same for "kdf", "typ" etc). > > checkHeader accepts an "epk" field when "alg" is "RSA-OAEP" even though it cannot understand such a combination because it hasn't been defined. > > checkHeader accepts "kdf" even if its value is an object (eg "kdf":{"xyz":...}) instead of having a string value. Again, who knows what that might mean? > > You have introduced some more failure modes. There are still plenty of JOSE message that your code will accept despite not understanding. Your library was more useful without checkHeader(). > > > P.S. Slightly better code might be: > if (!knownKeysSet.containsAll(jweHeader.keys()) throw SomeException(...) > > -- > James Manger > > >> public static void checkHeader(JSONObject jweHeader) throws >> Exception { >> @SuppressWarnings("rawtypes") >> Iterator iter = jweHeader.keys(); >> while (iter.hasNext()) { >> String key = (String) iter.next(); >> if ("alg".equals(key)) continue; >> if ("enc".equals(key)) continue; >> if ("int".equals(key)) continue; >> if ("kdf".equals(key)) continue; >> if ("iv".equals(key)) continue; >> if ("epk".equals(key)) continue; >> if ("zip".equals(key)) continue; >> if ("jku".equals(key)) continue; >> if ("jwk".equals(key)) continue; >> if ("x5u".equals(key)) continue; >> if ("x5t".equals(key)) continue; >> if ("x5c".equals(key)) continue; >> if ("kid".equals(key)) continue; >> if ("typ".equals(key)) continue; >> if ("cty".equals(key)) continue; >> if ("jku".equals(key)) continue; >> if ("jwk".equals(key)) continue; >> throw new Exception("unknown key in header: " >> + key); >> } >> } >> >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> Of Nennker, Axel >> Sent: Thursday, August 02, 2012 6:56 AM >> To: James.H.Manger@team.telstra.com; jose@ietf.org >> Subject: Re: [jose] implementing JOSE in Java: jsoncrypto >> >> I wanted to wait a little more before implementing that because the >> discussion here about it seems to bring too many changes to the code. >> There are other things too that need to be improved. But jsoncrypto >> implements all proposed alg and enc values other than none (which I >> find strange) and dir (which I had implemented first but the group at >> that time seemed to think that this might make it too easy for >> developers to use the same cek too often (always)). >> >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Thursday, August 02, 2012 3:26 AM >> To: Nennker, Axel; jose@ietf.org >> Subject: RE: implementing JOSE in Java: jsoncrypto >> >> Axel, >> >>> I moved my JOSE implementation out of my openinfocard project into a >>> new repository: >>> https://code.google.com/p/jsoncrypto/ >> It is good to see another JOSE implementation. >> >> Does jsoncrypto implement the "MUST understand everything" rule? >> >> [JWE-05, section 4] >> Implementations MUST understand the entire contents of the >> header; otherwise, the JWE MUST be rejected. >> >> [JWE-05, section 6] >> 4. The resulting JWE Header MUST be validated to only include >> parameters and values whose syntax and semantics are both >> understood and supported. >> >> Jsoncrypto does not appear to implement this rule. It appears to take >> the obvious approach of looking in the header for the fields it needs >> - >> - and ignoring anything else that might be there. >> >> [Regardless of any possible merit in a "MUST understand everything" >> rule, the fact that it will often not be implemented seems like a >> really good reason to drop the rule so the spec reflects reality.] >> >> -- >> James Manger From Axel.Nennker@telekom.de Sat Aug 4 23:54:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213BC21F86D6 for ; Sat, 4 Aug 2012 23:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWrNrFjmG3xi for ; Sat, 4 Aug 2012 23:54:38 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF6F21F8610 for ; Sat, 4 Aug 2012 23:54:38 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 05 Aug 2012 08:54:36 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Sun, 5 Aug 2012 08:54:36 +0200 From: To: Date: Sun, 5 Aug 2012 08:54:31 +0200 Thread-Topic: order of step for encryption. JWE section 5 Thread-Index: Ac1y1wQPutAF2XyLQPOP3bTnOMCRMw== Message-ID: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] order of step for encryption. JWE section 5 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 06:54:39 -0000 Hi, I have two issues with section 5 of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html 1) I would prefer it if the order of the steps 1 and 2 were reversed in sectio= n 5. Currently we have: Message Encryption The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. 1. When key agreement is employed, use the key agreement algorithm to compute the value of the agreed upon key. When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key. When key agreement with key wrapping is employed, the agreed upon key will be used to wrap the CMK. 2. When key wrapping, key encryption, or key agreement with key wrapping are employed, generate a random Content Master Key (CMK). See RFC 4086 [RFC4086] for considerations on generating random values. The CMK MUST have a length equal to that of the larger of the required encryption and integrity keys. Step 1 refers to the CMK that might be randomly created in step 2. I think it is better to have the CMK generation . 2) I find the text of the current step 1 confusing. 2a) The first sentence is nearly a tautology 2b) All sentences begin with When but the sentences two and three are alternative choices and the first is not. 2c) Does "When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key." make sense? What is the key agreement good for then? Should this read: "When key agreement without key wrapping is employed, let the agreed upon key be the CMK" ? There SHOULD be some randomness e.g. through the epk. Could we structure these steps more? I) determine the CEK, generate random values like IVs and epks II) build the jweHeaderSegment (e.g. put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) build the jweCryptoSegment V) build the jweIntegritySegment VI) base64url encode and concatenate the segments From Michael.Jones@microsoft.com Sun Aug 5 05:20:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DFB21F84C2 for ; Sun, 5 Aug 2012 05:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD5pJS1lTvAu for ; Sun, 5 Aug 2012 05:20:13 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 7557E21F84A7 for ; Sun, 5 Aug 2012 05:20:12 -0700 (PDT) Received: from mail59-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Aug 2012 12:20:11 +0000 Received: from mail59-db3 (localhost [127.0.0.1]) by mail59-db3-R.bigfish.com (Postfix) with ESMTP id 4C0341C01FF; Sun, 5 Aug 2012 12:20:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M111aI1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail59-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail59-db3 (localhost.localdomain [127.0.0.1]) by mail59-db3 (MessageSwitch) id 1344169210192911_10134; Sun, 5 Aug 2012 12:20:10 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.236]) by mail59-db3.bigfish.com (Postfix) with ESMTP id 23D223000C0; Sun, 5 Aug 2012 12:20:10 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 5 Aug 2012 12:20:09 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Sun, 5 Aug 2012 12:20:07 +0000 From: Mike Jones To: "Axel.Nennker@telekom.de" , "jose@ietf.org" Thread-Topic: order of step for encryption. JWE section 5 Thread-Index: Ac1y1wQPutAF2XyLQPOP3bTnOMCRMwALGibg Date: Sun, 5 Aug 2012 12:20:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] order of step for encryption. JWE section 5 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 12:20:14 -0000 Thanks for the careful read, Axel. I'll work to make the write-up of the s= teps clearer, using your input. In particular, I'll look for ways to bette= r structure the steps. (Unfortunately, the xml2rfc tool doesn't do a parti= cularly good job of structuring lists with sub-lists.) Answering your point 2c, a random CMK is not used in this case. Instead, t= he agreed-upon key is used directly to perform the encryption. I also plan= to add a key agreement example in the next draft. I expect that this will= help make this case clearer. Thanks again, -- Mike =20 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Saturday, August 04, 2012 11:55 PM To: jose@ietf.org Subject: [jose] order of step for encryption. JWE section 5 Hi, I have two issues with section 5 of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html 1) I would prefer it if the order of the steps 1 and 2 were reversed in sectio= n 5. Currently we have: Message Encryption The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. 1. When key agreement is employed, use the key agreement algorithm to compute the value of the agreed upon key. When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key. When key agreement with key wrapping is employed, the agreed upon key will be used to wrap the CMK. 2. When key wrapping, key encryption, or key agreement with key wrapping are employed, generate a random Content Master Key (CMK). See RFC 4086 [RFC4086] for considerations on generating random values. The CMK MUST have a length equal to that of the larger of the required encryption and integrity keys. Step 1 refers to the CMK that might be randomly created in step 2. I think = it is better to have the CMK generation . 2) I find the text of the current step 1 confusing. 2a) The first sentence is nearly a tautology 2b) All sentences begin with When but the sentences two and three are alte= rnative choices and the first is not. 2c) Does "When key agreement without key wrapping is employed, let the Con= tent Master Key (CMK) be the agreed upon key." make sense? What is the key agreement good for then? Should this read: "When key agreement without key wrapping is employ= ed, let the agreed upon key be the CMK" ? There SHOULD be some randomness e= .g. through the epk. Could we structure these steps more? I) determine the CEK, generate random = values like IVs and epks II) build the jweHeaderSegment (e.g. put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) buil= d the jweCryptoSegment V) build the jweIntegritySegment VI) base64url encod= e and concatenate the segments ____________________________________________= ___ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Sun Aug 5 09:00:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88F21F845F for ; Sun, 5 Aug 2012 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wndk5GcQcUTD for ; Sun, 5 Aug 2012 09:00:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1B72321F8427 for ; Sun, 5 Aug 2012 09:00:53 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 05 Aug 2012 18:00:52 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Sun, 5 Aug 2012 18:00:51 +0200 From: To: , Date: Sun, 5 Aug 2012 18:00:49 +0200 Thread-Topic: order of step for encryption. JWE section 5 Thread-Index: Ac1y1wQPutAF2XyLQPOP3bTnOMCRMwALGibgAAfS9xA= Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] order of step for encryption. JWE section 5 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 16:00:55 -0000 Maybe section 5 could have subsections like 5.1 Preparing Algorithm Parameters determine the CEK, generate random values like IVs and epks 5.2 Building the jweHeaderSegment e.g put the IV randomly generated in 5.1 there 5.3 Building the jweKeySegment=20 e.g. key wrapping 5.4 Building the jweCryptoSegment=20 5.5 Building the jweIntegritySegment 5.6 Putting it all together base64url encode and concatenate the segments The subsections then could have list of steps or alternative lists of steps= depending on header values Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Sunday, August 05, 2012 2:20 PM To: Nennker, Axel; jose@ietf.org Subject: Re: [jose] order of step for encryption. JWE section 5 Thanks for the careful read, Axel. I'll work to make the write-up of the s= teps clearer, using your input. In particular, I'll look for ways to bette= r structure the steps. (Unfortunately, the xml2rfc tool doesn't do a parti= cularly good job of structuring lists with sub-lists.) Answering your point 2c, a random CMK is not used in this case. Instead, t= he agreed-upon key is used directly to perform the encryption. I also plan= to add a key agreement example in the next draft. I expect that this will= help make this case clearer. Thanks again, -- Mike =20 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Saturday, August 04, 2012 11:55 PM To: jose@ietf.org Subject: [jose] order of step for encryption. JWE section 5 Hi, I have two issues with section 5 of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html 1) I would prefer it if the order of the steps 1 and 2 were reversed in sectio= n 5. Currently we have: Message Encryption The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. 1. When key agreement is employed, use the key agreement algorithm to compute the value of the agreed upon key. When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key. When key agreement with key wrapping is employed, the agreed upon key will be used to wrap the CMK. 2. When key wrapping, key encryption, or key agreement with key wrapping are employed, generate a random Content Master Key (CMK). See RFC 4086 [RFC4086] for considerations on generating random values. The CMK MUST have a length equal to that of the larger of the required encryption and integrity keys. Step 1 refers to the CMK that might be randomly created in step 2. I think = it is better to have the CMK generation . 2) I find the text of the current step 1 confusing. 2a) The first sentence is nearly a tautology 2b) All sentences begin with When but the sentences two and three are alte= rnative choices and the first is not. 2c) Does "When key agreement without key wrapping is employed, let the Con= tent Master Key (CMK) be the agreed upon key." make sense? What is the key agreement good for then? Should this read: "When key agreement without key wrapping is employ= ed, let the agreed upon key be the CMK" ? There SHOULD be some randomness e= .g. through the epk. Could we structure these steps more? I) determine the CEK, generate random = values like IVs and epks II) build the jweHeaderSegment (e.g. put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) buil= d the jweCryptoSegment V) build the jweIntegritySegment VI) base64url encod= e and concatenate the segments ____________________________________________= ___ 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 From ietf@augustcellars.com Tue Aug 7 12:02:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4D021F87AD for ; Tue, 7 Aug 2012 12:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co0kwTa-zg1x for ; Tue, 7 Aug 2012 12:02:09 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 622D221F8718 for ; Tue, 7 Aug 2012 12:02:03 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A50A82CA02; Tue, 7 Aug 2012 12:02:03 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Tue, 7 Aug 2012 12:00:36 -0700 Message-ID: <015001cd74ce$ee7a7460$cb6f5d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFW1jkqEaitbq4SUyx/cc/gK2wxEQDGdL+pmDW9XXA= Content-Language: en-us Subject: Re: [jose] order of step for encryption. JWE section 5 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 19:02:10 -0000 Mike, What is you issue of dealing with lists inside of lists for xml2rfc - is it just a question of how things are formatted? If so then this is an issue that can be left to the RFC Editor. Such formatting should be improved in general over the next few months as the new version of xml2rfc processing starts to get fully tested and rolled out. If the problem is something else, I would be interested in hearing what it is. > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Sunday, August 05, 2012 5:20 AM > To: Axel.Nennker@telekom.de; jose@ietf.org > Subject: Re: [jose] order of step for encryption. JWE section 5 > > Thanks for the careful read, Axel. I'll work to make the write-up of the steps > clearer, using your input. In particular, I'll look for ways to better structure > the steps. (Unfortunately, the xml2rfc tool doesn't do a particularly good job > of structuring lists with sub-lists.) > > Answering your point 2c, a random CMK is not used in this case. Instead, the > agreed-upon key is used directly to perform the encryption. I also plan to > add a key agreement example in the next draft. I expect that this will help > make this case clearer. > > Thanks again, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Axel.Nennker@telekom.de > Sent: Saturday, August 04, 2012 11:55 PM > To: jose@ietf.org > Subject: [jose] order of step for encryption. JWE section 5 > > Hi, > > I have two issues with section 5 of > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html > > 1) > I would prefer it if the order of the steps 1 and 2 were reversed in section 5. > > Currently we have: > Message Encryption > > > The message encryption process is as follows. The order of the steps > is not significant in cases where there are no dependencies between > the inputs and outputs of the steps. > > 1. When key agreement is employed, use the key agreement algorithm > to compute the value of the agreed upon key. When key agreement > without key wrapping is employed, let the Content Master Key > (CMK) be the agreed upon key. When key agreement with key > wrapping is employed, the agreed upon key will be used to wrap > the CMK. > > 2. When key wrapping, key encryption, or key agreement with key > wrapping are employed, generate a random Content Master Key > (CMK). See RFC 4086 [RFC4086] for considerations on generating > random values. The CMK MUST have a length equal to that of the > larger of the required encryption and integrity keys. > > Step 1 refers to the CMK that might be randomly created in step 2. I think it is > better to have the CMK generation . > > 2) I find the text of the current step 1 confusing. > 2a) The first sentence is nearly a tautology > 2b) All sentences begin with When but the sentences two and three are > alternative choices and the first is not. > 2c) Does "When key agreement without key wrapping is employed, let the > Content Master Key > (CMK) be the agreed upon key." make sense? > What is the key agreement good for then? > Should this read: "When key agreement without key wrapping is > employed, let the agreed upon key be the CMK" ? There SHOULD be some > randomness e.g. through the epk. > > Could we structure these steps more? I) determine the CEK, generate > random values like IVs and epks II) build the jweHeaderSegment (e.g. > put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) build > the jweCryptoSegment V) build the jweIntegritySegment VI) base64url > encode and concatenate the segments > _______________________________________________ > 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 From ietf@augustcellars.com Tue Aug 7 12:04:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DAA21F87CB for ; Tue, 7 Aug 2012 12:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oR07ObsSAfx for ; Tue, 7 Aug 2012 12:04:13 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id F305621F855E for ; Tue, 7 Aug 2012 12:04:12 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id BAF9238EA7; Tue, 7 Aug 2012 12:04:12 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 7 Aug 2012 12:02:46 -0700 Message-ID: <015101cd74cf$3b6ddb40$b24991c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOEqYX4FEpAj/QYUBhxmva5HYVMpZNeJ0w Content-Language: en-us Subject: Re: [jose] AESWrap vs ECB key wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 19:04:14 -0000 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Thursday, August 02, 2012 12:17 AM > To: jose@ietf.org > Subject: [jose] AESWrap vs ECB key wrap > > I noticed an "ECB key wrap" option was discussed at the IETF meeting, as an > alternative to AESWrap [RFC 3394]. > > I hadn't looked closely at AESWrap before. Its important features seem to > be: > 1. Only defined for content keys that are a multiple of 64-bits 2. Adds an > overhead of 64 bits (= 8 bytes = 12 B64 chars) 3. Offers a 64-bit integrity check > (from the overhead) 4. Performs 12 AES operations for each 64-bits of the > content key Do you believe that there is an issue with saying that key sizes are going to be a multiple of 64 bits? If so please speak up now and we can change this > > I assume an ECB key wrap, in contrast, would avoid the 64-bit overhead by > dropping the integrity check and only use 1/24th of the AES operations. > Would it also use, say, ciphertext stealing so there is no size overhead for any > content key size? There however is an issue where you cannot encrypt more than 128-bits of key material. This means that it would not be usable for many algorithms that are in the current specification. > > If a 12 byte overhead (when base64url-encoded) is too small to worry about > (and an extra, say, 46 AES operations is immaterial), then JOSE should keep > AESWrap as the only choice. It still need to define how to use AESWrap for > content keys that are not a multiple of 64-bits. Perhaps one byte of the > integrity check is changed to indicate the content key length? > > If size is going to be absolutely crucial for some use cases, then an ECB key > wrap could help. Such a size-constrained situation would probably need > other changes as well, such as the choice of a shorted IV and integrity tag for > AES-GCM (than the 128-bits and 96-bits picked in JWA). > > -- > James Manger > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Wed Aug 8 12:10:52 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B129B21F8589 for ; Wed, 8 Aug 2012 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=1.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQEOwb30v34e for ; Wed, 8 Aug 2012 12:10:52 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id E663221F8548 for ; Wed, 8 Aug 2012 12:10:51 -0700 (PDT) Received: from mail173-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 19:10:51 +0000 Received: from mail173-tx2 (localhost [127.0.0.1]) by mail173-tx2-R.bigfish.com (Postfix) with ESMTP id 4887B602A5 for ; Wed, 8 Aug 2012 19:10:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zz9371I542M1432Izz1202h1082kzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail173-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail173-tx2 (localhost.localdomain [127.0.0.1]) by mail173-tx2 (MessageSwitch) id 1344453050154278_29269; Wed, 8 Aug 2012 19:10:50 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.237]) by mail173-tx2.bigfish.com (Postfix) with ESMTP id 190033E00CA for ; Wed, 8 Aug 2012 19:10:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 19:10:49 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 8 Aug 2012 19:10:48 +0000 Received: from mail107-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 19:10:46 +0000 Received: from mail107-db3 (localhost [127.0.0.1]) by mail107-db3-R.bigfish.com (Postfix) with ESMTP id 3AFA2E0246 for ; Wed, 8 Aug 2012 19:10:46 +0000 (UTC) Received: from mail107-db3 (localhost.localdomain [127.0.0.1]) by mail107-db3 (MessageSwitch) id 1344453044374434_16876; Wed, 8 Aug 2012 19:10:44 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.243]) by mail107-db3.bigfish.com (Postfix) with ESMTP id 57A2E400B6; Wed, 8 Aug 2012 19:10:44 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 19:10:43 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT003.namprd03.prod.outlook.com ([10.255.97.38]) with mapi id 14.16.0175.005; Wed, 8 Aug 2012 19:10:43 +0000 From: Anthony Nadalin To: Jim Schaad , "'Manger, James H'" , "jose@ietf.org" Thread-Topic: [jose] AESWrap vs ECB key wrap Thread-Index: Ac1wfrzy/T+dm17hTSCmvrFUCKSwfgEUH4EAADKM32A= Date: Wed, 8 Aug 2012 19:10:42 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> <015101cd74cf$3b6ddb40$b24991c0$@augustcellars.com> In-Reply-To: <015101cd74cf$3b6ddb40$b24991c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [jose] AESWrap vs ECB key wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 19:10:52 -0000 > Do you believe that there is an issue with saying that key sizes are goin= g to be a multiple of 64 bits? If so please speak up now and we can change= this No I don't believe that all keys would fit into this category =20 -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Tuesday, August 07, 2012 12:03 PM To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] AESWrap vs ECB key wrap > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Manger, James H > Sent: Thursday, August 02, 2012 12:17 AM > To: jose@ietf.org > Subject: [jose] AESWrap vs ECB key wrap >=20 > I noticed an "ECB key wrap" option was discussed at the IETF meeting,=20 > as an > alternative to AESWrap [RFC 3394]. >=20 > I hadn't looked closely at AESWrap before. Its important features seem=20 > to > be: > 1. Only defined for content keys that are a multiple of 64-bits 2.=20 > Adds an overhead of 64 bits (=3D 8 bytes =3D 12 B64 chars) 3. Offers a=20 > 64-bit integrity check > (from the overhead) 4. Performs 12 AES operations for each 64-bits of=20 > the content key Do you believe that there is an issue with saying that key sizes are going = to be a multiple of 64 bits? If so please speak up now and we can change t= his >=20 > I assume an ECB key wrap, in contrast, would avoid the 64-bit overhead=20 > by dropping the integrity check and only use 1/24th of the AES operations= . > Would it also use, say, ciphertext stealing so there is no size=20 > overhead for any > content key size? There however is an issue where you cannot encrypt more than 128-bits of ke= y material. This means that it would not be usable for many algorithms tha= t are in the current specification. >=20 > If a 12 byte overhead (when base64url-encoded) is too small to worry=20 > about (and an extra, say, 46 AES operations is immaterial), then JOSE=20 > should keep > AESWrap as the only choice. It still need to define how to use AESWrap=20 > for content keys that are not a multiple of 64-bits. Perhaps one byte=20 > of the integrity check is changed to indicate the content key length? >=20 > If size is going to be absolutely crucial for some use cases, then an=20 > ECB key > wrap could help. Such a size-constrained situation would probably need=20 > other changes as well, such as the choice of a shorted IV and=20 > integrity tag for > AES-GCM (than the 128-bits and 96-bits picked in JWA). >=20 > -- > James Manger >=20 > _______________________________________________ > 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 From James.H.Manger@team.telstra.com Wed Aug 8 19:01:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBF321F85E7 for ; Wed, 8 Aug 2012 19:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfJR5PNhkm6e for ; Wed, 8 Aug 2012 19:01:38 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2921F85E1 for ; Wed, 8 Aug 2012 19:01:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,736,1336312800"; d="scan'208";a="84448501" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 09 Aug 2012 12:01:37 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6797"; a="75477996" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdni.tcif.telstra.com.au with ESMTP; 09 Aug 2012 12:01:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 9 Aug 2012 12:01:36 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Thu, 9 Aug 2012 12:01:35 +1000 Thread-Topic: [jose] AESWrap vs ECB key wrap Thread-Index: AQJOEqYX4FEpAj/QYUBhxmva5HYVMpZNeJ0wgAHdPBA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA5C35F3@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> <015101cd74cf$3b6ddb40$b24991c0$@augustcellars.com> In-Reply-To: <015101cd74cf$3b6ddb40$b24991c0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] AESWrap vs ECB key wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:01:39 -0000 PiA+IEkgbm90aWNlZCBhbiAiRUNCIGtleSB3cmFwIiBvcHRpb24gd2FzIGRpc2N1c3NlZCBhdCB0 aGUgSUVURiBtZWV0aW5nLA0KPiA+IGFzIGFuIGFsdGVybmF0aXZlIHRvIEFFU1dyYXAgW1JGQyAz Mzk0XS4NCj4gPg0KPiA+IEkgaGFkbid0IGxvb2tlZCBjbG9zZWx5IGF0IEFFU1dyYXAgYmVmb3Jl LiBJdHMgaW1wb3J0YW50IGZlYXR1cmVzDQo+ID4gc2VlbSB0byBiZToNCj4gPiAxLiBPbmx5IGRl ZmluZWQgZm9yIGNvbnRlbnQga2V5cyB0aGF0IGFyZSBhIG11bHRpcGxlIG9mIDY0LWJpdHMNCj4g PiAyLiBBZGRzIGFuIG92ZXJoZWFkIG9mIDY0IGJpdHMgKD0gOCBieXRlcyA9IDEyIEI2NCBjaGFy cykNCj4gPiAzLiBPZmZlcnMgYSA2NC1iaXQgaW50ZWdyaXR5IGNoZWNrIChmcm9tIHRoZSBvdmVy aGVhZCkNCj4gPiA0LiBQZXJmb3JtcyAxMiBBRVMgb3BlcmF0aW9ucyBmb3IgZWFjaCA2NC1iaXRz IG9mIHRoZSBjb250ZW50IGtleQ0KDQo+IERvIHlvdSBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgYW4g aXNzdWUgd2l0aCBzYXlpbmcgdGhhdCBrZXkgc2l6ZXMgYXJlDQo+IGdvaW5nIHRvIGJlIGEgbXVs dGlwbGUgb2YgNjQgYml0cz8gIElmIHNvIHBsZWFzZSBzcGVhayB1cCBub3cgYW5kIHdlIGNhbg0K PiBjaGFuZ2UgdGhpcw0KDQpIb3BlZnVsbHkgSk9TRSBpcyBhYm91dCB0byB1c2UgZHJhZnQtbWNn cmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIuIFRoYXQgZHJhZnQgaW5jbHVkZXMgQUVBRF9BRVNf MTI4X0NCQ19ITUFDX1NIQTEgdGhhdCB1c2VzIGEgMjg4LWJpdCBrZXkgKDEyOCsxNjApLiBPZiBj b3Vyc2UsIEpPU0UgbWF5IG9ubHkgcGljayB0aGUgU0hBMiB2YXJpYW50cyB3aG9zZSBrZXkgbGVu Z3RocyBhcmUgbXVsdGlwbGVzIG9mIDY0Lg0KDQpFdmVuIHRoZSBTSEEyIGZhbWlseSBoYXMgYSBT SEEtMjI0IHZhcmlhbnQgdGhhdCwgaWYgdXNlZCBpbiBzYXkgSE1BQyBtb2RlLCBpcyBsaWtlbHkg dG8gdXNlIGEga2V5IGxlbmd0aCB0aGF0IGlzbid0IGEgbXVsdGlwbGUgb2YgNjQuDQoNCg0KPiA+ IEkgYXNzdW1lIGFuIEVDQiBrZXkgd3JhcCwgaW4gY29udHJhc3QsIHdvdWxkIGF2b2lkIHRoZSA2 NC1iaXQNCj4gPiBvdmVyaGVhZCBieSBkcm9wcGluZyB0aGUgaW50ZWdyaXR5IGNoZWNrIGFuZCBv bmx5IHVzZSAxLzI0dGgNCj4gPiBvZiB0aGUgQUVTIG9wZXJhdGlvbnMuDQo+ID4gV291bGQgaXQg YWxzbyB1c2UsIHNheSwgY2lwaGVydGV4dCBzdGVhbGluZyBzbyB0aGVyZSBpcyBubyBzaXplDQo+ ID4gb3ZlcmhlYWQgZm9yIGFueSBjb250ZW50IGtleSBzaXplPw0KDQo+IFRoZXJlIGhvd2V2ZXIg aXMgYW4gaXNzdWUgd2hlcmUgeW91IGNhbm5vdCBlbmNyeXB0IG1vcmUgdGhhbiAxMjgtYml0cw0K PiBvZiBrZXkgbWF0ZXJpYWwuICBUaGlzIG1lYW5zIHRoYXQgaXQgd291bGQgbm90IGJlIHVzYWJs ZSBmb3IgbWFueSBhbGdvcml0aG1zDQo+IHRoYXQgYXJlIGluIHRoZSBjdXJyZW50IHNwZWNpZmlj YXRpb24uDQoNCklzIHRoZSA2NC1iaXQgaW50ZWdyaXR5IGNoZWNrIGluIEFFU1dyYXAgY3J1Y2lh bCBmb3IgaXRzIGFiaWxpdHkgdG8gd3JhcCBtb3JlIHRoYW4gYSBibG9jayBzaXplIG9mIGtleSBt YXRlcmlhbD8NCg0KTm8sIHdhcyBteSBndWVzcy4gSW4gd2hpY2ggY2FzZSBpdCBzaG91bGQgYmUg dGhlb3JldGljYWxseSBwb3NzaWJsZSB0byBzYXZlIHRoYXQgbGl0dGxlIGJpdCBvZiBzcGFjZSB3 aGVuIHdyYXBwaW5nIGEga2V5IHVzaW5nIHNvbWUgRUNCL0NCQy9jaXBoZXJ0ZXh0LXN0ZWFsaW5n IG1vZGUgKHRob3VnaCBpdCBtaWdodCBvbmx5IGJlIHNhZmUgaWYgZXZlcnkgcG9zc2libGUgcGxh aW50ZXh0IG9mIHRoZSBnaXZlbiBsZW5ndGggaXMgYSB2YWxpZCBrZXksIGFuZCBhbiBBRUFELWxh eWVyIHByb3ZpZGVzIGludGVncml0eSBvdmVyIHRoZSB3cmFwcGVkIGtleSkuDQoNCi0tDQpKYW1l cyBNYW5nZXINCg== From ietf@augustcellars.com Thu Aug 9 13:08:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586AA21F8733 for ; Thu, 9 Aug 2012 13:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu7p4BdxUR4O for ; Thu, 9 Aug 2012 13:08:56 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 971C021F869D for ; Thu, 9 Aug 2012 13:08:56 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 49ED638F24; Thu, 9 Aug 2012 13:08:56 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.com> <015101cd74cf$3b6ddb40$b24991c0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114FA5C35F3@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA5C35F3@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 9 Aug 2012 13:07:25 -0700 Message-ID: <007801cd766a$9c3ee170$d4bca450$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOEqYX4FEpAj/QYUBhxmva5HYVMgG8yi/HAvXCDMqWKgkqcA== Content-Language: en-us Subject: Re: [jose] AESWrap vs ECB key wrap X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:08:57 -0000 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Wednesday, August 08, 2012 7:02 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] AESWrap vs ECB key wrap >=20 > > > I noticed an "ECB key wrap" option was discussed at the IETF > > > meeting, as an alternative to AESWrap [RFC 3394]. > > > > > > I hadn't looked closely at AESWrap before. Its important features > > > seem to be: > > > 1. Only defined for content keys that are a multiple of 64-bits 2. > > > Adds an overhead of 64 bits (=3D 8 bytes =3D 12 B64 chars) 3. = Offers a > > > 64-bit integrity check (from the overhead) 4. Performs 12 AES > > > operations for each 64-bits of the content key >=20 > > Do you believe that there is an issue with saying that key sizes are > > going to be a multiple of 64 bits? If so please speak up now and we > > can change this >=20 > Hopefully JOSE is about to use draft-mcgrew-aead-aes-cbc-hmac-sha2. = That > draft includes AEAD_AES_128_CBC_HMAC_SHA1 that uses a 288-bit key > (128+160). Of course, JOSE may only pick the SHA2 variants whose key > lengths are multiples of 64. >=20 > Even the SHA2 family has a SHA-224 variant that, if used in say HMAC = mode, > is likely to use a key length that isn't a multiple of 64. >=20 >=20 > > > I assume an ECB key wrap, in contrast, would avoid the 64-bit > > > overhead by dropping the integrity check and only use 1/24th of = the > > > AES operations. > > > Would it also use, say, ciphertext stealing so there is no size > > > overhead for any content key size? >=20 > > There however is an issue where you cannot encrypt more than = 128-bits > > of key material. This means that it would not be usable for many > > algorithms that are in the current specification. >=20 > Is the 64-bit integrity check in AESWrap crucial for its ability to = wrap more > than a block size of key material? >=20 > No, was my guess. In which case it should be theoretically possible to = save > that little bit of space when wrapping a key using some = ECB/CBC/ciphertext- > stealing mode (though it might only be safe if every possible = plaintext of the > given length is a valid key, and an AEAD-layer provides integrity over = the > wrapped key). The design of AESWrap with a 64-bit integrity value and 64-bit multiple = key sizes was a byproduct of the inputs we had at the time. That is why = there is a newer version that allows for both having keys which are of a = different size. The role of the integrity value has nothing to do with the size, it has = everything to do with being able to both deeply protect the key and to = know that one is using the wrong key (or it has been tampered with) = before getting so far in the process that one needs to rewind and start = from scratch to process the input. You already have integrity built = into the normal RSA key transport methods. There is no such ability to = know that you have the correct pairs for the key agreement world or for = the symmetric key world. The additional of the integrity check here is = therefore good in determining that your problem is with the key pairs = and not with the content. Given that SKI can be a user defined value = for the X.509 certificate world, and all users can start with the number = 1 and increment. You can have a large number of SKI values that are the = same if you are doing static static. The problem can even be true for = identifying your own key pairs at times. I will just skip dealing with = how symmetric keys are defined since there is no standard method across = all protocols for doing so. Indeed in the jose case the key is going to = be implicitly defined in most cases.=20 There are timing attacks that can be made either with or without the = integrity value so there is no real advantage from that basis. Jim >=20 > -- > James Manger From ietf@augustcellars.com Sun Aug 12 11:57:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70E521F8630 for ; Sun, 12 Aug 2012 11:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idqkCYRVael5 for ; Sun, 12 Aug 2012 11:57:27 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id EC4AE21F861E for ; Sun, 12 Aug 2012 11:57:26 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 87DB238E6A; Sun, 12 Aug 2012 11:57:26 -0700 (PDT) From: "Jim Schaad" To: "'Harry Halpin'" References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> In-Reply-To: <5027C586.8080902@w3.org> Date: Sun, 12 Aug 2012 11:56:02 -0700 Message-ID: <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQLFlfTqqE/AKW0D4NQ2kQBPiDZx7QIHVRRolVYO0dA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 18:57:27 -0000 > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Michael Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some > access to raw key material, and the issue of whether or not to use JWK or > ASN.1 as the default format came up. Two issues have come out that we'd > like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to > support a JOSE-format for private keys? If so, when? Or 'maybe'? The working group policy is that there will be no private key format defined for JWK. This issue has been explicitly discussed by the working group and there are no plans to change that going forward. > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like for > backwards compatibility having some level of ASN.1 support would be useful > and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default > format in the low-level API, and having JWK as a format that can be built on > top of that in a possible high-level API. Would that be OK? It would probably be preferable to be able to import/export private key material as ASN.1. But to allow for the import/export of public key material in either the ASN.1 or JOSE format. This would simplify the implementation efforts for JOSE developers. I don't believe that it would be good to have systems that use JOSE to need to download script that did the ASN.1 to JOSE conversions. If you supported the ASN.1 blob at the SubjectPublicKeyInfo structure level, then an independent function could be placed in systems to do the conversion between the two formats. If you make it a high-level API, I would be worried about the support level provided by browsers. > > 3) How stable do you believe the JOSE formats are right now? Do you think > they are stable enough now we can reference them in our API draft at end of > August? If not, when? The W3C would like to and plan to use these formats > where possible. There are currently no open issues for discussion on the formats for asymmetric key formats; however there are some questions about the set of algorithms and key sizes for symmetric keys. While I have no reason to believe that there will be a change in the key formats, I cannot promise that there will not be one. Jim Schaad Jose WG Chair > > Feel free to forward this by JOSE WG for discussion. We'd like an answer > before we send our document to FPWD at end of August. > > cheers, > harry From hannes.tschofenig@gmx.net Mon Aug 13 09:30:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116F821F84F5 for ; Mon, 13 Aug 2012 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvw1KpfP5Obv for ; Mon, 13 Aug 2012 09:30:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AFF2121F84FC for ; Mon, 13 Aug 2012 09:30:03 -0700 (PDT) Received: (qmail invoked by alias); 13 Aug 2012 16:30:01 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 13 Aug 2012 18:30:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/9hR4cvIv9UYSt8O7mylr6g7j27DE6ku43fkFBDo lek7VbfRyms/ee Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> Date: Mon, 13 Aug 2012 19:30:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , 'Harry Halpin' , jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:30:05 -0000 On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote: >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems = like > for >> backwards compatibility having some level of ASN.1 support would be = useful >> and we *need* a format that allows key material (both private and >> public) to be exported. Folks seem to leaning towards ASN.1 as a = default >> format in the low-level API, and having JWK as a format that can be = built > on >> top of that in a possible high-level API. Would that be OK? This is really interesting! The entire work on JSON signing and encryption was started since the Web = and browser guys told us that there no way they would ever want to use = ASN.1. Completely impossible - not compatible with the way how Web = applications are developed these days, and so on.=20 Now, they ask for ASN.1 support.=20 From ietf@augustcellars.com Mon Aug 13 12:48:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0602D21F8602 for ; Mon, 13 Aug 2012 12:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duG2hAQO+SsS for ; Mon, 13 Aug 2012 12:48:29 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBAE21F85F4 for ; Mon, 13 Aug 2012 12:48:29 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 762472C9C5; Mon, 13 Aug 2012 12:48:27 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net> In-Reply-To: <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net> Date: Mon, 13 Aug 2012 12:47:00 -0700 Message-ID: <008601cd798c$6a5e26f0$3f1a74d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQLFlfTqqE/AKW0D4NQ2kQBPiDZx7QIHVRRoAg1xbPQBsJd0/5U5wZTg Content-Language: en-us Cc: 'Harry Halpin' , jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 19:48:30 -0000 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, August 13, 2012 9:30 AM > To: Jim Schaad > Cc: Hannes Tschofenig; 'Harry Halpin'; jose@ietf.org > Subject: Re: [jose] JOSE WG request from W3C WebCrypto API > > > On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote: > > >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems > >> like > > for > >> backwards compatibility having some level of ASN.1 support would be > >> useful and we *need* a format that allows key material (both private > >> and > >> public) to be exported. Folks seem to leaning towards ASN.1 as a > >> default format in the low-level API, and having JWK as a format that > >> can be built > > on > >> top of that in a possible high-level API. Would that be OK? > > > This is really interesting! > > The entire work on JSON signing and encryption was started since the Web > and browser guys told us that there no way they would ever want to use > ASN.1. Completely impossible - not compatible with the way how Web > applications are developed these days, and so on. > > > Now, they ask for ASN.1 support. I think this may be a simple case of - all of the low level crypto libraries that they might link to all support ASN.1 for dealing with asymmetric keys and they are trying to avoid doing the conversion to JOSE for that work. The other question is if we should just use ASN.1 for key formats in JOSE rather than the JSON version if they are going to go with ASN.1 anyway. Jim From Michael.Jones@microsoft.com Mon Aug 13 13:24:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C39A21F8645 for ; Mon, 13 Aug 2012 13:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqSvRE6N-8gw for ; Mon, 13 Aug 2012 13:24:22 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5918921F863B for ; Mon, 13 Aug 2012 13:24:22 -0700 (PDT) Received: from mail7-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Aug 2012 20:24:21 +0000 Received: from mail7-co1 (localhost [127.0.0.1]) by mail7-co1-R.bigfish.com (Postfix) with ESMTP id AAB46D001B5; Mon, 13 Aug 2012 20:24:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI98dI9371Ic85fh542M1432Izz1202hzz8275ch1033IL8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail7-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail7-co1 (localhost.localdomain [127.0.0.1]) by mail7-co1 (MessageSwitch) id 1344889459943712_1132; Mon, 13 Aug 2012 20:24:19 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.226]) by mail7-co1.bigfish.com (Postfix) with ESMTP id E47036600A6; Mon, 13 Aug 2012 20:24:19 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Aug 2012 20:24:18 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Mon, 13 Aug 2012 20:24:11 +0000 From: Mike Jones To: Jim Schaad , 'Hannes Tschofenig' Thread-Topic: [jose] JOSE WG request from W3C WebCrypto API Thread-Index: AQHNeJunnpgcpjfvnEmN0vS5J/XJKJdWhwUAgAFphwCAADcLAIAACmLa Date: Mon, 13 Aug 2012 20:24:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366773C7E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net>, <008601cd798c$6a5e26f0$3f1a74d0$@augustcellars.com> In-Reply-To: <008601cd798c$6a5e26f0$3f1a74d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366773C7ETK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: 'Harry Halpin' , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 20:24:23 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366773C7ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This argument cuts both ways. If WebCrypto is considering using ASN.1 becau= se we don't provide a private key representation, that may be sufficient gr= ounds for us to consider doing so (either in JWK or in an extension spec). -- Mike (who returns from vacation tomorrow) ________________________________ From: Jim Schaad Sent: 8/13/2012 3:48 PM To: 'Hannes Tschofenig' Cc: 'Harry Halpin'; jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, August 13, 2012 9:30 AM > To: Jim Schaad > Cc: Hannes Tschofenig; 'Harry Halpin'; jose@ietf.org > Subject: Re: [jose] JOSE WG request from W3C WebCrypto API > > > On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote: > > >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems > >> like > > for > >> backwards compatibility having some level of ASN.1 support would be > >> useful and we *need* a format that allows key material (both private > >> and > >> public) to be exported. Folks seem to leaning towards ASN.1 as a > >> default format in the low-level API, and having JWK as a format that > >> can be built > > on > >> top of that in a possible high-level API. Would that be OK? > > > This is really interesting! > > The entire work on JSON signing and encryption was started since the Web > and browser guys told us that there no way they would ever want to use > ASN.1. Completely impossible - not compatible with the way how Web > applications are developed these days, and so on. > > > Now, they ask for ASN.1 support. I think this may be a simple case of - all of the low level crypto librarie= s that they might link to all support ASN.1 for dealing with asymmetric keys and they are trying to avoid doing the conversion to JOSE for that work. The other question is if we should just use ASN.1 for key formats in JOSE rather than the JSON version if they are going to go with ASN.1 anyway. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366773C7ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This argument= cuts both ways. If WebCrypto is considering using ASN.1 because we don't p= rovide a private key representation, that may be sufficient grounds for us = to consider doing so (either in JWK or in an extension spec).

-- Mike (who returns from vacation tomorrow)

From: Jim Sc= haad
Sent: 8/13/2= 012 3:48 PM
To: 'Hanne= s Tschofenig'
Cc: 'Harry= Halpin'; jose@ietf.org
Subject: Re: [j= ose] JOSE WG request from W3C WebCrypto API



> -----Original Message-----
> From: Hannes Tschofenig [= mailto:hannes.tschofenig@gmx.net]
> Sent: Monday, August 13, 2012 9:30 AM
> To: Jim Schaad
> Cc: Hannes Tschofenig; 'Harry Halpin'; jose@ietf.org
> Subject: Re: [jose] JOSE WG request from W3C WebCrypto API
>
>
> On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote:
>
> >>  2) While we'd like encourage the use of JOSE over ASN.1= , it seems
> >> like
> > for
> >> backwards compatibility having some level of ASN.1 support wo= uld be
> >> useful and we *need* a format that allows key material (both = private
> >> and
> >> public) to be exported. Folks seem to leaning towards ASN.1 a= s a
> >> default format in the low-level API, and having JWK as a form= at that
> >> can be built
> > on
> >> top of that in a possible high-level API. Would that be OK? >
>
> This is really interesting!
>
> The entire work on JSON signing and encryption was started since the W= eb
> and browser guys told us that there no way they would ever want to use=
> ASN.1. Completely impossible - not compatible with the way how Web
> applications are developed these days, and so on.
>
>
> Now, they ask for ASN.1 support.

I think this may be a simple case of - all of the low level crypto librarie= s
that they might link to all support ASN.1 for dealing with asymmetric keys<= br> and they are trying to avoid doing the conversion to JOSE for that work. The other question is if we should just use ASN.1 for key formats in JOSE rather than the JSON version if they are going to go with ASN.1 anyway.

Jim



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

 --_000_4E1F6AAD24975D4BA5B168042967394366773C7ETK5EX14MBXC283r_-- From tonynad@microsoft.com Mon Aug 13 13:29:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D99621F8650 for ; Mon, 13 Aug 2012 13:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1EQ+6AqQLag for ; Mon, 13 Aug 2012 13:29:39 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id E21DF21F8645 for ; Mon, 13 Aug 2012 13:29:38 -0700 (PDT) Received: from mail92-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Aug 2012 20:29:37 +0000 Received: from mail92-am1 (localhost [127.0.0.1]) by mail92-am1-R.bigfish.com (Postfix) with ESMTP id A382D2A00D7 for ; Mon, 13 Aug 2012 20:29:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zzbb2dI98dI9371Ic85fh542M1432Izz1202h1082kzz8275ch1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah1155h) Received-SPF: pass (mail92-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1 (MessageSwitch) id 1344889775904340_717; Mon, 13 Aug 2012 20:29:35 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.226]) by mail92-am1.bigfish.com (Postfix) with ESMTP id DB0964C005F for ; Mon, 13 Aug 2012 20:29:35 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Aug 2012 20:29:35 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Mon, 13 Aug 2012 20:29:24 +0000 Received: from mail53-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Aug 2012 20:29:16 +0000 Received: from mail53-db3 (localhost [127.0.0.1]) by mail53-db3-R.bigfish.com (Postfix) with ESMTP id 291361802AB for ; Mon, 13 Aug 2012 20:29:16 +0000 (UTC) Received: from mail53-db3 (localhost.localdomain [127.0.0.1]) by mail53-db3 (MessageSwitch) id 1344889753841036_4031; Mon, 13 Aug 2012 20:29:13 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.243]) by mail53-db3.bigfish.com (Postfix) with ESMTP id C1308100047; Mon, 13 Aug 2012 20:29:13 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Aug 2012 20:29:12 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0175.005; Mon, 13 Aug 2012 20:29:12 +0000 From: Anthony Nadalin To: Mike Jones , Jim Schaad , 'Hannes Tschofenig' Thread-Topic: [jose] JOSE WG request from W3C WebCrypto API Thread-Index: AQHNeLxbUVYA/yBU8kyKvGZSTWCtDJdX8EsAgAA3CgCAAApjAIAAAOhw Date: Mon, 13 Aug 2012 20:29:11 +0000 Message-ID: References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net>, <008601cd798c$6a5e26f0$3f1a74d0$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366773C7E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366773C7E@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7718BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%W3.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: 'Harry Halpin' , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 20:29:40 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7718BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Private key was on list moving into JOSE as the requirements were discussed= at the BoF and during the charter discussions From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Monday, August 13, 2012 1:24 PM To: Jim Schaad; 'Hannes Tschofenig' Cc: 'Harry Halpin'; jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API This argument cuts both ways. If WebCrypto is considering using ASN.1 becau= se we don't provide a private key representation, that may be sufficient gr= ounds for us to consider doing so (either in JWK or in an extension spec). -- Mike (who returns from vacation tomorrow) ________________________________ From: Jim Schaad Sent: 8/13/2012 3:48 PM To: 'Hannes Tschofenig' Cc: 'Harry Halpin'; jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, August 13, 2012 9:30 AM > To: Jim Schaad > Cc: Hannes Tschofenig; 'Harry Halpin'; jose@ietf.org > Subject: Re: [jose] JOSE WG request from W3C WebCrypto API > > > On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote: > > >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems > >> like > > for > >> backwards compatibility having some level of ASN.1 support would be > >> useful and we *need* a format that allows key material (both private > >> and > >> public) to be exported. Folks seem to leaning towards ASN.1 as a > >> default format in the low-level API, and having JWK as a format that > >> can be built > > on > >> top of that in a possible high-level API. Would that be OK? > > > This is really interesting! > > The entire work on JSON signing and encryption was started since the Web > and browser guys told us that there no way they would ever want to use > ASN.1. Completely impossible - not compatible with the way how Web > applications are developed these days, and so on. > > > Now, they ask for ASN.1 support. I think this may be a simple case of - all of the low level crypto librarie= s that they might link to all support ASN.1 for dealing with asymmetric keys and they are trying to avoid doing the conversion to JOSE for that work. The other question is if we should just use ASN.1 for key formats in JOSE rather than the JSON version if they are going to go with ASN.1 anyway. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7718BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Private key was on list m= oving into JOSE as the requirements were discussed at the BoF and during th= e charter discussions

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Monday, August 13, 2012 1:24 PM
To: Jim Schaad; 'Hannes Tschofenig'
Cc: 'Harry Halpin'; jose@ietf.org
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

 

This arg= ument cuts both ways. If WebCrypto is considering using ASN.1 because we do= n't provide a private key representation, that may be sufficient grounds for us to consider doing so (either in JWK or in an extension spec= ).

-- Mike (who returns from vacation tomorrow)

From: Jim Schaad
Sent: 8/13/2012 3:48 PM
To: 'Hannes Tschofenig'
Cc: 'Harry Halpin'; jose@ietf.org
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API



> -----Original Message-----
> From: Hannes Tschofenig [= mailto:hannes.tschofenig@gmx.net]
> Sent: Monday, August 13, 2012 9:30 AM
> To: Jim Schaad
> Cc: Hannes Tschofenig; 'Harry Halpin'; jose@ietf.org
> Subject: Re: [jose] JOSE WG request from W3C WebCrypto API
>
>
> On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote:
>
> >>  2) While we'd like encourage the use of JOSE over ASN.1= , it seems
> >> like
> > for
> >> backwards compatibility having some level of ASN.1 support wo= uld be
> >> useful and we *need* a format that allows key material (both = private
> >> and
> >> public) to be exported. Folks seem to leaning towards ASN.1 a= s a
> >> default format in the low-level API, and having JWK as a form= at that
> >> can be built
> > on
> >> top of that in a possible high-level API. Would that be OK? >
>
> This is really interesting!
>
> The entire work on JSON signing and encryption was started since the W= eb
> and browser guys told us that there no way they would ever want to use=
> ASN.1. Completely impossible - not compatible with the way how Web
> applications are developed these days, and so on.
>
>
> Now, they ask for ASN.1 support.

I think this may be a simple case of - all of the low level crypto librarie= s
that they might link to all support ASN.1 for dealing with asymmetric keys<= br> and they are trying to avoid doing the conversion to JOSE for that work. The other question is if we should just use ASN.1 for key formats in JOSE rather than the JSON version if they are going to go with ASN.1 anyway.

Jim



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

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7718BL2PRD0310MB362_-- From ignisvulpis@googlemail.com Mon Aug 13 10:14:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7879221F86F7 for ; Mon, 13 Aug 2012 10:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrzCOBO7jMQJ for ; Mon, 13 Aug 2012 10:14:02 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50ACA21F86DA for ; Mon, 13 Aug 2012 10:14:02 -0700 (PDT) Received: by wicr5 with SMTP id r5so2192525wic.13 for ; Mon, 13 Aug 2012 10:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9Br6bMGRVmiVbgE2Q9JwwQsrHzfPt0lIojEz8nQrl8k=; b=Z1xxTlL5NfzMBkiJEGpO79OodeFVDoJUGI6oTO61FVGQo7fireqjYq4vc/PAgGY9E/ O2Lix3gKvqnOPj8UIsTtgWuSamggHLjQsayNTqJewxq142wDFxP1lGnBnOLekWhmS+vT gr9nSKzu+ydrgT0cKtKhP9ban1rKZf2aVON3rygsv4zwblo6y4r9GG8hvpQncSn7AQBC vr9eQoqMQ6zedVRSjAWbGSo28/grHutpib/aAPZw/siR+FjiysAD6dLWOKodAZjN0/uo dbLS+XLZR0GY/cQGtbUObtCOSmlJ+WBCvg0drqzMcgn2OuZgqKAYI6PqrEuiALn2q2Fi /p4w== MIME-Version: 1.0 Received: by 10.216.241.198 with SMTP id g48mr5807875wer.156.1344878041189; Mon, 13 Aug 2012 10:14:01 -0700 (PDT) Received: by 10.216.241.4 with HTTP; Mon, 13 Aug 2012 10:14:01 -0700 (PDT) Received: by 10.216.241.4 with HTTP; Mon, 13 Aug 2012 10:14:01 -0700 (PDT) In-Reply-To: <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <003c01cd78bc$1ed60660$5c821320$@augustcellars.com> <4B89844A-279C-4800-BDA2-C73A0195974B@gmx.net> Date: Mon, 13 Aug 2012 19:14:01 +0200 Message-ID: From: Axel Nennker To: Hannes Tschofenig , jose@ietf.org Content-Type: multipart/alternative; boundary=e0cb4e43d0afe94dff04c728d170 X-Mailman-Approved-At: Mon, 13 Aug 2012 17:52:41 -0700 Cc: Axel Nennker Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:14:45 -0000 --e0cb4e43d0afe94dff04c728d170 Content-Type: text/plain; charset=ISO-8859-1 There are two or more "they"... ASN.1 should never be MTI in JOSE nor WebCrypto. It is ok to use as a blob maybe but when either WG specifies something that requires ASN.1 parsing then we are on the wrong track I think. Am 13.08.2012 18:30 schrieb "Hannes Tschofenig" : > > On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote: > > >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems like > > for > >> backwards compatibility having some level of ASN.1 support would be > useful > >> and we *need* a format that allows key material (both private and > >> public) to be exported. Folks seem to leaning towards ASN.1 as a default > >> format in the low-level API, and having JWK as a format that can be > built > > on > >> top of that in a possible high-level API. Would that be OK? > > > This is really interesting! > > The entire work on JSON signing and encryption was started since the Web > and browser guys told us that there no way they would ever want to use > ASN.1. Completely impossible - not compatible with the way how Web > applications are developed these days, and so on. > > > Now, they ask for ASN.1 support. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --e0cb4e43d0afe94dff04c728d170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

There are two or more "they"...

ASN.1 should never be MTI in JOSE nor WebCrypto. It is ok to use as a bl= ob maybe but when either WG specifies something that requires ASN.1 parsing= then we are on the wrong track I think.

Am 13.08.2012 18:30 schrieb "Hannes Tschofe= nig" <hannes.tschofeni= g@gmx.net>:

On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote:

>> =A02) While we'd like encourage the use of JOSE over ASN.1, it= seems like
> for
>> backwards compatibility having some level of ASN.1 support would b= e useful
>> and we *need* a format that allows key material (both private and<= br> >> public) to be exported. Folks seem to leaning towards ASN.1 as a d= efault
>> format in the low-level API, and having JWK as a format that can b= e built
> on
>> top of that in a possible high-level API. Would that be OK?


This is really interesting!

The entire work on JSON signing and encryption was started since the Web an= d browser guys told us that there no way they would ever want to use ASN.1.= Completely impossible - not compatible with the way how Web applications a= re developed these days, and so on.


Now, they ask for ASN.1 support.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
--e0cb4e43d0afe94dff04c728d170-- From hannes.tschofenig@nsn.com Tue Aug 14 01:17:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FE121F86E4 for ; Tue, 14 Aug 2012 01:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.604 X-Spam-Level: X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFSuwib74qgN for ; Tue, 14 Aug 2012 01:17:37 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E88BB21F86E0 for ; Tue, 14 Aug 2012 01:17:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7E8HU4I018701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Aug 2012 10:17:30 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7E8HUF2018813; Tue, 14 Aug 2012 10:17:30 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Aug 2012 10:17:30 +0200 Received: from 10.159.32.11 ([10.159.32.11]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Aug 2012 08:17:29 +0000 MIME-Version: 1.0 Message-ID: <11b201cd79f5$3f036c6c$0b209f0a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [jose] JOSE WG request from W3C WebCrypto API Thread-Index: Ac159T8D2EgrRO9CS8Wu9cEiQELw9A== Date: Tue, 14 Aug 2012 11:17:30 +0300 To: "ext Axel Nennker" , "Hannes Tschofenig" , Content-Type: multipart/alternative; boundary="_8EEF93C2-CF3F-6CFD-397B-A617AB5E684C_"; charset="iso-8859-1" X-OriginalArrivalTime: 14 Aug 2012 08:17:30.0092 (UTC) FILETIME=[3F6192C0:01CD79F5] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5653 X-purgate-ID: 151667::1344932250-00003184-07FFF5E8/0-0/0-0 Cc: Axel Nennker Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 08:17:38 -0000 --_8EEF93C2-CF3F-6CFD-397B-A617AB5E684C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Axel, the 'they' refers to the W3C group. I am not part of the group and th= erefore have no insight in their decision making process nor in the reasons= for the decisions. That's the problem with closed groups... Sent from my Windows Phone -----Original Message----- From: ext Axel Nennker Sent: 8/14/2012 3:52 AM To: Hannes Tschofenig; jose@ietf.org Cc: Axel Nennker Subject: Re: [jose] JOSE WG request from W3C WebCrypto API There are two or more "they"... =20 ASN.1 should never be MTI in JOSE nor WebCrypto. It is ok to use as a blob = maybe but when either WG specifies something that requires ASN.1 parsing th= en we are on the wrong track I think. =20 Am 13.08.2012 18:30 schrieb "Hannes Tschofenig" = : =20 On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote: =20 >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems like > for >> backwards compatibility having some level of ASN.1 support would be use= ful >> and we *need* a format that allows key material (both private and >> public) to be exported. Folks seem to leaning towards ASN.1 as a defaul= t >> format in the low-level API, and having JWK as a format that can be bui= lt > on >> top of that in a possible high-level API. Would that be OK? =20 This is really interesting! =20 The entire work on JSON signing and encryption was started since the Web an= d browser guys told us that there no way they would ever want to use ASN.1.= Completely impossible - not compatible with the way how Web applications a= re developed these days, and so on. =20 Now, they ask for ASN.1 support. =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_8EEF93C2-CF3F-6CFD-397B-A617AB5E684C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Axel, the 'they' refers to the W3C group. I am not p= art of the group and therefore have no insight in their decision making pro= cess nor in the reasons for the decisions. That's the problem with closed g= roups...

Sent from my Windows Phone
Fr= om: ext Axel Nennker
Sent: 8/14/2012 3:52 AM
Hannes Tschofenig; jose@ietf.org
Cc: Axel Nennker=
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API=

There are two or more "they"...

=0A=

ASN.1 should never be MTI in JOSE nor WebCrypto. It is ok to use as a bl= ob maybe but when either WG specifies something that requires ASN.1 parsing= then we are on the wrong track I think.
=0A=

=0A=
Am 13.08.2012 18:30 schrieb "Hannes Tschofenig" = <hannes.tschofenig@gmx.net<= /a>>:
=0A=
=0A= On Aug 12, 2012, at 9:56 PM, Jim Schaad wrote:
=0A=
=0A= >>  2) While we'd like encourage the use of JOSE over ASN.1, it = seems like
=0A= > for
=0A= >> backwards compatibility having some level of ASN.1 support would b= e useful
=0A= >> and we *need* a format that allows key material (both private and<= br>=0A= >> public) to be exported. Folks seem to leaning towards ASN.1 as a d= efault
=0A= >> format in the low-level API, and having JWK as a format that can b= e built
=0A= > on
=0A= >> top of that in a possible high-level API. Would that be OK?
=0A=
=0A=
=0A= This is really interesting!
=0A=
=0A= The entire work on JSON signing and encryption was started since the Web an= d browser guys told us that there no way they would ever want to use ASN.1.= Completely impossible - not compatible with the way how Web applications a= re developed these days, and so on.
=0A= =0A=
=0A=
=0A= Now, they ask for ASN.1 support.
=0A=
=0A=
=0A= _______________________________________________
=0A= jose mailing list
=0A= jose@ietf.org
=0A= ht= tps://www.ietf.org/mailman/listinfo/jose
=0A=
=0A= = --_8EEF93C2-CF3F-6CFD-397B-A617AB5E684C_-- From odonoghue@isoc.org Wed Aug 15 11:45:19 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFE521F87E9 for ; Wed, 15 Aug 2012 11:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.82 X-Spam-Level: X-Spam-Status: No, score=-103.82 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn3tfu19RhvH for ; Wed, 15 Aug 2012 11:45:18 -0700 (PDT) Received: from smtp166.dfw.emailsrvr.com (smtp166.dfw.emailsrvr.com [67.192.241.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6152C21F87FA for ; Wed, 15 Aug 2012 11:45:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id F0FA940284 for ; Wed, 15 Aug 2012 14:45:17 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp16.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id C7093402B9 for ; Wed, 15 Aug 2012 14:45:17 -0400 (EDT) Message-ID: <502BEE34.4090605@isoc.org> Date: Wed, 15 Aug 2012 13:45:08 -0500 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org References: <5027C586.8080902@w3.org> In-Reply-To: <5027C586.8080902@w3.org> X-Forwarded-Message-Id: <5027C586.8080902@w3.org> Content-Type: multipart/alternative; boundary="------------080507010009020908050208" Subject: [jose] Fwd: JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:45:19 -0000 This is a multi-part message in MIME format. --------------080507010009020908050208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit jose wg, We have received a request for information from the W3C working group. We will be working on a response shortly. Comments welcome. Thanks, Karen -------- Original Message -------- Subject: JOSE WG request from W3C WebCrypto API Resent-Date: Sun, 12 Aug 2012 11:03:52 -0400 (EDT) Resent-From: hhalpin@w3.org Resent-To: odonoghue@isoc.org, ietf@augustcellars.com, Date: Sun, 12 Aug 2012 17:02:30 +0200 From: Harry Halpin To: Jim Schaad , Karen O'Donoghue , jose-chairs@tools.ietf.org, Michael Jones [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] JOSE Chairs, The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to: 1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'? 2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK? 3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when? The W3C would like to and plan to use these formats where possible. Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August. cheers, harry --------------080507010009020908050208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit jose wg,

We have received a request for information from the W3C working group. We will be working on a response shortly. Comments welcome.

Thanks,
Karen

-------- Original Message --------
Subject: JOSE WG request from W3C WebCrypto API
Resent-Date: Sun, 12 Aug 2012 11:03:52 -0400 (EDT)
Resent-From: hhalpin@w3.org
Resent-To: odonoghue@isoc.org, ietf@augustcellars.com,
Date: Sun, 12 Aug 2012 17:02:30 +0200
From: Harry Halpin <hhalpin@w3.org>
To: Jim Schaad <ietf@augustcellars.com>, Karen O'Donoghue <odonoghue@isoc.org>, jose-chairs@tools.ietf.org, Michael Jones <Michael.Jones@microsoft.com> 


[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some 
access to raw key material, and the issue of whether or not to use JWK 
or ASN.1 as the default format came up. Two issues have come out that 
we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to 
support a JOSE-format for private keys? If so, when? Or 'maybe'?

 2) While we'd like encourage the use of JOSE over ASN.1, it seems like 
for backwards compatibility having some level of ASN.1 support would be 
useful and we *need* a format that allows key material (both private and 
public) to be exported. Folks seem to leaning towards ASN.1 as a default 
format in the low-level API, and having JWK as a format that can be 
built on top of that in a possible high-level API. Would that be OK?

 3) How stable do you believe the JOSE formats are right now? Do you 
think they are stable enough now we can reference them in our API draft 
at end of August? If not, when?  The W3C would like to and plan to use 
these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer 
before we send our document to FPWD at end of August.

 cheers,
     harry



--------------080507010009020908050208-- From odonoghue@isoc.org Wed Aug 15 11:53:38 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC521F8679 for ; Wed, 15 Aug 2012 11:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12S1FI3t-M89 for ; Wed, 15 Aug 2012 11:53:29 -0700 (PDT) Received: from smtp158.ord.emailsrvr.com (smtp158.ord.emailsrvr.com [173.203.6.158]) by ietfa.amsl.com (Postfix) with ESMTP id C446E21F870F for ; Wed, 15 Aug 2012 11:53:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 9F5201982F7 for ; Wed, 15 Aug 2012 14:53:25 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 81B2019828E for ; Wed, 15 Aug 2012 14:53:25 -0400 (EDT) Message-ID: <502BF01C.1040701@isoc.org> Date: Wed, 15 Aug 2012 13:53:16 -0500 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org References: <5027C586.8080902@w3.org> <502BEE34.4090605@isoc.org> In-Reply-To: <502BEE34.4090605@isoc.org> Content-Type: multipart/alternative; boundary="------------080002020100040902010208" Subject: Re: [jose] Fwd: JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:53:38 -0000 This is a multi-part message in MIME format. --------------080002020100040902010208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My apologies folks... This was in my draft folder and I sent instead of deleted... please ignore and return to your previously scheduled discussion... Thanks, Karen On 8/15/12 1:45 PM, Karen O'Donoghue wrote: > jose wg, > > We have received a request for information from the W3C working group. > We will be working on a response shortly. Comments welcome. > > Thanks, > Karen > > -------- Original Message -------- > Subject: JOSE WG request from W3C WebCrypto API > Resent-Date: Sun, 12 Aug 2012 11:03:52 -0400 (EDT) > Resent-From: hhalpin@w3.org > Resent-To: odonoghue@isoc.org, ietf@augustcellars.com, > Date: Sun, 12 Aug 2012 17:02:30 +0200 > From: Harry Halpin > To: Jim Schaad , Karen O'Donoghue > , jose-chairs@tools.ietf.org, Michael Jones > > > > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some > access to raw key material, and the issue of whether or not to use JWK > or ASN.1 as the default format came up. Two issues have come out that > we'd like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to > support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like > for backwards compatibility having some level of ASN.1 support would be > useful and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default > format in the low-level API, and having JWK as a format that can be > built on top of that in a possible high-level API. Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do you > think they are stable enough now we can reference them in our API draft > at end of August? If not, when? The W3C would like to and plan to use > these formats where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an answer > before we send our document to FPWD at end of August. > > cheers, > harry > > > > > --------------080002020100040902010208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
My apologies folks... This was in my draft folder and I sent instead of deleted... please ignore and return to your previously scheduled discussion...

Thanks,
Karen

On 8/15/12 1:45 PM, Karen O'Donoghue wrote:
jose wg,

We have received a request for information from the W3C working group. We will be working on a response shortly. Comments welcome.

Thanks,
Karen

-------- Original Message --------
Subject: JOSE WG request from W3C WebCrypto API
Resent-Date: Sun, 12 Aug 2012 11:03:52 -0400 (EDT)
Resent-From: hhalpin@w3.org
Resent-To: odonoghue@isoc.org, ietf@augustcellars.com,
Date: Sun, 12 Aug 2012 17:02:30 +0200
From: Harry Halpin <hhalpin@w3.org>
To: Jim Schaad <ietf@augustcellars.com>, Karen O'Donoghue <odonoghue@isoc.org>, jose-chairs@tools.ietf.org, Michael Jones <Michael.Jones@microsoft.com> 


[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some 
access to raw key material, and the issue of whether or not to use JWK 
or ASN.1 as the default format came up. Two issues have come out that 
we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to 
support a JOSE-format for private keys? If so, when? Or 'maybe'?

 2) While we'd like encourage the use of JOSE over ASN.1, it seems like 
for backwards compatibility having some level of ASN.1 support would be 
useful and we *need* a format that allows key material (both private and 
public) to be exported. Folks seem to leaning towards ASN.1 as a default 
format in the low-level API, and having JWK as a format that can be 
built on top of that in a possible high-level API. Would that be OK?

 3) How stable do you believe the JOSE formats are right now? Do you 
think they are stable enough now we can reference them in our API draft 
at end of August? If not, when?  The W3C would like to and plan to use 
these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer 
before we send our document to FPWD at end of August.

 cheers,
     harry




--------------080002020100040902010208-- From Michael.Jones@microsoft.com Wed Aug 15 16:19:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7521E803A for ; Wed, 15 Aug 2012 16:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwUMeawTpuJx for ; Wed, 15 Aug 2012 16:19:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id D17CF21F84A7 for ; Wed, 15 Aug 2012 16:19:16 -0700 (PDT) Received: from mail153-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 23:19:16 +0000 Received: from mail153-ch1 (localhost [127.0.0.1]) by mail153-ch1-R.bigfish.com (Postfix) with ESMTP id 0B57C18076F; Wed, 15 Aug 2012 23:19:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz9371I1415J1454I148cI542Mzz1202hzz1033IL8275eh8275dha1495iz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail153-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail153-ch1 (localhost.localdomain [127.0.0.1]) by mail153-ch1 (MessageSwitch) id 1345072754190814_3104; Wed, 15 Aug 2012 23:19:14 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail153-ch1.bigfish.com (Postfix) with ESMTP id 2C764260046; Wed, 15 Aug 2012 23:19:14 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 23:19:13 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Wed, 15 Aug 2012 23:19:12 +0000 From: Mike Jones To: Harry Halpin , Jim Schaad , Karen O'Donoghue , "jose-chairs@tools.ietf.org" Thread-Topic: JOSE WG request from W3C WebCrypto API Thread-Index: AQHNeJunnpgcpjfvnEmN0vS5J/XJKJdbc0tA Date: Wed, 15 Aug 2012 23:19:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> In-Reply-To: <5027C586.8080902@w3.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 23:19:21 -0000 Thanks for writing, Harry and WebCrypto WG. =20 1) About private keys, given the WebCrypto use case, I personally think it= would be valuable for JOSE to define a JSON private key representation. T= o make this concrete, I would propose the private key representations speci= fied in http://tools.ietf.org/html/draft-jones-jose-json-private-key. You'= ll see that doing this is very simple; it just defines two additional membe= rs for the JWK structure for representing the private parts of Elliptic Cur= ve and RSA keys. This could either remain a separate spec from JWK/JWA or = be merged in, at the working group's preference. I had previously agreed with the position that it was not necessary for JOS= E to define private key representations because we didn't have a use case f= or it. However, as I see it, the W3C WebCrypto API use case changes things= . Better for JOSE to be responsive to WebCrypto and add this simple extens= ion, either as a new spec or in the existing specs, than to leave this undo= ne, and have it potentially be an area where otherwise standards-compliant = implementations diverge, and where JSON-only solutions are not possible. Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jos= e/charter/ does not preclude defining private key formats. (It simply requ= ires the definition of public key formats and is silent on the topic of pri= vate keys.) 2) I agree on the likely need for WebCrypto support ASN.1 for backwards co= mpatibility in some cases (just as the JOSE specs allow the use of X.509 ce= rtificates). However, I believe it would be a shame to preclude JSON-only = solutions by not supporting key import/export in JWK format, where such sol= utions make sense. 3) It appears to me the JWK format is stable. I believe the JWS format is= stable as well. The JWE format has known changes that will be applied sho= rtly, based upon working group discussions at IETF 84 in Vancouver two week= s ago. Some JWA changes will occur that are part of the JWE changes. I do= n't anticipate significant changes after that. (Making these changes is my= highest priority as JOSE editor. I'm hoping to have drafts out containing= them by the end of August, which hopefully fits well with the WebCrypto sc= hedule.) I write all of the above with the caveat that the working group i= s, of course, free to change things as they see fit. I look forward to a productive discussion of this coordination request in b= oth working groups. Best wishes, -- Mike P.S. If you prefer, a HTML-formatted version of the private key spec is av= ailable at http://self-issued.info/docs/draft-jones-jose-json-private-key.h= tml. I also blogged about this draft specification at http://self-issued.i= nfo/?p=3D816. -----Original Message----- From: Harry Halpin [mailto:hhalpin@w3.org]=20 Sent: Sunday, August 12, 2012 8:03 AM To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones Subject: JOSE WG request from W3C WebCrypto API [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] JOSE Chairs, The Web Cryptography Working group has noted that the API requires some acc= ess to raw key material, and the issue of whether or not to use JWK or ASN.= 1 as the default format came up. Two issues have come out that we'd like to= know the answer to: 1) JWK does not define a private key format. Does the JOSE WG plan to suppo= rt a JOSE-format for private keys? If so, when? Or 'maybe'? 2) While we'd like encourage the use of JOSE over ASN.1, it seems like fo= r backwards compatibility having some level of ASN.1 support would be usefu= l and we *need* a format that allows key material (both private and public) to be exported. Folks seem to leaning towards ASN.1 as a default fo= rmat in the low-level API, and having JWK as a format that can be built on = top of that in a possible high-level API. Would that be OK? 3) How stable do you believe the JOSE formats are right now? Do you think= they are stable enough now we can reference them in our API draft at end o= f August? If not, when? The W3C would like to and plan to use these format= s where possible. Feel free to forward this by JOSE WG for discussion. We'd like an answer be= fore we send our document to FPWD at end of August. cheers, harry From James.H.Manger@team.telstra.com Wed Aug 15 17:46:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D6811E80D9 for ; Wed, 15 Aug 2012 17:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4HKTMXKXCJf for ; Wed, 15 Aug 2012 17:46:56 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id E53BA11E80BA for ; Wed, 15 Aug 2012 17:46:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,776,1336312800"; d="scan'208";a="85617225" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 16 Aug 2012 10:46:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6804"; a="82773360" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccni.tcif.telstra.com.au with ESMTP; 16 Aug 2012 10:46:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 16 Aug 2012 10:46:47 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 16 Aug 2012 10:46:46 +1000 Thread-Topic: private keys, leading zeros Thread-Index: AQHNeJunnpgcpjfvnEmN0vS5J/XJKJdbc0tAgAAXnmA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA90743E@WSMSG3153V.srv.dir.telstra.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] private keys, leading zeros X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 00:46:56 -0000 TWlrZSwNCg0KVGhhbmtzIGZvciBtYWtpbmcgdGhlIGVmZm9ydCB0byBwcm9kdWNlIGEgZHJhZnQ6 DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1qb3NlLWpzb24tcHJpdmF0 ZS1rZXkNCg0KRm91ciBjb21tZW50czoNCg0KMS4NCllvdXIgY2hvaWNlIHRvIGV4dGVuZCB0aGUg cHVibGljIGtleSBmb3JtYXQgdG8gYWxzbyBob2xkIHRoZSBwcml2YXRlIGtleSBpbmZvIG1pZ2h0 IGhhdmUgc29tZSBpbnRlcmVzdGluZyBjb25zZXF1ZW5jZXMuIEl0IHN1Z2dlc3RzIHlvdSBjYW4g aGF2ZSBhIHNpbmdsZSBmaWxlIChvciBzaW5nbGUgSlNPTiBvYmplY3QpIHRoYXQgY2FuIGJlIHVz ZWQgYnkgdG9vbHMgdGhhdCBuZWVkcyBhIHB1YmxpYyBrZXksIGFuZCBieSB0b29scyB0aGF0IG5l ZWQgYSBwcml2YXRlIGtleS4gSG93ZXZlciwgSSBkb3VidCB0aGF0IGlzIHZlcnkgZ29vZCBwcmFj dGljZS4gSXQganVzdCBhZGRzIGEgcmlzayB0aGF0IGEgcHJpdmF0ZSBrZXkgaXMgaW5hZHZlcnRl bnRseSBleHBvc2VkIHdoZXJlIGl0IHNob3VsZG4ndCBiZS4NCg0KUGVyaGFwcyB0aGUgZm9sbG93 aW5nIHNvcnQgb2YgZm9ybWF0IHdvdWxkIGJlIGJldHRlcjoNCiAgew0KICAgICJwdWJsaWMiOnsi YWxnIjoiLi4ufSwNCiAgICAicHJpdmF0ZSI6eyJkIjouLi59DQogIH0NCg0KDQoyLg0KVGhlIHJ1 bGUgdGhhdCBpbnRlZ2VycyBNVVNUIG5vdCBiZSBzaG9ydGVuZWQgaWYgdGhleSBoYXZlIGxlYWRp bmcgMCdzIGlzIHNpbGx5LiBJdCBpbXBsaWVzIHlvdSBjYW5ub3QgZW5jb2RlIGFuIGludGVnZXIg d2l0aG91dCBrbm93aW5nIGEgbGFyZ2VyIGNvbnRleHQgKGVnIHlvdSBjYW5ub3QgZW5jb2RlIGQg d2l0aG91dCBzcGVjaWZ5aW5nIG4sIGluIHRoZSBjb250ZXh0IG9mIGFuIFJTQSBrZXkpLiBUaGlz IHJ1bGUgYXBwbGllcyB0byB0aGUgcHJpdmF0ZSBleHBvbmVudCwgYnV0IHRoZSBvcHBvc2l0ZSBy dWxlIGFwcGxpZXMgdG8gdGhlIHB1YmxpYyBleHBvbmVudC4gWXVjay4NCg0KRWl0aGVyIGFsd2F5 cyBmb3JiaWRkaW5nIGxlYWRpbmcgemVyb3MsIG9yIGFsd2F5cyBhbGxvd2luZyB0aGVtIChzbyBy ZWNlaXZlcnMgTVVTVCBzdXBwb3J0IHRoZW0pLCB3b3VsZCBiZSBtdWNoIGJldHRlciBydWxlcy4N Cg0KSSBqdXN0IG5vdGljZWQgdGhlICJNVVNUIG5vdCBvbWl0IGxlYWRpbmcgMCdzIiBydWxlIGFw cGxpZXMgdG8gdGhlIFJTQSBtb2R1bHVzIGluIEpXQSAoc2VjdGlvbiA1LjMuMSAibW9kIiBNb2R1 bHVzIFBhcmFtZXRlcikuIFRoZSBydWxlIGlzIGV2ZW4gc2lsbGllciBpbiB0aGlzIGNhc2UuIEl0 IGVmZmVjdGl2ZWx5IHNheXMgInRoZSBtb2R1bHVzIE1VU1QgYmUgZW5jb2RlZCBhcyB0aGUgc2l6 ZSBzb21lb25lL3NvbWV0aGluZyB0aG91Z2ggdGhlIG1vZHVsdXMgc2hvdWxkIGJlLCBpbnN0ZWFk IG9mIGFzIHRoZSBzaXplIGl0IGFjdHVhbGx5IGlzIi4gVGhpcyBzZWVtcyB0byBoYXZlIG5vIHB1 cnBvc2Ugb3RoZXIgdGhhbiB0byBtaXNsZWFkIChlZyB0cmljayBhIGNvbXBvbmVudCB0aGF0IG9u bHkgbG9va3MgYXQgdGhlIGVuY29kZWQgbGVuZ3RoIGludG8gdGhpbmtpbmcgdGhlIGtleSBpcyBs b25nZXIvc3Ryb25nZXIgdGhhbiBpdCBhY3R1YWxseSBpcykuDQoNCg0KMy4NCkFuIFJTQSBwcml2 YXRlIGtleSBmb3JtYXQgbmVlZHMgdG8gc3VwcG9ydCBjYWxjdWxhdGlvbnMgdGhhdCB1c2UgdGhl IENoaW5lc2UgUmVtYWluZGVyIFRoZW9ydW0gKENSVCksIGJ5IGFsbG93aW5nIHAsIHEsIGQgbW9k IHAtMSwgZCBtb2QgcS0xLCBhbmQgcWludiB0byBiZSBzcGVjaWZpZWQgLS0gbm90IGp1c3QgZC4g Q1JUIGNhbGN1bGF0aW9ucyBvZmZlciB0b28gbXVjaCBvZiBhIHBlcmZvcm1hbmNlIGJvb3N0IHRv IGlnbm9yZSAoMiBvciA0IHRpbWVzIGZhc3RlciwgY2FuJ3QgcmVtZW1iZXIgd2hpY2ggb2ZmIHRo ZSB0b3Agb2YgbXkgaGVhZCkuDQoNCkFuIFJTQSBtb2R1bHVzIGNhbiBhY3R1YWxseSBoYXZlIG1v cmUgdGhhbiAyIHByaW1lIGZhY3RvcnMuIEFuIFJTQSBwcml2YXRlIGtleSBmb3JtYXQgc2hvdWxk IHRoZW9yZXRpY2FsbHkgc3VwcG9ydCB0aGF0IGFzIHdlbGwuIFRoYXQgaXMsIHN1cHBvcnQgYW4g YXJyYXkgb2Yge3ByaW1lLCBleHBvbmVudCwgY29lZmZpY2llbnR9LCBpbnN0ZWFkIG9mIGhhcmR3 aXJpbmcgZmllbGRzIGZvciAyIHByaW1lcy4NClNlZSBSRkMzNDQ3ICJQS0NTICMxOiBSU0EgQ3J5 cHRvZ3JhcGh5IFNwZWNpZmljYXRpb25zLCB2ZXJzaW9uIDIuMSIuDQoNCg0KNC4NCkkgYW0gbm90 IHN1cmUgaWYgaXQgaGFzIGJlZW4gYXNrZWQgYmVmb3JlIChieSBtZSBvciBzb21lb25lIGVsc2Up LCBidXQgaXMgdGhlcmUgcmVhbGx5IGFueSBiZW5lZml0IGZyb20gd3JhcHBpbmcgdGhlIEpTT04g YXJyYXkgb2Yga2V5IG9iamVjdHMgaW4gYW5vdGhlciBKU09OIG9iamVjdCB3aXRoIGEgc2luZ2xl IG1lbWJlciAia2V5cyIgW0pXSyBzZWN0aW9uIDUgIkpTT04gV2ViIEtleSBTZXQgKEpXSyBTZXQp IEZvcm1hdCJdPyBUaGlzIGlzIGFkZGluZyBhbiBleHRlbnNpb24gcG9pbnQgd2l0aCBubyBjdXJy ZW50bHkta25vd24gdXNlLCBidXQgd2l0aG91dCBhbnkgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBz aW5jZSBhbnkgZXh0ZW5zaW9uIE1VU1QgYmUgdW5kZXJzdG9vZC4gDQoNCi0tDQpKYW1lcyBNYW5n ZXINCg0K From sakimura@gmail.com Thu Aug 16 19:27:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76B911E80B8 for ; Thu, 16 Aug 2012 19:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF71RpW9goin for ; Thu, 16 Aug 2012 19:26:59 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CF11E808D for ; Thu, 16 Aug 2012 19:26:59 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3954061ghb.31 for ; Thu, 16 Aug 2012 19:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P29bvSzaai9GSb/WpLJN8hESMuMOXrzOUO9LpA73Oy8=; b=CMrMIkgPyrM0fFTSgH+R9/IB1BmYOv9aE4rMJHlRaDqqF5NbrPcfasuulbEeQEiGjx w4/tUs0FiPQ5o7WTrGCiAeYlqtrnYw9ExNbu95n4iLhvtNe9CL1hLu9ihySp+En2b4Ut RO7SZA57TS9mHhJs+hNWlgufIDHngeyPT5MXhAIxCCbk9BnagBTB4kO/rsSKcI75v/aD QZrCNpTfBV5cpurf4ccoUuspMiZczaoqhZCEgmZjo+yGwb4cGgTbqKD/w7tPkhqZEFd/ 9Y953YgJJs8uOQqlY7mp4hGq2M18AVZJjK6tbEBJ7MnOzxNA7fJEVnjr4hdP+P0LY4Rm I+KQ== MIME-Version: 1.0 Received: by 10.50.85.166 with SMTP id i6mr216324igz.71.1345170418251; Thu, 16 Aug 2012 19:26:58 -0700 (PDT) Received: by 10.64.102.39 with HTTP; Thu, 16 Aug 2012 19:26:58 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 17 Aug 2012 11:26:58 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8f3b9c41f136ba04c76ce4cd Cc: Jim Schaad , "jose-chairs@tools.ietf.org" , Harry Halpin , "jose@ietf.org" , Karen O'Donoghue Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 02:27:00 -0000 --e89a8f3b9c41f136ba04c76ce4cd Content-Type: text/plain; charset=ISO-8859-1 Thanks Mike. Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. Thoughts? Nat On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones wrote: > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally think > it would be valuable for JOSE to define a JSON private key representation. > To make this concrete, I would propose the private key representations > specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. > You'll see that doing this is very simple; it just defines two additional > members for the JWK structure for representing the private parts of > Elliptic Curve and RSA keys. This could either remain a separate spec from > JWK/JWA or be merged in, at the working group's preference. > > I had previously agreed with the position that it was not necessary for > JOSE to define private key representations because we didn't have a use > case for it. However, as I see it, the W3C WebCrypto API use case changes > things. Better for JOSE to be responsive to WebCrypto and add this simple > extension, either as a new spec or in the existing specs, than to leave > this undone, and have it potentially be an area where otherwise > standards-compliant implementations diverge, and where JSON-only solutions > are not possible. > > Finally, I'll note that the JOSE charter > http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining > private key formats. (It simply requires the definition of public key > formats and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for backwards > compatibility in some cases (just as the JOSE specs allow the use of X.509 > certificates). However, I believe it would be a shame to preclude > JSON-only solutions by not supporting key import/export in JWK format, > where such solutions make sense. > > 3) It appears to me the JWK format is stable. I believe the JWS format > is stable as well. The JWE format has known changes that will be applied > shortly, based upon working group discussions at IETF 84 in Vancouver two > weeks ago. Some JWA changes will occur that are part of the JWE changes. > I don't anticipate significant changes after that. (Making these changes > is my highest priority as JOSE editor. I'm hoping to have drafts out > containing them by the end of August, which hopefully fits well with the > WebCrypto schedule.) I write all of the above with the caveat that the > working group is, of course, free to change things as they see fit. > > I look forward to a productive discussion of this coordination request in > both working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key spec is > available at > http://self-issued.info/docs/draft-jones-jose-json-private-key.html. I > also blogged about this draft specification at > http://self-issued.info/?p=816. > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some > access to raw key material, and the issue of whether or not to use JWK or > ASN.1 as the default format came up. Two issues have come out that we'd > like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to > support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like > for backwards compatibility having some level of ASN.1 support would be > useful and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default > format in the low-level API, and having JWK as a format that can be built > on top of that in a possible high-level API. Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do you > think they are stable enough now we can reference them in our API draft at > end of August? If not, when? The W3C would like to and plan to use these > formats where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an answer > before we send our document to FPWD at end of August. > > cheers, > harry > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --e89a8f3b9c41f136ba04c76ce4cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Mike.=A0

Would it not be a good idea to mandate t= hat private key file must be encrypted? As far as I remember, one of the re= ason for not producing private key format was from the fear that developers= leave the exported keys in a insecure manner.=A0

Thoughts?=A0

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks for writing, Harry and WebCrypto WG.<= br>
1) =A0About private keys, given the WebCrypto use case, I personally think = it would be valuable for JOSE to define a JSON private key representation. = =A0To make this concrete, I would propose the private key representations s= pecified in http://tools.ietf.org/html/draft-jones-jose-jso= n-private-key. =A0You'll see that doing this is very simple; it jus= t defines two additional members for the JWK structure for representing the= private parts of Elliptic Curve and RSA keys. =A0This could either remain = a separate spec from JWK/JWA or be merged in, at the working group's pr= eference.

I had previously agreed with the position that it was not necessary for JOS= E to define private key representations because we didn't have a use ca= se for it. =A0However, as I see it, the W3C WebCrypto API use case changes = things. =A0Better for JOSE to be responsive to WebCrypto and add this simpl= e extension, either as a new spec or in the existing specs, than to leave t= his undone, and have it potentially be an area where otherwise standards-co= mpliant implementations diverge, and where JSON-only solutions are not poss= ible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg= /jose/charter/ does not preclude defining private key formats. =A0(It s= imply requires the definition of public key formats and is silent on the to= pic of private keys.)

2) =A0I agree on the likely need for WebCrypto support ASN.1 for backwards = compatibility in some cases (just as the JOSE specs allow the use of X.509 = certificates). =A0However, I believe it would be a shame to preclude JSON-o= nly solutions by not supporting key import/export in JWK format, where such= solutions make sense.

3) =A0It appears to me the JWK format is stable. =A0I believe the JWS forma= t is stable as well. =A0The JWE format has known changes that will be appli= ed shortly, based upon working group discussions at IETF 84 in Vancouver tw= o weeks ago. =A0Some JWA changes will occur that are part of the JWE change= s. =A0I don't anticipate significant changes after that. =A0(Making the= se changes is my highest priority as JOSE editor. =A0I'm hoping to have= drafts out containing them by the end of August, which hopefully fits well= with the WebCrypto schedule.) =A0I write all of the above with the caveat = that the working group is, of course, free to change things as they see fit= .

I look forward to a productive discussion of this coordination request in b= oth working groups.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best wishes= ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

P.S. =A0If you prefer, a HTML-formatted version of the private key spec is = available at http://self-issued.info/docs/draft-jone= s-jose-json-private-key.html. =A0I also blogged about this draft specif= ication at h= ttp://self-issued.info/?p=3D816.

-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org= ]
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mik= e Jones
Subject: JOSE WG request from W3C WebCrypto API

[cc'ing Mike Jones and Richard Barnes, w= ho participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some acc= ess to raw key material, and the issue of whether or not to use JWK or ASN.= 1 as the default format came up. Two issues have come out that we'd lik= e to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to suppo= rt a JOSE-format for private keys? If so, when? Or 'maybe'?

=A0 2) While we'd like encourage the use of JOSE over ASN.1, it seems l= ike for backwards compatibility having some level of ASN.1 support would be= useful and we *need* a format that allows key material (both private and public) to be exported. Folks seem to leaning towards ASN.1 as a default fo= rmat in the low-level API, and having JWK as a format that can be built on = top of that in a possible high-level API. Would that be OK?

=A0 3) How stable do you believe the JOSE formats are right now? Do you thi= nk they are stable enough now we can reference them in our API draft at end= of August? If not, when? =A0The W3C would like to and plan to use these fo= rmats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answe= r before we send our document to FPWD at end of August.

=A0 cheers,
=A0 =A0 =A0 harry




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



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en

--e89a8f3b9c41f136ba04c76ce4cd-- From ietf@augustcellars.com Fri Aug 17 00:07:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88021F8589 for ; Fri, 17 Aug 2012 00:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kYMnGEjF90L for ; Fri, 17 Aug 2012 00:07:26 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA821F854F for ; Fri, 17 Aug 2012 00:07:25 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7C7FA38EFD for ; Fri, 17 Aug 2012 00:07:24 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:35:19 +0930 Message-ID: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16R+NkZj6V892HQ2emUuPRcALC+g== Content-Language: en-us Subject: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:07:26 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Is the current text for KID sufficiently defined and understood? Room vote: 2 yes, 0 no, 1 discuss From ietf@augustcellars.com Fri Aug 17 00:07:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C30A21F857E for ; Fri, 17 Aug 2012 00:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyhijQjBcYed for ; Fri, 17 Aug 2012 00:07:26 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DD97621F854F for ; Fri, 17 Aug 2012 00:07:26 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 18C5638F0B for ; Fri, 17 Aug 2012 00:07:25 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:35:19 +0930 Message-ID: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16R5jcjjwXKxuZTwOQJftRC8WQsw== Content-Language: en-us Subject: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:07:27 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. What should be the criticality of header fields as defined by the core specification? YES - all headers fields are critical NO - all header fields are non-critical MAYBE - header fields are marked critical or criticality should be defined by the application DISCUSS - need to talk more Room vote: 2 yes, 0 no, 4 maybe, 3 discuss From ietf@augustcellars.com Fri Aug 17 00:07:28 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68F421F858E for ; Fri, 17 Aug 2012 00:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8grRZxnYYm1h for ; Fri, 17 Aug 2012 00:07:28 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3F21F858A for ; Fri, 17 Aug 2012 00:07:28 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 995CB38EFD for ; Fri, 17 Aug 2012 00:07:27 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:35:19 +0930 Message-ID: <000201cd7c46$c4c60880$4e521980$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RzXpH3rn0ITJSUeyqH05uOydIQ== Content-Language: en-us Subject: [jose] POLL: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:07:29 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Do we need to define a nonce/timestamp parameter in the base specification? Room vote: 6 yes, 0 no, 1 discuss From ietf@augustcellars.com Fri Aug 17 00:07:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5BD21F859E for ; Fri, 17 Aug 2012 00:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY6sE+j0OFFd for ; Fri, 17 Aug 2012 00:07:30 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id EE07621F859C for ; Fri, 17 Aug 2012 00:07:29 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 29B9838EFD for ; Fri, 17 Aug 2012 00:07:28 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:35:19 +0930 Message-ID: <000301cd7c46$c5b1c810$51155830$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RvP41OcmDOmiQ/+7c8EuZk2YUA== Content-Language: en-us Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:07:30 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should SHA1 be the default parameters for these algorithms? Room vote: 0 yes, 5 no, 3 discuss From ietf@augustcellars.com Fri Aug 17 00:07:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FE221F858A for ; Fri, 17 Aug 2012 00:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2DAqOIax46p for ; Fri, 17 Aug 2012 00:07:31 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 80CD921F854F for ; Fri, 17 Aug 2012 00:07:31 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id AAF5638EFD for ; Fri, 17 Aug 2012 00:07:30 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:35:19 +0930 Message-ID: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RpZMp/Klr1eRRvihicMdAk2Fbw== Content-Language: en-us Subject: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:07:32 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should support be mandated to allow an algorithm to be both a string and an object Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"} Room vote: 1 yes, 5 no, 4 discuss From jimsch@augustcellars.com Fri Aug 17 00:08:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DD721F857E for ; Fri, 17 Aug 2012 00:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPAbsP3xTprZ for ; Fri, 17 Aug 2012 00:08:01 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id B671421F8589 for ; Fri, 17 Aug 2012 00:08:01 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (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 8139D38EF2 for ; Fri, 17 Aug 2012 00:08:00 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:36:32 +0930 Message-ID: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RidVje2mY8QHQcCUMfGKzpxf6g== Content-Language: en-us Subject: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:08:03 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we add the ability to have a randomly generated MAC key protected by a different key? The other key could be either a pre-shared symmetric key or a public key. Room vote: 3 yes, 5 no, 3 discuss From jimsch@augustcellars.com Fri Aug 17 00:08:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9C121F858A for ; Fri, 17 Aug 2012 00:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPCTYfeVOykz for ; Fri, 17 Aug 2012 00:08:04 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8C721F857E for ; Fri, 17 Aug 2012 00:08:04 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (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 4D30D38EF2; Fri, 17 Aug 2012 00:08:01 -0700 (PDT) From: "Jim Schaad" To: "Richard Barnes" Date: Fri, 17 Aug 2012 16:36:32 +0930 Message-ID: <000401cd7c46$d9d803e0$8d880ba0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16PoZz5DJVcfuCTOmzFCWSX3JJRQ== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Additional Usage Case X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:08:04 -0000 Richard, After talking with Bob at the last F2F meeting, I think I got my usage case fleshed out. I don't have access to your draft at the moment so I can't harmonize with how things look, but I am sure you will be able to X.X Constrained Devices There is a class of devices that are starting to come online that need to be able to do secure communications, but are very constrained both in terms of power and in terms of memory. One additional constraint is that these devices have minimal cryptographic functionality. Thus these devices have exponentiation and AES block encryption/decryption, but they do not have any hash functions built nor do they have enough memory for a software implementation. As such they can do EC-DH key agreement, but use an AES based KDF function for generating keys for encryption/decryption or MAC operations. One side effect of not having any hash functionality is that they have no ability at present to use TLS for any message protection. These devices are power constrained; this means that every byte that is transmitted over the net to another device is a drain. For this reason the smaller the message the better, the environment that they are working in however is better than that of the HTTP header in that they can transmit binary data without any problems. Thus for these devices there is no requirement that the data be converted to base64 prior to transmission. This is actually an undesirable step as it increases the size of the message to be transmitted. A better method of encoding the headers would be to use a length prefixed format for each of the pieces as this would produce a smaller transmission block. These devices would use UDP or the output of the CORE working group for transmission of data thus leading to a hard limit on the size of messages in the case of UDP. For these devices the messages are going to be extremely constrained, as such this means that allowing for a fixed order of the headers and any content fields is highly desirable. Having a fixed order simplifies the parsing as does the ability to specify a canonicalization of the encoding to minimize the number and location of characters that are not needed for parsing the fields of a JSON structure. Any devices operating in this environment would need to define some new algorithms as they will be operating in a static-static EC-DH mode (combined with constrained environments, this can provide some assurance on who originates the message) and a new AES based KDF function to move from the agreed secret to the content encryption key or MAC key used for protection on the message. This would also require defining a new MAC algorithm which allows for key derivation but no content encryption. It is possible that these environments would be fully satisfied with AES-GCC encryption mode however. These devices would use internal methods for deciding which keys can be trusted and what they are named. This means that all keys can be easily identified for all parties. From ietf@augustcellars.com Fri Aug 17 00:09:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDC421F858A for ; Fri, 17 Aug 2012 00:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXhJXmV6WaHm for ; Fri, 17 Aug 2012 00:09:00 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 61DE621F8589 for ; Fri, 17 Aug 2012 00:09:00 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A506A38EFD for ; Fri, 17 Aug 2012 00:08:57 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:37:31 +0930 Message-ID: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RKHtofAZQFAhQTSskRTxljUg5w== Content-Language: en-us Subject: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:09:00 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we change the current treatment of AES-CBC + HMAC to use a single content encryption name. Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: {"enc":"AES128CBC+HS256+CS256"} Exact name is still to be determined Room vote: 12 yes, 2 no, 0 discuss From ietf@augustcellars.com Fri Aug 17 00:09:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC721F8596 for ; Fri, 17 Aug 2012 00:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68oSFC77VMmO for ; Fri, 17 Aug 2012 00:09:13 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 94ADF21F8589 for ; Fri, 17 Aug 2012 00:09:13 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 596D138F0B for ; Fri, 17 Aug 2012 00:09:04 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:37:31 +0930 Message-ID: <008f01cd7c46$ff2210f0$fd6632d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RYqUXu1nDxr2TtqRTWT/b00wkA== Content-Language: en-us Subject: [jose] POLL: Add key wrap functionality for EC X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:09:14 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Do we need to require the ability for doing a key agree followed by a key wrap to get the CMK? Current process uses the output of the key agree as the CMK, saying yes would allow for both methods to operate. Room vote: 12 yes, 1 no, 1 discuss From ietf@augustcellars.com Fri Aug 17 00:09:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DFF21F8546 for ; Fri, 17 Aug 2012 00:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXli8P0HwM2X for ; Fri, 17 Aug 2012 00:09:13 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2A21F858E for ; Fri, 17 Aug 2012 00:09:02 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id F2A4938EFD for ; Fri, 17 Aug 2012 00:09:00 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:37:31 +0930 Message-ID: <008401cd7c46$fc8a9d30$f59fd790$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RmOdGziwgjMHRrelLF7FQW/lZA== Content-Language: en-us Subject: [jose] POLL: Add Key Usage "both" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:09:14 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Do we need to add the string "both" as a key usage? Room vote: 1 yes, 11 no, 0 discuss From ietf@augustcellars.com Fri Aug 17 00:09:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F121F8598 for ; Fri, 17 Aug 2012 00:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-RzkmUMr-Sd for ; Fri, 17 Aug 2012 00:09:13 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9470221F857E for ; Fri, 17 Aug 2012 00:09:13 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E48C938F07 for ; Fri, 17 Aug 2012 00:09:02 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:37:31 +0930 Message-ID: <008b01cd7c46$fda69480$f8f3bd80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16ReK1E33qYPkKRxqdpZpHt1rNEQ== Content-Language: en-us Subject: [jose] POLL: Remove no key wrap for key agreement algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:09:14 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step? This would remove the ability to go directly and would require an intervening key wrap step. Room vote: 1 yes, 6 no, 0 discuss From ietf@augustcellars.com Fri Aug 17 00:09:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F221F8596 for ; Fri, 17 Aug 2012 00:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgWTKvC3sEDQ for ; Fri, 17 Aug 2012 00:09:14 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DF6C921F8593 for ; Fri, 17 Aug 2012 00:09:13 -0700 (PDT) Received: from Tobias (122-49-181-93.ip.adam.com.au [122.49.181.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 738BD38F2B for ; Fri, 17 Aug 2012 00:09:07 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 17 Aug 2012 16:37:31 +0930 Message-ID: <009601cd7c47$005bf080$0113d180$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16RSs5cCtx6o7zTkybt2/fW57F8w== Content-Language: en-us Subject: [jose] POLL: Add new ECB Key wrap function X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:09:14 -0000 If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we add a new ECB key wrap function to the algorithm specification? This action would define a second key wrap function the current AES key wrap would not go away Room vote: 2 yes, 10 no, 0 discuss From hannes.tschofenig@gmx.net Fri Aug 17 06:23:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A912621F84B3 for ; Fri, 17 Aug 2012 06:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLgpEBM0+2mh for ; Fri, 17 Aug 2012 06:23:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 886F321F84A6 for ; Fri, 17 Aug 2012 06:23:19 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 13:23:18 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp069) with SMTP; 17 Aug 2012 15:23:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+mbKAh3eSmZGVJrW0NoNFtzTe8YGiNf+0iyv9wzC DkYXUsDgP+SkVn Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <000401cd7c46$d9d803e0$8d880ba0$@augustcellars.com> Date: Fri, 17 Aug 2012 16:23:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0C457612-5AB8-4F00-81B3-2FBB3E2A813B@gmx.net> References: <000401cd7c46$d9d803e0$8d880ba0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Richard Barnes , Hannes Tschofenig , jose@ietf.org Subject: Re: [jose] Additional Usage Case X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:23:20 -0000 Hi Jim,=20 On Aug 17, 2012, at 10:06 AM, Jim Schaad wrote: > Richard, >=20 > After talking with Bob at the last F2F meeting, I think I got my usage = case > fleshed out. I don't have access to your draft at the moment so I = can't > harmonize with how things look, but I am sure you will be able to >=20 >=20 > X.X Constrained Devices >=20 > There is a class of devices that are starting to come online that need = to be > able to do secure communications, but are very constrained both in = terms of > power and in terms of memory. ... and later in the text you add bandwidth constraints as well.=20 > One additional constraint is that these > devices have minimal cryptographic functionality. because of computational limitations or because of code size?=20 > Thus these devices have > exponentiation and AES block encryption/decryption, but they do not = have any > hash functions built nor do they have enough memory for a software > implementation. It's surprising that they have PK-based capabilities but no support for = a hash function... > As such they can do EC-DH key agreement, but use an AES > based KDF function for generating keys for encryption/decryption or = MAC > operations. One side effect of not having any hash functionality is = that > they have no ability at present to use TLS for any message protection. You are essentially saying that it would be good to have the ability to = use a single cryptographic primitive, namely AES, for constrained = devices.=20 >=20 > These devices are power constrained; this means that every byte that = is > transmitted over the net to another device is a drain. For this = reason the > smaller the message the better, the environment that they are working = in > however is better than that of the HTTP header in that they can = transmit > binary data without any problems. Thus for these devices there is no > requirement that the data be converted to base64 prior to = transmission. > This is actually an undesirable step as it increases the size of the = message > to be transmitted. A better method of encoding the headers would be = to use > a length prefixed format for each of the pieces as this would produce = a > smaller transmission block. These devices would use UDP or the output = of > the CORE working group for transmission of data thus leading to a hard = limit > on the size of messages in the case of UDP. This is essentially the story the CoAP guys are presenting us. HTTP = (with TCP) is too expensive and therefore they have to design something = new that is based on UDP and consumes less bandwidth.=20 >=20 > For these devices the messages are going to be extremely constrained, = as > such this means that allowing for a fixed order of the headers and any > content fields is highly desirable. Having a fixed order simplifies = the > parsing as does the ability to specify a canonicalization of the = encoding to > minimize the number and location of characters that are not needed for > parsing the fields of a JSON structure. Maybe JSON is too constrained for those scenarios as well.=20 (I have already hear that argument and those folks have been interested = in standardizing a binary format.) >=20 > Any devices operating in this environment would need to define some = new > algorithms as they will be operating in a static-static EC-DH mode = (combined > with constrained environments, this can provide some assurance on who > originates the message) and a new AES based KDF function to move from = the > agreed secret to the content encryption key or MAC key used for = protection > on the message. > This would also require defining a new MAC algorithm which > allows for key derivation but no content encryption. It is possible = that > these environments would be fully satisfied with AES-GCC encryption = mode > however. I am not sure a new algorithm is required. Aren't existing algorithms = providing this support already?=20 >=20 > These devices would use internal methods for deciding which keys can = be > trusted and what they are named. This means that all keys can be = easily > identified for all parties. Certainly.=20 Ciao Hannes >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From jricher@mitre.org Fri Aug 17 07:15:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8517F21F8440 for ; Fri, 17 Aug 2012 07:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxlnHLGmGRYB for ; Fri, 17 Aug 2012 07:15:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A97FF21F842B for ; Fri, 17 Aug 2012 07:15:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 86EB521C00F9; Fri, 17 Aug 2012 10:15:23 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6FC7821C0103; Fri, 17 Aug 2012 10:15:23 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 17 Aug 2012 10:15:23 -0400 Message-ID: <502E51A5.5080401@mitre.org> Date: Fri, 17 Aug 2012 10:13:57 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Nat Sakimura References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070008000309050901070906" X-Originating-IP: [129.83.31.58] Cc: "jose-chairs@tools.ietf.org" , Harry Halpin , Karen O'Donoghue , Jim Schaad , Mike Jones , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:15:26 -0000 --------------070008000309050901070906 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way. I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well. However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it. -- Justin [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ On 08/16/2012 10:26 PM, Nat Sakimura wrote: > Thanks Mike. > > Would it not be a good idea to mandate that private key file must be > encrypted? As far as I remember, one of the reason for not producing > private key format was from the fear that developers leave the > exported keys in a insecure manner. > > Thoughts? > > Nat > > On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones > > wrote: > > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally > think it would be valuable for JOSE to define a JSON private key > representation. To make this concrete, I would propose the > private key representations specified in > http://tools.ietf.org/html/draft-jones-jose-json-private-key. > You'll see that doing this is very simple; it just defines two > additional members for the JWK structure for representing the > private parts of Elliptic Curve and RSA keys. This could either > remain a separate spec from JWK/JWA or be merged in, at the > working group's preference. > > I had previously agreed with the position that it was not > necessary for JOSE to define private key representations because > we didn't have a use case for it. However, as I see it, the W3C > WebCrypto API use case changes things. Better for JOSE to be > responsive to WebCrypto and add this simple extension, either as a > new spec or in the existing specs, than to leave this undone, and > have it potentially be an area where otherwise standards-compliant > implementations diverge, and where JSON-only solutions are not > possible. > > Finally, I'll note that the JOSE charter > http://datatracker.ietf.org/wg/jose/charter/ does not preclude > defining private key formats. (It simply requires the definition > of public key formats and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for > backwards compatibility in some cases (just as the JOSE specs > allow the use of X.509 certificates). However, I believe it would > be a shame to preclude JSON-only solutions by not supporting key > import/export in JWK format, where such solutions make sense. > > 3) It appears to me the JWK format is stable. I believe the JWS > format is stable as well. The JWE format has known changes that > will be applied shortly, based upon working group discussions at > IETF 84 in Vancouver two weeks ago. Some JWA changes will occur > that are part of the JWE changes. I don't anticipate significant > changes after that. (Making these changes is my highest priority > as JOSE editor. I'm hoping to have drafts out containing them by > the end of August, which hopefully fits well with the WebCrypto > schedule.) I write all of the above with the caveat that the > working group is, of course, free to change things as they see fit. > > I look forward to a productive discussion of this coordination > request in both working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key > spec is available at > http://self-issued.info/docs/draft-jones-jose-json-private-key.html. > I also blogged about this draft specification at > http://self-issued.info/?p=816. > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org ] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org > ; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires > some access to raw key material, and the issue of whether or not > to use JWK or ASN.1 as the default format came up. Two issues have > come out that we'd like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan > to support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it > seems like for backwards compatibility having some level of ASN.1 > support would be useful and we *need* a format that allows key > material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a > default format in the low-level API, and having JWK as a format > that can be built on top of that in a possible high-level API. > Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do > you think they are stable enough now we can reference them in our > API draft at end of August? If not, when? The W3C would like to > and plan to use these formats where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an > answer before we send our document to FPWD at end of August. > > cheers, > harry > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------070008000309050901070906 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it.

 -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:
Thanks Mike. 

Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. 

Thoughts? 

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks for writing, Harry and WebCrypto WG.

1)  About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation.  To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.  You'll see that doing this is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.  This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference.

I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it.  However, as I see it, the W3C WebCrypto API use case changes things.  Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining private key formats.  (It simply requires the definition of public key formats and is silent on the topic of private keys.)

2)  I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates).  However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3)  It appears to me the JWK format is stable.  I believe the JWS format is stable as well.  The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago.  Some JWA changes will occur that are part of the JWE changes.  I don't anticipate significant changes after that.  (Making these changes is my highest priority as JOSE editor.  I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.)  I write all of the above with the caveat that the working group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in both working groups.

                                Best wishes,
                                -- Mike

P.S.  If you prefer, a HTML-formatted version of the private key spec is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html.  I also blogged about this draft specification at http://self-issued.info/?p=816.

-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org]
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'?

  2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when?  The W3C would like to and plan to use these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August.

  cheers,
      harry




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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



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

--------------070008000309050901070906-- From jricher@mitre.org Fri Aug 17 07:40:06 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E895621F85D7 for ; Fri, 17 Aug 2012 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmYHzzEakmRd for ; Fri, 17 Aug 2012 07:40:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6FED721F85B4 for ; Fri, 17 Aug 2012 07:40:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA22421B1D39 for ; Fri, 17 Aug 2012 10:40:05 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B324821B1D21 for ; Fri, 17 Aug 2012 10:40:05 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 17 Aug 2012 10:40:05 -0400 Message-ID: <502E576F.8010805@mitre.org> Date: Fri, 17 Aug 2012 10:38:39 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> In-Reply-To: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:40:07 -0000 No, this requires extra internal parsing on the part of anyone processing it, for no good reason that I can see. Use the JSON structure for what it's good at: structuring pieces of information together. Don't invent a new format for that. -- Justin On 08/17/2012 03:07 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a single > content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} > New: {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Fri Aug 17 08:02:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B556A21F84F9 for ; Fri, 17 Aug 2012 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMYvCZIyO5DG for ; Fri, 17 Aug 2012 08:02:18 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 178F821F8450 for ; Fri, 17 Aug 2012 08:02:18 -0700 (PDT) Received: by ggnh4 with SMTP id h4so4492952ggn.31 for ; Fri, 17 Aug 2012 08:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XmsO2L9NzGU6+cu6PzoH7fS4HvvmjcQ/waxd8tv/3vc=; b=x/L7p74lCM+e3LEy3Ff3Bh/flQgpUGFHIQFxiVzNR6GpigoIRMyFgh5ndzMBLCErWs JnG1g1Yh404STpvAzfE8ZP45Q/TAo72Tj3T5HkgKoQU+0KkRV9AxcZkCt07rvgjPuFx+ d1sYQPNWFBTrnt1R9XFBLpChW75FKFsA1K2App9qLR31IUNijvhlP2YqcPg/uj/4P3v6 grUDxBg696jB3CsFyp5rNr0Ae8lOyn+629EwWP8fetA7tvqqYoHlsC64FTUgh8cwmYpB xTiNSjItwiShmyaTB0eZyNZGiTd5WodJzRdkogt5IgSi7+ihBCDYN3yzUj+cmyZkx/Lm e4aw== Received: by 10.66.83.234 with SMTP id t10mr10124678pay.39.1345215737198; Fri, 17 Aug 2012 08:02:17 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rm9sm5059437pbc.72.2012.08.17.08.02.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 08:02:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> Date: Fri, 17 Aug 2012 08:02:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: <05C6CB94-0417-4A7E-BDB9-85CA4FF72969@gmail.com> References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:02:18 -0000 NO On Aug 17, 2012, at 12:05 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should support be mandated to allow an algorithm to be both a string and an > object > > Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", > "kid":"12345"} > > > Room vote: 1 yes, 5 no, 4 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Fri Aug 17 08:02:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3EE21E8034 for ; Fri, 17 Aug 2012 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bswAEgSCTIFN for ; Fri, 17 Aug 2012 08:02:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6311E80D5 for ; Fri, 17 Aug 2012 08:02:42 -0700 (PDT) Received: by dakr19 with SMTP id r19so928147dak.31 for ; Fri, 17 Aug 2012 08:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=E17MHvieYpGqzBrjc5WB62WmraVka8tJrFR+hvF5/mw=; b=ZVZTfHmR38rl6a8YPaCM/UIXqKLYDangW6MZBL7WezqULHjrGxBc/x6EJvoKoLPMdN QP27qAChXh37Kw/T9mzmoT2OpAy5oJnv/iRKRigUNvuBuCwmsKXAwFI6bi9zQa63uGAz /KAvbyVwYY8Z8TNhaVN1hFeEuMRJlUN6cul/uQKyHzWxofbjijFg0RBKraK2l9mTtNo3 kK5adkZmzgbGZqbih2iL9kVTZ5NDI7ZQLjy5qMVlgHWTWm4/+xRIcu++LrY32iwztT/Q y2bItL5rq0eJ7x9soYs0xyLifYiG9uHZzM4WCWpqeNGUhgEdFTYZaa2YLrcZd4UhIqeL Lv0w== Received: by 10.68.212.98 with SMTP id nj2mr11994544pbc.138.1345215762140; Fri, 17 Aug 2012 08:02:42 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rm9sm5059437pbc.72.2012.08.17.08.02.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 08:02:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> Date: Fri, 17 Aug 2012 08:02:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:02:45 -0000 DISCUSS On Aug 17, 2012, at 12:06 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we add the ability to have a randomly generated MAC key protected by > a different key? The other key could be either a pre-shared symmetric key > or a public key. > > > > Room vote: 3 yes, 5 no, 3 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Fri Aug 17 08:03:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DDA21F8450 for ; Fri, 17 Aug 2012 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WdKfZCstPwp for ; Fri, 17 Aug 2012 08:03:15 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41E8121E8034 for ; Fri, 17 Aug 2012 08:03:15 -0700 (PDT) Received: by dakr19 with SMTP id r19so928348dak.31 for ; Fri, 17 Aug 2012 08:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eVfP/g/xHgsXm5gGYEb0N6MfQ9ecuH77YLLIUkcxC3k=; b=V116xUUG3tIpwhOq6whRabkJKKJ2ZbuhHKxNCp+lx9tgeI7d/h5MZ36ELYu6cLybnM GwB5qjVCC3BaPEKrj+L1hlyb1c0sBDIANuUzmJmdZdjnnFRtLd+7WOsMp+fONcRdjWUk eBnR73ZaT4IhOHfLR9+PLw2pGcoluUeWr7MP2u+c0wQ+vVSY8SIaB5UqmGqwanSPs/aE /a1RkPqxz1JGMKmutY/Mtuof26DY/0paViUzxsiflXNh3w1dftJ7bzDiRq0cRSVpgeag YaDjaesvutpWmvQRcLCwKtc8/oE3vTf5OnQrixae+W6j4fiLSkm9NwJvD3z/axSar+1P btmw== Received: by 10.68.234.169 with SMTP id uf9mr5445782pbc.105.1345215794748; Fri, 17 Aug 2012 08:03:14 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rm9sm5059437pbc.72.2012.08.17.08.03.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 08:03:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <008f01cd7c46$ff2210f0$fd6632d0$@augustcellars.com> Date: Fri, 17 Aug 2012 08:03:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <00CD2040-2C49-48EE-815D-15F5A466068C@gmail.com> References: <008f01cd7c46$ff2210f0$fd6632d0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] POLL: Add key wrap functionality for EC X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:03:16 -0000 DISCUSS On Aug 17, 2012, at 12:07 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Do we need to require the ability for doing a key agree followed by a key > wrap to get the CMK? > > Current process uses the output of the key agree as the CMK, saying yes > would allow for both methods to operate. > > Room vote: 12 yes, 1 no, 1 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Fri Aug 17 08:03:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E9121F8433 for ; Fri, 17 Aug 2012 08:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TavaI5+j7WT for ; Fri, 17 Aug 2012 08:03:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1BC21F843F for ; Fri, 17 Aug 2012 08:03:44 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3558041pbb.31 for ; Fri, 17 Aug 2012 08:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=C5fK8g3/NuFKQ+MWVppWPxbbUgNmkaBL1tWLOq03Fcs=; b=Ocj/Pxf596rL2JZMQYMiy8AFjbDERchpFPgeVvcPB0fPVrQ9Chu6ISA5yX/9iavdC3 PQUpgxMLlkI5pqQ9TkgLMbfExe56WJM5zNyAMbpv0vNJ8T7BCtMNrEApvfNVR48wLqM2 19WZKFt8cyDSRo/lDca3kknGLB8ZeYYn2lHcwfadp4FUsY7SHZiBCJtapIlquLMlrds+ P+ySqhk1m/e2thJpvPTO13FI4yDr7P6lcjL43Fra0g9jwqqF7Xd9HkjUYLOl2sLwMLp1 SpJZCwKeAofWK/r3y2ahNe9T3KpILBRbgaehirnK6uhWeKtudO6YUcNp47UlozWu1JQy TgWw== Received: by 10.66.90.67 with SMTP id bu3mr10179388pab.26.1345215823877; Fri, 17 Aug 2012 08:03:43 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rm9sm5059437pbc.72.2012.08.17.08.03.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 08:03:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <008401cd7c46$fc8a9d30$f59fd790$@augustcellars.com> Date: Fri, 17 Aug 2012 08:03:34 -0700 Content-Transfer-Encoding: 7bit Message-Id: <01DC0902-2983-4F2E-B074-16807BB3B2F4@gmail.com> References: <008401cd7c46$fc8a9d30$f59fd790$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] POLL: Add Key Usage "both" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:03:57 -0000 NO On Aug 17, 2012, at 12:07 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Do we need to add the string "both" as a key usage? > > > > Room vote: 1 yes, 11 no, 0 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Fri Aug 17 08:05:34 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435A911E80A5 for ; Fri, 17 Aug 2012 08:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3PcNUFfP5KA for ; Fri, 17 Aug 2012 08:05:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8610221F842B for ; Fri, 17 Aug 2012 08:05:32 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3560299pbb.31 for ; Fri, 17 Aug 2012 08:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XBSkMIqRKNm0ScaDy6cq2mN2zhmEn58HXudsZj2h5ko=; b=XnmU6A8Zm3I47QcY7k+FDiuwQ7LmQVJq+uux88fnP1BwQiftqPgrl7YUVYy5mfrbu/ xYRS3D0FgvPR4/gnPV54CEXge6QUCpRob2PTc1Titl0AjnF/yn4hNPMAVO/K6o8K9cfE MRcTmkkcNngN3vBhhiNeKt+zXjwA9fT2wUlJsWZXAT2wK1ahG9BBnaRDh9ehXwuXJTPj fmV5WQsgUlDIjUcpMHFfXFg00k9CycDK8+Qw2M2r85mz9pMTMH4PBM4gQkkKjWpGo5nF /xIE2ofT92mfnd8tjaouEBtdDddPfBWxepCXGS6bYh+wUE8FbI2hn3Oz4Gmy54wWzrH3 RBPA== Received: by 10.66.83.8 with SMTP id m8mr10116144pay.48.1345215932175; Fri, 17 Aug 2012 08:05:32 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rn4sm5076229pbb.51.2012.08.17.08.05.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 08:05:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> Date: Fri, 17 Aug 2012 08:05:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5A02490D-9A59-4CEC-81E2-88A7C3B05978@gmail.com> References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:05:34 -0000 DISCUSS On Aug 17, 2012, at 12:07 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a single > content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} > New: {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Aug 17 09:23:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3343A11E80D1 for ; Fri, 17 Aug 2012 09:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=1.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30jJo8t1oMnO for ; Fri, 17 Aug 2012 09:23:36 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9B81211E80A5 for ; Fri, 17 Aug 2012 09:23:36 -0700 (PDT) Received: from mail129-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Aug 2012 16:23:35 +0000 Received: from mail129-tx2 (localhost [127.0.0.1]) by mail129-tx2-R.bigfish.com (Postfix) with ESMTP id EE553C034D; Fri, 17 Aug 2012 16:23:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail129-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail129-tx2 (localhost.localdomain [127.0.0.1]) by mail129-tx2 (MessageSwitch) id 1345220613591809_26352; Fri, 17 Aug 2012 16:23:33 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.252]) by mail129-tx2.bigfish.com (Postfix) with ESMTP id 8D70180195; Fri, 17 Aug 2012 16:23:33 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Aug 2012 16:23:32 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Fri, 17 Aug 2012 16:23:22 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters Thread-Index: Ac18lJzBZ7lrugc/SlOdnZgODbmGPw== Date: Fri, 17 Aug 2012 16:23:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366797E0F@TK5EX14MBXC284.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.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:23:37 -0000 I believe that the results below are recorded incorrectly. I know that I p= ersonally voted that we use the default parameters as widely deployed (SHA-= 1), so the results below can not be right. I believe that the results were= likely actually: Room vote: 5 yes, 0 no, 3 discuss -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 12:05 AM To: jose@ietf.org Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Should SHA1 be the default parameters for these algorithms? Room vote: 0 yes, 5 no, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Aug 17 10:08:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4B11E80A5 for ; Fri, 17 Aug 2012 10:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.324 X-Spam-Level: X-Spam-Status: No, score=-5.324 tagged_above=-999 required=5 tests=[AWL=1.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AquLx2YpI9QT for ; Fri, 17 Aug 2012 10:08:01 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id BB12111E809B for ; Fri, 17 Aug 2012 10:08:00 -0700 (PDT) Received: from mail39-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Aug 2012 17:08:00 +0000 Received: from mail39-tx2 (localhost [127.0.0.1]) by mail39-tx2-R.bigfish.com (Postfix) with ESMTP id 1AC222402F4; Fri, 17 Aug 2012 17:08:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zz9371Ic89bh148cI542Mc857hzz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail39-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail39-tx2 (localhost.localdomain [127.0.0.1]) by mail39-tx2 (MessageSwitch) id 1345223278738125_13687; Fri, 17 Aug 2012 17:07:58 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.244]) by mail39-tx2.bigfish.com (Postfix) with ESMTP id B150D2600E5; Fri, 17 Aug 2012 17:07:58 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Aug 2012 17:07:58 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 17 Aug 2012 17:07:57 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: private keys, leading zeros Thread-Index: AQHNe0ihP+YmMegBLkyGUSrfCtn07pdeNHxA Date: Fri, 17 Aug 2012 17:07:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366797EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FA90743E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA90743E@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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366797EADTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] private keys, leading zeros X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:08:02 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366797EADTK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVwbGllcyBpbmxpbmUuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE1LCAyMDEyIDU6NDcgUE0NClRvOiBNaWtlIEpvbmVz OyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBwcml2YXRlIGtleXMsIGxlYWRpbmcgemVyb3MNCg0K DQoNCk1pa2UsDQoNCg0KDQpUaGFua3MgZm9yIG1ha2luZyB0aGUgZWZmb3J0IHRvIHByb2R1Y2Ug YSBkcmFmdDoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1q c29uLXByaXZhdGUta2V5DQoNCg0KDQpZb3XigJlyZSB3ZWxjb21lLiA7LSkNCg0KDQoNCkZvdXIg Y29tbWVudHM6DQoNCg0KDQoxLg0KDQpZb3VyIGNob2ljZSB0byBleHRlbmQgdGhlIHB1YmxpYyBr ZXkgZm9ybWF0IHRvIGFsc28gaG9sZCB0aGUgcHJpdmF0ZSBrZXkgaW5mbyBtaWdodCBoYXZlIHNv bWUgaW50ZXJlc3RpbmcgY29uc2VxdWVuY2VzLiBJdCBzdWdnZXN0cyB5b3UgY2FuIGhhdmUgYSBz aW5nbGUgZmlsZSAob3Igc2luZ2xlIEpTT04gb2JqZWN0KSB0aGF0IGNhbiBiZSB1c2VkIGJ5IHRv b2xzIHRoYXQgbmVlZHMgYSBwdWJsaWMga2V5LCBhbmQgYnkgdG9vbHMgdGhhdCBuZWVkIGEgcHJp dmF0ZSBrZXkuIEhvd2V2ZXIsIEkgZG91YnQgdGhhdCBpcyB2ZXJ5IGdvb2QgcHJhY3RpY2UuIEl0 IGp1c3QgYWRkcyBhIHJpc2sgdGhhdCBhIHByaXZhdGUga2V5IGlzIGluYWR2ZXJ0ZW50bHkgZXhw b3NlZCB3aGVyZSBpdCBzaG91bGRuJ3QgYmUuDQoNCg0KDQpQZXJoYXBzIHRoZSBmb2xsb3dpbmcg c29ydCBvZiBmb3JtYXQgd291bGQgYmUgYmV0dGVyOg0KDQogIHsNCg0KICAgICJwdWJsaWMiOnsi YWxnIjoiLi4ufSwNCg0KICAgICJwcml2YXRlIjp7ImQiOi4uLn0NCg0KICB9DQoNCg0KDQpGb3Ig d2hhdCBpdOKAmXMgd29ydGgsIGhhdmluZyBhIGZvcm1hdCB0aGF0IGNhbiByZXByZXNlbnQgZWl0 aGVyIHB1YmxpYyBvciBwdWJsaWMvcHJpdmF0ZSBzZWVtcyB0byBiZSBmYWlybHkgY29tbW9uIHBy YWN0aWNlIGZvciBjcnlwdG8gQVBJcy4gIEZvciBpbnN0YW5jZSwgc2VlIGh0dHA6Ly9tc2RuLm1p Y3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9zeXN0ZW0uc2VjdXJpdHkuY3J5cHRvZ3JhcGh5LmNu Z2tleWJsb2Jmb3JtYXQuYXNweC4gIEkgYmVsaWV2ZSB0aGF0IHNpbWlsYXIgZnVuY3Rpb25zIGFy ZSBhbHNvIGF2YWlsYWJsZSBmb3IgSmF2YSwgZXRjLg0KDQoNCg0KMi4NCg0KVGhlIHJ1bGUgdGhh dCBpbnRlZ2VycyBNVVNUIG5vdCBiZSBzaG9ydGVuZWQgaWYgdGhleSBoYXZlIGxlYWRpbmcgMCdz IGlzIHNpbGx5LiBJdCBpbXBsaWVzIHlvdSBjYW5ub3QgZW5jb2RlIGFuIGludGVnZXIgd2l0aG91 dCBrbm93aW5nIGEgbGFyZ2VyIGNvbnRleHQgKGVnIHlvdSBjYW5ub3QgZW5jb2RlIGQgd2l0aG91 dCBzcGVjaWZ5aW5nIG4sIGluIHRoZSBjb250ZXh0IG9mIGFuIFJTQSBrZXkpLiBUaGlzIHJ1bGUg YXBwbGllcyB0byB0aGUgcHJpdmF0ZSBleHBvbmVudCwgYnV0IHRoZSBvcHBvc2l0ZSBydWxlIGFw cGxpZXMgdG8gdGhlIHB1YmxpYyBleHBvbmVudC4gWXVjay4NCg0KDQoNCkVpdGhlciBhbHdheXMg Zm9yYmlkZGluZyBsZWFkaW5nIHplcm9zLCBvciBhbHdheXMgYWxsb3dpbmcgdGhlbSAoc28gcmVj ZWl2ZXJzIE1VU1Qgc3VwcG9ydCB0aGVtKSwgd291bGQgYmUgbXVjaCBiZXR0ZXIgcnVsZXMuDQoN Cg0KDQpUaGlzIGxhbmd1YWdlIHdhcyBhY3R1YWxseSBqdXN0IGNvcGllZCBmcm9tIEpXSy4gIFRo ZSBnb2FsIGlzIHRvIGZhY2lsaXRhdGUgZGlyZWN0IGNvbnZlcnNpb24gZnJvbSB0aGUgYmFzZTY0 dXJsIGVuY29kZWQgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBieXRlIGFycmF5cyB0byB0aGUgYnl0 ZSBhcnJheXMgZm9yIHRoZSBrZXkgdmFsdWVzLCB3aXRoIG5vIOKAnHNoaWZ0aW5n4oCdIG9yIOKA nHByZXBlbmRpbmfigJ0gcmVxdWlyZWQuICBNYW55IGNyeXB0byBBUElzIHdpbGwgZXhwZWN0IGJ5 dGUgYXJyYXlzIG9mIHNwZWNpZmljIGxlbmd0aHMsIHRoYXQgaW5jbHVkZSB0aGUgbGVhZGluZyB6 ZXJvcy4gIEl0IHNlZW1lZCBiZXR0ZXIgdG8gbWFuZGF0ZSB0aGF0IHRoZSBsZWFkaW5nIHplcm9z IGJlIGluY2x1ZGVkIHNvIHRoYXQgdGhlIHJlc3VsdGluZyBieXRlIGFycmF5cyBjYW4gYmUgdXNl ZCBhcy1pcywgcmF0aGVyIHRoYW4gcG90ZW50aWFsbHkgaGF2aW5nIHRvIHByZXBlbmQgdGhlbSBp ZiB0aGV5IGFyZSBtaXNzaW5nIGJlZm9yZSB1c2luZyB0aGUgYnl0ZSBhcnJheS4NCg0KDQoNClRo YXQgYmVpbmcgc2FpZCwgaWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlcyB0byBjaGFuZ2UgdGhp cyB0byBzYXkgdGhhdCBsZWFkaW5nIHplcm9zIG1heSBiZSBvbWl0dGVkLCB3ZSBjb3VsZCBkbyB0 aGF0LCBhbHRob3VnaCBpdCB3b3VsZCBtZWFuIHRoYXQgaW1wbGVtZW50YXRpb25zIGhhdmUgbW9y ZSB0byBkbyB3aGVuIGltcG9ydGluZyBrZXlzLg0KDQoNCg0KSSBqdXN0IG5vdGljZWQgdGhlICJN VVNUIG5vdCBvbWl0IGxlYWRpbmcgMCdzIiBydWxlIGFwcGxpZXMgdG8gdGhlIFJTQSBtb2R1bHVz IGluIEpXQSAoc2VjdGlvbiA1LjMuMSAibW9kIiBNb2R1bHVzIFBhcmFtZXRlcikuIFRoZSBydWxl IGlzIGV2ZW4gc2lsbGllciBpbiB0aGlzIGNhc2UuIEl0IGVmZmVjdGl2ZWx5IHNheXMgInRoZSBt b2R1bHVzIE1VU1QgYmUgZW5jb2RlZCBhcyB0aGUgc2l6ZSBzb21lb25lL3NvbWV0aGluZyB0aG91 Z2ggdGhlIG1vZHVsdXMgc2hvdWxkIGJlLCBpbnN0ZWFkIG9mIGFzIHRoZSBzaXplIGl0IGFjdHVh bGx5IGlzIi4gVGhpcyBzZWVtcyB0byBoYXZlIG5vIHB1cnBvc2Ugb3RoZXIgdGhhbiB0byBtaXNs ZWFkIChlZyB0cmljayBhIGNvbXBvbmVudCB0aGF0IG9ubHkgbG9va3MgYXQgdGhlIGVuY29kZWQg bGVuZ3RoIGludG8gdGhpbmtpbmcgdGhlIGtleSBpcyBsb25nZXIvc3Ryb25nZXIgdGhhbiBpdCBh Y3R1YWxseSBpcykuDQoNCg0KDQozLg0KDQpBbiBSU0EgcHJpdmF0ZSBrZXkgZm9ybWF0IG5lZWRz IHRvIHN1cHBvcnQgY2FsY3VsYXRpb25zIHRoYXQgdXNlIHRoZSBDaGluZXNlIFJlbWFpbmRlciBU aGVvcnVtIChDUlQpLCBieSBhbGxvd2luZyBwLCBxLCBkIG1vZCBwLTEsIGQgbW9kIHEtMSwgYW5k IHFpbnYgdG8gYmUgc3BlY2lmaWVkIC0tIG5vdCBqdXN0IGQuIENSVCBjYWxjdWxhdGlvbnMgb2Zm ZXIgdG9vIG11Y2ggb2YgYSBwZXJmb3JtYW5jZSBib29zdCB0byBpZ25vcmUgKDIgb3IgNCB0aW1l cyBmYXN0ZXIsIGNhbid0IHJlbWVtYmVyIHdoaWNoIG9mZiB0aGUgdG9wIG9mIG15IGhlYWQpLg0K DQoNCg0KVGhpcyBtYWtlcyBzZW5zZS4gIElzIHRoZXJlIGV4aXN0aW5nIHByYWN0aWNlIGZvciBz dWNoIHJlcHJlc2VudGF0aW9ucyB0aGF0IHlvdSBjYW4gcG9pbnQgdXMgdG8gdGhhdCB3ZSBjb3Vs ZCBib3Jyb3cgZnJvbT8NCg0KDQoNCkFuIFJTQSBtb2R1bHVzIGNhbiBhY3R1YWxseSBoYXZlIG1v cmUgdGhhbiAyIHByaW1lIGZhY3RvcnMuIEFuIFJTQSBwcml2YXRlIGtleSBmb3JtYXQgc2hvdWxk IHRoZW9yZXRpY2FsbHkgc3VwcG9ydCB0aGF0IGFzIHdlbGwuIFRoYXQgaXMsIHN1cHBvcnQgYW4g YXJyYXkgb2Yge3ByaW1lLCBleHBvbmVudCwgY29lZmZpY2llbnR9LCBpbnN0ZWFkIG9mIGhhcmR3 aXJpbmcgZmllbGRzIGZvciAyIHByaW1lcy4NCg0KU2VlIFJGQzM0NDcgIlBLQ1MgIzE6IFJTQSBD cnlwdG9ncmFwaHkgU3BlY2lmaWNhdGlvbnMsIHZlcnNpb24gMi4xIi4NCg0KDQoNCklzIHRoaXMg dXNlZCBpbiBwcmFjdGljZT8gIFRoZSBjb2RlIHRoYXQgSeKAmXZlIGxvb2tlZCBhdCBkb2VzbuKA mXQgc3VwcG9ydCB0aGlzLiAgSWYgaXTigJlzIGp1c3QgYSB0aGVvcmV0aWNhbCBjYXNlLCByYXRo ZXIgdGhhbiBhIHByYWN0aWNhbCBvbmUsIEkgZG9u4oCZdCBzZWUgYW55IG5lZWQgZm9yIHVzIHRv IHN1cHBvcnQgaXQuDQoNCg0KDQo0Lg0KDQpJIGFtIG5vdCBzdXJlIGlmIGl0IGhhcyBiZWVuIGFz a2VkIGJlZm9yZSAoYnkgbWUgb3Igc29tZW9uZSBlbHNlKSwgYnV0IGlzIHRoZXJlIHJlYWxseSBh bnkgYmVuZWZpdCBmcm9tIHdyYXBwaW5nIHRoZSBKU09OIGFycmF5IG9mIGtleSBvYmplY3RzIGlu IGFub3RoZXIgSlNPTiBvYmplY3Qgd2l0aCBhIHNpbmdsZSBtZW1iZXIgImtleXMiIFtKV0sgc2Vj dGlvbiA1ICJKU09OIFdlYiBLZXkgU2V0IChKV0sgU2V0KSBGb3JtYXQiXT8gVGhpcyBpcyBhZGRp bmcgYW4gZXh0ZW5zaW9uIHBvaW50IHdpdGggbm8gY3VycmVudGx5LWtub3duIHVzZSwgYnV0IHdp dGhvdXQgYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgc2luY2UgYW55IGV4dGVuc2lvbiBNVVNU IGJlIHVuZGVyc3Rvb2QuDQoNCg0KDQpUaGlzIGFsbG93cyBkZXBsb3ltZW50cyB0byBkZWZpbmUg YW5kIHVzZSBvdGhlciBtZW1iZXJzIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUga2V5IHNldC4gIEppbSBTY2hhYWQgaGFkIHN1Z2dlc3RlZCBkZWZpbmluZyB0aGUg cmVnaXN0cnkgZm9yIHRoZXNlIG1lbWJlciBmb3IgZXhhY3RseSB0aGlzIHB1cnBvc2UsIHdoaWNo IG1hZGUgc2Vuc2UgdG8gbWUuDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0KDQo= --_000_4E1F6AAD24975D4BA5B168042967394366797EADTK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1z b1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5SZXBsaWVzIGlubGluZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KRnJvbTogTWFuZ2VyLCBKYW1lcyBIIFttYWlsdG86SmFtZXMuSC5NYW5nZXJA dGVhbS50ZWxzdHJhLmNvbV0gPGJyPg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTIg NTo0NyBQTTxicj4NClRvOiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnPGJyPg0KU3ViamVjdDog cHJpdmF0ZSBrZXlzLCBsZWFkaW5nIHplcm9zPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NaWtlLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgZm9yIG1ha2luZyB0aGUgZWZmb3J0IHRv IHByb2R1Y2UgYSBkcmFmdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWpvc2UtanNv bi1wcml2YXRlLWtleSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWpvc2UtanNv bi1wcml2YXRlLWtleTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIw NTAiPllvdeKAmXJlIHdlbGNvbWUuIDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Rm91ciBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllvdXIgY2hvaWNlIHRvIGV4dGVu ZCB0aGUgcHVibGljIGtleSBmb3JtYXQgdG8gYWxzbyBob2xkIHRoZSBwcml2YXRlIGtleSBpbmZv IG1pZ2h0IGhhdmUgc29tZSBpbnRlcmVzdGluZyBjb25zZXF1ZW5jZXMuIEl0IHN1Z2dlc3RzIHlv dSBjYW4gaGF2ZSBhIHNpbmdsZSBmaWxlIChvciBzaW5nbGUgSlNPTiBvYmplY3QpIHRoYXQgY2Fu IGJlIHVzZWQgYnkgdG9vbHMgdGhhdCBuZWVkcyBhIHB1YmxpYyBrZXksDQogYW5kIGJ5IHRvb2xz IHRoYXQgbmVlZCBhIHByaXZhdGUga2V5LiBIb3dldmVyLCBJIGRvdWJ0IHRoYXQgaXMgdmVyeSBn b29kIHByYWN0aWNlLiBJdCBqdXN0IGFkZHMgYSByaXNrIHRoYXQgYSBwcml2YXRlIGtleSBpcyBp bmFkdmVydGVudGx5IGV4cG9zZWQgd2hlcmUgaXQgc2hvdWxkbid0IGJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5QZXJoYXBzIHRoZSBmb2xsb3dpbmcgc29ydCBvZiBmb3JtYXQgd291 bGQgYmUgYmV0dGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtwdWJsaWMmcXVvdDs6eyZxdW90O2FsZyZxdW90OzomcXVvdDsuLi59LDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O3ByaXZhdGUmcXVvdDs6eyZxdW90O2QmcXVvdDs6Li4ufTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPkZvciB3aGF0IGl04oCZcyB3b3J0aCwg aGF2aW5nIGEgZm9ybWF0IHRoYXQgY2FuIHJlcHJlc2VudCBlaXRoZXIgcHVibGljIG9yIHB1Ymxp Yy9wcml2YXRlIHNlZW1zIHRvIGJlIGZhaXJseSBjb21tb24gcHJhY3RpY2UgZm9yIGNyeXB0byBB UElzLiZuYnNwOyBGb3IgaW5zdGFuY2UsIHNlZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cDovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L3N5 c3RlbS5zZWN1cml0eS5jcnlwdG9ncmFwaHkuY25na2V5YmxvYmZvcm1hdC5hc3B4Ij5odHRwOi8v bXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvc3lzdGVtLnNlY3VyaXR5LmNyeXB0b2dy YXBoeS5jbmdrZXlibG9iZm9ybWF0LmFzcHg8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDBCMDUwIj4uJm5ic3A7DQogSSBiZWxpZXZlIHRoYXQgc2ltaWxhciBmdW5jdGlvbnMgYXJlIGFs c28gYXZhaWxhYmxlIGZvciBKYXZhLCBldGMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIHJ1 bGUgdGhhdCBpbnRlZ2VycyBNVVNUIG5vdCBiZSBzaG9ydGVuZWQgaWYgdGhleSBoYXZlIGxlYWRp bmcgMCdzIGlzIHNpbGx5LiBJdCBpbXBsaWVzIHlvdSBjYW5ub3QgZW5jb2RlIGFuIGludGVnZXIg d2l0aG91dCBrbm93aW5nIGEgbGFyZ2VyIGNvbnRleHQgKGVnIHlvdSBjYW5ub3QgZW5jb2RlIGQg d2l0aG91dCBzcGVjaWZ5aW5nIG4sIGluIHRoZSBjb250ZXh0IG9mIGFuIFJTQSBrZXkpLiBUaGlz DQogcnVsZSBhcHBsaWVzIHRvIHRoZSBwcml2YXRlIGV4cG9uZW50LCBidXQgdGhlIG9wcG9zaXRl IHJ1bGUgYXBwbGllcyB0byB0aGUgcHVibGljIGV4cG9uZW50LiBZdWNrLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5FaXRoZXIgYWx3YXlzIGZvcmJpZGRpbmcgbGVhZGluZyB6ZXJvcywg b3IgYWx3YXlzIGFsbG93aW5nIHRoZW0gKHNvIHJlY2VpdmVycyBNVVNUIHN1cHBvcnQgdGhlbSks IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHJ1bGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+VGhpcyBsYW5ndWFnZSB3YXMgYWN0dWFsbHkg anVzdCBjb3BpZWQgZnJvbSBKV0suJm5ic3A7IFRoZSBnb2FsIGlzIHRvIGZhY2lsaXRhdGUgZGly ZWN0IGNvbnZlcnNpb24gZnJvbSB0aGUgYmFzZTY0dXJsIGVuY29kZWQgcmVwcmVzZW50YXRpb25z IG9mIHRoZSBieXRlIGFycmF5cyB0byB0aGUgYnl0ZSBhcnJheXMgZm9yIHRoZSBrZXkgdmFsdWVz LCB3aXRoIG5vIOKAnHNoaWZ0aW5n4oCdDQogb3Ig4oCccHJlcGVuZGluZ+KAnSByZXF1aXJlZC4m bmJzcDsgTWFueSBjcnlwdG8gQVBJcyB3aWxsIGV4cGVjdCBieXRlIGFycmF5cyBvZiBzcGVjaWZp YyBsZW5ndGhzLCB0aGF0IGluY2x1ZGUgdGhlIGxlYWRpbmcgemVyb3MuJm5ic3A7IEl0IHNlZW1l ZCBiZXR0ZXIgdG8gbWFuZGF0ZSB0aGF0IHRoZSBsZWFkaW5nIHplcm9zIGJlIGluY2x1ZGVkIHNv IHRoYXQgdGhlIHJlc3VsdGluZyBieXRlIGFycmF5cyBjYW4gYmUgdXNlZCBhcy1pcywgcmF0aGVy IHRoYW4gcG90ZW50aWFsbHkNCiBoYXZpbmcgdG8gcHJlcGVuZCB0aGVtIGlmIHRoZXkgYXJlIG1p c3NpbmcgYmVmb3JlIHVzaW5nIHRoZSBieXRlIGFycmF5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwQjA1MCI+VGhhdCBiZWluZyBzYWlkLCBpZiB0aGUgd29ya2luZyBncm91 cCBkZWNpZGVzIHRvIGNoYW5nZSB0aGlzIHRvIHNheSB0aGF0IGxlYWRpbmcgemVyb3MgbWF5IGJl IG9taXR0ZWQsIHdlIGNvdWxkIGRvIHRoYXQsIGFsdGhvdWdoIGl0IHdvdWxkIG1lYW4gdGhhdCBp bXBsZW1lbnRhdGlvbnMgaGF2ZSBtb3JlIHRvIGRvIHdoZW4gaW1wb3J0aW5nIGtleXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGp1c3Qgbm90aWNlZCB0aGUgJnF1b3Q7 TVVTVCBub3Qgb21pdCBsZWFkaW5nIDAncyZxdW90OyBydWxlIGFwcGxpZXMgdG8gdGhlIFJTQSBt b2R1bHVzIGluIEpXQSAoc2VjdGlvbiA1LjMuMSAmcXVvdDttb2QmcXVvdDsgTW9kdWx1cyBQYXJh bWV0ZXIpLiBUaGUgcnVsZSBpcyBldmVuIHNpbGxpZXIgaW4gdGhpcyBjYXNlLiBJdCBlZmZlY3Rp dmVseSBzYXlzICZxdW90O3RoZSBtb2R1bHVzIE1VU1QgYmUgZW5jb2RlZCBhcyB0aGUgc2l6ZSBz b21lb25lL3NvbWV0aGluZw0KIHRob3VnaCB0aGUgbW9kdWx1cyBzaG91bGQgYmUsIGluc3RlYWQg b2YgYXMgdGhlIHNpemUgaXQgYWN0dWFsbHkgaXMmcXVvdDsuIFRoaXMgc2VlbXMgdG8gaGF2ZSBu byBwdXJwb3NlIG90aGVyIHRoYW4gdG8gbWlzbGVhZCAoZWcgdHJpY2sgYSBjb21wb25lbnQgdGhh dCBvbmx5IGxvb2tzIGF0IHRoZSBlbmNvZGVkIGxlbmd0aCBpbnRvIHRoaW5raW5nIHRoZSBrZXkg aXMgbG9uZ2VyL3N0cm9uZ2VyIHRoYW4gaXQgYWN0dWFsbHkgaXMpLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ QW4gUlNBIHByaXZhdGUga2V5IGZvcm1hdCBuZWVkcyB0byBzdXBwb3J0IGNhbGN1bGF0aW9ucyB0 aGF0IHVzZSB0aGUgQ2hpbmVzZSBSZW1haW5kZXIgVGhlb3J1bSAoQ1JUKSwgYnkgYWxsb3dpbmcg cCwgcSwgZCBtb2QgcC0xLCBkIG1vZCBxLTEsIGFuZCBxaW52IHRvIGJlIHNwZWNpZmllZCAtLSBu b3QganVzdCBkLiBDUlQgY2FsY3VsYXRpb25zIG9mZmVyIHRvbyBtdWNoIG9mIGEgcGVyZm9ybWFu Y2UgYm9vc3QNCiB0byBpZ25vcmUgKDIgb3IgNCB0aW1lcyBmYXN0ZXIsIGNhbid0IHJlbWVtYmVy IHdoaWNoIG9mZiB0aGUgdG9wIG9mIG15IGhlYWQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+VGhpcyBtYWtlcyBzZW5zZS4mbmJzcDsg SXMgdGhlcmUgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIHN1Y2ggcmVwcmVzZW50YXRpb25zIHRoYXQg eW91IGNhbiBwb2ludCB1cyB0byB0aGF0IHdlIGNvdWxkIGJvcnJvdyBmcm9tPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+QW4gUlNBIG1vZHVsdXMgY2FuIGFjdHVhbGx5IGhhdmUgbW9yZSB0aGFuIDIgcHJpbWUgZmFj dG9ycy4gQW4gUlNBIHByaXZhdGUga2V5IGZvcm1hdCBzaG91bGQgdGhlb3JldGljYWxseSBzdXBw b3J0IHRoYXQgYXMgd2VsbC4gVGhhdCBpcywgc3VwcG9ydCBhbiBhcnJheSBvZiB7cHJpbWUsIGV4 cG9uZW50LCBjb2VmZmljaWVudH0sIGluc3RlYWQgb2YgaGFyZHdpcmluZyBmaWVsZHMgZm9yIDIg cHJpbWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VlIFJGQzM0 NDcgJnF1b3Q7UEtDUyAjMTogUlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0aW9ucywgdmVyc2lv biAyLjEmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDBCMDUwIj5JcyB0aGlzIHVzZWQgaW4gcHJhY3RpY2U/Jm5ic3A7IFRoZSBjb2RlIHRo YXQgSeKAmXZlIGxvb2tlZCBhdCBkb2VzbuKAmXQgc3VwcG9ydCB0aGlzLiZuYnNwOyBJZiBpdOKA mXMganVzdCBhIHRoZW9yZXRpY2FsIGNhc2UsIHJhdGhlciB0aGFuIGEgcHJhY3RpY2FsIG9uZSwg SSBkb27igJl0IHNlZSBhbnkgbmVlZCBmb3IgdXMgdG8gc3VwcG9ydCBpdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGFtIG5vdCBzdXJlIGlmIGl0IGhhcyBiZWVuIGFza2VkIGJlZm9yZSAoYnkg bWUgb3Igc29tZW9uZSBlbHNlKSwgYnV0IGlzIHRoZXJlIHJlYWxseSBhbnkgYmVuZWZpdCBmcm9t IHdyYXBwaW5nIHRoZSBKU09OIGFycmF5IG9mIGtleSBvYmplY3RzIGluIGFub3RoZXIgSlNPTiBv YmplY3Qgd2l0aCBhIHNpbmdsZSBtZW1iZXIgJnF1b3Q7a2V5cyZxdW90OyBbSldLIHNlY3Rpb24g NSAmcXVvdDtKU09OIFdlYiBLZXkgU2V0IChKV0sgU2V0KQ0KIEZvcm1hdCZxdW90O10/IFRoaXMg aXMgYWRkaW5nIGFuIGV4dGVuc2lvbiBwb2ludCB3aXRoIG5vIGN1cnJlbnRseS1rbm93biB1c2Us IGJ1dCB3aXRob3V0IGFueSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHNpbmNlIGFueSBleHRlbnNp b24gTVVTVCBiZSB1bmRlcnN0b29kLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5UaGlzIGFsbG93cyBkZXBsb3ltZW50cyB0byBkZWZp bmUgYW5kIHVzZSBvdGhlciBtZW1iZXJzIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlv biBhYm91dCB0aGUga2V5IHNldC4mbmJzcDsgSmltIFNjaGFhZCBoYWQgc3VnZ2VzdGVkIGRlZmlu aW5nIHRoZSByZWdpc3RyeSBmb3IgdGhlc2UgbWVtYmVyIGZvciBleGFjdGx5IHRoaXMgcHVycG9z ZSwgd2hpY2gNCiBtYWRlIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkphbWVz IE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B168042967394366797EADTK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Fri Aug 17 10:16:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E015121F8476 for ; Fri, 17 Aug 2012 10:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRaIlYo7Nt1l for ; Fri, 17 Aug 2012 10:16:38 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9332D21F8475 for ; Fri, 17 Aug 2012 10:16:38 -0700 (PDT) Received: from mail146-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Aug 2012 17:16:37 +0000 Received: from mail146-tx2 (localhost [127.0.0.1]) by mail146-tx2-R.bigfish.com (Postfix) with ESMTP id CB2BD4E01C6; Fri, 17 Aug 2012 17:16:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zzbb2dI98dI9371I1415Jc85fh1454I148cI542Mzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail146-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2 (MessageSwitch) id 1345223795949360_21591; Fri, 17 Aug 2012 17:16:35 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.243]) by mail146-tx2.bigfish.com (Postfix) with ESMTP id D952E320094; Fri, 17 Aug 2012 17:16:35 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Aug 2012 17:16:35 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Fri, 17 Aug 2012 17:16:34 +0000 From: Mike Jones To: Justin Richer , Nat Sakimura Thread-Topic: [jose] JOSE WG request from W3C WebCrypto API Thread-Index: AQHNeJunnpgcpjfvnEmN0vS5J/XJKJdbc0tAgAHbCgCAAMWIgIAAMLig Date: Fri, 17 Aug 2012 17:16:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366797ECB@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <502E51A5.5080401@mitre.org> In-Reply-To: <502E51A5.5080401@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366797ECBTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Jim Schaad , "jose-chairs@tools.ietf.org" , Harry Halpin , Karen O'Donoghue , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:16:44 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366797ECBTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nat, I agree that a JWK containing a private key *could* be encrypted, but = requiring that seems to be overkill, in part, for the reasons that Justin d= escribes. There are many contexts where it is normal/safe to handle privat= e key information - just like it's normal/safe to handle plaintext password= values. (Analogously, there are also contexts where this information shou= ld/must be encrypted.) Knowing when private keys should/must be encrypted = seems like a higher-level context-dependent decision. Justin, per my reply to James, putting the two in the same structure seems = to be existing practice for other APIs. It's certainly the simplest soluti= on. I don't see that the safety properties would be any different whether = there are "public" and "private" members with sub-members for the key field= s, or simply a flat structure of key members, which is currently what's spe= cified. In both cases, if there is private key information present, it *mu= st* be appropriately protected. Best wishes, -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, August 17, 2012 7:14 AM To: Nat Sakimura Cc: Mike Jones; Jim Schaad; jose-chairs@tools.ietf.org; Harry Halpin; jose@= ietf.org; Karen O'Donoghue Subject: Re: [jose] JOSE WG request from W3C WebCrypto API Nat, how would you store the private key that you encrypted the private key= with? And what key would you use to encrypt your private-key-encrypter key= ? It's turtles all the way down, and not in a good way. I personally really like having a parallel format to JWK for private keys, = and I even asked (off list) for this feature about six months back. My use = case was simple, and still valid: I have a server that takes in a configura= tion file with all kinds of already-sensitive information, like database pa= sswords and admin user lists. I would love to be able to put my public and = private keys in there without dropping to an ASN.1 structure. I realized th= at with JWK, I could store my public keys, but didn't have any place to put= the private keys. At the time, we punted and went with a container-native = certificate store with self-signed certificates, but this setup remains ove= rkill and a bad fit for what we actually care about, the keys. But in order= to get the keys, we had to generate a self-signed cert with a fake certifi= cate authority and junk metadata just to fit the format. A JWK/JPK structur= e (to coin an acronym for the soup) would be able to handle this quite nice= ly, and it parallels what the WebCrypto WG is after, from what I gather. It= would be fairly easy to add support for shared HMAC secrets in the same fo= rmat as well. However, I do agree with one point that was brought up: I don't necessarily= like putting the two in the same structure. I think it's quite *functional= * this way, but it seems like it could cause a problem like the private bit= s getting leaked. On the other hand, this feeling could be a case of premat= ure intuition-based optimization [1], so I'm not sure how much credence to = give it. -- Justin [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ On 08/16/2012 10:26 PM, Nat Sakimura wrote: Thanks Mike. Would it not be a good idea to mandate that private key file must be encryp= ted? As far as I remember, one of the reason for not producing private key = format was from the fear that developers leave the exported keys in a insec= ure manner. Thoughts? Nat On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones > wrote: Thanks for writing, Harry and WebCrypto WG. 1) About private keys, given the WebCrypto use case, I personally think it= would be valuable for JOSE to define a JSON private key representation. T= o make this concrete, I would propose the private key representations speci= fied in http://tools.ietf.org/html/draft-jones-jose-json-private-key. You'= ll see that doing this is very simple; it just defines two additional membe= rs for the JWK structure for representing the private parts of Elliptic Cur= ve and RSA keys. This could either remain a separate spec from JWK/JWA or = be merged in, at the working group's preference. I had previously agreed with the position that it was not necessary for JOS= E to define private key representations because we didn't have a use case f= or it. However, as I see it, the W3C WebCrypto API use case changes things= . Better for JOSE to be responsive to WebCrypto and add this simple extens= ion, either as a new spec or in the existing specs, than to leave this undo= ne, and have it potentially be an area where otherwise standards-compliant = implementations diverge, and where JSON-only solutions are not possible. Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jos= e/charter/ does not preclude defining private key formats. (It simply requ= ires the definition of public key formats and is silent on the topic of pri= vate keys.) 2) I agree on the likely need for WebCrypto support ASN.1 for backwards co= mpatibility in some cases (just as the JOSE specs allow the use of X.509 ce= rtificates). However, I believe it would be a shame to preclude JSON-only = solutions by not supporting key import/export in JWK format, where such sol= utions make sense. 3) It appears to me the JWK format is stable. I believe the JWS format is= stable as well. The JWE format has known changes that will be applied sho= rtly, based upon working group discussions at IETF 84 in Vancouver two week= s ago. Some JWA changes will occur that are part of the JWE changes. I do= n't anticipate significant changes after that. (Making these changes is my= highest priority as JOSE editor. I'm hoping to have drafts out containing= them by the end of August, which hopefully fits well with the WebCrypto sc= hedule.) I write all of the above with the caveat that the working group i= s, of course, free to change things as they see fit. I look forward to a productive discussion of this coordination request in b= oth working groups. Best wishes, -- Mike P.S. If you prefer, a HTML-formatted version of the private key spec is av= ailable at http://self-issued.info/docs/draft-jones-jose-json-private-key.h= tml. I also blogged about this draft specification at http://self-issued.i= nfo/?p=3D816. -----Original Message----- From: Harry Halpin [mailto:hhalpin@w3.org] Sent: Sunday, August 12, 2012 8:03 AM To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones Subject: JOSE WG request from W3C WebCrypto API [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] JOSE Chairs, The Web Cryptography Working group has noted that the API requires some acc= ess to raw key material, and the issue of whether or not to use JWK or ASN.= 1 as the default format came up. Two issues have come out that we'd like to= know the answer to: 1) JWK does not define a private key format. Does the JOSE WG plan to suppo= rt a JOSE-format for private keys? If so, when? Or 'maybe'? 2) While we'd like encourage the use of JOSE over ASN.1, it seems like fo= r backwards compatibility having some level of ASN.1 support would be usefu= l and we *need* a format that allows key material (both private and public) to be exported. Folks seem to leaning towards ASN.1 as a default fo= rmat in the low-level API, and having JWK as a format that can be built on = top of that in a possible high-level API. Would that be OK? 3) How stable do you believe the JOSE formats are right now? Do you think= they are stable enough now we can reference them in our API draft at end o= f August? If not, when? The W3C would like to and plan to use these format= s where possible. Feel free to forward this by JOSE WG for discussion. We'd like an answer be= fore we send our document to FPWD at end of August. cheers, harry _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366797ECBTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nat, I agree that a JWK c= ontaining a private key *could* be encrypted, but requiring that see= ms to be overkill, in part, for the reasons that Justin describes.  There are many contexts where it is normal/safe to handle= private key information – just like it’s normal/safe to handle= plaintext password values.  (Analogously, there are also contexts whe= re this information should/must be encrypted.)  Knowing when private keys should/must be encrypted seems like a higher-level conte= xt-dependent decision.

 <= /p>

Justin, per my reply to J= ames, putting the two in the same structure seems to be existing practice f= or other APIs.  It’s certainly the simplest solution.  I don’t see that the safety properties would be any different whether = there are “public” and “private” members with sub-m= embers for the key fields, or simply a flat structure of key members, which= is currently what’s specified.  In both cases, if there is priv= ate key information present, it *must* be appropriately protected.=

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Best wishes,

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, August 17, 2012 7:14 AM
To: Nat Sakimura
Cc: Mike Jones; Jim Schaad; jose-chairs@tools.ietf.org; Harry Halpin= ; jose@ietf.org; Karen O'Donoghue
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

 

Nat, how would you store the private key that you en= crypted the private key with? And what key would you use to encrypt your pr= ivate-key-encrypter key? It's turtles all the way down, and not in a good w= ay.

I personally really like having a parallel format to JWK for private keys, = and I even asked (off list) for this feature about six months back. My use = case was simple, and still valid: I have a server that takes in a configura= tion file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to= be able to put my public and private keys in there without dropping to an = ASN.1 structure. I realized that with JWK, I could store my public keys, bu= t didn't have any place to put the private keys. At the time, we punted and went with a container-native cert= ificate store with self-signed certificates, but this setup remains overkil= l and a bad fit for what we actually care about, the keys. But in order to = get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata jus= t to fit the format. A JWK/JPK structure (to coin an acronym for the soup) = would be able to handle this quite nicely, and it parallels what the WebCry= pto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same= format as well.

However, I do agree with one point that was brought up: I don't necessarily= like putting the two in the same structure. I think it's quite *functional= * this way, but it seems like it could cause a problem like the private bit= s getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1]= , so I'm not sure how much credence to give it.

 -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:

Thanks Mike. 

 

Would it not be a good idea to mandate that private = key file must be encrypted? As far as I remember, one of the reason for not= producing private key format was from the fear that developers leave the e= xported keys in a insecure manner. 

 

Thoughts? 

 

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks for writing, Harry and WebCrypto WG.

1)  About private keys, given the WebCrypto use case, I personally thi= nk it would be valuable for JOSE to define a JSON private key representatio= n.  To make this concrete, I would propose the private key representat= ions specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.  You= 'll see that doing this is very simple; it just defines two additional memb= ers for the JWK structure for representing the private parts of Elliptic Cu= rve and RSA keys.  This could either remain a separate spec from JWK/JWA or be merged in, at the working group'= s preference.

I had previously agreed with the position that it was not necessary for JOS= E to define private key representations because we didn't have a use case f= or it.  However, as I see it, the W3C WebCrypto API use case changes t= hings.  Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the= existing specs, than to leave this undone, and have it potentially be an a= rea where otherwise standards-compliant implementations diverge, and where = JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining= private key formats.  (It simply requires the definition of public ke= y formats and is silent on the topic of private keys.)

2)  I agree on the likely need for WebCrypto support ASN.1 for backwar= ds compatibility in some cases (just as the JOSE specs allow the use of X.5= 09 certificates).  However, I believe it would be a shame to preclude = JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3)  It appears to me the JWK format is stable.  I believe the JWS= format is stable as well.  The JWE format has known changes that will= be applied shortly, based upon working group discussions at IETF 84 in Van= couver two weeks ago.  Some JWA changes will occur that are part of the JWE changes.  I don't anticipate significant cha= nges after that.  (Making these changes is my highest priority as JOSE= editor.  I'm hoping to have drafts out containing them by the end of = August, which hopefully fits well with the WebCrypto schedule.)  I write all of the above with the caveat that the working= group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in b= oth working groups.

                     = ;           Best wishes,
                     = ;           -- Mike

P.S.  If you prefer, a HTML-formatted version of the private key spec = is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html. &n= bsp;I also blogged about this draft specification at http://self-= issued.info/?p=3D816.


-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org= ]
Sent: Sunday, August 12, 2012 8:03 AM

[cc'ing Mike Jones an= d Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some acc= ess to raw key material, and the issue of whether or not to use JWK or ASN.= 1 as the default format came up. Two issues have come out that we'd like to= know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to suppo= rt a JOSE-format for private keys? If so, when? Or 'maybe'?

  2) While we'd like encourage the use of JOSE over ASN.1, it seems li= ke for backwards compatibility having some level of ASN.1 support would be = useful and we *need* a format that allows key material (both private and public) to be exported. Folks seem to leaning towards ASN.1 as a default fo= rmat in the low-level API, and having JWK as a format that can be built on = top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you = think they are stable enough now we can reference them in our API draft at = end of August? If not, when?  The W3C would like to and plan to use th= ese formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer be= fore we send our document to FPWD at end of August.

  cheers,
      harry



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

 




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

 

--_000_4E1F6AAD24975D4BA5B168042967394366797ECBTK5EX14MBXC284r_-- From jricher@mitre.org Fri Aug 17 10:22:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C963F21F849A for ; Fri, 17 Aug 2012 10:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtKxzokOJ6Zt for ; Fri, 17 Aug 2012 10:22:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BEE5E21F8495 for ; Fri, 17 Aug 2012 10:22:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DEDC21B1949; Fri, 17 Aug 2012 13:22:32 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8A9E121B024E; Fri, 17 Aug 2012 13:22:32 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 17 Aug 2012 13:22:32 -0400 Message-ID: <502E7D82.3050908@mitre.org> Date: Fri, 17 Aug 2012 13:21:06 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Jones References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <502E51A5.5080401@mitre.org> <4E1F6AAD24975D4BA5B168042967394366797ECB@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366797ECB@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------080909070901070307060106" X-Originating-IP: [129.83.31.58] Cc: "jose-chairs@tools.ietf.org" , Harry Halpin , Karen O'Donoghue , Jim Schaad , Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:22:37 -0000 --------------080909070901070307060106 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > Justin, per my reply to James, putting the two in the same structure > seems to be existing practice for other APIs. It's certainly the > simplest solution. I don't see that the safety properties would be > any different whether there are "public" and "private" members with > sub-members for the key fields, or simply a flat structure of key > members, which is currently what's specified. In both cases, if there > is private key information present, it **must** be appropriately > protected. > Right, when you put it in those terms it makes more sense. The keys are going to be contained in the same root object structure either way, and it'd be just as likely for someone to accidentally grab the public keys in both cases. -- Justin > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, August 17, 2012 7:14 AM > *To:* Nat Sakimura > *Cc:* Mike Jones; Jim Schaad; jose-chairs@tools.ietf.org; Harry > Halpin; jose@ietf.org; Karen O'Donoghue > *Subject:* Re: [jose] JOSE WG request from W3C WebCrypto API > > Nat, how would you store the private key that you encrypted the > private key with? And what key would you use to encrypt your > private-key-encrypter key? It's turtles all the way down, and not in a > good way. > > I personally really like having a parallel format to JWK for private > keys, and I even asked (off list) for this feature about six months > back. My use case was simple, and still valid: I have a server that > takes in a configuration file with all kinds of already-sensitive > information, like database passwords and admin user lists. I would > love to be able to put my public and private keys in there without > dropping to an ASN.1 structure. I realized that with JWK, I could > store my public keys, but didn't have any place to put the private > keys. At the time, we punted and went with a container-native > certificate store with self-signed certificates, but this setup > remains overkill and a bad fit for what we actually care about, the > keys. But in order to get the keys, we had to generate a self-signed > cert with a fake certificate authority and junk metadata just to fit > the format. A JWK/JPK structure (to coin an acronym for the soup) > would be able to handle this quite nicely, and it parallels what the > WebCrypto WG is after, from what I gather. It would be fairly easy to > add support for shared HMAC secrets in the same format as well. > > However, I do agree with one point that was brought up: I don't > necessarily like putting the two in the same structure. I think it's > quite *functional* this way, but it seems like it could cause a > problem like the private bits getting leaked. On the other hand, this > feeling could be a case of premature intuition-based optimization [1], > so I'm not sure how much credence to give it. > > -- Justin > > [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ > > > On 08/16/2012 10:26 PM, Nat Sakimura wrote: > > Thanks Mike. > > Would it not be a good idea to mandate that private key file must > be encrypted? As far as I remember, one of the reason for not > producing private key format was from the fear that developers > leave the exported keys in a insecure manner. > > Thoughts? > > Nat > > On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones > > > wrote: > > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally > think it would be valuable for JOSE to define a JSON private key > representation. To make this concrete, I would propose the > private key representations specified in > http://tools.ietf.org/html/draft-jones-jose-json-private-key. > You'll see that doing this is very simple; it just defines two > additional members for the JWK structure for representing the > private parts of Elliptic Curve and RSA keys. This could either > remain a separate spec from JWK/JWA or be merged in, at the > working group's preference. > > I had previously agreed with the position that it was not > necessary for JOSE to define private key representations because > we didn't have a use case for it. However, as I see it, the W3C > WebCrypto API use case changes things. Better for JOSE to be > responsive to WebCrypto and add this simple extension, either as a > new spec or in the existing specs, than to leave this undone, and > have it potentially be an area where otherwise standards-compliant > implementations diverge, and where JSON-only solutions are not > possible. > > Finally, I'll note that the JOSE charter > http://datatracker.ietf.org/wg/jose/charter/ > does not preclude > defining private key formats. (It simply requires the definition > of public key formats and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for > backwards compatibility in some cases (just as the JOSE specs > allow the use of X.509 certificates). However, I believe it would > be a shame to preclude JSON-only solutions by not supporting key > import/export in JWK format, where such solutions make sense. > > 3) It appears to me the JWK format is stable. I believe the JWS > format is stable as well. The JWE format has known changes that > will be applied shortly, based upon working group discussions at > IETF 84 in Vancouver two weeks ago. Some JWA changes will occur > that are part of the JWE changes. I don't anticipate significant > changes after that. (Making these changes is my highest priority > as JOSE editor. I'm hoping to have drafts out containing them by > the end of August, which hopefully fits well with the WebCrypto > schedule.) I write all of the above with the caveat that the > working group is, of course, free to change things as they see fit. > > I look forward to a productive discussion of this coordination > request in both working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key > spec is available at > http://self-issued.info/docs/draft-jones-jose-json-private-key.html. > I also blogged about this draft specification at > http://self-issued.info/?p=816. > > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org ] > Sent: Sunday, August 12, 2012 8:03 AM > > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org > ; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires > some access to raw key material, and the issue of whether or not > to use JWK or ASN.1 as the default format came up. Two issues have > come out that we'd like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan > to support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it > seems like for backwards compatibility having some level of ASN.1 > support would be useful and we *need* a format that allows key > material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a > default format in the low-level API, and having JWK as a format > that can be built on top of that in a possible high-level API. > Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do > you think they are stable enough now we can reference them in our > API draft at end of August? If not, when? The W3C would like to > and plan to use these formats where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an > answer before we send our document to FPWD at end of August. > > cheers, > harry > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > --------------080909070901070307060106 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

Justin, per my reply to James, putting the two in the same structure seems to be existing practice for other APIs.  It’s certainly the simplest solution.  I don’t see that the safety properties would be any different whether there are “public” and “private” members with sub-members for the key fields, or simply a flat structure of key members, which is currently what’s specified.  In both cases, if there is private key information present, it *must* be appropriately protected.

Right, when you put it in those terms it makes more sense. The keys are going to be contained in the same root object structure either way, and it'd be just as likely for someone to accidentally grab the public keys in both cases.

 -- Justin
 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, August 17, 2012 7:14 AM
To: Nat Sakimura
Cc: Mike Jones; Jim Schaad; jose-chairs@tools.ietf.org; Harry Halpin; jose@ietf.org; Karen O'Donoghue
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

 

Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it.

 -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:

Thanks Mike. 

 

Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. 

 

Thoughts? 

 

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing, Harry and WebCrypto WG.

1)  About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation.  To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.  You'll see that doing this is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.  This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference.

I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it.  However, as I see it, the W3C WebCrypto API use case changes things.  Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining private key formats.  (It simply requires the definition of public key formats and is silent on the topic of private keys.)

2)  I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates).  However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3)  It appears to me the JWK format is stable.  I believe the JWS format is stable as well.  The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago.  Some JWA changes will occur that are part of the JWE changes.  I don't anticipate significant changes after that.  (Making these changes is my highest priority as JOSE editor.  I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.)  I write all of the above with the caveat that the working group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in both working groups.

                                Best wishes,
                                -- Mike

P.S.  If you prefer, a HTML-formatted version of the private key spec is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html.  I also blogged about this draft specification at http://self-issued.info/?p=816.


-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org]
Sent: Sunday, August 12, 2012 8:03 AM

To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'?

  2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when?  The W3C would like to and plan to use these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August.

  cheers,
      harry



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



 

--
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 




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

 


--------------080909070901070307060106-- From jricher@mitre.org Fri Aug 17 11:03:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E978A21E8044 for ; Fri, 17 Aug 2012 11:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdL+zYhTc+Ly for ; Fri, 17 Aug 2012 11:03:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED311E809B for ; Fri, 17 Aug 2012 11:03:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60AAF21B194A; Fri, 17 Aug 2012 14:03:05 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 46BEC21B193D; Fri, 17 Aug 2012 14:03:05 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 17 Aug 2012 14:03:04 -0400 Message-ID: <502E8702.7070308@mitre.org> Date: Fri, 17 Aug 2012 14:01:38 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Jones References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <502E51A5.5080401@mitre.org> <4E1F6AAD24975D4BA5B168042967394366797ECB@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030308030701030706090304" X-Originating-IP: [129.83.31.58] Cc: "jose-chairs@tools.ietf.org" , Harry Halpin , Karen O'Donoghue , Jim Schaad , Nat Sakimura , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 18:03:10 -0000 --------------030308030701030706090304 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Meant to say "accidentally grab the private keys" below, obviously. I care somewhat less about who grabs my public keys. -- Justin On 08/17/2012 01:21 PM, Justin Richer wrote: > >> Justin, per my reply to James, putting the two in the same structure >> seems to be existing practice for other APIs. It's certainly the >> simplest solution. I don't see that the safety properties would be >> any different whether there are "public" and "private" members with >> sub-members for the key fields, or simply a flat structure of key >> members, which is currently what's specified. In both cases, if >> there is private key information present, it **must** be >> appropriately protected. >> > Right, when you put it in those terms it makes more sense. The keys > are going to be contained in the same root object structure either > way, and it'd be just as likely for someone to accidentally grab the > public keys in both cases. > > -- Justin >> >> *From:*Justin Richer [mailto:jricher@mitre.org] >> *Sent:* Friday, August 17, 2012 7:14 AM >> *To:* Nat Sakimura >> *Cc:* Mike Jones; Jim Schaad; jose-chairs@tools.ietf.org; Harry >> Halpin; jose@ietf.org; Karen O'Donoghue >> *Subject:* Re: [jose] JOSE WG request from W3C WebCrypto API >> >> Nat, how would you store the private key that you encrypted the >> private key with? And what key would you use to encrypt your >> private-key-encrypter key? It's turtles all the way down, and not in >> a good way. >> >> I personally really like having a parallel format to JWK for private >> keys, and I even asked (off list) for this feature about six months >> back. My use case was simple, and still valid: I have a server that >> takes in a configuration file with all kinds of already-sensitive >> information, like database passwords and admin user lists. I would >> love to be able to put my public and private keys in there without >> dropping to an ASN.1 structure. I realized that with JWK, I could >> store my public keys, but didn't have any place to put the private >> keys. At the time, we punted and went with a container-native >> certificate store with self-signed certificates, but this setup >> remains overkill and a bad fit for what we actually care about, the >> keys. But in order to get the keys, we had to generate a self-signed >> cert with a fake certificate authority and junk metadata just to fit >> the format. A JWK/JPK structure (to coin an acronym for the soup) >> would be able to handle this quite nicely, and it parallels what the >> WebCrypto WG is after, from what I gather. It would be fairly easy to >> add support for shared HMAC secrets in the same format as well. >> >> However, I do agree with one point that was brought up: I don't >> necessarily like putting the two in the same structure. I think it's >> quite *functional* this way, but it seems like it could cause a >> problem like the private bits getting leaked. On the other hand, this >> feeling could be a case of premature intuition-based optimization >> [1], so I'm not sure how much credence to give it. >> >> -- Justin >> >> [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ >> >> >> On 08/16/2012 10:26 PM, Nat Sakimura wrote: >> >> Thanks Mike. >> >> Would it not be a good idea to mandate that private key file must >> be encrypted? As far as I remember, one of the reason for not >> producing private key format was from the fear that developers >> leave the exported keys in a insecure manner. >> >> Thoughts? >> >> Nat >> >> On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones >> > > wrote: >> >> Thanks for writing, Harry and WebCrypto WG. >> >> 1) About private keys, given the WebCrypto use case, I >> personally think it would be valuable for JOSE to define a JSON >> private key representation. To make this concrete, I would >> propose the private key representations specified in >> http://tools.ietf.org/html/draft-jones-jose-json-private-key. >> You'll see that doing this is very simple; it just defines two >> additional members for the JWK structure for representing the >> private parts of Elliptic Curve and RSA keys. This could either >> remain a separate spec from JWK/JWA or be merged in, at the >> working group's preference. >> >> I had previously agreed with the position that it was not >> necessary for JOSE to define private key representations because >> we didn't have a use case for it. However, as I see it, the W3C >> WebCrypto API use case changes things. Better for JOSE to be >> responsive to WebCrypto and add this simple extension, either as >> a new spec or in the existing specs, than to leave this undone, >> and have it potentially be an area where otherwise >> standards-compliant implementations diverge, and where JSON-only >> solutions are not possible. >> >> Finally, I'll note that the JOSE charter >> http://datatracker.ietf.org/wg/jose/charter/ >> does not preclude >> defining private key formats. (It simply requires the definition >> of public key formats and is silent on the topic of private keys.) >> >> 2) I agree on the likely need for WebCrypto support ASN.1 for >> backwards compatibility in some cases (just as the JOSE specs >> allow the use of X.509 certificates). However, I believe it >> would be a shame to preclude JSON-only solutions by not >> supporting key import/export in JWK format, where such solutions >> make sense. >> >> 3) It appears to me the JWK format is stable. I believe the JWS >> format is stable as well. The JWE format has known changes that >> will be applied shortly, based upon working group discussions at >> IETF 84 in Vancouver two weeks ago. Some JWA changes will occur >> that are part of the JWE changes. I don't anticipate significant >> changes after that. (Making these changes is my highest priority >> as JOSE editor. I'm hoping to have drafts out containing them by >> the end of August, which hopefully fits well with the WebCrypto >> schedule.) I write all of the above with the caveat that the >> working group is, of course, free to change things as they see fit. >> >> I look forward to a productive discussion of this coordination >> request in both working groups. >> >> Best wishes, >> -- Mike >> >> P.S. If you prefer, a HTML-formatted version of the private key >> spec is available at >> http://self-issued.info/docs/draft-jones-jose-json-private-key.html. >> I also blogged about this draft specification at >> http://self-issued.info/?p=816. >> >> >> -----Original Message----- >> From: Harry Halpin [mailto:hhalpin@w3.org ] >> Sent: Sunday, August 12, 2012 8:03 AM >> >> To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org >> ; Mike Jones >> Subject: JOSE WG request from W3C WebCrypto API >> >> [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] >> >> JOSE Chairs, >> >> The Web Cryptography Working group has noted that the API >> requires some access to raw key material, and the issue of >> whether or not to use JWK or ASN.1 as the default format came up. >> Two issues have come out that we'd like to know the answer to: >> >> 1) JWK does not define a private key format. Does the JOSE WG >> plan to support a JOSE-format for private keys? If so, when? Or >> 'maybe'? >> >> 2) While we'd like encourage the use of JOSE over ASN.1, it >> seems like for backwards compatibility having some level of ASN.1 >> support would be useful and we *need* a format that allows key >> material (both private and >> public) to be exported. Folks seem to leaning towards ASN.1 as a >> default format in the low-level API, and having JWK as a format >> that can be built on top of that in a possible high-level API. >> Would that be OK? >> >> 3) How stable do you believe the JOSE formats are right now? Do >> you think they are stable enough now we can reference them in our >> API draft at end of August? If not, when? The W3C would like to >> and plan to use these formats where possible. >> >> Feel free to forward this by JOSE WG for discussion. We'd like an >> answer before we send our document to FPWD at end of August. >> >> cheers, >> harry >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> _______________________________________________ >> >> 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 --------------030308030701030706090304 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Meant to say "accidentally grab the private keys" below, obviously. I care somewhat less about who grabs my public keys.

 -- Justin

On 08/17/2012 01:21 PM, Justin Richer wrote:

Justin, per my reply to James, putting the two in the same structure seems to be existing practice for other APIs.  It’s certainly the simplest solution.  I don’t see that the safety properties would be any different whether there are “public” and “private” members with sub-members for the key fields, or simply a flat structure of key members, which is currently what’s specified.  In both cases, if there is private key information present, it *must* be appropriately protected.

Right, when you put it in those terms it makes more sense. The keys are going to be contained in the same root object structure either way, and it'd be just as likely for someone to accidentally grab the public keys in both cases.

 -- Justin
 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, August 17, 2012 7:14 AM
To: Nat Sakimura
Cc: Mike Jones; Jim Schaad; jose-chairs@tools.ietf.org; Harry Halpin; jose@ietf.org; Karen O'Donoghue
Subject: Re: [jose] JOSE WG request from W3C WebCrypto API

 

Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it.

 -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:

Thanks Mike. 

 

Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. 

 

Thoughts? 

 

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Thanks for writing, Harry and WebCrypto WG.

1)  About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation.  To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.  You'll see that doing this is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.  This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference.

I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it.  However, as I see it, the W3C WebCrypto API use case changes things.  Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining private key formats.  (It simply requires the definition of public key formats and is silent on the topic of private keys.)

2)  I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates).  However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3)  It appears to me the JWK format is stable.  I believe the JWS format is stable as well.  The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago.  Some JWA changes will occur that are part of the JWE changes.  I don't anticipate significant changes after that.  (Making these changes is my highest priority as JOSE editor.  I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.)  I write all of the above with the caveat that the working group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in both working groups.

                                Best wishes,
                                -- Mike

P.S.  If you prefer, a HTML-formatted version of the private key spec is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html.  I also blogged about this draft specification at http://self-issued.info/?p=816.


-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org]
Sent: Sunday, August 12, 2012 8:03 AM

To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'?

  2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when?  The W3C would like to and plan to use these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August.

  cheers,
      harry



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



 

--
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 




_______________________________________________
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

--------------030308030701030706090304-- From bobwyman@gmail.com Fri Aug 17 13:37:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C070611E80E0 for ; Fri, 17 Aug 2012 13:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyNRDFZ6h0E7 for ; Fri, 17 Aug 2012 13:37:48 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9708111E80E1 for ; Fri, 17 Aug 2012 13:37:48 -0700 (PDT) Received: by ggnh4 with SMTP id h4so4817475ggn.31 for ; Fri, 17 Aug 2012 13:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Yj9VPdVwGCI9A5nCKgxs3d9c8rdLJjiR+CoMU0ixeVo=; b=N5egM9UXF3Q85UIH9QS0ZPtyTIEpb1IMtt0haFd95p/gNrpgtO8emUrptO77ajc4HU T3i9YyXBa6fbnlqS+ocq1+xGP1mqr2JCP0iD2jBhfjmcURaVlI11eLjqAwV4igemCM/P G0gXRstV5YyUfCBhHwE8CRP2cVVSEeRiIvBBk8SQoAXLmrAuckqXNYMR+artSgssHcrM WGRig3KXmqhznP5zMrNdjf31LjMOKpxQLFAdCr0qnJVnl/i8sOxy6MrV1jFD7zJSLFkF y5rQs1n+FESi2eGHpUN/5yDjd3NGUhj2jRHgnCnLC7q23hyerQyeoTmkKH99o18Qs0S0 nfvQ== MIME-Version: 1.0 Received: by 10.50.85.230 with SMTP id k6mr3129001igz.49.1345235866476; Fri, 17 Aug 2012 13:37:46 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.64.148.76 with HTTP; Fri, 17 Aug 2012 13:37:46 -0700 (PDT) Date: Fri, 17 Aug 2012 16:37:46 -0400 X-Google-Sender-Auth: RgigIYuVlEFjaolhGKjHmaZm08w Message-ID: From: Bob Wyman To: JOSE IETF Content-Type: multipart/alternative; boundary=e89a8f3ba85bf5e23f04c77c2178 Subject: [jose] Why three parts, not four? (Multiple, aggregated signatures for single object use case) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:37:49 -0000 --e89a8f3ba85bf5e23f04c77c2178 Content-Type: text/plain; charset=ISO-8859-1 In reading JOSE specs, I can't help asking a question that I asked some time ago in the Magic Signatures discussion: Why does a signature contain three parts instead of four? Please let me know if what I wish to do, as described below, can be done with JOSE today. Perhaps I've missed something... The reason I ask is that I'm interested in the set of use cases that involve multiple people signing a single payload. In order to store the multiple signatures and in order to create messages that represent the payload packaged with a set of multiple signatures, it would be convenient if the JWS Header and Payload encodings were the same for all signatures and thus did not contain any data specific to an individual signature. Given the current specs, the payload bits might, in fact, be the same for multiple JOSE signed messages, but since the JWS header contains information specific to the signature (i.e. optional jwk value, etc.) in addition to information about the payload (like type, etc.) it might not be possible for two signers to share the same JWS Header and Payload bits... If JOSE signatures supported a four part representation, the JWS header would only 1) Identify the header as a JWS header and 2) contain data concerning the payload's type and encoding. Signatures would then have two parts: 1) A signature header, and 2) the signature itself. The signature header would be Base64URLencoded, just like JWS Headers. Thus, a four-part object might look like: ... The advantage of such a four part system is that I could then take the following three signed objects: ... ... ... and combine them into a single, smaller object that looked something like this: ....... Doing so would potentially save a great deal of storage and/or communication resource as well as make it easier to communicate the presence of multiple signatures. Note: If this business of using multiple signatures on a single header/payload pair was supported, I think I might also ask for some syntax to make handling sets of signatures easier. Something like the following might be reasonable: ..[.,.] Having distinct signature headers would also allow me to do another thing I need for my use case, which is to record not just the signature, but information concerning why the signature was created. Thus, I could distinguish between an assertion of "authorship" over the payload, a claim of acceptance of whatever was asserted in the payload (i.e. "I agree." or "I accept."), the inverse of that ("I disagree.") or whatever... Given the current three part system, any such signer-specific statements would have to be included in the payload body and that would make it impossible to have multiple signatures for the same payload unless all signers were making precisely the same statement with their signatures. Is there a strong reason why signature specific data is included in the JWS Header or is that just a case of path-dependence? Is there some way to address my concerns for the use cases hinted at above with JOSE signatures as currently defined? bob wyman --e89a8f3ba85bf5e23f04c77c2178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In reading JOSE specs, I can't help asking a question that I asked some= time ago in the Magic Signatures discussion:

Why does a= signature contain three parts instead of four? Please let me know if what = I wish to do, as described below, can be done with JOSE today. Perhaps I= 9;ve missed something...

The reason I ask is that I'm interested in the set = of use cases that involve multiple people signing a single payload. In orde= r to store the multiple signatures and in order to create messages that rep= resent the payload packaged with a set of multiple signatures, it would be = convenient if the JWS Header and Payload encodings were the same for all si= gnatures and thus did not contain any data specific to an individual signat= ure. Given the current specs, the payload bits might, in fact, be the same = for multiple JOSE signed messages, but since the JWS header contains inform= ation specific to the signature (i.e. optional jwk value, etc.) in addition= to information about the payload (like type, etc.) it might not be possibl= e for two signers to share the same JWS Header and Payload bits...

If JOSE signatures supported a four part representation= , the JWS header would only 1) Identify the header as a JWS header and 2) c= ontain data concerning the payload's type and encoding. Signatures woul= d then have two parts: 1) A signature header, and 2) the signature itself. = The signature header would be Base64URLencoded, just like JWS Headers. Thus= , a four-part object might look like:

<JWS Header>.<Payload>.<Signatur= e Header>.<Signature>

The advantag= e of such a four part system is that I could then take the following three = signed objects:
<JWS_Header>.<Payload&g= t;.<Signature Header 1>.<Signature 1>
<JWS_Header>.<Payload>.<S= ignature Header 2>.<Signature 2>
<JWS_Header>.&l= t;Payload>.<Signature Header 3>.<Signature 3>

and combine them into a single, smaller object that= looked something like this:
<JWS_Header>.<Payload&g= t;.<Signature Header 1>.<Signature 1>.<Signature Header 2>= ;.<Signature 2>.<Signature Header 3>.<Signature 3>=

Doing so would potentially save a great deal of storage= and/or communication resource as well as make it easier to communicate the= presence of multiple signatures.
Note: If this business of using= multiple signatures on a single header/payload pair was supported, I think= I might also ask for some syntax to make handling sets of signatures easie= r. Something like the following might be reasonable:
<JWS_He= ader>.<Payload>.[<Signature Header 1>.<Signature 1>,<Signature Head= er 2>.<Signature 2>]

Having distinct signature headers would also allow me t= o do another thing I need for my use case, which is to record not just the = signature, but information concerning why the signature was created. Thus, = I could distinguish between an assertion of "authorship" over the= payload, a claim of acceptance of whatever was asserted in the payload (i.= e. "I agree." or "I accept."), the inverse of that (&qu= ot;I disagree.") or whatever... Given the current three part system, a= ny such signer-specific statements would have to be included in the payload= body and that would make it impossible to have multiple signatures for the= same payload unless all signers were making precisely the same statement w= ith their signatures.

Is there a strong reason why signature specific data is= included in the JWS Header or is that just a case of path-dependence? Is t= here some way to address my concerns for the use cases hinted at above with= JOSE signatures as currently defined?

bob wyman


--e89a8f3ba85bf5e23f04c77c2178-- From rbarnes@bbn.com Fri Aug 17 14:58:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA6321F847B for ; Fri, 17 Aug 2012 14:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTG7n-Da9it0 for ; Fri, 17 Aug 2012 14:58:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76221F847A for ; Fri, 17 Aug 2012 14:58:29 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:58930) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T2UYm-0008IT-KG for jose@ietf.org; Fri, 17 Aug 2012 17:58:28 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Aug 2012 17:58:27 -0400 Message-Id: To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:58:30 -0000 Hey all, At IETF 84, I suggested that we take another look at what header = information gets integrity-protected and what doesn't. The main issue = being that in multiple-recipient or multiple-signer scenarios, there's = unnecessary duplication of data if recipient- or signer-specific = information is in the integrity-protected header. Following some on what Bob Wyman proposed this afternoon, I would like = to propose that we split the set of header fields into some logical = groupings: 1. Top-level fields that require integrity protection (e.g., cty or a = digest algorithm parameter) 2. Top-level fields that do not require integrity protection (e.g., x5c) 3. Fields that are specific to a signer (e.g., jwk) 4. Fields that are specific to a recipient (e.g., epk) In this taxonomy, only fields of type (1) need to be base64-encoded for = to preserve their serialization, and fields of type (3) and (4) could be = gathered together into the moral equivalent of SignerInfo and = RecipientInfo objects. All this makes the JSON serialization a lot = cleaner, for example: { "type": "S", "header": "[base64-type1]", "params": { /* type2 */ }, "content": "[base64-content]", "signers": [ { /* type3 */ } ] } You can also imagine a reasonable compact serialization, something like: = S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-= signer2]. ... That encoding even has the benefit that the multi-signer case doesn't = add any overhead over the single-signer case, except for maybe a couple = of "." characters. (Obviously, you would want some structure on how the = signer info gets serialized, but that's another level of detail down. = You could imagine something like = "[signer-header].[public-key].[signature-value]".) The additional structure might seem like it's more work to parse, but I = don't think it's really that bad. Given a parsed JOSE object "obj": 1. Decode obj.header and add its fields to obj.params 2. Look through "signers" / "recipients" to find one we understand 3. Verify / decrypt content using signer/recipient info and parameters There are several details to be worked out -- most critically, which = fields go in which groupings -- but I thought I would throw out the = general idea for comment before diving into the details. Cheers, --Richard From mamille2@cisco.com Fri Aug 17 15:24:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB221E8063 for ; Fri, 17 Aug 2012 15:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.285 X-Spam-Level: X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5X7y1iDDAes for ; Fri, 17 Aug 2012 15:24:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D946311E80A4 for ; Fri, 17 Aug 2012 15:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=7225; q=dns/txt; s=iport; t=1345242269; x=1346451869; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z4SMelRxUa0J5CnGGwZgbp5EoffD21dBraKzAKeAdK8=; b=h6V/nTz541/gBqs0rQZkslFR7uOArX+53+CSnEuCxVCsVYvmSa90r08U VEQUiXWo5CCtLWngR0aIynrvblN8BaKHyAECiSdi00iT+qR2TKxifA/Y1 jfn+mVVQZRV1WXOD7f64saSo65vUldBL0Ucl5WC12mbDURvXJsp6laMGW 8=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALvDLlCtJXHA/2dsb2JhbABFuj+BB4IgAQEBAwEBAQEPAVsLBQsCAQhGAiULJQIEDgUOFIdlBguaDKA2BIsLhhtgA45agSCFVY4sgWaCYA X-IronPort-AV: E=Sophos;i="4.77,788,1336348800"; d="sig'?p7s'?scan'208";a="112836753" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 Aug 2012 22:24:28 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7HMOSuP026506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 22:24:28 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.219]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Fri, 17 Aug 2012 17:24:27 -0500 From: "Matt Miller (mamille2)" To: "Richard L. Barnes" Thread-Topic: [jose] Splitting headers Thread-Index: AQHNfMNxsnde0xV9wEGIc/Ypg7RBo5de6GyA Date: Fri, 17 Aug 2012 22:24:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19122.001 x-tm-as-result: No--43.352500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-34--284634176" MIME-Version: 1.0 Cc: "" Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 22:24:29 -0000 --Apple-Mail-34--284634176 Content-Type: multipart/signed; boundary=Apple-Mail-33--284634178; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-33--284634178 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This seems reasonable to me. I'm interested to see a specific take on encryption. - m&m Matt Miller - Cisco Systems, Inc. On Aug 17, 2012, at 15:58, Richard L. Barnes wrote: > Hey all, >=20 > At IETF 84, I suggested that we take another look at what header = information gets integrity-protected and what doesn't. The main issue = being that in multiple-recipient or multiple-signer scenarios, there's = unnecessary duplication of data if recipient- or signer-specific = information is in the integrity-protected header. >=20 > Following some on what Bob Wyman proposed this afternoon, I would like = to propose that we split the set of header fields into some logical = groupings: > 1. Top-level fields that require integrity protection (e.g., cty or a = digest algorithm parameter) > 2. Top-level fields that do not require integrity protection (e.g., = x5c) > 3. Fields that are specific to a signer (e.g., jwk) > 4. Fields that are specific to a recipient (e.g., epk) >=20 > In this taxonomy, only fields of type (1) need to be base64-encoded = for to preserve their serialization, and fields of type (3) and (4) = could be gathered together into the moral equivalent of SignerInfo and = RecipientInfo objects. All this makes the JSON serialization a lot = cleaner, for example: >=20 > { > "type": "S", > "header": "[base64-type1]", > "params": { /* type2 */ }, > "content": "[base64-content]", > "signers": [ > { /* type3 */ } > ] > } >=20 > You can also imagine a reasonable compact serialization, something = like: >=20 > = S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-= signer2]. ... >=20 > That encoding even has the benefit that the multi-signer case doesn't = add any overhead over the single-signer case, except for maybe a couple = of "." characters. (Obviously, you would want some structure on how the = signer info gets serialized, but that's another level of detail down. = You could imagine something like = "[signer-header].[public-key].[signature-value]".) >=20 > The additional structure might seem like it's more work to parse, but = I don't think it's really that bad. Given a parsed JOSE object "obj": > 1. Decode obj.header and add its fields to obj.params > 2. Look through "signers" / "recipients" to find one we understand > 3. Verify / decrypt content using signer/recipient info and parameters >=20 > There are several details to be worked out -- most critically, which = fields go in which groupings -- but I thought I would throw out the = general idea for comment before diving into the details. >=20 > Cheers, > --Richard >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-33--284634178 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgxNzIyMjQy OVowIwYJKoZIhvcNAQkEMRYEFLkVA+qGHtDgcbXgrodq2oA/XuRCMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAvYQksr4/PRNhXiUiT3TKKgaXN71alyXtVuSzd7yxRs/4Jcvpo+IslQekX CQ2tMssqnKUsUdKlzq2b4oz/ArwRHffy5CcyXwe5Y79gAa6gywJoB5iVUtlOyI52sXigGpPOnX7R yp+VIQGAVHW7HrZTMRcXYK8Wunwjkj4gT8ADMhFwa7ua960iXgvnmI94fNh7gWCZNS+YZ+qcKaQB szre55jUD8cvAFMnTq+h4fV+x+E8KSDOgiVYhpAEUsGlaO0Bf9Wh3/Wj00MmWLD91/V0MBBK5sOZ Aqqco427SYxjz6xrsAW4+f2oUF0VnUxEfDJF/jIxBWz/QGjLnecLk7BRAAAAAAAA --Apple-Mail-33--284634178-- --Apple-Mail-34--284634176 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQLsSeAAoJEJq6Ou0cgrSP1sAIANs3pjU1Vt5vjtu9wdizhYhN +yYJXVjdYyS12qICyVhR+3isVsDhRYT6OHaBUTXZbpaIHM+IybtJ4gvSdWHzkWwz x/e1cIljsDvchXXFnPHgqlMZI5uzmIqTlgBwWnmHf1tzxJWOglHAYkvatDueVFRJ wK59L2vp9XjgN/Fpi534DZGS1Sr8FXnq9+F1TJ51W4tEN7lbiTkbemHUqZKyiXBJ 3CVACfShxO75R5hkKIN2/sZdfi+iKia9LixTDBI0ytwHi9KOEpUU5+ZdIAtvGOdk 6iWVRA+5zjCIb8D1Em9TxToNiqRjZ/BYugb6fjV/PbUYachqQhuDV0mKZFTl8l0= =SAzD -----END PGP SIGNATURE----- --Apple-Mail-34--284634176-- From rbarnes@bbn.com Fri Aug 17 15:52:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5168821F84B6 for ; Fri, 17 Aug 2012 15:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.279 X-Spam-Level: X-Spam-Status: No, score=-106.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwe60F1Kkb09 for ; Fri, 17 Aug 2012 15:52:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5521F849D for ; Fri, 17 Aug 2012 15:52:39 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:59149) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T2VOt-000DuS-Ri; Fri, 17 Aug 2012 18:52:19 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 17 Aug 2012 18:52:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3237A855-316E-4B79-9DA8-4DAC74650DC5@bbn.com> References: To: "Matt Miller (mamille2)" X-Mailer: Apple Mail (2.1278) Cc: "" Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 22:52:40 -0000 On Aug 17, 2012, at 6:24 PM, Matt Miller (mamille2) wrote: > This seems reasonable to me. >=20 > I'm interested to see a specific take on encryption. In the same "outline" form as for signature below: { "type": "E", "header": "[base64-type1]", "params": { /* type2 */ }, "content": "[base64-content]", "recipients": [ { /* type3 */ } ] } Note that because we've removed the recipient-specific parameters from = the top-level "header" field, the integrity check value is the same for = every recipient. So if you're using an algorithm that integrates the = ICV into the ciphertext (e.g., CCM), it will be part of the "content" = value; otherwise, we could add an "integrity-check" field at the top = level. While I'm covering the different cases, note that MAC is a hybrid of = these two. The MAC key is wrapped for each recipient, but the MAC value = is constant/top-level. { "type": "A", "header": "[base64-type1]", "params": { /* type2 */ }, "content": "[base64-content]", "mac": "[base64-mac]", "recipients": [ { /* type3 */ } ] } Similar compact encoding tricks can be applied here as in the signature = case. --Richard >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > On Aug 17, 2012, at 15:58, Richard L. Barnes wrote: >=20 >> Hey all, >>=20 >> At IETF 84, I suggested that we take another look at what header = information gets integrity-protected and what doesn't. The main issue = being that in multiple-recipient or multiple-signer scenarios, there's = unnecessary duplication of data if recipient- or signer-specific = information is in the integrity-protected header. >>=20 >> Following some on what Bob Wyman proposed this afternoon, I would = like to propose that we split the set of header fields into some logical = groupings: >> 1. Top-level fields that require integrity protection (e.g., cty or a = digest algorithm parameter) >> 2. Top-level fields that do not require integrity protection (e.g., = x5c) >> 3. Fields that are specific to a signer (e.g., jwk) >> 4. Fields that are specific to a recipient (e.g., epk) >>=20 >> In this taxonomy, only fields of type (1) need to be base64-encoded = for to preserve their serialization, and fields of type (3) and (4) = could be gathered together into the moral equivalent of SignerInfo and = RecipientInfo objects. All this makes the JSON serialization a lot = cleaner, for example: >>=20 >> { >> "type": "S", >> "header": "[base64-type1]", >> "params": { /* type2 */ }, >> "content": "[base64-content]", >> "signers": [ >> { /* type3 */ } >> ] >> } >>=20 >> You can also imagine a reasonable compact serialization, something = like: >>=20 >> = S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-= signer2]. ... >>=20 >> That encoding even has the benefit that the multi-signer case doesn't = add any overhead over the single-signer case, except for maybe a couple = of "." characters. (Obviously, you would want some structure on how the = signer info gets serialized, but that's another level of detail down. = You could imagine something like = "[signer-header].[public-key].[signature-value]".) >>=20 >> The additional structure might seem like it's more work to parse, but = I don't think it's really that bad. Given a parsed JOSE object "obj": >> 1. Decode obj.header and add its fields to obj.params >> 2. Look through "signers" / "recipients" to find one we understand >> 3. Verify / decrypt content using signer/recipient info and = parameters >>=20 >> There are several details to be worked out -- most critically, which = fields go in which groupings -- but I thought I would throw out the = general idea for comment before diving into the details. >>=20 >> Cheers, >> --Richard >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From hhalpin@w3.org Fri Aug 17 05:52:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C033921F84B6 for ; Fri, 17 Aug 2012 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLX5lu4cAn-M for ; Fri, 17 Aug 2012 05:52:16 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 92DFB21F84B5 for ; Fri, 17 Aug 2012 05:52:16 -0700 (PDT) Received: from [199.254.238.206] (helo=[172.27.0.43]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1T2M1s-0003aw-FP; Fri, 17 Aug 2012 08:51:57 -0400 Message-ID: <502E3E65.4090405@w3.org> Date: Fri, 17 Aug 2012 14:51:49 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Aug 2012 17:11:57 -0700 Cc: Jim Schaad , "jose-chairs@tools.ietf.org" , "jose@ietf.org" , Karen O'Donoghue Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:52:17 -0000 On 08/16/2012 01:19 AM, Mike Jones wrote: > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation. To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. You'll see that doing this is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys. This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference. cheer If that could be done, that would be great. Just keep WebCrypto in the loop. > > I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it. However, as I see it, the W3C WebCrypto API use case changes things. Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible. > > Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining private key formats. (It simply requires the definition of public key formats and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates). However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense. My feeling, and we've expressed this on telecons, is that we want JOSE compatibility, especially to encourage WebApp developers who are not crypto experts, as I imagine they would likely rather deal with JOSE than ASN.1. Our API is likely going to have a "lower-level" for general application programming version that will support ASN.1 due , and a "higher-level" one for WebApp developers come out later (in about 6 months). > > 3) It appears to me the JWK format is stable. I believe the JWS format is stable as well. The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago. Some JWA changes will occur that are part of the JWE changes. I don't anticipate significant changes after that. (Making these changes is my highest priority as JOSE editor. I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.) I write all of the above with the caveat that the working group is, of course, free to change things as they see fit. I think the JOSE WG is moving ahead of us nicely, so I imagine having things stabilized in about 6 months would be perfect in order to be used with the "higher-level" API. cheers, harry > > I look forward to a productive discussion of this coordination request in both working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key spec is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html. I also blogged about this draft specification at http://self-issued.info/?p=816. > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when? The W3C would like to and plan to use these formats where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August. > > cheers, > harry > > > > From sakimura@gmail.com Fri Aug 17 20:27:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68221E805A for ; Fri, 17 Aug 2012 20:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk3VhUwRwXat for ; Fri, 17 Aug 2012 20:27:07 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5421E8048 for ; Fri, 17 Aug 2012 20:27:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7051896obb.31 for ; Fri, 17 Aug 2012 20:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=NMmL4HFmgyML4ykLuttUnhxnXOrz32nGSkUxHxt5P3A=; b=RSpJcOGWZIbyP7v1s/87tftcggqJKR6ALmSERcCXjL29ATSw7oWMr4J82H7fs1YWOm G56v/FjcsxD4HyrY+He+/wX8SoWSHYFKqj9nU1LgZiOFnsUbj8nf/6pXcbvIdGK9rUvd hlfa+2giUZU11Yto70W5apNw2qZGuYnAZavYiHtHmfn9hPCnjAyhGUxrsMJguW2u9RlE Qb9BirgUjcwXY4MnThhWlF4+N7rIk+bJCSGwy4jQEyunDN5SWMzonsoZn3o1indNlxhR aM09lu8vSbBgFldT72h2tE6myLZGO+csHbBIKjbwq8a3ZZkJggo5gEaGAKiY4nIHXpO8 EWLA== Received: by 10.50.189.227 with SMTP id gl3mr3829268igc.34.1345260423317; Fri, 17 Aug 2012 20:27:03 -0700 (PDT) References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <502E51A5.5080401@mitre.org> From: Nat Sakimura In-Reply-To: <502E51A5.5080401@mitre.org> Mime-Version: 1.0 (1.0) Date: Sat, 18 Aug 2012 12:27:03 +0900 Message-ID: <8039706901170831017@unknownmsgid> To: Justin Richer Content-Type: multipart/alternative; boundary=14dae9340f73a98a1904c781d9e7 Cc: "jose-chairs@tools.ietf.org" , Harry Halpin , Karen O'Donoghue , Jim Schaad , Mike Jones , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 03:27:09 -0000 --14dae9340f73a98a1904c781d9e7 Content-Type: text/plain; charset=ISO-8859-1 The rationale for having the encrypted keys were because I thought that the main use case were to transfer keys from one system to another, while it stays within a system, hopefully we can use platform supplied storage mechanism and key store. Now, your use case is different. You want to use the JWK private key stored in the local file system to sign or encrypt messages. For that, I agree it is turtles all the way. System implementers needs to be careful on how the process authentication is done when allowing the access to the key file is done though. =nat via iPhone On Aug 17, 2012, at 11:15 PM, Justin Richer wrote: Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way. I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well. However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it. -- Justin [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ On 08/16/2012 10:26 PM, Nat Sakimura wrote: Thanks Mike. Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. Thoughts? Nat On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones wrote: > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally think > it would be valuable for JOSE to define a JSON private key representation. > To make this concrete, I would propose the private key representations > specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. > You'll see that doing this is very simple; it just defines two additional > members for the JWK structure for representing the private parts of > Elliptic Curve and RSA keys. This could either remain a separate spec from > JWK/JWA or be merged in, at the working group's preference. > > I had previously agreed with the position that it was not necessary for > JOSE to define private key representations because we didn't have a use > case for it. However, as I see it, the W3C WebCrypto API use case changes > things. Better for JOSE to be responsive to WebCrypto and add this simple > extension, either as a new spec or in the existing specs, than to leave > this undone, and have it potentially be an area where otherwise > standards-compliant implementations diverge, and where JSON-only solutions > are not possible. > > Finally, I'll note that the JOSE charter > http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining > private key formats. (It simply requires the definition of public key > formats and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for backwards > compatibility in some cases (just as the JOSE specs allow the use of X.509 > certificates). However, I believe it would be a shame to preclude > JSON-only solutions by not supporting key import/export in JWK format, > where such solutions make sense. > > 3) It appears to me the JWK format is stable. I believe the JWS format > is stable as well. The JWE format has known changes that will be applied > shortly, based upon working group discussions at IETF 84 in Vancouver two > weeks ago. Some JWA changes will occur that are part of the JWE changes. > I don't anticipate significant changes after that. (Making these changes > is my highest priority as JOSE editor. I'm hoping to have drafts out > containing them by the end of August, which hopefully fits well with the > WebCrypto schedule.) I write all of the above with the caveat that the > working group is, of course, free to change things as they see fit. > > I look forward to a productive discussion of this coordination request in > both working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key spec is > available at > http://self-issued.info/docs/draft-jones-jose-json-private-key.html. I > also blogged about this draft specification at > http://self-issued.info/?p=816. > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some > access to raw key material, and the issue of whether or not to use JWK or > ASN.1 as the default format came up. Two issues have come out that we'd > like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to > support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like > for backwards compatibility having some level of ASN.1 support would be > useful and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default > format in the low-level API, and having JWK as a format that can be built > on top of that in a possible high-level API. Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do you > think they are stable enough now we can reference them in our API draft at > end of August? If not, when? The W3C would like to and plan to use these > formats where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an answer > before we send our document to FPWD at end of August. > > cheers, > harry > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ jose mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose --14dae9340f73a98a1904c781d9e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The rationale for having = the encrypted keys were because I thought that the main use case were to tr= ansfer keys from one system to another, while it stays within a system, hop= efully we can use platform supplied storage mechanism and key store.=A0

Now, your use case is different. You want to use the JW= K private key stored in the local file system to sign or encrypt messages. = For that, I agree it is turtles all the way. System implementers needs to b= e careful on how the process authentication is done when allowing the acces= s to the key file is done though.=A0

=3Dnat via iPhone

On Aug 17, 2012, at 11:15 PM, Just= in Richer <jricher@mitre.org>= ; wrote:

=20 =20 =20
Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could caus= e a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it.
=A0-- Justin

[1] http://thesmithfam.org/blog/2011/0= 2/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:
Thanks Mike.=A0

Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner.=A0

Thoughts?=A0

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks for writing, Harry and WebCrypto WG.

1) =A0About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation. =A0To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. =A0You'll see that doing this is very simple; it just defin= es two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys. =A0This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference.

I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it. =A0However, as I = see it, the W3C WebCrypto API use case changes things. =A0Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker= .ietf.org/wg/jose/charter/ does not preclude defining private key formats. =A0(It simply requires the definition of public key formats and is silent on the topic of private keys.)

2) =A0I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates). =A0However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3) =A0It appears to me the JWK format is stable. =A0I believe the JWS format is stable as well. =A0The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago. =A0Some JWA changes will occur that are part of the JWE changes. =A0I don't anticipate significant changes after th= at. =A0(Making these changes is my highest priority as JOSE editor. =A0I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.) =A0I write all of the above with the caveat that the working group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in both working groups.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Best wishes,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= -- Mike

P.S. =A0If you prefer, a HTML-formatted version of the private key spec is available at http://self-iss= ued.info/docs/draft-jones-jose-json-private-key.html. =A0I also blogged about this draft specification at http://self-issued.info= /?p=3D816.

-----Original Message-----
From: Harry Halpin [mailto:= hhalpin@w3.org]
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; = jose-chairs@tools.ietf.org; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'?

=A0 2) While we'd like encourage the use of JOSE over ASN= .1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK?

=A0 3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when? =A0The W3C would like to and plan to use these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August.

=A0 cheers,
=A0 =A0 =A0 harry




___________________________________________= ____
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat= .sakimura.org/
@_nat_en



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

=20
--14dae9340f73a98a1904c781d9e7-- From ietf@augustcellars.com Sat Aug 18 03:33:52 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A975121F8575 for ; Sat, 18 Aug 2012 03:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBR1pLOrA9Ou for ; Sat, 18 Aug 2012 03:33:51 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7698F21F8578 for ; Sat, 18 Aug 2012 03:33:50 -0700 (PDT) Received: from Tobias (unknown [210.11.218.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2A91438F0B; Sat, 18 Aug 2012 03:33:47 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Harry Halpin'" References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 18 Aug 2012 20:02:19 +0930 Message-ID: <023301cd7d2c$c2f71c60$48e55520$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLFlfTqqE/AKW0D4NQ2kQBPiDZx7QIHVRRoAeECGDmVTx6fUA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 10:33:52 -0000 Mike, You have said that you think that doing this as JOSE structures would be useful. It is not clear to me that there is actually a use case defined here that bears that out. Who is responsible for building and encrypting (or decrypting and parsing) the structure? Are we suggesting that the private keys be exported in the clear and it is up to the JOSE developer to encrypt them or are we saying that it is up to the WebCrypto system to do this on behalf of the JOSE developer? If we say it is the JOSE developer, then this introduces lots of places where the private keys will be handled insecurely - if nothing else from just hanging around in memory until they get cleaned up. If we say that it is the WebCrypto system that does this, then we are saying that we don't really care what the format of the private key blobs is internally, we just need to know how to deal with them from the scripting side - which would be as a blob of some type (either a binary blob or a string blob). Finally, how much do we want this to be a portable method of doing key transport? All of the browsers currently have a method of doing an import and export of an ASN.1 private key blob. What is the additional benefit that you think would be obtained from the WebCrypto side from having a second format that all of the browsers would need to support, but which might not have the same level of support from various operating systems and key devices? Would this then lead to scripters needing to have two different sets of import/export code depending on what the internal structure was and potentially needed to switch between the two structures? I think it makes sense to allow for the use of JOSE public keys since that is being passed in the message structure itself. I don't believe that it makes a great deal of sense at this point in time to have a private key structure defined. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, August 16, 2012 8:49 AM > To: Harry Halpin; Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org > Cc: jose@ietf.org > Subject: RE: JOSE WG request from W3C WebCrypto API > > Thanks for writing, Harry and WebCrypto WG. > > 1) About private keys, given the WebCrypto use case, I personally think it > would be valuable for JOSE to define a JSON private key representation. To > make this concrete, I would propose the private key representations > specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. > You'll see that doing this is very simple; it just defines two additional > members for the JWK structure for representing the private parts of Elliptic > Curve and RSA keys. This could either remain a separate spec from JWK/JWA > or be merged in, at the working group's preference. > > I had previously agreed with the position that it was not necessary for JOSE > to define private key representations because we didn't have a use case for > it. However, as I see it, the W3C WebCrypto API use case changes things. > Better for JOSE to be responsive to WebCrypto and add this simple > extension, either as a new spec or in the existing specs, than to leave this > undone, and have it potentially be an area where otherwise standards- > compliant implementations diverge, and where JSON-only solutions are not > possible. > > Finally, I'll note that the JOSE charter > http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining > private key formats. (It simply requires the definition of public key formats > and is silent on the topic of private keys.) > > 2) I agree on the likely need for WebCrypto support ASN.1 for backwards > compatibility in some cases (just as the JOSE specs allow the use of X.509 > certificates). However, I believe it would be a shame to preclude JSON-only > solutions by not supporting key import/export in JWK format, where such > solutions make sense. > > 3) It appears to me the JWK format is stable. I believe the JWS format is > stable as well. The JWE format has known changes that will be applied > shortly, based upon working group discussions at IETF 84 in Vancouver two > weeks ago. Some JWA changes will occur that are part of the JWE changes. I > don't anticipate significant changes after that. (Making these changes is my > highest priority as JOSE editor. I'm hoping to have drafts out containing them > by the end of August, which hopefully fits well with the WebCrypto > schedule.) I write all of the above with the caveat that the working group is, > of course, free to change things as they see fit. > > I look forward to a productive discussion of this coordination request in both > working groups. > > Best wishes, > -- Mike > > P.S. If you prefer, a HTML-formatted version of the private key spec is > available at http://self-issued.info/docs/draft-jones-jose-json-private- > key.html. I also blogged about this draft specification at http://self- > issued.info/?p=816. > > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones > Subject: JOSE WG request from W3C WebCrypto API > > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > > JOSE Chairs, > > The Web Cryptography Working group has noted that the API requires some > access to raw key material, and the issue of whether or not to use JWK or > ASN.1 as the default format came up. Two issues have come out that we'd > like to know the answer to: > > 1) JWK does not define a private key format. Does the JOSE WG plan to > support a JOSE-format for private keys? If so, when? Or 'maybe'? > > 2) While we'd like encourage the use of JOSE over ASN.1, it seems like for > backwards compatibility having some level of ASN.1 support would be useful > and we *need* a format that allows key material (both private and > public) to be exported. Folks seem to leaning towards ASN.1 as a default > format in the low-level API, and having JWK as a format that can be built on > top of that in a possible high-level API. Would that be OK? > > 3) How stable do you believe the JOSE formats are right now? Do you think > they are stable enough now we can reference them in our API draft at end of > August? If not, when? The W3C would like to and plan to use these formats > where possible. > > Feel free to forward this by JOSE WG for discussion. We'd like an answer > before we send our document to FPWD at end of August. > > cheers, > harry > > From ietf@augustcellars.com Sat Aug 18 03:34:28 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF2221F8575 for ; Sat, 18 Aug 2012 03:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhpuWhMNv1ZR for ; Sat, 18 Aug 2012 03:34:27 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id E257821F8570 for ; Sat, 18 Aug 2012 03:34:27 -0700 (PDT) Received: from Tobias (unknown [210.11.218.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A049038EF2 for ; Sat, 18 Aug 2012 03:34:26 -0700 (PDT) From: "Jim Schaad" To: Date: Sat, 18 Aug 2012 20:02:59 +0930 Message-ID: <023e01cd7d2c$d981fc20$8c85f460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac19LLhObpR4vkBXT6KFVPlMy4J5tA== Content-Language: en-us Subject: [jose] Poll Additional Informaiton X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 10:34:28 -0000 After sending the messages I noted the following omissions 1. Poll will be finished on 1 September 2. Karen will be making the consensus calls as I have been a participant in several of the arguments. Jim From ietf@augustcellars.com Sat Aug 18 04:09:50 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37421F8522 for ; Sat, 18 Aug 2012 04:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcJRf39pyml6 for ; Sat, 18 Aug 2012 04:09:49 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id C202F21F8498 for ; Sat, 18 Aug 2012 04:09:49 -0700 (PDT) Received: from Tobias (unknown [210.11.218.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 402FB38EF2; Sat, 18 Aug 2012 04:09:46 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B168042967394366797E0F@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366797E0F@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sat, 18 Aug 2012 20:38:17 +0930 Message-ID: <024001cd7d31$ca406620$5ec13260$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEqDe4LGWOpRtk0JpZ2Sze0GyDcNZimR3+g Content-Language: en-us Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 11:09:50 -0000 I believe that I switched the question between the room and here. The question in the room was should we switch FROM SHA1 to something else. The room count should be reversed with the revised question. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Saturday, August 18, 2012 1:53 AM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters > > I believe that the results below are recorded incorrectly. I know that I > personally voted that we use the default parameters as widely deployed > (SHA-1), so the results below can not be right. I believe that the results were > likely actually: > > Room vote: 5 yes, 0 no, 3 discuss > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters > > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should SHA1 be the default parameters for these algorithms? > > > Room vote: 0 yes, 5 no, 3 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sun Aug 19 03:46:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9A921F8508 for ; Sun, 19 Aug 2012 03:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZXFHwCcIMZt for ; Sun, 19 Aug 2012 03:46:43 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9807721F8505 for ; Sun, 19 Aug 2012 03:46:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,792,1336312800"; d="scan'208,217";a="92424299" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 19 Aug 2012 20:46:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="83140725" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 19 Aug 2012 20:46:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Sun, 19 Aug 2012 20:46:25 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Sun, 19 Aug 2012 20:46:23 +1000 Thread-Topic: private keys, leading zeros Thread-Index: AQHNe0ihP+YmMegBLkyGUSrfCtn07pdeNHxAgAK8u0A= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA1689B@WSMSG3153V.srv.dir.telstra.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FA90743E@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366797EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366797EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FAA1689BWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] private keys, leading zeros X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 10:46:48 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FAA1689BWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkaXRpb25zIHdpdGggW0pNXSBwcmVmaXgNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIwMTIgNTo0NyBQTQ0KVG86 IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBwcml2YXRlIGtleXMsIGxlYWRpbmcgemVyb3MNCg0KDQoNCk1pa2UsDQoNCg0KDQpUaGFua3Mg Zm9yIG1ha2luZyB0aGUgZWZmb3J0IHRvIHByb2R1Y2UgYSBkcmFmdDoNCg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1qc29uLXByaXZhdGUta2V5DQoNCg0KDQpZ b3XigJlyZSB3ZWxjb21lLiA7LSkNCg0KDQoNCkZvdXIgY29tbWVudHM6DQoNCg0KDQoxLg0KDQpZ b3VyIGNob2ljZSB0byBleHRlbmQgdGhlIHB1YmxpYyBrZXkgZm9ybWF0IHRvIGFsc28gaG9sZCB0 aGUgcHJpdmF0ZSBrZXkgaW5mbyBtaWdodCBoYXZlIHNvbWUgaW50ZXJlc3RpbmcgY29uc2VxdWVu Y2VzLiBJdCBzdWdnZXN0cyB5b3UgY2FuIGhhdmUgYSBzaW5nbGUgZmlsZSAob3Igc2luZ2xlIEpT T04gb2JqZWN0KSB0aGF0IGNhbiBiZSB1c2VkIGJ5IHRvb2xzIHRoYXQgbmVlZHMgYSBwdWJsaWMg a2V5LCBhbmQgYnkgdG9vbHMgdGhhdCBuZWVkIGEgcHJpdmF0ZSBrZXkuIEhvd2V2ZXIsIEkgZG91 YnQgdGhhdCBpcyB2ZXJ5IGdvb2QgcHJhY3RpY2UuIEl0IGp1c3QgYWRkcyBhIHJpc2sgdGhhdCBh IHByaXZhdGUga2V5IGlzIGluYWR2ZXJ0ZW50bHkgZXhwb3NlZCB3aGVyZSBpdCBzaG91bGRuJ3Qg YmUuDQoNCg0KDQpQZXJoYXBzIHRoZSBmb2xsb3dpbmcgc29ydCBvZiBmb3JtYXQgd291bGQgYmUg YmV0dGVyOg0KDQogIHsNCg0KICAgICJwdWJsaWMiOnsiYWxnIjoiLi4ufSwNCg0KICAgICJwcml2 YXRlIjp7ImQiOi4uLn0NCg0KICB9DQoNCg0KDQpGb3Igd2hhdCBpdOKAmXMgd29ydGgsIGhhdmlu ZyBhIGZvcm1hdCB0aGF0IGNhbiByZXByZXNlbnQgZWl0aGVyIHB1YmxpYyBvciBwdWJsaWMvcHJp dmF0ZSBzZWVtcyB0byBiZSBmYWlybHkgY29tbW9uIHByYWN0aWNlIGZvciBjcnlwdG8gQVBJcy4g IEZvciBpbnN0YW5jZSwgc2VlIGh0dHA6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFy eS9zeXN0ZW0uc2VjdXJpdHkuY3J5cHRvZ3JhcGh5LmNuZ2tleWJsb2Jmb3JtYXQuYXNweC4gIEkg YmVsaWV2ZSB0aGF0IHNpbWlsYXIgZnVuY3Rpb25zIGFyZSBhbHNvIGF2YWlsYWJsZSBmb3IgSmF2 YSwgZXRjLg0KDQoNCg0KW0pNXSBJIHRoaW5rIHRoaXMgc2hvd3MgdGhlIG9wcG9zaXRlLiBUaGUg Q25nS2V5QmxvYkZvcm1hdCBjbGFzcyByZXByZXNlbnRzIGEgZm9ybWF0LCBub3QgYW4gYWN0dWFs IGtleS4gSXQgaGFzIHNlcGFyYXRlIGZvcm1hdHMgZm9yIHByaXZhdGUga2V5cyAoRWNjUHJpdmF0 ZUJsb2IsIEdlbmVyaWNQcml2YXRlQmxvYiwgUGtjczhQcml2YXRlQmxvYikgYW5kIHB1YmxpYyBr ZXlzIChFY2NQdWJsaWNCbG9iLCBHZW5lcmljUHVibGljQmxvYikuDQoNCg0KDQoNCg0KMi4NCg0K VGhlIHJ1bGUgdGhhdCBpbnRlZ2VycyBNVVNUIG5vdCBiZSBzaG9ydGVuZWQgaWYgdGhleSBoYXZl IGxlYWRpbmcgMCdzIGlzIHNpbGx5LiBJdCBpbXBsaWVzIHlvdSBjYW5ub3QgZW5jb2RlIGFuIGlu dGVnZXIgd2l0aG91dCBrbm93aW5nIGEgbGFyZ2VyIGNvbnRleHQgKGVnIHlvdSBjYW5ub3QgZW5j b2RlIGQgd2l0aG91dCBzcGVjaWZ5aW5nIG4sIGluIHRoZSBjb250ZXh0IG9mIGFuIFJTQSBrZXkp LiBUaGlzIHJ1bGUgYXBwbGllcyB0byB0aGUgcHJpdmF0ZSBleHBvbmVudCwgYnV0IHRoZSBvcHBv c2l0ZSBydWxlIGFwcGxpZXMgdG8gdGhlIHB1YmxpYyBleHBvbmVudC4gWXVjay4NCg0KDQoNCkVp dGhlciBhbHdheXMgZm9yYmlkZGluZyBsZWFkaW5nIHplcm9zLCBvciBhbHdheXMgYWxsb3dpbmcg dGhlbSAoc28gcmVjZWl2ZXJzIE1VU1Qgc3VwcG9ydCB0aGVtKSwgd291bGQgYmUgbXVjaCBiZXR0 ZXIgcnVsZXMuDQoNCg0KDQpUaGlzIGxhbmd1YWdlIHdhcyBhY3R1YWxseSBqdXN0IGNvcGllZCBm cm9tIEpXSy4gIFRoZSBnb2FsIGlzIHRvIGZhY2lsaXRhdGUgZGlyZWN0IGNvbnZlcnNpb24gZnJv bSB0aGUgYmFzZTY0dXJsIGVuY29kZWQgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBieXRlIGFycmF5 cyB0byB0aGUgYnl0ZSBhcnJheXMgZm9yIHRoZSBrZXkgdmFsdWVzLCB3aXRoIG5vIOKAnHNoaWZ0 aW5n4oCdIG9yIOKAnHByZXBlbmRpbmfigJ0gcmVxdWlyZWQuICBNYW55IGNyeXB0byBBUElzIHdp bGwgZXhwZWN0IGJ5dGUgYXJyYXlzIG9mIHNwZWNpZmljIGxlbmd0aHMsIHRoYXQgaW5jbHVkZSB0 aGUgbGVhZGluZyB6ZXJvcy4gIEl0IHNlZW1lZCBiZXR0ZXIgdG8gbWFuZGF0ZSB0aGF0IHRoZSBs ZWFkaW5nIHplcm9zIGJlIGluY2x1ZGVkIHNvIHRoYXQgdGhlIHJlc3VsdGluZyBieXRlIGFycmF5 cyBjYW4gYmUgdXNlZCBhcy1pcywgcmF0aGVyIHRoYW4gcG90ZW50aWFsbHkgaGF2aW5nIHRvIHBy ZXBlbmQgdGhlbSBpZiB0aGV5IGFyZSBtaXNzaW5nIGJlZm9yZSB1c2luZyB0aGUgYnl0ZSBhcnJh eS4NCg0KDQoNClRoYXQgYmVpbmcgc2FpZCwgaWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlcyB0 byBjaGFuZ2UgdGhpcyB0byBzYXkgdGhhdCBsZWFkaW5nIHplcm9zIG1heSBiZSBvbWl0dGVkLCB3 ZSBjb3VsZCBkbyB0aGF0LCBhbHRob3VnaCBpdCB3b3VsZCBtZWFuIHRoYXQgaW1wbGVtZW50YXRp b25zIGhhdmUgbW9yZSB0byBkbyB3aGVuIGltcG9ydGluZyBrZXlzLg0KDQoNCg0KSSBqdXN0IG5v dGljZWQgdGhlICJNVVNUIG5vdCBvbWl0IGxlYWRpbmcgMCdzIiBydWxlIGFwcGxpZXMgdG8gdGhl IFJTQSBtb2R1bHVzIGluIEpXQSAoc2VjdGlvbiA1LjMuMSAibW9kIiBNb2R1bHVzIFBhcmFtZXRl cikuIFRoZSBydWxlIGlzIGV2ZW4gc2lsbGllciBpbiB0aGlzIGNhc2UuIEl0IGVmZmVjdGl2ZWx5 IHNheXMgInRoZSBtb2R1bHVzIE1VU1QgYmUgZW5jb2RlZCBhcyB0aGUgc2l6ZSBzb21lb25lL3Nv bWV0aGluZyB0aG91Z2ggdGhlIG1vZHVsdXMgc2hvdWxkIGJlLCBpbnN0ZWFkIG9mIGFzIHRoZSBz aXplIGl0IGFjdHVhbGx5IGlzIi4gVGhpcyBzZWVtcyB0byBoYXZlIG5vIHB1cnBvc2Ugb3RoZXIg dGhhbiB0byBtaXNsZWFkIChlZyB0cmljayBhIGNvbXBvbmVudCB0aGF0IG9ubHkgbG9va3MgYXQg dGhlIGVuY29kZWQgbGVuZ3RoIGludG8gdGhpbmtpbmcgdGhlIGtleSBpcyBsb25nZXIvc3Ryb25n ZXIgdGhhbiBpdCBhY3R1YWxseSBpcykuDQoNCg0KDQozLg0KDQpBbiBSU0EgcHJpdmF0ZSBrZXkg Zm9ybWF0IG5lZWRzIHRvIHN1cHBvcnQgY2FsY3VsYXRpb25zIHRoYXQgdXNlIHRoZSBDaGluZXNl IFJlbWFpbmRlciBUaGVvcnVtIChDUlQpLCBieSBhbGxvd2luZyBwLCBxLCBkIG1vZCBwLTEsIGQg bW9kIHEtMSwgYW5kIHFpbnYgdG8gYmUgc3BlY2lmaWVkIC0tIG5vdCBqdXN0IGQuIENSVCBjYWxj dWxhdGlvbnMgb2ZmZXIgdG9vIG11Y2ggb2YgYSBwZXJmb3JtYW5jZSBib29zdCB0byBpZ25vcmUg KDIgb3IgNCB0aW1lcyBmYXN0ZXIsIGNhbid0IHJlbWVtYmVyIHdoaWNoIG9mZiB0aGUgdG9wIG9m IG15IGhlYWQpLg0KDQoNCg0KVGhpcyBtYWtlcyBzZW5zZS4gIElzIHRoZXJlIGV4aXN0aW5nIHBy YWN0aWNlIGZvciBzdWNoIHJlcHJlc2VudGF0aW9ucyB0aGF0IHlvdSBjYW4gcG9pbnQgdXMgdG8g dGhhdCB3ZSBjb3VsZCBib3Jyb3cgZnJvbT8NCg0KDQoNCltKTV0gUkZDIDM0NDcg4oCcUEtDUyAj MTogUlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0aW9ucywgdmVyc2lvbiAyLjHigJ0sIHNlY3Rp b24gQS4xLjIgUlNBIHByaXZhdGUga2V5IHN5bnRheCwgZm9yIHRoZSBSU0FQcml2YXRlS2V5IEFT Ti4xIHR5cGUuDQoNCg0KDQpBbiBSU0EgbW9kdWx1cyBjYW4gYWN0dWFsbHkgaGF2ZSBtb3JlIHRo YW4gMiBwcmltZSBmYWN0b3JzLiBBbiBSU0EgcHJpdmF0ZSBrZXkgZm9ybWF0IHNob3VsZCB0aGVv cmV0aWNhbGx5IHN1cHBvcnQgdGhhdCBhcyB3ZWxsLiBUaGF0IGlzLCBzdXBwb3J0IGFuIGFycmF5 IG9mIHtwcmltZSwgZXhwb25lbnQsIGNvZWZmaWNpZW50fSwgaW5zdGVhZCBvZiBoYXJkd2lyaW5n IGZpZWxkcyBmb3IgMiBwcmltZXMuDQoNClNlZSBSRkMzNDQ3ICJQS0NTICMxOiBSU0EgQ3J5cHRv Z3JhcGh5IFNwZWNpZmljYXRpb25zLCB2ZXJzaW9uIDIuMSIuDQoNCg0KDQpJcyB0aGlzIHVzZWQg aW4gcHJhY3RpY2U/ICBUaGUgY29kZSB0aGF0IEnigJl2ZSBsb29rZWQgYXQgZG9lc27igJl0IHN1 cHBvcnQgdGhpcy4gIElmIGl04oCZcyBqdXN0IGEgdGhlb3JldGljYWwgY2FzZSwgcmF0aGVyIHRo YW4gYSBwcmFjdGljYWwgb25lLCBJIGRvbuKAmXQgc2VlIGFueSBuZWVkIGZvciB1cyB0byBzdXBw b3J0IGl0Lg0KDQoNCg0KNC4NCg0KSSBhbSBub3Qgc3VyZSBpZiBpdCBoYXMgYmVlbiBhc2tlZCBi ZWZvcmUgKGJ5IG1lIG9yIHNvbWVvbmUgZWxzZSksIGJ1dCBpcyB0aGVyZSByZWFsbHkgYW55IGJl bmVmaXQgZnJvbSB3cmFwcGluZyB0aGUgSlNPTiBhcnJheSBvZiBrZXkgb2JqZWN0cyBpbiBhbm90 aGVyIEpTT04gb2JqZWN0IHdpdGggYSBzaW5nbGUgbWVtYmVyICJrZXlzIiBbSldLIHNlY3Rpb24g NSAiSlNPTiBXZWIgS2V5IFNldCAoSldLIFNldCkgRm9ybWF0Il0/IFRoaXMgaXMgYWRkaW5nIGFu IGV4dGVuc2lvbiBwb2ludCB3aXRoIG5vIGN1cnJlbnRseS1rbm93biB1c2UsIGJ1dCB3aXRob3V0 IGFueSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHNpbmNlIGFueSBleHRlbnNpb24gTVVTVCBiZSB1 bmRlcnN0b29kLg0KDQoNCg0KVGhpcyBhbGxvd3MgZGVwbG95bWVudHMgdG8gZGVmaW5lIGFuZCB1 c2Ugb3RoZXIgbWVtYmVycyB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQg dGhlIGtleSBzZXQuICBKaW0gU2NoYWFkIGhhZCBzdWdnZXN0ZWQgZGVmaW5pbmcgdGhlIHJlZ2lz dHJ5IGZvciB0aGVzZSBtZW1iZXIgZm9yIGV4YWN0bHkgdGhpcyBwdXJwb3NlLCB3aGljaCBtYWRl IHNlbnNlIHRvIG1lLg0KDQoNCg0KW0pNXSBFeGNlcHQgdGhhdCDigJxwcm92aWRpbmcgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUga2V5IHNldOKAnSB3aWxsIGJlIGJhcmVseSBkZXBs b3lhYmxlIGFzIGl0IHdpbGwgYnJlYWsgYWxsIGV4aXN0aW5nIHN5c3RlbXMgKHN1Y2ggYXMgY3J5 cHRvIGxpYnJhcmllcykgYXQgdGhhdCB0aW1lIGR1ZSB0byB0aGUgTVVTVCB1bmRlcnN0YW5kIHJ1 bGUuDQoNCg0KDQpGb3IgYSBzZXQgb2Yga2V5cywgaG93IGFib3V0IHVzaW5nIGEgSlNPTiBvYmpl Y3Qgd2l0aCBmaWVsZCBuYW1lcyB0aGF0IGFyZSBrZXktaWRzLCBhbmQgdGhlIHZhbHVlcyBhcmUg SldLcy4NCg0KICB7IOKAnDIwMTItMDbigJ06e+KAnGFsZ+KAnTrigJ1SU0HigJ0s4oCmfSwg4oCc MjAxMi0wNeKAnTp74oCcYWxn4oCdOuKAnVJTQeKAnSzigKZ9fQ0KDQpUaGF0IG1ha2VzIGl0IGVh c3kvaW50dWl0aXZlIHRvIGZpbmQgdGhlIGtleSBuZWVkZWQgZm9yIGEgSk9TRSBtZXNzYWdlIGZy b20gdGhlIGtleS1pZCBpbiB0aGF0IG1lc3NhZ2UuDQoNCkl0IG1lYW5zIHRoZSBKU09OIGZyYWdt ZW50IHN5bnRheCBkZWZpbmVkIGluIHRoZSBKU09OIHBvaW50ZXIgZHJhZnQgc3BlYyBjYW4gYmUg c2Vuc2libGUgdXNlZCB3aXRoIGEgVVJJIHRoYXQgcG9pbnRzIHRvIGEgc2V0IG9mIGtleXM6ICB7 ImprdSI6Imh0dHA6Ly9leGFtcGxlLmNvbS9+amltL2tleXMuandrIy8yMDEyLTA2IiB9DQoNCg0K DQoNCg0KLS0NCg0KSmFtZXMgTWFuZ2VyDQoNCg0K --_000_255B9BB34FB7D647A506DC292726F6E114FAA1689BWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5N c29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9 RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQnPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5BZGRpdGlvbnMgd2l0aCBbSk1dIHByZWZpeDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy PkZyb206IE1hbmdlciwgSmFtZXMgSCBbPGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRl YW0udGVsc3RyYS5jb20iPm1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9h Pl0gPGJyPlNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE1LCAyMDEyIDU6NDcgUE08YnI+VG86IE1p a2UgSm9uZXM7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9h Pjxicj5TdWJqZWN0OiBwcml2YXRlIGtleXMsIGxlYWRpbmcgemVyb3M8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPk1p a2UsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz5UaGFua3MgZm9yIG1ha2luZyB0aGUgZWZmb3J0IHRvIHByb2R1Y2Ug YSBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IGxhbmc9RU4tVVM+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9u ZXMtam9zZS1qc29uLXByaXZhdGUta2V5Ij48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSc+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9u ZXMtam9zZS1qc29uLXByaXZhdGUta2V5PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMwMEIw NTAnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzAwQjA1MCc+WW914oCZcmUgd2VsY29tZS4gOy0p PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUz5Gb3VyIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+MS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+WW91ciBjaG9p Y2UgdG8gZXh0ZW5kIHRoZSBwdWJsaWMga2V5IGZvcm1hdCB0byBhbHNvIGhvbGQgdGhlIHByaXZh dGUga2V5IGluZm8gbWlnaHQgaGF2ZSBzb21lIGludGVyZXN0aW5nIGNvbnNlcXVlbmNlcy4gSXQg c3VnZ2VzdHMgeW91IGNhbiBoYXZlIGEgc2luZ2xlIGZpbGUgKG9yIHNpbmdsZSBKU09OIG9iamVj dCkgdGhhdCBjYW4gYmUgdXNlZCBieSB0b29scyB0aGF0IG5lZWRzIGEgcHVibGljIGtleSwgYW5k IGJ5IHRvb2xzIHRoYXQgbmVlZCBhIHByaXZhdGUga2V5LiBIb3dldmVyLCBJIGRvdWJ0IHRoYXQg aXMgdmVyeSBnb29kIHByYWN0aWNlLiBJdCBqdXN0IGFkZHMgYSByaXNrIHRoYXQgYSBwcml2YXRl IGtleSBpcyBpbmFkdmVydGVudGx5IGV4cG9zZWQgd2hlcmUgaXQgc2hvdWxkbid0IGJlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxh bmc9RU4tVVM+UGVyaGFwcyB0aGUgZm9sbG93aW5nIHNvcnQgb2YgZm9ybWF0IHdvdWxkIGJlIGJl dHRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxh bmc9RU4tVVM+Jm5ic3A7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3B1YmxpYyZxdW90 Ozp7JnF1b3Q7YWxnJnF1b3Q7OiZxdW90Oy4uLn0sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtwcml2YXRlJnF1b3Q7OnsmcXVvdDtkJnF1b3Q7Oi4uLn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7IH08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdjb2xvcjojMDBCMDUwJz5Gb3Igd2hhdCBpdOKAmXMgd29ydGgsIGhhdmluZyBh IGZvcm1hdCB0aGF0IGNhbiByZXByZXNlbnQgZWl0aGVyIHB1YmxpYyBvciBwdWJsaWMvcHJpdmF0 ZSBzZWVtcyB0byBiZSBmYWlybHkgY29tbW9uIHByYWN0aWNlIGZvciBjcnlwdG8gQVBJcy4mbmJz cDsgRm9yIGluc3RhbmNlLCBzZWUgPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9y OmJsYWNrJz48YSBocmVmPSJodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkv c3lzdGVtLnNlY3VyaXR5LmNyeXB0b2dyYXBoeS5jbmdrZXlibG9iZm9ybWF0LmFzcHgiPmh0dHA6 Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9zeXN0ZW0uc2VjdXJpdHkuY3J5cHRv Z3JhcGh5LmNuZ2tleWJsb2Jmb3JtYXQuYXNweDwvYT48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzAwQjA1MCc+LiZuYnNwOyBJIGJlbGlldmUgdGhhdCBzaW1pbGFyIGZ1bmN0 aW9ucyBhcmUgYWxzbyBhdmFpbGFibGUgZm9yIEphdmEsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W0pNXSBJIHRoaW5rIHRoaXMg c2hvd3MgdGhlIG9wcG9zaXRlLiBUaGUgQ25nS2V5QmxvYkZvcm1hdCBjbGFzcyByZXByZXNlbnRz IGEgZm9ybWF0LCBub3QgYW4gYWN0dWFsIGtleS4gSXQgaGFzIHNlcGFyYXRlIGZvcm1hdHMgZm9y IHByaXZhdGUga2V5cyAoRWNjUHJpdmF0ZUJsb2IsIEdlbmVyaWNQcml2YXRlQmxvYiwgUGtjczhQ cml2YXRlQmxvYikgYW5kIHB1YmxpYyBrZXlzIChFY2NQdWJsaWNCbG9iLCBHZW5lcmljUHVibGlj QmxvYikuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz4yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUz5UaGUgcnVsZSB0aGF0IGludGVnZXJzIE1VU1Qgbm90IGJl IHNob3J0ZW5lZCBpZiB0aGV5IGhhdmUgbGVhZGluZyAwJ3MgaXMgc2lsbHkuIEl0IGltcGxpZXMg eW91IGNhbm5vdCBlbmNvZGUgYW4gaW50ZWdlciB3aXRob3V0IGtub3dpbmcgYSBsYXJnZXIgY29u dGV4dCAoZWcgeW91IGNhbm5vdCBlbmNvZGUgZCB3aXRob3V0IHNwZWNpZnlpbmcgbiwgaW4gdGhl IGNvbnRleHQgb2YgYW4gUlNBIGtleSkuIFRoaXMgcnVsZSBhcHBsaWVzIHRvIHRoZSBwcml2YXRl IGV4cG9uZW50LCBidXQgdGhlIG9wcG9zaXRlIHJ1bGUgYXBwbGllcyB0byB0aGUgcHVibGljIGV4 cG9uZW50LiBZdWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+RWl0aGVyIGFsd2F5cyBmb3JiaWRkaW5nIGxlYWRp bmcgemVyb3MsIG9yIGFsd2F5cyBhbGxvd2luZyB0aGVtIChzbyByZWNlaXZlcnMgTVVTVCBzdXBw b3J0IHRoZW0pLCB3b3VsZCBiZSBtdWNoIGJldHRlciBydWxlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjojMDBCMDUwJz5UaGlzIGxhbmd1YWdlIHdhcyBhY3R1YWxseSBqdXN0IGNvcGllZCBm cm9tIEpXSy4mbmJzcDsgVGhlIGdvYWwgaXMgdG8gZmFjaWxpdGF0ZSBkaXJlY3QgY29udmVyc2lv biBmcm9tIHRoZSBiYXNlNjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlvbnMgb2YgdGhlIGJ5dGUg YXJyYXlzIHRvIHRoZSBieXRlIGFycmF5cyBmb3IgdGhlIGtleSB2YWx1ZXMsIHdpdGggbm8g4oCc c2hpZnRpbmfigJ0gb3Ig4oCccHJlcGVuZGluZ+KAnSByZXF1aXJlZC4mbmJzcDsgTWFueSBjcnlw dG8gQVBJcyB3aWxsIGV4cGVjdCBieXRlIGFycmF5cyBvZiBzcGVjaWZpYyBsZW5ndGhzLCB0aGF0 IGluY2x1ZGUgdGhlIGxlYWRpbmcgemVyb3MuJm5ic3A7IEl0IHNlZW1lZCBiZXR0ZXIgdG8gbWFu ZGF0ZSB0aGF0IHRoZSBsZWFkaW5nIHplcm9zIGJlIGluY2x1ZGVkIHNvIHRoYXQgdGhlIHJlc3Vs dGluZyBieXRlIGFycmF5cyBjYW4gYmUgdXNlZCBhcy1pcywgcmF0aGVyIHRoYW4gcG90ZW50aWFs bHkgaGF2aW5nIHRvIHByZXBlbmQgdGhlbSBpZiB0aGV5IGFyZSBtaXNzaW5nIGJlZm9yZSB1c2lu ZyB0aGUgYnl0ZSBhcnJheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMwMEIwNTAnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nY29sb3I6IzAwQjA1MCc+VGhhdCBiZWluZyBzYWlkLCBpZiB0aGUgd29ya2luZyBncm91cCBk ZWNpZGVzIHRvIGNoYW5nZSB0aGlzIHRvIHNheSB0aGF0IGxlYWRpbmcgemVyb3MgbWF5IGJlIG9t aXR0ZWQsIHdlIGNvdWxkIGRvIHRoYXQsIGFsdGhvdWdoIGl0IHdvdWxkIG1lYW4gdGhhdCBpbXBs ZW1lbnRhdGlvbnMgaGF2ZSBtb3JlIHRvIGRvIHdoZW4gaW1wb3J0aW5nIGtleXMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F Ti1VUz5JIGp1c3Qgbm90aWNlZCB0aGUgJnF1b3Q7TVVTVCBub3Qgb21pdCBsZWFkaW5nIDAncyZx dW90OyBydWxlIGFwcGxpZXMgdG8gdGhlIFJTQSBtb2R1bHVzIGluIEpXQSAoc2VjdGlvbiA1LjMu MSAmcXVvdDttb2QmcXVvdDsgTW9kdWx1cyBQYXJhbWV0ZXIpLiBUaGUgcnVsZSBpcyBldmVuIHNp bGxpZXIgaW4gdGhpcyBjYXNlLiBJdCBlZmZlY3RpdmVseSBzYXlzICZxdW90O3RoZSBtb2R1bHVz IE1VU1QgYmUgZW5jb2RlZCBhcyB0aGUgc2l6ZSBzb21lb25lL3NvbWV0aGluZyB0aG91Z2ggdGhl IG1vZHVsdXMgc2hvdWxkIGJlLCBpbnN0ZWFkIG9mIGFzIHRoZSBzaXplIGl0IGFjdHVhbGx5IGlz JnF1b3Q7LiBUaGlzIHNlZW1zIHRvIGhhdmUgbm8gcHVycG9zZSBvdGhlciB0aGFuIHRvIG1pc2xl YWQgKGVnIHRyaWNrIGEgY29tcG9uZW50IHRoYXQgb25seSBsb29rcyBhdCB0aGUgZW5jb2RlZCBs ZW5ndGggaW50byB0aGlua2luZyB0aGUga2V5IGlzIGxvbmdlci9zdHJvbmdlciB0aGFuIGl0IGFj dHVhbGx5IGlzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPkFuIFJTQSBwcml2YXRlIGtleSBmb3JtYXQg bmVlZHMgdG8gc3VwcG9ydCBjYWxjdWxhdGlvbnMgdGhhdCB1c2UgdGhlIENoaW5lc2UgUmVtYWlu ZGVyIFRoZW9ydW0gKENSVCksIGJ5IGFsbG93aW5nIHAsIHEsIGQgbW9kIHAtMSwgZCBtb2QgcS0x LCBhbmQgcWludiB0byBiZSBzcGVjaWZpZWQgLS0gbm90IGp1c3QgZC4gQ1JUIGNhbGN1bGF0aW9u cyBvZmZlciB0b28gbXVjaCBvZiBhIHBlcmZvcm1hbmNlIGJvb3N0IHRvIGlnbm9yZSAoMiBvciA0 IHRpbWVzIGZhc3RlciwgY2FuJ3QgcmVtZW1iZXIgd2hpY2ggb2ZmIHRoZSB0b3Agb2YgbXkgaGVh ZCkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzAwQjA1MCc+VGhpcyBtYWtlcyBzZW5zZS4m bmJzcDsgSXMgdGhlcmUgZXhpc3RpbmcgcHJhY3RpY2UgZm9yIHN1Y2ggcmVwcmVzZW50YXRpb25z IHRoYXQgeW91IGNhbiBwb2ludCB1cyB0byB0aGF0IHdlIGNvdWxkIGJvcnJvdyBmcm9tPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5bSk1d IFJGQyAzNDQ3IOKAnFBLQ1MgIzE6IFJTQSBDcnlwdG9ncmFwaHkgU3BlY2lmaWNhdGlvbnMsIHZl cnNpb24gMi4x4oCdLCBzZWN0aW9uIEEuMS4yIFJTQSBwcml2YXRlIGtleSBzeW50YXgsIGZvciB0 aGUgUlNBUHJpdmF0ZUtleSBBU04uMSB0eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5n PUVOLVVTPkFuIFJTQSBtb2R1bHVzIGNhbiBhY3R1YWxseSBoYXZlIG1vcmUgdGhhbiAyIHByaW1l IGZhY3RvcnMuIEFuIFJTQSBwcml2YXRlIGtleSBmb3JtYXQgc2hvdWxkIHRoZW9yZXRpY2FsbHkg c3VwcG9ydCB0aGF0IGFzIHdlbGwuIFRoYXQgaXMsIHN1cHBvcnQgYW4gYXJyYXkgb2Yge3ByaW1l LCBleHBvbmVudCwgY29lZmZpY2llbnR9LCBpbnN0ZWFkIG9mIGhhcmR3aXJpbmcgZmllbGRzIGZv ciAyIHByaW1lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz cGFuIGxhbmc9RU4tVVM+U2VlIFJGQzM0NDcgJnF1b3Q7UEtDUyAjMTogUlNBIENyeXB0b2dyYXBo eSBTcGVjaWZpY2F0aW9ucywgdmVyc2lvbiAyLjEmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Y29sb3I6IzAwQjA1MCc+SXMgdGhpcyB1c2VkIGluIHByYWN0aWNlPyZuYnNwOyBUaGUgY29kZSB0 aGF0IEnigJl2ZSBsb29rZWQgYXQgZG9lc27igJl0IHN1cHBvcnQgdGhpcy4mbmJzcDsgSWYgaXTi gJlzIGp1c3QgYSB0aGVvcmV0aWNhbCBjYXNlLCByYXRoZXIgdGhhbiBhIHByYWN0aWNhbCBvbmUs IEkgZG9u4oCZdCBzZWUgYW55IG5lZWQgZm9yIHVzIHRvIHN1cHBvcnQgaXQuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+NC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+SSBhbSBub3Qgc3VyZSBpZiBpdCBoYXMgYmVl biBhc2tlZCBiZWZvcmUgKGJ5IG1lIG9yIHNvbWVvbmUgZWxzZSksIGJ1dCBpcyB0aGVyZSByZWFs bHkgYW55IGJlbmVmaXQgZnJvbSB3cmFwcGluZyB0aGUgSlNPTiBhcnJheSBvZiBrZXkgb2JqZWN0 cyBpbiBhbm90aGVyIEpTT04gb2JqZWN0IHdpdGggYSBzaW5nbGUgbWVtYmVyICZxdW90O2tleXMm cXVvdDsgW0pXSyBzZWN0aW9uIDUgJnF1b3Q7SlNPTiBXZWIgS2V5IFNldCAoSldLIFNldCkgRm9y bWF0JnF1b3Q7XT8gVGhpcyBpcyBhZGRpbmcgYW4gZXh0ZW5zaW9uIHBvaW50IHdpdGggbm8gY3Vy cmVudGx5LWtub3duIHVzZSwgYnV0IHdpdGhvdXQgYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg c2luY2UgYW55IGV4dGVuc2lvbiBNVVNUIGJlIHVuZGVyc3Rvb2QuIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2NvbG9yOiMwMEIwNTAnPlRoaXMgYWxsb3dzIGRlcGxveW1lbnRzIHRvIGRlZmluZSBhbmQg dXNlIG90aGVyIG1lbWJlcnMgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBrZXkgc2V0LiZuYnNwOyBKaW0gU2NoYWFkIGhhZCBzdWdnZXN0ZWQgZGVmaW5pbmcgdGhl IHJlZ2lzdHJ5IGZvciB0aGVzZSBtZW1iZXIgZm9yIGV4YWN0bHkgdGhpcyBwdXJwb3NlLCB3aGlj aCBtYWRlIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5bSk1dIEV4Y2VwdCB0aGF0IOKAnHByb3ZpZGluZyBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBrZXkgc2V04oCdIHdpbGwgYmUgYmFyZWx5IGRlcGxv eWFibGUgYXMgaXQgd2lsbCBicmVhayBhbGwgZXhpc3Rpbmcgc3lzdGVtcyAoc3VjaCBhcyBjcnlw dG8gbGlicmFyaWVzKSBhdCB0aGF0IHRpbWUgZHVlIHRvIHRoZSBNVVNUIHVuZGVyc3RhbmQgcnVs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+Rm9yIGEgc2V0IG9mIGtleXMsIGhvdyBhYm91dCB1c2luZyBhIEpTT04gb2JqZWN0IHdpdGgg ZmllbGQgbmFtZXMgdGhhdCBhcmUga2V5LWlkcywgYW5kIHRoZSB2YWx1ZXMgYXJlIEpXS3MuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdjb2xvcjojMUY0OTdEJz7CoCB7IOKAnDIwMTItMDbigJ06e+KAnGFsZ+KAnTrigJ1S U0HigJ0s4oCmfSwg4oCcMjAxMi0wNeKAnTp74oCcYWxn4oCdOuKAnVJTQeKAnSzigKZ9fTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nY29sb3I6IzFGNDk3RCc+VGhhdCBtYWtlcyBpdCBlYXN5L2ludHVpdGl2ZSB0byBmaW5k IHRoZSBrZXkgbmVlZGVkIGZvciBhIEpPU0UgbWVzc2FnZSBmcm9tIHRoZSBrZXktaWQgaW4gdGhh dCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SXQgbWVhbnMgdGhlIEpTT04gZnJh Z21lbnQgc3ludGF4IGRlZmluZWQgaW4gdGhlIEpTT04gcG9pbnRlciBkcmFmdCBzcGVjIGNhbiBi ZSBzZW5zaWJsZSB1c2VkIHdpdGggYSBVUkkgdGhhdCBwb2ludHMgdG8gYSBzZXQgb2Yga2V5czrC oCB7JnF1b3Q7amt1JnF1b3Q7OiZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9+amlt L2tleXMuandrIy8yMDEyLTA2Ij5odHRwOi8vZXhhbXBsZS5jb20vfmppbS9rZXlzLmp3ayMvMjAx Mi0wNjwvYT4mcXVvdDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+SmFtZXMgTWFuZ2VyPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114FAA1689BWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Sun Aug 19 04:06:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F72A21F84FA for ; Sun, 19 Aug 2012 04:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPjO-wUkOytF for ; Sun, 19 Aug 2012 04:06:52 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 35FAA21F84DD for ; Sun, 19 Aug 2012 04:06:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,792,1336312800"; d="scan'208";a="87299619" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:06:50 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="82489742" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipccvi.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:06:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Sun, 19 Aug 2012 21:06:49 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Sun, 19 Aug 2012 21:06:47 +1000 Thread-Topic: [jose] POLL: Non AEAD algorithms as a single name Thread-Index: Ac16RKHtofAZQFAhQTSskRTxljUg5wDtSNTg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA1689E@WSMSG3153V.srv.dir.telstra.com> References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> In-Reply-To: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 11:06:53 -0000 WUVTIQ0KW1dlIG9ubHkgc3VwcG9ydCBBRUFEIGVuY3J5cHRpb24uIFNwbGl0dGluZyBzb21lIEFF QUQgYWxnb3JpdGhtcyBpbnRvIHNvbWUgY29uc3RpdHVlbnQgcGFydHMgKGtkZixlbmMsbWFjKSBz aG91bGQgYmUgdW5kZXJuZWF0aCAobm90IHZpc2libGUgYXQpIHRoZSBKT1NFIGFic3RyYWN0aW9u Ll0NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mDQo+IEppbSBTY2hhYWQNCj4gU2VudDogRnJpZGF5LCAxNyBBdWd1c3Qg MjAxMiA1OjA4IFBNDQo+IFRvOiBqb3NlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtqb3NlXSBQT0xM OiBOb24gQUVBRCBhbGdvcml0aG1zIGFzIGEgc2luZ2xlIG5hbWUNCj4gDQo+IDxDSEFJUj4NCj4g DQo+IElmIHlvdSB2b3RlZCBhdCB0aGUgZmFjZS0yLWZhY2UgcGxlYXNlIGRvIG5vdCB2b3RlIGFn YWluLiAgSWYgeW91IHdhbnQNCj4gdG8NCj4gcHJvdmlkZSBjb21tZW50cyBwbGVhc2UgY2hhbmdl IHRoZSB0aXRsZSBmcm9tIFBPTEwgdG8gRElTQ1VTUy4NCj4gDQo+IFNob3VsZCB3ZSBjaGFuZ2Ug dGhlIGN1cnJlbnQgdHJlYXRtZW50IG9mIEFFUy1DQkMgKyBITUFDIHRvIHVzZSBhDQo+IHNpbmds ZQ0KPiBjb250ZW50IGVuY3J5cHRpb24gbmFtZS4NCj4gDQo+IE9sZDogeyJlbmMiOiJBMTI4Q0JD IiwgImludCI6SFMyNTYiLCAia2RmIjoiQ1MyNTYifQ0KPiBOZXc6IHsiZW5jIjoiQUVTMTI4Q0JD K0hTMjU2K0NTMjU2In0NCj4gDQo+IEV4YWN0IG5hbWUgaXMgc3RpbGwgdG8gYmUgZGV0ZXJtaW5l ZA0KPiANCj4gUm9vbSB2b3RlOiAgMTIgeWVzLCAyIG5vLCAwIGRpc2N1c3MNCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBqb3NlIG1h aWxpbmcgbGlzdA0KPiBqb3NlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vam9zZQ0K From James.H.Manger@team.telstra.com Sun Aug 19 04:21:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3421F84FA for ; Sun, 19 Aug 2012 04:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3sZquHfxiYS for ; Sun, 19 Aug 2012 04:21:06 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A321F850C for ; Sun, 19 Aug 2012 04:21:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,792,1336312800"; d="scan'208";a="89426959" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:21:05 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="108621882" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:21:04 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Sun, 19 Aug 2012 21:21:03 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Sun, 19 Aug 2012 21:21:01 +1000 Thread-Topic: [jose] POLL: Criticality of understanding header fields Thread-Index: Ac16R5jcjjwXKxuZTwOQJftRC8WQswDs+K6w Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA168A8@WSMSG3153V.srv.dir.telstra.com> References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> In-Reply-To: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 11:21:07 -0000 Tk8gLS0gYWxsICp1bnJlY29nbml6ZWQqIGZpZWxkcyBhcmUgbm9uLWNyaXRpY2FsDQoNCihsb3Rz IG9mIGZpZWxkcyBhcmUgY3JpdGljYWwsIGJ1dCBiYXNlZCBvbiBlYWNoIHR5cGUgb2YgbWVzc2Fn ZS4gRWcgZm9yIGEgSk9TRSBtZXNzYWdlIHRoYXQgZG9lcyBrZXkgYWdyZWVtZW50IHRoZW4gZW5j cnlwdGlvbiwgdGhlICJhZ3IiOjxrZXktYWdyZWVtZW50LWFsZz4gYW5kICJlbmMiOjxBRUFELWFs Zz4gZmllbGRzIGFyZSBjcml0aWNhbCkNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gSmltIFNjaGFhZA0KPiBT ZW50OiBGcmlkYXksIDE3IEF1Z3VzdCAyMDEyIDU6MDUgUE0NCj4gVG86IGpvc2VAaWV0Zi5vcmcN Cj4gU3ViamVjdDogW2pvc2VdIFBPTEw6IENyaXRpY2FsaXR5IG9mIHVuZGVyc3RhbmRpbmcgaGVh ZGVyIGZpZWxkcw0KPiANCj4gPENIQUlSPg0KPiANCj4gSWYgeW91IHZvdGVkIGF0IHRoZSBmYWNl LTItZmFjZSBwbGVhc2UgZG8gbm90IHZvdGUgYWdhaW4uICBJZiB5b3Ugd2FudA0KPiB0bw0KPiBw cm92aWRlIGNvbW1lbnRzIHBsZWFzZSBjaGFuZ2UgdGhlIHRpdGxlIGZyb20gUE9MTCB0byBESVND VVNTLg0KPiANCj4gV2hhdCBzaG91bGQgYmUgdGhlIGNyaXRpY2FsaXR5IG9mIGhlYWRlciBmaWVs ZHMgYXMgZGVmaW5lZCBieSB0aGUgY29yZQ0KPiBzcGVjaWZpY2F0aW9uPw0KPiANCj4gWUVTIC0g YWxsIGhlYWRlcnMgZmllbGRzIGFyZSBjcml0aWNhbA0KPiBOTyAtIGFsbCBoZWFkZXIgZmllbGRz IGFyZSBub24tY3JpdGljYWwNCj4gTUFZQkUgLSBoZWFkZXIgZmllbGRzIGFyZSBtYXJrZWQgY3Jp dGljYWwgb3IgY3JpdGljYWxpdHkgc2hvdWxkIGJlDQo+IGRlZmluZWQNCj4gYnkgdGhlIGFwcGxp Y2F0aW9uDQo+IERJU0NVU1MgLSBuZWVkIHRvIHRhbGsgbW9yZQ0KPiANCj4gUm9vbSB2b3RlOiAg MiB5ZXMsIDAgbm8sIDQgbWF5YmUsIDMgZGlzY3Vzcw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBqb3NlIG1haWxpbmcgbGlz dA0KPiBqb3NlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vam9zZQ0K From James.H.Manger@team.telstra.com Sun Aug 19 04:21:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770CC21F84FA for ; Sun, 19 Aug 2012 04:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXVloLJ5Gdmc for ; Sun, 19 Aug 2012 04:21:44 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id B347221F850C for ; Sun, 19 Aug 2012 04:21:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,792,1336312800"; d="scan'208";a="85770532" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:21:44 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="30821156" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcani.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:21:42 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Sun, 19 Aug 2012 21:21:42 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Sun, 19 Aug 2012 21:21:40 +1000 Thread-Topic: [jose] POLL: Is KID sufficently defined Thread-Index: Ac16R+NkZj6V892HQ2emUuPRcALC+gDtNx0Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA168A9@WSMSG3153V.srv.dir.telstra.com> References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> In-Reply-To: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 11:21:44 -0000 Tk8NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YNCj4gSmltIFNjaGFhZA0KPiBTZW50OiBGcmlkYXksIDE3IEF1Z3Vz dCAyMDEyIDU6MDUgUE0NCj4gVG86IGpvc2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2pvc2VdIFBP TEw6IElzIEtJRCBzdWZmaWNlbnRseSBkZWZpbmVkDQo+IA0KPiA8Q0hBSVI+DQo+IA0KPiBJZiB5 b3Ugdm90ZWQgYXQgdGhlIGZhY2UtMi1mYWNlIHBsZWFzZSBkbyBub3Qgdm90ZSBhZ2Fpbi4gIElm IHlvdSB3YW50DQo+IHRvDQo+IHByb3ZpZGUgY29tbWVudHMgcGxlYXNlIGNoYW5nZSB0aGUgdGl0 bGUgZnJvbSBQT0xMIHRvIERJU0NVU1MuDQo+IA0KPiBJcyB0aGUgY3VycmVudCB0ZXh0IGZvciBL SUQgc3VmZmljaWVudGx5IGRlZmluZWQgYW5kIHVuZGVyc3Rvb2Q/DQo+IA0KPiANCj4gUm9vbSB2 b3RlOiAgMiB5ZXMsIDAgbm8sIDEgZGlzY3Vzcw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+IGpv c2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3Nl DQo= From James.H.Manger@team.telstra.com Sun Aug 19 04:26:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C525D21F8505 for ; Sun, 19 Aug 2012 04:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IVkkDbyczeR for ; Sun, 19 Aug 2012 04:26:58 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id DD44F21F84FE for ; Sun, 19 Aug 2012 04:26:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,792,1336312800"; d="scan'208";a="87247518" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:26:57 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="82495491" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:26:55 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Sun, 19 Aug 2012 21:26:55 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Sun, 19 Aug 2012 21:26:54 +1000 Thread-Topic: [jose] POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: Ac16RvP41OcmDOmiQ/+7c8EuZk2YUADtetaw Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA168AE@WSMSG3153V.srv.dir.telstra.com> References: <000301cd7c46$c5b1c810$51155830$@augustcellars.com> In-Reply-To: <000301cd7c46$c5b1c810$51155830$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 11:26:58 -0000 Tm8NClNob3VsZCBpbmRpY2F0ZSBhbGwgdGhlIG1haW4gYnVpbGRpbmcgYmxvY2tzIGluIGVhY2gg bmFtZSAoQUVTLCBTSEEyLCBSU0EsIEVDLCAuLi4pIGluc3RlYWQgb2YgdHJ5aW5nIHRvIGFub2lu dCBvbmUgYnkgbWFraW5nIGl0IHRoZSBkZWZhdWx0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBKaW0gU2No YWFkDQo+IFNlbnQ6IEZyaWRheSwgMTcgQXVndXN0IDIwMTIgNTowNSBQTQ0KPiBUbzogam9zZUBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBbam9zZV0gUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0 IHBhcmFtZXRlcnMNCj4gDQo+IDxDSEFJUj4NCj4gDQo+IElmIHlvdSB2b3RlZCBhdCB0aGUgZmFj ZS0yLWZhY2UgcGxlYXNlIGRvIG5vdCB2b3RlIGFnYWluLiAgSWYgeW91IHdhbnQNCj4gdG8gcHJv dmlkZSBjb21tZW50cyBwbGVhc2UgY2hhbmdlIHRoZSB0aXRsZSBmcm9tIFBPTEwgdG8gRElTQ1VT Uy4NCj4gDQo+IFNob3VsZCBTSEExIGJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgZm9yIHRoZXNl IGFsZ29yaXRobXM/DQo+IA0KPiANCj4gUm9vbSB2b3RlOiAgMCB5ZXMsIDUgbm8sIDMgZGlzY3Vz cw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+IGpvc2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo= From James.H.Manger@team.telstra.com Sun Aug 19 04:40:42 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402B821F848F for ; Sun, 19 Aug 2012 04:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsQaY4ooeuE2 for ; Sun, 19 Aug 2012 04:40:40 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAD821F848A for ; Sun, 19 Aug 2012 04:40:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,792,1336312800"; d="scan'208";a="92426142" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:40:38 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="83322350" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 19 Aug 2012 21:40:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Sun, 19 Aug 2012 21:40:37 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Sun, 19 Aug 2012 21:40:35 +1000 Thread-Topic: [jose] DISCUSS: Add other than pre-shared MAC key Thread-Index: Ac16RidVje2mY8QHQcCUMfGKzpxf6gDt3nNQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA168B0@WSMSG3153V.srv.dir.telstra.com> References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] DISCUSS: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 11:40:42 -0000 TUFDLXdpdGgtcGVyLW1lc3NhZ2Uta2V5IGlzIGEgcmVhc29uYWJsZSBtb2RlLCByZWdhcmRsZXNz IG9mIHdoZXRoZXIgb3Igbm90IGl0IGlzIGltcG9ydGFudCBlbm91Z2ggdG8gbWFrZSB0aGUgaW5p dGlhbCBjdXQgZm9yIEpPU0UuIEl0IHdvdWxkIGxvb2sgbW9yZSBsaWtlIEpXRSB0aGVuIEpXUy4N Ckl0IGhpZ2hsaWdodHMgdGhhdCB3ZSByZWFsbHkgbmVlZCB0byBkcm9wIHRoaXMgSldFL0pXUyBk aWNob3RvbXksIGFuZCBoYXZlIGEgc2luZ2xlIEpPU0UgbWVzc2FnZSB0aGF0IHN1cHBvcnRzIGFu eSBudW1iZXIgb2YgbW9kZXMgKGF0IGxlYXN0IHBsYWluLCBzaWduZWQsIE1BQ2VkLCBlbmNyeXB0 ZWQsIGtleS1leGNoYW5nZSArIGVuY3J5cHQ7IHBlcmhhcHMga2V5LWV4Y2hhbmdlICsgTUFDLCBj b21wcmVzc2VkLCBwbHVzIHdoYXRldmVyIHRoZSBmdXR1cmUgbmVlZHMpLg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3NlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zg0KPiBKaW0gU2NoYWFkDQo+IFNlbnQ6IEZyaWRheSwgMTcgQXVndXN0IDIwMTIgNTowNyBQTQ0K PiBUbzogam9zZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbam9zZV0gUE9MTDogQWRkIG90aGVyIHRo YW4gcHJlLXNoYXJlZCBNQUMga2V5DQo+IA0KPiA8Q0hBSVI+DQo+IA0KPiBJZiB5b3Ugdm90ZWQg YXQgdGhlIGZhY2UtMi1mYWNlIHBsZWFzZSBkbyBub3Qgdm90ZSBhZ2Fpbi4gIElmIHlvdSB3YW50 DQo+IHRvIHByb3ZpZGUgY29tbWVudHMgcGxlYXNlIGNoYW5nZSB0aGUgdGl0bGUgZnJvbSBQT0xM IHRvIERJU0NVU1MuDQo+IA0KPiBTaG91bGQgd2UgYWRkIHRoZSBhYmlsaXR5IHRvIGhhdmUgYSBy YW5kb21seSBnZW5lcmF0ZWQgTUFDIGtleQ0KPiBwcm90ZWN0ZWQgYnkgYSBkaWZmZXJlbnQga2V5 PyAgVGhlIG90aGVyIGtleSBjb3VsZCBiZSBlaXRoZXIgYSBwcmUtDQo+IHNoYXJlZCBzeW1tZXRy aWMga2V5IG9yIGEgcHVibGljIGtleS4NCj4gDQo+IA0KPiANCj4gUm9vbSB2b3RlOiAgMyB5ZXMs IDUgbm8sIDMgZGlzY3Vzcw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+IGpvc2VAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo= From James.H.Manger@team.telstra.com Sun Aug 19 18:31:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD921F861C for ; Sun, 19 Aug 2012 18:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w4ZcPhq2Vcp for ; Sun, 19 Aug 2012 18:31:03 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 735FC21F861B for ; Sun, 19 Aug 2012 18:31:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,795,1336312800"; d="scan'208";a="89494771" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 20 Aug 2012 11:31:01 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6809"; a="81739659" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 20 Aug 2012 11:31:00 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 20 Aug 2012 11:30:59 +1000 From: "Manger, James H" To: "Richard L. Barnes" , "jose@ietf.org" Date: Mon, 20 Aug 2012 11:30:58 +1000 Thread-Topic: [jose] Splitting headers Thread-Index: Ac18w3KLmwnHiaKdTjWj8SnSruZNMQBqH0Uw Message-ID: <255B9BB34FB7D647A506DC292726F6E114FAA16EDB@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 01:31:03 -0000 PiBBdCBJRVRGIDg0LCBJIHN1Z2dlc3RlZCB0aGF0IHdlIHRha2UgYW5vdGhlciBsb29rIGF0IHdo YXQgaGVhZGVyDQo+IGluZm9ybWF0aW9uIGdldHMgaW50ZWdyaXR5LXByb3RlY3RlZCBhbmQgd2hh dCBkb2Vzbid0LiAgVGhlIG1haW4gaXNzdWUNCj4gYmVpbmcgdGhhdCBpbiBtdWx0aXBsZS1yZWNp cGllbnQgb3IgbXVsdGlwbGUtc2lnbmVyIHNjZW5hcmlvcywgdGhlcmUncw0KPiB1bm5lY2Vzc2Fy eSBkdXBsaWNhdGlvbiBvZiBkYXRhIGlmIHJlY2lwaWVudC0gb3Igc2lnbmVyLXNwZWNpZmljDQo+ IGluZm9ybWF0aW9uIGlzIGluIHRoZSBpbnRlZ3JpdHktcHJvdGVjdGVkIGhlYWRlci4NCg0KVGhl IHVubmVjZXNzYXJ5IGR1cGxpY2F0aW9uIGNvdWxkIGJlIGF2b2lkZWQgd2hpbGUgcmV0YWluaW5n IGZ1bGwgaGVhZGVyIGludGVncml0eSBwcm90ZWN0aW9uIGlmIHRoZSBKT1NFIHN5bnRheCBleHBs aWNpdGx5IHN1cHBvcnRlZCBtdWx0aXBsZSByZWNpcGllbnRzL3NpZ25lcnMuDQoNClJpY2hhcmTi gJlzIEpTTVMgZHJhZnQsIGFuZCBNaWtl4oCZcyBKV1MtSlMvSldFLUpTIGRyYWZ0cyBzaG93IHRo YXQgcGVvcGxlIHdhbnQgc3BlY3MgZm9yIHRoZSBtdWx0aXBsZSByZWNpcGllbnRzL3NpZ25lcnMg c2l0dWF0aW9ucyBzbyBJIHRoaW5rIHdlIHdvdWxkIGJlIGJldHRlciBvZmYgc3VwcG9ydGluZyB0 aGVzZSBjYXNlcyBpbiB0aGUgY29yZSBzeW50YXggZnJvbSB0aGUgc3RhcnQuDQoNCk11bHRpcGxl IHJlY2lwaWVudHMvc2lnbmVycyBkb2VzIGFkZCBzb21lIGNvbXBsZXhpdHkgdG8gdGhlIHNpbXBs ZXN0IChhbmQgY29tbW9uZXN0KSBjYXNlcywgYnV0IEkgc3VzcGVjdCB0aGUgY2hhbmdlIGNhbiBi ZSByZWFsbHkgcXVpdGUgbWlub3IgZm9yIGEgcGFydHkgdGhhdCBrbm93cyB0aGV5IG9ubHkgZXZl ciB3YW50IHRvIHN1cHBvcnQgYSBzaW5nbGUgcmVjaXBpZW50L3NpZ25lci4gVGhlIGNoYW5nZSBi YXNpY2FsbHkganVzdCBtb3ZlcyBhIGZldyBmaWVsZHMgZnJvbSBhIHRvcC1sZXZlbCBKU09OIG9i amVjdCB0byB0aGUgZmlyc3QgSlNPTiBvYmplY3QgaW4gYW4gYXJyYXkuIFN5bnRheCBvdmVyaGVh ZCBpcyA4IGJ5dGVzLCB1c2luZyAiciIgZm9yIHJlY2lwaWVudHMuDQoNCkZST00gICAgIHsgLi4u LCAieCI6MTIzLCAieSI6NDU2LCAuLi4gfQ0KVE8gICAgICAgeyAuLi4sICJyIjpbeyJ4IjoxMjMs ICJ5Ijo0NTZ9XSwgLi4uIH0NCg0KDQpXaXRoIHN1cHBvcnQgaW4gdGhlIGNvcmUgZm9yIG11bHRp cGxlIHJlY2lwaWVudHMvc2lnbmVycywgZnVsbCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiB3b3VsZCBv bmx5IGNhdXNlIGR1cGxpY2F0aW9uIHdoZW4gbXVsdGlwbGUgcGFydGllcyBhcmUgYWRkZWQgKmF0 IHNlcGFyYXRlIHRpbWVzKiAoaWUgYWZ0ZXIgYSBKT1NFIG1lc3NhZ2UgaGFzIGJlZW4gY3JlYXRl ZCkuIFRoZSBYTVBQIHVzZSBjYXNlIGRpZCBuZWVkIHRoaXMgKEFsaWNlIGNyZWF0ZXMgYSBKT1NF IG1lc3NhZ2UgZm9yIEJvYjsgbGF0ZXIgQm9i4oCZcyBzZXJ2ZXIgYWRkcyBCb2IncyBwaG9uZSBh bmQgQm9i4oCZcyBsYXB0b3AgYXMgbmV3IHJlY2lwaWVudHMpLCBidXQgdGhhdCBmZWVscyBsaWtl IHF1aXRlIGEgc3BlY2lhbGl6ZWQgY2FzZSB0aGF0IEpPU0UgbmVlZCBub3Qgb3B0aW1pemUgZm9y Lg0KDQoNCj4gRm9sbG93aW5nIHNvbWUgb24gd2hhdCBCb2IgV3ltYW4gcHJvcG9zZWQgdGhpcyBh ZnRlcm5vb24sIEkgd291bGQgbGlrZQ0KPiB0byBwcm9wb3NlIHRoYXQgd2Ugc3BsaXQgdGhlIHNl dCBvZiBoZWFkZXIgZmllbGRzIGludG8gc29tZSBsb2dpY2FsDQo+IGdyb3VwaW5nczoNCj4gMS4g VG9wLWxldmVsIGZpZWxkcyB0aGF0IHJlcXVpcmUgaW50ZWdyaXR5IHByb3RlY3Rpb24gKGUuZy4s IGN0eSBvciBhDQo+IGRpZ2VzdCBhbGdvcml0aG0gcGFyYW1ldGVyKQ0KPiAyLiBUb3AtbGV2ZWwg ZmllbGRzIHRoYXQgZG8gbm90IHJlcXVpcmUgaW50ZWdyaXR5IHByb3RlY3Rpb24gKGUuZy4sDQo+ IHg1YykNCj4gMy4gRmllbGRzIHRoYXQgYXJlIHNwZWNpZmljIHRvIGEgc2lnbmVyIChlLmcuLCBq d2spDQo+IDQuIEZpZWxkcyB0aGF0IGFyZSBzcGVjaWZpYyB0byBhIHJlY2lwaWVudCAoZS5nLiwg ZXBrKQ0KDQpXb3VsZCBhbm90aGVyIHBvc3NpYmlsaXR5IGZvciAjMiBiZSB3cmFwcGluZyBhIEpP U0UgbWVzc2FnZSBhcyB0aGUgY29udGVudCBvZiBhbm90aGVyIHVucHJvdGVjdGVkIEpPU0UgbWVz c2FnZSB0aGF0IGhhcyB0aGUgZmllbGRzIG5vdCByZXF1aXJpbmcgcHJvdGVjdGlvbj8gRm9yIGV4 YW1wbGUgKHdpdGhvdXQgYmFzZTY0dXJsLWVuY29kaW5nIGZvciBjbGFyaXR5KToNCg0KICB7ICJh bGciOiJub25lIiwgIng1YyI6WyJNSUlFM+KApiJdLCAib2NzcCI6WyJNSWVS4oCmIl19Ljxpbm5l ci1KT1NFLW1lc3NhZ2U+Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From hannes.tschofenig@nsn.com Mon Aug 20 01:17:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1C21F8686 for ; Mon, 20 Aug 2012 01:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3UfbzCjgXYi for ; Mon, 20 Aug 2012 01:17:09 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4D37721F86AF for ; Mon, 20 Aug 2012 01:17:09 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7K8Guao009218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Aug 2012 10:16:56 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7K8Grck022589; Mon, 20 Aug 2012 10:16:55 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Aug 2012 10:16:48 +0200 Received: from 10.159.32.94 ([10.159.32.94]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Aug 2012 08:16:47 +0000 MIME-Version: 1.0 Message-ID: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [jose] Splitting headers Thread-Index: Ac1+rCSwdsgshm0STzeHt6Ev6lqFvA== Date: Mon, 20 Aug 2012 11:16:45 +0300 To: "ext Richard L. Barnes" , Content-Type: multipart/alternative; boundary="_6C9831A1-AE34-E1D4-93A7-1F6080ABD041_"; charset="iso-8859-1" X-OriginalArrivalTime: 20 Aug 2012 08:16:48.0239 (UTC) FILETIME=[24E9CFF0:01CD7EAC] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7246 X-purgate-ID: 151667::1345450617-00006F5F-831BED26/0-0/0-0 Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:17:10 -0000 --_6C9831A1-AE34-E1D4-93A7-1F6080ABD041_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Here is my view: the muliple recipient case is a rare case. Having a bit of= extra overhead for rare cases is IMHO acceptable to keep the core spec sim= pler.=20 hannes Sent from my Windows Phone -----Original Message----- From: ext Richard L. Barnes Sent: 8/18/2012 12:58 AM To: jose@ietf.org Subject: [jose] Splitting headers Hey all, At IETF 84, I suggested that we take another look at what header informatio= n gets integrity-protected and what doesn't. The main issue being that in = multiple-recipient or multiple-signer scenarios, there's unnecessary duplic= ation of data if recipient- or signer-specific information is in the integr= ity-protected header. Following some on what Bob Wyman proposed this afternoon, I would like to p= ropose that we split the set of header fields into some logical groupings: 1. Top-level fields that require integrity protection (e.g., cty or a diges= t algorithm parameter) 2. Top-level fields that do not require integrity protection (e.g., x5c) 3. Fields that are specific to a signer (e.g., jwk) 4. Fields that are specific to a recipient (e.g., epk) In this taxonomy, only fields of type (1) need to be base64-encoded for to = preserve their serialization, and fields of type (3) and (4) could be gathe= red together into the moral equivalent of SignerInfo and RecipientInfo obje= cts. All this makes the JSON serialization a lot cleaner, for example: { "type": "S", "header": "[base64-type1]", "params": { /* type2 */ }, "content": "[base64-content]", "signers": [ { /* type3 */ } ] } You can also imagine a reasonable compact serialization, something like: S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-s= igner2]. ... That encoding even has the benefit that the multi-signer case doesn't add a= ny overhead over the single-signer case, except for maybe a couple of "." c= haracters. (Obviously, you would want some structure on how the signer info= gets serialized, but that's another level of detail down. You could imagi= ne something like "[signer-header].[public-key].[signature-value]".) The additional structure might seem like it's more work to parse, but I don= 't think it's really that bad. Given a parsed JOSE object "obj": 1. Decode obj.header and add its fields to obj.params 2. Look through "signers" / "recipients" to find one we understand 3. Verify / decrypt content using signer/recipient info and parameters There are several details to be worked out -- most critically, which fields= go in which groupings -- but I thought I would throw out the general idea = for comment before diving into the details. Cheers, --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_6C9831A1-AE34-E1D4-93A7-1F6080ABD041_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Here is my view: the muliple recipient case is a rare = case. Having a bit of extra overhead for rare cases is IMHO acceptable to k= eep the core spec simpler.

hannes

Sent from my Windows Phone=
From: ext Richard L. Barnes
Se= nt: 8/18/2012 12:58 AM
To: jose@ietf.org
Su= bject: [jose] Splitting headers

Hey all,

At IETF 84, I su= ggested that we take another look at what header information gets integrity= -protected and what doesn't.  The main issue being that in multiple-re= cipient or multiple-signer scenarios, there's unnecessary duplication of da= ta if recipient- or signer-specific information is in the integrity-protect= ed header.

Following some on what Bob Wyman proposed this afternoon,= I would like to propose that we split the set of header fields into some l= ogical groupings:
1. Top-level fields that require integrity protection = (e.g., cty or a digest algorithm parameter)
2. Top-level fields that do = not require integrity protection (e.g., x5c)
3. Fields that are specific= to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g= ., epk)

In this taxonomy, only fields of type (1) need to be base64-= encoded for to preserve their serialization, and fields of type (3) and (4)= could be gathered together into the moral equivalent of SignerInfo and Rec= ipientInfo objects.  All this makes the JSON serialization a lot clean= er, for example:

{
    "type": "S",
  = ;  "header": "[base64-type1]",
    "params": { /* ty= pe2 */ },
    "content": "[base64-content]",
 &nb= sp;  "signers": [
        { /* t= ype3 */ }
    ]
}

You can also imagine a reason= able compact serialization, something like:

S.[base64-type1].[base64= -type2].[base64-content].[base64-signer1].[base64-signer2]. ...

That= encoding even has the benefit that the multi-signer case doesn't add any o= verhead over the single-signer case, except for maybe a couple of "." chara= cters. (Obviously, you would want some structure on how the signer info get= s serialized, but that's another level of detail down.  You could imag= ine something like "[signer-header].[public-key].[signature-value]".)
The additional structure might seem like it's more work to parse, but I d= on't think it's really that bad.  Given a parsed JOSE object "obj":1. Decode obj.header and add its fields to obj.params
2. Look through "= signers" / "recipients" to find one we understand
3. Verify / decrypt co= ntent using signer/recipient info and parameters

There are several d= etails to be worked out -- most critically, which fields go in which groupi= ngs -- but I thought I would throw out the general idea for comment before = diving into the details.

Cheers,
--Richard




___= ____________________________________________
jose mailing list
jose@i= etf.org
https://www.ietf.org/mailman/listinfo/jose
= --_6C9831A1-AE34-E1D4-93A7-1F6080ABD041_-- From rbarnes@bbn.com Mon Aug 20 05:21:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B8021F8617 for ; Mon, 20 Aug 2012 05:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.304 X-Spam-Level: X-Spam-Status: No, score=-106.304 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmrcuyp7uSDC for ; Mon, 20 Aug 2012 05:21:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4B40721F84F5 for ; Mon, 20 Aug 2012 05:21:44 -0700 (PDT) Received: from [128.89.254.52] (port=54801) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T3QzF-000Pbr-0s; Mon, 20 Aug 2012 08:21:41 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> Date: Mon, 20 Aug 2012 08:21:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF2FDA8-DDBD-44A7-B791-2831BA8C7042@bbn.com> References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:21:45 -0000 Hannes, By what metric of "rare"? In the XMPP case, different appearances of a = JID count as multiple recipients (at the crypto layer), and in XMPP, = multiple appearance is very common (e.g., laptop vs. phone). --Richard On Aug 20, 2012, at 4:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Here is my view: the muliple recipient case is a rare case. Having a = bit of extra overhead for rare cases is IMHO acceptable to keep the core = spec simpler.=20 >=20 > hannes >=20 > Sent from my Windows Phone > From: ext Richard L. Barnes > Sent: 8/18/2012 12:58 AM > To: jose@ietf.org > Subject: [jose] Splitting headers >=20 > Hey all, >=20 > At IETF 84, I suggested that we take another look at what header = information gets integrity-protected and what doesn't. The main issue = being that in multiple-recipient or multiple-signer scenarios, there's = unnecessary duplication of data if recipient- or signer-specific = information is in the integrity-protected header. >=20 > Following some on what Bob Wyman proposed this afternoon, I would like = to propose that we split the set of header fields into some logical = groupings: > 1. Top-level fields that require integrity protection (e.g., cty or a = digest algorithm parameter) > 2. Top-level fields that do not require integrity protection (e.g., = x5c) > 3. Fields that are specific to a signer (e.g., jwk) > 4. Fields that are specific to a recipient (e.g., epk) >=20 > In this taxonomy, only fields of type (1) need to be base64-encoded = for to preserve their serialization, and fields of type (3) and (4) = could be gathered together into the moral equivalent of SignerInfo and = RecipientInfo objects. All this makes the JSON serialization a lot = cleaner, for example: >=20 > { > "type": "S", > "header": "[base64-type1]", > "params": { /* type2 */ }, > "content": "[base64-content]", > "signers": [ > { /* type3 */ } > ] > } >=20 > You can also imagine a reasonable compact serialization, something = like: >=20 > = S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-= signer2]. ... >=20 > That encoding even has the benefit that the multi-signer case doesn't = add any overhead over the single-signer case, except for maybe a couple = of "." characters. (Obviously, you would want some structure on how the = signer info gets serialized, but that's another level of detail down. = You could imagine something like = "[signer-header].[public-key].[signature-value]".) >=20 > The additional structure might seem like it's more work to parse, but = I don't think it's really that bad. Given a parsed JOSE object "obj": > 1. Decode obj.header and add its fields to obj.params > 2. Look through "signers" / "recipients" to find one we understand > 3. Verify / decrypt content using signer/recipient info and parameters >=20 > There are several details to be worked out -- most critically, which = fields go in which groupings -- but I thought I would throw out the = general idea for comment before diving into the details. >=20 > Cheers, > --Richard >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Mon Aug 20 05:27:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E820A21F8650 for ; Mon, 20 Aug 2012 05:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGmY3aHFw9he for ; Mon, 20 Aug 2012 05:27:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7527F21F8634 for ; Mon, 20 Aug 2012 05:27:31 -0700 (PDT) Received: from [128.89.254.52] (port=54802) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T3R4p-000PeG-HR; Mon, 20 Aug 2012 08:27:27 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FAA16EDB@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 20 Aug 2012 08:27:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B57C958-D2EE-4FA4-B713-6F4B7D0D790A@bbn.com> References: <255B9BB34FB7D647A506DC292726F6E114FAA16EDB@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:27:32 -0000 Hey James, >> Following some on what Bob Wyman proposed this afternoon, I would = like >> to propose that we split the set of header fields into some logical >> groupings: >> 1. Top-level fields that require integrity protection (e.g., cty or a >> digest algorithm parameter) >> 2. Top-level fields that do not require integrity protection (e.g., >> x5c) >> 3. Fields that are specific to a signer (e.g., jwk) >> 4. Fields that are specific to a recipient (e.g., epk) >=20 > Would another possibility for #2 be wrapping a JOSE message as the = content of another unprotected JOSE message that has the fields not = requiring protection? For example (without base64url-encoding for = clarity): >=20 > { "alg":"none", "x5c":["MIIE3=85"], = "ocsp":["MIeR=85"]}.. I guess you could, but what would be the benefit? The "wrapping" = doesn't really seem to add anything. --Richard= From jricher@mitre.org Mon Aug 20 07:15:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EE921F8629 for ; Mon, 20 Aug 2012 07:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bptVLk0bt4LS for ; Mon, 20 Aug 2012 07:15:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6852921F8602 for ; Mon, 20 Aug 2012 07:15:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C13BE21B134B; Mon, 20 Aug 2012 10:15:35 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AC40621B1339; Mon, 20 Aug 2012 10:15:35 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 20 Aug 2012 10:15:35 -0400 Message-ID: <5032462D.4010204@mitre.org> Date: Mon, 20 Aug 2012 10:14:05 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Nat Sakimura References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <502E51A5.5080401@mitre.org> <8039706901170831017@unknownmsgid> In-Reply-To: <8039706901170831017@unknownmsgid> Content-Type: multipart/alternative; boundary="------------010504090800050704010807" X-Originating-IP: [129.83.31.58] Cc: "jose-chairs@tools.ietf.org" , Harry Halpin , Karen O'Donoghue , Jim Schaad , Mike Jones , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 14:15:39 -0000 --------------010504090800050704010807 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > The rationale for having the encrypted keys were because I thought > that the main use case were to transfer keys from one system to > another, while it stays within a system, hopefully we can use platform > supplied storage mechanism and key store. That makes sense. In that case, I think it would make more sense to just use an existing encryption container like JWE with the public and private key structure as the payload. Or just use TLS. > > Now, your use case is different. You want to use the JWK private key > stored in the local file system to sign or encrypt messages. For that, > I agree it is turtles all the way. System implementers needs to be > careful on how the process authentication is done when allowing the > access to the key file is done though. Yes, absolutely. But in our use case (service configuration) it's already being stored and protected in a place that houses other sensitive secrets, and it needs to be treated as sensitive just like the rest of them. -- Justin > > On Aug 17, 2012, at 11:15 PM, Justin Richer > wrote: > > >> Nat, how would you store the private key that you encrypted the >> private key with? And what key would you use to encrypt your >> private-key-encrypter key? It's turtles all the way down, and not in >> a good way. >> >> I personally really like having a parallel format to JWK for private >> keys, and I even asked (off list) for this feature about six months >> back. My use case was simple, and still valid: I have a server that >> takes in a configuration file with all kinds of already-sensitive >> information, like database passwords and admin user lists. I would >> love to be able to put my public and private keys in there without >> dropping to an ASN.1 structure. I realized that with JWK, I could >> store my public keys, but didn't have any place to put the private >> keys. At the time, we punted and went with a container-native >> certificate store with self-signed certificates, but this setup >> remains overkill and a bad fit for what we actually care about, the >> keys. But in order to get the keys, we had to generate a self-signed >> cert with a fake certificate authority and junk metadata just to fit >> the format. A JWK/JPK structure (to coin an acronym for the soup) >> would be able to handle this quite nicely, and it parallels what the >> WebCrypto WG is after, from what I gather. It would be fairly easy to >> add support for shared HMAC secrets in the same format as well. >> >> However, I do agree with one point that was brought up: I don't >> necessarily like putting the two in the same structure. I think it's >> quite *functional* this way, but it seems like it could cause a >> problem like the private bits getting leaked. On the other hand, this >> feeling could be a case of premature intuition-based optimization >> [1], so I'm not sure how much credence to give it. >> >> -- Justin >> >> [1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/ >> >> >> On 08/16/2012 10:26 PM, Nat Sakimura wrote: >>> Thanks Mike. >>> >>> Would it not be a good idea to mandate that private key file must be >>> encrypted? As far as I remember, one of the reason for not producing >>> private key format was from the fear that developers leave the >>> exported keys in a insecure manner. >>> >>> Thoughts? >>> >>> Nat >>> >>> On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones >>> > >>> wrote: >>> >>> Thanks for writing, Harry and WebCrypto WG. >>> >>> 1) About private keys, given the WebCrypto use case, I >>> personally think it would be valuable for JOSE to define a JSON >>> private key representation. To make this concrete, I would >>> propose the private key representations specified in >>> http://tools.ietf.org/html/draft-jones-jose-json-private-key. >>> You'll see that doing this is very simple; it just defines two >>> additional members for the JWK structure for representing the >>> private parts of Elliptic Curve and RSA keys. This could either >>> remain a separate spec from JWK/JWA or be merged in, at the >>> working group's preference. >>> >>> I had previously agreed with the position that it was not >>> necessary for JOSE to define private key representations because >>> we didn't have a use case for it. However, as I see it, the W3C >>> WebCrypto API use case changes things. Better for JOSE to be >>> responsive to WebCrypto and add this simple extension, either as >>> a new spec or in the existing specs, than to leave this undone, >>> and have it potentially be an area where otherwise >>> standards-compliant implementations diverge, and where JSON-only >>> solutions are not possible. >>> >>> Finally, I'll note that the JOSE charter >>> http://datatracker.ietf.org/wg/jose/charter/ does not preclude >>> defining private key formats. (It simply requires the >>> definition of public key formats and is silent on the topic of >>> private keys.) >>> >>> 2) I agree on the likely need for WebCrypto support ASN.1 for >>> backwards compatibility in some cases (just as the JOSE specs >>> allow the use of X.509 certificates). However, I believe it >>> would be a shame to preclude JSON-only solutions by not >>> supporting key import/export in JWK format, where such solutions >>> make sense. >>> >>> 3) It appears to me the JWK format is stable. I believe the >>> JWS format is stable as well. The JWE format has known changes >>> that will be applied shortly, based upon working group >>> discussions at IETF 84 in Vancouver two weeks ago. Some JWA >>> changes will occur that are part of the JWE changes. I don't >>> anticipate significant changes after that. (Making these >>> changes is my highest priority as JOSE editor. I'm hoping to >>> have drafts out containing them by the end of August, which >>> hopefully fits well with the WebCrypto schedule.) I write all >>> of the above with the caveat that the working group is, of >>> course, free to change things as they see fit. >>> >>> I look forward to a productive discussion of this coordination >>> request in both working groups. >>> >>> Best wishes, >>> -- Mike >>> >>> P.S. If you prefer, a HTML-formatted version of the private key >>> spec is available at >>> http://self-issued.info/docs/draft-jones-jose-json-private-key.html. >>> I also blogged about this draft specification at >>> http://self-issued.info/?p=816. >>> >>> -----Original Message----- >>> From: Harry Halpin [mailto:hhalpin@w3.org ] >>> Sent: Sunday, August 12, 2012 8:03 AM >>> To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org >>> ; Mike Jones >>> Subject: JOSE WG request from W3C WebCrypto API >>> >>> [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] >>> >>> JOSE Chairs, >>> >>> The Web Cryptography Working group has noted that the API >>> requires some access to raw key material, and the issue of >>> whether or not to use JWK or ASN.1 as the default format came >>> up. Two issues have come out that we'd like to know the answer to: >>> >>> 1) JWK does not define a private key format. Does the JOSE WG >>> plan to support a JOSE-format for private keys? If so, when? Or >>> 'maybe'? >>> >>> 2) While we'd like encourage the use of JOSE over ASN.1, it >>> seems like for backwards compatibility having some level of >>> ASN.1 support would be useful and we *need* a format that allows >>> key material (both private and >>> public) to be exported. Folks seem to leaning towards ASN.1 as a >>> default format in the low-level API, and having JWK as a format >>> that can be built on top of that in a possible high-level API. >>> Would that be OK? >>> >>> 3) How stable do you believe the JOSE formats are right now? >>> Do you think they are stable enough now we can reference them in >>> our API draft at end of August? If not, when? The W3C would >>> like to and plan to use these formats where possible. >>> >>> Feel free to forward this by JOSE WG for discussion. We'd like >>> an answer before we send our document to FPWD at end of August. >>> >>> cheers, >>> harry >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> --------------010504090800050704010807 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

The rationale for having the encrypted keys were because I thought that the main use case were to transfer keys from one system to another, while it stays within a system, hopefully we can use platform supplied storage mechanism and key store.
That makes sense. In that case, I think it would make more sense to just use an existing encryption container like JWE with the public and private key structure as the payload. Or just use TLS.


Now, your use case is different. You want to use the JWK private key stored in the local file system to sign or encrypt messages. For that, I agree it is turtles all the way. System implementers needs to be careful on how the process authentication is done when allowing the access to the key file is done though.

Yes, absolutely. But in our use case (service configuration) it's already being stored and protected in a place that houses other sensitive secrets, and it needs to be treated as sensitive just like the rest of them.

 -- Justin


On Aug 17, 2012, at 11:15 PM, Justin Richer <jricher@mitre.org> wrote:


Nat, how would you store the private key that you encrypted the private key with? And what key would you use to encrypt your private-key-encrypter key? It's turtles all the way down, and not in a good way.

I personally really like having a parallel format to JWK for private keys, and I even asked (off list) for this feature about six months back. My use case was simple, and still valid: I have a server that takes in a configuration file with all kinds of already-sensitive information, like database passwords and admin user lists. I would love to be able to put my public and private keys in there without dropping to an ASN.1 structure. I realized that with JWK, I could store my public keys, but didn't have any place to put the private keys. At the time, we punted and went with a container-native certificate store with self-signed certificates, but this setup remains overkill and a bad fit for what we actually care about, the keys. But in order to get the keys, we had to generate a self-signed cert with a fake certificate authority and junk metadata just to fit the format. A JWK/JPK structure (to coin an acronym for the soup) would be able to handle this quite nicely, and it parallels what the WebCrypto WG is after, from what I gather. It would be fairly easy to add support for shared HMAC secrets in the same format as well.

However, I do agree with one point that was brought up: I don't necessarily like putting the two in the same structure. I think it's quite *functional* this way, but it seems like it could cause a problem like the private bits getting leaked. On the other hand, this feeling could be a case of premature intuition-based optimization [1], so I'm not sure how much credence to give it.

 -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:
Thanks Mike. 

Would it not be a good idea to mandate that private key file must be encrypted? As far as I remember, one of the reason for not producing private key format was from the fear that developers leave the exported keys in a insecure manner. 

Thoughts? 

Nat

On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks for writing, Harry and WebCrypto WG.

1)  About private keys, given the WebCrypto use case, I personally think it would be valuable for JOSE to define a JSON private key representation.  To make this concrete, I would propose the private key representations specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key.  You'll see that doing this is very simple; it just defines two additional members for the JWK structure for representing the private parts of Elliptic Curve and RSA keys.  This could either remain a separate spec from JWK/JWA or be merged in, at the working group's preference.

I had previously agreed with the position that it was not necessary for JOSE to define private key representations because we didn't have a use case for it.  However, as I see it, the W3C WebCrypto API use case changes things.  Better for JOSE to be responsive to WebCrypto and add this simple extension, either as a new spec or in the existing specs, than to leave this undone, and have it potentially be an area where otherwise standards-compliant implementations diverge, and where JSON-only solutions are not possible.

Finally, I'll note that the JOSE charter http://datatracker.ietf.org/wg/jose/charter/ does not preclude defining private key formats.  (It simply requires the definition of public key formats and is silent on the topic of private keys.)

2)  I agree on the likely need for WebCrypto support ASN.1 for backwards compatibility in some cases (just as the JOSE specs allow the use of X.509 certificates).  However, I believe it would be a shame to preclude JSON-only solutions by not supporting key import/export in JWK format, where such solutions make sense.

3)  It appears to me the JWK format is stable.  I believe the JWS format is stable as well.  The JWE format has known changes that will be applied shortly, based upon working group discussions at IETF 84 in Vancouver two weeks ago.  Some JWA changes will occur that are part of the JWE changes.  I don't anticipate significant changes after that.  (Making these changes is my highest priority as JOSE editor.  I'm hoping to have drafts out containing them by the end of August, which hopefully fits well with the WebCrypto schedule.)  I write all of the above with the caveat that the working group is, of course, free to change things as they see fit.

I look forward to a productive discussion of this coordination request in both working groups.

                                Best wishes,
                                -- Mike

P.S.  If you prefer, a HTML-formatted version of the private key spec is available at http://self-issued.info/docs/draft-jones-jose-json-private-key.html.  I also blogged about this draft specification at http://self-issued.info/?p=816.

-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org]
Sent: Sunday, August 12, 2012 8:03 AM
To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike Jones
Subject: JOSE WG request from W3C WebCrypto API

[cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

JOSE Chairs,

The Web Cryptography Working group has noted that the API requires some access to raw key material, and the issue of whether or not to use JWK or ASN.1 as the default format came up. Two issues have come out that we'd like to know the answer to:

1) JWK does not define a private key format. Does the JOSE WG plan to support a JOSE-format for private keys? If so, when? Or 'maybe'?

  2) While we'd like encourage the use of JOSE over ASN.1, it seems like for backwards compatibility having some level of ASN.1 support would be useful and we *need* a format that allows key material (both private and
public) to be exported. Folks seem to leaning towards ASN.1 as a default format in the low-level API, and having JWK as a format that can be built on top of that in a possible high-level API. Would that be OK?

  3) How stable do you believe the JOSE formats are right now? Do you think they are stable enough now we can reference them in our API draft at end of August? If not, when?  The W3C would like to and plan to use these formats where possible.

Feel free to forward this by JOSE WG for discussion. We'd like an answer before we send our document to FPWD at end of August.

  cheers,
      harry




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



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



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


--------------010504090800050704010807-- From Michael.Jones@microsoft.com Mon Aug 20 11:08:42 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0489621F866E for ; Mon, 20 Aug 2012 11:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.842 X-Spam-Level: X-Spam-Status: No, score=-3.842 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFUG93LnzcrZ for ; Mon, 20 Aug 2012 11:08:41 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6F21F8650 for ; Mon, 20 Aug 2012 11:08:41 -0700 (PDT) Received: from mail167-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 18:08:40 +0000 Received: from mail167-co1 (localhost [127.0.0.1]) by mail167-co1-R.bigfish.com (Postfix) with ESMTP id CB694D40195; Mon, 20 Aug 2012 18:08:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail167-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail167-co1 (localhost.localdomain [127.0.0.1]) by mail167-co1 (MessageSwitch) id 1345486119116993_6858; Mon, 20 Aug 2012 18:08:39 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.240]) by mail167-co1.bigfish.com (Postfix) with ESMTP id 1A1CCA80044; Mon, 20 Aug 2012 18:08:39 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 18:08:38 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Mon, 20 Aug 2012 18:08:22 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters Thread-Index: Ac18lJzBZ7lrugc/SlOdnZgODbmGPwAnSfqAAHM38mA= Date: Mon, 20 Aug 2012 18:08:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667A1FD3@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366797E0F@TK5EX14MBXC284.redmond.corp.microsoft.com> <024001cd7d31$ca406620$5ec13260$@augustcellars.com> In-Reply-To: <024001cd7d31$ca406620$5ec13260$@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:08:42 -0000 Just to avoid confusion, could you or Karen please resend the poll question= with the correct room count? Thanks, -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Saturday, August 18, 2012 4:08 AM To: Mike Jones; jose@ietf.org Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters I believe that I switched the question between the room and here. The ques= tion in the room was should we switch FROM SHA1 to something else. The room count should be reversed with the revised question. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Saturday, August 18, 2012 1:53 AM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters >=20 > I believe that the results below are recorded incorrectly. I know=20 > that I personally voted that we use the default parameters as widely=20 > deployed (SHA-1), so the results below can not be right. I believe=20 > that the results were > likely actually: >=20 > Room vote: 5 yes, 0 no, 3 discuss >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Jim Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters >=20 > >=20 > If you voted at the face-2-face please do not vote again. If you want=20 > to provide comments please change the title from POLL to DISCUSS. >=20 > Should SHA1 be the default parameters for these algorithms? >=20 >=20 > Room vote: 0 yes, 5 no, 3 discuss >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Aug 20 11:12:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A6021F86BE for ; Mon, 20 Aug 2012 11:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.84 X-Spam-Level: X-Spam-Status: No, score=-3.84 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E2zgyBFkfQ4 for ; Mon, 20 Aug 2012 11:12:13 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id DF98421E8049 for ; Mon, 20 Aug 2012 11:12:12 -0700 (PDT) Received: from mail38-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 18:12:12 +0000 Received: from mail38-am1 (localhost [127.0.0.1]) by mail38-am1-R.bigfish.com (Postfix) with ESMTP id D7464380069; Mon, 20 Aug 2012 18:12:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432I111aI1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h) Received-SPF: pass (mail38-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail38-am1 (localhost.localdomain [127.0.0.1]) by mail38-am1 (MessageSwitch) id 1345486328154949_12153; Mon, 20 Aug 2012 18:12:08 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.254]) by mail38-am1.bigfish.com (Postfix) with ESMTP id 1ABA840044; Mon, 20 Aug 2012 18:12:08 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 18:12:04 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Mon, 20 Aug 2012 18:11:58 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] order of step for encryption. JWE section 5 Thread-Index: Ac1y1wQPutAF2XyLQPOP3bTnOMCRMwALGibgAHLgNQACjA8d0A== Date: Mon, 20 Aug 2012 18:11:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667A2030@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943667537AF@TK5EX14MBXC285.redmond.corp.microsoft.com> <015001cd74ce$ee7a7460$cb6f5d20$@augustcellars.com> In-Reply-To: <015001cd74ce$ee7a7460$cb6f5d20$@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] order of step for encryption. JWE section 5 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:12:14 -0000 The problem is that sub-lists are formatted with the same indentation as th= e lists that enclose them. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Tuesday, August 07, 2012 12:01 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] order of step for encryption. JWE section 5 Mike, What is you issue of dealing with lists inside of lists for xml2rfc - is it= just a question of how things are formatted? If so then this is an issue = that can be left to the RFC Editor. Such formatting should be improved in = general over the next few months as the new version of xml2rfc processing s= tarts to get fully tested and rolled out. If the problem is something else, I would be interested in hearing what it = is. > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Mike Jones > Sent: Sunday, August 05, 2012 5:20 AM > To: Axel.Nennker@telekom.de; jose@ietf.org > Subject: Re: [jose] order of step for encryption. JWE section 5 >=20 > Thanks for the careful read, Axel. I'll work to make the write-up of=20 > the steps > clearer, using your input. In particular, I'll look for ways to=20 > better structure > the steps. (Unfortunately, the xml2rfc tool doesn't do a particularly good job > of structuring lists with sub-lists.) >=20 > Answering your point 2c, a random CMK is not used in this case. =20 > Instead, the > agreed-upon key is used directly to perform the encryption. I also=20 > plan to > add a key agreement example in the next draft. I expect that this=20 > will help > make this case clearer. >=20 > Thanks again, > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Axel.Nennker@telekom.de > Sent: Saturday, August 04, 2012 11:55 PM > To: jose@ietf.org > Subject: [jose] order of step for encryption. JWE section 5 >=20 > Hi, >=20 > I have two issues with section 5 of > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html >=20 > 1) > I would prefer it if the order of the steps 1 and 2 were reversed in section 5. >=20 > Currently we have: > Message Encryption >=20 >=20 > The message encryption process is as follows. The order of the steps > is not significant in cases where there are no dependencies between > the inputs and outputs of the steps. >=20 > 1. When key agreement is employed, use the key agreement algorithm > to compute the value of the agreed upon key. When key agreement > without key wrapping is employed, let the Content Master Key > (CMK) be the agreed upon key. When key agreement with key > wrapping is employed, the agreed upon key will be used to wrap > the CMK. >=20 > 2. When key wrapping, key encryption, or key agreement with key > wrapping are employed, generate a random Content Master Key > (CMK). See RFC 4086 [RFC4086] for considerations on generating > random values. The CMK MUST have a length equal to that of the > larger of the required encryption and integrity keys. >=20 > Step 1 refers to the CMK that might be randomly created in step 2. I=20 > think it is > better to have the CMK generation . >=20 > 2) I find the text of the current step 1 confusing. > 2a) The first sentence is nearly a tautology > 2b) All sentences begin with When but the sentences two and three are=20 > alternative choices and the first is not. > 2c) Does "When key agreement without key wrapping is employed, let=20 > the Content Master Key > (CMK) be the agreed upon key." make sense? > What is the key agreement good for then? > Should this read: "When key agreement without key wrapping is=20 > employed, let the agreed upon key be the CMK" ? There SHOULD be some=20 > randomness e.g. through the epk. >=20 > Could we structure these steps more? I) determine the CEK, generate=20 > random values like IVs and epks II) build the jweHeaderSegment (e.g. > put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) build > the jweCryptoSegment V) build the jweIntegritySegment VI) base64url=20 > encode and concatenate the segments=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From jricher@mitre.org Thu Aug 23 08:19:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D383B21F856C for ; Thu, 23 Aug 2012 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60zUiu6NqDsx for ; Thu, 23 Aug 2012 08:19:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 827F121F8564 for ; Thu, 23 Aug 2012 08:19:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9972821B1BE9; Thu, 23 Aug 2012 11:19:15 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7FB5E21B0744; Thu, 23 Aug 2012 11:19:15 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 23 Aug 2012 11:19:15 -0400 Message-ID: <50364996.1050502@mitre.org> Date: Thu, 23 Aug 2012 11:17:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> In-Reply-To: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> Content-Type: multipart/alternative; boundary="------------040401020500070901090604" X-Originating-IP: [129.83.31.58] Cc: "ext Richard L. Barnes" , jose@ietf.org Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:19:17 -0000 --------------040401020500070901090604 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I'd like to pose the question of what constitutes "a bit of extra overhead". Making the overhead mandatory to support in the core can lead to developer friction for the majority cases. This reminds me of the discussion on the OAuth list about returning multiple tokens. Sometimes, yes, you want to return multiple access tokens. Usually it's just one. We could have made the return value an array instead of a string, but then you'd force every client to pull out "access_token[0]" instead of just "access_token", and that's an annoyance for the non-rare case. In the end, the group decided on supporting the simple case in the core and letting an extension define the multi-token format. That extension was never proposed, so I would wager that the multi-token case was at least rare enough to not force the standardization question. I think the same approach should be taken here. Keep the existing, deployed, simple format of header.payload.signature for the simple single-signature case. Use a different serialization format for different use case, such as the JWS-JSON format that Mike's proposed or the multi-dot format proposed below. I would argue that they're fundamentally different kinds of objects and that conflating their use cases by forcing the overhead is a big mistake. -- Justin On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Here is my view: the muliple recipient case is a rare case. Having a > bit of extra overhead for rare cases is IMHO acceptable to keep the > core spec simpler. > > hannes > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: ext Richard L. Barnes > Sent: 8/18/2012 12:58 AM > To: jose@ietf.org > Subject: [jose] Splitting headers > > Hey all, > > At IETF 84, I suggested that we take another look at what header > information gets integrity-protected and what doesn't. The main issue > being that in multiple-recipient or multiple-signer scenarios, there's > unnecessary duplication of data if recipient- or signer-specific > information is in the integrity-protected header. > > Following some on what Bob Wyman proposed this afternoon, I would like > to propose that we split the set of header fields into some logical > groupings: > 1. Top-level fields that require integrity protection (e.g., cty or a > digest algorithm parameter) > 2. Top-level fields that do not require integrity protection (e.g., x5c) > 3. Fields that are specific to a signer (e.g., jwk) > 4. Fields that are specific to a recipient (e.g., epk) > > In this taxonomy, only fields of type (1) need to be base64-encoded > for to preserve their serialization, and fields of type (3) and (4) > could be gathered together into the moral equivalent of SignerInfo and > RecipientInfo objects. All this makes the JSON serialization a lot > cleaner, for example: > > { > "type": "S", > "header": "[base64-type1]", > "params": { /* type2 */ }, > "content": "[base64-content]", > "signers": [ > { /* type3 */ } > ] > } > > You can also imagine a reasonable compact serialization, something like: > > S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. > ... > > That encoding even has the benefit that the multi-signer case doesn't > add any overhead over the single-signer case, except for maybe a > couple of "." characters. (Obviously, you would want some structure on > how the signer info gets serialized, but that's another level of > detail down. You could imagine something like > "[signer-header].[public-key].[signature-value]".) > > The additional structure might seem like it's more work to parse, but > I don't think it's really that bad. Given a parsed JOSE object "obj": > 1. Decode obj.header and add its fields to obj.params > 2. Look through "signers" / "recipients" to find one we understand > 3. Verify / decrypt content using signer/recipient info and parameters > > There are several details to be worked out -- most critically, which > fields go in which groupings -- but I thought I would throw out the > general idea for comment before diving into the details. > > Cheers, > --Richard > > > > > _______________________________________________ > 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 --------------040401020500070901090604 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
I'd like to pose the question of what constitutes "a bit of extra overhead". Making the overhead mandatory to support in the core can lead to developer friction for the majority cases.

This reminds me of the discussion on the OAuth list about returning multiple tokens. Sometimes, yes, you want to return multiple access tokens. Usually it's just one. We could have made the return value an array instead of a string, but then you'd force every client to pull out "access_token[0]" instead of just "access_token", and that's an annoyance for the non-rare case. In the end, the group decided on supporting the simple case in the core and letting an extension define the multi-token format. That extension was never proposed, so I would wager that the multi-token case was at least rare enough to not force the standardization question.

I think the same approach should be taken here. Keep the existing, deployed, simple format of header.payload.signature for the simple single-signature case. Use a different serialization format for different use case, such as the JWS-JSON format that Mike's proposed or the multi-dot format proposed below. I would argue that they're fundamentally different kinds of objects and that conflating their use cases by forcing the overhead is a big mistake.

 -- Justin

On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Here is my view: the muliple recipient case is a rare case. Having a bit of extra overhead for rare cases is IMHO acceptable to keep the core spec simpler.

hannes

Sent from my Windows Phone
From: ext Richard L. Barnes
Sent: 8/18/2012 12:58 AM
To: jose@ietf.org
Subject: [jose] Splitting headers

Hey all,

At IETF 84, I suggested that we take another look at what header information gets integrity-protected and what doesn't.  The main issue being that in multiple-recipient or multiple-signer scenarios, there's unnecessary duplication of data if recipient- or signer-specific information is in the integrity-protected header.

Following some on what Bob Wyman proposed this afternoon, I would like to propose that we split the set of header fields into some logical groupings:
1. Top-level fields that require integrity protection (e.g., cty or a digest algorithm parameter)
2. Top-level fields that do not require integrity protection (e.g., x5c)
3. Fields that are specific to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g., epk)

In this taxonomy, only fields of type (1) need to be base64-encoded for to preserve their serialization, and fields of type (3) and (4) could be gathered together into the moral equivalent of SignerInfo and RecipientInfo objects.  All this makes the JSON serialization a lot cleaner, for example:

{
    "type": "S",
    "header": "[base64-type1]",
    "params": { /* type2 */ },
    "content": "[base64-content]",
    "signers": [
        { /* type3 */ }
    ]
}

You can also imagine a reasonable compact serialization, something like:

S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. ...

That encoding even has the benefit that the multi-signer case doesn't add any overhead over the single-signer case, except for maybe a couple of "." characters. (Obviously, you would want some structure on how the signer info gets serialized, but that's another level of detail down.  You could imagine something like "[signer-header].[public-key].[signature-value]".)

The additional structure might seem like it's more work to parse, but I don't think it's really that bad.  Given a parsed JOSE object "obj":
1. Decode obj.header and add its fields to obj.params
2. Look through "signers" / "recipients" to find one we understand
3. Verify / decrypt content using signer/recipient info and parameters

There are several details to be worked out -- most critically, which fields go in which groupings -- but I thought I would throw out the general idea for comment before diving into the details.

Cheers,
--Richard




_______________________________________________
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

--------------040401020500070901090604-- From hannes.tschofenig@gmx.net Thu Aug 23 08:54:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2DD21F8565 for ; Thu, 23 Aug 2012 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzNs4poRoNIP for ; Thu, 23 Aug 2012 08:54:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2A49D21F855D for ; Thu, 23 Aug 2012 08:54:45 -0700 (PDT) Received: (qmail invoked by alias); 23 Aug 2012 15:54:44 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 23 Aug 2012 17:54:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18KoZoM80EKbYijSc5XDzzagyFz7lO+1QcWLs1xG9 UNw7o7gNXPMTr+ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50364996.1050502@mitre.org> Date: Thu, 23 Aug 2012 18:54:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <488CCD98-D359-4D9D-B6EF-29AE636953AD@gmx.net> References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> <50364996.1050502@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "ext Richard L. Barnes" , Hannes Tschofenig , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , jose@ietf.org Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 15:54:48 -0000 I agree with you, Justin.=20 My impression is that the multi-party communication and multi-party = security scenario will either have to live with additional overhead = (Richard, how much overhead are we talking about) or (what is more = likely) there will be a different mechanism used (which is what happened = with security for multi-party communication in the IETF in general).=20 Ciao Hannes On Aug 23, 2012, at 6:17 PM, Justin Richer wrote: > I'd like to pose the question of what constitutes "a bit of extra = overhead". Making the overhead mandatory to support in the core can lead = to developer friction for the majority cases.=20 >=20 > This reminds me of the discussion on the OAuth list about returning = multiple tokens. Sometimes, yes, you want to return multiple access = tokens. Usually it's just one. We could have made the return value an = array instead of a string, but then you'd force every client to pull out = "access_token[0]" instead of just "access_token", and that's an = annoyance for the non-rare case. In the end, the group decided on = supporting the simple case in the core and letting an extension define = the multi-token format. That extension was never proposed, so I would = wager that the multi-token case was at least rare enough to not force = the standardization question. >=20 > I think the same approach should be taken here. Keep the existing, = deployed, simple format of header.payload.signature for the simple = single-signature case. Use a different serialization format for = different use case, such as the JWS-JSON format that Mike's proposed or = the multi-dot format proposed below. I would argue that they're = fundamentally different kinds of objects and that conflating their use = cases by forcing the overhead is a big mistake. >=20 > -- Justin >=20 > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Here is my view: the muliple recipient case is a rare case. Having a = bit of extra overhead for rare cases is IMHO acceptable to keep the core = spec simpler.=20 >>=20 >> hannes >>=20 >> Sent from my Windows Phone >> From: ext Richard L. Barnes >> Sent: 8/18/2012 12:58 AM >> To: jose@ietf.org >> Subject: [jose] Splitting headers >>=20 >> Hey all, >>=20 >> At IETF 84, I suggested that we take another look at what header = information gets integrity-protected and what doesn't. The main issue = being that in multiple-recipient or multiple-signer scenarios, there's = unnecessary duplication of data if recipient- or signer-specific = information is in the integrity-protected header. >>=20 >> Following some on what Bob Wyman proposed this afternoon, I would = like to propose that we split the set of header fields into some logical = groupings: >> 1. Top-level fields that require integrity protection (e.g., cty or a = digest algorithm parameter) >> 2. Top-level fields that do not require integrity protection (e.g., = x5c) >> 3. Fields that are specific to a signer (e.g., jwk) >> 4. Fields that are specific to a recipient (e.g., epk) >>=20 >> In this taxonomy, only fields of type (1) need to be base64-encoded = for to preserve their serialization, and fields of type (3) and (4) = could be gathered together into the moral equivalent of SignerInfo and = RecipientInfo objects. All this makes the JSON serialization a lot = cleaner, for example: >>=20 >> { >> "type": "S", >> "header": "[base64-type1]", >> "params": { /* type2 */ }, >> "content": "[base64-content]", >> "signers": [ >> { /* type3 */ } >> ] >> } >>=20 >> You can also imagine a reasonable compact serialization, something = like: >>=20 >> = S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-= signer2]. ... >>=20 >> That encoding even has the benefit that the multi-signer case doesn't = add any overhead over the single-signer case, except for maybe a couple = of "." characters. (Obviously, you would want some structure on how the = signer info gets serialized, but that's another level of detail down. = You could imagine something like = "[signer-header].[public-key].[signature-value]".) >>=20 >> The additional structure might seem like it's more work to parse, but = I don't think it's really that bad. Given a parsed JOSE object "obj": >> 1. Decode obj.header and add its fields to obj.params >> 2. Look through "signers" / "recipients" to find one we understand >> 3. Verify / decrypt content using signer/recipient info and = parameters >>=20 >> There are several details to be worked out -- most critically, which = fields go in which groupings -- but I thought I would throw out the = general idea for comment before diving into the details. >>=20 >> Cheers, >> --Richard >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >>=20 >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Thu Aug 23 09:02:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6787221F8598 for ; Thu, 23 Aug 2012 09:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.682 X-Spam-Level: X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZqi+kmXtxWW for ; Thu, 23 Aug 2012 09:02:04 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id DF82121F8594 for ; Thu, 23 Aug 2012 09:02:03 -0700 (PDT) Received: from mail-vc0-f177.google.com ([209.85.220.177]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKUDZT+0NoqfmHfmz670tx8UseY2DKyA2U@postini.com; Thu, 23 Aug 2012 09:02:04 PDT Received: by vcbfl13 with SMTP id fl13so1048232vcb.36 for ; Thu, 23 Aug 2012 09:02:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9Lu0N3vtgmL/9wygAzK5XGByEJwaNA6Dr1tBDxi3LSE=; b=R9StNpNNXb6DVf2iIgqvi7PM5/bkObrYYO46N/pXJyW0buZU00k35Gd2rqiye74304 JSdvx1oooXZB6IaAfZe2pUPm/R5D8inkUoDd4DefX6K3oDD+pIFD4nbWc/W5X1uIRgfU 2xZLqwqOvnUBY2gl5yRu60XXae5U3ws/wGEanYKkqAGbtpxMJcwri+zatyTag4KEoUnp zqmR570Ozk4zcsy+I7XCgVMn+ZYuSCazV2xcV1Vtqop+hNS2JrtpspSuUJsW7BG0mSMe NTXeST+BfQi8DAWyaZUUxbd2jZwY9W25yIrpmytOYJMaxix8e9wbhaCeFwZVsIcZc89N dhlQ== Received: by 10.220.204.212 with SMTP id fn20mr1689974vcb.43.1345737722657; Thu, 23 Aug 2012 09:02:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.66.228 with HTTP; Thu, 23 Aug 2012 09:01:32 -0700 (PDT) In-Reply-To: <488CCD98-D359-4D9D-B6EF-29AE636953AD@gmx.net> References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> <50364996.1050502@mitre.org> <488CCD98-D359-4D9D-B6EF-29AE636953AD@gmx.net> From: Brian Campbell Date: Thu, 23 Aug 2012 10:01:32 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=bcaec54fb042eb7c3804c7f0fa5d X-Gm-Message-State: ALoCoQnNTARnXdDfS0RGKapZcsiFE8Co6maso0FIYNLQdwPWhjBU3yBWURIHu+jL6YmNmMSrBQYF Cc: "ext Richard L. Barnes" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Justin Richer , jose@ietf.org Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:02:05 -0000 --bcaec54fb042eb7c3804c7f0fa5d Content-Type: text/plain; charset=ISO-8859-1 I'll reiterate that I'd very much like to see the single signer and single recipient cases remain as simple as possible. On Thu, Aug 23, 2012 at 9:54 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > I agree with you, Justin. > > My impression is that the multi-party communication and multi-party > security scenario will either have to live with additional overhead > (Richard, how much overhead are we talking about) or (what is more likely) > there will be a different mechanism used (which is what happened with > security for multi-party communication in the IETF in general). > > Ciao > Hannes > > > On Aug 23, 2012, at 6:17 PM, Justin Richer wrote: > > > I'd like to pose the question of what constitutes "a bit of extra > overhead". Making the overhead mandatory to support in the core can lead to > developer friction for the majority cases. > > > > This reminds me of the discussion on the OAuth list about returning > multiple tokens. Sometimes, yes, you want to return multiple access tokens. > Usually it's just one. We could have made the return value an array instead > of a string, but then you'd force every client to pull out > "access_token[0]" instead of just "access_token", and that's an annoyance > for the non-rare case. In the end, the group decided on supporting > the simple case in the core and letting an extension define the multi-token > format. That extension was never proposed, so I would wager that the > multi-token case was at least rare enough to not force the standardization > question. > > > > I think the same approach should be taken here. Keep the existing, > deployed, simple format of header.payload.signature for the simple > single-signature case. Use a different serialization format for different > use case, such as the JWS-JSON format that Mike's proposed or the multi-dot > format proposed below. I would argue that they're fundamentally different > kinds of objects and that conflating their use cases by forcing the > overhead is a big mistake. > > > > -- Justin > > > > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Here is my view: the muliple recipient case is a rare case. Having a > bit of extra overhead for rare cases is IMHO acceptable to keep the core > spec simpler. > >> > >> hannes > >> > >> Sent from my Windows Phone > >> From: ext Richard L. Barnes > >> Sent: 8/18/2012 12:58 AM > >> To: jose@ietf.org > >> Subject: [jose] Splitting headers > >> > >> Hey all, > >> > >> At IETF 84, I suggested that we take another look at what header > information gets integrity-protected and what doesn't. The main issue > being that in multiple-recipient or multiple-signer scenarios, there's > unnecessary duplication of data if recipient- or signer-specific > information is in the integrity-protected header. > >> > >> Following some on what Bob Wyman proposed this afternoon, I would like > to propose that we split the set of header fields into some logical > groupings: > >> 1. Top-level fields that require integrity protection (e.g., cty or a > digest algorithm parameter) > >> 2. Top-level fields that do not require integrity protection (e.g., x5c) > >> 3. Fields that are specific to a signer (e.g., jwk) > >> 4. Fields that are specific to a recipient (e.g., epk) > >> > >> In this taxonomy, only fields of type (1) need to be base64-encoded for > to preserve their serialization, and fields of type (3) and (4) could be > gathered together into the moral equivalent of SignerInfo and RecipientInfo > objects. All this makes the JSON serialization a lot cleaner, for example: > >> > >> { > >> "type": "S", > >> "header": "[base64-type1]", > >> "params": { /* type2 */ }, > >> "content": "[base64-content]", > >> "signers": [ > >> { /* type3 */ } > >> ] > >> } > >> > >> You can also imagine a reasonable compact serialization, something like: > >> > >> > S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. > ... > >> > >> That encoding even has the benefit that the multi-signer case doesn't > add any overhead over the single-signer case, except for maybe a couple of > "." characters. (Obviously, you would want some structure on how the signer > info gets serialized, but that's another level of detail down. You could > imagine something like "[signer-header].[public-key].[signature-value]".) > >> > >> The additional structure might seem like it's more work to parse, but I > don't think it's really that bad. Given a parsed JOSE object "obj": > >> 1. Decode obj.header and add its fields to obj.params > >> 2. Look through "signers" / "recipients" to find one we understand > >> 3. Verify / decrypt content using signer/recipient info and parameters > >> > >> There are several details to be worked out -- most critically, which > fields go in which groupings -- but I thought I would throw out the general > idea for comment before diving into the details. > >> > >> Cheers, > >> --Richard > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > > 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 > --bcaec54fb042eb7c3804c7f0fa5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll reiterate that I'd very much like to see the single signer and= single recipient cases remain as simple as possible.

On Thu, Aug 23, 2012 at 9:54 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
I agree with you, Justin.

My impression is that the multi-party communication and multi-party securit= y scenario will either have to live with additional overhead (Richard, how = much overhead are we talking about) or (what is more likely) there will be = a different mechanism used (which is what happened with security for multi-= party communication in the IETF in general).

Ciao
Hannes


On Aug 23, 2012, at 6:17 PM, Justin Richer wrote:

> I'd like to pose the question of what constitutes "a bit of e= xtra overhead". Making the overhead mandatory to support in the core c= an lead to developer friction for the majority cases.
>
> This reminds me of the discussion on the OAuth list about returning mu= ltiple tokens. Sometimes, yes, you want to return multiple access tokens. U= sually it's just one. We could have made the return value an array inst= ead of a string, but then you'd force every client to pull out "ac= cess_token[0]" instead of just "access_token", and that'= s an annoyance for the non-rare case. In =A0 =A0 =A0 the end, the group dec= ided on supporting the simple case in the core and letting an extension def= ine the multi-token format. That extension was never proposed, so I would w= ager that the multi-token case was at least rare enough to not force the st= andardization question.
>
> I think the same approach should be taken here. Keep the existing, dep= loyed, simple format of header.payload.signature for the simple single-sign= ature case. Use a different serialization format for different use case, su= ch as the JWS-JSON format that Mike's proposed or the multi-dot format = proposed below. I would argue that they're fundamentally different kind= s of objects and that conflating their use cases by forcing the overhead is= a big mistake.
>
> =A0-- Justin
>
> On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> Here is my view: the muliple recipient case is a rare case. Having= a bit of extra overhead for rare cases is IMHO acceptable to keep the core= spec simpler.
>>
>> hannes
>>
>> Sent from my Windows Phone
>> From: ext Richard L.= Barnes
>> Sent: 8/18/2012 12:58 AM
>> To: jose@ietf.org
>> Subject: [jose] Splitting headers
>>
>> Hey all,
>>
>> At IETF 84, I suggested that we take another look at what header i= nformation gets integrity-protected and what doesn't. =A0The main issue= being that in multiple-recipient or multiple-signer scenarios, there's= unnecessary duplication of data if recipient- or signer-specific informati= on is in the integrity-protected header.
>>
>> Following some on what Bob Wyman proposed this afternoon, I would = like to propose that we split the set of header fields into some logical gr= oupings:
>> 1. Top-level fields that require integrity protection (e.g., cty o= r a digest algorithm parameter)
>> 2. Top-level fields that do not require integrity protection (e.g.= , x5c)
>> 3. Fields that are specific to a signer (e.g., jwk)
>> 4. Fields that are specific to a recipient (e.g., epk)
>>
>> In this taxonomy, only fields of type (1) need to be base64-encode= d for to preserve their serialization, and fields of type (3) and (4) could= be gathered together into the moral equivalent of SignerInfo and Recipient= Info objects. =A0All this makes the JSON serialization a lot cleaner, for e= xample:
>>
>> {
>> =A0 =A0 "type": "S",
>> =A0 =A0 "header": "[base64-type1]",
>> =A0 =A0 "params": { /* type2 */ },
>> =A0 =A0 "content": "[base64-content]",
>> =A0 =A0 "signers": [
>> =A0 =A0 =A0 =A0 { /* type3 */ }
>> =A0 =A0 ]
>> }
>>
>> You can also imagine a reasonable compact serialization, something= like:
>>
>> S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].= [base64-signer2]. ...
>>
>> That encoding even has the benefit that the multi-signer case does= n't add any overhead over the single-signer case, except for maybe a co= uple of "." characters. (Obviously, you would want some structure= on how the signer info gets serialized, but that's another level of de= tail down. =A0You could imagine something like "[signer-header].[publi= c-key].[signature-value]".)
>>
>> The additional structure might seem like it's more work to par= se, but I don't think it's really that bad. =A0Given a parsed JOSE = object "obj":
>> 1. Decode obj.header and add its fields to obj.params
>> 2. Look through "signers" / "recipients" to fi= nd one we understand
>> 3. Verify / decrypt content using signer/recipient info and parame= ters
>>
>> There are several details to be worked out -- most critically, whi= ch fields go in which groupings -- but I thought I would throw out the gene= ral idea for comment before diving into the details.
>>
>> Cheers,
>> --Richard
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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

--bcaec54fb042eb7c3804c7f0fa5d-- From sakimura@gmail.com Thu Aug 23 09:25:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A24421F854B for ; Thu, 23 Aug 2012 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7z7MxGsDSjI for ; Thu, 23 Aug 2012 09:24:59 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B938021F8522 for ; Thu, 23 Aug 2012 09:24:58 -0700 (PDT) Received: by qadz3 with SMTP id z3so607265qad.10 for ; Thu, 23 Aug 2012 09:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d4bgx7mBAfwCCNGt++83M826aTsOHza/Af03o2Bv06A=; b=Rn0SWfXo0qCXP1sFv0QmTdE2KgmBYNL2TV+qKMjjD5eKZ2maMPMF0hpYLK5iW6IIRx Onkuo41OaS6lSel43RFw9R15iaZkYWrUqoIp2DbZ4OItfmqef5/Dtu4ep7JSUHymKkib DmL1Xr9zViPnJeocaaA+ro68vn19V/XYfZ1Psjlc/nbURcp+BL4EjcDuHC5escnzArJf kIGHsccNWQm3C3AgiaN0eCWWFy9WVvAk972ZDfqwLb1u7U4Y8+43HyRs80jbnjdG6ROd 89ReqajASHrynhoKdA2+BM7D86fFHHOWh+3nxvIuxv3zaTbLGR+KgraWR/YYstuqxflv K8bw== MIME-Version: 1.0 Received: by 10.224.174.75 with SMTP id s11mr3599759qaz.88.1345739097893; Thu, 23 Aug 2012 09:24:57 -0700 (PDT) Received: by 10.49.94.115 with HTTP; Thu, 23 Aug 2012 09:24:57 -0700 (PDT) In-Reply-To: <50364996.1050502@mitre.org> References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> <50364996.1050502@mitre.org> Date: Fri, 24 Aug 2012 01:24:57 +0900 Message-ID: From: Nat Sakimura To: Justin Richer Content-Type: multipart/alternative; boundary=20cf30334811e3ea0104c7f14cd5 Cc: "ext Richard L. Barnes" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , jose@ietf.org Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:25:00 -0000 --20cf30334811e3ea0104c7f14cd5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 24, 2012 at 12:17 AM, Justin Richer wrote: > I'd like to pose the question of what constitutes "a bit of extra > overhead". Making the overhead mandatory to support in the core can lead to > developer friction for the majority cases. > > This reminds me of the discussion on the OAuth list about returning > multiple tokens. Sometimes, yes, you want to return multiple access tokens. > Usually it's just one. We could have made the return value an array instead > of a string, but then you'd force every client to pull out > "access_token[0]" instead of just "access_token", and that's an annoyance > for the non-rare case. In the end, the group decided on supporting the > simple case in the core and letting an extension define the multi-token > format. That extension was never proposed, so I would wager that the > multi-token case was at least rare enough to not force the standardization > question. > Actually, we decided to do it as an extension, called OpenID Connect. Userinfo endpoint actually returns multiple tokens. > > I think the same approach should be taken here. Keep the existing, > deployed, simple format of header.payload.signature for the simple > single-signature case. Use a different serialization format for different > use case, such as the JWS-JSON format that Mike's proposed or the multi-dot > format proposed below. I would argue that they're fundamentally different > kinds of objects and that conflating their use cases by forcing the > overhead is a big mistake. > +1 Note: I have a multi-signature use case that I have to solve, but I believe for the adoption purpose, we should be focused on the main use cases. > > -- Justin > > > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Here is my view: the muliple recipient case is a rare case. Having a bit > of extra overhead for rare cases is IMHO acceptable to keep the core spec > simpler. > > hannes > > Sent from my Windows Phone > ------------------------------ > From: ext Richard L. Barnes > Sent: 8/18/2012 12:58 AM > To: jose@ietf.org > Subject: [jose] Splitting headers > > Hey all, > > At IETF 84, I suggested that we take another look at what header > information gets integrity-protected and what doesn't. The main issue > being that in multiple-recipient or multiple-signer scenarios, there's > unnecessary duplication of data if recipient- or signer-specific > information is in the integrity-protected header. > > Following some on what Bob Wyman proposed this afternoon, I would like to > propose that we split the set of header fields into some logical groupings: > 1. Top-level fields that require integrity protection (e.g., cty or a > digest algorithm parameter) > 2. Top-level fields that do not require integrity protection (e.g., x5c) > 3. Fields that are specific to a signer (e.g., jwk) > 4. Fields that are specific to a recipient (e.g., epk) > > In this taxonomy, only fields of type (1) need to be base64-encoded for to > preserve their serialization, and fields of type (3) and (4) could be > gathered together into the moral equivalent of SignerInfo and RecipientInfo > objects. All this makes the JSON serialization a lot cleaner, for example: > > { > "type": "S", > "header": "[base64-type1]", > "params": { /* type2 */ }, > "content": "[base64-content]", > "signers": [ > { /* type3 */ } > ] > } > > You can also imagine a reasonable compact serialization, something like: > > S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. > ... > > That encoding even has the benefit that the multi-signer case doesn't add > any overhead over the single-signer case, except for maybe a couple of "." > characters. (Obviously, you would want some structure on how the signer > info gets serialized, but that's another level of detail down. You could > imagine something like "[signer-header].[public-key].[signature-value]".) > > The additional structure might seem like it's more work to parse, but I > don't think it's really that bad. Given a parsed JOSE object "obj": > 1. Decode obj.header and add its fields to obj.params > 2. Look through "signers" / "recipients" to find one we understand > 3. Verify / decrypt content using signer/recipient info and parameters > > There are several details to be worked out -- most critically, which > fields go in which groupings -- but I thought I would throw out the general > idea for comment before diving into the details. > > Cheers, > --Richard > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --20cf30334811e3ea0104c7f14cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 24, 2012 at 12:17 AM, Justin= Richer <jricher@mitre.org> wrote:
=20 =20 =20
I'd like to pose the question of what constitutes "a bit of extra overhead". Making the overhead mandatory to support in the core can lead to developer friction for the majority cases.

This reminds me of the discussion on the OAuth list about returning multiple tokens. Sometimes, yes, you want to return multiple access tokens. Usually it's just one. We could have made the return value an array instead of a string, but then you'd force every client to pull out "access_token[0]" instead of= just "access_token", and that's an annoyance for the non-rar= e case. In the end, the group decided on supporting the simple case in the core and letting an extension define the multi-token format. That extension was never proposed, so I would wager that the multi-token case was at least rare enough to not force the standardization question.

=
Actually, we decided to do it as an extension, called OpenID Connect.= =A0
Userinfo endpoint actually returns multiple tokens.=A0
<= div> =A0

I think the same approach should be taken here. Keep the existing, deployed, simple format of header.payload.signature for the simple single-signature case. Use a different serialization format for different use case, such as the JWS-JSON format that Mike's proposed or the multi-dot format proposed below. I would argue that they're fundamentally different kinds of objects and that conflating their use cases by forcing the overhead is a big mistake.

+1=A0
=
Note: I have a multi-signature use case that I have to solve= , but I believe for the adoption purpose, we should be focused on the main = use cases. =A0=A0



=A0-- Justin


On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
=20
Here is my view: the muliple recipient case is a rare case. Having a bit of extra overhead for rare cases is IMHO acceptable to keep the core spec simpler.

hannes

Sent from my Windows Phone
From: ext Richard L. Barnes
Sent: 8/18/2012 12:58 AM
To: jose@ietf.org<= /span>
Subject: [jose] Splitting headers

Hey all,

At IETF 84, I suggested that we take another look at what header information gets integrity-protected and what doesn't.=A0 The mai= n issue being that in multiple-recipient or multiple-signer scenarios, there's unnecessary duplication of data if recipient- or signer-specific information is in the integrity-protected header.

Following some on what Bob Wyman proposed this afternoon, I would like to propose that we split the set of header fields into some logical groupings:
1. Top-level fields that require integrity protection (e.g., cty or a digest algorithm parameter)
2. Top-level fields that do not require integrity protection (e.g., x5c)
3. Fields that are specific to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g., epk)

In this taxonomy, only fields of type (1) need to be base64-encoded for to preserve their serialization, and fields of type (3) and (4) could be gathered together into the moral equivalent of SignerInfo and RecipientInfo objects.=A0 All this makes the JSON serialization a lot cleaner, for example:

{
=A0=A0=A0 "type": "S",
=A0=A0=A0 "header": "[base64-type1]",
=A0=A0=A0 "params": { /* type2 */ },
=A0=A0=A0 "content": "[base64-content]",
=A0=A0=A0 "signers": [
=A0=A0=A0=A0=A0=A0=A0 { /* type3 */ }
=A0=A0=A0 ]
}

You can also imagine a reasonable compact serialization, something like:

S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[ba= se64-signer2]. ...

That encoding even has the benefit that the multi-signer case doesn't add any overhead over the single-signer case, except for maybe a couple of "." characters. (Obviously, you would wan= t some structure on how the signer info gets serialized, but that's another level of detail down.=A0 You could imagine something like "[signer-header].[public-key].[signature-value]".)

The additional structure might seem like it's more work to parse, but I don't think it's really that bad.=A0 Given a parsed JOS= E object "obj":
1. Decode obj.header and add its fields to obj.params
2. Look through "signers" / "recipients" to find = one we understand
3. Verify / decrypt content using signer/recipient info and parameters

There are several details to be worked out -- most critically, which fields go in which groupings -- but I thought I would throw out the general idea for comment before diving into the details.

Cheers,
--Richard




_______________________________________________
jose mailing list
jose@ietf.org<= br> https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--20cf30334811e3ea0104c7f14cd5-- From jricher@mitre.org Thu Aug 23 10:01:36 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B54821F85AD for ; Thu, 23 Aug 2012 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcmKkwLF4P9H for ; Thu, 23 Aug 2012 10:01:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8221F85B8 for ; Thu, 23 Aug 2012 10:01:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D82A221B1AC1; Thu, 23 Aug 2012 13:01:33 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B66B821B1A0D; Thu, 23 Aug 2012 13:01:33 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 23 Aug 2012 13:01:33 -0400 Message-ID: <503661ED.8040409@mitre.org> Date: Thu, 23 Aug 2012 13:01:33 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Nat Sakimura References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> <50364996.1050502@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070902070607040707000609" X-Originating-IP: [129.83.31.58] Cc: "ext Richard L. Barnes" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , jose@ietf.org Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:01:36 -0000 --------------070902070607040707000609 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > On Fri, Aug 24, 2012 at 12:17 AM, Justin Richer > wrote: > > That extension was never proposed, so I would wager that the > multi-token case was at least rare enough to not force the > standardization question. > > > Actually, we decided to do it as an extension, called OpenID Connect. > Userinfo endpoint actually returns multiple tokens. > Just to clarify -- this isn't quite the same thing. What folks had been asking about was not multiple different kinds of tokens at once, which the existing JSON structure makes amenable, but multiple parallel access tokens, each with their own values and (potentially) metadata. The two tokens that Connect returns have different purposes, different audiences, potentially very different formats and structures. This is why they come back as two tokens in different members, "access_token" and "id_token". What was discussed on the group was more the case where you'd have an array of "access_token" values. > > I think the same approach should be taken here. Keep the existing, > deployed, simple format of header.payload.signature for the simple > single-signature case. Use a different serialization format for > different use case, such as the JWS-JSON format that Mike's > proposed or the multi-dot format proposed below. I would argue > that they're fundamentally different kinds of objects and that > conflating their use cases by forcing the overhead is a big mistake. > > > +1 > > Note: I have a multi-signature use case that I have to solve, but I > believe for the adoption purpose, we should be focused on the main use > cases. Right, there are definitely use cases for this, but I think that it's a different solution that's needed here. There isn't always a nice, single general abstraction. -- Justin > > > > -- Justin > > > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Here is my view: the muliple recipient case is a rare case. >> Having a bit of extra overhead for rare cases is IMHO acceptable >> to keep the core spec simpler. >> >> hannes >> >> Sent from my Windows Phone >> ------------------------------------------------------------------------ >> From: ext Richard L. Barnes >> Sent: 8/18/2012 12:58 AM >> To: jose@ietf.org >> Subject: [jose] Splitting headers >> >> Hey all, >> >> At IETF 84, I suggested that we take another look at what header >> information gets integrity-protected and what doesn't. The main >> issue being that in multiple-recipient or multiple-signer >> scenarios, there's unnecessary duplication of data if recipient- >> or signer-specific information is in the integrity-protected header. >> >> Following some on what Bob Wyman proposed this afternoon, I would >> like to propose that we split the set of header fields into some >> logical groupings: >> 1. Top-level fields that require integrity protection (e.g., cty >> or a digest algorithm parameter) >> 2. Top-level fields that do not require integrity protection >> (e.g., x5c) >> 3. Fields that are specific to a signer (e.g., jwk) >> 4. Fields that are specific to a recipient (e.g., epk) >> >> In this taxonomy, only fields of type (1) need to be >> base64-encoded for to preserve their serialization, and fields of >> type (3) and (4) could be gathered together into the moral >> equivalent of SignerInfo and RecipientInfo objects. All this >> makes the JSON serialization a lot cleaner, for example: >> >> { >> "type": "S", >> "header": "[base64-type1]", >> "params": { /* type2 */ }, >> "content": "[base64-content]", >> "signers": [ >> { /* type3 */ } >> ] >> } >> >> You can also imagine a reasonable compact serialization, >> something like: >> >> S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. >> ... >> >> That encoding even has the benefit that the multi-signer case >> doesn't add any overhead over the single-signer case, except for >> maybe a couple of "." characters. (Obviously, you would want some >> structure on how the signer info gets serialized, but that's >> another level of detail down. You could imagine something like >> "[signer-header].[public-key].[signature-value]".) >> >> The additional structure might seem like it's more work to parse, >> but I don't think it's really that bad. Given a parsed JOSE >> object "obj": >> 1. Decode obj.header and add its fields to obj.params >> 2. Look through "signers" / "recipients" to find one we understand >> 3. Verify / decrypt content using signer/recipient info and >> parameters >> >> There are several details to be worked out -- most critically, >> which fields go in which groupings -- but I thought I would throw >> out the general idea for comment before diving into the details. >> >> Cheers, >> --Richard >> >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --------------070902070607040707000609 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On Fri, Aug 24, 2012 at 12:17 AM, Justin Richer <jricher@mitre.org> wrote:
That extension was never proposed, so I would wager that the multi-token case was at least rare enough to not force the standardization question.

Actually, we decided to do it as an extension, called OpenID Connect. 
Userinfo endpoint actually returns multiple tokens. 
 

Just to clarify -- this isn't quite the same thing. What folks had been asking about was not multiple different kinds of tokens at once, which the existing JSON structure makes amenable, but multiple parallel access tokens, each with their own values and (potentially) metadata. The two tokens that Connect returns have different purposes, different audiences, potentially very different formats and structures. This is why they come back as two tokens in different members, "access_token" and "id_token". What was discussed on the group was more the case where you'd have an array of "access_token" values.


I think the same approach should be taken here. Keep the existing, deployed, simple format of header.payload.signature for the simple single-signature case. Use a different serialization format for different use case, such as the JWS-JSON format that Mike's proposed or the multi-dot format proposed below. I would argue that they're fundamentally different kinds of objects and that conflating their use cases by forcing the overhead is a big mistake.

+1 

Note: I have a multi-signature use case that I have to solve, but I believe for the adoption purpose, we should be focused on the main use cases.  

Right, there are definitely use cases for this, but I think that it's a different solution that's needed here. There isn't always a nice, single general abstraction.

 -- Justin




 -- Justin


On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Here is my view: the muliple recipient case is a rare case. Having a bit of extra overhead for rare cases is IMHO acceptable to keep the core spec simpler.

hannes

Sent from my Windows Phone
From: ext Richard L. Barnes
Sent: 8/18/2012 12:58 AM
To: jose@ietf.org
Subject: [jose] Splitting headers

Hey all,

At IETF 84, I suggested that we take another look at what header information gets integrity-protected and what doesn't.  The main issue being that in multiple-recipient or multiple-signer scenarios, there's unnecessary duplication of data if recipient- or signer-specific information is in the integrity-protected header.

Following some on what Bob Wyman proposed this afternoon, I would like to propose that we split the set of header fields into some logical groupings:
1. Top-level fields that require integrity protection (e.g., cty or a digest algorithm parameter)
2. Top-level fields that do not require integrity protection (e.g., x5c)
3. Fields that are specific to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g., epk)

In this taxonomy, only fields of type (1) need to be base64-encoded for to preserve their serialization, and fields of type (3) and (4) could be gathered together into the moral equivalent of SignerInfo and RecipientInfo objects.  All this makes the JSON serialization a lot cleaner, for example:

{
    "type": "S",
    "header": "[base64-type1]",
    "params": { /* type2 */ },
    "content": "[base64-content]",
    "signers": [
        { /* type3 */ }
    ]
}

You can also imagine a reasonable compact serialization, something like:

S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. ...

That encoding even has the benefit that the multi-signer case doesn't add any overhead over the single-signer case, except for maybe a couple of "." characters. (Obviously, you would want some structure on how the signer info gets serialized, but that's another level of detail down.  You could imagine something like "[signer-header].[public-key].[signature-value]".)

The additional structure might seem like it's more work to parse, but I don't think it's really that bad.  Given a parsed JOSE object "obj":
1. Decode obj.header and add its fields to obj.params
2. Look through "signers" / "recipients" to find one we understand
3. Verify / decrypt content using signer/recipient info and parameters

There are several details to be worked out -- most critically, which fields go in which groupings -- but I thought I would throw out the general idea for comment before diving into the details.

Cheers,
--Richard




_______________________________________________
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


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




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


--------------070902070607040707000609-- From jricher@mitre.org Thu Aug 23 10:25:28 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FB621F855E for ; Thu, 23 Aug 2012 10:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKIJKhBPtE7m for ; Thu, 23 Aug 2012 10:25:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 786BC21F8609 for ; Thu, 23 Aug 2012 10:25:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E8AB321B1AFA; Thu, 23 Aug 2012 13:25:24 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DA7AF21B07DB; Thu, 23 Aug 2012 13:25:24 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 23 Aug 2012 13:25:24 -0400 Message-ID: <50366784.70803@mitre.org> Date: Thu, 23 Aug 2012 13:25:24 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Bob Wyman References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> <50364996.1050502@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080608070608070308040604" X-Originating-IP: [129.83.31.58] Cc: "jose@ietf.org" Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:25:28 -0000 --------------080608070608070308040604 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit [pulling the jose list back on the thread] I agree that too much simplicity can be as much as an impediment as too much complexity, but I don't think we've hit that here. I could of course be wrong, but the single-signature use case seems to be pretty well-established. I'm not arguing that you should never make a breaking change during the specification process, but that any breaking change, especially one so deeply fundamental as this, needs to have very strong support in both group consensus and running code. So with that in mind: What's the cause for splitting payload and signature headers? What kind of information constitutes a "payload header" anyway? Just about every claim that's defined in the header today is for the signature or encryption. And you need to protect all of them with the signature in either case. -- Justin On 08/23/2012 01:01 PM, Bob Wyman wrote: > Simplicity is good, but sometimes too much simplicity can prevent us > from doing things that would be valuable to our eventual users. In > this case, I will admit that I am asking for a bit of additional > complexity -- but, it should be recognized as well that I am also > calling for additional simplicity in the structuring of the data. > Rather than mixing things up, I suggest separating them into logical > processing groups. > > I argue that instead of: >
.. > we should have: > ... > where payload header contains only that data which is specific to the > payload and the signature_header contains only data relevant to the > signature. Given that the content of the signature_header is what is > currently already defined as part of the
, then the added > message size is only several bytes. I cannot see that there is much > added complexity in the code, since any code written will typically > first concern itself with the payload related data, wherever it is, > and then concern itself with the signature related stuff. Frankly, it > looks to me like while their might be more code to handle four parts > rather than three, the code itself would be cleaner and better > structured since it would inevitably tend to reflect the better > compartmentalization and separation of concerns in the encoded data. > One interesting side-effect of my "simplifying" proposal is that what > falls out of it is a simple way to transmit unsigned data. (i.e. > . without a signature.)... > > Certainly, my suggestion is motivated largely by the > multiple-signature use case (which is required for many applications), > but I am also motivated by a desire to see the data structures be > better normalized. And, I would like to do what can be done now to > simplify the process of defining extensions in the future (from a > standards process point of view) as well as simplicity when people > decide to adopt an extension. > > The current definition doesn't seem to me to provide much room for > extensions that would handle the multi-signature case. The only > alternative seems to be not an extension but rather a completely new > spec. Clearly, given the process overhead in IETF, that isn't going to > move along slowly. We would probably spend much more time debating the > extension/alternative as would be consumed in aggregate by all the > developers who needed to handle four parts rather than three... In any > case, the harsh reality is that non-core extensions are rarely > implemented if they aren't firmly rooted in the conventions of the > core specification -- no matter what the standard. > > How about this as a compromise? > *Consider using the four-part format that I suggest, but stay silent > on the subject of multiple signatures or any other extensions.* Then, > i'll write up a draft that covers a variety of extensions that > leverage the four-part format -- including the multi-signature case. > If this strategy is used, the core spec will be better structured and > it will remain very "simple" -- but it will be simple in a way that > makes it vastly easier and cleaner to define extensions with minimal > divergence from the simple core. Developers will be served by this > approach since it should make it easier for them to incorporate > support for extensions in the future, if they choose to. And, users > will be served because it makes it easier for us to define extensions > that serve their needs. > > bob wyman > > On Thu, Aug 23, 2012 at 11:17 AM, Justin Richer > wrote: > > I'd like to pose the question of what constitutes "a bit of extra > overhead". Making the overhead mandatory to support in the core > can lead to developer friction for the majority cases. > > This reminds me of the discussion on the OAuth list about > returning multiple tokens. Sometimes, yes, you want to return > multiple access tokens. Usually it's just one. We could have made > the return value an array instead of a string, but then you'd > force every client to pull out "access_token[0]" instead of just > "access_token", and that's an annoyance for the non-rare case. In > the end, the group decided on supporting the simple case in the > core and letting an extension define the multi-token format. That > extension was never proposed, so I would wager that the > multi-token case was at least rare enough to not force the > standardization question. > > I think the same approach should be taken here. Keep the existing, > deployed, simple format of header.payload.signature for the simple > single-signature case. Use a different serialization format for > different use case, such as the JWS-JSON format that Mike's > proposed or the multi-dot format proposed below. I would argue > that they're fundamentally different kinds of objects and that > conflating their use cases by forcing the overhead is a big mistake. > > -- Justin > > > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Here is my view: the muliple recipient case is a rare case. >> Having a bit of extra overhead for rare cases is IMHO acceptable >> to keep the core spec simpler. >> >> hannes >> >> Sent from my Windows Phone >> ------------------------------------------------------------------------ >> From: ext Richard L. Barnes >> Sent: 8/18/2012 12:58 AM >> To: jose@ietf.org >> Subject: [jose] Splitting headers >> >> Hey all, >> >> At IETF 84, I suggested that we take another look at what header >> information gets integrity-protected and what doesn't. The main >> issue being that in multiple-recipient or multiple-signer >> scenarios, there's unnecessary duplication of data if recipient- >> or signer-specific information is in the integrity-protected header. >> >> Following some on what Bob Wyman proposed this afternoon, I would >> like to propose that we split the set of header fields into some >> logical groupings: >> 1. Top-level fields that require integrity protection (e.g., cty >> or a digest algorithm parameter) >> 2. Top-level fields that do not require integrity protection >> (e.g., x5c) >> 3. Fields that are specific to a signer (e.g., jwk) >> 4. Fields that are specific to a recipient (e.g., epk) >> >> In this taxonomy, only fields of type (1) need to be >> base64-encoded for to preserve their serialization, and fields of >> type (3) and (4) could be gathered together into the moral >> equivalent of SignerInfo and RecipientInfo objects. All this >> makes the JSON serialization a lot cleaner, for example: >> >> { >> "type": "S", >> "header": "[base64-type1]", >> "params": { /* type2 */ }, >> "content": "[base64-content]", >> "signers": [ >> { /* type3 */ } >> ] >> } >> >> You can also imagine a reasonable compact serialization, >> something like: >> >> S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. >> ... >> >> That encoding even has the benefit that the multi-signer case >> doesn't add any overhead over the single-signer case, except for >> maybe a couple of "." characters. (Obviously, you would want some >> structure on how the signer info gets serialized, but that's >> another level of detail down. You could imagine something like >> "[signer-header].[public-key].[signature-value]".) >> >> The additional structure might seem like it's more work to parse, >> but I don't think it's really that bad. Given a parsed JOSE >> object "obj": >> 1. Decode obj.header and add its fields to obj.params >> 2. Look through "signers" / "recipients" to find one we understand >> 3. Verify / decrypt content using signer/recipient info and >> parameters >> >> There are several details to be worked out -- most critically, >> which fields go in which groupings -- but I thought I would throw >> out the general idea for comment before diving into the details. >> >> Cheers, >> --Richard >> >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --------------080608070608070308040604 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
[pulling the jose list back on the thread]

I agree that too much simplicity can be as much as an impediment as too much complexity, but I don't think we've hit that here. I could of course be wrong, but the single-signature use case seems to be pretty well-established. I'm not arguing that you should never make a breaking change during the specification process, but that any breaking change, especially one so deeply fundamental as this, needs to have very strong support in both group consensus and running code.

So with that in mind: What's the cause for splitting payload and signature headers? What kind of information constitutes a "payload header" anyway? Just about every claim that's defined in the header today is for the signature or encryption. And you need to protect all of them with the signature in either case.

 -- Justin

On 08/23/2012 01:01 PM, Bob Wyman wrote:
Simplicity is good, but sometimes too much simplicity can prevent us from doing things that would be valuable to our eventual users. In this case, I will admit that I am asking for a bit of additional complexity -- but, it should be recognized as well that I am also calling for additional simplicity in the structuring of the data. Rather than mixing things up, I suggest separating them into logical processing groups.

I argue that instead of:
  <header>.<payload>.<signature>
we should have:
  <payload_header>.<payload>.<signature_header>.<signature>
where payload header contains only that data which is specific to the payload and the signature_header contains only data relevant to the signature. Given that the content of the signature_header is what is currently already defined as part of the <header>, then the added message size is only several bytes. I cannot see that there is much added complexity in the code, since any code written will typically first concern itself with the payload related data, wherever it is, and then concern itself with the signature related stuff. Frankly, it looks to me like while their might be more code to handle four parts rather than three, the code itself would be cleaner and better structured since it would inevitably tend to reflect the better compartmentalization and separation of concerns in the encoded data. One interesting side-effect of my "simplifying" proposal is that what falls out of it is a simple way to transmit unsigned data. (i.e. <payload_header>.<payload> without a signature.)...

Certainly, my suggestion is motivated largely by the multiple-signature use case (which is required for many applications), but I am also motivated by a desire to see the data structures be better normalized. And, I would like to do what can be done now to simplify the process of defining extensions in the future (from a standards process point of view) as well as simplicity when people decide to adopt an extension.

The current definition doesn't seem to me to provide much room for extensions that would handle the multi-signature case. The only alternative seems to be not an extension but rather a completely new spec. Clearly, given the process overhead in IETF, that isn't going to move along slowly. We would probably spend much more time debating the extension/alternative as would be consumed in aggregate by all the developers who needed to handle four parts rather than three... In any case, the harsh reality is that non-core extensions are rarely implemented if they aren't firmly rooted in the conventions of the core specification -- no matter what the standard.

How about this as a compromise?
Consider using the four-part format that I suggest, but stay silent on the subject of multiple signatures or any other extensions. Then, i'll write up a draft that covers a variety of extensions that leverage the four-part format -- including the multi-signature case. If this strategy is used, the core spec will be better structured and it will remain very "simple" -- but it will be simple in a way that makes it vastly easier and cleaner to define extensions with minimal divergence from the simple core. Developers will be served by this approach since it should make it easier for them to incorporate support for extensions in the future, if they choose to. And, users will be served because it makes it easier for us to define extensions that serve their needs.

bob wyman

On Thu, Aug 23, 2012 at 11:17 AM, Justin Richer <jricher@mitre.org> wrote:
I'd like to pose the question of what constitutes "a bit of extra overhead". Making the overhead mandatory to support in the core can lead to developer friction for the majority cases.

This reminds me of the discussion on the OAuth list about returning multiple tokens. Sometimes, yes, you want to return multiple access tokens. Usually it's just one. We could have made the return value an array instead of a string, but then you'd force every client to pull out "access_token[0]" instead of just "access_token", and that's an annoyance for the non-rare case. In the end, the group decided on supporting the simple case in the core and letting an extension define the multi-token format. That extension was never proposed, so I would wager that the multi-token case was at least rare enough to not force the standardization question.

I think the same approach should be taken here. Keep the existing, deployed, simple format of header.payload.signature for the simple single-signature case. Use a different serialization format for different use case, such as the JWS-JSON format that Mike's proposed or the multi-dot format proposed below. I would argue that they're fundamentally different kinds of objects and that conflating their use cases by forcing the overhead is a big mistake.

 -- Justin


On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Here is my view: the muliple recipient case is a rare case. Having a bit of extra overhead for rare cases is IMHO acceptable to keep the core spec simpler.

hannes

Sent from my Windows Phone
From: ext Richard L. Barnes
Sent: 8/18/2012 12:58 AM
To: jose@ietf.org
Subject: [jose] Splitting headers

Hey all,

At IETF 84, I suggested that we take another look at what header information gets integrity-protected and what doesn't.  The main issue being that in multiple-recipient or multiple-signer scenarios, there's unnecessary duplication of data if recipient- or signer-specific information is in the integrity-protected header.

Following some on what Bob Wyman proposed this afternoon, I would like to propose that we split the set of header fields into some logical groupings:
1. Top-level fields that require integrity protection (e.g., cty or a digest algorithm parameter)
2. Top-level fields that do not require integrity protection (e.g., x5c)
3. Fields that are specific to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g., epk)

In this taxonomy, only fields of type (1) need to be base64-encoded for to preserve their serialization, and fields of type (3) and (4) could be gathered together into the moral equivalent of SignerInfo and RecipientInfo objects.  All this makes the JSON serialization a lot cleaner, for example:

{
    "type": "S",
    "header": "[base64-type1]",
    "params": { /* type2 */ },
    "content": "[base64-content]",
    "signers": [
        { /* type3 */ }
    ]
}

You can also imagine a reasonable compact serialization, something like:

S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. ...

That encoding even has the benefit that the multi-signer case doesn't add any overhead over the single-signer case, except for maybe a couple of "." characters. (Obviously, you would want some structure on how the signer info gets serialized, but that's another level of detail down.  You could imagine something like "[signer-header].[public-key].[signature-value]".)

The additional structure might seem like it's more work to parse, but I don't think it's really that bad.  Given a parsed JOSE object "obj":
1. Decode obj.header and add its fields to obj.params
2. Look through "signers" / "recipients" to find one we understand
3. Verify / decrypt content using signer/recipient info and parameters

There are several details to be worked out -- most critically, which fields go in which groupings -- but I thought I would throw out the general idea for comment before diving into the details.

Cheers,
--Richard




_______________________________________________
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


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



--------------080608070608070308040604-- From Michael.Jones@microsoft.com Thu Aug 23 11:15:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C46921F8630 for ; Thu, 23 Aug 2012 11:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmPbRQV3CBGx for ; Thu, 23 Aug 2012 11:15:28 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3521F8620 for ; Thu, 23 Aug 2012 11:15:28 -0700 (PDT) Received: from mail268-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 Aug 2012 18:15:27 +0000 Received: from mail268-va3 (localhost [127.0.0.1]) by mail268-va3-R.bigfish.com (Postfix) with ESMTP id DC9C317C057C; Thu, 23 Aug 2012 18:15:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zz9371I1415J1454I148cI542M1432Izz1202hzz1033IL8275eh8275dha1495iz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail268-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail268-va3 (localhost.localdomain [127.0.0.1]) by mail268-va3 (MessageSwitch) id 1345745726104062_31422; Thu, 23 Aug 2012 18:15:26 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.244]) by mail268-va3.bigfish.com (Postfix) with ESMTP id 0DBB81D00046; Thu, 23 Aug 2012 18:15:26 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 Aug 2012 18:15:24 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Thu, 23 Aug 2012 18:15:20 +0000 From: Mike Jones To: Jim Schaad , 'Harry Halpin' Thread-Topic: JOSE WG request from W3C WebCrypto API Thread-Index: AQHNeJunnpgcpjfvnEmN0vS5J/XJKJdbc0tAgAP0+oCACFgaoA== Date: Thu, 23 Aug 2012 18:15:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667A74DC@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <023301cd7d2c$c2f71c60$48e55520$@augustcellars.com> In-Reply-To: <023301cd7d2c$c2f71c60$48e55520$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 18:15:30 -0000 The use cases come from the WebCrypto spec, which requires key import/expor= t, and one of the supported import/export formats is JWK. See http://www.w= 3.org/2012/webcrypto/WebCryptoAPI/#KeyImporter-interface, for instance. Se= arch for "export" in the spec for other pertinent sections. I'm not saying that the private key format necessarily needs to be part of = JWK itself. The right solution might very well be an optional supplemental= spec. But I do think that it would be a good thing for JOSE to try to be responsi= ve to the W3C's request in this regard. That why I created http://tools.ie= tf.org/html/draft-jones-jose-json-private-key-00 to facilitate concrete dis= cussion of the possible solution space. Best wishes, -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Saturday, August 18, 2012 3:32 AM To: Mike Jones; 'Harry Halpin' Cc: jose@ietf.org Subject: RE: JOSE WG request from W3C WebCrypto API Mike, You have said that you think that doing this as JOSE structures would be us= eful. It is not clear to me that there is actually a use case defined here= that bears that out. Who is responsible for building and encrypting (or decrypting and parsing) = the structure? Are we suggesting that the private keys be exported in the c= lear and it is up to the JOSE developer to encrypt them or are we saying th= at it is up to the WebCrypto system to do this on behalf of the JOSE develo= per? If we say it is the JOSE developer, then this introduces lots of places whe= re the private keys will be handled insecurely - if nothing else from just = hanging around in memory until they get cleaned up. If we say that it is the WebCrypto system that does this, then we are sayin= g that we don't really care what the format of the private key blobs is int= ernally, we just need to know how to deal with them from the scripting side= - which would be as a blob of some type (either a binary blob or a string = blob). =20 Finally, how much do we want this to be a portable method of doing key tran= sport? All of the browsers currently have a method of doing an import and = export of an ASN.1 private key blob. What is the additional benefit that y= ou think would be obtained from the WebCrypto side from having a second for= mat that all of the browsers would need to support, but which might not hav= e the same level of support from various operating systems and key devices?= Would this then lead to scripters needing to have two different sets of i= mport/export code depending on what the internal structure was and potentia= lly needed to switch between the two structures? I think it makes sense to allow for the use of JOSE public keys since that = is being passed in the message structure itself. I don't believe that it m= akes a great deal of sense at this point in time to have a private key stru= cture defined. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, August 16, 2012 8:49 AM > To: Harry Halpin; Jim Schaad; Karen O'Donoghue;=20 > jose-chairs@tools.ietf.org > Cc: jose@ietf.org > Subject: RE: JOSE WG request from W3C WebCrypto API >=20 > Thanks for writing, Harry and WebCrypto WG. >=20 > 1) About private keys, given the WebCrypto use case, I personally=20 > think it > would be valuable for JOSE to define a JSON private key representation. To > make this concrete, I would propose the private key representations=20 > specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key= . > You'll see that doing this is very simple; it just defines two=20 > additional members for the JWK structure for representing the private=20 > parts of Elliptic > Curve and RSA keys. This could either remain a separate spec from=20 > JWK/JWA or be merged in, at the working group's preference. >=20 > I had previously agreed with the position that it was not necessary=20 > for JOSE > to define private key representations because we didn't have a use=20 > case for > it. However, as I see it, the W3C WebCrypto API use case changes things. > Better for JOSE to be responsive to WebCrypto and add this simple=20 > extension, either as a new spec or in the existing specs, than to=20 > leave this > undone, and have it potentially be an area where otherwise standards-=20 > compliant implementations diverge, and where JSON-only solutions are=20 > not possible. >=20 > Finally, I'll note that the JOSE charter=20 > http://datatracker.ietf.org/wg/jose/charter/ does not preclude=20 > defining private key formats. (It simply requires the definition of=20 > public key formats > and is silent on the topic of private keys.) >=20 > 2) I agree on the likely need for WebCrypto support ASN.1 for=20 > backwards compatibility in some cases (just as the JOSE specs allow=20 > the use of X.509 certificates). However, I believe it would be a=20 > shame to preclude JSON-only > solutions by not supporting key import/export in JWK format, where=20 > such solutions make sense. >=20 > 3) It appears to me the JWK format is stable. I believe the JWS=20 > format is > stable as well. The JWE format has known changes that will be applied=20 > shortly, based upon working group discussions at IETF 84 in Vancouver=20 > two weeks ago. Some JWA changes will occur that are part of the JWE chan= ges. I > don't anticipate significant changes after that. (Making these=20 > changes is my > highest priority as JOSE editor. I'm hoping to have drafts out=20 > containing them > by the end of August, which hopefully fits well with the WebCrypto > schedule.) I write all of the above with the caveat that the working group is, > of course, free to change things as they see fit. >=20 > I look forward to a productive discussion of this coordination request=20 > in both > working groups. >=20 > Best wishes, > -- Mike >=20 > P.S. If you prefer, a HTML-formatted version of the private key spec=20 > is available at=20 > http://self-issued.info/docs/draft-jones-jose-json-private- > key.html. I also blogged about this draft specification at=20 > http://self- issued.info/?p=3D816. >=20 > -----Original Message----- > From: Harry Halpin [mailto:hhalpin@w3.org] > Sent: Sunday, August 12, 2012 8:03 AM > To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike=20 > Jones > Subject: JOSE WG request from W3C WebCrypto API >=20 > [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] >=20 > JOSE Chairs, >=20 > The Web Cryptography Working group has noted that the API requires=20 > some access to raw key material, and the issue of whether or not to=20 > use JWK or > ASN.1 as the default format came up. Two issues have come out that=20 > we'd like to know the answer to: >=20 > 1) JWK does not define a private key format. Does the JOSE WG plan to=20 > support a JOSE-format for private keys? If so, when? Or 'maybe'? >=20 > 2) While we'd like encourage the use of JOSE over ASN.1, it seems=20 > like for > backwards compatibility having some level of ASN.1 support would be=20 > useful and we *need* a format that allows key material (both private=20 > and > public) to be exported. Folks seem to leaning towards ASN.1 as a=20 > default format in the low-level API, and having JWK as a format that=20 > can be built on > top of that in a possible high-level API. Would that be OK? >=20 > 3) How stable do you believe the JOSE formats are right now? Do you think > they are stable enough now we can reference them in our API draft at=20 > end of > August? If not, when? The W3C would like to and plan to use these=20 > formats where possible. >=20 > Feel free to forward this by JOSE WG for discussion. We'd like an=20 > answer before we send our document to FPWD at end of August. >=20 > cheers, > harry >=20 >=20 From hannes.tschofenig@gmx.net Thu Aug 23 11:57:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A4621F84DD for ; Thu, 23 Aug 2012 11:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4aOTddAKfc2 for ; Thu, 23 Aug 2012 11:57:47 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2D7C421F84B3 for ; Thu, 23 Aug 2012 11:57:46 -0700 (PDT) Received: (qmail invoked by alias); 23 Aug 2012 18:57:45 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp038) with SMTP; 23 Aug 2012 20:57:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX195yr0A3MF5/qMJTVwKiKsyAGzygKboTP/PTJ2hzP s7+/0tzuLuZuep Message-ID: <50367D24.3080307@gmx.net> Date: Thu, 23 Aug 2012 21:57:40 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Jones References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <023301cd7d2c$c2f71c60$48e55520$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943667A74DC@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667A74DC@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Jim Schaad , 'Harry Halpin' , "jose@ietf.org" Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 18:57:49 -0000 I had noticed the need for a mechanism to carry a privacy key in a JSON-based format already with the work on the OAuth-HOTK document. Without it I was only able to generate the public/private key pair on the client and to make the public key available to the authorization server. With Mike's new draft I can now off-load the expensive asymmetric key generation to the server. I also know that this is not a mechanism that every use case would need and hence it good that it is defined as a separate extension, as Mike did. On 08/23/2012 09:15 PM, Mike Jones wrote: > The use cases come from the WebCrypto spec, which requires key import/export, and one of the supported import/export formats is JWK. See http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyImporter-interface, for instance. Search for "export" in the spec for other pertinent sections. > > I'm not saying that the private key format necessarily needs to be part of JWK itself. The right solution might very well be an optional supplemental spec. > > But I do think that it would be a good thing for JOSE to try to be responsive to the W3C's request in this regard. That why I created http://tools.ietf.org/html/draft-jones-jose-json-private-key-00 to facilitate concrete discussion of the possible solution space. > > Best wishes, > -- Mike > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Saturday, August 18, 2012 3:32 AM > To: Mike Jones; 'Harry Halpin' > Cc: jose@ietf.org > Subject: RE: JOSE WG request from W3C WebCrypto API > > Mike, > > You have said that you think that doing this as JOSE structures would be useful. It is not clear to me that there is actually a use case defined here that bears that out. > > Who is responsible for building and encrypting (or decrypting and parsing) the structure? Are we suggesting that the private keys be exported in the clear and it is up to the JOSE developer to encrypt them or are we saying that it is up to the WebCrypto system to do this on behalf of the JOSE developer? > > If we say it is the JOSE developer, then this introduces lots of places where the private keys will be handled insecurely - if nothing else from just hanging around in memory until they get cleaned up. > > If we say that it is the WebCrypto system that does this, then we are saying that we don't really care what the format of the private key blobs is internally, we just need to know how to deal with them from the scripting side - which would be as a blob of some type (either a binary blob or a string blob). > > Finally, how much do we want this to be a portable method of doing key transport? All of the browsers currently have a method of doing an import and export of an ASN.1 private key blob. What is the additional benefit that you think would be obtained from the WebCrypto side from having a second format that all of the browsers would need to support, but which might not have the same level of support from various operating systems and key devices? Would this then lead to scripters needing to have two different sets of import/export code depending on what the internal structure was and potentially needed to switch between the two structures? > > I think it makes sense to allow for the use of JOSE public keys since that is being passed in the message structure itself. I don't believe that it makes a great deal of sense at this point in time to have a private key structure defined. > > Jim > > >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Thursday, August 16, 2012 8:49 AM >> To: Harry Halpin; Jim Schaad; Karen O'Donoghue; >> jose-chairs@tools.ietf.org >> Cc: jose@ietf.org >> Subject: RE: JOSE WG request from W3C WebCrypto API >> >> Thanks for writing, Harry and WebCrypto WG. >> >> 1) About private keys, given the WebCrypto use case, I personally >> think > it >> would be valuable for JOSE to define a JSON private key representation. > To >> make this concrete, I would propose the private key representations >> specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. >> You'll see that doing this is very simple; it just defines two >> additional members for the JWK structure for representing the private >> parts of > Elliptic >> Curve and RSA keys. This could either remain a separate spec from >> JWK/JWA or be merged in, at the working group's preference. >> >> I had previously agreed with the position that it was not necessary >> for > JOSE >> to define private key representations because we didn't have a use >> case > for >> it. However, as I see it, the W3C WebCrypto API use case changes things. >> Better for JOSE to be responsive to WebCrypto and add this simple >> extension, either as a new spec or in the existing specs, than to >> leave > this >> undone, and have it potentially be an area where otherwise standards- >> compliant implementations diverge, and where JSON-only solutions are >> not possible. >> >> Finally, I'll note that the JOSE charter >> http://datatracker.ietf.org/wg/jose/charter/ does not preclude >> defining private key formats. (It simply requires the definition of >> public key > formats >> and is silent on the topic of private keys.) >> >> 2) I agree on the likely need for WebCrypto support ASN.1 for >> backwards compatibility in some cases (just as the JOSE specs allow >> the use of X.509 certificates). However, I believe it would be a >> shame to preclude > JSON-only >> solutions by not supporting key import/export in JWK format, where >> such solutions make sense. >> >> 3) It appears to me the JWK format is stable. I believe the JWS >> format > is >> stable as well. The JWE format has known changes that will be applied >> shortly, based upon working group discussions at IETF 84 in Vancouver >> two weeks ago. Some JWA changes will occur that are part of the JWE changes. > I >> don't anticipate significant changes after that. (Making these >> changes is > my >> highest priority as JOSE editor. I'm hoping to have drafts out >> containing > them >> by the end of August, which hopefully fits well with the WebCrypto >> schedule.) I write all of the above with the caveat that the working > group is, >> of course, free to change things as they see fit. >> >> I look forward to a productive discussion of this coordination request >> in > both >> working groups. >> >> Best wishes, >> -- Mike >> >> P.S. If you prefer, a HTML-formatted version of the private key spec >> is available at >> http://self-issued.info/docs/draft-jones-jose-json-private- >> key.html. I also blogged about this draft specification at >> http://self- issued.info/?p=816. >> >> -----Original Message----- >> From: Harry Halpin [mailto:hhalpin@w3.org] >> Sent: Sunday, August 12, 2012 8:03 AM >> To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike >> Jones >> Subject: JOSE WG request from W3C WebCrypto API >> >> [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] >> >> JOSE Chairs, >> >> The Web Cryptography Working group has noted that the API requires >> some access to raw key material, and the issue of whether or not to >> use JWK or >> ASN.1 as the default format came up. Two issues have come out that >> we'd like to know the answer to: >> >> 1) JWK does not define a private key format. Does the JOSE WG plan to >> support a JOSE-format for private keys? If so, when? Or 'maybe'? >> >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems >> like > for >> backwards compatibility having some level of ASN.1 support would be >> useful and we *need* a format that allows key material (both private >> and >> public) to be exported. Folks seem to leaning towards ASN.1 as a >> default format in the low-level API, and having JWK as a format that >> can be built > on >> top of that in a possible high-level API. Would that be OK? >> >> 3) How stable do you believe the JOSE formats are right now? Do you > think >> they are stable enough now we can reference them in our API draft at >> end > of >> August? If not, when? The W3C would like to and plan to use these >> formats where possible. >> >> Feel free to forward this by JOSE WG for discussion. We'd like an >> answer before we send our document to FPWD at end of August. >> >> cheers, >> harry >> >> > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From bobwyman@gmail.com Thu Aug 23 12:14:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BFE21F8665 for ; Thu, 23 Aug 2012 12:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpD+3ypkc4T6 for ; Thu, 23 Aug 2012 12:14:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0563921F84DD for ; Thu, 23 Aug 2012 12:14:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2943950obb.31 for ; Thu, 23 Aug 2012 12:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fGMthvDq9cE1j6l5NRU3ZFgWJqu5MLEaIYg38tYGxsg=; b=P084JKBtkU+28ofy+jyBc3gT8QE5o1saW6Kn9KKzz8Hh7L5I1fEijolSkBVM+NINXG Xdee5e3mjWaeWBMcLpoJmjvxRESueA49WI2+uB3lFfFlqx8VX48vSp3x7LP/tJGfU4Gz HD6xsUEPSDQ1ltMTMJ+XUsODlpHaY7vUHo4UY7zEvoiuf8+MgdiN20SyooteSQQQUN1m lfRh4SycFvndfTptk+TJPs9XgtX0NJPHwzR4FOykX/AgaCBL13pmKsmLgFHxTa8bvzcu LFe1hO+8RrgIWW/vqarrPO8JATsZ0DzJ1iv+grLQP5+dTU1Bv8Nymd9O6uyjt4qb3dQz t/0A== MIME-Version: 1.0 Received: by 10.50.217.133 with SMTP id oy5mr2721036igc.49.1345749237404; Thu, 23 Aug 2012 12:13:57 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.64.148.76 with HTTP; Thu, 23 Aug 2012 12:13:57 -0700 (PDT) In-Reply-To: <50366784.70803@mitre.org> References: <11d401cd7eac$24b0b116$5e209f0a@nsnintra.net> <50364996.1050502@mitre.org> <50366784.70803@mitre.org> Date: Thu, 23 Aug 2012 15:13:57 -0400 X-Google-Sender-Auth: zIpK25h5ngcrkSVOzjhybOS7K5g Message-ID: From: Bob Wyman To: Justin Richer Content-Type: multipart/alternative; boundary=14dae934043d40949804c7f3a969 Cc: "jose@ietf.org" Subject: Re: [jose] Splitting headers X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:14:05 -0000 --14dae934043d40949804c7f3a969 Content-Type: text/plain; charset=ISO-8859-1 As you point out, today's JWS_header is primarily concerned with the signature rather than the payload. I'm suggesting that typ and cty should be in a payload_header while all the rest of the stuff currently in JWS_header should be in a signature_header. Thus, instead of the three parts: .. we would have four parts: ... This is, I think, a cleaner separation of the various bits of metadata and should lead to a better structured spec as well as better structured code -- and a variety of easily defined extensions. The multiple-signature case is the easiest one to understand. Imagine that I have something like a document approval application that sends around documents that need to be signed by multiple people. Given a three part format, what I need to do is collect all three parts (including the payload) from all signers. If the payload is large, this can be very cumbersome. However, using the four-part format, it becomes trivial. I can send a . pair out to reviewers and ask them to send back their . pairs (or send back all four parts and I'll throw away all but one . pair. Then, once I've collected a few or few hundred signatures, I can then easily and efficiently send out the signed payload with a potentially long list of . pairs. This is easy, simple, etc. Certainly, with the three part format, I can approximate the kind of exchange I describe above by saying to signers that they should send me their . pairs and I'll then re-insert the payload to make sense of the signatures. But, then I have to ensure that I also tell the signers that they must not modify the typ or cty fields in the even though they would rewrite most other fields in that header. Frankly, it would be much easier to simply say: Here is a . pair. Sign it without modifying anything and send me your . pair. bob wyman On Thu, Aug 23, 2012 at 1:25 PM, Justin Richer wrote: > [pulling the jose list back on the thread] > > I agree that too much simplicity can be as much as an impediment as too > much complexity, but I don't think we've hit that here. I could of course > be wrong, but the single-signature use case seems to be pretty > well-established. I'm not arguing that you should never make a breaking > change during the specification process, but that any breaking change, > especially one so deeply fundamental as this, needs to have very strong > support in both group consensus and running code. > > So with that in mind: What's the cause for splitting payload and signature > headers? What kind of information constitutes a "payload header" anyway? > Just about every claim that's defined in the header today is for the > signature or encryption. And you need to protect all of them with the > signature in either case. > > -- Justin > > > On 08/23/2012 01:01 PM, Bob Wyman wrote: > > Simplicity is good, but sometimes too much simplicity can prevent us from > doing things that would be valuable to our eventual users. In this case, I > will admit that I am asking for a bit of additional complexity -- but, it > should be recognized as well that I am also calling for additional > simplicity in the structuring of the data. Rather than mixing things up, I > suggest separating them into logical processing groups. > > I argue that instead of: >
.. > we should have: > ... > where payload header contains only that data which is specific to the > payload and the signature_header contains only data relevant to the > signature. Given that the content of the signature_header is what is > currently already defined as part of the
, then the added message > size is only several bytes. I cannot see that there is much added > complexity in the code, since any code written will typically first concern > itself with the payload related data, wherever it is, and then concern > itself with the signature related stuff. Frankly, it looks to me like while > their might be more code to handle four parts rather than three, the code > itself would be cleaner and better structured since it would inevitably > tend to reflect the better compartmentalization and separation of concerns > in the encoded data. One interesting side-effect of my "simplifying" > proposal is that what falls out of it is a simple way to transmit unsigned > data. (i.e. . without a signature.)... > > Certainly, my suggestion is motivated largely by the multiple-signature > use case (which is required for many applications), but I am also motivated > by a desire to see the data structures be better normalized. And, I would > like to do what can be done now to simplify the process of defining > extensions in the future (from a standards process point of view) as well > as simplicity when people decide to adopt an extension. > > The current definition doesn't seem to me to provide much room for > extensions that would handle the multi-signature case. The only alternative > seems to be not an extension but rather a completely new spec. Clearly, > given the process overhead in IETF, that isn't going to move along slowly. > We would probably spend much more time debating the extension/alternative > as would be consumed in aggregate by all the developers who needed to > handle four parts rather than three... In any case, the harsh reality is > that non-core extensions are rarely implemented if they aren't firmly > rooted in the conventions of the core specification -- no matter what the > standard. > > How about this as a compromise? > *Consider using the four-part format that I suggest, but stay silent on > the subject of multiple signatures or any other extensions.* Then, i'll > write up a draft that covers a variety of extensions that leverage the > four-part format -- including the multi-signature case. If this strategy is > used, the core spec will be better structured and it will remain very > "simple" -- but it will be simple in a way that makes it vastly easier and > cleaner to define extensions with minimal divergence from the simple core. > Developers will be served by this approach since it should make it easier > for them to incorporate support for extensions in the future, if they > choose to. And, users will be served because it makes it easier for us to > define extensions that serve their needs. > > bob wyman > > On Thu, Aug 23, 2012 at 11:17 AM, Justin Richer wrote: > >> I'd like to pose the question of what constitutes "a bit of extra >> overhead". Making the overhead mandatory to support in the core can lead to >> developer friction for the majority cases. >> >> This reminds me of the discussion on the OAuth list about returning >> multiple tokens. Sometimes, yes, you want to return multiple access tokens. >> Usually it's just one. We could have made the return value an array instead >> of a string, but then you'd force every client to pull out >> "access_token[0]" instead of just "access_token", and that's an annoyance >> for the non-rare case. In the end, the group decided on supporting the >> simple case in the core and letting an extension define the multi-token >> format. That extension was never proposed, so I would wager that the >> multi-token case was at least rare enough to not force the standardization >> question. >> >> I think the same approach should be taken here. Keep the existing, >> deployed, simple format of header.payload.signature for the simple >> single-signature case. Use a different serialization format for different >> use case, such as the JWS-JSON format that Mike's proposed or the multi-dot >> format proposed below. I would argue that they're fundamentally different >> kinds of objects and that conflating their use cases by forcing the >> overhead is a big mistake. >> >> -- Justin >> >> >> On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >> Here is my view: the muliple recipient case is a rare case. Having a >> bit of extra overhead for rare cases is IMHO acceptable to keep the core >> spec simpler. >> >> hannes >> >> Sent from my Windows Phone >> ------------------------------ >> From: ext Richard L. Barnes >> Sent: 8/18/2012 12:58 AM >> To: jose@ietf.org >> Subject: [jose] Splitting headers >> >> Hey all, >> >> At IETF 84, I suggested that we take another look at what header >> information gets integrity-protected and what doesn't. The main issue >> being that in multiple-recipient or multiple-signer scenarios, there's >> unnecessary duplication of data if recipient- or signer-specific >> information is in the integrity-protected header. >> >> Following some on what Bob Wyman proposed this afternoon, I would like to >> propose that we split the set of header fields into some logical groupings: >> 1. Top-level fields that require integrity protection (e.g., cty or a >> digest algorithm parameter) >> 2. Top-level fields that do not require integrity protection (e.g., x5c) >> 3. Fields that are specific to a signer (e.g., jwk) >> 4. Fields that are specific to a recipient (e.g., epk) >> >> In this taxonomy, only fields of type (1) need to be base64-encoded for >> to preserve their serialization, and fields of type (3) and (4) could be >> gathered together into the moral equivalent of SignerInfo and RecipientInfo >> objects. All this makes the JSON serialization a lot cleaner, for example: >> >> { >> "type": "S", >> "header": "[base64-type1]", >> "params": { /* type2 */ }, >> "content": "[base64-content]", >> "signers": [ >> { /* type3 */ } >> ] >> } >> >> You can also imagine a reasonable compact serialization, something like: >> >> S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. >> ... >> >> That encoding even has the benefit that the multi-signer case doesn't add >> any overhead over the single-signer case, except for maybe a couple of "." >> characters. (Obviously, you would want some structure on how the signer >> info gets serialized, but that's another level of detail down. You could >> imagine something like "[signer-header].[public-key].[signature-value]".) >> >> The additional structure might seem like it's more work to parse, but I >> don't think it's really that bad. Given a parsed JOSE object "obj": >> 1. Decode obj.header and add its fields to obj.params >> 2. Look through "signers" / "recipients" to find one we understand >> 3. Verify / decrypt content using signer/recipient info and parameters >> >> There are several details to be worked out -- most critically, which >> fields go in which groupings -- but I thought I would throw out the general >> idea for comment before diving into the details. >> >> Cheers, >> --Richard >> >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > > --14dae934043d40949804c7f3a969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As you point out, today's JWS_header is primarily concerned with the si= gnature rather than the payload. I'm suggesting that typ and cty should= be in a payload_header while all the rest of the stuff currently in JWS_he= ader should be in a signature_header. Thus, instead of the three parts: =A0 =A0 <JWS_header>.<payloa= d>.<signature>
we would have four parts:
=A0 =A0 <payload_header>.<= payload>.<signature_header>.<signature>
This is, I think, a cleaner separation of the various bits of metadata= and should lead to a better structured spec as well as better structured c= ode -- and a variety of easily defined extensions.

The multiple-signature case is the easiest one to understand. Imagine = that I have something like a document approval application that sends aroun= d documents that need to be signed by multiple people. Given a three part f= ormat, what I need to do is collect all three parts (including the payload)= from all signers. If the payload is large, this can be very cumbersome. Ho= wever, using the four-part format, it becomes trivial. I can send a <pay= load_header>.<payload> pair out to reviewers and ask them to send = back their <signature_header>.<signature> pairs (or send back a= ll four parts and I'll throw away all but one <payload_header>.&l= t;payload> pair. Then, once I've collected a few or few hundred sign= atures, I can then easily and efficiently send out the signed payload with = a potentially long list of <signature_header>.<signature> pairs= . This is easy, simple, etc.

Certainly, with the three part format, I can approximat= e the kind of exchange I describe above by saying to signers that they shou= ld send me their <JWS_header>.<signature> pairs and I'll th= en re-insert the payload to make sense of the signatures. But, then I have = to ensure that I also tell the signers that they must not modify the typ or= cty fields in the <JWS_header> even though they would rewrite most o= ther fields in that header. Frankly, it would be much easier to simply say:= Here is a <payload_header>.<payload> pair. Sign it without mod= ifying anything and send me your <signature_header>.<signature>= pair.

bob wyman


On Thu, Aug 23, 2012 at 1:25 PM, Justin Richer <jricher= @mitre.org> wrote:
=20 =20 =20
[pulling the jose list back on the thread]

I agree that too much simplicity can be as much as an impediment as too much complexity, but I don't think we've hit that here= . I could of course be wrong, but the single-signature use case seems to be pretty well-established. I'm not arguing that you should never make a breaking change during the specification process, but that any breaking change, especially one so deeply fundamental as this, needs to have very strong support in both group consensus and running code.

So with that in mind: What's the cause for splitting payload and signature headers? What kind of information constitutes a "paylo= ad header" anyway? Just about every claim that's defined in the header today is for the signature or encryption. And you need to protect all of them with the signature in either case.

=A0-- Justin


On 08/23/2012 01:01 PM, Bob Wyman wrote:
=20 Simplicity is good, but sometimes too much simplicity can prevent us from doing things that would be valuable to our eventual users. In this case, I will admit that I am asking for a bit of additional complexity -- but, it should be recognized as well that I am also calling for additional simplicity in the structuring of the data. Rather than mixing things up, I suggest separating them into logical processing groups.

I argue that instead of:
=A0 <header>.<pay= load>.<signature>
we should have:
=A0 <payload_header>= .<payload>.<signature_header>.<signature>
where payload header contains only that data which is specific to the payload and the signature_header contains only data relevant to the signature. Given that the content of the signature_header is what is currently already defined as part of the <header>, then the added message size is only several bytes. I cannot see that there is much added complexity in the code, since any code written will typically first concern itself with the payload related data, wherever it is, and then concern itself with the signature related stuff. Frankly, it looks to me like while their might be more code to handle four parts rather than three, the code itself would be cleaner and better structured since it would inevitably tend to reflect the better compartmentalization and separation of concerns in the encoded data. One interesting side-effect of my "simplifying" pro= posal is that what falls out of it is a simple way to transmit unsigned data. (i.e. <payload_header>.<payload> without a signature.)...

Certainly, my suggestion is motivated largely by the multiple-signature use case (which is required for many applications), but I am also motivated by a desire to see the data structures be better normalized. And, I would like to do what can be done now to simplify the process of defining extensions in the future (from a standards process point of view) as well as simplicity when people decide to adopt an extension.

The current definition doesn't seem to me to provide much room for extensions that would handle the multi-signature case. The only alternative seems to be not an extension but rather a completely new spec. Clearly, given the process overhead in IETF, that isn't going to move along slowly. We would probably spend much more time debating the extension/alternative as would be consumed in aggregate by all the developers who needed to handle four parts rather than three... In any case, the harsh reality is that non-core extensions are rarely implemented if they aren't firmly rooted in the conventions of the core specification -- no matter what the standard.

How about this as a compromise?
Consider using the four-part format that I suggest, but stay silent on the subject of multiple signatures or any other extensions. Then, i'll write up a draft that covers a variety of extensions that leverage the four-part format -- including the multi-signature case. If this strategy is used, the core spec will be better structured and it will remain very "simple" -- but it will be simple in a way that makes it = vastly easier and cleaner to define extensions with minimal divergence from the simple core. Developers will be served by this approach since it should make it easier for them to incorporate support for extensions in the future, if they choose to. And, users will be served because it makes it easier for us to define extensions that serve their needs.

bob wyman

On Thu, Aug 23, 2012 at 11:17 AM, Justin Richer <jricher@mitre.org> wrote:
I'd like to pose the question of what constitutes &q= uot;a bit of extra overhead". Making the overhead mandatory = to support in the core can lead to developer friction for the majority cases.

This reminds me of the discussion on the OAuth list about returning multiple tokens. Sometimes, yes, you want to return multiple access tokens. Usually it's jus= t one. We could have made the return value an array instead of a string, but then you'd force every client to pull out "access_token[0]" instead of just "access_token", and that's an annoyance for t= he non-rare case. In the end, the group decided on supporting the simple case in the core and letting an extension define the multi-token format. That extension was never proposed, so I would wager that the multi-token case was at least rare enough to not force the standardization question.

I think the same approach should be taken here. Keep the existing, deployed, simple format of header.payload.signature for the simple single-signature case. Use a different serialization format for different use case, such as the JWS-JSON format that Mike's proposed or the multi-dot format proposed below. I would argue that they're fundamentally different kinds of objects and that conflating their use cases by forcing the overhead is a big mistake.

=A0-- Justin


On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Here is my view: the muliple recipient case is a rare case. Having a bit of extra overhead for rare cases is IMHO acceptable to keep the core spec simpler.

hannes

Sent from my Windows Phone
From: ext Richard L. Barnes
Sent: 8/18/2012 12:58 AM
To: jose@ietf.o= rg
Subject: [jose] Splitting headers

Hey all,

At IETF 84, I suggested that we take another look at what header information gets integrity-protected and what doesn't.=A0 The main issue being that in multiple-recipient or multiple-signer scenarios, there's unnecessary duplication of data if recipient- or signer-specific information is in the integrity-protected header.

Following some on what Bob Wyman proposed this afternoon, I would like to propose that we split the set of header fields into some logical groupings:
1. Top-level fields that require integrity protection (e.g., cty or a digest algorithm parameter)
2. Top-level fields that do not require integrity protection (e.g., x5c)
3. Fields that are specific to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g., epk)

In this taxonomy, only fields of type (1) need to be base64-encoded for to preserve their serialization, and fields of type (3) and (4) could be gathered together into the moral equivalent of SignerInfo and RecipientInfo objects.=A0 All this makes the JSON serialization a lot cleaner, for example:

{
=A0=A0=A0 "type": "S",
=A0=A0=A0 "header": "[base64-type1]"= ;,
=A0=A0=A0 "params": { /* type2 */ },
=A0=A0=A0 "content": "[base64-content]&q= uot;,
=A0=A0=A0 "signers": [
=A0=A0=A0=A0=A0=A0=A0 { /* type3 */ }
=A0=A0=A0 ]
}

You can also imagine a reasonable compact serialization, something like:

S.[base64-type1].[base64-type2].[base64-content].[base6= 4-signer1].[base64-signer2]. ...

That encoding even has the benefit that the multi-signer case doesn't add any overhead over the single-signer case, except for maybe a couple of "= ." characters. (Obviously, you would want some structure on how the signer info gets serialized, but that's another level of detail down.=A0 You cou= ld imagine something like "[signer-header].[public-key].[signature-value]&qu= ot;.)

The additional structure might seem like it's more work to parse, but I don't think it's really th= at bad.=A0 Given a parsed JOSE object "obj":
1. Decode obj.header and add its fields to obj.params
2. Look through "signers" / "recipients&= quot; to find one we understand
3. Verify / decrypt content using signer/recipient info and parameters

There are several details to be worked out -- most critically, which fields go in which groupings -- but I thought I would throw out the general idea for comment before diving into the details.

Cheers,
--Richard




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


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


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




--14dae934043d40949804c7f3a969-- From dholth@gmail.com Thu Aug 23 13:58:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457E321F8578 for ; Thu, 23 Aug 2012 13:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSMCiiXdMZa0 for ; Thu, 23 Aug 2012 13:58:09 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6327921F8518 for ; Thu, 23 Aug 2012 13:58:09 -0700 (PDT) Received: by bkty7 with SMTP id y7so397288bkt.31 for ; Thu, 23 Aug 2012 13:58:08 -0700 (PDT) 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=BGlaX/ama6RH8sZHm2wRhD0iHv4EcuSIBWdpJEbORLY=; b=i/OBNLKtncLfgEYy3r+z+CyU8/ODeawWAGNcAaDxUpXOxRy2AKmb19kdfZf2FQlF4X UTr+COc+F20+ohJwABTSG0YNB27Ulnmr79F/S+a+dmI9x3wrQp/mPdDB2S4KU7hgSATe ATptSwJ+T3McGc8KUvX/YFu2twLT28uKfMYTfR2UdI7XF80RFzdx2q0txBTpW9zvs3AM Gper45Au8HPWqTrKAMQfq3UnavxGupCD0wU64DIsKmT9oL7l0hMEafKXkrjkCdEGGLpv wHbup7k96JUD2hpVuu3UNbR3i2ubGnHG9AfE1IUnMMUyHwLh38tjOk3iUaAwloWH55GN 9n7A== MIME-Version: 1.0 Received: by 10.204.157.143 with SMTP id b15mr1160757bkx.75.1345755488273; Thu, 23 Aug 2012 13:58:08 -0700 (PDT) Received: by 10.204.200.141 with HTTP; Thu, 23 Aug 2012 13:58:08 -0700 (PDT) Date: Thu, 23 Aug 2012 16:58:08 -0400 Message-ID: From: Daniel Holth To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [jose] JWS-JS on disk X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:58:43 -0000 I'm attempting to design a JWS-JS-inspired format into a code signing mechanism for Python wheel files. It works. The payload just includes a hash of a manifest that in turn includes the hash of all the other files in the archive, and the signatures always include the full verifying key for the Ed25519 system in the header, like so. I like it, but want a place to include information about the signature itself (when was this signature added?) apart from the single payload. I see there is some discussion of split headers that may provide it. That's all. I really like the spec so far. Daniel Holth {'alg': 'Ed25519', 'key': {'alg': 'Ed25519', 'vk': u'dSUK9K1lSClpgCrtjTpywL3o-TfyCHQsD4xC6ey1GH4'}, 'typ': 'JWT'} {'hash': 'sha256=N7if_qZx7EVe4hN72ajBrWZ5Gwqs74nkK1vWLGTQTFY'} {"headers": ["eyJhbGciOiAiRWQyNTUxOSIsICJrZXkiOiB7ImFsZyI6ICJFZDI1NTE5IiwgInZrIjogImRTVUs5SzFsU0NscGdDcnRqVHB5d0wzby1UZnlDSFFzRDR4QzZleTFHSDQifSwgInR5cCI6ICJKV1QifQ"], "payload": "eyJoYXNoIjogInNoYTI1Nj1ON2lmX3FaeDdFVmU0aE43MmFqQnJXWjVHd3FzNzRua0sxdldMR1RRVEZZIn0", "signatures": ["KFt27VW2tM5Q637Mu4kyfqBRrxzJ9MRZ6O7ax8lSnKuVLMGG6bcNKkLqombv12bUV-8I-n-SlQfaGlSqnn_xAw"]} From sakimura@gmail.com Thu Aug 23 19:09:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F064D21F84CD for ; Thu, 23 Aug 2012 19:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve1PwP11J3gh for ; Thu, 23 Aug 2012 19:09:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2127E21F84C9 for ; Thu, 23 Aug 2012 19:09:31 -0700 (PDT) Received: by iabz21 with SMTP id z21so2645803iab.31 for ; Thu, 23 Aug 2012 19:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CP799CtmgH7FlqL7o/JaQQDWi64IT4D1uFwOda1d6Oo=; b=IRn5hIWdHfD0DsNbaObXg2Qpz3uKcs29lIUf5+saNKYbR6wgGnhEik8z4xB50ogQ0j M4xJqEdb/BLaMiVpSUkp2b98zhrOIGmBGQA/zxWpFFPaUB7rOC/w+FSrT/fkdWOUocdp aWsmkpzq+KCq2vYeqFSI9zdmJ9hAcTo6X9CiR4Q0FtO3YIA+w7jg8kAe+om9y0BmPpuV rkZCRlWs159NknP9hQlq8HNE+qf9JBJT0YobxUFAtZLnVusGCdoNDC/9ZAko4jgDPFU+ ckJ+MVIobpqNojOUxSmhMMgMvpevNrrrajg4hMJUQgrO2p7I03RHEOwMLHHERJez85T1 P9Sg== MIME-Version: 1.0 Received: by 10.50.154.130 with SMTP id vo2mr388035igb.71.1345774170549; Thu, 23 Aug 2012 19:09:30 -0700 (PDT) Received: by 10.64.102.39 with HTTP; Thu, 23 Aug 2012 19:09:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 11:09:30 +0900 Message-ID: From: Nat Sakimura To: Daniel Holth Content-Type: multipart/alternative; boundary=14dae93405b1622e7104c7f977a4 Cc: jose@ietf.org Subject: Re: [jose] JWS-JS on disk X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 02:09:32 -0000 --14dae93405b1622e7104c7f977a4 Content-Type: text/plain; charset=ISO-8859-1 There is "iat" (issued at) claim in JWT http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01 I would use it to show when it was signed. Nat On Fri, Aug 24, 2012 at 5:58 AM, Daniel Holth wrote: > I'm attempting to design a JWS-JS-inspired format into a code signing > mechanism for Python wheel files. It works. The payload just includes > a hash of a manifest that in turn includes the hash of all the other > files in the archive, and the signatures always include the full > verifying key for the Ed25519 system in the header, like so. I like > it, but want a place to include information about the signature itself > (when was this signature added?) apart from the single payload. I see > there is some discussion of split headers that may provide it. > > That's all. I really like the spec so far. > > Daniel Holth > > {'alg': 'Ed25519', > 'key': {'alg': 'Ed25519', > 'vk': u'dSUK9K1lSClpgCrtjTpywL3o-TfyCHQsD4xC6ey1GH4'}, > 'typ': 'JWT'} > > {'hash': 'sha256=N7if_qZx7EVe4hN72ajBrWZ5Gwqs74nkK1vWLGTQTFY'} > > {"headers": > ["eyJhbGciOiAiRWQyNTUxOSIsICJrZXkiOiB7ImFsZyI6ICJFZDI1NTE5IiwgInZrIjogImRTVUs5SzFsU0NscGdDcnRqVHB5d0wzby1UZnlDSFFzRDR4QzZleTFHSDQifSwgInR5cCI6ICJKV1QifQ"], > "payload": > "eyJoYXNoIjogInNoYTI1Nj1ON2lmX3FaeDdFVmU0aE43MmFqQnJXWjVHd3FzNzRua0sxdldMR1RRVEZZIn0", > "signatures": > ["KFt27VW2tM5Q637Mu4kyfqBRrxzJ9MRZ6O7ax8lSnKuVLMGG6bcNKkLqombv12bUV-8I-n-SlQfaGlSqnn_xAw"]} > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --14dae93405b1622e7104c7f977a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is "iat" (issued at) claim in JWT=A0http://tools.ietf.org/ht= ml/draft-ietf-oauth-json-web-token-01
I would use it to show when i= t was signed.=A0

Nat

On Fri, Aug 24, 2= 012 at 5:58 AM, Daniel Holth <dholth@gmail.com> wrote:
I'm attempting to design a JWS-JS-inspired format into a code signing mechanism for Python wheel files. It works. The payload just includes
a hash of a manifest that in turn includes the hash of all the other
files in the archive, and the signatures always include the full
verifying key for the Ed25519 system in the header, like so. I like
it, but want a place to include information about the signature itself
(when was this signature added?) apart from the single payload. I see
there is some discussion of split headers that may provide it.

That's all. I really like the spec so far.

Daniel Holth

{'alg': 'Ed25519',
=A0 =A0'key': {'alg': 'Ed25519',
=A0 =A0 =A0 =A0 =A0 =A0 'vk': u'dSUK9K1lSClpgCrtjTpywL3o-TfyCHQ= sD4xC6ey1GH4'},
=A0 =A0'typ': 'JWT'}

=A0{'hash': 'sha256=3DN7if_qZx7EVe4hN72ajBrWZ5Gwqs74nkK1vWLGTQT= FY'}

{"headers": ["eyJhbGciOiAiRWQyNTUxOSIsICJrZXkiOiB7ImFsZyI6IC= JFZDI1NTE5IiwgInZrIjogImRTVUs5SzFsU0NscGdDcnRqVHB5d0wzby1UZnlDSFFzRDR4QzZle= TFHSDQifSwgInR5cCI6ICJKV1QifQ"],
"payload": "eyJoYXNoIjogInNoYTI1Nj1ON2lmX3FaeDdFVmU0aE43MmFq= QnJXWjVHd3FzNzRua0sxdldMR1RRVEZZIn0",
"signatures": ["KFt27VW2tM5Q637Mu4kyfqBRrxzJ9MRZ6O7ax8lSnKuV= LMGG6bcNKkLqombv12bUV-8I-n-SlQfaGlSqnn_xAw"]}
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--14dae93405b1622e7104c7f977a4-- From dholth@gmail.com Thu Aug 23 22:57:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2111E80A3 for ; Thu, 23 Aug 2012 22:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HlMz4sEwWXJ for ; Thu, 23 Aug 2012 22:57:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7131111E8091 for ; Thu, 23 Aug 2012 22:57:43 -0700 (PDT) Received: by bkty12 with SMTP id y12so42846bkt.31 for ; Thu, 23 Aug 2012 22:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/RsGETf4LSrDm7IeySsrRKt4ILxERd1gd3D2RoquvY=; b=H5i/C9ZeR55kr7u+btyIf+UVMXuYb4rTejO9dm4SYBP3t2dJNWUQJK3X+TQKa2VYgE Zw7BAoVqYg5RX11JijZLfjpoE4F3thj5vCqe+//lnvdkSMZRGmZ8dmziEFqtzHX8t5C0 YlikPXBIfFqsSSuJBnknsdgOjW1+2Dylb7zR5mFf9PppiWCmBKevhp0pzE0AHaoIE9dc MRWQ6zSpV7Fbz3zxgvoC+tn2OAo2cTWaWRbmuJq+VxtQ3MgcGTCYBJVkQ26pumxsArQg WSwF8ns3TLg5JMYXzDaWz0M/OWW4gRgwc6ym+s9Ar5e7JDTlQ0kRtZBSvVDRS6zMaU3Q tXQg== MIME-Version: 1.0 Received: by 10.204.154.73 with SMTP id n9mr1437958bkw.113.1345787862424; Thu, 23 Aug 2012 22:57:42 -0700 (PDT) Received: by 10.204.200.141 with HTTP; Thu, 23 Aug 2012 22:57:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 01:57:42 -0400 Message-ID: From: Daniel Holth To: Nat Sakimura Content-Type: text/plain; charset=ISO-8859-1 Cc: jose@ietf.org Subject: Re: [jose] JWS-JS on disk X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 05:57:44 -0000 Yes, but IIUC iat goes in the payload only according to the spec, so the first signer can put it in, but if the second signature comes along the next day there is no place for iat to go, because the second signer only adds a new header. An obvious solution might be to just put another iat in the second header. From ietf@augustcellars.com Fri Aug 24 01:17:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C908821F867D for ; Fri, 24 Aug 2012 01:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao2iERQhhEey for ; Fri, 24 Aug 2012 01:17:48 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55DA021F84E2 for ; Fri, 24 Aug 2012 01:17:48 -0700 (PDT) Received: from Tobias (keygal.lnk.telstra.net [120.151.176.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 02A542C9F8; Fri, 24 Aug 2012 01:17:45 -0700 (PDT) From: "Jim Schaad" To: "'Hannes Tschofenig'" , "'Mike Jones'" References: <5020216E.7050504@w3.org> <5027C586.8080902@w3.org> <4E1F6AAD24975D4BA5B16804296739436677A2D7@TK5EX14MBXC283.redmond.corp.microsoft.com> <023301cd7d2c$c2f71c60$48e55520$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943667A74DC@TK5EX14MBXC284.redmond.corp.microsoft.com> <50367D24.3080307@gmx.net> In-Reply-To: <50367D24.3080307@gmx.net> Date: Fri, 24 Aug 2012 18:16:19 +1000 Message-ID: <04a801cd81d0$c1c3d5b0$454b8110$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLFlfTqqE/AKW0D4NQ2kQBPiDZx7QIHVRRoAeECGDkCzUphSAFTglP8AY8cR1aVK7M5IA== Content-Language: en-us Cc: 'Harry Halpin' , jose@ietf.org Subject: Re: [jose] JOSE WG request from W3C WebCrypto API X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 08:17:49 -0000 Hannes, Is carrying this directly in JSON better than carrying as a binary blob using the current PKCS#8 format? I remain unconvinced that this is a true statement given the number of different ways that it can be messed up. Jim > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, August 24, 2012 4:58 AM > To: Mike Jones > Cc: Jim Schaad; 'Harry Halpin'; jose@ietf.org > Subject: Re: [jose] JOSE WG request from W3C WebCrypto API > > I had noticed the need for a mechanism to carry a privacy key in a JSON- > based format already with the work on the OAuth-HOTK document. > Without it I was only able to generate the public/private key pair on the client > and to make the public key available to the authorization server. With Mike's > new draft I can now off-load the expensive asymmetric key generation to > the server. > > I also know that this is not a mechanism that every use case would need and > hence it good that it is defined as a separate extension, as Mike did. > > On 08/23/2012 09:15 PM, Mike Jones wrote: > > The use cases come from the WebCrypto spec, which requires key > import/export, and one of the supported import/export formats is JWK. See > http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyImporter- > interface, for instance. Search for "export" in the spec for other pertinent > sections. > > > > I'm not saying that the private key format necessarily needs to be part of > JWK itself. The right solution might very well be an optional supplemental > spec. > > > > But I do think that it would be a good thing for JOSE to try to be responsive > to the W3C's request in this regard. That why I created > http://tools.ietf.org/html/draft-jones-jose-json-private-key-00 to facilitate > concrete discussion of the possible solution space. > > > > Best wishes, > > -- Mike > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: Saturday, August 18, 2012 3:32 AM > > To: Mike Jones; 'Harry Halpin' > > Cc: jose@ietf.org > > Subject: RE: JOSE WG request from W3C WebCrypto API > > > > Mike, > > > > You have said that you think that doing this as JOSE structures would be > useful. It is not clear to me that there is actually a use case defined here that > bears that out. > > > > Who is responsible for building and encrypting (or decrypting and parsing) > the structure? Are we suggesting that the private keys be exported in the > clear and it is up to the JOSE developer to encrypt them or are we saying that > it is up to the WebCrypto system to do this on behalf of the JOSE developer? > > > > If we say it is the JOSE developer, then this introduces lots of places where > the private keys will be handled insecurely - if nothing else from just hanging > around in memory until they get cleaned up. > > > > If we say that it is the WebCrypto system that does this, then we are saying > that we don't really care what the format of the private key blobs is > internally, we just need to know how to deal with them from the scripting > side - which would be as a blob of some type (either a binary blob or a string > blob). > > > > Finally, how much do we want this to be a portable method of doing key > transport? All of the browsers currently have a method of doing an import > and export of an ASN.1 private key blob. What is the additional benefit that > you think would be obtained from the WebCrypto side from having a second > format that all of the browsers would need to support, but which might not > have the same level of support from various operating systems and key > devices? Would this then lead to scripters needing to have two different > sets of import/export code depending on what the internal structure was > and potentially needed to switch between the two structures? > > > > I think it makes sense to allow for the use of JOSE public keys since that is > being passed in the message structure itself. I don't believe that it makes a > great deal of sense at this point in time to have a private key structure > defined. > > > > Jim > > > > > >> -----Original Message----- > >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] > >> Sent: Thursday, August 16, 2012 8:49 AM > >> To: Harry Halpin; Jim Schaad; Karen O'Donoghue; > >> jose-chairs@tools.ietf.org > >> Cc: jose@ietf.org > >> Subject: RE: JOSE WG request from W3C WebCrypto API > >> > >> Thanks for writing, Harry and WebCrypto WG. > >> > >> 1) About private keys, given the WebCrypto use case, I personally > >> think > > it > >> would be valuable for JOSE to define a JSON private key representation. > > To > >> make this concrete, I would propose the private key representations > >> specified in http://tools.ietf.org/html/draft-jones-jose-json-private-key. > >> You'll see that doing this is very simple; it just defines two > >> additional members for the JWK structure for representing the private > >> parts of > > Elliptic > >> Curve and RSA keys. This could either remain a separate spec from > >> JWK/JWA or be merged in, at the working group's preference. > >> > >> I had previously agreed with the position that it was not necessary > >> for > > JOSE > >> to define private key representations because we didn't have a use > >> case > > for > >> it. However, as I see it, the W3C WebCrypto API use case changes things. > >> Better for JOSE to be responsive to WebCrypto and add this simple > >> extension, either as a new spec or in the existing specs, than to > >> leave > > this > >> undone, and have it potentially be an area where otherwise standards- > >> compliant implementations diverge, and where JSON-only solutions are > >> not possible. > >> > >> Finally, I'll note that the JOSE charter > >> http://datatracker.ietf.org/wg/jose/charter/ does not preclude > >> defining private key formats. (It simply requires the definition of > >> public key > > formats > >> and is silent on the topic of private keys.) > >> > >> 2) I agree on the likely need for WebCrypto support ASN.1 for > >> backwards compatibility in some cases (just as the JOSE specs allow > >> the use of X.509 certificates). However, I believe it would be a > >> shame to preclude > > JSON-only > >> solutions by not supporting key import/export in JWK format, where > >> such solutions make sense. > >> > >> 3) It appears to me the JWK format is stable. I believe the JWS > >> format > > is > >> stable as well. The JWE format has known changes that will be > >> applied shortly, based upon working group discussions at IETF 84 in > >> Vancouver two weeks ago. Some JWA changes will occur that are part of > the JWE changes. > > I > >> don't anticipate significant changes after that. (Making these > >> changes is > > my > >> highest priority as JOSE editor. I'm hoping to have drafts out > >> containing > > them > >> by the end of August, which hopefully fits well with the WebCrypto > >> schedule.) I write all of the above with the caveat that the working > > group is, > >> of course, free to change things as they see fit. > >> > >> I look forward to a productive discussion of this coordination > >> request in > > both > >> working groups. > >> > >> Best wishes, > >> -- Mike > >> > >> P.S. If you prefer, a HTML-formatted version of the private key spec > >> is available at > >> http://self-issued.info/docs/draft-jones-jose-json-private- > >> key.html. I also blogged about this draft specification at > >> http://self- issued.info/?p=816. > >> > >> -----Original Message----- > >> From: Harry Halpin [mailto:hhalpin@w3.org] > >> Sent: Sunday, August 12, 2012 8:03 AM > >> To: Jim Schaad; Karen O'Donoghue; jose-chairs@tools.ietf.org; Mike > >> Jones > >> Subject: JOSE WG request from W3C WebCrypto API > >> > >> [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs] > >> > >> JOSE Chairs, > >> > >> The Web Cryptography Working group has noted that the API requires > >> some access to raw key material, and the issue of whether or not to > >> use JWK or > >> ASN.1 as the default format came up. Two issues have come out that > >> we'd like to know the answer to: > >> > >> 1) JWK does not define a private key format. Does the JOSE WG plan to > >> support a JOSE-format for private keys? If so, when? Or 'maybe'? > >> > >> 2) While we'd like encourage the use of JOSE over ASN.1, it seems > >> like > > for > >> backwards compatibility having some level of ASN.1 support would be > >> useful and we *need* a format that allows key material (both private > >> and > >> public) to be exported. Folks seem to leaning towards ASN.1 as a > >> default format in the low-level API, and having JWK as a format that > >> can be built > > on > >> top of that in a possible high-level API. Would that be OK? > >> > >> 3) How stable do you believe the JOSE formats are right now? Do > >> you > > think > >> they are stable enough now we can reference them in our API draft at > >> end > > of > >> August? If not, when? The W3C would like to and plan to use these > >> formats where possible. > >> > >> Feel free to forward this by JOSE WG for discussion. We'd like an > >> answer before we send our document to FPWD at end of August. > >> > >> cheers, > >> harry > >> > >> > > > > > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > From dholth@gmail.com Fri Aug 24 06:15:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38D21F86C6 for ; Fri, 24 Aug 2012 06:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcJdj0ThQSdx for ; Fri, 24 Aug 2012 06:15:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3021F86C4 for ; Fri, 24 Aug 2012 06:15:55 -0700 (PDT) Received: by bkty12 with SMTP id y12so184694bkt.31 for ; Fri, 24 Aug 2012 06:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ZBITVkm9jmgbP5Pwk9lD1owdfkY/+DQmmKJouPHIl8=; b=Wrb/jx6cqlxkoDJ6Di/o9pWPrJ+dh+3gOCHqOP+oWHZXa5NpbDdTgBj+WPnsEDvD9u 2rpQ6W2i5w0/HnIs8YQTM4gJ0wf2tmUuqLZJPL2t1143Vcdi2gpfycNPc4Old8hzB+Zk 9s7KA3/nzot34L89e75vSjAC1wYLt8y9JjImZwtjSz56+pLvKDeaWNU0mHKewAbLbhPe UZR1I8PKC6abKqxkM0mX2izmqJNvO5s5GQHtf08Aj8wvBmJDxXCXpUmsSAS6P1IaCa2d 6BE7CpefhheZ+WbX2CJ7saOWA4jOI+yInT3e0FNLkZhjPt3ByFMT9KDoEP7ZMtADPqgq DSOg== MIME-Version: 1.0 Received: by 10.204.130.211 with SMTP id u19mr1891201bks.24.1345814154585; Fri, 24 Aug 2012 06:15:54 -0700 (PDT) Received: by 10.204.200.141 with HTTP; Fri, 24 Aug 2012 06:15:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Aug 2012 09:15:54 -0400 Message-ID: From: Daniel Holth To: Nat Sakimura Content-Type: text/plain; charset=ISO-8859-1 Cc: jose@ietf.org Subject: Re: [jose] JWS-JS on disk X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 13:15:56 -0000 Since my payload is so boring, I may just go with a list of complete JWT's or a file with one-per-line / whitespace separated as a multi-signature format. From Michael.Jones@microsoft.com Fri Aug 24 16:03:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D480A21F859F for ; Fri, 24 Aug 2012 16:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfhl06RvGUMc for ; Fri, 24 Aug 2012 16:03:00 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id DC20921F859A for ; Fri, 24 Aug 2012 16:02:59 -0700 (PDT) Received: from mail253-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 23:02:58 +0000 Received: from mail253-tx2 (localhost [127.0.0.1]) by mail253-tx2-R.bigfish.com (Postfix) with ESMTP id 2A9B110803B4; Fri, 24 Aug 2012 23:02:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I168aJ542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail253-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail253-tx2 (localhost.localdomain [127.0.0.1]) by mail253-tx2 (MessageSwitch) id 1345849376791563_13817; Fri, 24 Aug 2012 23:02:56 +0000 (UTC) Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.244]) by mail253-tx2.bigfish.com (Postfix) with ESMTP id BC711640045; Fri, 24 Aug 2012 23:02:56 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 23:02:56 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Fri, 24 Aug 2012 23:02:55 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2CTJhfhDZ21YmQR8aBkF8crw0gfQ== Date: Fri, 24 Aug 2012 23:02:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.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.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 23:03:01 -0000 I'll note for discussion purposes that a nonce and a timestamp are not the = same thing (although sometimes they are used to achieve similar/related goa= ls). A nonce tends to be an opaque value that must be preserved across the= communication. Whereas a timestamp typically has defined semantics - some= times simply a non-decreasing integer value - and sometimes a representatio= n of time, and then, sometimes with a uniqueness requirement. For discussion purposes, I'll say that the simplest thing for us to do (sho= uld we decide to do anything in this regard) would be to define the nonce a= s an opaque string value that must be preserved. We could also define a timestamp parameter, but as I wrote above, that woul= d likely require us to specify additional semantics - starting with whether= it's a non-decreasing integer or a representation of a time value. This s= eems much harder to define and possibly to use than a nonce. Would it make sense to define a nonce parameter now and hold off on definin= g a timestamp parameter until there's a clear demonstrated use case for whi= ch a nonce is not sufficient? That would be my personal recommendation. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 12:05 AM To: jose@ietf.org Subject: [jose] POLL: Nonce/Timestamp parameter If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Do we need to define a nonce/timestamp parameter in the base specification? Room vote: 6 yes, 0 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:12:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76F921F8432 for ; Mon, 27 Aug 2012 01:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWIWtJJHki9p for ; Mon, 27 Aug 2012 01:12:41 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id E68AD21F8581 for ; Mon, 27 Aug 2012 01:12:37 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:12:35 +0200 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE113415.emea1.cds.t-internal.com (10.125.65.81) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 27 Aug 2012 10:12:35 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113559.emea1.cds.t-internal.com ([2002:7cd:4165::7cd:4165]) with mapi; Mon, 27 Aug 2012 10:12:35 +0200 From: To: , Date: Mon, 27 Aug 2012 10:12:34 +0200 Thread-Topic: [jose] POLL: Support Multiple types for algorithms Thread-Index: Ac16RpZMp/Klr1eRRvihicMdAk2FbwJ5PEIw Message-ID: References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> In-Reply-To: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:12:42 -0000 NO -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:05 AM To: jose@ietf.org Subject: [jose] POLL: Support Multiple types for algorithms If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Should support be mandated to allow an algorithm to be both a string and an= object Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":= "12345"} Room vote: 1 yes, 5 no, 4 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:15:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA95621F8432 for ; Mon, 27 Aug 2012 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WCS8gRO6t4M for ; Mon, 27 Aug 2012 01:15:25 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 2A64321F85A7 for ; Mon, 27 Aug 2012 01:15:24 -0700 (PDT) Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:15:11 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113598.emea1.cds.t-internal.com ([2002:7cd:4175::7cd:4175]) with mapi; Mon, 27 Aug 2012 10:15:11 +0200 From: To: , Date: Mon, 27 Aug 2012 10:15:10 +0200 Thread-Topic: [jose] POLL: Is KID sufficently defined Thread-Index: Ac16R+NkZj6V892HQ2emUuPRcALC+gJ5Cjyg Message-ID: References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> In-Reply-To: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:15:26 -0000 YES -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:05 AM To: jose@ietf.org Subject: [jose] POLL: Is KID sufficently defined If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Is the current text for KID sufficiently defined and understood? Room vote: 2 yes, 0 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:16:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BF921F84F9 for ; Mon, 27 Aug 2012 01:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNSk7jogJP7c for ; Mon, 27 Aug 2012 01:16:25 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 56FBF21F8495 for ; Mon, 27 Aug 2012 01:16:23 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:16:20 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Mon, 27 Aug 2012 10:16:20 +0200 From: To: , Date: Mon, 27 Aug 2012 10:16:19 +0200 Thread-Topic: [jose] POLL: Criticality of understanding header fields Thread-Index: Ac16R5jcjjwXKxuZTwOQJftRC8WQswJ5KBQg Message-ID: References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> In-Reply-To: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:16:26 -0000 YES -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:05 AM To: jose@ietf.org Subject: [jose] POLL: Criticality of understanding header fields If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. What should be the criticality of header fields as defined by the core spec= ification? YES - all headers fields are critical NO - all header fields are non-critical MAYBE - header fields are marked critical or criticality should be defined = by the application DISCUSS - need to talk more Room vote: 2 yes, 0 no, 4 maybe, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:18:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4121F84F9 for ; Mon, 27 Aug 2012 01:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQM9L+Bv0-nm for ; Mon, 27 Aug 2012 01:18:30 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0691621F84F8 for ; Mon, 27 Aug 2012 01:18:29 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:18:29 +0200 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE111527.EMEA1.CDS.T-INTERNAL.COM (10.125.90.86) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 27 Aug 2012 10:18:28 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113559.emea1.cds.t-internal.com ([2002:7cd:4165::7cd:4165]) with mapi; Mon, 27 Aug 2012 10:18:28 +0200 From: To: , Date: Mon, 27 Aug 2012 10:18:26 +0200 Thread-Topic: [jose] POLL: Add other than pre-shared MAC key Thread-Index: Ac16RidVje2mY8QHQcCUMfGKzpxf6gJ5lUvw Message-ID: References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:18:30 -0000 NO -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:07 AM To: jose@ietf.org Subject: [jose] POLL: Add other than pre-shared MAC key If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Should we add the ability to have a randomly generated MAC key protected by= a different key? The other key could be either a pre-shared symmetric key= or a public key. Room vote: 3 yes, 5 no, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:21:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540C121F8600 for ; Mon, 27 Aug 2012 01:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmbJHLP06xiP for ; Mon, 27 Aug 2012 01:21:58 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2621F85A5 for ; Mon, 27 Aug 2012 01:21:57 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:21:56 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Mon, 27 Aug 2012 10:21:56 +0200 From: To: , Date: Mon, 27 Aug 2012 10:21:55 +0200 Thread-Topic: [jose] POLL: Non AEAD algorithms as a single name Thread-Index: Ac16RKHtofAZQFAhQTSskRTxljUg5wJ6GBKg Message-ID: References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> In-Reply-To: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:21:59 -0000 NO -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:08 AM To: jose@ietf.org Subject: [jose] POLL: Non AEAD algorithms as a single name If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Should we change the current treatment of AES-CBC + HMAC to use a single co= ntent encryption name. Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: {"enc":"AES128CBC+HS256+CS256"} Exact name is still to be determined Room vote: 12 yes, 2 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:24:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2941821F8505 for ; Mon, 27 Aug 2012 01:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yto7nySMRPw6 for ; Mon, 27 Aug 2012 01:24:08 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55821F847D for ; Mon, 27 Aug 2012 01:24:08 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:24:03 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Mon, 27 Aug 2012 10:24:02 +0200 From: To: , Date: Mon, 27 Aug 2012 10:24:02 +0200 Thread-Topic: [jose] POLL: Remove no key wrap for key agreement algorithms Thread-Index: Ac16ReK1E33qYPkKRxqdpZpHt1rNEQJ52mgw Message-ID: References: <008b01cd7c46$fda69480$f8f3bd80$@augustcellars.com> In-Reply-To: <008b01cd7c46$fda69480$f8f3bd80$@augustcellars.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] POLL: Remove no key wrap for key agreement algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:24:09 -0000 NO -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:08 AM To: jose@ietf.org Subject: [jose] POLL: Remove no key wrap for key agreement algorithms If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Should we remove the ability to go directly from a Key Agreement algorithm = to the CMK without having a key wrap step? This would remove the ability to go directly and would require an interveni= ng key wrap step. Room vote: 1 yes, 6 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 01:37:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE85821F84BF for ; Mon, 27 Aug 2012 01:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtMUQ+GWOo3g for ; Mon, 27 Aug 2012 01:37:29 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 31AE621F84A7 for ; Mon, 27 Aug 2012 01:37:29 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 10:37:27 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Mon, 27 Aug 2012 10:37:21 +0200 From: To: , Date: Mon, 27 Aug 2012 10:37:21 +0200 Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2ELoc7u5wC+hIARhuRuZsuq8qwFA== Message-ID: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:37:30 -0000 What is the base specification? https://tools.ietf.org/html/draft-ietf-oaut= h-json-web-token-03 ? I think that nonce and timestamp are protocol specific fields and that JOSE= is not about protocols. There are no round-trips in JOSE. The cryptographic algorithms used in JOSE are secure enough without nounce = and timestamp. Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:05 AM To: jose@ietf.org Subject: [jose] POLL: Nonce/Timestamp parameter If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Do we need to define a nonce/timestamp parameter in the base specification? Room vote: 6 yes, 0 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From jricher@mitre.org Mon Aug 27 08:00:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA93021F86DA for ; Mon, 27 Aug 2012 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT9TBnAdbWCz for ; Mon, 27 Aug 2012 08:00:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F521F866B for ; Mon, 27 Aug 2012 08:00:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 098DD21B1853; Mon, 27 Aug 2012 11:00:23 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EB82021B1851; Mon, 27 Aug 2012 11:00:22 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 27 Aug 2012 11:00:22 -0400 Message-ID: <503B8B2D.7070202@mitre.org> Date: Mon, 27 Aug 2012 10:58:53 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:00:24 -0000 How is "issued at" not a timestamp? -- Justin On 08/24/2012 07:02 PM, Mike Jones wrote: > I'll note for discussion purposes that a nonce and a timestamp are not the same thing (although sometimes they are used to achieve similar/related goals). A nonce tends to be an opaque value that must be preserved across the communication. Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement. > > For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved. > > We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value. This seems much harder to define and possibly to use than a nonce. > > Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient? That would be my personal recommendation. > > Best wishes, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Nonce/Timestamp parameter > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > Do we need to define a nonce/timestamp parameter in the base specification? > > > > Room vote: 6 yes, 0 no, 1 discuss > > > _______________________________________________ > 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 From torsten@lodderstedt.net Mon Aug 27 08:43:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C2421F8495 for ; Mon, 27 Aug 2012 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeZ3wHg1tj1G for ; Mon, 27 Aug 2012 08:43:40 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4521F848F for ; Mon, 27 Aug 2012 08:43:39 -0700 (PDT) Received: from [80.187.97.73] (helo=[100.79.254.162]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1T61TU-0000eh-HW; Mon, 27 Aug 2012 17:43:37 +0200 References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----K6ALK8IYRDBA4H4M2PGTSWREA902WH" From: Torsten Lodderstedt Date: Mon, 27 Aug 2012 17:43:17 +0200 To: Axel.Nennker@telekom.de,ietf@augustcellars.com,jose@ietf.org Message-ID: <59966db6-b436-4e5d-98fd-63f135b971ce@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:43:41 -0000 ------K6ALK8IYRDBA4H4M2PGTSWREA902WH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit No -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Axel.Nennker@telekom.de schrieb: NO -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, August 17, 2012 9:05 AM To: jose@ietf.org Subject: [jose] POLL: Support Multiple types for algorithms If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should support be mandated to allow an algorithm to be both a string and an object Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"} Room vote: 1 yes, 5 no, 4 discuss _____________________________________________ 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 ------K6ALK8IYRDBA4H4M2PGTSWREA902WH Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit No
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.



Axel.Nennker@telekom.de schrieb:
NO

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 9:05 AM
To: jose@ietf.org
Subject: [jose] POLL: Support Multiple types for algorithms

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to provide comments please change the title from POLL to DISCUSS.

Should support be mandated to allow an algorithm to be both a string and an object

Example:  "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"}


Room vote:  1 yes, 5 no, 4 discuss



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
------K6ALK8IYRDBA4H4M2PGTSWREA902WH-- From Michael.Jones@microsoft.com Mon Aug 27 11:11:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C14B21F8532 for ; Mon, 27 Aug 2012 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.842 X-Spam-Level: X-Spam-Status: No, score=-3.842 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUiGeHJkIbZL for ; Mon, 27 Aug 2012 11:11:57 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3F26A21F8551 for ; Mon, 27 Aug 2012 11:11:57 -0700 (PDT) Received: from mail26-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 18:11:55 +0000 Received: from mail26-am1 (localhost [127.0.0.1]) by mail26-am1-R.bigfish.com (Postfix) with ESMTP id 8930E2C0186; Mon, 27 Aug 2012 18:11:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zzbb2dI98dI9371I168aJ542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h) Received-SPF: pass (mail26-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail26-am1 (localhost.localdomain [127.0.0.1]) by mail26-am1 (MessageSwitch) id 1346091113254449_23460; Mon, 27 Aug 2012 18:11:53 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.227]) by mail26-am1.bigfish.com (Postfix) with ESMTP id 325161C004E; Mon, 27 Aug 2012 18:11:53 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 18:11:52 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Mon, 27 Aug 2012 18:11:51 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2CTJhfhDZ21YmQR8aBkF8crw0gfQCF+DqAAAavCgA= Date: Mon, 27 Aug 2012 18:11:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AB0E9@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503B8B2D.7070202@mitre.org> In-Reply-To: <503B8B2D.7070202@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:11:58 -0000 It is. For those of you wondering what the reference to "issued at" is, se= e http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1= .3. -- Mike -----Original Message----- From: Justin Richer [mailto:jricher@mitre.org]=20 Sent: Monday, August 27, 2012 7:59 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter How is "issued at" not a timestamp? -- Justin On 08/24/2012 07:02 PM, Mike Jones wrote: > I'll note for discussion purposes that a nonce and a timestamp are not th= e same thing (although sometimes they are used to achieve similar/related g= oals). A nonce tends to be an opaque value that must be preserved across t= he communication. Whereas a timestamp typically has defined semantics - so= metimes simply a non-decreasing integer value - and sometimes a representat= ion of time, and then, sometimes with a uniqueness requirement. > > For discussion purposes, I'll say that the simplest thing for us to do (s= hould we decide to do anything in this regard) would be to define the nonce= as an opaque string value that must be preserved. > > We could also define a timestamp parameter, but as I wrote above, that wo= uld likely require us to specify additional semantics - starting with wheth= er it's a non-decreasing integer or a representation of a time value. This= seems much harder to define and possibly to use than a nonce. > > Would it make sense to define a nonce parameter now and hold off on defin= ing a timestamp parameter until there's a clear demonstrated use case for w= hich a nonce is not sufficient? That would be my personal recommendation. > > Best wishes, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of J= im Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Nonce/Timestamp parameter > > > > If you voted at the face-2-face please do not vote again. If you want to= provide comments please change the title from POLL to DISCUSS. > > Do we need to define a nonce/timestamp parameter in the base specificatio= n? > > > > Room vote: 6 yes, 0 no, 1 discuss > > > _______________________________________________ > 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 From Axel.Nennker@telekom.de Mon Aug 27 12:06:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9B21F852B for ; Mon, 27 Aug 2012 12:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWWrdLI3znyt for ; Mon, 27 Aug 2012 12:06:08 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE121F851E for ; Mon, 27 Aug 2012 12:06:08 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 21:06:05 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Mon, 27 Aug 2012 21:06:04 +0200 From: To: , Date: Mon, 27 Aug 2012 21:06:03 +0200 Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2ELoc7u5wC+hIARhuRuZsuq8qwFAAVxixQ Message-ID: References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:06:09 -0000 I vote: NO I think that nonce does make sense in signing or encryption because it only= makes sense in a protocol exchange.=20 Maybe there is some justification for nonce in jwt but if jwt is used with = oauth2 then we already have state. Could one of the six who voted yes please explain why nonce is useful? Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nen= nker, Axel Sent: Monday, August 27, 2012 10:37 AM To: ietf@augustcellars.com; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter What is the base specification? https://tools.ietf.org/html/draft-ietf-oaut= h-json-web-token-03 ? I think that nonce and timestamp are protocol specific fields and that JOSE= is not about protocols. There are no round-trips in JOSE. The cryptographic algorithms used in JOSE are secure enough without nounce = and timestamp. Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, August 17, 2012 9:05 AM To: jose@ietf.org Subject: [jose] POLL: Nonce/Timestamp parameter If you voted at the face-2-face please do not vote again. If you want to p= rovide comments please change the title from POLL to DISCUSS. Do we need to define a nonce/timestamp parameter in the base specification? Room vote: 6 yes, 0 no, 1 discuss _______________________________________________ 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 From dick.hardt@gmail.com Mon Aug 27 12:11:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6890B21F852B for ; Mon, 27 Aug 2012 12:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmz+PECo19sn for ; Mon, 27 Aug 2012 12:11:41 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E59B121F8512 for ; Mon, 27 Aug 2012 12:11:40 -0700 (PDT) Received: by dadf8 with SMTP id f8so2684439dad.31 for ; Mon, 27 Aug 2012 12:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sBOJ/zuhIfTxurMdzordjX7A9XiCL9JGufijfBTVu0k=; b=HPKwIIEb250UR0HdFeqkgvivzmU4zH8xuEWf0w11cl15OsSsAKL1qKJFp7gdgFrt1g ArQpzXXvyfHj8s1TEiZpZqSmgJ+91+5LSECtrbZdgDAYkiVdMxRNtArikgVKtJ1AYUpS Alo5s73TL/wdgl3boSV4i/She6o3/ksPcd2ps8Bvycg080bvKxuYDl6NntfceqkZYKhT p60lxL3kxmYIeNMx1DhBZzYLEmaN6WCe6goapwuKjQo/Jdz2qxW+9vDfSYs+YYGo1N1s lsqfXpJBwgQxn2t6rdaZLy8JfT7i0aWpBnJp56OtczeG6HZU3U6dUshjhaFaoz8sHu3d pjAg== Received: by 10.68.227.165 with SMTP id sb5mr36474794pbc.82.1346094700615; Mon, 27 Aug 2012 12:11:40 -0700 (PDT) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id oj8sm15246521pbb.54.2012.08.27.12.11.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 12:11:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Dick Hardt In-Reply-To: Date: Mon, 27 Aug 2012 12:11:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> References: To: Axel.Nennker@telekom.de X-Mailer: Apple Mail (2.1486) Cc: ietf@augustcellars.com, jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:11:41 -0000 I have an application for JWT that is not OAuth2.=20 Having said that, nonce's are difficult to implement at scale and I have = heard of many sites that don't implement them fully. On Aug 27, 2012, at 12:06 PM, Axel.Nennker@telekom.de wrote: > I vote: NO >=20 > I think that nonce does make sense in signing or encryption because it = only makes sense in a protocol exchange.=20 > Maybe there is some justification for nonce in jwt but if jwt is used = with oauth2 then we already have state. >=20 > Could one of the six who voted yes please explain why nonce is useful? >=20 > Axel >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Nennker, Axel > Sent: Monday, August 27, 2012 10:37 AM > To: ietf@augustcellars.com; jose@ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter >=20 > What is the base specification? = https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ? > I think that nonce and timestamp are protocol specific fields and that = JOSE is not about protocols. There are no round-trips in JOSE. > The cryptographic algorithms used in JOSE are secure enough without = nounce and timestamp. >=20 > Axel >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Jim Schaad > Sent: Friday, August 17, 2012 9:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Nonce/Timestamp parameter >=20 > >=20 > If you voted at the face-2-face please do not vote again. If you want = to provide comments please change the title from POLL to DISCUSS. >=20 > Do we need to define a nonce/timestamp parameter in the base = specification? >=20 >=20 >=20 > Room vote: 6 yes, 0 no, 1 discuss >=20 >=20 > _______________________________________________ > 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 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From beaton@google.com Mon Aug 27 13:06:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7FD21F8539 for ; Mon, 27 Aug 2012 13:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IxIueu2Yzq2 for ; Mon, 27 Aug 2012 13:06:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0C021F852E for ; Mon, 27 Aug 2012 13:06:21 -0700 (PDT) Received: by lahm15 with SMTP id m15so2963023lah.31 for ; Mon, 27 Aug 2012 13:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=giIh/NlfPcJXxkhCwVDkI8qNeisJjFHUVdvoT2KvSBQ=; b=ZCKhdG3RNDkkTtPGRiMGNh6F9SYR0oWfCYw4B2v8sfv481VSwvY7xa2MXo/b3cPtFq aKgdRnbktGNdVMHZN8E8Or9oB6phE1JKiwM3PfvjsLOJGdlLXSHikPChwT0CJPHdmWre CksY2kOrOVcvLJgzYP8KmDChiPRU0R+2AZJHOTTdVujSikn0QBhcLhVbiVrV5NcRTJ8S 3imtnk4QlFnJgOf8rYVdIPKOaCT9ECckSgz2js+EZ4sRwyKdGQl7pyUUIny3yphdk9tN PeqrEZ6iPT6iDYccWRK6tsgg4fKnkdp0h9O1+svU5FvzpXjTQiPVLvHeSrw6F8Pjrg0F CpjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=giIh/NlfPcJXxkhCwVDkI8qNeisJjFHUVdvoT2KvSBQ=; b=ZObHPVzND8Q02MNm2Z7ul/1rEl8at4Tsqcu/bnAULoHMJilgi3+bQPGh1vgpc+DgPT dAJat/XzWjKpGXFD9NHpMEZF0vu4hC7+uNuaM8o1tzgCTlAHEjseX3MZ/dgit/lCuvjr GMOA6uu39bc50WsVTtpXeCLACC/jdGb/dCXsrZNqfSV5kN93G4BZEMC71Jv1FgRKzJ1x TXY8ZxCXo7bttcaAWpsW8t9V9C7hE7vmlUZeTp+LzXiyurrLuaSJEBp6PvqutPODckMF D9UBtx1v+3F26+vlOOgKoWXBLviZwrMvHVLLO3tm+ASs6T9cJ8IN+fN1cOkIJDQI2/mD TuaA== Received: by 10.152.144.168 with SMTP id sn8mr16108186lab.1.1346097980215; Mon, 27 Aug 2012 13:06:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.144.168 with SMTP id sn8mr16108166lab.1.1346097980001; Mon, 27 Aug 2012 13:06:20 -0700 (PDT) Received: by 10.112.60.41 with HTTP; Mon, 27 Aug 2012 13:06:19 -0700 (PDT) In-Reply-To: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> Date: Mon, 27 Aug 2012 13:06:19 -0700 Message-ID: From: Brian Eaton To: Dick Hardt Content-Type: multipart/alternative; boundary=e89a8f234687ee4e0a04c844db80 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmrdduEzLltv3PwUOikXPHAgsrVccwdRnq+7ez/yKkPlra1/LVLxrax8+8ZjUu1sGC2L+81XKO3kXEzPFsf1pnE+DKF5a2u5WIpfAsgWG+McoqqItNSqNAvRz8alvZLc1TFEP1jcwW3KZ7w5ow851/dvk1SReDw8+tF0e2WDObpUi7r1OhxjVXeOKXjyaazblyxWUAY Cc: ietf@augustcellars.com, jose@ietf.org, Axel.Nennker@telekom.de Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:06:23 -0000 --e89a8f234687ee4e0a04c844db80 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt wrote: > I have an application for JWT that is not OAuth2. > Should nonce and timestamp logic go in the application level protocol? > Having said that, nonce's are difficult to implement at scale and I have > heard of many sites that don't implement them fully. > Nonce alone can't be implemented efficiently. You have to have time stamps as well, otherwise you are stuck storing ever nonce you've ever seen, forever. Even nonce + time stamp is challenging in distributed systems. It adds a lot of complexity. That complexity is sometimes merited, but not always. --e89a8f234687ee4e0a04c844db80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:
I have an application for JWT that is not OAuth2.

=
Should nonce and timestamp logic go in the application level pro= tocol?
=A0
Having said that, nonce's are difficult to implement at scale and I hav= e heard of many sites that don't implement them fully.
=

Nonce alone can't be implemented efficiently. =A0Yo= u have to have time stamps as well, otherwise you are stuck storing ever no= nce you've ever seen, forever.

Even nonce + time stamp is challenging in distributed s= ystems. =A0It adds a lot of complexity. =A0That complexity is sometimes mer= ited, but not always.
--e89a8f234687ee4e0a04c844db80-- From dick.hardt@gmail.com Mon Aug 27 13:23:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9066121F8453 for ; Mon, 27 Aug 2012 13:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tXkpTrvsyJR for ; Mon, 27 Aug 2012 13:23:18 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 126BE21F844F for ; Mon, 27 Aug 2012 13:23:18 -0700 (PDT) Received: by dadf8 with SMTP id f8so2720017dad.31 for ; Mon, 27 Aug 2012 13:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=5njOFVyAsIte1NfT7Hix0uZS6lqseuzS0wENVDNALD4=; b=ouDBcILk/69tuJJZkDdpnwmXrGAezs6pTjmxQROFhV2eUfNcBikkh96QfIR2OdcDkF D/LqxPvGowXY3HrwPwuC4NCsT11uD5ye6wKiHhOfdPqCChaEicCJEitLImZRacsiHrLA JWPTx/F1Mx7vC0B02a1qi0v/wAEA4z0X2jcR5p2iW4ZufC4D7UReBLKmt7s9WJsg5gpQ ASFmREcthJHSJy7cUob7MQvCajTCEGR1GrFYxiTjVLZWLIrY4Ru3N/ojRg88Ur9+apvK B2F2SsXcMdfD50XZpA12/5nZXPJUduEZLKLe7KbHlXKAGCDenc6EgfYY01vx5rAckViv S49Q== Received: by 10.68.241.72 with SMTP id wg8mr22557171pbc.96.1346098997827; Mon, 27 Aug 2012 13:23:17 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id qp6sm15353910pbc.55.2012.08.27.13.23.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 13:23:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_190205E2-862D-4B3D-844E-5D5CE2DFCF4B" From: Dick Hardt In-Reply-To: Date: Mon, 27 Aug 2012 13:23:01 -0700 Message-Id: <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> To: Brian Eaton X-Mailer: Apple Mail (2.1278) Cc: Jim Schaad , jose@ietf.org, Axel Nennker Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:23:18 -0000 --Apple-Mail=_190205E2-862D-4B3D-844E-5D5CE2DFCF4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt = wrote: > I have an application for JWT that is not OAuth2. >=20 > Should nonce and timestamp logic go in the application level protocol? I prefer to NOT have the application level deal with token validity. > =20 > Having said that, nonce's are difficult to implement at scale and I = have heard of many sites that don't implement them fully. >=20 > Nonce alone can't be implemented efficiently. You have to have time = stamps as well, otherwise you are stuck storing ever nonce you've ever = seen, forever. >=20 > Even nonce + time stamp is challenging in distributed systems. It = adds a lot of complexity. That complexity is sometimes merited, but not = always. Thanks for confirming my statement. I have stopped using nonce and only use time stamps lately and have made = the system relatively stateless so that a second submission of the token = is ok. That may not work for everyone, but I have found that = architecture to be easier to implement and scale. --Apple-Mail=_190205E2-862D-4B3D-844E-5D5CE2DFCF4B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote:

On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I have an application for JWT that is not OAuth2.

Should nonce and timestamp logic go in the application level protocol?

I prefer to NOT have the application level deal with token validity.

 
Having said that, nonce's are difficult to implement at scale and I have heard of many sites that don't implement them fully.

Nonce alone can't be implemented efficiently.  You have to have time stamps as well, otherwise you are stuck storing ever nonce you've ever seen, forever.

Even nonce + time stamp is challenging in distributed systems.  It adds a lot of complexity.  That complexity is sometimes merited, but not always.

Thanks for confirming my statement.

I have stopped using nonce and only use time stamps lately and have made the system relatively stateless so that a second submission of the token is ok. That may not work for everyone, but I have found that architecture to be easier to implement and scale.

--Apple-Mail=_190205E2-862D-4B3D-844E-5D5CE2DFCF4B-- From tonynad@microsoft.com Mon Aug 27 14:03:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC021F84DF for ; Mon, 27 Aug 2012 14:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxKzZhEo0w4q for ; Mon, 27 Aug 2012 14:03:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3121F846B for ; Mon, 27 Aug 2012 14:03:35 -0700 (PDT) Received: from mail70-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 21:03:34 +0000 Received: from mail70-am1 (localhost [127.0.0.1]) by mail70-am1-R.bigfish.com (Postfix) with ESMTP id 3864F3E00B7 for ; Mon, 27 Aug 2012 21:03:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz98dI9371Ic85fhzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah1155h) Received-SPF: pass (mail70-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail70-am1 (localhost.localdomain [127.0.0.1]) by mail70-am1 (MessageSwitch) id 1346101412666722_9228; Mon, 27 Aug 2012 21:03:32 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.240]) by mail70-am1.bigfish.com (Postfix) with ESMTP id 976B52C0062 for ; Mon, 27 Aug 2012 21:03:32 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 21:03:32 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 27 Aug 2012 21:03:16 +0000 Received: from mail96-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 21:03:00 +0000 Received: from mail96-am1 (localhost [127.0.0.1]) by mail96-am1-R.bigfish.com (Postfix) with ESMTP id 859424200E7 for ; Mon, 27 Aug 2012 21:03:00 +0000 (UTC) Received: from mail96-am1 (localhost.localdomain [127.0.0.1]) by mail96-am1 (MessageSwitch) id 1346101379200058_21316; Mon, 27 Aug 2012 21:02:59 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.234]) by mail96-am1.bigfish.com (Postfix) with ESMTP id 253FD180047; Mon, 27 Aug 2012 21:02:59 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 21:02:58 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.235]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0190.008; Mon, 27 Aug 2012 21:02:57 +0000 From: Anthony Nadalin To: Brian Eaton , Dick Hardt Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2ELoc7hDZ21YmQR8aBkF8crw0gfQAWHlqAAAAxeYAAAelbgAAB4z/A Date: Mon, 27 Aug 2012 21:02:57 +0000 Message-ID: References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75EA38E51BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TELEKOM.DE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "ietf@augustcellars.com" , "Axel.Nennker@telekom.de" , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:03:37 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75EA38E51BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Depends on what the nonce is used for as if this is for key entropy then I = would say there is very little overhead and storage issues and in this case= I would expect the header to contain the nonce, if it's for state of some = sort then I would expect it at the application level and not as a header a= nd more of a JWT claim. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bri= an Eaton Sent: Monday, August 27, 2012 1:06 PM To: Dick Hardt Cc: ietf@augustcellars.com; jose@ietf.org; Axel.Nennker@telekom.de Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt > wrote: I have an application for JWT that is not OAuth2. Should nonce and timestamp logic go in the application level protocol? Having said that, nonce's are difficult to implement at scale and I have he= ard of many sites that don't implement them fully. Nonce alone can't be implemented efficiently. You have to have time stamps= as well, otherwise you are stuck storing ever nonce you've ever seen, fore= ver. Even nonce + time stamp is challenging in distributed systems. It adds a l= ot of complexity. That complexity is sometimes merited, but not always. --_000_B26C1EF377CB694EAB6BDDC8E624B6E75EA38E51BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Depends on what the nonce= is used for as if this is for key entropy then I would say there is very l= ittle overhead and storage issues and in this case I would expect the header to contain the nonce, if it’s for state of some so= rt then I would expect it at the application level and  not as a heade= r and more of a JWT claim.

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Brian Eaton
Sent: Monday, August 27, 2012 1:06 PM
To: Dick Hardt
Cc: ietf@augustcellars.com; jose@ietf.org; Axel.Nennker@telekom.de Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

I have an application for JWT that is not OAuth2.

 

Should nonce and timestamp logic go in the applicati= on level protocol?

 

Having said that, nonce's are difficult to implement= at scale and I have heard of many sites that don't implement them fully.

 

Nonce alone can't be implemented efficiently.  = You have to have time stamps as well, otherwise you are stuck storing ever = nonce you've ever seen, forever.

 

Even nonce + time stamp is challenging in distri= buted systems.  It adds a lot of complexity.  That complexity is = sometimes merited, but not always.

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75EA38E51BL2PRD0310MB362_-- From Axel.Nennker@telekom.de Mon Aug 27 14:13:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3C21F8518 for ; Mon, 27 Aug 2012 14:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAaAmfJmWuom for ; Mon, 27 Aug 2012 14:13:18 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3B21F8501 for ; Mon, 27 Aug 2012 14:13:17 -0700 (PDT) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 23:13:15 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Mon, 27 Aug 2012 23:13:15 +0200 From: To: , Date: Mon, 27 Aug 2012 23:13:09 +0200 Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2Ekc1v3q3i0xfJQVyqbmnlKPELkQABuOGg Message-ID: References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> In-Reply-To: <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C107HE111541eme_" MIME-Version: 1.0 Cc: ietf@augustcellars.com, jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:13:18 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C107HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have exp https://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -03#section-4.1.1 and iat https://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -03#section-4.1.3 in JWT. Why do we need a timestamp? Replay attacks of the same jwt can be mitigated through the jti claim https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.= 7 What do timestamp and nonce add to these? Axel From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, August 27, 2012 10:23 PM To: Brian Eaton Cc: Nennker, Axel; Jim Schaad; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt > wrote: I have an application for JWT that is not OAuth2. Should nonce and timestamp logic go in the application level protocol? I prefer to NOT have the application level deal with token validity. Having said that, nonce's are difficult to implement at scale and I have he= ard of many sites that don't implement them fully. Nonce alone can't be implemented efficiently. You have to have time stamps= as well, otherwise you are stuck storing ever nonce you've ever seen, fore= ver. Even nonce + time stamp is challenging in distributed systems. It adds a l= ot of complexity. That complexity is sometimes merited, but not always. Thanks for confirming my statement. I have stopped using nonce and only use time stamps lately and have made th= e system relatively stateless so that a second submission of the token is o= k. That may not work for everyone, but I have found that architecture to be= easier to implement and scale. --_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C107HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have exp

   =              ht= tps://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.1<= o:p>

and iat

           =      https://tools.ietf.org/html/draft-ietf-oauth-json-= web-token-03#section-4.1.3

in JWT. Wh= y do we need a timestamp?

 =

Replay attacks of the same jwt can be mit= igated through the jti claim

https://= tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.7

 

What do timestamp and nonce add to these?

 

Axel

 

 

 

From: Dick Hardt [mailto:dick.hardt@g= mail.com]
Sent: Monday, August 27, 2012 10:23 PM
To: B= rian Eaton
Cc: Nennker, Axel; Jim Schaad; jose@ietf.org
Sub= ject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

 

On Aug 27, 2012, at 1= :06 PM, Brian Eaton wrote:


On Mon, Aug 27, 2012 at 12:11 PM, Dick= Hardt <dick.h= ardt@gmail.com> wrote:

I have an application for JW= T that is not OAuth2.

=  

Should nonce and times= tamp logic go in the application level protocol?

=

 

I prefer to NOT have the application level deal with token validity.



 

Having said that, nonce's are di= fficult to implement at scale and I have heard of many sites that don't imp= lement them fully.

 

Nonce alone can't be impl= emented efficiently.  You have to have time stamps as well, otherwise = you are stuck storing ever nonce you've ever seen, forever.

<= /div>

 

Even nonce + time stamp is challenging in distributed systems. &nb= sp;It adds a lot of complexity.  That complexity is sometimes merited,= but not always.

 =

Thanks for confirming my statemen= t.

 

I have stopped using nonce and only use time sta= mps lately and have made the system relatively stateless so that a second s= ubmission of the token is ok. That may not work for everyone, but I have fo= und that architecture to be easier to implement and scale.

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C107HE111541eme_-- From Michael.Jones@microsoft.com Mon Aug 27 14:36:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D37F21E803F for ; Mon, 27 Aug 2012 14:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.84 X-Spam-Level: X-Spam-Status: No, score=-3.84 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNqzGkDT05Ws for ; Mon, 27 Aug 2012 14:36:18 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id B527F21E803C for ; Mon, 27 Aug 2012 14:36:17 -0700 (PDT) Received: from mail33-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 21:36:16 +0000 Received: from mail33-am1 (localhost [127.0.0.1]) by mail33-am1-R.bigfish.com (Postfix) with ESMTP id 4E5E93400CB; Mon, 27 Aug 2012 21:36:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zz98dI9371Ic85fh168aJ148cIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail33-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail33-am1 (localhost.localdomain [127.0.0.1]) by mail33-am1 (MessageSwitch) id 1346103374234436_29895; Mon, 27 Aug 2012 21:36:14 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.252]) by mail33-am1.bigfish.com (Postfix) with ESMTP id 36F0912004E; Mon, 27 Aug 2012 21:36:14 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 21:36:12 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Mon, 27 Aug 2012 21:36:03 +0000 From: Mike Jones To: "Axel.Nennker@telekom.de" , "dick.hardt@gmail.com" , "beaton@google.com" Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2ELoc7hDZ21YmQR8aBkF8crw0gfQAWHlqAAAAxeYAAAelbgAAAlU+AAAHAOoAAALydIA== Date: Mon, 27 Aug 2012 21:36:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667ABCF4@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667ABCF4TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ietf@augustcellars.com" , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:36:20 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667ABCF4TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to complete the picture, I'll also add that OpenID Connect defines a n= once claim (at the JWT claim level, rather than the JOSE header parameter l= evel). -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Monday, August 27, 2012 2:13 PM To: dick.hardt@gmail.com; beaton@google.com Cc: ietf@augustcellars.com; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter We have exp https://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -03#section-4.1.1 and iat https://tools.ietf.org/html/draft-ietf-oauth-json-web-token= -03#section-4.1.3 in JWT. Why do we need a timestamp? Replay attacks of the same jwt can be mitigated through the jti claim https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.= 7 What do timestamp and nonce add to these? Axel From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, August 27, 2012 10:23 PM To: Brian Eaton Cc: Nennker, Axel; Jim Schaad; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt > wrote: I have an application for JWT that is not OAuth2. Should nonce and timestamp logic go in the application level protocol? I prefer to NOT have the application level deal with token validity. Having said that, nonce's are difficult to implement at scale and I have he= ard of many sites that don't implement them fully. Nonce alone can't be implemented efficiently. You have to have time stamps= as well, otherwise you are stuck storing ever nonce you've ever seen, fore= ver. Even nonce + time stamp is challenging in distributed systems. It adds a l= ot of complexity. That complexity is sometimes merited, but not always. Thanks for confirming my statement. I have stopped using nonce and only use time stamps lately and have made th= e system relatively stateless so that a second submission of the token is o= k. That may not work for everyone, but I have found that architecture to be= easier to implement and scale. --_000_4E1F6AAD24975D4BA5B1680429673943667ABCF4TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just to complete the pict= ure, I’ll also add that OpenID Connect defines a nonce claim (at the = JWT claim level, rather than the JOSE header parameter level).

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de
Sent: Monday, August 27, 2012 2:13 PM
To: dick.hardt@gmail.com; beaton@google.com
Cc: ietf@augustcellars.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

We have exp

        &= nbsp;       https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.= 1

and iat

        &= nbsp;       https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.= 3

in JWT. Why do we need a timestamp?

 

Replay attacks of the same jwt can be mitigated t= hrough the jti claim

https://tools.ietf.org/html/draft-i= etf-oauth-json-web-token-03#section-4.1.7

 

What do timestamp and nonce add to these?

 

Axel

 

 <= /p>

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.c= om]
Sent: Monday, August 27, 2012 10:23 PM
To: Brian Eaton
Cc: Nennker, Axel; Jim Schaad; jose= @ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

 

On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote:=

 

On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

I have an application for JWT that is not OAuth2.

 

Should nonce and timestamp logic go in the applicati= on level protocol?

 

I prefer to NOT have the application level deal with= token validity.

 

 

Having said that, nonce's are difficult to implement= at scale and I have heard of many sites that don't implement them fully.

 

Nonce alone can't be implemented efficiently.  = You have to have time stamps as well, otherwise you are stuck storing ever = nonce you've ever seen, forever.

 

Even nonce + time stamp is challenging in distri= buted systems.  It adds a lot of complexity.  That complexity is = sometimes merited, but not always.

 

Thanks for confirming my statement.

 

I have stopped using nonce and only use time stamps = lately and have made the system relatively stateless so that a second submi= ssion of the token is ok. That may not work for everyone, but I have found = that architecture to be easier to implement and scale.

 

--_000_4E1F6AAD24975D4BA5B1680429673943667ABCF4TK5EX14MBXC284r_-- From dick.hardt@gmail.com Mon Aug 27 14:55:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7021E803A for ; Mon, 27 Aug 2012 14:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQmyTFOzsHuA for ; Mon, 27 Aug 2012 14:55:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13B3A21E8034 for ; Mon, 27 Aug 2012 14:55:08 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8030012pbb.31 for ; Mon, 27 Aug 2012 14:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=3g0WNyEdg/EuqE/3nZglIzcHqIruIGJNBNq5jwsgkmI=; b=XVVwgMybavMh0JxASWLQhUHoEXmQi/dIgRyA4OdwVNB+++3XuQr+nxq6kvvITjrC1S Z6d4QYCJip9I1snIBCmvH1/Rpsx2Aut4t4udoRDocR8o95F1qaMJUH/4NwNG1LSZVBNp foWOdPPIGYKuLxyCYXg+20/oVpMGNGEvqlRKkdcKl1WLWwTAh5T0QluWg8GaRDeXRx6g X0nI6NfP1HDvwjHVE7ixvBn1kGuwz9FQ+gBMQouqLEdf+muZxbsRML9djBTNIHa+yHH1 j49afOhVXTEOi6AN+D8kaVKoK73F9+qH0Ky3U8IhI82K8fqyEOI0J/mJa7z0qd7xYHjV i26g== Received: by 10.68.190.8 with SMTP id gm8mr202938pbc.74.1346104507810; Mon, 27 Aug 2012 14:55:07 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id qn13sm15481264pbb.71.2012.08.27.14.55.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 14:55:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_478A0AE9-C074-46FA-880D-35553089D0ED" From: Dick Hardt In-Reply-To: Date: Mon, 27 Aug 2012 14:54:58 -0700 Message-Id: <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> To: X-Mailer: Apple Mail (2.1278) Cc: beaton@google.com, ietf@augustcellars.com, jose@ietf.org, dick.hardt@gmail.com Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:55:08 -0000 --Apple-Mail=_478A0AE9-C074-46FA-880D-35553089D0ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was considering "iat" to be the timestamp. I was not thinking there = would be an additional timestamp. On Aug 27, 2012, at 2:13 PM, wrote: > We have exp > = https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1= .1 > and iat > = https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1= .3 > in JWT. Why do we need a timestamp? > =20 > Replay attacks of the same jwt can be mitigated through the jti claim > = https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1= .7 > =20 > What do timestamp and nonce add to these? > =20 > Axel > =20 > =20 > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Monday, August 27, 2012 10:23 PM > To: Brian Eaton > Cc: Nennker, Axel; Jim Schaad; jose@ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > =20 > On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: >=20 >=20 > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt = wrote: > I have an application for JWT that is not OAuth2. > =20 > Should nonce and timestamp logic go in the application level protocol? > =20 > I prefer to NOT have the application level deal with token validity. >=20 >=20 > =20 > Having said that, nonce's are difficult to implement at scale and I = have heard of many sites that don't implement them fully. > =20 > Nonce alone can't be implemented efficiently. You have to have time = stamps as well, otherwise you are stuck storing ever nonce you've ever = seen, forever. > =20 > Even nonce + time stamp is challenging in distributed systems. It = adds a lot of complexity. That complexity is sometimes merited, but not = always. > =20 > Thanks for confirming my statement. > =20 > I have stopped using nonce and only use time stamps lately and have = made the system relatively stateless so that a second submission of the = token is ok. That may not work for everyone, but I have found that = architecture to be easier to implement and scale. --Apple-Mail=_478A0AE9-C074-46FA-880D-35553089D0ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I was considering "iat" to be the timestamp. I was = not thinking there would be an additional = timestamp.



wrote: > No > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > > Axel.Nennker@telekom.de schrieb: >> >> NO >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Friday, August 17, 2012 9:05 AM >> To: jose@ietf.org >> Subject: [jose] POLL: Support Multiple types for algorithms >> >> >> >> If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. >> >> Should support be mandated to allow an algorithm to be both a string and an object >> >> Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"} >> >> >> Room vote: 1 yes, 5 no, 4 discuss >> >> >> ------------------------------ >> >> 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 >> >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --14dae93409e56e9edf04c849a501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

NO

On Aug 27, 2012 8:43 AM, "Torsten Lodderste= dt" <torsten@lodderstedt= .net> wrote:
No
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

=


Axel.Nennker@t= elekom.de schrieb:
NO

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org<=
/a>] On Behalf Of Jim Schaad

Sent: Friday, August 17, 2012 9:05 AM
To: jose@ietf.org
Subject: [jose] POLL: Support Mul=
tiple types for algorithms

<CHAIR>

If you voted at the =
face-2-face please do not vote again.  If you want to provide comments plea=
se change the title from POLL to DISCUSS.


Should support be mandated to allow an algorithm to be both a string an=
d an object

Example:  "alg":{"name":"EC-DH-=
SS", "random":"XXXXX", "KDF":"CS256=
", "kid":"12345"}



Room vote:  1 yes, 5 no, 4 discuss



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
<=
/pre>

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

--14dae93409e56e9edf04c849a501-- From ignisvulpis@googlemail.com Sat Aug 25 00:37:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6521F8449 for ; Sat, 25 Aug 2012 00:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8VBK3ODoQWR for ; Sat, 25 Aug 2012 00:37:42 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 683C921F844A for ; Sat, 25 Aug 2012 00:37:42 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1270409wib.13 for ; Sat, 25 Aug 2012 00:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xlhHEzvBRY12SmFub3f+DSftOOccZ2YyWPNrGd0nXZg=; b=tZ7WqKyJkIsEdHaIf5knCvMUq6JDExSsUkVyMAtbDWNtd8sX72lvpt34VXCnEr19iG FDOXM5H+KQTDx9gZ7VLVXwnLFupFQnC4iEez9Tkvx3zcNE076HfTn0Qn5m+l36Vck2vL V1iigRY62cO4cT+y65yqXDxwz+NIemG4wr91yQYgJftqrGNG+m8oJIuQ3/12cm9cAlpO r6psdf/6j/8GVUxWN3vzzdBNPW4O2Se6xip7byvQN/MND2tE9CH6Tk7E6taBcd2gQ5w8 6A7Mm9M5iyUkJXMhLfx9Tl9UTB2IIJ9tg3mKAL4GbeJXVSVP7NyAGnDu96PXHsa3Y/x8 L/Rg== MIME-Version: 1.0 Received: by 10.216.138.220 with SMTP id a70mr4016481wej.170.1345880261432; Sat, 25 Aug 2012 00:37:41 -0700 (PDT) Received: by 10.216.241.4 with HTTP; Sat, 25 Aug 2012 00:37:41 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sat, 25 Aug 2012 09:37:41 +0200 Message-ID: From: Axel Nennker To: Mike Jones Content-Type: multipart/alternative; boundary=0016e6d99b45e4967b04c8122afa X-Mailman-Approved-At: Mon, 27 Aug 2012 18:58:04 -0700 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 07:37:43 -0000 --0016e6d99b45e4967b04c8122afa Content-Type: text/plain; charset=ISO-8859-1 To clarify: What is the base specification that Jim mentioned? Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ? Would somebody please present a use-case for either nonce or timestamp? If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not? I guess I am missing some information that those in the room who voted "yes" had? Axel 2012/8/25 Mike Jones > I'll note for discussion purposes that a nonce and a timestamp are not the > same thing (although sometimes they are used to achieve similar/related > goals). A nonce tends to be an opaque value that must be preserved across > the communication. Whereas a timestamp typically has defined semantics - > sometimes simply a non-decreasing integer value - and sometimes a > representation of time, and then, sometimes with a uniqueness requirement. > > For discussion purposes, I'll say that the simplest thing for us to do > (should we decide to do anything in this regard) would be to define the > nonce as an opaque string value that must be preserved. > > We could also define a timestamp parameter, but as I wrote above, that > would likely require us to specify additional semantics - starting with > whether it's a non-decreasing integer or a representation of a time value. > This seems much harder to define and possibly to use than a nonce. > > Would it make sense to define a nonce parameter now and hold off on > defining a timestamp parameter until there's a clear demonstrated use case > for which a nonce is not sufficient? That would be my personal > recommendation. > > Best wishes, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Nonce/Timestamp parameter > > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Do we need to define a nonce/timestamp parameter in the base specification? > > > > Room vote: 6 yes, 0 no, 1 discuss > > > _______________________________________________ > 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 > --0016e6d99b45e4967b04c8122afa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To clarify: What is the base specification that Jim mentioned?
Is it: <= a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03">ht= tp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?

Wo= uld somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and = state? Nonce would be signed while state is not?

I guess I am missin= g some information that those in the room who voted "yes" had?
Axel

2012/8/25 Mike Jones <Michael.Jones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestamp are not = the same thing (although sometimes they are used to achieve similar/related= goals). =A0A nonce tends to be an opaque value that must be preserved acro= ss the communication. =A0Whereas a timestamp typically has defined semantic= s - sometimes simply a non-decreasing integer value - and sometimes a repre= sentation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do = (should we decide to do anything in this regard) would be to define the non= ce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that woul= d likely require us to specify additional semantics - starting with whether= it's a non-decreasing integer or a representation of a time value. =A0= This seems much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on definin= g a timestamp parameter until there's a clear demonstrated use case for= which a nonce is not sufficient? =A0That would be my personal recommendati= on.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best wishes= ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.org
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again. =A0If you want to= provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?=



Room vote: =A06 yes, 0 no, 1 discuss


_______________________________________________
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

--0016e6d99b45e4967b04c8122afa-- From kent@bbn.com Mon Aug 27 21:19:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793DE11E80A3 for ; Mon, 27 Aug 2012 21:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOxoVqZt9eht for ; Mon, 27 Aug 2012 21:19:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F711E808E for ; Mon, 27 Aug 2012 21:19:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38182 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6DH8-000AK0-2z; Tue, 28 Aug 2012 00:19:38 -0400 Message-ID: <503C46D8.9020808@bbn.com> Date: Tue, 28 Aug 2012 00:19:36 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org, Axel.Nennker@telekom.de References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000004050107080205090508" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:19:41 -0000 This is a multi-part message in MIME format. --------------000004050107080205090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Axel, I did not vote on this issue, but I am concerned by what appears to be the basis for your position. Specifically, you say: *Maybe there is some justification for nonce in jwt but if jwt is used with oauth2 then we already have state.* JOSE's cope is not just oauth2, so it seems inappropriate to argue that a feature is not needed based on just that app. Steve --------------000004050107080205090508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Axel,

I did not vote on this issue, but I am concerned by what appears to be the basis for your
position. Specifically, you say:

Maybe there is some justification for nonce in jwt but if jwt is used with oauth2 then we already have state.

JOSE's cope is not just oauth2, so it seems inappropriate to argue that a feature is not
needed based on just that app.

Steve
--------------000004050107080205090508-- From kent@bbn.com Mon Aug 27 21:27:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB46C21E8042 for ; Mon, 27 Aug 2012 21:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZsbHjgCMrB7 for ; Mon, 27 Aug 2012 21:27:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0221E803F for ; Mon, 27 Aug 2012 21:27:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50722 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6DOV-000ALe-Ug for jose@ietf.org; Tue, 28 Aug 2012 00:27:16 -0400 Message-ID: <503C48A2.2040702@bbn.com> Date: Tue, 28 Aug 2012 00:27:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:27:17 -0000 Brian, ... Nonce alone can't be implemented efficiently. You have to have time stamps as well, otherwise you are stuck storing ever nonce you've ever seen, forever. In general how long one needs to retain a nonce depends on how the nonce is used. But I agree that using timestamps and plus nonces together helps. Steve From rbarnes@bbn.com Mon Aug 27 21:29:19 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C18721E8039 for ; Mon, 27 Aug 2012 21:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6sIeIsffcZb for ; Mon, 27 Aug 2012 21:29:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3321E803F for ; Mon, 27 Aug 2012 21:29:18 -0700 (PDT) Received: from [128.89.255.8] (port=49247) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6DQT-000ALw-3H; Tue, 28 Aug 2012 00:29:17 -0400 Date: Tue, 28 Aug 2012 11:29:12 +0700 From: Richard Barnes To: Stephen Kent Message-ID: <99FB3331D4B5425BBCFB1466EFF19CFF@bbn.com> In-Reply-To: <503C48A2.2040702@bbn.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <503C48A2.2040702@bbn.com> X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:29:19 -0000 Steve: That depends on how the nonce is being used, right? All: This sort of confusion is a good example of how underspecified this question is. Does anyone understand the question well enough to re-phrase more clearly? -- Richard Barnes Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, August 28, 2012 at 11:27 AM, Stephen Kent wrote: > Brian, > > ... > > Nonce alone can't be implemented efficiently. You have to have time > stamps as well, otherwise you are stuck storing ever nonce you've ever > seen, forever. > > In general how long one needs to retain a nonce depends on how the nonce > is used. But I agree > that using timestamps and plus nonces together helps. > > Steve > _______________________________________________ > jose mailing list > jose@ietf.org (mailto:jose@ietf.org) > https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Aug 27 21:30:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F7221E803F for ; Mon, 27 Aug 2012 21:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RvXbtBPOUJG for ; Mon, 27 Aug 2012 21:30:19 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 282A021E8039 for ; Mon, 27 Aug 2012 21:30:18 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 28 Aug 2012 06:30:17 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Tue, 28 Aug 2012 06:30:16 +0200 From: To: , Date: Tue, 28 Aug 2012 06:30:13 +0200 Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter Thread-Index: Ac2E1FkVDWRwHUA/RZSnc4vLTezgDQAAHgaA Message-ID: References: <503C46D8.9020808@bbn.com> In-Reply-To: <503C46D8.9020808@bbn.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C11AHE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 04:30:20 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C11AHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that jwt is useful without oauth2. Still we already have exp, iat, jti in jwt. What protection do nonce/timestamp bring to jwt users? I think the poll about this question should be reconsidered because the que= stion is unclear and nonce/timestamp have no supporting use case beyond exp= , iat, jti. Axel From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, August 28, 2012 6:20 AM To: jose@ietf.org; Nennker, Axel Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter Axel, I did not vote on this issue, but I am concerned by what appears to be the = basis for your position. Specifically, you say: Maybe there is some justification for nonce in jwt but if jwt is used with = oauth2 then we already have state. JOSE's cope is not just oauth2, so it seems inappropriate to argue that a f= eature is not needed based on just that app. Steve --_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C11AHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I agree that jwt is  useful without oauth2. <= /p>

Still we already have exp, iat, jti in jwt.<= o:p>

What protection do nonce/t= imestamp bring to jwt users?

 

I think the poll= about this question should be reconsidered because the question is unclear= and nonce/timestamp have no supporting use case beyond exp, iat, jti.

 

<= p class=3DMsoNormal>Axel

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

 

From:<= /b> Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, A= ugust 28, 2012 6:20 AM
To: jose@ietf.org; Nennker, Axel
Sub= ject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

Axel,

I did not vote on this issue, but I am concerned by what app= ears to be the basis for your
position. Specifically, you say:

<= b>Maybe there is some justification for nonce in jwt but if jwt is used wit= h oauth2 then we already have state.

JOSE's cope is not just oau= th2, so it seems inappropriate to argue that a feature is not
needed bas= ed on just that app.

Steve

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C11AHE111541eme_-- From lef.mutualauth@gmail.com Mon Aug 27 23:52:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48D821E804E for ; Mon, 27 Aug 2012 23:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-2.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ETLq1SR3Uvi for ; Mon, 27 Aug 2012 23:52:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51B0421E8049 for ; Mon, 27 Aug 2012 23:52:00 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8657243pbb.31 for ; Mon, 27 Aug 2012 23:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Zl+gPUzYct/CiYj7byosnv4Cy4H50jWzdG8LmfoyDE=; b=fw8uN/E5u8K4NcEudIQEvzmRSJPI7hzECCcAflSrkYczDjBgg4So/Coyq1rfOU8yBB eCHyBNydB05Iiph5ZsZA/Bf9Fa1Lus4qPWjal10KEx2X8CMgOh/uEP0ZvAj+eIG4FRjA p+K5VCL18BvbrFeCYroBnztGxC+AVWKa+75IleEWsli1D+oAvMPhcUDR6R0KAv0LDgvE mBEDmsXFlOVSihhSh5AV9GahXlygjqTavv31PpsyEK+Nw+cNY0ADEi9IrJnqXcHbUlOR 18dS43w29/VfnTLCzPt+2kcJQsC/xUUUOZSzSvLKaiUOfbl+ITdVCX3/sR+XF+9Qlfdr g7eA== Received: by 10.66.74.195 with SMTP id w3mr35386786pav.64.1346136720111; Mon, 27 Aug 2012 23:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:51:39 -0700 (PDT) In-Reply-To: References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:51:39 +0900 Message-ID: To: Axel.Nennker@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@augustcellars.com, jose@ietf.org Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:52:00 -0000 NO On Mon, Aug 27, 2012 at 5:21 PM, wrote: > NO > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:08 AM > To: jose@ietf.org > Subject: [jose] POLL: Non AEAD algorithms as a single name > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a single content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} > New: {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ > 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 -- HAYASHI, Tatsuya Lepidum Co. Ltd. From lef.mutualauth@gmail.com Mon Aug 27 23:54:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787CD21E8045 for ; Mon, 27 Aug 2012 23:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=-2.409, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRgAxk6sB8K3 for ; Mon, 27 Aug 2012 23:54:02 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC44F21E8050 for ; Mon, 27 Aug 2012 23:54:01 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8659900pbb.31 for ; Mon, 27 Aug 2012 23:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=7iLCW9rAGzZEPxrb7gAMm039pj+opDIROVmrmWW1Nlo=; b=PV80Y7kjKeLOVZcIVk7gH2qWKj6bCQx4fbahpvT019KlKtTZQ8LNqUCm0+RtXf+EP3 0yVRlIzIGeZI52Xh2L63Ak6gVnZuGTJVt+ZIOYVA0w2RJIPJAZfB5Bi01xljsAx54FvI PKD3E2yWHLVLlPbBwnFWzw0qdmaBN1NUTVn8GGpr223X4U6fmIrh06gyR+fBeFexX8Sj taxO+FqrS3P4T+jGnlQf8YEfnDTFVSO9IwEPaDzE3rK7SCm39ED4wGw8C2si7iqThMLU Vr0+aTOWTNGTQm779OO5KRP/OE6xUJrZHRz/S0ENnShhwhxYlXe2Y7rHGX4hS9yVjm7X 3EQQ== Received: by 10.66.83.234 with SMTP id t10mr35477171pay.39.1346136841449; Mon, 27 Aug 2012 23:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:53:41 -0700 (PDT) In-Reply-To: References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> <59966db6-b436-4e5d-98fd-63f135b971ce@email.android.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:53:41 +0900 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:54:02 -0000 NO On Tue, Aug 28, 2012 at 10:49 AM, Breno de Medeiros wrote: > NO > > On Aug 27, 2012 8:43 AM, "Torsten Lodderstedt" > wrote: >> >> No >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> >> >> Axel.Nennker@telekom.de schrieb: >>> >>> NO >>> >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >>> Jim Schaad >>> >>> Sent: Friday, August 17, 2012 9:05 AM >>> To: jose@ietf.org >>> Subject: [jose] POLL: Support Multiple types for algorithms >>> >>> >>> >>> If you voted at the face-2-face please do not vote again. If you want to >>> provide comments please change the title from POLL to DISCUSS. >>> >>> >>> Should support be mandated to allow an algorithm to be both a string and >>> an object >>> >>> Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", >>> "kid":"12345"} >>> >>> >>> >>> Room vote: 1 yes, 5 no, 4 discuss >>> >>> >>> ________________________________ >>> >>> 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 >> >> >> _______________________________________________ >> >> 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 > -- HAYASHI, Tatsuya Lepidum Co. Ltd. From lef.mutualauth@gmail.com Mon Aug 27 23:55:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9521E8049 for ; Mon, 27 Aug 2012 23:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=-2.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZzzxHs12lma for ; Mon, 27 Aug 2012 23:55:06 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B533821E8045 for ; Mon, 27 Aug 2012 23:55:06 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8661280pbb.31 for ; Mon, 27 Aug 2012 23:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=e0b6YzvZydkBCRpuqsl8rR8Yd4GFTIHwHf3faDNhDrg=; b=ku7n43vVnhfi17sQiNskQNc+Qb8A3gRd2kF8Qp44+xXIbvzgXsT17De7QmaSL1J7fd f9NreTjdSxHb9NzqOPUfu8q3/XMYdmZhXVNwasjeM62SStC0oJtIdjgvYfnWGGzYtqEU 5pCLrA80CjHQdIcSDGdan74wL3gJ1r8d8OdBzcfysUW4rlMvuxGQ3bEp8RxLH/SgGhrr 95BRI0LUx70timrBX6c+PWPn5Vylqhh3kKJJufy5wlOEsBVyGhfurz9SORpdGVYZmzfp 4OPMghLqoJIXZMd0HD5TvYe1tLChfmfz8LpY32MAF8Ud898ARZk9fVmIqc3fGUub418V Tlyg== Received: by 10.68.197.9 with SMTP id iq9mr3500599pbc.17.1346136906498; Mon, 27 Aug 2012 23:55:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:54:46 -0700 (PDT) In-Reply-To: References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:54:46 +0900 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:55:07 -0000 NO On Mon, Aug 27, 2012 at 5:18 PM, wrote: > NO > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:07 AM > To: jose@ietf.org > Subject: [jose] POLL: Add other than pre-shared MAC key > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > Should we add the ability to have a randomly generated MAC key protected by a different key? The other key could be either a pre-shared symmetric key or a public key. > > > > Room vote: 3 yes, 5 no, 3 discuss > > > _______________________________________________ > 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 -- HAYASHI, Tatsuya Lepidum Co. Ltd. From lef.mutualauth@gmail.com Mon Aug 27 23:55:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C701E21E8054 for ; Mon, 27 Aug 2012 23:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=-2.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAZ4pj1puVZ6 for ; Mon, 27 Aug 2012 23:55:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59C7921E8050 for ; Mon, 27 Aug 2012 23:55:27 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rr4so8661280pbb.31 for ; Mon, 27 Aug 2012 23:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=CJdQ+t1Wru/dkviWpL0sujW0mKqrn8Hza31izUMz924=; b=CEi3j7SB0JLQCob4rs/CVD7Gt4+JFEP3TPSPXf1IqdnERpsq/uWsY4MR94KjQuki10 vxIaQx0wTBuwIlXfiVtcQCecT2UUq9GhT5vi4vUlCOzX5XzCErb9UKxsb6IPyi5JBH8l Ok8VtMRCFgbguvFS0HnRDJrZBuX/EzC51bMUckEn+bTnfpHq6f90DU2kEaZzy9eZuHbK G6ZPVCwtXl5DSK1kv+O5+1RhxVzFE1obBbGKnFZe5wcGGWX4edw8dcYmJo68rZDPJutr MBN3N/8aGTuIWrZAiMvoteM8WDwiFtgeCtE7R4/J5nzjNiNkdVt6vhtDjud0FmmRVC2m 4Lww== Received: by 10.68.234.99 with SMTP id ud3mr39919254pbc.166.1346136927228; Mon, 27 Aug 2012 23:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:55:07 -0700 (PDT) In-Reply-To: References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:55:07 +0900 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:55:27 -0000 YES On Mon, Aug 27, 2012 at 5:16 PM, wrote: > YES > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Criticality of understanding header fields > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > What should be the criticality of header fields as defined by the core specification? > > YES - all headers fields are critical > NO - all header fields are non-critical > MAYBE - header fields are marked critical or criticality should be defined by the application DISCUSS - need to talk more > > Room vote: 2 yes, 0 no, 4 maybe, 3 discuss > > > > _______________________________________________ > 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 -- HAYASHI, Tatsuya Lepidum Co. Ltd. From lef.mutualauth@gmail.com Mon Aug 27 23:55:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1586821E804B for ; Mon, 27 Aug 2012 23:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.492 X-Spam-Level: X-Spam-Status: No, score=-5.492 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5fJd3dNOEdD for ; Mon, 27 Aug 2012 23:55:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24B21E804D for ; Mon, 27 Aug 2012 23:55:40 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rr4so8661280pbb.31 for ; Mon, 27 Aug 2012 23:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xU0vrsdWS0gWBAHO0m6xr+GFhdoFxDVD5T0xacl9+Vo=; b=0/74NaPXmeAIzcm3ekcMZngcnkxvEEyB+jEHU1vBp9zEHviOXvtzBHBpPDKg0n71aD KhqN0uk+JAsBMKRvvyINlUQuE+q18vabXBZcaE/NFr7gxoLYltG/0E/f8WMdlTRO08bF sn+P5JELiX2HwTjQpmb60RoUGWNFuZyPqbe8dBNsAGmeIS/46vNupFHqGlpeVbK7f3bt VzWri6jXWWceFiLvxAkoK6wzbMl9r/FCqKoj0au2O8Fch5tPJBNsbDpY2AHU/yUgcCF9 DvzpyZVSWg7XS0BHoQu59Rzg/AXdaSOXOT0xnovEf4e3xG9CcaP5I9BEy8SUXSjSHBk+ tscQ== Received: by 10.68.197.9 with SMTP id iq9mr3503280pbc.17.1346136940122; Mon, 27 Aug 2012 23:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:55:19 -0700 (PDT) In-Reply-To: References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:55:19 +0900 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:55:41 -0000 YES On Mon, Aug 27, 2012 at 5:15 PM, wrote: > YES > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Is KID sufficently defined > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > Is the current text for KID sufficiently defined and understood? > > > Room vote: 2 yes, 0 no, 1 discuss > > > _______________________________________________ > 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 -- HAYASHI, Tatsuya Lepidum Co. Ltd. From lef.mutualauth@gmail.com Mon Aug 27 23:56:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E31E21E8050 for ; Mon, 27 Aug 2012 23:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.366 X-Spam-Level: X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=-1.767, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWpZxWJn9TVh for ; Mon, 27 Aug 2012 23:56:02 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2A21E804D for ; Mon, 27 Aug 2012 23:56:02 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rr4so8661280pbb.31 for ; Mon, 27 Aug 2012 23:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Q8LGNzjQsu004BbvHnCO0KqFSF8cqamuhv3T0EusbZQ=; b=p1iqvghl1wt4F6/ULNPLiVGnlSPSTRtTDgF+Tfz226x1ACpqIZDGY9O/y/XsCzHFDH VM+8jDhatPVlwFP7lPVQrWq5GX/uWSPr921GQrj3BXhAuvnLTyZ1bUFyHhrBisDyCo5C Sg/31poAfnSsCmlLQb3dmCBOsbLbExvqr3dYZMyLnckU58fT2Z1ETAC9wcqLIJJJqKCp isuMz4i9LJvxCw/rVxZRXvH+DnK5ndis85mYqNPENm1LSoNCTmJPDb5me3OLAhxNiwwg DbFHQ1TQDKHcd7CmftOS6CdhWNTHw7a1BNu55Dm6h9XfgqW1uClA+OIFm9F+Zorc7Nfd 4RRQ== Received: by 10.66.89.70 with SMTP id bm6mr35452772pab.41.1346136962009; Mon, 27 Aug 2012 23:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:55:41 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FAA168AE@WSMSG3153V.srv.dir.telstra.com> References: <000301cd7c46$c5b1c810$51155830$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114FAA168AE@WSMSG3153V.srv.dir.telstra.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:55:41 +0900 Message-ID: To: "jose@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:56:02 -0000 NO On Sun, Aug 19, 2012 at 8:26 PM, Manger, James H wrote: > No > Should indicate all the main building blocks in each name (AES, SHA2, RSA, EC, ...) instead of trying to anoint one by making it the default. > > -- > James Manger > > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Jim Schaad >> Sent: Friday, 17 August 2012 5:05 PM >> To: jose@ietf.org >> Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters >> >> >> >> If you voted at the face-2-face please do not vote again. If you want >> to provide comments please change the title from POLL to DISCUSS. >> >> Should SHA1 be the default parameters for these algorithms? >> >> >> Room vote: 0 yes, 5 no, 3 discuss >> >> >> _______________________________________________ >> 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 -- HAYASHI, Tatsuya Lepidum Co. Ltd. From lef.mutualauth@gmail.com Mon Aug 27 23:56:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C33E21E804E for ; Mon, 27 Aug 2012 23:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=-1.656, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBne0hCBtyMC for ; Mon, 27 Aug 2012 23:56:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9CAE21E8045 for ; Mon, 27 Aug 2012 23:56:14 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rr4so8661280pbb.31 for ; Mon, 27 Aug 2012 23:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=cp9MMysuu/OyAgIxiOauv3nPKfiAhD+f46h5/98Rf9M=; b=YFZa4lSXYdFwqBQEUJsXa7ckSUl6tdp+CdYdtlNz51gaUYRenNU66C3YCXBmYTKzNC ZfXgxheu5aSz0/5Ty6zPnJYgg5Itwa/SzWwcxJedka1xCqn/PHkRy8u8nApvtnYgKZkA xME2Fws7d1CA1ZwItYUvi98giRcSmw9x/QNJUwoHeYeq0ZFA0uStFerJTRKAUZoO3jw9 xa6XjrGULlCbeDrCiC0lhqOEIBHb3udDvXPcFpwvjMjsPHoJjowYI1+ImGHXTFL40usf GG4BGrXVWElUx+Ro3F+NyLL4NI7MRlMN7ukGlkOUAZWa/3/w8aDvBI7e0H2q2VeTCBR7 ts8Q== Received: by 10.68.225.199 with SMTP id rm7mr40813083pbc.150.1346136974624; Mon, 27 Aug 2012 23:56:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.234.129 with HTTP; Mon, 27 Aug 2012 23:55:54 -0700 (PDT) In-Reply-To: <000201cd7c46$c4c60880$4e521980$@augustcellars.com> References: <000201cd7c46$c4c60880$4e521980$@augustcellars.com> From: "HAYASHI, Tatsuya" Date: Tue, 28 Aug 2012 15:55:54 +0900 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:56:15 -0000 YES On Fri, Aug 17, 2012 at 4:05 PM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Do we need to define a nonce/timestamp parameter in the base specification? > > > > Room vote: 6 yes, 0 no, 1 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- HAYASHI, Tatsuya Lepidum Co. Ltd. From rbarnes@bbn.com Tue Aug 28 01:02:34 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8CB21F84FA for ; Tue, 28 Aug 2012 01:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClLZTH7b-l9Q for ; Tue, 28 Aug 2012 01:02:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6263121F84F7 for ; Tue, 28 Aug 2012 01:02:33 -0700 (PDT) Received: from [128.89.255.8] (port=50290) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6Gkb-0006M3-CB; Tue, 28 Aug 2012 04:02:17 -0400 Date: Tue, 28 Aug 2012 15:02:14 +0700 From: Richard Barnes To: =?utf-8?Q?HAYASHI=2C_Tatsuya?= Message-ID: <3F05CE94720C45679B743583BBE2EBD3@bbn.com> In-Reply-To: References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: jose@ietf.org Subject: Re: [jose] DISCUSS: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:02:34 -0000 I voted "NO" on this in the room, because I don't understand it. Could one of you "YES" voters explain it? What does "kid" mean in the context of a public-key wrapped key? Is it a public key? If so, in what format? How about in the context of key agreement? Thanks, --Richard -- Richard Barnes Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, August 28, 2012 at 1:55 PM, HAYASHI, Tatsuya wrote: > YES > > On Mon, Aug 27, 2012 at 5:15 PM, wrote: > > YES > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: Friday, August 17, 2012 9:05 AM > > To: jose@ietf.org (mailto:jose@ietf.org) > > Subject: [jose] POLL: Is KID sufficently defined > > > > > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > > > Is the current text for KID sufficiently defined and understood? > > > > > > Room vote: 2 yes, 0 no, 1 discuss > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org (mailto:jose@ietf.org) > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > > jose mailing list > > jose@ietf.org (mailto:jose@ietf.org) > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > -- > HAYASHI, Tatsuya > Lepidum Co. Ltd. > _______________________________________________ > jose mailing list > jose@ietf.org (mailto:jose@ietf.org) > https://www.ietf.org/mailman/listinfo/jose > From rbarnes@bbn.com Tue Aug 28 01:04:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A490E11E80A3 for ; Tue, 28 Aug 2012 01:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.597 X-Spam-Level: X-Spam-Status: No, score=-106.597 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ63N5l+IwNl for ; Tue, 28 Aug 2012 01:04:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DECDE11E808D for ; Tue, 28 Aug 2012 01:04:55 -0700 (PDT) Received: from [128.89.255.8] (port=50298) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6Gn7-000BSN-E8; Tue, 28 Aug 2012 04:04:53 -0400 Date: Tue, 28 Aug 2012 15:04:50 +0700 From: Richard Barnes To: =?utf-8?Q?HAYASHI=2C_Tatsuya?= Message-ID: In-Reply-To: References: <000201cd7c46$c4c60880$4e521980$@augustcellars.com> X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:04:56 -0000 Could someone explain what the use case is for these parameters? As a general JWS/JWE parameter, as opposed to a JWT parameter? I wonder if we actually want a more functionally specific random field, such as the UKM field used for DH in CMS. --Richard -- Richard Barnes Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, August 28, 2012 at 1:55 PM, HAYASHI, Tatsuya wrote: > YES > > On Fri, Aug 17, 2012 at 4:05 PM, Jim Schaad wrote: > > > > > > If you voted at the face-2-face please do not vote again. If you want to > > provide comments please change the title from POLL to DISCUSS. > > > > Do we need to define a nonce/timestamp parameter in the base specification? > > > > > > > > Room vote: 6 yes, 0 no, 1 discuss > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org (mailto:jose@ietf.org) > > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > HAYASHI, Tatsuya > Lepidum Co. Ltd. > _______________________________________________ > jose mailing list > jose@ietf.org (mailto:jose@ietf.org) > https://www.ietf.org/mailman/listinfo/jose From breno@google.com Tue Aug 28 06:45:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6087711E80D9 for ; Tue, 28 Aug 2012 06:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5nDUAcf6ZZw for ; Tue, 28 Aug 2012 06:45:17 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 90BD111E80D3 for ; Tue, 28 Aug 2012 06:45:17 -0700 (PDT) Received: by qadz3 with SMTP id z3so2585756qad.10 for ; Tue, 28 Aug 2012 06:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=ZnpxA4gnPOBSRo1+kvwijUZME13a8OjhBURPvPv+9s4=; b=CeAK5nXnpSH2AvfVYKvewkeNh4VQRZw3xXOpNBUvdH8H9xrpDAwNCHnx6meQrNuOjR LubkUuroBwKGsld4cWFa2q3tpASpz5UJaOKg3w/FJlc6lBTDjyHE8/Sg/ipNcbGyhYhX ttGOYPO0WVJZTUKIOlQVcptoFwcBFJm9mivpPvrgtFfRaN+LVnNVGIU5kVKmbGpj6J4A JYOwqCFKLxAZ9GAclAyafVPpvGsxA0AyxGarMQN92D74cENCAdOYurCvbEgDttDVFZS1 qmxj9ZlbRYT13DcPCSK2p+b2hcpW6QoXO8RKY6YIgvjkDNqBQZsQpdHuHTJZzh9xyrLq 5vLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ZnpxA4gnPOBSRo1+kvwijUZME13a8OjhBURPvPv+9s4=; b=GAE1SHVhBPelx0UVWUTP1VMs84CEfqt7RxiaEvlfVmcQYfBagRPyhG5zpBWokibDDU MFNAwIGPjSwuue6ZQkqiuvVlQtxXQaLX9ZG3vGQoqNCbWxOlDsvgFnyb/XfMnEgB5BCW A7fBVVCyXB7GfCZVPtSoAyJRGlDKY/lx/WMA6srOFbc5EnMoKpnOJAW1mPkcGpJTFiQ5 vzoI/pgcn8tnR2P8znQpKMMbsjYAPRPDYsvGmb2U6DjaPZfaD1IHbY5zjUN40DKWZd1t BsbnRWSIzLNtEhXfRH3vWRNEI1S20by4S6Bo5glsuwMP2UGhLHKlG91v4yIZcqGXj8BY 0OEQ== Received: by 10.224.173.206 with SMTP id q14mr30149440qaz.31.1346161516898; Tue, 28 Aug 2012 06:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.173.206 with SMTP id q14mr30149411qaz.31.1346161516648; Tue, 28 Aug 2012 06:45:16 -0700 (PDT) Received: by 10.229.162.193 with HTTP; Tue, 28 Aug 2012 06:45:16 -0700 (PDT) Received: by 10.229.162.193 with HTTP; Tue, 28 Aug 2012 06:45:16 -0700 (PDT) In-Reply-To: References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> Date: Tue, 28 Aug 2012 06:45:16 -0700 Message-ID: From: Breno de Medeiros To: "HAYASHI, Tatsuya" Content-Type: multipart/alternative; boundary=20cf30363f6502979004c853a79c X-System-Of-Record: true X-Gm-Message-State: ALoCoQmbPYVkhO/cb5jj17ovDR7GiJU01s9FdbFJHdSmCNZSYG8MsgVROta9d/oZY7d6tJULUkZIVO/31jRsWK11gOPHHLFeY08ML3vvQ5a+W2YmC/EnTQbhG7M8ab7LCUAzvM1desyG7kGI8fe5DYqMir9wq1GTM0r1j418urZJ4HaZcVQlQG88DLpJxZMQgwC8Tceu7utb Cc: jose@ietf.org Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:45:18 -0000 --20cf30363f6502979004c853a79c Content-Type: text/plain; charset=ISO-8859-1 YES On Aug 27, 2012 11:55 PM, "HAYASHI, Tatsuya" wrote: > YES > > On Mon, Aug 27, 2012 at 5:15 PM, wrote: > > YES > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > > Sent: Friday, August 17, 2012 9:05 AM > > To: jose@ietf.org > > Subject: [jose] POLL: Is KID sufficently defined > > > > > > > > If you voted at the face-2-face please do not vote again. If you want > to provide comments please change the title from POLL to DISCUSS. > > > > Is the current text for KID sufficiently defined and understood? > > > > > > Room vote: 2 yes, 0 no, 1 discuss > > > > > > _______________________________________________ > > 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 > > > > -- > HAYASHI, Tatsuya > Lepidum Co. Ltd. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --20cf30363f6502979004c853a79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

YES

On Aug 27, 2012 11:55 PM, "HAYASHI, Tatsuya= " <lef.mutualauth@gmail= .com> wrote:
YES

On Mon, Aug 27, 2012 at 5:15 PM, =A0<Axel.Nennker@telekom.de> wrote:
> YES
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
> Sent: Friday, August 17, 2012 9:05 AM
> To: jose@ietf.org
> Subject: [jose] POLL: Is KID sufficently defined
>
> <CHAIR>
>
> If you voted at the face-2-face please do not vote again. =A0If you wa= nt to provide comments please change the title from POLL to DISCUSS.
>
> Is the current text for KID sufficiently defined and understood?
>
>
> Room vote: =A02 yes, 0 no, 1 discuss
>
>
> _______________________________________________
> 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



--
HAYASHI, Tatsuya
Lepidum Co. Ltd.
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
--20cf30363f6502979004c853a79c-- From jricher@mitre.org Tue Aug 28 07:34:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CAB21F84F6 for ; Tue, 28 Aug 2012 07:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryaPnZWQ5rCD for ; Tue, 28 Aug 2012 07:34:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AF74D21F84F3 for ; Tue, 28 Aug 2012 07:34:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AE33C21B1A7A; Tue, 28 Aug 2012 10:34:21 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BDCE21B0625; Tue, 28 Aug 2012 10:34:21 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 Aug 2012 10:34:21 -0400 Message-ID: <503CD692.4020007@mitre.org> Date: Tue, 28 Aug 2012 10:32:50 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Axel Nennker References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060902090801060207080300" X-Originating-IP: [129.83.31.58] Cc: Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:34:24 -0000 --------------060902090801060207080300 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 08/25/2012 03:37 AM, Axel Nennker wrote: > To clarify: What is the base specification that Jim mentioned? > Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ? > > Would somebody please present a use-case for either nonce or timestamp? > If a jwt is used with oauth2 then what is the difference between nonce > and state? Nonce would be signed while state is not? > Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject. -- Justin > I guess I am missing some information that those in the room who voted > "yes" had? > > Axel > > 2012/8/25 Mike Jones > > > I'll note for discussion purposes that a nonce and a timestamp are > not the same thing (although sometimes they are used to achieve > similar/related goals). A nonce tends to be an opaque value that > must be preserved across the communication. Whereas a timestamp > typically has defined semantics - sometimes simply a > non-decreasing integer value - and sometimes a representation of > time, and then, sometimes with a uniqueness requirement. > > For discussion purposes, I'll say that the simplest thing for us > to do (should we decide to do anything in this regard) would be to > define the nonce as an opaque string value that must be preserved. > > We could also define a timestamp parameter, but as I wrote above, > that would likely require us to specify additional semantics - > starting with whether it's a non-decreasing integer or a > representation of a time value. This seems much harder to define > and possibly to use than a nonce. > > Would it make sense to define a nonce parameter now and hold off > on defining a timestamp parameter until there's a clear > demonstrated use case for which a nonce is not sufficient? That > would be my personal recommendation. > > Best wishes, > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org ] On > Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Nonce/Timestamp parameter > > > > If you voted at the face-2-face please do not vote again. If you > want to provide comments please change the title from POLL to DISCUSS. > > Do we need to define a nonce/timestamp parameter in the base > specification? > > > > Room vote: 6 yes, 0 no, 1 discuss > > > _______________________________________________ > 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 > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------060902090801060207080300 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 08/25/2012 03:37 AM, Axel Nennker wrote:
To clarify: What is the base specification that Jim mentioned?
Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?

Would somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?


Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.

 -- Justin

I guess I am missing some information that those in the room who voted "yes" had?

Axel

2012/8/25 Mike Jones <Michael.Jones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestamp are not the same thing (although sometimes they are used to achieve similar/related goals).  A nonce tends to be an opaque value that must be preserved across the communication.  Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value.  This seems much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient?  That would be my personal recommendation.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.org
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?



Room vote:  6 yes, 0 no, 1 discuss


_______________________________________________
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



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

--------------060902090801060207080300-- From ve7jtb@ve7jtb.com Tue Aug 28 07:47:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEFD21F84BF for ; Tue, 28 Aug 2012 07:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up+zu7XdXalX for ; Tue, 28 Aug 2012 07:47:29 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6689E21F84B3 for ; Tue, 28 Aug 2012 07:47:29 -0700 (PDT) Received: by qcac10 with SMTP id c10so3995653qca.31 for ; Tue, 28 Aug 2012 07:47:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=E5Wf/Z27amOqSpnQRNvg8M7fMMW2NMvkUkylz/A9AQY=; b=KP/klX4mPGPTa6UViPdMzJOnqvvXik8LByjlGK3YhPZp6SYALQlW1VSjn73jehZpXM nTc8BHagGB//pnZVxdQ/6BwhrwsDOd1EtQrJsOHdEokVh9EhfeFGDJeWikfhYPeRhNmL hvC4qo/GgEeh6B7x/dKOmo3MP1QdMo6r9dn/ntG9mo2gX24EbLwcwvZvTZonFjkhgXMg c1GkwKpoupVBuLq1wNUxFwtEWKvTUWMJJ6X+TJI4VbTsLl/L+6xfV29d8GGAzshk6YFj k00mUM1oYjdDlcgu9JUQ8KfmoSzSz6NyYBBQ8WqvKY1RPPvs/5YRMoVhJf1FsdpVm1dr jEzQ== Received: by 10.224.116.210 with SMTP id n18mr22187926qaq.46.1346165244395; Tue, 28 Aug 2012 07:47:24 -0700 (PDT) Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id gx4sm8725433qab.3.2012.08.28.07.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 07:47:21 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_839AED85-2B44-4F3E-805C-E12482C609BC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: Date: Tue, 28 Aug 2012 10:46:11 -0400 Message-Id: <2EF4D842-C6A3-418F-82B2-DEBB92F4565B@ve7jtb.com> References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkBIigj8h4nWwFM7KQrviNisc0hDsrA+eqA8BtM1wiPoicvKo741qivxLRr7UzMECPABT8F Cc: Brian Eaton , "ietf@augustcellars.com" , "jose@ietf.org" , "Axel.Nennker@telekom.de" , Dick Hardt Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:47:30 -0000 --Apple-Mail=_839AED85-2B44-4F3E-805C-E12482C609BC Content-Type: multipart/alternative; boundary="Apple-Mail=_A963B36B-7FFA-4E87-B822-01B6A71DE2F8" --Apple-Mail=_A963B36B-7FFA-4E87-B822-01B6A71DE2F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There are attacks that we have seen in the past that are possible if the = attacker can predict the header and control what is signed in the body. Perhaps nonce is not the best name for it. People seem to have kept to = the conclusion that it is used to maintain session state between = parties. I raised it as a standard place to add per message entropy, as JOSE = doesn't control the content of the body. I was not saying that it is required, it is not in cases where the = signer is producing the body without external input. It is intended as a optional claim who's value may not be processed by = the receiver at all.=20 Some applications might code something into the nonce, or use it to = prevent replay, that was however not my primary intent. John B. On 2012-08-27, at 5:02 PM, Anthony Nadalin = wrote: > Depends on what the nonce is used for as if this is for key entropy = then I would say there is very little overhead and storage issues and in = this case I would expect the header to contain the nonce, if it=92s for = state of some sort then I would expect it at the application level and = not as a header and more of a JWT claim. > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Brian Eaton > Sent: Monday, August 27, 2012 1:06 PM > To: Dick Hardt > Cc: ietf@augustcellars.com; jose@ietf.org; Axel.Nennker@telekom.de > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt = wrote: > I have an application for JWT that is not OAuth2. > =20 > Should nonce and timestamp logic go in the application level protocol? > =20 > Having said that, nonce's are difficult to implement at scale and I = have heard of many sites that don't implement them fully. > =20 > Nonce alone can't be implemented efficiently. You have to have time = stamps as well, otherwise you are stuck storing ever nonce you've ever = seen, forever. > =20 > Even nonce + time stamp is challenging in distributed systems. It = adds a lot of complexity. That complexity is sometimes merited, but not = always. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_A963B36B-7FFA-4E87-B822-01B6A71DE2F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 There are attacks that we have = seen in the past that are possible if the attacker can predict the = header and control what is signed in the = body.

Perhaps nonce is not the best name for it. =   People seem to have kept to the conclusion that it is used to = maintain session state between parties.

I = raised it as a standard place to add per message entropy, as JOSE = doesn't control the content of the body.
I was not saying that = it is required, it is not in cases where the signer is producing the = body without external input.

It is intended as = a optional claim who's value may not be processed by the receiver at = all. 

Some applications might code = something into the nonce, or use it to prevent replay, that was however = not my primary intent.

John = B.

On 2012-08-27, at 5:02 PM, Anthony = Nadalin <tonynad@microsoft.com> = wrote:

Depends on what the = nonce is used for as if this is for key entropy then I would say there = is very little overhead and storage issues and in this case I would = expect the header to contain the nonce, if it=92s for state of some sort = then I would expect it at the application level and  not as a = header and more of a JWT claim.
 
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Brian = Eaton
Sent: Monday, August 27, 2012 = 1:06 PM
To: Dick = Hardt
Cc: ietf@augustcellars.com; jose@ietf.org; Axel.Nennker@telekom.de
= Subject: Re: = [jose] DISCUSS: Nonce/Timestamp parameter
 
dick.hardt@gmail.com> = wrote:
I have an application for JWT that is not = OAuth2.
Having said that, nonce's are = difficult to implement at scale and I have heard of many sites that = don't implement them fully.
 
Nonce alone can't be implemented efficiently. =  You have to have time stamps as well, otherwise you are stuck = storing ever nonce you've ever seen, = forever.
Even = nonce + time stamp is challenging in distributed systems.  It adds = a lot of complexity.  That complexity is sometimes merited, but not = always.
________________________________= _______________
jose mailing list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_A963B36B-7FFA-4E87-B822-01B6A71DE2F8-- --Apple-Mail=_839AED85-2B44-4F3E-805C-E12482C609BC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy ODE0NDYxMlowIwYJKoZIhvcNAQkEMRYEFOphp3HVWSdK2hC2UKyqvf4VX1AcMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEemArLhYwwVrVbaxe1QI+F20TR464CWv71DK2gA1JeS48J7liVNL3lX2E4ig57pYIJk+xTzj7xC xswKc4gtd5NsbcrRFJeZbQbxKH9ZJXp3gZyB1I6cF3yHwpnIN2MVCTMiJRZJxJbX5zCvxXvAlPTi BZ9nD4MoO7BF4ge/i5OxR9SNE1AKhECrVPudpSMvX5Yw14VWDFs9A4jcgFAhaYtD7cBL61AYEEB8 fowDiKnIwz57PldoKbkzcDpCQQ9j3Nxjik0Gk+JnE9xhbLJP1OuKEf6iDym+eEZ2ApiRHM41G9Q/ 3hRt+ui+//ssr/0ukyjJ2mbS1HrtZrqPkQW7nCwAAAAAAAA= --Apple-Mail=_839AED85-2B44-4F3E-805C-E12482C609BC-- From bcampbell@pingidentity.com Tue Aug 28 08:00:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2611E808D for ; Tue, 28 Aug 2012 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4abYX0S5U0SM for ; Tue, 28 Aug 2012 08:00:57 -0700 (PDT) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id C730721F84EA for ; Tue, 28 Aug 2012 08:00:56 -0700 (PDT) Received: from mail-vb0-f50.google.com ([209.85.212.50]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUDzdKKV3v1+ayCKKB3aPGCj3lU2yn+Pb@postini.com; Tue, 28 Aug 2012 08:00:56 PDT Received: by vbal1 with SMTP id l1so7608175vba.23 for ; Tue, 28 Aug 2012 08:00:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=6l2SxVsL0q5LkBkZdd4Y4HB/KIPbT67wkhaMW8Q4ZEE=; b=eMY/77iMrza57QWqEe8acmZk4k1k9KyubZxaurTUxwMeZAr0NPIfrgdWRzhzFxQ+F8 8uXiJzF3d8DaR9LUa7jAC1wELfgI0NqIiyQnrWghX+bXTiyLwg3a0iGe+UV7OoDVHcar YTtfm/6CZa/2zYWYjSEdY5dUNHDI8FvsG5HskBFNv5t/Awo2Qu+2NRhkeBbViRNXJaLv YnP8JExlAXlQuXmxaaw0ySjftK+TAZu91jjGNht4LmUBbSRX77gW+xFiikWuatSipMzB bNhMsktr1DExfGZM0moqBVOOl/WeUoBIPwTtqTKxQPlqN7qpg5Rwjx498Lx0HEqr/rJK +BUw== Received: by 10.58.89.168 with SMTP id bp8mr16293149veb.20.1346166055347; Tue, 28 Aug 2012 08:00:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.66.228 with HTTP; Tue, 28 Aug 2012 08:00:25 -0700 (PDT) In-Reply-To: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> From: Brian Campbell Date: Tue, 28 Aug 2012 09:00:25 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b33c75089a4b304c854b568 X-Gm-Message-State: ALoCoQmJBvOZedqlg7dV1jj7V+N4IENGpBDijH1h6Td9Wf4288wcnI7NlBo54DvDa4DinpfEcUE4 Cc: jose@ietf.org Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:00:57 -0000 --047d7b33c75089a4b304c854b568 Content-Type: text/plain; charset=ISO-8859-1 no On Fri, Aug 17, 2012 at 1:05 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should support be mandated to allow an algorithm to be both a string and an > object > > Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", > "kid":"12345"} > > > Room vote: 1 yes, 5 no, 4 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --047d7b33c75089a4b304c854b568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable no

On Fri, Aug 17, 2012 at 1:05 AM, Jim S= chaad <ietf@augustcellars.com> wrote:
<CHAIR>

If you voted at the face-2-face please do not vote again. =A0If you want to=
provide comments please change the title from POLL to DISCUSS.

Should support be mandated to allow an algorithm to be both a string and an=
object

Example: =A0"alg":{"name":"EC-DH-SS", "r= andom":"XXXXX", "KDF":"CS256",
"kid":"12345"}


Room vote: =A01 yes, 5 no, 4 discuss


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

--047d7b33c75089a4b304c854b568-- From bcampbell@pingidentity.com Tue Aug 28 08:03:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0763111E80BF for ; Tue, 28 Aug 2012 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXUDhMjAZAb6 for ; Tue, 28 Aug 2012 08:03:06 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id CB1EB11E80D7 for ; Tue, 28 Aug 2012 08:03:05 -0700 (PDT) Received: from mail-vb0-f53.google.com ([209.85.212.53]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUDzdqaIpPXkD4v8A8qREgh4+T3kvf2RB@postini.com; Tue, 28 Aug 2012 08:03:05 PDT Received: by vbbfc26 with SMTP id fc26so6808536vbb.12 for ; Tue, 28 Aug 2012 08:03:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=XP5fYf6vGdLd9turRw39/ModP7PptNy8qm7UzO+aWs0=; b=YXZrWlg0QnOjpwmZIzjfhP2DEXR38xvwXbrVqWhIlPaNHp8iMmo2oWfLfLVf9hE1At kJ7mu6/qs6k4b6+LWOFqqydiMaCI73vOXJA2EZFk9UHnHmccygKfhyxXVPVeYCx4IABd 71yLDswZ6jW/s58JzV1Kj0ZshbTfZSiXYyuIVtm7P3fb/pJXLojvFW0PA5aC7RPMYbPT HGDRsLaeVemeuw/BO6Q7e1XO+DP3WTYsqdmRdI7GRPeQkQR/5JwLYiT8F6rmZbHqsi/L 5v3UNla5zKm4tB7PwTImw0giuFDIo8Z7nGeWJ/ieWcoNWn2qk7Zqt/nL8xVVt3NmWcBL Ou4Q== Received: by 10.220.225.194 with SMTP id it2mr14912345vcb.32.1346166184683; Tue, 28 Aug 2012 08:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.66.228 with HTTP; Tue, 28 Aug 2012 08:02:34 -0700 (PDT) In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> From: Brian Campbell Date: Tue, 28 Aug 2012 09:02:34 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=14dae9ccd5103f29cc04c854bdc0 X-Gm-Message-State: ALoCoQmBgv1PHgjI1uPjqIoRy3qugPcfvgRwpGCEbP/PNumwXNT6EyUVdSnCdCLxkkLgYbstz87s Cc: jose@ietf.org Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:03:07 -0000 --14dae9ccd5103f29cc04c854bdc0 Content-Type: text/plain; charset=ISO-8859-1 no On Fri, Aug 17, 2012 at 1:06 AM, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we add the ability to have a randomly generated MAC key protected by > a different key? The other key could be either a pre-shared symmetric key > or a public key. > > > > Room vote: 3 yes, 5 no, 3 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --14dae9ccd5103f29cc04c854bdc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable no

On Fri, Aug 17, 2012 at 1:06 AM, Jim S= chaad <jimsch@augustcellars.com> wrote:
<CHAIR>

If you voted at the face-2-face please do not vote again. =A0If you want to=
provide comments please change the title from POLL to DISCUSS.

Should we add the ability to have a randomly generated MAC key protected by=
a different key? =A0The other key could be either a pre-shared symmetric ke= y
or a public key.



Room vote: =A03 yes, 5 no, 3 discuss


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

--14dae9ccd5103f29cc04c854bdc0-- From ve7jtb@ve7jtb.com Tue Aug 28 08:09:19 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDFA11E80F6 for ; Tue, 28 Aug 2012 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK4OrG6rEMA2 for ; Tue, 28 Aug 2012 08:09:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 466DF11E80F7 for ; Tue, 28 Aug 2012 08:09:18 -0700 (PDT) Received: by qcac10 with SMTP id c10so4018253qca.31 for ; Tue, 28 Aug 2012 08:09:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=K1L8KYSXvjzUiLx9k1+tO5oGyinXZN8BFWnf16trzD0=; b=dkD6RCGZmN9tQ6M4u3svB4w3N3Wz+3X8pEpBsV94BSFaRbfVggaa1a3vUUhVi3sPBb LywZt3wAdB+7wtANxkJ8p2sZl3BLJabgnYPUCwgQVvZd86yEpjcgDxL2OLhjdkTq+7Gg hDTrDNGN9z3EmsrVYOtWUUwrMAaRJFyoOszMj1otpqlrDWia16i5IRNT6PVD5RJKYiy0 lHyEX15jxJZOHSnCGgXkqXYx+4D6cOI9LCDxHcJK1eMbCBSpFJW5ehWHPDy9+jISnK9q PkveCURFEYt4OWDn4OHduJThTykqL82sqa47MRbtpdn5NdagCvczgWnIqLYQX8c7eg5B H6OA== Received: by 10.224.53.4 with SMTP id k4mr13931734qag.32.1346166557182; Tue, 28 Aug 2012 08:09:17 -0700 (PDT) Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id gd3sm12248941qab.13.2012.08.28.08.09.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 08:09:15 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6ED0C75A-1A0D-4CE5-8A9E-4E31AB188085"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <503CD692.4020007@mitre.org> Date: Tue, 28 Aug 2012 11:09:07 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503CD692.4020007@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQnCwrUvvbzEFCXXvNoyExG7mJ6qmKYrpRvPuHq5NREr+cOSDDvQbrkR3bYWVVB6rfgeAybs Cc: Axel Nennker , Mike Jones , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:09:19 -0000 --Apple-Mail=_6ED0C75A-1A0D-4CE5-8A9E-4E31AB188085 Content-Type: multipart/alternative; boundary="Apple-Mail=_60255DDB-7CDF-4EDA-9844-3E2D3E810131" --Apple-Mail=_60255DDB-7CDF-4EDA-9844-3E2D3E810131 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 In OAuth 2 state gets overloaded with a bunch of things from preventing = XSRF to providing a handle to look up who the the authorization request = was sent to. In Connect we added a nonce sent by client that is returned inside the = signed id_token (JWT) to allow the client to detect replay, and = optionally reference a specific browser session that presents the = id_token. The nonce I suggested for JOSE is not ether of those. =20 I used nonce in the sense that it is used with stream cyphers when the = same key is used over multiple messages. JOSE will be used for more than OAuth and JWT. There are cases where = adding entropy to the header will be a security benefit. I would like = to have a standard claim for doing that. If people want to call it something else that is fine, but it is a nonce = by definition. If used it should be a random or pseudo random value that is time = variant with sufficient granularity to ensure a nonce is used only once. John B. On 2012-08-28, at 10:32 AM, Justin Richer wrote: > On 08/25/2012 03:37 AM, Axel Nennker wrote: >> To clarify: What is the base specification that Jim mentioned?=20 >> Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 = ? >>=20 >> Would somebody please present a use-case for either nonce or = timestamp? >> If a jwt is used with oauth2 then what is the difference between = nonce and state? Nonce would be signed while state is not? >>=20 >=20 > Nonce would generally be generated by the entity creating the token. = State in OAuth is generated by the client, and would only be protected = if the client had a means to make a signed request to the server, using = either a MAC binding or a JWT-based OIDC-style RequestObject. >=20 > -- Justin >=20 >> I guess I am missing some information that those in the room who = voted "yes" had? >>=20 >> Axel >>=20 >> 2012/8/25 Mike Jones >> I'll note for discussion purposes that a nonce and a timestamp are = not the same thing (although sometimes they are used to achieve = similar/related goals). A nonce tends to be an opaque value that must = be preserved across the communication. Whereas a timestamp typically = has defined semantics - sometimes simply a non-decreasing integer value = - and sometimes a representation of time, and then, sometimes with a = uniqueness requirement. >>=20 >> For discussion purposes, I'll say that the simplest thing for us to = do (should we decide to do anything in this regard) would be to define = the nonce as an opaque string value that must be preserved. >>=20 >> We could also define a timestamp parameter, but as I wrote above, = that would likely require us to specify additional semantics - starting = with whether it's a non-decreasing integer or a representation of a time = value. This seems much harder to define and possibly to use than a = nonce. >>=20 >> Would it make sense to define a nonce parameter now and hold off on = defining a timestamp parameter until there's a clear demonstrated use = case for which a nonce is not sufficient? That would be my personal = recommendation. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Jim Schaad >> Sent: Friday, August 17, 2012 12:05 AM >> To: jose@ietf.org >> Subject: [jose] POLL: Nonce/Timestamp parameter >>=20 >> >>=20 >> If you voted at the face-2-face please do not vote again. If you = want to provide comments please change the title from POLL to DISCUSS. >>=20 >> Do we need to define a nonce/timestamp parameter in the base = specification? >>=20 >>=20 >>=20 >> Room vote: 6 yes, 0 no, 1 discuss >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_60255DDB-7CDF-4EDA-9844-3E2D3E810131 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 In = OAuth 2 state gets overloaded with a bunch of things from preventing = XSRF to providing a handle to look up who the the authorization request = was sent to.

In Connect we added a nonce sent by = client that is returned inside the signed id_token (JWT) to allow the = client to detect replay, and optionally reference a specific browser = session that presents the id_token.

The nonce I = suggested for JOSE is not ether of those. =  

I used nonce in the sense that it is = used with stream cyphers when the same key is used over multiple = messages.

JOSE will be used for more than OAuth = and JWT.   There are cases where adding entropy to the header will = be a security benefit.  I would like to have a standard claim for = doing that.
If people want to call it something else that is = fine, but it is a nonce by definition.
If used it should be a = random or pseudo random value that is time variant with sufficient = granularity to ensure a nonce is used only = once.

John = B.

On 2012-08-28, at 10:32 AM, Justin = Richer <jricher@mitre.org> = wrote:

=20 =20
On 08/25/2012 03:37 AM, Axel Nennker wrote:
To clarify: What is the base specification that Jim mentioned? =
Is it: htt= p://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?

Would somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?


Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.

 -- Justin

I guess I am missing some information that those in the room who voted "yes" had?

Axel

2012/8/25 Mike Jones <Michael.Jones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestamp are not the same thing (although sometimes they are used to achieve similar/related goals).  A nonce tends to be an = opaque value that must be preserved across the communication.  Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value.  This seems = much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient?  That would be my personal recommendation.

                  =               Best wishes,
                  =               -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.org
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again. =  If you want to provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?



Room vote:  6 yes, 0 no, 1 discuss


_______________________________________________
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



_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/m=
ailman/listinfo/jose

_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_60255DDB-7CDF-4EDA-9844-3E2D3E810131-- --Apple-Mail=_6ED0C75A-1A0D-4CE5-8A9E-4E31AB188085 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy ODE1MDkwN1owIwYJKoZIhvcNAQkEMRYEFBFWANsrJMWsZm0LDhUbF0q3w1L9MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACvVPAkRgtLsI4OFXyjn9IVV0DnCvERDM20YSK1sqYFCdFBD9bGdukph9X+IJry2Y5ETkzl16CFX 3ZXCc8FmfhBHeGPT4Loe0zMnANvMRUir0jO3phrSzLU7pNGx9VIAzS7/8sbItl2gZao1jcU90V3n P6ePnqmqhGpds4TwGNr0y6qfqbwPgxsSWR5rUn99ECidPdFLaNS6hrAqrNA5Vu95Z7q0vKaVDoDv 6JmvAVkprBqXfHG2+mrrVeRNQ278Et0NB+h6E04l/lpLvSCFjD8bH4VJrmoJ1IvC2+4VQcZvgNFb Q1cRvs7B5jaIFv13HbEyl4txtzebYdm6X23cTFEAAAAAAAA= --Apple-Mail=_6ED0C75A-1A0D-4CE5-8A9E-4E31AB188085-- From torsten@lodderstedt.net Tue Aug 28 09:50:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C444E21F8596 for ; Tue, 28 Aug 2012 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1utybpTLFjf for ; Tue, 28 Aug 2012 09:50:34 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7D63121F8593 for ; Tue, 28 Aug 2012 09:50:34 -0700 (PDT) Received: from [91.2.87.202] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T6Ozo-00064t-MS; Tue, 28 Aug 2012 18:50:32 +0200 Message-ID: <503CF6D6.1030309@lodderstedt.net> Date: Tue, 28 Aug 2012 18:50:30 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "HAYASHI, Tatsuya" References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: jose@ietf.org Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:50:36 -0000 NO Am 28.08.2012 08:54, schrieb HAYASHI, Tatsuya: > NO > > On Mon, Aug 27, 2012 at 5:18 PM, wrote: >> NO >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Friday, August 17, 2012 9:07 AM >> To: jose@ietf.org >> Subject: [jose] POLL: Add other than pre-shared MAC key >> >> >> >> If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. >> >> Should we add the ability to have a randomly generated MAC key protected by a different key? The other key could be either a pre-shared symmetric key or a public key. >> >> >> >> Room vote: 3 yes, 5 no, 3 discuss >> >> >> _______________________________________________ >> 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 > > From torsten@lodderstedt.net Tue Aug 28 09:51:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC421F8596 for ; Tue, 28 Aug 2012 09:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GeRhkVGCQ6T for ; Tue, 28 Aug 2012 09:51:24 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 425AD21F858F for ; Tue, 28 Aug 2012 09:51:24 -0700 (PDT) Received: from [91.2.87.202] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T6P0c-00049Z-GZ; Tue, 28 Aug 2012 18:51:22 +0200 Message-ID: <503CF708.5050902@lodderstedt.net> Date: Tue, 28 Aug 2012 18:51:20 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Breno de Medeiros References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090902090405070907030202" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "HAYASHI, Tatsuya" , jose@ietf.org Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:51:26 -0000 This is a multi-part message in MIME format. --------------090902090405070907030202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit YES Am 28.08.2012 15:45, schrieb Breno de Medeiros: > > YES > > On Aug 27, 2012 11:55 PM, "HAYASHI, Tatsuya" > wrote: > > YES > > On Mon, Aug 27, 2012 at 5:15 PM, > wrote: > > YES > > > > -----Original Message----- > > From: jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org ] On > Behalf Of Jim Schaad > > Sent: Friday, August 17, 2012 9:05 AM > > To: jose@ietf.org > > Subject: [jose] POLL: Is KID sufficently defined > > > > > > > > If you voted at the face-2-face please do not vote again. If > you want to provide comments please change the title from POLL to > DISCUSS. > > > > Is the current text for KID sufficiently defined and understood? > > > > > > Room vote: 2 yes, 0 no, 1 discuss > > > > > > _______________________________________________ > > 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 > > > > -- > HAYASHI, Tatsuya > Lepidum Co. Ltd. > _______________________________________________ > 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 --------------090902090405070907030202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit YES
Am 28.08.2012 15:45, schrieb Breno de Medeiros:

YES

On Aug 27, 2012 11:55 PM, "HAYASHI, Tatsuya" <lef.mutualauth@gmail.com> wrote:
YES

On Mon, Aug 27, 2012 at 5:15 PM,  <Axel.Nennker@telekom.de> wrote:
> YES
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
> Sent: Friday, August 17, 2012 9:05 AM
> To: jose@ietf.org
> Subject: [jose] POLL: Is KID sufficently defined
>
> <CHAIR>
>
> If you voted at the face-2-face please do not vote again.  If you want to provide comments please change the title from POLL to DISCUSS.
>
> Is the current text for KID sufficiently defined and understood?
>
>
> Room vote:  2 yes, 0 no, 1 discuss
>
>
> _______________________________________________
> 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



--
HAYASHI, Tatsuya
Lepidum Co. Ltd.
_______________________________________________
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

--------------090902090405070907030202-- From torsten@lodderstedt.net Tue Aug 28 09:51:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AE121F8593 for ; Tue, 28 Aug 2012 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIIBn-J1zXup for ; Tue, 28 Aug 2012 09:51:49 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2814C21F858F for ; Tue, 28 Aug 2012 09:51:49 -0700 (PDT) Received: from [91.2.87.202] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T6P10-0003oH-0C; Tue, 28 Aug 2012 18:51:46 +0200 Message-ID: <503CF720.8090603@lodderstedt.net> Date: Tue, 28 Aug 2012 18:51:44 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Axel.Nennker@telekom.de References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: ietf@augustcellars.com, jose@ietf.org Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:51:52 -0000 YES Am 27.08.2012 10:16, schrieb Axel.Nennker@telekom.de: > YES > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Criticality of understanding header fields > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > What should be the criticality of header fields as defined by the core specification? > > YES - all headers fields are critical > NO - all header fields are non-critical > MAYBE - header fields are marked critical or criticality should be defined by the application DISCUSS - need to talk more > > Room vote: 2 yes, 0 no, 4 maybe, 3 discuss > > > > _______________________________________________ > 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 From torsten@lodderstedt.net Tue Aug 28 09:52:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A317321F859F for ; Tue, 28 Aug 2012 09:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GStndN+HI0+s for ; Tue, 28 Aug 2012 09:52:01 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by ietfa.amsl.com (Postfix) with ESMTP id F0E4A21F858F for ; Tue, 28 Aug 2012 09:52:00 -0700 (PDT) Received: from [91.2.87.202] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T6P1A-00076m-UJ; Tue, 28 Aug 2012 18:51:56 +0200 Message-ID: <503CF72B.5060308@lodderstedt.net> Date: Tue, 28 Aug 2012 18:51:55 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Axel.Nennker@telekom.de References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: ietf@augustcellars.com, jose@ietf.org Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:52:01 -0000 NO Am 27.08.2012 10:21, schrieb Axel.Nennker@telekom.de: > NO > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:08 AM > To: jose@ietf.org > Subject: [jose] POLL: Non AEAD algorithms as a single name > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a single content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} > New: {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ > 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 From torsten@lodderstedt.net Tue Aug 28 09:52:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A9121F85DA for ; Tue, 28 Aug 2012 09:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m44MryYgqmDs for ; Tue, 28 Aug 2012 09:52:13 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by ietfa.amsl.com (Postfix) with ESMTP id A4E3021F858F for ; Tue, 28 Aug 2012 09:52:11 -0700 (PDT) Received: from [91.2.87.202] (helo=[192.168.71.42]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T6P1O-0004el-2b; Tue, 28 Aug 2012 18:52:10 +0200 Message-ID: <503CF738.1020800@lodderstedt.net> Date: Tue, 28 Aug 2012 18:52:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Axel.Nennker@telekom.de References: <008b01cd7c46$fda69480$f8f3bd80$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: ietf@augustcellars.com, jose@ietf.org Subject: Re: [jose] POLL: Remove no key wrap for key agreement algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:52:14 -0000 NO Am 27.08.2012 10:24, schrieb Axel.Nennker@telekom.de: > NO > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 17, 2012 9:08 AM > To: jose@ietf.org > Subject: [jose] POLL: Remove no key wrap for key agreement algorithms > > > > If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. > > Should we remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step? > > This would remove the ability to go directly and would require an intervening key wrap step. > > Room vote: 1 yes, 6 no, 0 discuss > > > _______________________________________________ > 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 From ejay@mgi1.com Tue Aug 28 10:46:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405FB21F85B8 for ; Tue, 28 Aug 2012 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qpy1UoZkcSwa for ; Tue, 28 Aug 2012 10:46:32 -0700 (PDT) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by ietfa.amsl.com (Postfix) with SMTP id A1DA121F85AC for ; Tue, 28 Aug 2012 10:46:32 -0700 (PDT) Received: from [98.139.52.189] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:46:27 -0000 Received: from [66.94.237.105] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:46:27 -0000 Received: from [127.0.0.1] by omp1010.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:46:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 30483.85876.bm@omp1010.access.mail.mud.yahoo.com Received: (qmail 16520 invoked by uid 60001); 28 Aug 2012 17:46:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346175986; bh=sbPsNgmqH55EH4ohXbhQog9OW/NOztLhp2e5t/CvwuQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rhvjXmFf8Yv/AsCouzWBpIBkKjz74GJJQBMHau3O28ateg67hv6Ht1+sUoUFetybML4vgiFcdQC1I2RT40t/W6AimyXQbxUpRVf4C7AoZsugGr1JqOb45WcpYTZ2bQmHZGENkdGvkuNb2Ss4vucwpiiEAwcSiKKPy2XHl6VDU/0= X-YMail-OSG: 8eiWqmgVM1lIeFCtv9Vh2OpErCJaHX8UTICQzG0FOBDw0yo En9EWISn.rpXwQVgLlkwDSrVQzxaJQGxjMCofAqfTC2OvsH.KIXBLKqhAHi0 bM21DI_5J3.VyzT4VFi9YseoD7gUtik0d8PYZyXvQ9UnXpNE1hl2FUZFchL8 jSZWUGhodovPam2IVJMG0YQWLXX9Cwd1.f3tms7JidFVHRQJsXo3dWJDz2fV k2Ph2fCCCkkbKXDySMbzwZeUyRAaZJoPnugbFrsX0hJikcjpYBPqfZl85.NK ..rs4ThPWYuYLp0338Fynhx2i5tz3kUNOc1ybBNVJOCGQTm41j_2f85VMhpZ 9bsAaxxwQX.xkCb33cBi0HzsSgKhrkueuSl6r9eRT1y2lSUdTh2az.qdQ3q1 r19UbwJ3dZiGGFHCQ0YrsFmi9Xv6NbevmRmnkxHW0imREB2gVILaRWgNglrO L8atl4eiuRNBXENK60qxt9aKGhQ3250ebM3i9yQWr8EUN5qH0YOEOD9DHodY - Received: from [64.140.94.67] by web184402.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:46:26 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> Message-ID: <1346175986.12437.YahooMailRC@web184402.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:46:26 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-334495122-1378672979-1346175986=:12437" Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:46:33 -0000 ---334495122-1378672979-1346175986=:12437 Content-Type: text/plain; charset=us-ascii YES ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:07:30 AM Subject: [jose] POLL: Is KID sufficently defined If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Is the current text for KID sufficiently defined and understood? Room vote: 2 yes, 0 no, 1 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---334495122-1378672979-1346175986=:12437 Content-Type: text/html; charset=us-ascii
YES

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:07:30 AM
Subject: [jose] POLL: Is KID sufficently defined

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Is the current text for KID sufficiently defined and understood?


Room vote:  2 yes, 0 no, 1 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---334495122-1378672979-1346175986=:12437-- From ejay@mgi1.com Tue Aug 28 10:47:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ED221F85B4 for ; Tue, 28 Aug 2012 10:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sE+iz5jOlhU for ; Tue, 28 Aug 2012 10:47:13 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id 150FC21F85AC for ; Tue, 28 Aug 2012 10:47:13 -0700 (PDT) Received: from [98.139.52.194] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:47:07 -0000 Received: from [66.94.237.101] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:47:07 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:47:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 522351.86816.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 95462 invoked by uid 60001); 28 Aug 2012 17:47:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346176027; bh=LurHPor6YT3/+rrpyyQfhmSPRbBdZRU93IEXiJLQVnE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CMZXELYt10XZXFCMeC0NezBGJix83J8J+46aNPz47gpDrENBMaT5Tst+sJ8JOlILIyS59U+0U190Ljs9h5ffIGkUnoVnG4rZotTHejHZbYk9InVxMztruHsJjlVoVeKXomtPqBrskELn31yr3His3PD7otqlpXukD6VWUhu62nY= X-YMail-OSG: G4s6vZMVM1lrqa2MuxrcqBf3kCBBh_mt1vHYJraQ81O_V0d mAfqS4j0cPutJ50q0mAyoNeVwUu7WQmoqoss3yBM07FxRYW7ZwIEspeprkTS Sy.6HmIG8xK1DPsibbwqWfB4dNSwyPXIq2wskxcS6rFV71o92VZHnObeCHbr px5CP613Q7TBaB1a3oaRSFowTxwJEMtMU4boj9FmJOl9iMH6rRiRhjsI2onf RCXHNmx3yFQaO12mZ7AJrdZky5hcrz4Mg6S6IEle8m0VyTGwi0clxNuCjeWK KehswEV9LR22CWbdj.XFY34Q334huhU06n.kM0jpLJDRxhcwyTcHb0fUWnjQ DEDBqdc3tvUYzByN5rr7J1xDQ_AcMMreDUHxbdgfdU5_53OrOxSkNG_.BmDl j.vevBTEhLkqOavamm4ll6HMZouIYrwrRMwVxuFUXjZNuia2XEIp6W8IN2Dp YBpZKoIV83OJ8ckaT1XPV4hoIFtBrEI45al1YPKyDfGXXVZoAUWhZjUD1zg- - Received: from [64.140.94.67] by web184404.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:47:07 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> Message-ID: <1346176027.93335.YahooMailRC@web184404.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:47:07 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-420974808-1965604110-1346176027=:93335" Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:47:13 -0000 ---420974808-1965604110-1346176027=:93335 Content-Type: text/plain; charset=us-ascii YES ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:07:40 AM Subject: [jose] POLL: Criticality of understanding header fields If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. What should be the criticality of header fields as defined by the core specification? YES - all headers fields are critical NO - all header fields are non-critical MAYBE - header fields are marked critical or criticality should be defined by the application DISCUSS - need to talk more Room vote: 2 yes, 0 no, 4 maybe, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---420974808-1965604110-1346176027=:93335 Content-Type: text/html; charset=us-ascii
YES

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:07:40 AM
Subject: [jose] POLL: Criticality of understanding header fields

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

What should be the criticality of header fields as defined by the core
specification?

YES - all headers fields are critical
NO - all header fields are non-critical
MAYBE - header fields are marked critical or criticality should be defined
by the application
DISCUSS - need to talk more

Room vote:  2 yes, 0 no, 4 maybe, 3 discuss



_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---420974808-1965604110-1346176027=:93335-- From ejay@mgi1.com Tue Aug 28 10:47:42 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7521F8595 for ; Tue, 28 Aug 2012 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGH0tMaaPum1 for ; Tue, 28 Aug 2012 10:47:42 -0700 (PDT) Received: from nm2.bullet.mail.ne1.yahoo.com (nm2.bullet.mail.ne1.yahoo.com [98.138.90.65]) by ietfa.amsl.com (Postfix) with SMTP id 4570F21F853D for ; Tue, 28 Aug 2012 10:47:42 -0700 (PDT) Received: from [98.138.226.176] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 28 Aug 2012 17:47:36 -0000 Received: from [66.94.237.101] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 28 Aug 2012 17:47:36 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:47:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 607593.32725.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 93980 invoked by uid 60001); 28 Aug 2012 17:47:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346176056; bh=eD8Ne/M46LCWLztijJ41y23ogp5m4lckwTFn2TyYK2k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=vuOcJJc6/dVsHqBOQ5rZ24p0axiE3TId8tmwPMrlNwt9JV+rfTlDAIjB+dsNyzAXM4+juQVAjvWeDxUmISQrfiwRf9X9TP78BeIDBrUD9IuXZ/rCljVOjiNxB8aYcjyPCQU5yy9Sf/KfBZ3K7okqeRBHUs8AGNDPCAxa+aZo3gM= X-YMail-OSG: BOB30uYVM1k5ieQ6Du6GLXVb3iHUF5OOTlrJ1sb0vlWkS2J MQgmoY5jKwq66ZcWvPX35gLHWt5E_.aa3fe5PmQqLqIX.l7ecJ7KoZeQCoii 7xsd7H6Ck2dufgKMZJzoc0ActS7v4arHStpc6_11ltdcB7J0VWVafXeMRzIf G1c_f6Jvsb.dbIGLGTbBPR0QjOUlPV.xJJ2qYBzDOvH0gl.86.Dlo_XSzRpr 1BKNcsVxQimev.Td_kQIu5.k385J519_VtY_p5XAUC4COlXqVlnXlz.603fl zs77.PFkyFJYPHAiFEnEYMP4UeB662TQuvLzfaZByXIrn.d0pwJgdxV7UA1e cJNSJ4JxmzkYh7z71yXKONgmqvVGidbowFAa_Z8R.0GQnnu7BYY_sI8XQ.BR mAtZqJkCHzo_c.bCF4uwxtnLGXzgL3LTDyVcZP7v8PB5PrtM0IHXbzI6q0y. g2T_KgOuVpZP4Na4OCAXJRN7oRjjy_p9mPPNYJZtDtQMt81.UJyIW4rRtrA- - Received: from [64.140.94.67] by web184401.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:47:36 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> Message-ID: <1346176056.70860.YahooMailRC@web184401.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:47:36 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1009959307-1109433895-1346176056=:70860" Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:47:43 -0000 --1009959307-1109433895-1346176056=:70860 Content-Type: text/plain; charset=us-ascii NO ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:07:38 AM Subject: [jose] POLL: Support Multiple types for algorithms If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should support be mandated to allow an algorithm to be both a string and an object Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"} Room vote: 1 yes, 5 no, 4 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --1009959307-1109433895-1346176056=:70860 Content-Type: text/html; charset=us-ascii
NO

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:07:38 AM
Subject: [jose] POLL: Support Multiple types for algorithms

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Should support be mandated to allow an algorithm to be both a string and an
object

Example:  "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256",
"kid":"12345"}


Room vote:  1 yes, 5 no, 4 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--1009959307-1109433895-1346176056=:70860-- From ejay@mgi1.com Tue Aug 28 10:48:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8796521F8597 for ; Tue, 28 Aug 2012 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV7UvZfePdTz for ; Tue, 28 Aug 2012 10:48:53 -0700 (PDT) Received: from nm25-vm0.bullet.mail.ac4.yahoo.com (nm25-vm0.bullet.mail.ac4.yahoo.com [98.139.52.240]) by ietfa.amsl.com (Postfix) with SMTP id D9B7121F8595 for ; Tue, 28 Aug 2012 10:48:52 -0700 (PDT) Received: from [98.139.52.189] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:48:49 -0000 Received: from [66.94.237.116] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:48:49 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:48:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 783036.83962.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 97553 invoked by uid 60001); 28 Aug 2012 17:48:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346176129; bh=sUzx5/A8RSkdKqCeHN60PxtR4Wi2Z5Z4/I195BeR2xA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=voxItBE5op+ldZkifLb9J52hEXkW5MyPbgv0nCqM7M8sG/oCmz6aLiOW+VpFd9/Wg3zEDK7IdUJWFXE2GeNE7aGwmvcfa+nYlIGFAhzBBjRuB2mR0/bR8f3U4zIyrQmjwMhxarGGndgEBVTsEuetFxHBOJoB6a1/aYUWVrb9ws0= X-YMail-OSG: 3lJwdYMVM1kS2OjuMb0F8G5bA_B5aiPvFgXMsr4Pv9T3GT. kVJeRKcmcbR.hvzt6h8iJjQ1b6YpnvDqg0tJ1VkNv2PdVnouY7j3sO5I5M4j j066NnVWVGPwsU_.ru2NkuMDxQCeiVzAocGyKBmnK.qYlaE_HuLSuXxChA1f u9C2k0oouZoXgN9HQVf5wJY8BBSQFktQp.s7J5qnAjGU4XqtRQhd2GW6ut2r n0pS6C_hpWXD1lM7Nx9akA0F3Pvvwai1i_yxltM3tlTiIRhOT4Sej1dz5OVM OLvyxne3V_YjlFigYi0GI2A3TOSsHvmL8lh.uKtBVlGfnUq82yvX0oBaE.CV 24AJnj6FdsfX6lwL0axOxk0VQVnPHQYvU1LC5ACDZEomTVKSKGNeMFxK4BQ7 PR9zJ_KIayh4IHiZvWlkpjIUhwsQRP8pH_dcLqnZ0ORhFHB7WPNuAsdSO16P 3gARexRYRo5veQreZFX6bO6I3vaE54Pq5cQbxx95xugwd8tvIo03EsP1sipQ m Received: from [64.140.94.67] by web184404.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:48:49 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> Message-ID: <1346176129.74210.YahooMailRC@web184404.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:48:49 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-420974808-920995736-1346176129=:74210" Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:48:53 -0000 ---420974808-920995736-1346176129=:74210 Content-Type: text/plain; charset=us-ascii NO ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:08:06 AM Subject: [jose] POLL: Add other than pre-shared MAC key If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we add the ability to have a randomly generated MAC key protected by a different key? The other key could be either a pre-shared symmetric key or a public key. Room vote: 3 yes, 5 no, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---420974808-920995736-1346176129=:74210 Content-Type: text/html; charset=us-ascii
NO

From: Jim Schaad <jimsch@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:08:06 AM
Subject: [jose] POLL: Add other than pre-shared MAC key

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Should we add the ability to have a randomly generated MAC key protected by
a different key?  The other key could be either a pre-shared symmetric key
or a public key.



Room vote:  3 yes, 5 no, 3 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---420974808-920995736-1346176129=:74210-- From ejay@mgi1.com Tue Aug 28 10:52:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315D621F8464 for ; Tue, 28 Aug 2012 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL3XOpgvxjMG for ; Tue, 28 Aug 2012 10:52:46 -0700 (PDT) Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by ietfa.amsl.com (Postfix) with SMTP id 116EF21F84A5 for ; Tue, 28 Aug 2012 10:52:42 -0700 (PDT) Received: from [98.139.91.66] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 28 Aug 2012 17:52:38 -0000 Received: from [66.94.237.123] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 28 Aug 2012 17:52:38 -0000 Received: from [127.0.0.1] by omp1028.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:52:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 31269.67978.bm@omp1028.access.mail.mud.yahoo.com Received: (qmail 1792 invoked by uid 60001); 28 Aug 2012 17:52:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346176357; bh=itJ4oeDtyICwBfcExyJ/U7XcR1BxGUHUpaXG+DRjm2I=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=oxxgRgmSWw6zUYQCbW/GQTkehnSydQUOpN/Twn8YtrvgCT4Z8az0PN8M6/WhEO+TZ5KY6sfAXjJnIeZsjxMpIwkzM5RQ2jRzs0M9logBee45oMUHmz/+CJDYQ5Hqkrqr6ydMhpuSGf0t2o+KIeXxKXVaGmZYOHe0jaQCwb62iBw= X-YMail-OSG: XvjE9zoVM1lLeb1pgkvcX5SAgQRWYoYUKNAJdWkGwfqWIKs wNNMq44mCjlBGL3qzqzC9MldRjywYTFeZCe93uqco93cy8pmKrZwzWnWWOOc dWipgOdTG_et48oSOavPafjh6Z8SOivFHLNSLjXaRfs7ZPLLBE959fgHvleE _JKptIjTdaGSeUd7hwSzvwadgBfJeKxCge4kiU.W0c8REJBiPtBn8iPYJrOX BAR.dTJg.935g7u.s1PAsCcawM7VW5U5H5OZ58fyUIc76zSo3uS4t0FwP4Xu mGjIL7QkQFl5Y2lTVEUaLWQwsoH.DH4gLXMQVm991s0kwX_n.AcKtdWKlqX6 2KKbfTh43wYTWSpbMDyG7JXTIfgJuWGFGZjLADTXSLIGY3px9IfNWOA5BhIr ggxXmzvB1btAmulFs7CyItwv94K2Jym.Up21.bpTYu00cZLrAmoUO.NrOqQA 6X2WhBkwY5SQ94UJ87dFT3x_D7wC0PQSXU5_T5RggalgGTPdMMM8pXYFfKN5 N Received: from [64.140.94.67] by web184404.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:52:37 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> Message-ID: <1346176357.33556.YahooMailRC@web184404.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:52:37 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-420974808-1225200955-1346176357=:33556" Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:52:48 -0000 ---420974808-1225200955-1346176357=:33556 Content-Type: text/plain; charset=us-ascii NO ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:09:15 AM Subject: [jose] POLL: Non AEAD algorithms as a single name If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we change the current treatment of AES-CBC + HMAC to use a single content encryption name. Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: {"enc":"AES128CBC+HS256+CS256"} Exact name is still to be determined Room vote: 12 yes, 2 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---420974808-1225200955-1346176357=:33556 Content-Type: text/html; charset=us-ascii
NO

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:09:15 AM
Subject: [jose] POLL: Non AEAD algorithms as a single name

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Should we change the current treatment of AES-CBC + HMAC to use a single
content encryption name.

Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"}
New: {"enc":"AES128CBC+HS256+CS256"}

Exact name is still to be determined

Room vote:  12 yes, 2 no, 0 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---420974808-1225200955-1346176357=:33556-- From ejay@mgi1.com Tue Aug 28 10:53:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C321F84A5 for ; Tue, 28 Aug 2012 10:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYbOs3d12OMT for ; Tue, 28 Aug 2012 10:53:32 -0700 (PDT) Received: from nm25.bullet.mail.ac4.yahoo.com (nm25.bullet.mail.ac4.yahoo.com [98.139.52.222]) by ietfa.amsl.com (Postfix) with SMTP id 0734921F8498 for ; Tue, 28 Aug 2012 10:53:31 -0700 (PDT) Received: from [98.139.52.193] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:53:28 -0000 Received: from [66.94.237.110] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 28 Aug 2012 17:53:28 -0000 Received: from [127.0.0.1] by omp1015.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:53:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 107458.99819.bm@omp1015.access.mail.mud.yahoo.com Received: (qmail 49545 invoked by uid 60001); 28 Aug 2012 17:53:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346176407; bh=U7jbamtq3k2qe0wni2ElqW4dbXPbBLdc9RFwNmbQVlE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CrF4AMtdK2bFMfdkV+jm+ZfGh52WAz5JTkfckNWieXAc92zLTq7WHbGPTm84H+AIY/JfxVjMny2qd2StHKGSxoaWD+EZXGnPVAkt51lhrhSaEjgHY/8R79oxjHQvmovYItfQdxnyL0JnY+2UhuZ8oESdjLbamNXBre/cumSVdxM= X-YMail-OSG: nkrOboYVM1nPmZff.gOSBWL3oud0hkERl7QHougDYGdXp_7 Sw5n454Qf3Bu2_XmpIcneDzssLHlXYtsh8OmaRz3VLDQHss2Q0kuUhyXkQiQ j1P4v_iWDB8wBAObjUPlNbF4_YM5Az_KFMKxF6kXjy9DtWGyy5JZIHkjeF5W YGyYboQiz5IJuhtCN.f_zJgIYG6Ra._pJkBgrKbYl8ZdPrlxEtKQszHLZ9Bf mdjhcG6VmKrROiTHW23PwrDsBDkPu_orgrnmtfAUeYVOfslp9HTCUZG5WvGK fI4s9UYiO5ielKsMsFE20B18Kheurqudod9SoNqmI4yYJhyEcExPMkgXjEeS 4Mob5TPl_Sj5MwywcVR8JnmLZc4OE.7XGTnhzxjRCNmE2qGmjVP6a8kYXHwY jZj85yt8D8SdUHyjB6325qf.NGE2zK0kGJGGdMvbTX58nIBhfHjzk.wnxokN FWgKR94KyzVf6b89Zca1hk4NBzBuu5KQz0dNtIbeDf88AkHv9seQWgpfec_Q - Received: from [64.140.94.67] by web184406.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:53:27 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <008b01cd7c46$fda69480$f8f3bd80$@augustcellars.com> Message-ID: <1346176407.33477.YahooMailRC@web184406.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:53:27 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <008b01cd7c46$fda69480$f8f3bd80$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1789658926-592480834-1346176407=:33477" Subject: Re: [jose] POLL: Remove no key wrap for key agreement algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:53:32 -0000 --1789658926-592480834-1346176407=:33477 Content-Type: text/plain; charset=us-ascii NO ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:09:20 AM Subject: [jose] POLL: Remove no key wrap for key agreement algorithms If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we remove the ability to go directly from a Key Agreement algorithm to the CMK without having a key wrap step? This would remove the ability to go directly and would require an intervening key wrap step. Room vote: 1 yes, 6 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --1789658926-592480834-1346176407=:33477 Content-Type: text/html; charset=us-ascii
NO

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:09:20 AM
Subject: [jose] POLL: Remove no key wrap for key agreement algorithms

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Should we remove the ability to go directly from a Key Agreement algorithm
to the CMK without having a key wrap step?

This would remove the ability to go directly and would require an
intervening key wrap step.

Room vote:  1 yes, 6 no, 0 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--1789658926-592480834-1346176407=:33477-- From ejay@mgi1.com Tue Aug 28 10:54:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0621F84C8 for ; Tue, 28 Aug 2012 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5deCacVECHv for ; Tue, 28 Aug 2012 10:54:04 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id 7C6D421F84A5 for ; Tue, 28 Aug 2012 10:54:04 -0700 (PDT) Received: from [98.139.91.68] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 28 Aug 2012 17:53:59 -0000 Received: from [66.94.237.107] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 28 Aug 2012 17:53:59 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 17:53:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 456042.2260.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 51651 invoked by uid 60001); 28 Aug 2012 17:53:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346176438; bh=KYpk9SCSlct/Cln39G/3PXwZC/KltSd7TsAZ1ppjbT8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WsLDUPKQHqD3hy0uthrwlqWvALgLQWycdmTRpCgm84RfpcRk/4D+K4QPgOBcwhIX1Xt7vn3iRYMDX8UjVtPPNREOqgiaHqu4ExIbgd6iq4zrUdy3/dvzJF9GWeMhxjaUp85y92XG2t7nOy5WwvEVG40mkKGR9gR28wi76UrjTD4= X-YMail-OSG: gWnP1GEVM1lwldZ2aWp001L84n5pHtyPm3ldkDGufbFhC9p E2lSOIsnBZHeFSXDtXf7TiweZa71Qk0fUNvJIL2JrJi6suCobNVU3Ft2BI1X y_x8MzHY_3eoVj9TjRsnWLwKBn_B7Wta1BqXXlEsCkVIAtMovGLI4c12Hwd8 eTYfFg79zI4Q4HyzOhVS4OWuNa4PEPFvkP8uGWebtNNlRufQI4yFcZoAsybh ol4RXLAiTJkGMFuRshUYcIJR_k4l490MX9IpLTqyHyVSkY3GkCu1Ya5oAUZx 8WQeiAAZva63RshDhqWTHJuiRH82uWstpAcP1d0mP1B.PYfJTRvLx5yyk0Sh DesfLkmHY03Fl9caGvGSMQ1ZGXt19Y3lEdTTrIdtzRKuvnUbzpG_LTUmZXXl kbdk0ZXYaJStFD_kJ68MakSXj9RlFw0z.tlQAo8r3FRU1pPXCxhGCxEIe6Su CvtGcwW5jc.wEY8IHslMiugrZt7P8KADO8OTEKKy57RbB9.lNvx2wzbY- Received: from [64.140.94.67] by web184405.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 10:53:58 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <000301cd7c46$c5b1c810$51155830$@augustcellars.com> Message-ID: <1346176438.20001.YahooMailRC@web184405.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 10:53:58 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <000301cd7c46$c5b1c810$51155830$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1412092350-1378876495-1346176438=:20001" Subject: Re: [jose] POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:54:05 -0000 ---1412092350-1378876495-1346176438=:20001 Content-Type: text/plain; charset=us-ascii NO ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:07:36 AM Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should SHA1 be the default parameters for these algorithms? Room vote: 0 yes, 5 no, 3 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---1412092350-1378876495-1346176438=:20001 Content-Type: text/html; charset=us-ascii
NO

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:07:36 AM
Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Should SHA1 be the default parameters for these algorithms?


Room vote:  0 yes, 5 no, 3 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---1412092350-1378876495-1346176438=:20001-- From hannes.tschofenig@gmx.net Tue Aug 28 11:00:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF80321F8514 for ; Tue, 28 Aug 2012 11:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKRXAjb+GXgc for ; Tue, 28 Aug 2012 11:00:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 73A8621F85C6 for ; Tue, 28 Aug 2012 11:00:29 -0700 (PDT) Received: (qmail invoked by alias); 28 Aug 2012 18:00:27 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 28 Aug 2012 20:00:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ITyJNlphIO6KoWVflLerTYhb87UTyjVwoyYmNh0 earbwMgoodQIwd Message-ID: <503D0738.3050207@gmx.net> Date: Tue, 28 Aug 2012 21:00:24 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Barnes References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> <3F05CE94720C45679B743583BBE2EBD3@bbn.com> In-Reply-To: <3F05CE94720C45679B743583BBE2EBD3@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "HAYASHI, Tatsuya" , jose@ietf.org Subject: Re: [jose] DISCUSS: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:00:30 -0000 Richard has a point here. Here is the description from: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-05#section-4.3 The semantic of the kid is not defined. So the question is not so much whether it is sufficiently defined but more "does it matter that it is not defined?" The answer depends on what you want to use the key id for. If you ever have to assume a structure of the kid then you will have a problem. This could, for example, happen when you use it to make some authorization decisions and when you compare it against some existing other identities. I am not even sure what the kid references. Does it always reference a key that is included in the payload it self or does it reference a key that is external to the payload? Will you ever have the case that you need to use part of the identifier structure to find the key? (e.g., to discover the right server where the key is stored?) On 08/28/2012 11:02 AM, Richard Barnes wrote: > I voted "NO" on this in the room, because I don't understand it. Could one of you "YES" voters explain it? > > What does "kid" mean in the context of a public-key wrapped key? Is it a public key? If so, in what format? How about in the context of key agreement? > > Thanks, > --Richard > > From ejay@mgi1.com Tue Aug 28 11:43:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFAE21F8518 for ; Tue, 28 Aug 2012 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIn2bUQIiO5Y for ; Tue, 28 Aug 2012 11:43:12 -0700 (PDT) Received: from nm31-vm6.bullet.mail.bf1.yahoo.com (nm31-vm6.bullet.mail.bf1.yahoo.com [72.30.239.14]) by ietfa.amsl.com (Postfix) with SMTP id 4D56221F8516 for ; Tue, 28 Aug 2012 11:43:12 -0700 (PDT) Received: from [98.139.212.152] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 18:43:11 -0000 Received: from [66.94.237.108] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 18:43:11 -0000 Received: from [127.0.0.1] by omp1013.access.mail.mud.yahoo.com with NNFMP; 28 Aug 2012 18:43:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 651607.96987.bm@omp1013.access.mail.mud.yahoo.com Received: (qmail 19930 invoked by uid 60001); 28 Aug 2012 18:43:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346179391; bh=nvgR1Wo2ToBDJRjvuzOvTGB/nKKywAbC3BdNkcYQ4Hc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=L8je+Ws8E8rd9/g3NcsYIgT8baD+KkdmqALlHQYsArnvXkjnnFJvL54CLki1nu8pF7I+BeD7OKMgmpukNVd5G9Td+rGd/NEdCeh8fYcKEewTfFjcWKG4Rm2nkUuXfa5lA2TyaTs0G8mkCYSC0leDKKLvgmk13YtznGWhMBqU4iQ= X-YMail-OSG: ot5OeAoVM1kAQTkuS5MGtOBWdzGfBFbSoB7qoa6MKQ6N3eV 7mwBNY1r5EtPV7DusroOMY_viQs4L6ixG1VDYl8dakaarWfNlq_AurhOdav9 S6CSZy9D5ukNMt3cVUVrjguk_RwZ0wrvlwqmqCUn5aHqozzT1ef4edPeJFLb akRBpcSZUYBKPIi_V3mYTVLNTNVvyYDI9b9QmVwyJiNCVFDTe5cXUQHEC2vz NCSNpFdrqALVtF6iYvntlFy3z_Hjru6ASXiFeLqj_K80UZ3.PaoN073qr2O4 rdz1d_lHgncWBd..IA.oGQE3BV_E2cmmR6DW32BO49QjmI.YnM8juyO4jiIB Ne1DeZCobE1OOg0X2XdeVRLhxN68p1OXoTDNAHQBT4YAdL7QivpIIEardsOo SaeHJhaQv7T51G8TS7ZN9ZaaK958rDzxxV9FJCvrQguSe9epNY5oNiRb374U eXLSD0QfKmnC7dmJYx67CtQF7VdEsi65WRgjEqoCxATZ3o7kUtigqKE5ATA- - Received: from [64.140.94.67] by web184405.mail.bf1.yahoo.com via HTTP; Tue, 28 Aug 2012 11:43:10 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> <1346176357.33556.YahooMailRC@web184404.mail.bf1.yahoo.com> Message-ID: <1346179390.94539.YahooMailRC@web184405.mail.bf1.yahoo.com> Date: Tue, 28 Aug 2012 11:43:10 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <1346176357.33556.YahooMailRC@web184404.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1412092350-462680830-1346179390=:94539" Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:43:13 -0000 ---1412092350-462680830-1346179390=:94539 Content-Type: text/plain; charset=us-ascii Sorry, I made a mistake. I would like to change my vote to YES. ________________________________ From: Edmund Jay To: jose@ietf.org Sent: Tue, August 28, 2012 10:52:53 AM Subject: Re: [jose] POLL: Non AEAD algorithms as a single name NO ________________________________ From: Jim Schaad To: jose@ietf.org Sent: Fri, August 17, 2012 12:09:15 AM Subject: [jose] POLL: Non AEAD algorithms as a single name If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we change the current treatment of AES-CBC + HMAC to use a single content encryption name. Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: {"enc":"AES128CBC+HS256+CS256"} Exact name is still to be determined Room vote: 12 yes, 2 no, 0 discuss _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ---1412092350-462680830-1346179390=:94539 Content-Type: text/html; charset=us-ascii
Sorry, I made a mistake.
I would like to change my vote to YES.

From: Edmund Jay <ejay@mgi1.com>
To: jose@ietf.org
Sent: Tue, August 28, 2012 10:52:53 AM
Subject: Re: [jose] POLL: Non AEAD algorithms as a single name

NO

From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
Sent: Fri, August 17, 2012 12:09:15 AM
Subject: [jose] POLL: Non AEAD algorithms as a single name

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to
provide comments please change the title from POLL to DISCUSS.

Should we change the current treatment of AES-CBC + HMAC to use a single
content encryption name.

Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"}
New: {"enc":"AES128CBC+HS256+CS256"}

Exact name is still to be determined

Room vote:  12 yes, 2 no, 0 discuss


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
---1412092350-462680830-1346179390=:94539-- From stpeter@stpeter.im Tue Aug 28 11:44:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586A21F8551 for ; Tue, 28 Aug 2012 11:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iILhYAX2zTG4 for ; Tue, 28 Aug 2012 11:44:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A733521F8518 for ; Tue, 28 Aug 2012 11:44:56 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6F743404EB; Tue, 28 Aug 2012 12:46:05 -0600 (MDT) Message-ID: <503D11A7.2060203@stpeter.im> Date: Tue, 28 Aug 2012 12:44:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Edmund Jay References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> <1346176357.33556.YahooMailRC@web184404.mail.bf1.yahoo.com> <1346179390.94539.YahooMailRC@web184405.mail.bf1.yahoo.com> In-Reply-To: <1346179390.94539.YahooMailRC@web184405.mail.bf1.yahoo.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: jose@ietf.org Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:44:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We don't actually vote at the IETF. :-) But it seems that "the sense of the group" is pretty clear on this one... /psa On 8/28/12 12:43 PM, Edmund Jay wrote: > Sorry, I made a mistake. I would like to change my vote to YES. > > ------------------------------------------------------------------------ > > *From:* Edmund Jay > *To:* jose@ietf.org *Sent:* Tue, August 28, 2012 10:52:53 AM > *Subject:* Re: [jose] POLL: Non AEAD algorithms as a single name > > NO > > ------------------------------------------------------------------------ > > *From:* Jim Schaad > *To:* jose@ietf.org *Sent:* Fri, August 17, 2012 12:09:15 AM > *Subject:* [jose] POLL: Non AEAD algorithms as a single name > > > > If you voted at the face-2-face please do not vote again. If you > want to provide comments please change the title from POLL to > DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a > single content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: > {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9EacACgkQNL8k5A2w/vxPMwCgzZgeu/GNlLmu0a09v4e/3eVe 4wcAn1kxJPQS/XE4ey28F4oas694P2i/ =UQK3 -----END PGP SIGNATURE----- From breno@google.com Tue Aug 28 12:06:36 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E621F8539 for ; Tue, 28 Aug 2012 12:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfmPJ-tBXXeT for ; Tue, 28 Aug 2012 12:06:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA31921F8526 for ; Tue, 28 Aug 2012 12:06:34 -0700 (PDT) Received: by qcac10 with SMTP id c10so4227899qca.31 for ; Tue, 28 Aug 2012 12:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Y79hpL4tLI8FB8ddpd2m1jLCSp7Eo3yVvOdU3pX+dpE=; b=PNkAiUHDHex0BU1iZFZ9z6tR3DU/D36zD9g16uBdIvTAf1KssdP0Uxw5LSULxXgFpM RAKa2hIN6vkWoDGj81LDgJ5ZUKh5tUn7M3MRtMbj/++zDvNjDyLV+mCQpxOjUSrLQckk VkTjae2I7fNxUCkNVrg2H39/SqKBUY07U54fdfJKYEC/KvMKAKkU12jI6Md9/CMMDofd W7jE5gIuLBG4gT5q0qKlCbqhb7/FnKQXuXshSsFPHWIy7rvX1aDyu2ax5yWGMfR5i0rD fHQiDS9T4HWKlfM4kPJT6nHT2NZxeRO4w4gjZizJoqJxst4jIGzT6GRxQXYwv8ln71OM o75A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Y79hpL4tLI8FB8ddpd2m1jLCSp7Eo3yVvOdU3pX+dpE=; b=ZtNyopkAWBbrd6777KsqWtMzeJldMSsCfaDizdQeTYGcExlDIKP1P8k66M76V6YFdr Gq2WKFXimRoNJ2vJ1V+8uMqst7q63ov3+pQyqDSbJt1ZTL5d0bpNnBxnkQteh1n+ojpX 3mOUr1J9O9Cj5XBJ468Q88MoJY9woiIUbLKUoppjALqqLMEkMTA2xHrV+uBzPAbkZqWH 2BgWe/4ec0S+vGaVWNy2wbxrtI593zepV5clwzmIR59qkv17Ue4MhxuFv0tORhFfE6rx W4kjGqil9kBQuelnwG5NmNzbq2RVOnlleCLlI3NPHZcC3bXgPEcyWKqFhGD3zRWVAvrC 4J8w== Received: by 10.224.196.73 with SMTP id ef9mr32483059qab.36.1346180793805; Tue, 28 Aug 2012 12:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.196.73 with SMTP id ef9mr32483023qab.36.1346180793591; Tue, 28 Aug 2012 12:06:33 -0700 (PDT) Received: by 10.229.162.193 with HTTP; Tue, 28 Aug 2012 12:06:33 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503CD692.4020007@mitre.org> Date: Tue, 28 Aug 2012 12:06:33 -0700 Message-ID: From: Breno de Medeiros To: John Bradley Content-Type: multipart/alternative; boundary=20cf300fb20101662404c8582472 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmkcGE+b0kyQ/BwWX3LRE5wzhO0oWdII7r5o6U1Y2mRD88o/AtVdznPijifZJH5RIcQsbbMzuB2jz0xSzYYOdrCTYXNEODPoqblzSefGDvgkZLHjb/FRoRNpz9LiW/r585Zb3S1PKT5ZAlCntJzU/lOshdaLFul+7dNqEwVfvmPVZ//d/lBCw179jL6lnlzZIQwQQVq Cc: Axel Nennker , Mike Jones , Justin Richer , "jose@ietf.org" , Jim Schaad Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:06:36 -0000 --20cf300fb20101662404c8582472 Content-Type: text/plain; charset=ISO-8859-1 I agree that this should be looked independently of oauth2. Nonce is a generally used concept in crypto, though sometimes protocol designers have called for nonces with bad outcomes because the difficulty of implementing nonce-checking was disregarded. However, difficulties to implement nonces in general are not relevant if there is a compelling use case that is able to leverage nonces effectively. As for timestamps: we already have issued time and the nonce can embed a timestamp additionally. So I don't think we need to concern ourselves with timestamps when considering nonces. On Tue, Aug 28, 2012 at 8:09 AM, John Bradley wrote: > In OAuth 2 state gets overloaded with a bunch of things from preventing > XSRF to providing a handle to look up who the the authorization request was > sent to. > > In Connect we added a nonce sent by client that is returned inside the > signed id_token (JWT) to allow the client to detect replay, and optionally > reference a specific browser session that presents the id_token. > > The nonce I suggested for JOSE is not ether of those. > > I used nonce in the sense that it is used with stream cyphers when the > same key is used over multiple messages. > > JOSE will be used for more than OAuth and JWT. There are cases where > adding entropy to the header will be a security benefit. I would like to > have a standard claim for doing that. > If people want to call it something else that is fine, but it is a nonce > by definition. > If used it should be a random or pseudo random value that is time variant > with sufficient granularity to ensure a nonce is used only once. > > John B. > > On 2012-08-28, at 10:32 AM, Justin Richer wrote: > > On 08/25/2012 03:37 AM, Axel Nennker wrote: > > To clarify: What is the base specification that Jim mentioned? > Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ? > > Would somebody please present a use-case for either nonce or timestamp? > If a jwt is used with oauth2 then what is the difference between nonce and > state? Nonce would be signed while state is not? > > > Nonce would generally be generated by the entity creating the token. State > in OAuth is generated by the client, and would only be protected if the > client had a means to make a signed request to the server, using either a > MAC binding or a JWT-based OIDC-style RequestObject. > > -- Justin > > I guess I am missing some information that those in the room who voted > "yes" had? > > Axel > > 2012/8/25 Mike Jones > >> I'll note for discussion purposes that a nonce and a timestamp are not >> the same thing (although sometimes they are used to achieve similar/related >> goals). A nonce tends to be an opaque value that must be preserved across >> the communication. Whereas a timestamp typically has defined semantics - >> sometimes simply a non-decreasing integer value - and sometimes a >> representation of time, and then, sometimes with a uniqueness requirement. >> >> For discussion purposes, I'll say that the simplest thing for us to do >> (should we decide to do anything in this regard) would be to define the >> nonce as an opaque string value that must be preserved. >> >> We could also define a timestamp parameter, but as I wrote above, that >> would likely require us to specify additional semantics - starting with >> whether it's a non-decreasing integer or a representation of a time value. >> This seems much harder to define and possibly to use than a nonce. >> >> Would it make sense to define a nonce parameter now and hold off on >> defining a timestamp parameter until there's a clear demonstrated use case >> for which a nonce is not sufficient? That would be my personal >> recommendation. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Jim Schaad >> Sent: Friday, August 17, 2012 12:05 AM >> To: jose@ietf.org >> Subject: [jose] POLL: Nonce/Timestamp parameter >> >> >> >> If you voted at the face-2-face please do not vote again. If you want to >> provide comments please change the title from POLL to DISCUSS. >> >> Do we need to define a nonce/timestamp parameter in the base >> specification? >> >> >> >> Room vote: 6 yes, 0 no, 1 discuss >> >> >> _______________________________________________ >> 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 >> > > > > _______________________________________________ > jose mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > 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 > > -- --Breno --20cf300fb20101662404c8582472 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that this should be looked independently of oauth2.

<= div>Nonce is a generally used concept in crypto, though sometimes protocol = designers have called for nonces with bad outcomes because the difficulty o= f implementing nonce-checking was disregarded. However, difficulties to imp= lement nonces in general are not relevant if there is a compelling use case= that is able to leverage nonces effectively.

As for timestamps: we already have issued time and the = nonce can embed a timestamp additionally. So I don't think we need to c= oncern ourselves with timestamps when considering nonces.




On Tue, Aug 28, 2012 at 8:09 AM, John Bradley <= ;ve7jtb@ve7jtb.com> wrote:
In OAuth= 2 state gets overloaded with a bunch of things from preventing XSRF to pro= viding a handle to look up who the the authorization request was sent to.
In Connect we added a nonce sent by client that is returned = inside the signed id_token (JWT) to allow the client to detect replay, and = optionally reference a specific browser session that presents the id_token.=

The nonce I suggested for JOSE is not ether of those. = =A0

I used nonce in the sense that it is used with= stream cyphers when the same key is used over multiple messages.


<= br>
=20 =20 =20
On 08/25/2012 03:37 AM, Axel Nennker wrote:
=20 To clarify: What is the base specification that Jim mentioned?
Is it: http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-03 ?

Would somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?


Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.

=A0-- Justin

I guess I am missing some information that th= ose in the room who voted "yes" had?

Axel

2012/8/25 Mike Jones <= ;Michael.J= ones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestam= p are not the same thing (although sometimes they are used to achieve similar/related goals). =A0A nonce tends to be an opaque value that must be preserved across the communication. =A0Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value. =A0This seems much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient? =A0That would be my personal recommendation.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 B= est wishes,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -= - Mike

-----Original Message-----
From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.= org
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again. =A0If you want to provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?



Room vote: =A06 yes, 0 no, 1 discuss


_______________________________________________
jose mailing list
jose@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/jose



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

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


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




--
--Breno<= br>
--20cf300fb20101662404c8582472-- From breno@google.com Tue Aug 28 12:08:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72B21F85B4 for ; Tue, 28 Aug 2012 12:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.735 X-Spam-Level: X-Spam-Status: No, score=-102.735 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFpVkVaj+5c9 for ; Tue, 28 Aug 2012 12:08:10 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2192921F8598 for ; Tue, 28 Aug 2012 12:08:09 -0700 (PDT) Received: by qcac10 with SMTP id c10so4229208qca.31 for ; Tue, 28 Aug 2012 12:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=8rCGQTkE6Z8J0l+rYREaATvKGAyId9QQTMaq0mhF4M4=; b=j1ZbceAhvx5PJCj7EpekEbstlgadr/8Tubf55wL2JgsWw22JUdgrYL0tENzv0wn7s4 AYauHx1burHnmPljaS/MM22p17VWdXG7fzFFkxtUbx35bbksZw8RuYD79mnzi4Hc+rA+ IOUGkhra0/UVNuXqkC8V+h3MJW77gu8pHj2wVqN72mVeBGq3nokhAz8j9ouBsbhCoqv7 KfvU3nBmXmV93zfiulp4l7waJ+JPIJeUyg9FXdSazc0u0SSR1DABL/gdaYmnes0Nyr6Q l4x2yFKgN/xYvwFpWJjHCcUwUhZ3RfFaCjc6cIHdUdFBvZi8N6q0qowx/YoEXXXoTeXy c6/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=8rCGQTkE6Z8J0l+rYREaATvKGAyId9QQTMaq0mhF4M4=; b=JxSnIR80shonYApK+JMMbOwXd2X+ycFbFkTXM0hljwdEOb++6a0eAlZ31AD5uJKTT5 pi4BnSXA5Rryfx9LKL2sMQRdQznSLX0GhnKOWkwYFYIouqLEQCfoN/f1f7Fg+AD7iscD djo2vtizCV+5B1zzRJSAacmnXURHpy/h6XaDEHz9joC9dPWZ/H8shFxDgMf0EZzWK8tj lXTiiZ6o1L9ilE29F8L7+KMDGxc6Nm8kRXbC8W+Bpg3Jc4olKnbnK1c32Nvdt4h6jzwt JepqnILzDGaDUACg6lJv3oRgMzBrLLEAhYb9NsjnO5m/cweH5+zl9Hb2+W9TIQPlfbro lM5w== Received: by 10.224.181.193 with SMTP id bz1mr32418662qab.64.1346180889258; Tue, 28 Aug 2012 12:08:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.181.193 with SMTP id bz1mr32418615qab.64.1346180888938; Tue, 28 Aug 2012 12:08:08 -0700 (PDT) Received: by 10.229.162.193 with HTTP; Tue, 28 Aug 2012 12:08:08 -0700 (PDT) In-Reply-To: <503D11A7.2060203@stpeter.im> References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> <1346176357.33556.YahooMailRC@web184404.mail.bf1.yahoo.com> <1346179390.94539.YahooMailRC@web184405.mail.bf1.yahoo.com> <503D11A7.2060203@stpeter.im> Date: Tue, 28 Aug 2012 12:08:08 -0700 Message-ID: From: Breno de Medeiros To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf303637f7b0493204c8582915 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkVHkcSQVxau8gSkfGLX+Vpr+OtsIcWcdYgaDhoPiIO3wFESY7AlgquLIwTRh4dTnYey65Aaryb3OSmxZDZfYAT79t1lLx7W5HgqhVnm34fkQ0/GGx0RTivsh8EL6qzCRVC4KwFYRw9TH298ElpT1wBhEu1enqFsmLn/byY0RKrXAHzV+QErvYZ/COP1dgLliA4hhoh Cc: jose@ietf.org, Edmund Jay Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:08:11 -0000 --20cf303637f7b0493204c8582915 Content-Type: text/plain; charset=ISO-8859-1 YES On Tue, Aug 28, 2012 at 11:44 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We don't actually vote at the IETF. :-) > > But it seems that "the sense of the group" is pretty clear on this one... > > /psa > > On 8/28/12 12:43 PM, Edmund Jay wrote: > > Sorry, I made a mistake. I would like to change my vote to YES. > > > > ------------------------------------------------------------------------ > > > > > *From:* Edmund Jay > > *To:* jose@ietf.org *Sent:* Tue, August 28, 2012 10:52:53 AM > > *Subject:* Re: [jose] POLL: Non AEAD algorithms as a single name > > > > NO > > > > ------------------------------------------------------------------------ > > > > > *From:* Jim Schaad > > *To:* jose@ietf.org *Sent:* Fri, August 17, 2012 12:09:15 AM > > *Subject:* [jose] POLL: Non AEAD algorithms as a single name > > > > > > > > If you voted at the face-2-face please do not vote again. If you > > want to provide comments please change the title from POLL to > > DISCUSS. > > > > Should we change the current treatment of AES-CBC + HMAC to use a > > single content encryption name. > > > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: > > {"enc":"AES128CBC+HS256+CS256"} > > > > Exact name is still to be determined > > > > Room vote: 12 yes, 2 no, 0 discuss > > > > > > _______________________________________________ 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 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlA9EacACgkQNL8k5A2w/vxPMwCgzZgeu/GNlLmu0a09v4e/3eVe > 4wcAn1kxJPQS/XE4ey28F4oas694P2i/ > =UQK3 > -----END PGP SIGNATURE----- > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- --Breno --20cf303637f7b0493204c8582915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable YES


On Tue, Au= g 28, 2012 at 11:44 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We don't actually vote at the IETF. :-)

But it seems that "the sense of the group" is pretty clear on thi= s one...

/psa

On 8/28/12 12:43 PM, Edmund Jay wrote:
> Sorry, I made a mistake. I would like to change my vote to YES.
>
> ----------------------------------------------------------------= --------
>
>
*From:* Edmund Jay <ejay@mgi1.com&g= t;
> *To:* jose@ietf.org *Sent:* Tue, = August 28, 2012 10:52:53 AM
> *Subject:* Re: [jose] POLL: Non AEAD algorithms as a single name
>
> NO
>
> ----------------------------------------------------------------------= --
>
>
*From:* Jim Schaad <ietf@augus= tcellars.com>
> *To:* jose@ietf.org *Sent:* Fri, = August 17, 2012 12:09:15 AM
> *Subject:* [jose] POLL: Non AEAD algorithms as a single name
>
> <CHAIR>
>
> If you voted at the face-2-face please do not vote again. =A0If you > want to provide comments please change the title from POLL to
> DISCUSS.
>
> Should we change the current treatment of AES-CBC + HMAC to use a
> single content encryption name.
>
> Old: {"enc":"A128CBC", "int":HS256"= , "kdf":"CS256"} New:
> {"enc":"AES128CBC+HS256+CS256"}
>
> Exact name is still to be determined
>
> Room vote: =A012 yes, 2 no, 0 discuss
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org <mailto:jose@ietf.org>
> https://www.ietf.org/mailman/listinfo/jose
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org https://www.ietf.org/= mailman/listinfo/jose
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA9EacACgkQNL8k5A2w/vxPMwCgzZgeu/GNlLmu0a09v4e/3eVe
4wcAn1kxJPQS/XE4ey28F4oas694P2i/
=3DUQK3
-----END PGP SIGNATURE-----
___________________________________= ____________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
= --Breno

--20cf303637f7b0493204c8582915-- From cmortimore@salesforce.com Tue Aug 28 12:11:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8921F860E for ; Tue, 28 Aug 2012 12:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s44pDDkFatTg for ; Tue, 28 Aug 2012 12:11:15 -0700 (PDT) Received: from exprod8og103.obsmtp.com (exprod8og103.obsmtp.com [64.18.3.86]) by ietfa.amsl.com (Postfix) with SMTP id 6316821F85F7 for ; Tue, 28 Aug 2012 12:11:15 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob103.postini.com ([64.18.7.12]) with SMTP ID DSNKUD0X0w3Uc4fW49towE5uWa//IgxMz55S@postini.com; Tue, 28 Aug 2012 12:11:15 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 28 Aug 2012 12:11:14 -0700 From: Chuck Mortimore To: Breno de Medeiros Date: Tue, 28 Aug 2012 12:11:13 -0700 Thread-Topic: [jose] POLL: Non AEAD algorithms as a single name Thread-Index: Ac2FUORdx/8BlCj6Rp+iVScDCrPrrA== Message-ID: <83DBD945-422C-4BCD-8087-3257BC3A0331@salesforce.com> References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> <1346176357.33556.YahooMailRC@web184404.mail.bf1.yahoo.com> <1346179390.94539.YahooMailRC@web184405.mail.bf1.yahoo.com> <503D11A7.2060203@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_83DBD945422C4BCD80873257BC3A0331salesforcecom_" MIME-Version: 1.0 Cc: "jose@ietf.org" , Peter Saint-Andre , Edmund Jay Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:11:16 -0000 --_000_83DBD945422C4BCD80873257BC3A0331salesforcecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YES On Aug 28, 2012, at 12:08 PM, Breno de Medeiros wrote: YES On Tue, Aug 28, 2012 at 11:44 AM, Peter Saint-Andre > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We don't actually vote at the IETF. :-) But it seems that "the sense of the group" is pretty clear on this one... /psa On 8/28/12 12:43 PM, Edmund Jay wrote: > Sorry, I made a mistake. I would like to change my vote to YES. > > ------------------------------------------------------------------------ > > *From:* Edmund Jay > > *To:* jose@ietf.org *Sent:* Tue, August 28, 2012 10= :52:53 AM > *Subject:* Re: [jose] POLL: Non AEAD algorithms as a single name > > NO > > ------------------------------------------------------------------------ > > *From:* Jim Schaad > > *To:* jose@ietf.org *Sent:* Fri, August 17, 2012 12= :09:15 AM > *Subject:* [jose] POLL: Non AEAD algorithms as a single name > > > > If you voted at the face-2-face please do not vote again. If you > want to provide comments please change the title from POLL to > DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a > single content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New: > {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9EacACgkQNL8k5A2w/vxPMwCgzZgeu/GNlLmu0a09v4e/3eVe 4wcAn1kxJPQS/XE4ey28F4oas694P2i/ =3DUQK3 -----END PGP SIGNATURE----- _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- --Breno _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_83DBD945422C4BCD80873257BC3A0331salesforcecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YES

On A= ug 28, 2012, at 12:08 PM, Breno de Medeiros wrote:

YES


On Tue, Aug 28, 2012 at 11:44 AM, Pete= r Saint-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We don't actually vote at the IETF. :-)

But it seems that "the sense of the group" is pretty clear on this one...
/psa

On 8/28/12 12:43 PM, Edmund Jay wrote:
> Sorry, I made a mistake. I would like to change my vote to YES.
>
> ----------------------------------------------------------------= --------
>
>
*From:* Edmund Jay <ejay@mgi1.com&g= t;
> *To:* jose@ietf.org *Sent:* Tue, = August 28, 2012 10:52:53 AM
> *Subject:* Re: [jose] POLL: Non AEAD algorithms as a single name
>
> NO
>
> ----------------------------------------------------------------------= --
>
>
*From:* Jim Schaad <ietf@augus= tcellars.com>
> *To:* jose@ietf.org *Sent:* Fri, = August 17, 2012 12:09:15 AM
> *Subject:* [jose] POLL: Non AEAD algorithms as a single name
>
> <CHAIR>
>
> If you voted at the face-2-face please do not vote again.  If you=
> want to provide comments please change the title from POLL to
> DISCUSS.
>
> Should we change the current treatment of AES-CBC + HMAC to use a
> single content encryption name.
>
> Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} New:
> {"enc":"AES128CBC+HS256+CS256"}
>
> Exact name is still to be determined
>
> Room vote:  12 yes, 2 no, 0 discuss
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org <mailto:jose@ietf.org>
> https://www.ietf.org/mailman/listinfo/jose
>
>
> _______________________________________________ jose mailing list
> jose@ietf.org https://www.ietf.org/= mailman/listinfo/jose
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA9EacACgkQNL8k5A2w/vxPMwCgzZgeu/GNlLmu0a09v4e/3eVe
4wcAn1kxJPQS/XE4ey28F4oas694P2i/
=3DUQK3
-----END PGP SIGNATURE-----
___________________________________= ____________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
= --Breno

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mai= lman/listinfo/jose

= --_000_83DBD945422C4BCD80873257BC3A0331salesforcecom_-- From cmortimore@salesforce.com Tue Aug 28 12:12:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7321F85F7 for ; Tue, 28 Aug 2012 12:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLedi-k+nuBQ for ; Tue, 28 Aug 2012 12:12:13 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by ietfa.amsl.com (Postfix) with SMTP id 2DDD721F85B4 for ; Tue, 28 Aug 2012 12:12:13 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKUD0YDNWYWTRIfmskQ+e1lhPcsVs7krNA@postini.com; Tue, 28 Aug 2012 12:12:13 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 28 Aug 2012 12:12:12 -0700 From: Chuck Mortimore To: "jose@ietf.org" Date: Tue, 28 Aug 2012 12:12:11 -0700 Thread-Topic: [jose] POLL: Is KID sufficently defined Thread-Index: Ac2FUQbIEvF9ZoU3QXGIdl5xfdgEPw== Message-ID: <5ED0272B-CC5B-4A7D-92B2-E8E9008376E6@salesforce.com> References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@augustcellars.com" Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:12:13 -0000 YES On Aug 27, 2012, at 1:15 AM, wrote: > YES >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of J= im Schaad > Sent: Friday, August 17, 2012 9:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Is KID sufficently defined >=20 > >=20 > If you voted at the face-2-face please do not vote again. If you want to= provide comments please change the title from POLL to DISCUSS. >=20 > Is the current text for KID sufficiently defined and understood? >=20 >=20 > Room vote: 2 yes, 0 no, 1 discuss >=20 >=20 > _______________________________________________ > 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 From cmortimore@salesforce.com Tue Aug 28 12:13:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F5C11E8099 for ; Tue, 28 Aug 2012 12:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMxHHG3XBbaI for ; Tue, 28 Aug 2012 12:13:24 -0700 (PDT) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by ietfa.amsl.com (Postfix) with SMTP id 7562811E80A5 for ; Tue, 28 Aug 2012 12:13:24 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKUD0YVLkS1bMv4TE/nauyYVx295ESqL78@postini.com; Tue, 28 Aug 2012 12:13:24 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Tue, 28 Aug 2012 12:13:23 -0700 From: Chuck Mortimore To: "jose@ietf.org" Date: Tue, 28 Aug 2012 12:13:23 -0700 Thread-Topic: [jose] POLL: Criticality of understanding header fields Thread-Index: Ac2FUTGIb3xL+E0KRMagCm7ZgVGGRg== Message-ID: <63AEF75F-250A-41CE-A334-D03A293BDE52@salesforce.com> References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@augustcellars.com" Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:13:25 -0000 YES On Aug 27, 2012, at 1:16 AM, wrote: > YES >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of J= im Schaad > Sent: Friday, August 17, 2012 9:05 AM > To: jose@ietf.org > Subject: [jose] POLL: Criticality of understanding header fields >=20 > >=20 > If you voted at the face-2-face please do not vote again. If you want to= provide comments please change the title from POLL to DISCUSS. >=20 > What should be the criticality of header fields as defined by the core sp= ecification? >=20 > YES - all headers fields are critical > NO - all header fields are non-critical > MAYBE - header fields are marked critical or criticality should be define= d by the application DISCUSS - need to talk more >=20 > Room vote: 2 yes, 0 no, 4 maybe, 3 discuss >=20 >=20 >=20 > _______________________________________________ > 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 From cmortimore@salesforce.com Tue Aug 28 12:13:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA311E80FC for ; Tue, 28 Aug 2012 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9LmYF0QX8b4 for ; Tue, 28 Aug 2012 12:13:56 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by ietfa.amsl.com (Postfix) with SMTP id 0E59011E80D9 for ; Tue, 28 Aug 2012 12:13:56 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKUD0Yc3u0RsdaUUpm/1bHTA97+Hi2a/VJ@postini.com; Tue, 28 Aug 2012 12:13:56 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Tue, 28 Aug 2012 12:13:55 -0700 From: Chuck Mortimore To: "jose@ietf.org" Date: Tue, 28 Aug 2012 12:13:54 -0700 Thread-Topic: [jose] POLL: Support Multiple types for algorithms Thread-Index: Ac2FUURcwOYfHX7PSqCmlNa6Sst6KA== Message-ID: References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DBF4A17C61794FB4A4E408B46273A700salesforcecom_" MIME-Version: 1.0 Cc: Jim Schaad Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:13:57 -0000 --_000_DBF4A17C61794FB4A4E408B46273A700salesforcecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NO On Aug 28, 2012, at 8:00 AM, Brian Campbell wrote: no On Fri, Aug 17, 2012 at 1:05 AM, Jim Schaad > wrote: If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should support be mandated to allow an algorithm to be both a string and an object Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"} Room vote: 1 yes, 5 no, 4 discuss _______________________________________________ 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 --_000_DBF4A17C61794FB4A4E408B46273A700salesforcecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NO

On Au= g 28, 2012, at 8:00 AM, Brian Campbell wrote:

no

On Fri, Aug 17, 2012 at 1:05 AM, Jim Schaad <ietf@augustcellars.c= om> wrote:
<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want= to
provide comments please change the title from POLL to DISCUSS.

Should support be mandated to allow an algorithm to be both a string and an=
object

Example:  "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", "kid":"12345"}


Room vote:  1 yes, 5 no, 4 discuss


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

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mai= lman/listinfo/jose

= --_000_DBF4A17C61794FB4A4E408B46273A700salesforcecom_-- From cmortimore@salesforce.com Tue Aug 28 12:14:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D458411E8102 for ; Tue, 28 Aug 2012 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay0L+ldMwBI3 for ; Tue, 28 Aug 2012 12:14:39 -0700 (PDT) Received: from exprod8og117.obsmtp.com (exprod8og117.obsmtp.com [64.18.3.34]) by ietfa.amsl.com (Postfix) with SMTP id 2C21211E80D7 for ; Tue, 28 Aug 2012 12:14:39 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob117.postini.com ([64.18.7.12]) with SMTP ID DSNKUD0YnsEdptYDHinyXbyz43QOtE5iz8oW@postini.com; Tue, 28 Aug 2012 12:14:39 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Tue, 28 Aug 2012 12:14:38 -0700 From: Chuck Mortimore To: "jose@ietf.org" Date: Tue, 28 Aug 2012 12:14:38 -0700 Thread-Topic: [jose] POLL: Add other than pre-shared MAC key Thread-Index: Ac2FUV4oIty+g+TtQA+UegLd8AskeA== Message-ID: <921BA779-8384-4228-858B-813DBFF5CED7@salesforce.com> References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_921BA77983844228858B813DBFF5CED7salesforcecom_" MIME-Version: 1.0 Cc: Jim Schaad Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:14:40 -0000 --_000_921BA77983844228858B813DBFF5CED7salesforcecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NO On Aug 28, 2012, at 8:02 AM, Brian Campbell wrote: no On Fri, Aug 17, 2012 at 1:06 AM, Jim Schaad > wrote: If you voted at the face-2-face please do not vote again. If you want to provide comments please change the title from POLL to DISCUSS. Should we add the ability to have a randomly generated MAC key protected by a different key? The other key could be either a pre-shared symmetric key or a public key. Room vote: 3 yes, 5 no, 3 discuss _______________________________________________ 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 --_000_921BA77983844228858B813DBFF5CED7salesforcecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NO
On Aug 28,= 2012, at 8:02 AM, Brian Campbell wrote:

no

O= n Fri, Aug 17, 2012 at 1:06 AM, Jim Schaad <jimsch@augustcellars.co= m> wrote:
<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want= to
provide comments please change the title from POLL to DISCUSS.

Should we add the ability to have a randomly generated MAC key protected by=
a different key?  The other key could be either a pre-shared symmetric= key
or a public key.



Room vote:  3 yes, 5 no, 3 discuss


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

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mai= lman/listinfo/jose

= --_000_921BA77983844228858B813DBFF5CED7salesforcecom_-- From bcampbell@pingidentity.com Tue Aug 28 13:30:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01321F8512 for ; Tue, 28 Aug 2012 13:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qmOsqyFt2YS for ; Tue, 28 Aug 2012 13:30:43 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9321421F8510 for ; Tue, 28 Aug 2012 13:30:43 -0700 (PDT) Received: from mail-qa0-f43.google.com ([209.85.216.43]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUD0qaWlGGJzbZOreRT+k/Tc4wZz8hoSw@postini.com; Tue, 28 Aug 2012 13:30:43 PDT Received: by qatk31 with SMTP id k31so3394926qat.2 for ; Tue, 28 Aug 2012 13:30:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Rx48ZsKutkhm4UaPrx5WfbxoBF8aE4ca8FlQPZlOLv0=; b=fYCeDTECuObrmDwxwicA3NrcX3qcqqP9NtuClm6759k88SKtas+p3fHBzOs2DDF0UH +1TPQSNODj6C06O90wAEX1GOMA0FFB8oujFk+Q8OO4mniBbJaAmjOL+g7041MRUSDgdn dYhJ1QiFnWQ69wTOFZbpRqxUXyeuarQ2GlVE5Qnmy1ebe5jE+lbilLvPTyGcT1pHDyDZ +VcZEFY/c8CRCYm/P7Av2yzxFLws2m62T/NEWm1pp2bX9thrCYgTWxeQ/hq98Qc0CFjN 6nHmYxm2QF+5tBvtfi2g1mK+po+t5wyGPzTiQrXkrjz7dwI/tbIKJ7m0QiD/bqN3f9d9 eQyw== Received: by 10.224.196.134 with SMTP id eg6mr32885969qab.63.1346185832902; Tue, 28 Aug 2012 13:30:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.73 with HTTP; Tue, 28 Aug 2012 13:30:02 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667A1FD3@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366797E0F@TK5EX14MBXC284.redmond.corp.microsoft.com> <024001cd7d31$ca406620$5ec13260$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943667A1FD3@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Brian Campbell Date: Tue, 28 Aug 2012 14:30:02 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf3005dd965f2f7804c859502b X-Gm-Message-State: ALoCoQlKqXPRlQO86QJlRlfiQ1zzowaz1qoSmizzALdlcY45Em8nm4ao6sLnEcqi9u9aqfQ8YiOQ Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:30:44 -0000 --20cf3005dd965f2f7804c859502b Content-Type: text/plain; charset=ISO-8859-1 I, for one, am very confused by this one. I just went with the intention to vote in favor of using widely deployed default parameters (like SHA1) but after reading this and the poll thread again, I wasn't sure what a yes or no vote was actually for. On Mon, Aug 20, 2012 at 12:08 PM, Mike Jones wrote: > Just to avoid confusion, could you or Karen please resend the poll > question with the correct room count? > > Thanks, > -- Mike > > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Saturday, August 18, 2012 4:08 AM > To: Mike Jones; jose@ietf.org > Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters > > I believe that I switched the question between the room and here. The > question in the room was should we switch FROM SHA1 to something else. > > The room count should be reversed with the revised question. > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Saturday, August 18, 2012 1:53 AM > > To: Jim Schaad; jose@ietf.org > > Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters > > > > I believe that the results below are recorded incorrectly. I know > > that I personally voted that we use the default parameters as widely > > deployed (SHA-1), so the results below can not be right. I believe > > that the > results were > > likely actually: > > > > Room vote: 5 yes, 0 no, 3 discuss > > > > -- Mike > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Jim Schaad > > Sent: Friday, August 17, 2012 12:05 AM > > To: jose@ietf.org > > Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters > > > > > > > > If you voted at the face-2-face please do not vote again. If you want > > to provide comments please change the title from POLL to DISCUSS. > > > > Should SHA1 be the default parameters for these algorithms? > > > > > > Room vote: 0 yes, 5 no, 3 discuss > > > > > > _______________________________________________ > > 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 > --20cf3005dd965f2f7804c859502b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I, for one, am very confused by this one. I just went with the intention to= vote in favor of using widely deployed default parameters (like SHA1) but = after reading this and the poll thread again, I wasn't sure what a yes = or no vote was actually for.

On Mon, Aug 20, 2012 at 12:08 PM, Mike Jones= <Michael.Jones@microsoft.com> wrote:
Just to avoid confusion, could you or Karen = please resend the poll question with the correct room count?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Saturday, August 18, 2012 4:08 AM
To: Mike Jones; jose@iet= f.org
Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters

I believe that I switched the question between the room and here. =A0The qu= estion in the room was should we switch FROM SHA1 to something else.

The room count should be reversed with the revised question.

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Saturday, August 18, 2012 1:53 AM
> To: Jim Schaad; jos= e@ietf.org
> Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters
>
> I believe that the results below are recorded incorrectly. =A0I know > that I personally voted that we use the default parameters as widely > deployed (SHA-1), so the results below can not be right. =A0I believe<= br> > that the
results were
> likely actually:
>
> Room vote: =A05 yes, 0 no, 3 discuss
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >
> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> Of Jim Schaad
> Sent: Friday, August 17, 2012 12:05 AM
> To: jose@ietf.org
> Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters
>
> <CHAIR>
>
> If you voted at the face-2-face please do not vote again. =A0If you wa= nt
> to provide comments please change the title from POLL to DISCUSS.
>
> Should SHA1 be the default parameters for these algorithms?
>
>
> Room vote: =A00 yes, 5 no, 3 discuss
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose




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

--20cf3005dd965f2f7804c859502b-- From bcampbell@pingidentity.com Tue Aug 28 13:46:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1130711E80A5 for ; Tue, 28 Aug 2012 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJsSMyERBvwy for ; Tue, 28 Aug 2012 13:46:38 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C111E8099 for ; Tue, 28 Aug 2012 13:46:37 -0700 (PDT) Received: from mail-qc0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUD0uLQ4mjCZdRoJprk5IZlU6t/ofh9Hs@postini.com; Tue, 28 Aug 2012 13:46:37 PDT Received: by qcsg15 with SMTP id g15so4611032qcs.13 for ; Tue, 28 Aug 2012 13:46:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=LSoPFVP0c7DmiRIRGXnF5xkEYHfyd+Mlv9jVFHVQW/c=; b=kGGrcfYMxBysAxXOAKehi+eMMrmvh8JEcewr4CUBwqQLMeNQwy+BKZga4+Wtpw17HF RUCkKKNBnlULP/qhauEKX1q0dSHlYFelnxDwVndbpAjQf6VafSNx7hZiTPoNso48Pk4p 9k7Df1/TIXG0DENa1FUEZZqZa+Qyk0tQL3buaBZZOhTKHt3EawNuS9/lLdhfB0GqI5lT 55mlFayEkqss//LTy8i5d5pjGW2lSRE+CjBsjES9DgdpPJakImBNorfiYTNPggObK54r tMhsD8WsXyXzIiZ+glG4/OTQH3PIfXKgyhFRiWBWTzCSsXCJ1Zqb5gmHkW19eloMlWSo /cbA== Received: by 10.224.115.208 with SMTP id j16mr10651336qaq.54.1346186796368; Tue, 28 Aug 2012 13:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.73 with HTTP; Tue, 28 Aug 2012 13:46:06 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503CD692.4020007@mitre.org> From: Brian Campbell Date: Tue, 28 Aug 2012 14:46:06 -0600 Message-ID: To: Breno de Medeiros Content-Type: multipart/alternative; boundary=20cf3074b1becc844b04c85989a8 X-Gm-Message-State: ALoCoQkSwpBBvSuMAZQKtAl3M4uAfRsvhUTBQa9odCEYKeJJ+sBvzgAljmBu0PCJOJTSfcC4tIiO Cc: Axel Nennker , Jim Schaad , Mike Jones , "jose@ietf.org" , John Bradley , Justin Richer Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:46:39 -0000 --20cf3074b1becc844b04c85989a8 Content-Type: text/plain; charset=ISO-8859-1 Isn't the pool question really about JOSE (this is the JOSE list after all) and if a nonce or timestamp type thing should be defined in JWE/JWS as a Reserved Header Parameter Name? I don't think it can be said that we already have an issued time defined. "iat" (Issued At) is a claim defined in JWT. That's all together a different thing than a JOSE header and I don't see anything like it anywhere in the JOSE docs. JWT is a layer above JOSE and, while there is a lot of overlap of people, is being developed in a completely different WG. I'm, at this point, saying we need this thing but rather just trying to clarify the question. On Tue, Aug 28, 2012 at 1:06 PM, Breno de Medeiros wrote: > I agree that this should be looked independently of oauth2. > > Nonce is a generally used concept in crypto, though sometimes protocol > designers have called for nonces with bad outcomes because the difficulty > of implementing nonce-checking was disregarded. However, difficulties to > implement nonces in general are not relevant if there is a compelling use > case that is able to leverage nonces effectively. > > As for timestamps: we already have issued time and the nonce can embed a > timestamp additionally. So I don't think we need to concern ourselves with > timestamps when considering nonces. > > > > > On Tue, Aug 28, 2012 at 8:09 AM, John Bradley wrote: > >> In OAuth 2 state gets overloaded with a bunch of things from preventing >> XSRF to providing a handle to look up who the the authorization request was >> sent to. >> >> In Connect we added a nonce sent by client that is returned inside the >> signed id_token (JWT) to allow the client to detect replay, and optionally >> reference a specific browser session that presents the id_token. >> >> The nonce I suggested for JOSE is not ether of those. >> >> I used nonce in the sense that it is used with stream cyphers when the >> same key is used over multiple messages. >> >> JOSE will be used for more than OAuth and JWT. There are cases where >> adding entropy to the header will be a security benefit. I would like to >> have a standard claim for doing that. >> If people want to call it something else that is fine, but it is a nonce >> by definition. >> If used it should be a random or pseudo random value that is time variant >> with sufficient granularity to ensure a nonce is used only once. >> >> John B. >> >> On 2012-08-28, at 10:32 AM, Justin Richer wrote: >> >> On 08/25/2012 03:37 AM, Axel Nennker wrote: >> >> To clarify: What is the base specification that Jim mentioned? >> Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ? >> >> Would somebody please present a use-case for either nonce or timestamp? >> If a jwt is used with oauth2 then what is the difference between nonce >> and state? Nonce would be signed while state is not? >> >> >> Nonce would generally be generated by the entity creating the token. >> State in OAuth is generated by the client, and would only be protected if >> the client had a means to make a signed request to the server, using either >> a MAC binding or a JWT-based OIDC-style RequestObject. >> >> -- Justin >> >> I guess I am missing some information that those in the room who voted >> "yes" had? >> >> Axel >> >> 2012/8/25 Mike Jones >> >>> I'll note for discussion purposes that a nonce and a timestamp are not >>> the same thing (although sometimes they are used to achieve similar/related >>> goals). A nonce tends to be an opaque value that must be preserved across >>> the communication. Whereas a timestamp typically has defined semantics - >>> sometimes simply a non-decreasing integer value - and sometimes a >>> representation of time, and then, sometimes with a uniqueness requirement. >>> >>> For discussion purposes, I'll say that the simplest thing for us to do >>> (should we decide to do anything in this regard) would be to define the >>> nonce as an opaque string value that must be preserved. >>> >>> We could also define a timestamp parameter, but as I wrote above, that >>> would likely require us to specify additional semantics - starting with >>> whether it's a non-decreasing integer or a representation of a time value. >>> This seems much harder to define and possibly to use than a nonce. >>> >>> Would it make sense to define a nonce parameter now and hold off on >>> defining a timestamp parameter until there's a clear demonstrated use case >>> for which a nonce is not sufficient? That would be my personal >>> recommendation. >>> >>> Best wishes, >>> -- Mike >>> >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >>> Jim Schaad >>> Sent: Friday, August 17, 2012 12:05 AM >>> To: jose@ietf.org >>> Subject: [jose] POLL: Nonce/Timestamp parameter >>> >>> >>> >>> If you voted at the face-2-face please do not vote again. If you want >>> to provide comments please change the title from POLL to DISCUSS. >>> >>> Do we need to define a nonce/timestamp parameter in the base >>> specification? >>> >>> >>> >>> Room vote: 6 yes, 0 no, 1 discuss >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> _______________________________________________ >> jose mailing listjose@ietf.orghttps://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> 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 >> >> > > > -- > --Breno > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --20cf3074b1becc844b04c85989a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isn't the pool question really about JOSE (this is the JOSE list after = all) and if a nonce or timestamp type thing should be defined in JWE/JWS as= a Reserved Header Parameter Name?=A0

I don't think it can be s= aid that we already have an issued time defined. "iat" (Issued At= ) is a claim defined in JWT. That's all together a different thing than= a JOSE header and I don't see anything like it anywhere in the JOSE do= cs. JWT is a layer above JOSE and, while there is a lot of overlap of peopl= e, is being developed in a completely different WG.

I'm, at this point, saying we need this thing but rather just tryin= g to clarify the question.

On Tue, Aug 2= 8, 2012 at 1:06 PM, Breno de Medeiros <breno@google.com> wrot= e:
I agree that this should be looked independe= ntly of oauth2.

Nonce is a generally used concept in cry= pto, though sometimes protocol designers have called for nonces with bad ou= tcomes because the difficulty of implementing nonce-checking was disregarde= d. However, difficulties to implement nonces in general are not relevant if= there is a compelling use case that is able to leverage nonces effectively= .

As for timestamps: we already have issued time and the = nonce can embed a timestamp additionally. So I don't think we need to c= oncern ourselves with timestamps when considering nonces.



=
On Tue, Aug 28, 2012 at 8:09 AM, John Bradle= y <ve7jtb@ve7jtb.com> wrote:
In OAuth= 2 state gets overloaded with a bunch of things from preventing XSRF to pro= viding a handle to look up who the the authorization request was sent to.
In Connect we added a nonce sent by client that is returned = inside the signed id_token (JWT) to allow the client to detect replay, and = optionally reference a specific browser session that presents the id_token.=

The nonce I suggested for JOSE is not ether of those. = =A0

I used nonce in the sense that it is used with= stream cyphers when the same key is used over multiple messages.

JOSE will be used for more than OAuth and JWT. =A0 There are= cases where adding entropy to the header will be a security benefit. =A0I = would like to have a standard claim for doing that.
If people wan= t to call it something else that is fine, but it is a nonce by definition.<= /div>
If used it should be a random or pseudo random value that is time vari= ant with sufficient granularity to ensure a nonce is used only once.
<= div>
John B.

On 2012-08-28, at 10:32 AM, Justin Richer <jricher@mitre.org> wrote:
<= br>
=20 =20 =20
On 08/25/2012 03:37 AM, Axel Nennker wrote:
=20 To clarify: What is the base specification that Jim mentioned?
Is it: http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-03 ?

Would somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?


Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.

=A0-- Justin

I guess I am missing some information that th= ose in the room who voted "yes" had?

Axel

2012/8/25 Mike Jones <= ;Michael.J= ones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestam= p are not the same thing (although sometimes they are used to achieve similar/related goals). =A0A nonce tends to be an opaque value that must be preserved across the communication. =A0Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value. =A0This seems much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient? =A0That would be my personal recommendation.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 B= est wishes,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -= - Mike

-----Original Message-----
From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.= org
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again. =A0If you want to provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?



Room vote: =A06 yes, 0 no, 1 discuss


_______________________________________________
jose mailing list
jose@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/jose



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

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


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




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


--20cf3074b1becc844b04c85989a8-- From jricher@mitre.org Tue Aug 28 14:16:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD7C11E80E7 for ; Tue, 28 Aug 2012 14:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8mzNE7-KfLe for ; Tue, 28 Aug 2012 14:16:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED511E80A5 for ; Tue, 28 Aug 2012 14:16:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFBC221B0C2D; Tue, 28 Aug 2012 17:16:00 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9840A21B08A0; Tue, 28 Aug 2012 17:16:00 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 Aug 2012 17:16:00 -0400 Message-ID: <503D34B4.9040606@mitre.org> Date: Tue, 28 Aug 2012 17:14:28 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Campbell References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503CD692.4020007@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010303090806060809000209" X-Originating-IP: [129.83.31.58] Cc: Axel Nennker , Jim Schaad , Breno de Medeiros , Mike Jones , "jose@ietf.org" , John Bradley Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:16:04 -0000 --------------010303090806060809000209 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit So the obvious question (to me) is whether or not the claim should move to the JOSE layer. -- Justin On 08/28/2012 04:46 PM, Brian Campbell wrote: > Isn't the pool question really about JOSE (this is the JOSE list after > all) and if a nonce or timestamp type thing should be defined in > JWE/JWS as a Reserved Header Parameter Name? > > I don't think it can be said that we already have an issued time > defined. "iat" (Issued At) is a claim defined in JWT. That's all > together a different thing than a JOSE header and I don't see anything > like it anywhere in the JOSE docs. JWT is a layer above JOSE and, > while there is a lot of overlap of people, is being developed in a > completely different WG. > > I'm, at this point, saying we need this thing but rather just trying > to clarify the question. > > On Tue, Aug 28, 2012 at 1:06 PM, Breno de Medeiros > wrote: > > I agree that this should be looked independently of oauth2. > > Nonce is a generally used concept in crypto, though sometimes > protocol designers have called for nonces with bad outcomes > because the difficulty of implementing nonce-checking was > disregarded. However, difficulties to implement nonces in general > are not relevant if there is a compelling use case that is able to > leverage nonces effectively. > > As for timestamps: we already have issued time and the nonce can > embed a timestamp additionally. So I don't think we need to > concern ourselves with timestamps when considering nonces. > > > > > On Tue, Aug 28, 2012 at 8:09 AM, John Bradley > wrote: > > In OAuth 2 state gets overloaded with a bunch of things from > preventing XSRF to providing a handle to look up who the the > authorization request was sent to. > > In Connect we added a nonce sent by client that is returned > inside the signed id_token (JWT) to allow the client to detect > replay, and optionally reference a specific browser session > that presents the id_token. > > The nonce I suggested for JOSE is not ether of those. > > I used nonce in the sense that it is used with stream cyphers > when the same key is used over multiple messages. > > JOSE will be used for more than OAuth and JWT. There are > cases where adding entropy to the header will be a security > benefit. I would like to have a standard claim for doing that. > If people want to call it something else that is fine, but it > is a nonce by definition. > If used it should be a random or pseudo random value that is > time variant with sufficient granularity to ensure a nonce is > used only once. > > John B. > > On 2012-08-28, at 10:32 AM, Justin Richer > wrote: > >> On 08/25/2012 03:37 AM, Axel Nennker wrote: >>> To clarify: What is the base specification that Jim mentioned? >>> Is it: >>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ? >>> >>> Would somebody please present a use-case for either nonce or >>> timestamp? >>> If a jwt is used with oauth2 then what is the difference >>> between nonce and state? Nonce would be signed while state >>> is not? >>> >> >> Nonce would generally be generated by the entity creating the >> token. State in OAuth is generated by the client, and would >> only be protected if the client had a means to make a signed >> request to the server, using either a MAC binding or a >> JWT-based OIDC-style RequestObject. >> >> -- Justin >> >>> I guess I am missing some information that those in the room >>> who voted "yes" had? >>> >>> Axel >>> >>> 2012/8/25 Mike Jones >> > >>> >>> I'll note for discussion purposes that a nonce and a >>> timestamp are not the same thing (although sometimes >>> they are used to achieve similar/related goals). A >>> nonce tends to be an opaque value that must be preserved >>> across the communication. Whereas a timestamp typically >>> has defined semantics - sometimes simply a >>> non-decreasing integer value - and sometimes a >>> representation of time, and then, sometimes with a >>> uniqueness requirement. >>> >>> For discussion purposes, I'll say that the simplest >>> thing for us to do (should we decide to do anything in >>> this regard) would be to define the nonce as an opaque >>> string value that must be preserved. >>> >>> We could also define a timestamp parameter, but as I >>> wrote above, that would likely require us to specify >>> additional semantics - starting with whether it's a >>> non-decreasing integer or a representation of a time >>> value. This seems much harder to define and possibly to >>> use than a nonce. >>> >>> Would it make sense to define a nonce parameter now and >>> hold off on defining a timestamp parameter until there's >>> a clear demonstrated use case for which a nonce is not >>> sufficient? That would be my personal recommendation. >>> >>> Best wishes, >>> -- Mike >>> >>> -----Original Message----- >>> From: jose-bounces@ietf.org >>> >>> [mailto:jose-bounces@ietf.org >>> ] On Behalf Of Jim Schaad >>> Sent: Friday, August 17, 2012 12:05 AM >>> To: jose@ietf.org >>> Subject: [jose] POLL: Nonce/Timestamp parameter >>> >>> >>> >>> If you voted at the face-2-face please do not vote >>> again. If you want to provide comments please change >>> the title from POLL to DISCUSS. >>> >>> Do we need to define a nonce/timestamp parameter in the >>> base specification? >>> >>> >>> >>> Room vote: 6 yes, 0 no, 1 discuss >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > -- > --Breno > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --------------010303090806060809000209 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
So the obvious question (to me) is whether or not the claim should move to the JOSE layer.

 -- Justin

On 08/28/2012 04:46 PM, Brian Campbell wrote:
Isn't the pool question really about JOSE (this is the JOSE list after all) and if a nonce or timestamp type thing should be defined in JWE/JWS as a Reserved Header Parameter Name? 

I don't think it can be said that we already have an issued time defined. "iat" (Issued At) is a claim defined in JWT. That's all together a different thing than a JOSE header and I don't see anything like it anywhere in the JOSE docs. JWT is a layer above JOSE and, while there is a lot of overlap of people, is being developed in a completely different WG.

I'm, at this point, saying we need this thing but rather just trying to clarify the question.

On Tue, Aug 28, 2012 at 1:06 PM, Breno de Medeiros <breno@google.com> wrote:
I agree that this should be looked independently of oauth2.

Nonce is a generally used concept in crypto, though sometimes protocol designers have called for nonces with bad outcomes because the difficulty of implementing nonce-checking was disregarded. However, difficulties to implement nonces in general are not relevant if there is a compelling use case that is able to leverage nonces effectively.

As for timestamps: we already have issued time and the nonce can embed a timestamp additionally. So I don't think we need to concern ourselves with timestamps when considering nonces.




On Tue, Aug 28, 2012 at 8:09 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In OAuth 2 state gets overloaded with a bunch of things from preventing XSRF to providing a handle to look up who the the authorization request was sent to.

In Connect we added a nonce sent by client that is returned inside the signed id_token (JWT) to allow the client to detect replay, and optionally reference a specific browser session that presents the id_token.

The nonce I suggested for JOSE is not ether of those.  

I used nonce in the sense that it is used with stream cyphers when the same key is used over multiple messages.

JOSE will be used for more than OAuth and JWT.   There are cases where adding entropy to the header will be a security benefit.  I would like to have a standard claim for doing that.
If people want to call it something else that is fine, but it is a nonce by definition.
If used it should be a random or pseudo random value that is time variant with sufficient granularity to ensure a nonce is used only once.

John B.

On 2012-08-28, at 10:32 AM, Justin Richer <jricher@mitre.org> wrote:

On 08/25/2012 03:37 AM, Axel Nennker wrote:
To clarify: What is the base specification that Jim mentioned?
Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?

Would somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?


Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.

 -- Justin

I guess I am missing some information that those in the room who voted "yes" had?

Axel

2012/8/25 Mike Jones <Michael.Jones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestamp are not the same thing (although sometimes they are used to achieve similar/related goals).  A nonce tends to be an opaque value that must be preserved across the communication.  Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value.  This seems much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient?  That would be my personal recommendation.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.org
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?



Room vote:  6 yes, 0 no, 1 discuss


_______________________________________________
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



_______________________________________________
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


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




--
--Breno


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



--------------010303090806060809000209-- From Michael.Jones@microsoft.com Tue Aug 28 15:12:34 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD69A11E8107 for ; Tue, 28 Aug 2012 15:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raZ1hobs6WF4 for ; Tue, 28 Aug 2012 15:12:32 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id CD1D321F84D3 for ; Tue, 28 Aug 2012 15:12:31 -0700 (PDT) Received: from mail24-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 22:12:30 +0000 Received: from mail24-db3 (localhost [127.0.0.1]) by mail24-db3-R.bigfish.com (Postfix) with ESMTP id B8D693200FB; Tue, 28 Aug 2012 22:12:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371Ic85fh542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail24-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail24-db3 (localhost.localdomain [127.0.0.1]) by mail24-db3 (MessageSwitch) id 1346191948283925_3135; Tue, 28 Aug 2012 22:12:28 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.253]) by mail24-db3.bigfish.com (Postfix) with ESMTP id 2D91F24004E; Tue, 28 Aug 2012 22:12:28 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 22:12:25 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 22:12:23 +0000 From: Mike Jones To: Karen O'Donoghue , Jim Schaad Thread-Topic: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters Thread-Index: Ac18lJzBZ7lrugc/SlOdnZgODbmGPwAnSfqAAHM38mABl1CGAAADS3Lw Importance: high X-Priority: 1 Date: Tue, 28 Aug 2012 22:12:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AD5CF@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366797E0F@TK5EX14MBXC284.redmond.corp.microsoft.com> <024001cd7d31$ca406620$5ec13260$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943667A1FD3@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667AD5CFTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Brian Campbell , "jose@ietf.org" Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 22:12:34 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667AD5CFTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Karen or Jim, would you mind resending this poll question in a way that the= question and the room count match? I agree with Brian that the current si= tuation is incredibly confusing and I believe that the confusion is interfe= ring with us getting unambiguous results for this question. When you resend it, could you maybe also give people who've already replied= an opportunity to reconfirm their positions? It wouldn't surprise me if s= ome of the votes changed once the ambiguity is cleared up. Thanks a bu= nch, -- Mike From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Tuesday, August 28, 2012 1:30 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters I, for one, am very confused by this one. I just went with the intention to= vote in favor of using widely deployed default parameters (like SHA1) but = after reading this and the poll thread again, I wasn't sure what a yes or n= o vote was actually for. On Mon, Aug 20, 2012 at 12:08 PM, Mike Jones > wrote: Just to avoid confusion, could you or Karen please resend the poll question= with the correct room count? Thanks, -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, August 18, 2012 4:08 AM To: Mike Jones; jose@ietf.org Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters I believe that I switched the question between the room and here. The ques= tion in the room was should we switch FROM SHA1 to something else. The room count should be reversed with the revised question. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Saturday, August 18, 2012 1:53 AM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters > > I believe that the results below are recorded incorrectly. I know > that I personally voted that we use the default parameters as widely > deployed (SHA-1), so the results below can not be right. I believe > that the results were > likely actually: > > Room vote: 5 yes, 0 no, 3 discuss > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf > Of Jim Schaad > Sent: Friday, August 17, 2012 12:05 AM > To: jose@ietf.org > Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters > > > > If you voted at the face-2-face please do not vote again. If you want > to provide comments please change the title from POLL to DISCUSS. > > Should SHA1 be the default parameters for these algorithms? > > > Room vote: 0 yes, 5 no, 3 discuss > > > _______________________________________________ > 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 --_000_4E1F6AAD24975D4BA5B1680429673943667AD5CFTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Karen or Jim, would you m= ind resending this poll question in a way that the question and the room co= unt match?  I agree with Brian that the current situation is incredibly confusing and I believe that the confusion is interfering wi= th us getting unambiguous results for this question.

 <= /p>

When you resend it, could= you maybe also give people who’ve already replied an opportunity to = reconfirm their positions?  It wouldn’t surprise me if some of the votes changed once the ambiguity is cleared up.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Thanks a bunch,<= /o:p>

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

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Tuesday, August 28, 2012 1:30 PM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters

 

I, for one, am very c= onfused by this one. I just went with the intention to vote in favor of usi= ng widely deployed default parameters (like SHA1) but after reading this an= d the poll thread again, I wasn't sure what a yes or no vote was actually for.

On Mon, Aug 20, 2012 at 12:08 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Just to avoid confusion, could you or Karen please r= esend the poll question with the correct room count?

                     = ;           Thanks,
                     = ;           -- Mike


-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Saturday, August 18, 2012 4:08 AM
To: Mike Jones; jose@iet= f.org
Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters

I believe that I switched the question between the room and here.  The= question in the room was should we switch FROM SHA1 to something else.

The room count should be reversed with the revised question.

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Saturday, August 18, 2012 1:53 AM
> To: Jim Schaad; jos= e@ietf.org
> Subject: RE: [jose] DISCUSS: RSA-OAEP/RSA-PSS default parameters
>
> I believe that the results below are recorded incorrectly.  I kno= w
> that I personally voted that we use the default parameters as widely > deployed (SHA-1), so the results below can not be right.  I belie= ve
> that the
results were
> likely actually:
>
> Room vote:  5 yes, 0 no, 3 discuss
>
>                     =           -- Mike
>
> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> Of Jim Schaad
> Sent: Friday, August 17, 2012 12:05 AM
> To: jose@ietf.org
> Subject: [jose] POLL: RSA-OAEP/RSA-PSS default parameters
>
> <CHAIR>
>
> If you voted at the face-2-face please do not vote again.  If you= want
> to provide comments please change the title from POLL to DISCUSS.
>
> Should SHA1 be the default parameters for these algorithms?
>
>
> Room vote:  0 yes, 5 no, 3 discuss
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose




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

 

--_000_4E1F6AAD24975D4BA5B1680429673943667AD5CFTK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Tue Aug 28 15:48:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFB321F856D for ; Tue, 28 Aug 2012 15:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.838 X-Spam-Level: X-Spam-Status: No, score=-3.838 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbYH7oWham0M for ; Tue, 28 Aug 2012 15:48:53 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id A294B21F855D for ; Tue, 28 Aug 2012 15:48:52 -0700 (PDT) Received: from mail107-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 22:48:51 +0000 Received: from mail107-am1 (localhost [127.0.0.1]) by mail107-am1-R.bigfish.com (Postfix) with ESMTP id 5CD1A2600EE; Tue, 28 Aug 2012 22:48:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: VS-14(z1091vz9371I148cI542M14ffIzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail107-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail107-am1 (localhost.localdomain [127.0.0.1]) by mail107-am1 (MessageSwitch) id 1346194129431156_29804; Tue, 28 Aug 2012 22:48:49 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.253]) by mail107-am1.bigfish.com (Postfix) with ESMTP id 67075460045; Tue, 28 Aug 2012 22:48:49 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 22:48:49 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Tue, 28 Aug 2012 22:48:45 +0000 From: Mike Jones To: hideki nara , "jose@ietf.org" Thread-Topic: [jose] JWS header x5c is a JSON array? Thread-Index: Ac2Fb0dCEw2H+uSASnGsbG/lpi/LAQ== Date: Tue, 28 Aug 2012 22:48:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AD75D@TK5EX14MBXC284.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Jim Schaad Subject: Re: [jose] JWS header x5c is a JSON array? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 22:48:53 -0000 Thanks for pointing out this wording ambiguity, Hideki. As you point out -= it's not a JSON array - at the JSON level, it's a text string, per http://= tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B. I'll= reword accordingly in the next revision. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of hid= eki nara Sent: Monday, July 16, 2012 10:27 PM To: jose@ietf.org Cc: Jim Schaad Subject: [jose] JWS header x5c is a JSON arrary? Hi all, In http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section= -4.1.6 , "The certificate or certificate chain is represented as an array of certificate values. " But, Appendix B gives us a text stream which seems to be the same one as th= e return from "x5u" . (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-= B ) Am I missing anything between lines ? I like the same format as the return of x5u anyway. --- hdknr _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Tue Aug 28 20:40:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AC321F841A for ; Tue, 28 Aug 2012 20:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBQpw2SJeAgI for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id C3FDB11E808A for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 1F9582CA19; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , , "Mike Jones" References: <255B9BB34FB7D647A506DC292726F6E114F97B728F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F97B728F@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 28 Aug 2012 20:38:50 -0700 Message-ID: <05f701cd8597$d0a802c0$71f80840$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05F8_01CD855D.244B2690" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFisr/sze6uO+MXLJ/jTWkit+C6RZhE8xyg Content-Language: en-us Subject: Re: [jose] Open Issue: Representing the JWE IV as a dot-separated element X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:40:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05F8_01CD855D.244B2690 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have several problems with moving the IV and/or the tag into the = ciphertext field. =20 1. I am firmly of the belief that one needs to be able to have = key management on the key used in the MAC processing. At the present = time, this can only be done by defining a new algorithm that will be a = null encryption with authentication algorithm. This would play havoc if = you wanted to do detached content as all the applications would need to = know about the IV and authentication tags that are attached to the = content rather than having them be separate from the content. I = realize that this is a minority viewpoint. 2. This should only be an issue for the simple dot version of the = encoding; if you do the multiple recipient versions then the second = layer of base64 application should not be required. Thus no double = encoding. Again a minority viewpoint. 3. This does not solve the same problem for all of the other = binary fields that can occur in headers. As compactness in the dot = encoded format is supposed to be a requirement, this this problem needs = to be addressed for ALL possible binary fields. An example of a much = larger binary field would be the ephemeral DH key. =20 While the group does not agree with me on the first two issues, I think = that it should respect the last one. One possible solution is to use = the current second dot field as a binary dump rather than for a single = purpose. One would then add a new header for the wrapped key and = specify an offset and a length for any binary data blob which occurs in = that binary data field. Another would be to allow for multiple binary = blobs and just provide the index of the blob that contains the data in = question. =20 Jim =20 =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Manger, James H Sent: Sunday, July 29, 2012 6:50 PM To: jose@ietf.org Subject: Re: [jose] Open Issue: Representing the JWE IV as a = dot-separated element =20 Make the IV a prefix of the ciphertext and you save another couple of = bytes. Plus the IV length would no longer be defined twice (firstly by = the alg definition; secondly by the length of the IV field in the = message), which avoids a potential inconsistency. =20 While we are doing that, may as well make the AEAD authentication tag a = suffix of the ciphertext. =20 -- James Manger =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones Sent: Saturday, 28 July 2012 8:49 AM To: jose@ietf.org Subject: [jose] Open Issue: Representing the JWE IV as a dot-separated = element =20 All the JWE block encryption algorithms we=E2=80=99re using require an = Initialization Vector. I=E2=80=99d originally put the IV in the JWE = header because I thought it would be optional, but in practice, = it=E2=80=99s not. As a result, we=E2=80=99re always double base64url = encoding required content. =20 I did an investigation and we could save 15 characters in the GCM = example at = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section= -3.1 and 17 characters in the CBC example at = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section= -3.2 if we were to represent the IV as another dot-separated element = rather than putting it in the header and double base64url encoding it. =20 Since size matters a lot in some use cases, we should consider whether = to do this. =20 I=E2=80=99ll add it to the open issues list for us to discuss in = Vancouver. =20 -- Mike =20 ------=_NextPart_000_05F8_01CD855D.244B2690 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have several problems with moving the IV = and/or the tag into the ciphertext field.

 

1.       = =C2=A0I am = firmly of the belief that one needs to be able to have key management on = the key used in the MAC processing. =C2=A0At the present time, this can = only be done by defining a new algorithm that will be a null encryption = with authentication algorithm. =C2=A0This would play havoc if you wanted = to do detached content as all the applications would need to know about = the IV and authentication tags that are attached to the content rather = than having them be separate from the content.=C2=A0=C2=A0 I realize = that this is a minority viewpoint.

2.       = This should = only be an issue for the simple dot version of the encoding; if you do = the multiple recipient versions then the second layer of base64 = application should not be required.=C2=A0 Thus no double encoding.=C2=A0 = Again a minority viewpoint.

3.       = This does = not solve the same problem for all of the other binary fields that can = occur in headers. =C2=A0As compactness in the dot encoded format is = supposed to be a requirement, this this problem needs to be addressed = for ALL possible binary fields.=C2=A0 An example of a much larger binary = field would be the ephemeral DH key.

 

While the group does not = agree with me on the first two issues, I think that it should respect = the last one.=C2=A0 One possible solution is to use the current second = dot field as a binary dump rather than for a single purpose.=C2=A0 One = would then add a new header for the wrapped key and specify an offset = and a length for any binary data blob which occurs in that binary data = field. =C2=A0=C2=A0Another would be to allow for multiple binary blobs = and just provide the index of the blob that contains the data in = question.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Manger, James H
Sent: Sunday, July 29, 2012 6:50 = PM
To: jose@ietf.org
Subject: Re: [jose] Open Issue: = Representing the JWE IV as a dot-separated = element

 

Make the IV a prefix of the = ciphertext and you save another couple of bytes. Plus the IV length = would no longer be defined twice (firstly by the alg definition; = secondly by the length of the IV field in the message), which avoids a = potential inconsistency.

 

While we = are doing that, may as well make the AEAD authentication tag a suffix of = the ciphertext.

 

--

James = Manger

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Mike Jones
Sent: Saturday, 28 = July 2012 8:49 AM
To: jose@ietf.org
Subject: = [jose] Open Issue: Representing the JWE IV as a dot-separated = element

 

All the = JWE block encryption algorithms we=E2=80=99re using require an = Initialization Vector.  I=E2=80=99d originally put the IV in the = JWE header because I thought it would be optional, but in practice, = it=E2=80=99s not.  As a result, we=E2=80=99re always double = base64url encoding required content.

 

I did an = investigation and we could save 15 characters in the GCM example at http://tools.ietf.org/html/draft-ietf-jose-json-web-encrypt= ion-04#section-3.1 and 17 characters in the CBC example at http://tools.ietf.org/html/draft-ietf-jose-json-web-encrypt= ion-04#section-3.2 if we were to represent the IV as another = dot-separated element rather than putting it in the header and double = base64url encoding it.

 

Since size = matters a lot in some use cases, we should consider whether to do = this.

 

I=E2=80=99ll add it to the open issues list for us to = discuss in Vancouver.

 

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

 

------=_NextPart_000_05F8_01CD855D.244B2690-- From ietf@augustcellars.com Tue Aug 28 20:40:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C9121F841A for ; Tue, 28 Aug 2012 20:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqtF7yv1-kTl for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2921F841C for ; Tue, 28 Aug 2012 20:40:14 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D56FC2C9F4; Tue, 28 Aug 2012 20:40:12 -0700 (PDT) From: "Jim Schaad" To: "'Dick Hardt'" , References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com> In-Reply-To: <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com> Date: Tue, 28 Aug 2012 20:38:20 -0700 Message-ID: <05f101cd8597$cff358c0$6fda0a40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05F2_01CD855D.239718D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+fWRNYMYi661kYmFSaxgdrCg93gEzurJ7AjUoCs0BvUKSxAIEi9JxArm+c1MCJORRUZctGIvg Content-Language: en-us Cc: beaton@google.com, jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 03:40:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05F2_01CD855D.239718D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The question from my point of view is that common fields from many structures should potentially be supported in the base specification so that they can be common rather than having each structure define them separately. This is only an issue if one wishes them to be placed in the header structure and not in the data structure. If one is looking at signing an unstructured data object - such as a file - then it becomes difficult to have the fields such as a time that it was signed be part of the file itself, especially if one is applying multiple signatures at different times. This is not an issue for the token specification but could be for other uses of the signature or encryption specifications. I would agree that "iat" is a timestamp for the purposes of this conversation. If one wanted a formalized timestamp from a third party authority then a totally different way of going about it would be required. I chose the term nonce or timestamp because both had been discussed in the past without any specific resolution about what is needed. Jim From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, August 27, 2012 2:55 PM To: Axel.Nennker@telekom.de Cc: dick.hardt@gmail.com; beaton@google.com; ietf@augustcellars.com; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter I was considering "iat" to be the timestamp. I was not thinking there would be an additional timestamp. On Aug 27, 2012, at 2:13 PM, wrote: We have exp https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.1 and iat https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.3 in JWT. Why do we need a timestamp? Replay attacks of the same jwt can be mitigated through the jti claim https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.7 What do timestamp and nonce add to these? Axel From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, August 27, 2012 10:23 PM To: Brian Eaton Cc: Nennker, Axel; Jim Schaad; jose@ietf.org Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt wrote: I have an application for JWT that is not OAuth2. Should nonce and timestamp logic go in the application level protocol? I prefer to NOT have the application level deal with token validity. Having said that, nonce's are difficult to implement at scale and I have heard of many sites that don't implement them fully. Nonce alone can't be implemented efficiently. You have to have time stamps as well, otherwise you are stuck storing ever nonce you've ever seen, forever. Even nonce + time stamp is challenging in distributed systems. It adds a lot of complexity. That complexity is sometimes merited, but not always. Thanks for confirming my statement. I have stopped using nonce and only use time stamps lately and have made the system relatively stateless so that a second submission of the token is ok. That may not work for everyone, but I have found that architecture to be easier to implement and scale. ------=_NextPart_000_05F2_01CD855D.239718D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The question from my point of view is that common fields from many = structures should potentially be supported in the base specification so = that they can be common rather than having each structure define them = separately.  This is only an issue if one wishes them to be placed = in the header structure and not in the data structure.  =

 

If one is looking at signing an unstructured data object – such = as a file – then it becomes difficult to have the fields such as a = time that it was signed be part of the file itself, especially if one is = applying multiple signatures at different times.  This is not an = issue for the token specification but could be for other uses of the = signature or encryption specifications.

 

I would agree that “iat” is a timestamp for the purposes = of this conversation.  If one wanted a formalized timestamp from a = third party authority then a totally different way of going about it = would be required.  I chose the term nonce or timestamp because = both had been discussed in the past without any specific resolution = about what is needed.

 

Jim

 

 

From:= = Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Monday, August = 27, 2012 2:55 PM
To: Axel.Nennker@telekom.de
Cc: = dick.hardt@gmail.com; beaton@google.com; ietf@augustcellars.com; = jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp = parameter

 

I was = considering "iat" to be the timestamp. I was not thinking = there would be an additional timestamp.

 

On = Aug 27, 2012, at 2:13 PM, <Axel.Nennker@telekom.de> = wrote:



We have = exp

and = iat

in JWT. = Why do we need a timestamp?

 =

Replay = attacks of the same jwt can be mitigated through the jti = claim

 =

What do = timestamp and nonce add to these?

 =

Axel

 =

 

 

From:=  Dick Hardt = [mailto:dick.hardt@gmail.co= m] 
Sent: Monday, August 27, 2012 10:23 = PM
To: Brian = Eaton
Cc: Nennker, Axel; Jim Schaad; jose@ietf.org
Subject: Re: [jose] DISCUSS: = Nonce/Timestamp parameter

 

 

On Aug 27, 2012, at 1:06 PM, Brian Eaton = wrote:




On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

I have an application for JWT that is not = OAuth2.

 

Should nonce and timestamp logic go in the application = level protocol?

 

I prefer to NOT have the application level deal with = token validity.




 

Having said that, nonce's are difficult to implement = at scale and I have heard of many sites that don't implement them = fully.

 

Nonce alone can't be implemented efficiently. =  You have to have time stamps as well, otherwise you are stuck = storing ever nonce you've ever seen, = forever.

 

Even nonce + time stamp is challenging in distributed = systems.  It adds a lot of complexity.  That complexity is = sometimes merited, but not = always.

 

Thanks for confirming my = statement.

 

I have stopped using nonce and only use time stamps = lately and have made the system relatively stateless so that a second = submission of the token is ok. That may not work for everyone, but I = have found that architecture to be easier to implement and = scale.

 

------=_NextPart_000_05F2_01CD855D.239718D0-- From matake@gmail.com Tue Aug 28 21:45:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD9211E809C for ; Tue, 28 Aug 2012 21:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqkXMVzhWWSR for ; Tue, 28 Aug 2012 21:45:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9C11E80BA for ; Tue, 28 Aug 2012 21:45:14 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so413879pbb.31 for ; Tue, 28 Aug 2012 21:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uA7qPQRLj4gMpuSR5Gu7aAqBXlzM72DyFFhvEdwu7VM=; b=RMGgfy1VW4cfa20ObfGig6xEa/4Ds4mcHG0gRLQ3ejhDsQK5oc/5cDV5IQlT7qGipr sWVvcfOuaINbqzoIMdHKM355GnJAOY5wk9tVq7mYj46JHbaiQVdOJUjRXPjBFai53E3i QUi4YNH5/YNvYovo0ajQzwXLdb8K9iiasvuCa9bZSSbf9f8cMqCJWx/W4UlGdEcwMkTI TFHYREQTDAV49iX0gaxCU/uxvxjrmBN40xVJ8SJFcufHa5HYIWsD8VLAKWsezFcIc9Wt tN7ORIzRgQ1NmrwfPsQYIYV5BBQg3FwUKanxBF0UyxeoP0WrVT7G9GGEWW3VeDwgDh30 uahg== Received: by 10.68.240.138 with SMTP id wa10mr1576743pbc.145.1346215513663; Tue, 28 Aug 2012 21:45:13 -0700 (PDT) Received: from tov.cyberagent.co.jp (124x35x85x170.ap124.ftth.ucom.ne.jp. [124.35.85.170]) by mx.google.com with ESMTPS id sr3sm18492746pbc.44.2012.08.28.21.45.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 21:45:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: nov matake In-Reply-To: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> Date: Wed, 29 Aug 2012 13:45:10 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <000001cd7c46$c2ecb4a0$48c61de0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1486) Cc: jose@ietf.org Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:45:16 -0000 YES On 2012/08/17, at 16:05, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Is the current text for KID sufficiently defined and understood? > > > Room vote: 2 yes, 0 no, 1 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Tue Aug 28 21:45:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C766C21F84FD for ; Tue, 28 Aug 2012 21:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlg6HOZSnYPR for ; Tue, 28 Aug 2012 21:45:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4131421F846E for ; Tue, 28 Aug 2012 21:45:28 -0700 (PDT) Received: by dadf8 with SMTP id f8so111289dad.31 for ; Tue, 28 Aug 2012 21:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NFbuJDXF7Lc8B9SJ3RH5bHDBpw/6dqXWr2Fwm0Q5yrA=; b=FT5OIlwKGd0UVinoISC1CwrZg+MTYswEU/a+aUN8kJxq7DLb1HNn8VlkrvQfR5kVe/ BTuVMtxTbZQLXBg++Efs2CYw/v7E/Wjeb+Oi70BdxBVgCp3DS3JBwui1FM7C2FLTzThm jtdbEnYq1J+SEaSEx44A+qSyLXvfLrNV17/rwXY8oI/a4AoenMvhaiVttRZ01FtdzmlW 2u5TDM5PwnMD1WP6OboykikMANlKtE189JsW5jgZjn7mqgBuBrV0dCtbqYT4nc6oFZAM g7L/3oaSlGMsYjMOAJCQxQMUgAumGT+EEbtX20eKKthxNXgPgTn0yl+6p9g1/CWJgb/e 1jow== Received: by 10.68.189.99 with SMTP id gh3mr1628292pbc.31.1346215527769; Tue, 28 Aug 2012 21:45:27 -0700 (PDT) Received: from tov.cyberagent.co.jp (124x35x85x170.ap124.ftth.ucom.ne.jp. [124.35.85.170]) by mx.google.com with ESMTPS id sr3sm18492746pbc.44.2012.08.28.21.45.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 21:45:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: nov matake In-Reply-To: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> Date: Wed, 29 Aug 2012 13:45:26 +0900 Content-Transfer-Encoding: 7bit Message-Id: <4893DB55-47D1-4BA9-921B-1A279404B5EF@gmail.com> References: <000101cd7c46$c3dd2f20$4b978d60$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1486) Cc: jose@ietf.org Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:45:31 -0000 YES On 2012/08/17, at 16:05, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > What should be the criticality of header fields as defined by the core > specification? > > YES - all headers fields are critical > NO - all header fields are non-critical > MAYBE - header fields are marked critical or criticality should be defined > by the application > DISCUSS - need to talk more > > Room vote: 2 yes, 0 no, 4 maybe, 3 discuss > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Tue Aug 28 21:45:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E0C21F84C4 for ; Tue, 28 Aug 2012 21:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhtj3rSVEgMV for ; Tue, 28 Aug 2012 21:45:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC521F84B8 for ; Tue, 28 Aug 2012 21:45:55 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so414737pbb.31 for ; Tue, 28 Aug 2012 21:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5JRFdk4MLHRg/w0wAoMA2xTZiQFbIHCE9FhDWoHZ93w=; b=CRNXmPmPm368HbkbMPa3Nq6WIwEhCUwk9N2HhMzgQCNJ6yjOk9awsdCoMT/JgWE9VQ gZsUmbO0CTi88ak+AhLMfTw4QbafwRvrd3lPdoHha3saX9b+Gi3dLhJcfzUf4xf4tW+6 7Gyqz61Y4J6x7AHiNLOTfJLQa+0rnSyMxQjZ4NZpdCWShgKZ6/zI5gzfFQV92Ltw9DTM 3jyebF9kDQsofARgPHjzNoLmfFlvvklTwwQvhapCAikR98bqXoWd0QbnHRmsDdhkK6sI GfzcC/2ZKr1P8+kEm1AqsOWuXZegR7RAc5HkuViVg4KckeGM44umalJfVO7N/Rm9iwSq c0CQ== Received: by 10.68.224.70 with SMTP id ra6mr1803410pbc.11.1346215554961; Tue, 28 Aug 2012 21:45:54 -0700 (PDT) Received: from tov.cyberagent.co.jp (124x35x85x170.ap124.ftth.ucom.ne.jp. [124.35.85.170]) by mx.google.com with ESMTPS id sr3sm18492746pbc.44.2012.08.28.21.45.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 21:45:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: nov matake In-Reply-To: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> Date: Wed, 29 Aug 2012 13:45:53 +0900 Content-Transfer-Encoding: 7bit Message-Id: <5E2AB91E-1CDE-4A66-B590-F9B77A1607E6@gmail.com> References: <000401cd7c46$c69cc450$53d64cf0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1486) Cc: jose@ietf.org Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:45:57 -0000 NO On 2012/08/17, at 16:05, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should support be mandated to allow an algorithm to be both a string and an > object > > Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", > "kid":"12345"} > > > Room vote: 1 yes, 5 no, 4 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Tue Aug 28 21:46:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6AD21F84FD for ; Tue, 28 Aug 2012 21:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOeWUz63K11o for ; Tue, 28 Aug 2012 21:46:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53A21F84B8 for ; Tue, 28 Aug 2012 21:46:16 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rr4so414737pbb.31 for ; Tue, 28 Aug 2012 21:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZLxTPSTJEBN85TCowBOlXN2XqLX8edy+FFEkXkcSUf8=; b=EetkR59VpeN5fx7XJoB0AR2Msk1Zv4LrXADY0pfqwSaGOpfTOSML/imRc8zh7RBzAO DkGONR76PQDsHOcqgyCuy/BoC6KoajJT5NOzdkQie6RNlPyEymqlnmn0dfOpO4tI1VHZ OijC5cFygz/Ra4S3pE65RBIzSnZm8hPlb3Q6wTOvT5tCilem6NdLCnyFwTYlt1wHfttB y3HT/TIk/DqSoFVEvzD0hIW7Bi40nAYlBEkznCexP1S99GZ4tJHrb2PyJUUwwGUUu5CL 2/ENRpHMQ/gh+ZEMip9jYkdOs2niqmi8QuOHmwOuPSb5bYoOdQRR7gjQ9OgxGuLrFY3N +JDQ== Received: by 10.68.136.40 with SMTP id px8mr1573616pbb.153.1346215576421; Tue, 28 Aug 2012 21:46:16 -0700 (PDT) Received: from tov.cyberagent.co.jp (124x35x85x170.ap124.ftth.ucom.ne.jp. [124.35.85.170]) by mx.google.com with ESMTPS id sr3sm18492746pbc.44.2012.08.28.21.46.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 21:46:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: nov matake In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> Date: Wed, 29 Aug 2012 13:46:15 +0900 Content-Transfer-Encoding: 7bit Message-Id: <35D689CF-13E3-42DA-8FC2-10E20E9FD39D@gmail.com> References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1486) Cc: jose@ietf.org Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:46:17 -0000 NO On 2012/08/17, at 16:06, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we add the ability to have a randomly generated MAC key protected by > a different key? The other key could be either a pre-shared symmetric key > or a public key. > > > > Room vote: 3 yes, 5 no, 3 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From matake@gmail.com Tue Aug 28 21:48:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DE121F84B5 for ; Tue, 28 Aug 2012 21:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrVcbD5UTPyA for ; Tue, 28 Aug 2012 21:48:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 260EB21F844F for ; Tue, 28 Aug 2012 21:48:30 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so417749pbb.31 for ; Tue, 28 Aug 2012 21:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=o6R1ipW6UtscdlOcKQAd32ufMxv92yqaN9GbHf7Yd5U=; b=YRktNt1+Gdrd39DmIpkG5GrYAKQS/6EV3ymTdjtoNPMzR7riLwnVamaNRm2gzTUMlx QlRwWc58B0M/1E8hZpbH7UbjkNb4ZG9NLEGq+vSBzcUPY5O4XFPxg9xC8+TvrNGQjhqg IdHKHwpg3QGZddTGwvJ7hxKzAMcMKJcflfSmXfKoq49/BgJM18AiTy+n1kOxjagmZVKr 3tfPqG0AZe079JrJez1fhgBZ5AIj7cA7vL1UBrCISHYOQjU/sBhEWn4QlGPtEWCx4GDJ 7VyJcH2LmdGz9rpNK66qS5ZKuMr+RSd/4o7Hjj9i1prizHlgsGOQZS0WSci6VnmBjZxT s6Vg== Received: by 10.68.130.131 with SMTP id oe3mr1673532pbb.102.1346215709944; Tue, 28 Aug 2012 21:48:29 -0700 (PDT) Received: from tov.cyberagent.co.jp (124x35x85x170.ap124.ftth.ucom.ne.jp. [124.35.85.170]) by mx.google.com with ESMTPS id th6sm18522398pbc.0.2012.08.28.21.48.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 21:48:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7EA4D57D-22D4-4E49-840E-C7B65A483E35" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: nov matake In-Reply-To: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> Date: Wed, 29 Aug 2012 13:48:26 +0900 Message-Id: <75B0EFEE-EAD3-46DE-ABFF-5F2FD96AA1AD@gmail.com> References: <008001cd7c46$fb5837b0$f208a710$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1486) Cc: jose@ietf.org Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 04:48:35 -0000 --Apple-Mail=_7EA4D57D-22D4-4E49-840E-C7B65A483E35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii YES On 2012/08/17, at 16:07, Jim Schaad wrote: > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a single > content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} > New: {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_7EA4D57D-22D4-4E49-840E-C7B65A483E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 2012/08/17, at 16:07, Jim = Schaad <ietf@augustcellars.com> = wrote:

<CHAIR>

If you voted at the face-2-face = please do not vote again.  If you want to
provide comments = please change the title from POLL to DISCUSS.

Should we change = the current treatment of AES-CBC + HMAC to use a single
content = encryption name.

Old: {"enc":"A128CBC", "int":HS256", = "kdf":"CS256"}
New: {"enc":"AES128CBC+HS256+CS256"}

Exact name = is still to be determined

Room vote:  12 yes, 2 no, 0 = discuss


_______________________________________________
jose= mailing list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_7EA4D57D-22D4-4E49-840E-C7B65A483E35-- From prateek.mishra@oracle.com Wed Aug 29 06:04:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E033121F8679 for ; Wed, 29 Aug 2012 06:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obi+6YwmyXzD for ; Wed, 29 Aug 2012 06:04:54 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE421F8673 for ; Wed, 29 Aug 2012 06:04:54 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7TD4iuq031369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Aug 2012 13:04:45 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7TD4hZG012759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 13:04:44 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7TD4hmt026066 for ; Wed, 29 Aug 2012 08:04:43 -0500 Received: from [192.168.2.2] (/66.31.108.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 06:04:43 -0700 Message-ID: <503E136B.3020503@oracle.com> Date: Wed, 29 Aug 2012 09:04:43 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> In-Reply-To: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 13:04:55 -0000 YES, this is a significant use-case, wherein a server is provisioned with a certificate and clients generate a symmetric key (per session or transaction). Said key is encrypted using the server public key and used for integrity protection and encryption during the session/transaction. > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we add the ability to have a randomly generated MAC key protected by > a different key? The other key could be either a pre-shared symmetric key > or a public key. > > > > Room vote: 3 yes, 5 no, 3 discuss > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Wed Aug 29 08:14:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A176121F86C7 for ; Wed, 29 Aug 2012 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghWG-d72An2R for ; Wed, 29 Aug 2012 08:14:25 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3521F86BA for ; Wed, 29 Aug 2012 08:14:25 -0700 (PDT) Received: by qadz3 with SMTP id z3so543707qad.10 for ; Wed, 29 Aug 2012 08:14:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Odd08FuHUr5pw8ZxOyjjkv5eurBPtQaaK8QvVumxDik=; b=hTnGepxpP681MUOMaFE/lFYJi1Z68VrW//nD7BQTz89841CtrpYT+UyL5E81Zfyq4k cgSjdZhedANcFIs5qjF9gYqMGCjjOz+c3lBgfJOKRynV7A4llrfROXEuz4250b1u0e4H xXyLwovGl3G7x8dx1U1Z12laffv3RIvCj+yxTAEkb5VIU7fWqRuOFLHvjmFRdIBP/iyZ cihYgPlvoXIulGRYd2fmQY/reyeRKibCa1UOKhtEa0y+6e2sz6D/jcBqQ/VSz616b6VP KEcP6ZwlypFkViVWK+HDPFXdAAh1Oox/1iLDYSS/QTcEzm9bt0PQXzaaXZRANTVhxNTv fUlQ== Received: by 10.224.200.130 with SMTP id ew2mr4174551qab.92.1346253264970; Wed, 29 Aug 2012 08:14:24 -0700 (PDT) Received: from [192.168.1.211] (190-20-54-75.baf.movistar.cl. [190.20.54.75]) by mx.google.com with ESMTPS id g13sm5706137qah.5.2012.08.29.08.14.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 08:14:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B5E46969-2B54-4E4F-8046-932D62562211"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <503E136B.3020503@oracle.com> Date: Wed, 29 Aug 2012 11:14:13 -0400 Message-Id: References: <000001cd7c46$d87cb9a0$89762ce0$@augustcellars.com> <503E136B.3020503@oracle.com> To: PRATEEK MISHRA X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQlqNxrxt92OAXpHEvl1F3OAK3W2S+YatpEZUNJ7M2/1P1azEF8gdxNKL1luBtBiL4/XNJAG Cc: jose@ietf.org Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:14:26 -0000 --Apple-Mail=_B5E46969-2B54-4E4F-8046-932D62562211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think there is some confusion. We support this for encryption + integrity now. I think the question in the room was should we add a way in JWE to HMAC = the message body with a key that is sent in the same message that is = signed by another key. I think the questions to the list are not entirely consistent with what = was discussed in the room in some cases. Perhaps others can clarify if my recollection is wrong. John B. On 2012-08-29, at 9:04 AM, prateek mishra = wrote: > YES, this is a significant use-case, wherein a server is provisioned = with a certificate and clients generate a symmetric key > (per session or transaction). Said key is encrypted using the server = public key and used for integrity protection and > encryption during the session/transaction. >> >>=20 >> If you voted at the face-2-face please do not vote again. If you = want to >> provide comments please change the title from POLL to DISCUSS. >>=20 >> Should we add the ability to have a randomly generated MAC key = protected by >> a different key? The other key could be either a pre-shared = symmetric key >> or a public key. >>=20 >>=20 >>=20 >> Room vote: 3 yes, 5 no, 3 discuss >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_B5E46969-2B54-4E4F-8046-932D62562211 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy OTE1MTQxNFowIwYJKoZIhvcNAQkEMRYEFPPS95gFFmU07F3CMMzvmyhjlPkEMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ADi1/A33pcgwYYZZWZnIygVMMDowmIam7sWVj7in66/BpCe5jZ/qOlO1wEzUVvusMPQeQ3StoPdt shGZRNq/FbRJVKM0sjoSNlgrmhNgCLJD2396n+7fXO+q0S3XQChdQ0Zc6WsR2JV152v+BUhuBErs RuRdupiH6iWYM01Lr485BqB65NZ+KMLngf0rX5FVmLgKKSgkunmtekCHSmlMpgz6anVgouo0PzLD 1RHF0z39hOLyASZWYweResNauCK/9oPoWd6YdWTMJexno+qyXN/yK6Ykx1v4LWcF5oyPwBC+df7Z smUz6FkoA6EUMlk6JQRxpzxBF6iLBL5WSDiIr38AAAAAAAA= --Apple-Mail=_B5E46969-2B54-4E4F-8046-932D62562211-- From odonoghue@isoc.org Wed Aug 29 14:29:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2011E80F5 for ; Wed, 29 Aug 2012 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC3NZxbWsaNx for ; Wed, 29 Aug 2012 14:29:39 -0700 (PDT) Received: from smtp186.iad.emailsrvr.com (smtp186.iad.emailsrvr.com [207.97.245.186]) by ietfa.amsl.com (Postfix) with ESMTP id 85E6711E80F3 for ; Wed, 29 Aug 2012 14:29:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 07A0DE0367 for ; Wed, 29 Aug 2012 17:29:38 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp28.relay.iad1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id E24E1E0206 for ; Wed, 29 Aug 2012 17:29:37 -0400 (EDT) Message-ID: <503E89C1.2030409@isoc.org> Date: Wed, 29 Aug 2012 17:29:37 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:29:40 -0000 Folks, Given the confusion around the original version of this poll, I'd like to try again. The basic question is unchanged, the room count from Vancouver has been corrected, and a clarification regarding the status of SHA1 in the OAEP specification has been added. For those of you who voted and feel you may have misunderstood the question or voted incorrectly, please feel free to update your answer. Question: Should SHA1 (and mgf1SHA1) be the default parameters for these algorithms? Note: These are the default parameters specified in RFC 3447, Section A.2.1, and are widely deployed. Room vote: 5 yes, 0 no, 3 discuss Thanks, Karen From bcampbell@pingidentity.com Wed Aug 29 14:58:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD221F845F for ; Wed, 29 Aug 2012 14:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K0mhDkCTobP for ; Wed, 29 Aug 2012 14:58:05 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 49DEA21F845A for ; Wed, 29 Aug 2012 14:58:05 -0700 (PDT) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUD6QbND7GIKkWFJ8nDvqtgUS8eI0bU6o@postini.com; Wed, 29 Aug 2012 14:58:05 PDT Received: by vcbfo14 with SMTP id fo14so1401720vcb.31 for ; Wed, 29 Aug 2012 14:58:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=zLXQNiucUdIuC6WVD2JP3MrF++p1hi4kZ6Xd+MqDcUo=; b=oeUPFeoHGbTlGWGUxWdbP7GdHaJwbs16fUWOvLHBWXiG/NJFWhYcFcJH5y8RvkJTdh ZUt0ArarDBN6d1gVMUGXBMP9y4TeedHUOIeN2WfxSs/CSjQz4US7fUOXisC+FeuvKkRJ E1uUTxrQ1bYfCdo1vBqwM5gTdyvGp2UksJ+lXbYDZxWBObM5erx5VUH5A/5Flz70qyW1 hgRM1KC2eN6DOefgXqlqyzRNSnaVTPUz9wpwbPinN8+WqZWeBo6E/YChKMwJuGUNFmnr DG0Y1kNNodpoFKVx/aRnQX5LF9rx87nDjM/KJvVNCo16m7sP+OGwAhpjZWdxo2HVrcbT AbOw== Received: by 10.220.204.212 with SMTP id fn20mr1914376vcb.43.1346277483732; Wed, 29 Aug 2012 14:58:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.66.228 with HTTP; Wed, 29 Aug 2012 14:57:33 -0700 (PDT) In-Reply-To: <503E89C1.2030409@isoc.org> References: <503E89C1.2030409@isoc.org> From: Brian Campbell Date: Wed, 29 Aug 2012 15:57:33 -0600 Message-ID: To: odonoghue@isoc.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkRjxSFCMQmPyaUcw59Pgg3OJJ2VNsswASOgiWmeV3dFi32ZiSZJOroHuQUpbuMHwmRiaa5 Cc: jose@ietf.org Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:58:06 -0000 yes (I can't honestly remember if I voted in Vancouver but I'm pretty sure I abstained on this one at that time) On Wed, Aug 29, 2012 at 3:29 PM, Karen O'Donoghue wrote: > Folks, > > Given the confusion around the original version of this poll, I'd like to > try again. > > The basic question is unchanged, the room count from Vancouver has been > corrected, and a clarification regarding the status of SHA1 in the OAEP > specification has been added. For those of you who voted and feel you may > have misunderstood the question or voted incorrectly, please feel free to > update your answer. > > Question: > Should SHA1 (and mgf1SHA1) be the default parameters for these algorithms? > Note: These are the default parameters specified in RFC 3447, Section > A.2.1, and are widely deployed. > > Room vote: 5 yes, 0 no, 3 discuss > > Thanks, > Karen > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ejay@mgi1.com Wed Aug 29 15:21:06 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E01C21F8606 for ; Wed, 29 Aug 2012 15:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHt1spOPJguN for ; Wed, 29 Aug 2012 15:21:05 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id 6B68121F8605 for ; Wed, 29 Aug 2012 15:21:05 -0700 (PDT) Received: from [98.139.91.70] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 29 Aug 2012 22:21:02 -0000 Received: from [66.94.237.102] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 29 Aug 2012 22:21:01 -0000 Received: from [127.0.0.1] by omp1007.access.mail.mud.yahoo.com with NNFMP; 29 Aug 2012 22:21:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 912593.77532.bm@omp1007.access.mail.mud.yahoo.com Received: (qmail 64264 invoked by uid 60001); 29 Aug 2012 22:21:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346278860; bh=7AtyNk7wQ/4PI94H4XbC5uEdKW6aOseMDTES1lnXiR4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qFT5NecvO9JKLkLN/QWNxhp4p5pubmf3bibewUm2MRFNq1e+elyyRa8tIo5l0IXR/o9hcvy8bRS+z77L5vaGdblUbdTus5Z2CrHyjuQQp/H4hxne8vZ8ysPGCinjV8iSt/e/xTzP9mTAt+vPJh/UrbgVuyX/F4rdoP1hoke3cVg= X-YMail-OSG: uvczUuAVM1n.zxgF6rbitwnFMn_NuLuzGhmuquhKEROITh5 2O3k5E4qZPZTkxKfhNxkjy7ul1XInpI0McibzPjX_NxskaxVXzUjk.5OPxYA YlnJPGNhvVJWqZZ_p3tuZ..x6iuy.Y1dWDu.yV8aHk9pa9Xp0l8Om.YaGOC_ UHR21x8skYivaCX3f1ewVHiEA0Yoc6K8cLYub9TOnY_LZzZLi8TLMEmH1AKR cUlHpvOQM3.gikgAV3Rp4axXx6KAsVQjgBuwNJKBqttD_.bEjnZmVL3AGJEr JrQiWcy6i9PQYdOd_xThyHuTN.ou2JuifC4r1eK27rNJonJ7lukogAmLstwE QLQ5pvq_lZV7i8QYdxlV7CnI8HmXawVunJ79kgUrTSkTrm_OgqfWhXPfo8NS Ftv51cHhHFTT7kjYhyG719DDNBoOddB8uji8mOfKAoduWcRknEGWM3Ei3iIf 2WHssc_IvSugdeN8wGS_GKhD4xo2LlSrHw_aUEMYFQ8LZufnPVJUQdNP6QA- - Received: from [64.140.94.67] by web184406.mail.bf1.yahoo.com via HTTP; Wed, 29 Aug 2012 15:20:59 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.121.416 References: <503E89C1.2030409@isoc.org> Message-ID: <1346278859.64076.YahooMailRC@web184406.mail.bf1.yahoo.com> Date: Wed, 29 Aug 2012 15:20:59 -0700 (PDT) From: Edmund Jay To: jose@ietf.org In-Reply-To: <503E89C1.2030409@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1789658926-380833443-1346278859=:64076" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 22:21:06 -0000 --1789658926-380833443-1346278859=:64076 Content-Type: text/plain; charset=us-ascii YES ________________________________ From: Karen O'Donoghue To: jose@ietf.org Sent: Wed, August 29, 2012 2:29:43 PM Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Folks, Given the confusion around the original version of this poll, I'd like to try again. The basic question is unchanged, the room count from Vancouver has been corrected, and a clarification regarding the status of SHA1 in the OAEP specification has been added. For those of you who voted and feel you may have misunderstood the question or voted incorrectly, please feel free to update your answer. Question: Should SHA1 (and mgf1SHA1) be the default parameters for these algorithms? Note: These are the default parameters specified in RFC 3447, Section A.2.1, and are widely deployed. Room vote: 5 yes, 0 no, 3 discuss Thanks, Karen _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --1789658926-380833443-1346278859=:64076 Content-Type: text/html; charset=us-ascii
YES

From: Karen O'Donoghue <odonoghue@isoc.org>
To: jose@ietf.org
Sent: Wed, August 29, 2012 2:29:43 PM
Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters

Folks,

Given the confusion around the original version of this poll, I'd like to try again.

The basic question is unchanged, the room count from Vancouver has been corrected, and a clarification regarding the status of SHA1 in the OAEP specification has been added.  For those of you who voted and feel you may have misunderstood the question or voted incorrectly, please feel free to update your answer.

Question:
Should SHA1 (and mgf1SHA1) be the default parameters for these algorithms?
Note:  These are the default parameters specified in RFC 3447, Section A.2.1, and are widely deployed.

Room vote:  5 yes, 0 no, 3 discuss

Thanks,
Karen
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--1789658926-380833443-1346278859=:64076-- From James.H.Manger@team.telstra.com Wed Aug 29 16:58:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9120111E80F0 for ; Wed, 29 Aug 2012 16:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zIgOJImsWSJ for ; Wed, 29 Aug 2012 16:58:26 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id BB77511E809C for ; Wed, 29 Aug 2012 16:58:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,336,1344175200"; d="scan'208";a="87447524" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 30 Aug 2012 09:58:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="33740300" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcani.tcif.telstra.com.au with ESMTP; 30 Aug 2012 09:58:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 30 Aug 2012 09:58:22 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 30 Aug 2012 09:58:21 +1000 Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: Ac2GLWno7rcATbIAR7qBGG58NBZdoAAEIWvQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> References: <503E89C1.2030409@isoc.org> In-Reply-To: <503E89C1.2030409@isoc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 23:58:26 -0000 PiBTaG91bGQgU0hBMSAoYW5kIG1nZjFTSEExKSBiZSB0aGUgZGVmYXVsdCBwYXJhbWV0ZXJzIGZv ciB0aGVzZQ0KPiBhbGdvcml0aG1zPw0KDQpXZSBkb27igJl0IGhhdmUgImFsZ29yaXRobSBwYXJh bWV0ZXJzIiBpbiBKT1NFIOKAkyB0aGF0IGlzIHRoZSBzdWJqZWN0IG9mIGEgc2VwYXJhdGUgUE9M TCAoIlN1cHBvcnQgbXVsdGlwbGUgdHlwZXMgZm9yIGFsZ29yaXRobXMiKS4gSk9TRSBjdXJyZW50 bHkgaGFzIGFsZ29yaXRobSBsYWJlbHMgd2l0aCBubyBwYXJhbWV0ZXJzLg0KDQpDb25zZXF1ZW50 bHkgdGhpcyBxdWVzdGlvbiBpcyByZWFsbHkgYXNraW5nIG9uZSBvZiB0aGUgZm9sbG93aW5nOg0K DQpRMS4gU2hvdWxkIFJTQSBPQUVQIHdpdGggU0hBLTEgYmUgZGVmaW5lZCBmb3IgdXNlIHdpdGgg Sk9TRT8gUGVyaGFwcyBhZGRpdGlvbmFsbHksIHNob3VsZCBpdCBiZSBtYW5kYXRvcnkgdG8gaW1w bGVtZW50Pw0KVGhlIGNvcmUgb2YgdGhpcyBxdWVzdGlvbiBpcyB3aGV0aGVyIFNIQS0xIGlzIGNy eXB0b2dyYXBoaWNhbGx5LWNvbXByb21pc2VkIGVub3VnaCB0aGF0IHdlIHNob3VsZG4ndCB1c2Ug aXQgaW4gbmV3IGNyeXB0byBzcGVjcywgb3IgaXMgaXRzIHdpZGVzcHJlYWQtYXZhaWxhYmlsaXR5 IG1vcmUgaW1wb3J0YW50IHRoYW4gYW55IGNyeXB0byB3ZWFrbmVzcz8NCg0KUTIuIFNob3VsZCB0 aGUgbGFiZWwgIlJTQS1PQUVQIiBiZSB1c2VkIGZvciBSU0EgT0FFUCB3aXRoIFNIQS0xPw0KDQpN eSBhbnN3ZXIgdG8gUTIgaXMgTk8uIFRoZSAiUlNBLU9BRVAiIGxhYmVsIGlzIGluY29uc2lzdGVu dCB3aXRoIG90aGVyIEpPU0UgYWxnIG5hbWVzLiBKV0Egc3BlY2lmaWVzICJIUzUxMiIsICJSUzUx MiIsICJFUzUxMiIsIGFuZCAiQ1M1MTIiIHdoZXJlIHRoZSBTeHh4IHN1ZmZpeCBpbmRpY2F0ZXMg YSBoYXNoIGFsZ29yaXRobS4gUlNBIE9BRVAgd2l0aCBTSEEtMSBjb3VsZCB1c2UgIlJPUzEiIG9y ICJST1MxNjAiLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gS2FyZW4gTydEb25vZ2h1ZQ0KPiBTZW50OiBUaHVy c2RheSwgMzAgQXVndXN0IDIwMTIgNzozMCBBTQ0KPiBUbzogam9zZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0 ZXJzDQo+IA0KPiBGb2xrcywNCj4gDQo+IEdpdmVuIHRoZSBjb25mdXNpb24gYXJvdW5kIHRoZSBv cmlnaW5hbCB2ZXJzaW9uIG9mIHRoaXMgcG9sbCwgSSdkIGxpa2UNCj4gdG8gdHJ5IGFnYWluLg0K PiANCj4gVGhlIGJhc2ljIHF1ZXN0aW9uIGlzIHVuY2hhbmdlZCwgdGhlIHJvb20gY291bnQgZnJv bSBWYW5jb3V2ZXIgaGFzIGJlZW4NCj4gY29ycmVjdGVkLCBhbmQgYSBjbGFyaWZpY2F0aW9uIHJl Z2FyZGluZyB0aGUgc3RhdHVzIG9mIFNIQTEgaW4gdGhlIE9BRVANCj4gc3BlY2lmaWNhdGlvbiBo YXMgYmVlbiBhZGRlZC4gIEZvciB0aG9zZSBvZiB5b3Ugd2hvIHZvdGVkIGFuZCBmZWVsIHlvdQ0K PiBtYXkgaGF2ZSBtaXN1bmRlcnN0b29kIHRoZSBxdWVzdGlvbiBvciB2b3RlZCBpbmNvcnJlY3Rs eSwgcGxlYXNlIGZlZWwNCj4gZnJlZSB0byB1cGRhdGUgeW91ciBhbnN3ZXIuDQo+IA0KPiBRdWVz dGlvbjoNCj4gU2hvdWxkIFNIQTEgKGFuZCBtZ2YxU0hBMSkgYmUgdGhlIGRlZmF1bHQgcGFyYW1l dGVycyBmb3IgdGhlc2UNCj4gYWxnb3JpdGhtcz8NCj4gTm90ZTogIFRoZXNlIGFyZSB0aGUgZGVm YXVsdCBwYXJhbWV0ZXJzIHNwZWNpZmllZCBpbiBSRkMgMzQ0NywgU2VjdGlvbg0KPiBBLjIuMSwg YW5kIGFyZSB3aWRlbHkgZGVwbG95ZWQuDQo+IA0KPiBSb29tIHZvdGU6ICA1IHllcywgMCBubywg MyBkaXNjdXNzDQo+IA0KPiBUaGFua3MsDQo+IEthcmVuDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+IGpvc2VA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo= From breno@google.com Wed Aug 29 17:00:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4887111E80F6 for ; Wed, 29 Aug 2012 17:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.748 X-Spam-Level: X-Spam-Status: No, score=-102.748 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOIpdTC4p482 for ; Wed, 29 Aug 2012 17:00:47 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 721E411E80F5 for ; Wed, 29 Aug 2012 17:00:47 -0700 (PDT) Received: by iabz21 with SMTP id z21so2430869iab.31 for ; Wed, 29 Aug 2012 17:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=GIlkC3rIP19PWb/yj13kgUGsPz9+Wpuaz63k3cKUOqM=; b=g4G97tIxanZd76FPU32tWhDG6wQbWePpqIcn+wC2xsCCdKEHy8IOjMJ1NGhgqnBaQh pDH0P7fNwENRi0AyeyYvzgIrvBPeA+92Iv2OBM70p7kJqUwqlVqwWMjg1BcHMsiXxYBY j0TQfI1u/abzIWv0IUH1KCLGklmo00ztSYXxawM9cJ+WNHP2NRMI1huKYAZFLRIgHDxg VAx8+vgR6MP2x0niN2pESuucpCKiue4TQLjVo16h2ph0135CevB20H3dKhpNs19vdugB WC6FvW3toyZ0bLjm92jkIzhhR9BKqGdlfpV6veHJm+o8WosTx3sGo7Nhh29NQtBEAVGs fa2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=GIlkC3rIP19PWb/yj13kgUGsPz9+Wpuaz63k3cKUOqM=; b=MUPtdPwnPLIUJrmscmNlk4VmPab9eldRzee07t4wZNYcJXuFyLgUQdwNjimX6QaD3Z 6qVg9Wh3KLJejOhrRgC7MpAWh5gvsYEapF8ddAcYcXb5znqoqzN1sSSMPWuuEr2yPnq3 86f1GKQfV3E1BoYZGbvhwDhK6Hr20tj+54//6WaAIyoeR5UeStYJ4de6K7mVQEcKIfXo Zry7Ns2My2tFAB7/HEaSe6hYzOFMcXKsLoP4PFHbqF1TOoKNsFoUd9jbLPheihZ99hnh mWqRwSA4PBIq/ztQWUhw2HoB1G7jl1bf6mAdfO9x8qFiXBJGwP/ytKq2fwzezP2GWDBa I54A== Received: by 10.50.34.137 with SMTP id z9mr19611047igi.5.1346284847002; Wed, 29 Aug 2012 17:00:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.34.137 with SMTP id z9mr19611040igi.5.1346284846875; Wed, 29 Aug 2012 17:00:46 -0700 (PDT) Received: by 10.231.239.3 with HTTP; Wed, 29 Aug 2012 17:00:46 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 29 Aug 2012 17:00:46 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae93409e51082c004c8705e08 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkCQbZyHYarJS+euDeddbB42DD7n/Otes6J5vnX/dYw3lOjUeY5/c7+iReNkZkgInBRNePbyilHXDad/ye7Qry07Tw5DuKYgD52gdWQAvLIso4ccj83Bzv8ljtl+VD3hM2+QyZ5UFVNh2EWiNCfYd/nJAfvnyapOc/VBCagcUyHn2fVRriY0ggSXAMvVIuEZ8tsXE+s Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:00:48 -0000 --14dae93409e51082c004c8705e08 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Concur with the analysis that 'RSA-OAEP' terminology appears inconsistent with other acronym usage. On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > Should SHA1 (and mgf1SHA1) be the default parameters for these > > algorithms? > > We don=92t have "algorithm parameters" in JOSE =96 that is the subject of= a > separate POLL ("Support multiple types for algorithms"). JOSE currently h= as > algorithm labels with no parameters. > > Consequently this question is really asking one of the following: > > Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps > additionally, should it be mandatory to implement? > The core of this question is whether SHA-1 is > cryptographically-compromised enough that we shouldn't use it in new cryp= to > specs, or is its widespread-availability more important than any crypto > weakness? > > Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1? > > My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with other > JOSE alg names. JWA specifies "HS512", "RS512", "ES512", and "CS512" wher= e > the Sxxx suffix indicates a hash algorithm. RSA OAEP with SHA-1 could use > "ROS1" or "ROS160". > > -- > James Manger > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Karen O'Donoghue > > Sent: Thursday, 30 August 2012 7:30 AM > > To: jose@ietf.org > > Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters > > > > Folks, > > > > Given the confusion around the original version of this poll, I'd like > > to try again. > > > > The basic question is unchanged, the room count from Vancouver has been > > corrected, and a clarification regarding the status of SHA1 in the OAEP > > specification has been added. For those of you who voted and feel you > > may have misunderstood the question or voted incorrectly, please feel > > free to update your answer. > > > > Question: > > Should SHA1 (and mgf1SHA1) be the default parameters for these > > algorithms? > > Note: These are the default parameters specified in RFC 3447, Section > > A.2.1, and are widely deployed. > > > > Room vote: 5 yes, 0 no, 3 discuss > > > > Thanks, > > Karen > > _______________________________________________ > > 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 > --=20 --Breno --14dae93409e51082c004c8705e08 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Concur with the analysis that 'RSA-OAEP' terminology appears incons= istent with other acronym usage.


On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> Should SHA1 (and mgf1= SHA1) be the default parameters for these
> algorithms?

We don=92t have "algorithm parameters" in JOSE =96 that is = the subject of a separate POLL ("Support multiple types for algorithms= "). JOSE currently has algorithm labels with no parameters.

Consequently this question is really asking one of the following:

Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps additi= onally, should it be mandatory to implement?
The core of this question is whether SHA-1 is cryptographically-compromised= enough that we shouldn't use it in new crypto specs, or is its widespr= ead-availability more important than any crypto weakness?

Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1?<= br>
My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with = other JOSE alg names. JWA specifies "HS512", "RS512", &= quot;ES512", and "CS512" where the Sxxx suffix indicates a h= ash algorithm. RSA OAEP with SHA-1 could use "ROS1" or "ROS1= 60".

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Karen O'Donoghue
> Sent: Thursday, 30 August 2012 7:30 AM
> To: jose@ietf.org
> Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters
>
> Folks,
>
> Given the confusion around the original version of this poll, I'd = like
> to try again.
>
> The basic question is unchanged, the room count from Vancouver has bee= n
> corrected, and a clarification regarding the status of SHA1 in the OAE= P
> specification has been added. =A0For those of you who voted and feel y= ou
> may have misunderstood the question or voted incorrectly, please feel<= br> > free to update your answer.
>
> Question:
> Should SHA1 (and mgf1SHA1) be the default parameters for these
> algorithms?
> Note: =A0These are the default parameters specified in RFC 3447, Secti= on
> A.2.1, and are widely deployed.
>
> Room vote: =A05 yes, 0 no, 3 discuss
>
> Thanks,
> Karen
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
= --Breno

--14dae93409e51082c004c8705e08-- From stephen.farrell@cs.tcd.ie Wed Aug 29 17:05:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75011E80F6 for ; Wed, 29 Aug 2012 17:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lP4QNYExtfc for ; Wed, 29 Aug 2012 17:05:03 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A5A6A11E809C for ; Wed, 29 Aug 2012 17:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 437D117148C; Thu, 30 Aug 2012 01:05:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346285100; bh=N3BgVpYxuXRnDv CwdlD8yKUKl5QPOk5k4Kf5dvXCOeA=; b=iBfBC7WN4H7VRvpZE/CEMmYFlLB2YQ Gae5zRveSLspVjQ7cGXsaNpQLH+WH0ojQGLnQbKrlBLuOaBVzlj+c0er1js3q1/k 2PQY6tbuySX36ySJ23Pax7KlvUrju5/nXkpqiCF5UOXehgqLZ9YRX8DWB4NbXa7f TmmD/VVRR7MrE0HplDGEAM8pbKg19hTS3F1iODrX1n9W+5QfjlAhO6BJk4qspxax AoCIrklHUqycqdK3aApGYCreEydTXAaIu70GXE1Vadrt7iR0jD9RPWi/P+r/eEe+ LMTsRKiaqx5ICvb4P4nOMojI0mQGlbVtCnx5N+DkawoXPysL0lN8BgdQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fueCth5tDoid; Thu, 30 Aug 2012 01:05:00 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.76.72]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AE01417147C; Thu, 30 Aug 2012 01:04:55 +0100 (IST) Message-ID: <503EAE27.9030409@cs.tcd.ie> Date: Thu, 30 Aug 2012 01:04:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Manger, James H" References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:05:04 -0000 On 08/30/2012 12:58 AM, Manger, James H wrote: > Consequently this question is really asking one of the following: > > Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps additionally, should it be mandatory to implement? > The core of this question is whether SHA-1 is cryptographically-compromised enough that we shouldn't use it in new crypto specs, or is its widespread-availability more important than any crypto weakness? Just on this part. DKIM and DANE both decided to go with to sha256 as the mandatory to implement digest alg. I think that is a trend. I don't see why JOSE would be different in that respect. If JOSE do choose to stand out from the crowd and go with sha1 then I think you'll need to justify that explicitly and convincingly. S. From Michael.Jones@microsoft.com Wed Aug 29 17:06:52 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD511E80FC for ; Wed, 29 Aug 2012 17:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.836 X-Spam-Level: X-Spam-Status: No, score=-3.836 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXNY4tG-0Bcb for ; Wed, 29 Aug 2012 17:06:49 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 556B711E80F6 for ; Wed, 29 Aug 2012 17:06:48 -0700 (PDT) Received: from mail33-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 Aug 2012 00:06:47 +0000 Received: from mail33-db3 (localhost [127.0.0.1]) by mail33-db3-R.bigfish.com (Postfix) with ESMTP id 2A9C53402EE; Thu, 30 Aug 2012 00:06:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371Ic85fh542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail33-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail33-db3 (localhost.localdomain [127.0.0.1]) by mail33-db3 (MessageSwitch) id 1346285205755226_351; Thu, 30 Aug 2012 00:06:45 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.243]) by mail33-db3.bigfish.com (Postfix) with ESMTP id B532A420045; Thu, 30 Aug 2012 00:06:45 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 Aug 2012 00:06:44 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Thu, 30 Aug 2012 00:06:42 +0000 From: Mike Jones To: Breno de Medeiros , "Manger, James H" Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: AQHNhi1oMG2bBx4eNkynEaO7ZDjUypdxd/uAgAAArACAAAB5IA== Date: Thu, 30 Aug 2012 00:06:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667AEEF3TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:06:52 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667AEEF3TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Where a key size is required to fully specify the algorithm, it's included = in the name. Examples: HS256, A128GCM. Where the size isn't required to fully specify the algorithm, it isn't. Ex= amples: RSA1_5, RSA-OAEP, ECSH-ES. No inconsistency. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bre= no de Medeiros Sent: Wednesday, August 29, 2012 5:01 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Concur with the analysis that 'RSA-OAEP' terminology appears inconsistent w= ith other acronym usage. On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H > wrote: > Should SHA1 (and mgf1SHA1) be the default parameters for these > algorithms? We don't have "algorithm parameters" in JOSE - that is the subject of a sep= arate POLL ("Support multiple types for algorithms"). JOSE currently has al= gorithm labels with no parameters. Consequently this question is really asking one of the following: Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps additi= onally, should it be mandatory to implement? The core of this question is whether SHA-1 is cryptographically-compromised= enough that we shouldn't use it in new crypto specs, or is its widespread-= availability more important than any crypto weakness? Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1? My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with other JOSE= alg names. JWA specifies "HS512", "RS512", "ES512", and "CS512" where the = Sxxx suffix indicates a hash algorithm. RSA OAEP with SHA-1 could use "ROS1= " or "ROS160". -- James Manger > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf Of > Karen O'Donoghue > Sent: Thursday, 30 August 2012 7:30 AM > To: jose@ietf.org > Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters > > Folks, > > Given the confusion around the original version of this poll, I'd like > to try again. > > The basic question is unchanged, the room count from Vancouver has been > corrected, and a clarification regarding the status of SHA1 in the OAEP > specification has been added. For those of you who voted and feel you > may have misunderstood the question or voted incorrectly, please feel > free to update your answer. > > Question: > Should SHA1 (and mgf1SHA1) be the default parameters for these > algorithms? > Note: These are the default parameters specified in RFC 3447, Section > A.2.1, and are widely deployed. > > Room vote: 5 yes, 0 no, 3 discuss > > Thanks, > Karen > _______________________________________________ > 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 -- --Breno --_000_4E1F6AAD24975D4BA5B1680429673943667AEEF3TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Where a key size is requi= red to fully specify the algorithm, it’s included in the name.  = Examples:  HS256, A128GCM.

Where the size isn’= t required to fully specify the algorithm, it isn’t.  Examples:&= nbsp; RSA1_5, RSA-OAEP, ECSH-ES.

 <= /p>

No inconsistency.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros
Sent: Wednesday, August 29, 2012 5:01 PM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters=

 

Concur with the analysis that 'RSA-OAEP' terminology= appears inconsistent with other acronym usage.

 

On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:

> Should SHA1 (and= mgf1SHA1) be the default parameters for these
> algorithms?

We don’t have "algorithm parameters"= in JOSE – that is the subject of a separate POLL ("Support mult= iple types for algorithms"). JOSE currently has algorithm labels with = no parameters.

Consequently this question is really asking one of the following:

Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps additi= onally, should it be mandatory to implement?
The core of this question is whether SHA-1 is cryptographically-compromised= enough that we shouldn't use it in new crypto specs, or is its widespread-= availability more important than any crypto weakness?

Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1?<= br>
My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with = other JOSE alg names. JWA specifies "HS512", "RS512", &= quot;ES512", and "CS512" where the Sxxx suffix indicates a h= ash algorithm. RSA OAEP with SHA-1 could use "ROS1" or "ROS1= 60".

--
James Manger


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Karen O'Donoghue
> Sent: Thursday, 30 August 2012 7:30 AM
> To: jose@ietf.org
> Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters
>

> Folks,
>
> Given the confusion around the original version of this poll, I'd like=
> to try again.
>
> The basic question is unchanged, the room count from Vancouver has bee= n
> corrected, and a clarification regarding the status of SHA1 in the OAE= P
> specification has been added.  For those of you who voted and fee= l you
> may have misunderstood the question or voted incorrectly, please feel<= br> > free to update your answer.
>
> Question:
> Should SHA1 (and mgf1SHA1) be the default parameters for these
> algorithms?
> Note:  These are the default parameters specified in RFC 3447, Se= ction
> A.2.1, and are widely deployed.
>
> Room vote:  5 yes, 0 no, 3 discuss
>
> Thanks,
> Karen
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



 

--
--Breno

--_000_4E1F6AAD24975D4BA5B1680429673943667AEEF3TK5EX14MBXC284r_-- From James.H.Manger@team.telstra.com Wed Aug 29 17:11:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2900311E80FF for ; Wed, 29 Aug 2012 17:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SlsGhQFQ0jO for ; Wed, 29 Aug 2012 17:11:15 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 35FCE11E80F8 for ; Wed, 29 Aug 2012 17:11:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,337,1344175200"; d="scan'208,217";a="88978495" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 30 Aug 2012 10:11:03 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="85203132" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccvi.tcif.telstra.com.au with ESMTP; 30 Aug 2012 10:11:02 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Thu, 30 Aug 2012 10:11:01 +1000 From: "Manger, James H" To: Mike Jones , Breno de Medeiros Date: Thu, 30 Aug 2012 10:11:00 +1000 Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: AQHNhi1oMG2bBx4eNkynEaO7ZDjUypdxd/uAgAAArACAAAB5IIAAAeVg Message-ID: <255B9BB34FB7D647A506DC292726F6E114FC6C4501@WSMSG3153V.srv.dir.telstra.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FC6C4501WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:11:16 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FC6C4501WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gd2hhdCBhYm91dCBSUzI1NiwgUlMzODQsIGFuZCBSUzUxMj8NCg0KLS0NCkphbWVzIE1hbmdl cg0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t XQ0KU2VudDogVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDEwOjA3IEFNDQpUbzogQnJlbm8gZGUg TWVkZWlyb3M7IE1hbmdlciwgSmFtZXMgSA0KQ2M6IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0ZXJz DQoNCldoZXJlIGEga2V5IHNpemUgaXMgcmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxn b3JpdGhtLCBpdOKAmXMgaW5jbHVkZWQgaW4gdGhlIG5hbWUuICBFeGFtcGxlczogIEhTMjU2LCBB MTI4R0NNLg0KV2hlcmUgdGhlIHNpemUgaXNu4oCZdCByZXF1aXJlZCB0byBmdWxseSBzcGVjaWZ5 IHRoZSBhbGdvcml0aG0sIGl0IGlzbuKAmXQuICBFeGFtcGxlczogIFJTQTFfNSwgUlNBLU9BRVAs IEVDU0gtRVMuDQoNCk5vIGluY29uc2lzdGVuY3kuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogam9z ZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJlbm8gZGUgTWVkZWlyb3MNClNl bnQ6IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDU6MDEgUE0NClRvOiBNYW5nZXIsIEphbWVz IEgNCkNjOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRlcnMN Cg0KQ29uY3VyIHdpdGggdGhlIGFuYWx5c2lzIHRoYXQgJ1JTQS1PQUVQJyB0ZXJtaW5vbG9neSBh cHBlYXJzIGluY29uc2lzdGVudCB3aXRoIG90aGVyIGFjcm9ueW0gdXNhZ2UuDQoNCk9uIFdlZCwg QXVnIDI5LCAyMDEyIGF0IDQ6NTggUE0sIE1hbmdlciwgSmFtZXMgSCA8SmFtZXMuSC5NYW5nZXJA dGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4+ IHdyb3RlOg0KPiBTaG91bGQgU0hBMSAoYW5kIG1nZjFTSEExKSBiZSB0aGUgZGVmYXVsdCBwYXJh bWV0ZXJzIGZvciB0aGVzZQ0KPiBhbGdvcml0aG1zPw0KV2UgZG9u4oCZdCBoYXZlICJhbGdvcml0 aG0gcGFyYW1ldGVycyIgaW4gSk9TRSDigJMgdGhhdCBpcyB0aGUgc3ViamVjdCBvZiBhIHNlcGFy YXRlIFBPTEwgKCJTdXBwb3J0IG11bHRpcGxlIHR5cGVzIGZvciBhbGdvcml0aG1zIikuIEpPU0Ug Y3VycmVudGx5IGhhcyBhbGdvcml0aG0gbGFiZWxzIHdpdGggbm8gcGFyYW1ldGVycy4NCg0KQ29u c2VxdWVudGx5IHRoaXMgcXVlc3Rpb24gaXMgcmVhbGx5IGFza2luZyBvbmUgb2YgdGhlIGZvbGxv d2luZzoNCg0KUTEuIFNob3VsZCBSU0EgT0FFUCB3aXRoIFNIQS0xIGJlIGRlZmluZWQgZm9yIHVz ZSB3aXRoIEpPU0U/IFBlcmhhcHMgYWRkaXRpb25hbGx5LCBzaG91bGQgaXQgYmUgbWFuZGF0b3J5 IHRvIGltcGxlbWVudD8NClRoZSBjb3JlIG9mIHRoaXMgcXVlc3Rpb24gaXMgd2hldGhlciBTSEEt MSBpcyBjcnlwdG9ncmFwaGljYWxseS1jb21wcm9taXNlZCBlbm91Z2ggdGhhdCB3ZSBzaG91bGRu J3QgdXNlIGl0IGluIG5ldyBjcnlwdG8gc3BlY3MsIG9yIGlzIGl0cyB3aWRlc3ByZWFkLWF2YWls YWJpbGl0eSBtb3JlIGltcG9ydGFudCB0aGFuIGFueSBjcnlwdG8gd2Vha25lc3M/DQoNClEyLiBT aG91bGQgdGhlIGxhYmVsICJSU0EtT0FFUCIgYmUgdXNlZCBmb3IgUlNBIE9BRVAgd2l0aCBTSEEt MT8NCg0KTXkgYW5zd2VyIHRvIFEyIGlzIE5PLiBUaGUgIlJTQS1PQUVQIiBsYWJlbCBpcyBpbmNv bnNpc3RlbnQgd2l0aCBvdGhlciBKT1NFIGFsZyBuYW1lcy4gSldBIHNwZWNpZmllcyAiSFM1MTIi LCAiUlM1MTIiLCAiRVM1MTIiLCBhbmQgIkNTNTEyIiB3aGVyZSB0aGUgU3h4eCBzdWZmaXggaW5k aWNhdGVzIGEgaGFzaCBhbGdvcml0aG0uIFJTQSBPQUVQIHdpdGggU0hBLTEgY291bGQgdXNlICJS T1MxIiBvciAiUk9TMTYwIi4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9z ZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+IEthcmVuIE8nRG9ub2dodWUNCj4g U2VudDogVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDc6MzAgQU0NCj4gVG86IGpvc2VAaWV0Zi5v cmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtqb3NlXSAoUkVETykgUE9MTDog UlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRlcnMNCj4NCj4gRm9sa3MsDQo+DQo+IEdp dmVuIHRoZSBjb25mdXNpb24gYXJvdW5kIHRoZSBvcmlnaW5hbCB2ZXJzaW9uIG9mIHRoaXMgcG9s bCwgSSdkIGxpa2UNCj4gdG8gdHJ5IGFnYWluLg0KPg0KPiBUaGUgYmFzaWMgcXVlc3Rpb24gaXMg dW5jaGFuZ2VkLCB0aGUgcm9vbSBjb3VudCBmcm9tIFZhbmNvdXZlciBoYXMgYmVlbg0KPiBjb3Jy ZWN0ZWQsIGFuZCBhIGNsYXJpZmljYXRpb24gcmVnYXJkaW5nIHRoZSBzdGF0dXMgb2YgU0hBMSBp biB0aGUgT0FFUA0KPiBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFkZGVkLiAgRm9yIHRob3NlIG9m IHlvdSB3aG8gdm90ZWQgYW5kIGZlZWwgeW91DQo+IG1heSBoYXZlIG1pc3VuZGVyc3Rvb2QgdGhl IHF1ZXN0aW9uIG9yIHZvdGVkIGluY29ycmVjdGx5LCBwbGVhc2UgZmVlbA0KPiBmcmVlIHRvIHVw ZGF0ZSB5b3VyIGFuc3dlci4NCj4NCj4gUXVlc3Rpb246DQo+IFNob3VsZCBTSEExIChhbmQgbWdm MVNIQTEpIGJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgZm9yIHRoZXNlDQo+IGFsZ29yaXRobXM/ DQo+IE5vdGU6ICBUaGVzZSBhcmUgdGhlIGRlZmF1bHQgcGFyYW1ldGVycyBzcGVjaWZpZWQgaW4g UkZDIDM0NDcsIFNlY3Rpb24NCj4gQS4yLjEsIGFuZCBhcmUgd2lkZWx5IGRlcGxveWVkLg0KPg0K PiBSb29tIHZvdGU6ICA1IHllcywgMCBubywgMyBkaXNjdXNzDQo+DQo+IFRoYW5rcywNCj4gS2Fy ZW4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g am9zZSBtYWlsaW5nIGxpc3QNCj4gam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4N Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QN Cmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQoNCi0tDQotLUJyZW5vDQo= --_000_255B9BB34FB7D647A506DC292726F6E114FC6C4501WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVy cGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlNvIHdoYXQgYWJvdXQgUlMyNTYsIFJTMzg0LCBhbmQgUlM1MTI/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1pa2UgSm9uZXMgW21haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXks IDMwIEF1Z3VzdCAyMDEyIDEwOjA3IEFNPGJyPjxiPlRvOjwvYj4gQnJlbm8gZGUgTWVkZWlyb3M7 IE1hbmdlciwgSmFtZXMgSDxicj48Yj5DYzo8L2I+IGpvc2VAaWV0Zi5vcmc8YnI+PGI+U3ViamVj dDo8L2I+IFJFOiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBw YXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoZXJlIGEga2V5IHNpemUgaXMgcmVxdWlyZWQgdG8gZnVs bHkgc3BlY2lmeSB0aGUgYWxnb3JpdGhtLCBpdOKAmXMgaW5jbHVkZWQgaW4gdGhlIG5hbWUuJm5i c3A7IEV4YW1wbGVzOiZuYnNwOyBIUzI1NiwgQTEyOEdDTS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaGVy ZSB0aGUgc2l6ZSBpc27igJl0IHJlcXVpcmVkIHRvIGZ1bGx5IHNwZWNpZnkgdGhlIGFsZ29yaXRo bSwgaXQgaXNu4oCZdC4mbmJzcDsgRXhhbXBsZXM6Jm5ic3A7IFJTQTFfNSwgUlNBLU9BRVAsIEVD U0gtRVMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Tm8gaW5jb25z aXN0ZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhh bGYgT2YgPC9iPkJyZW5vIGRlIE1lZGVpcm9zPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1 Z3VzdCAyOSwgMjAxMiA1OjAxIFBNPGJyPjxiPlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBIPGJyPjxi PkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+ PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0Et UFNTIGRlZmF1bHQgcGFyYW1ldGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Q29uY3VyIHdpdGggdGhlIGFuYWx5c2lzIHRo YXQgJ1JTQS1PQUVQJyB0ZXJtaW5vbG9neSBhcHBlYXJzIGluY29uc2lzdGVudCB3aXRoIG90aGVy IGFjcm9ueW0gdXNhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUz5PbiBXZWQsIEF1ZyAyOSwgMjAxMiBhdCA0OjU4IFBNLCBNYW5nZXIsIEphbWVzIEggJmx0 OzxhIGhyZWY9Im1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIiB0YXJnZXQ9 Il9ibGFuayI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+Jmd0OyBTaG91bGQgU0hBMSAoYW5kIG1n ZjFTSEExKSBiZSB0aGUgZGVmYXVsdCBwYXJhbWV0ZXJzIGZvciB0aGVzZTxicj4mZ3Q7IGFsZ29y aXRobXM/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPldlIGRvbuKAmXQgaGF2ZSAmcXVvdDthbGdvcml0aG0gcGFyYW1ldGVycyZx dW90OyBpbiBKT1NFIOKAkyB0aGF0IGlzIHRoZSBzdWJqZWN0IG9mIGEgc2VwYXJhdGUgUE9MTCAo JnF1b3Q7U3VwcG9ydCBtdWx0aXBsZSB0eXBlcyBmb3IgYWxnb3JpdGhtcyZxdW90OykuIEpPU0Ug Y3VycmVudGx5IGhhcyBhbGdvcml0aG0gbGFiZWxzIHdpdGggbm8gcGFyYW1ldGVycy48YnI+PGJy PkNvbnNlcXVlbnRseSB0aGlzIHF1ZXN0aW9uIGlzIHJlYWxseSBhc2tpbmcgb25lIG9mIHRoZSBm b2xsb3dpbmc6PGJyPjxicj5RMS4gU2hvdWxkIFJTQSBPQUVQIHdpdGggU0hBLTEgYmUgZGVmaW5l ZCBmb3IgdXNlIHdpdGggSk9TRT8gUGVyaGFwcyBhZGRpdGlvbmFsbHksIHNob3VsZCBpdCBiZSBt YW5kYXRvcnkgdG8gaW1wbGVtZW50Pzxicj5UaGUgY29yZSBvZiB0aGlzIHF1ZXN0aW9uIGlzIHdo ZXRoZXIgU0hBLTEgaXMgY3J5cHRvZ3JhcGhpY2FsbHktY29tcHJvbWlzZWQgZW5vdWdoIHRoYXQg d2Ugc2hvdWxkbid0IHVzZSBpdCBpbiBuZXcgY3J5cHRvIHNwZWNzLCBvciBpcyBpdHMgd2lkZXNw cmVhZC1hdmFpbGFiaWxpdHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBhbnkgY3J5cHRvIHdlYWtuZXNz Pzxicj48YnI+UTIuIFNob3VsZCB0aGUgbGFiZWwgJnF1b3Q7UlNBLU9BRVAmcXVvdDsgYmUgdXNl ZCBmb3IgUlNBIE9BRVAgd2l0aCBTSEEtMT88YnI+PGJyPk15IGFuc3dlciB0byBRMiBpcyBOTy4g VGhlICZxdW90O1JTQS1PQUVQJnF1b3Q7IGxhYmVsIGlzIGluY29uc2lzdGVudCB3aXRoIG90aGVy IEpPU0UgYWxnIG5hbWVzLiBKV0Egc3BlY2lmaWVzICZxdW90O0hTNTEyJnF1b3Q7LCAmcXVvdDtS UzUxMiZxdW90OywgJnF1b3Q7RVM1MTImcXVvdDssIGFuZCAmcXVvdDtDUzUxMiZxdW90OyB3aGVy ZSB0aGUgU3h4eCBzdWZmaXggaW5kaWNhdGVzIGEgaGFzaCBhbGdvcml0aG0uIFJTQSBPQUVQIHdp dGggU0hBLTEgY291bGQgdXNlICZxdW90O1JPUzEmcXVvdDsgb3IgJnF1b3Q7Uk9TMTYwJnF1b3Q7 Ljxicj48YnI+LS08YnI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGll dGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Ompvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mPGJyPiZndDsgS2FyZW4gTydEb25vZ2h1ZTxicj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCAz MCBBdWd1c3QgMjAxMiA3OjMwIEFNPGJyPiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpqb3NlQGll dGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4mZ3Q7IFN1YmplY3Q6IFtqb3NlXSAoUkVETykg UE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRlcnM8YnI+Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVM+Jmd0OyBGb2xrcyw8YnI+Jmd0Ozxicj4mZ3Q7IEdpdmVuIHRoZSBjb25mdXNpb24g YXJvdW5kIHRoZSBvcmlnaW5hbCB2ZXJzaW9uIG9mIHRoaXMgcG9sbCwgSSdkIGxpa2U8YnI+Jmd0 OyB0byB0cnkgYWdhaW4uPGJyPiZndDs8YnI+Jmd0OyBUaGUgYmFzaWMgcXVlc3Rpb24gaXMgdW5j aGFuZ2VkLCB0aGUgcm9vbSBjb3VudCBmcm9tIFZhbmNvdXZlciBoYXMgYmVlbjxicj4mZ3Q7IGNv cnJlY3RlZCwgYW5kIGEgY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgdGhlIHN0YXR1cyBvZiBTSEEx IGluIHRoZSBPQUVQPGJyPiZndDsgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiBhZGRlZC4gJm5ic3A7 Rm9yIHRob3NlIG9mIHlvdSB3aG8gdm90ZWQgYW5kIGZlZWwgeW91PGJyPiZndDsgbWF5IGhhdmUg bWlzdW5kZXJzdG9vZCB0aGUgcXVlc3Rpb24gb3Igdm90ZWQgaW5jb3JyZWN0bHksIHBsZWFzZSBm ZWVsPGJyPiZndDsgZnJlZSB0byB1cGRhdGUgeW91ciBhbnN3ZXIuPGJyPiZndDs8YnI+Jmd0OyBR dWVzdGlvbjo8YnI+Jmd0OyBTaG91bGQgU0hBMSAoYW5kIG1nZjFTSEExKSBiZSB0aGUgZGVmYXVs dCBwYXJhbWV0ZXJzIGZvciB0aGVzZTxicj4mZ3Q7IGFsZ29yaXRobXM/PGJyPiZndDsgTm90ZTog Jm5ic3A7VGhlc2UgYXJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgc3BlY2lmaWVkIGluIFJGQyAz NDQ3LCBTZWN0aW9uPGJyPiZndDsgQS4yLjEsIGFuZCBhcmUgd2lkZWx5IGRlcGxveWVkLjxicj4m Z3Q7PGJyPiZndDsgUm9vbSB2b3RlOiAmbmJzcDs1IHllcywgMCBubywgMyBkaXNjdXNzPGJyPiZn dDs8YnI+Jmd0OyBUaGFua3MsPGJyPiZndDsgS2FyZW48YnI+Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IGpvc2UgbWFpbGluZyBsaXN0 PGJyPiZndDsgPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+ PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9q b3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9qb3NlPC9hPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj5qb3NlIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9y ZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48YnI+PGJyIGNsZWFy PWFsbD48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4tLSA8 YnI+LS1CcmVubzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+ PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114FC6C4501WSMSG3153Vsrv_-- From ve7jtb@ve7jtb.com Wed Aug 29 17:22:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523E721F8462 for ; Wed, 29 Aug 2012 17:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ9lHIAMeRFb for ; Wed, 29 Aug 2012 17:22:39 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB88C11E80F5 for ; Wed, 29 Aug 2012 17:22:38 -0700 (PDT) Received: by ghbg16 with SMTP id g16so259570ghb.31 for ; Wed, 29 Aug 2012 17:22:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=NFFlxFsw9d0O2kYX3grksXi3ue6G6EsiGqXzHnqz8Ms=; b=DE+YP1jh1BQWdVRDTj4qZqX7Hz5NbwUuPgSOwBKbE1ZisiqGb+M4VwdOwh6MqWP/6l NAvzfenc6gxkSi/cdZYUIvMVJ5ua7kYZ50ga3z7aD77uCdC/JTMdELGW/UrtLOaAeHBZ zR+LWbnv/tIisJNSTEWCAC9qH4rxDaSMCmI6fcChxKYBwVj+xUWYgd7ZWwL7CcrAJ2WI ZTqyfwm/L4o0mDj3IHNUBHYwkvmLUmlCuf6jNUMEp2LT/zf/gwfPqF2e8922Sif4mmZN JlxgfwXVHY2x7MjnPdPJqfBAIObRXY0R0x1yohCJnpExvO4rfo5Tc/XfwHcFaVGk+jTO 7ntQ== Received: by 10.236.173.164 with SMTP id v24mr3487571yhl.60.1346286158109; Wed, 29 Aug 2012 17:22:38 -0700 (PDT) Received: from [192.168.1.211] (190-20-35-71.baf.movistar.cl. [190.20.35.71]) by mx.google.com with ESMTPS id z5sm144876ang.7.2012.08.29.17.21.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 17:22:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_32E5C027-7CCA-443C-819D-F0B16E53970E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Wed, 29 Aug 2012 20:21:20 -0400 Message-Id: <6DE0480F-705C-4A6A-A6B2-FE78BA8F3FFB@ve7jtb.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQm07nW9BRWcUGlrhZYm4bQX1CRrwYrUcNwlaV11cXVHccDZMmd2khj34Z8K1nw2LvGafsNs Cc: Breno de Medeiros , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:22:40 -0000 --Apple-Mail=_32E5C027-7CCA-443C-819D-F0B16E53970E Content-Type: multipart/alternative; boundary="Apple-Mail=_4AD8362F-0C1C-4D4A-8436-ADA72F95A664" --Apple-Mail=_4AD8362F-0C1C-4D4A-8436-ADA72F95A664 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To clarify we are talking about the internal hash algorithm for the OAEP = or PSS padding calculation and NOT the hash of the size of the hash for = the message or the size of the key for AES. In most cases the internal hash size is not exposed but baked in to OAEP = and PSS calculation. If we were talking about making SHA1 the default hash size for RSA = signatures I would be opposed to this, but we are talking about a = internal of the padding calculation.=20 I have not seen any indication that SHA1 is in any way compromised for = that use. =20 My vote was to make SHA1 the hash function used for PSS/OAEP padding in = the RSA-OAEP and RSA-PSS algorithms. The size of the hash for signing and the size of the key for encryption = are separate issues. John B. On 2012-08-29, at 8:06 PM, Mike Jones = wrote: > Where a key size is required to fully specify the algorithm, it=92s = included in the name. Examples: HS256, A128GCM. > Where the size isn=92t required to fully specify the algorithm, it = isn=92t. Examples: RSA1_5, RSA-OAEP, ECSH-ES. > =20 > No inconsistency. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Breno de Medeiros > Sent: Wednesday, August 29, 2012 5:01 PM > To: Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters > =20 > Concur with the analysis that 'RSA-OAEP' terminology appears = inconsistent with other acronym usage. > =20 >=20 > On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H = wrote: > > Should SHA1 (and mgf1SHA1) be the default parameters for these > > algorithms? >=20 > We don=92t have "algorithm parameters" in JOSE =96 that is the subject = of a separate POLL ("Support multiple types for algorithms"). JOSE = currently has algorithm labels with no parameters. >=20 > Consequently this question is really asking one of the following: >=20 > Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps = additionally, should it be mandatory to implement? > The core of this question is whether SHA-1 is = cryptographically-compromised enough that we shouldn't use it in new = crypto specs, or is its widespread-availability more important than any = crypto weakness? >=20 > Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1? >=20 > My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with other = JOSE alg names. JWA specifies "HS512", "RS512", "ES512", and "CS512" = where the Sxxx suffix indicates a hash algorithm. RSA OAEP with SHA-1 = could use "ROS1" or "ROS160". >=20 > -- > James Manger >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > > Karen O'Donoghue > > Sent: Thursday, 30 August 2012 7:30 AM > > To: jose@ietf.org > > Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters > > > > Folks, > > > > Given the confusion around the original version of this poll, I'd = like > > to try again. > > > > The basic question is unchanged, the room count from Vancouver has = been > > corrected, and a clarification regarding the status of SHA1 in the = OAEP > > specification has been added. For those of you who voted and feel = you > > may have misunderstood the question or voted incorrectly, please = feel > > free to update your answer. > > > > Question: > > Should SHA1 (and mgf1SHA1) be the default parameters for these > > algorithms? > > Note: These are the default parameters specified in RFC 3447, = Section > > A.2.1, and are widely deployed. > > > > Room vote: 5 yes, 0 no, 3 discuss > > > > Thanks, > > Karen > > _______________________________________________ > > 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 >=20 >=20 > =20 > --=20 > --Breno >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_4AD8362F-0C1C-4D4A-8436-ADA72F95A664 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 To clarify we are talking about = the internal hash algorithm for the OAEP or PSS padding calculation and = NOT the hash of the size of the hash for the message or the size of the = key for AES.

In most cases the internal hash size is = not exposed but baked in to OAEP and PSS = calculation.

If we were talking about making = SHA1 the default hash size for RSA signatures I would be opposed to = this, but we are talking about a internal of the padding = calculation. 
I have not seen any indication that SHA1 is = in any way compromised for that use. =   

My vote was to make SHA1 the hash = function used for PSS/OAEP padding in the RSA-OAEP and RSA-PSS = algorithms.

The size of the hash for signing = and the size of the key for encryption are separate = issues.

John B.

On = 2012-08-29, at 8:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Where a key size is = required to fully specify the algorithm, it=92s included in the = name.  Examples:  HS256, A128GCM.
Where the size isn=92t = required to fully specify the algorithm, it isn=92t.  = Examples:  RSA1_5, RSA-OAEP, ECSH-ES.
 
No = inconsistency.
 
 
 jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Breno de = Medeiros
Sent: Wednesday, August 29, 2012 = 5:01 PM
To: Manger, James = H
Cc: jose@ietf.org
Subject: Re: [jose] (REDO) POLL: = RSA-OAEP/RSA-PSS default parameters
 
 

We don=92t = have "algorithm parameters" in JOSE =96 that is the subject of a = separate POLL ("Support multiple types for algorithms"). JOSE currently = has algorithm labels with no parameters.

Consequently this = question is really asking one of the following:

Q1. Should RSA = OAEP with SHA-1 be defined for use with JOSE? Perhaps additionally, = should it be mandatory to implement?
The core of this question is = whether SHA-1 is cryptographically-compromised enough that we shouldn't = use it in new crypto specs, or is its widespread-availability more = important than any crypto weakness?

Q2. Should the label = "RSA-OAEP" be used for RSA OAEP with SHA-1?

My answer to Q2 is = NO. The "RSA-OAEP" label is inconsistent with other JOSE alg names. JWA = specifies "HS512", "RS512", "ES512", and "CS512" where the Sxxx suffix = indicates a hash algorithm. RSA OAEP with SHA-1 could use "ROS1" or = "ROS160".

--
James Manger

> -----Original Message-----
> = From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of
> Karen O'Donoghue
> Sent: Thursday, 30 August 2012 7:30 = AM
> To: jose@ietf.org
> Subject: [jose] (REDO) POLL: = RSA-OAEP/RSA-PSS default = parameters
>

= --Apple-Mail=_4AD8362F-0C1C-4D4A-8436-ADA72F95A664-- --Apple-Mail=_32E5C027-7CCA-443C-819D-F0B16E53970E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgz MDAwMjEyMVowIwYJKoZIhvcNAQkEMRYEFKkC6zMWqKCzFU3AAXVaBp5grbu1MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AB3cN8tTtG5nPNEbm6LgcYA7oY8b1Zfc/rObFazkVRjQ1KT8VdG3MMMHUw1ytEs/rbatUNbld+ZP zUQREF2fpD5VdveSiZuE6/jDl0c71nh8jFJEnJiMNcqLCVCFpN+DsavtrYiqg0MgmM71mG0ATOXK bo0SEHeQezWfC1TmDZpss6vHq8JFbsUzBJZhD/7B/D77KUemnrPOUXLxOExSv0jY2kcIq6wTKbbF TxWfXr2+WDUhJvQXAf1fvAPEOAxwT3V6HNIC4N/psGOzkp6X7USJX1v70vL+3vr9zAANsypo8gzA wnQ4nEaxQ08D6ZBEbfjHREi9QxRp3JY7Kf0dMBkAAAAAAAA= --Apple-Mail=_32E5C027-7CCA-443C-819D-F0B16E53970E-- From Michael.Jones@microsoft.com Wed Aug 29 17:31:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EF11E80FB for ; Wed, 29 Aug 2012 17:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJlR1Zb0o0VQ for ; Wed, 29 Aug 2012 17:31:40 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 874BD11E80F5 for ; Wed, 29 Aug 2012 17:31:40 -0700 (PDT) Received: from mail82-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 Aug 2012 00:31:39 +0000 Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id E6A608A01E0; Thu, 30 Aug 2012 00:31:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371Ic89bh542M1432Ic857h4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail82-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 134628669817369_18464; Thu, 30 Aug 2012 00:31:38 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.249]) by mail82-co1.bigfish.com (Postfix) with ESMTP id F3DF17C0047; Thu, 30 Aug 2012 00:31:37 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 Aug 2012 00:31:37 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Thu, 30 Aug 2012 00:31:36 +0000 From: Mike Jones To: "Manger, James H" , Breno de Medeiros Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: AQHNhi1oMG2bBx4eNkynEaO7ZDjUypdxd/uAgAAArACAAAB5IIAAAeVggAAGENA= Date: Thu, 30 Aug 2012 00:31:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AEF8B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FC6C4501@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FC6C4501@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.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667AEF8BTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:31:41 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667AEF8BTK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhleeKAmXJlIGluIHRoZSBmaXJzdCBjYXRlZ29yeSwgaW4gd2hpY2ggYSBrZXkgc2l6ZSBpcyBy ZXF1aXJlZCB0byBmdWxseSBzcGVjaWZ5IHRoZSBhbGdvcml0aG0uDQoNCkZyb206IGpvc2UtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1hbmdlciwgSmFtZXMgSA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgNToxMSBQ TQ0KVG86IE1pa2UgSm9uZXM7IEJyZW5vIGRlIE1lZGVpcm9zDQpDYzogam9zZUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0 IHBhcmFtZXRlcnMNCg0KU28gd2hhdCBhYm91dCBSUzI1NiwgUlMzODQsIGFuZCBSUzUxMj8NCg0K LS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tXTxtYWlsdG86W21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b21dPg0KU2VudDogVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDEwOjA3IEFNDQpUbzogQnJlbm8g ZGUgTWVkZWlyb3M7IE1hbmdlciwgSmFtZXMgSA0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpv c2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9S U0EtUFNTIGRlZmF1bHQgcGFyYW1ldGVycw0KDQpXaGVyZSBhIGtleSBzaXplIGlzIHJlcXVpcmVk IHRvIGZ1bGx5IHNwZWNpZnkgdGhlIGFsZ29yaXRobSwgaXTigJlzIGluY2x1ZGVkIGluIHRoZSBu YW1lLiAgRXhhbXBsZXM6ICBIUzI1NiwgQTEyOEdDTS4NCldoZXJlIHRoZSBzaXplIGlzbuKAmXQg cmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxnb3JpdGhtLCBpdCBpc27igJl0LiAgRXhh bXBsZXM6ICBSU0ExXzUsIFJTQS1PQUVQLCBFQ1NILUVTLg0KDQpObyBpbmNvbnNpc3RlbmN5Lg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJyZW5vIGRlIE1lZGVpcm9zDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxMiA1 OjAxIFBNDQpUbzogTWFuZ2VyLCBKYW1lcyBIDQpDYzogam9zZUBpZXRmLm9yZzxtYWlsdG86am9z ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JT QS1QU1MgZGVmYXVsdCBwYXJhbWV0ZXJzDQoNCkNvbmN1ciB3aXRoIHRoZSBhbmFseXNpcyB0aGF0 ICdSU0EtT0FFUCcgdGVybWlub2xvZ3kgYXBwZWFycyBpbmNvbnNpc3RlbnQgd2l0aCBvdGhlciBh Y3JvbnltIHVzYWdlLg0KDQpPbiBXZWQsIEF1ZyAyOSwgMjAxMiBhdCA0OjU4IFBNLCBNYW5nZXIs IEphbWVzIEggPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToNCj4gU2hvdWxkIFNIQTEgKGFuZCBtZ2Yx U0hBMSkgYmUgdGhlIGRlZmF1bHQgcGFyYW1ldGVycyBmb3IgdGhlc2UNCj4gYWxnb3JpdGhtcz8N CldlIGRvbuKAmXQgaGF2ZSAiYWxnb3JpdGhtIHBhcmFtZXRlcnMiIGluIEpPU0Ug4oCTIHRoYXQg aXMgdGhlIHN1YmplY3Qgb2YgYSBzZXBhcmF0ZSBQT0xMICgiU3VwcG9ydCBtdWx0aXBsZSB0eXBl cyBmb3IgYWxnb3JpdGhtcyIpLiBKT1NFIGN1cnJlbnRseSBoYXMgYWxnb3JpdGhtIGxhYmVscyB3 aXRoIG5vIHBhcmFtZXRlcnMuDQoNCkNvbnNlcXVlbnRseSB0aGlzIHF1ZXN0aW9uIGlzIHJlYWxs eSBhc2tpbmcgb25lIG9mIHRoZSBmb2xsb3dpbmc6DQoNClExLiBTaG91bGQgUlNBIE9BRVAgd2l0 aCBTSEEtMSBiZSBkZWZpbmVkIGZvciB1c2Ugd2l0aCBKT1NFPyBQZXJoYXBzIGFkZGl0aW9uYWxs eSwgc2hvdWxkIGl0IGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQ/DQpUaGUgY29yZSBvZiB0aGlz IHF1ZXN0aW9uIGlzIHdoZXRoZXIgU0hBLTEgaXMgY3J5cHRvZ3JhcGhpY2FsbHktY29tcHJvbWlz ZWQgZW5vdWdoIHRoYXQgd2Ugc2hvdWxkbid0IHVzZSBpdCBpbiBuZXcgY3J5cHRvIHNwZWNzLCBv ciBpcyBpdHMgd2lkZXNwcmVhZC1hdmFpbGFiaWxpdHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBhbnkg Y3J5cHRvIHdlYWtuZXNzPw0KDQpRMi4gU2hvdWxkIHRoZSBsYWJlbCAiUlNBLU9BRVAiIGJlIHVz ZWQgZm9yIFJTQSBPQUVQIHdpdGggU0hBLTE/DQoNCk15IGFuc3dlciB0byBRMiBpcyBOTy4gVGhl ICJSU0EtT0FFUCIgbGFiZWwgaXMgaW5jb25zaXN0ZW50IHdpdGggb3RoZXIgSk9TRSBhbGcgbmFt ZXMuIEpXQSBzcGVjaWZpZXMgIkhTNTEyIiwgIlJTNTEyIiwgIkVTNTEyIiwgYW5kICJDUzUxMiIg d2hlcmUgdGhlIFN4eHggc3VmZml4IGluZGljYXRlcyBhIGhhc2ggYWxnb3JpdGhtLiBSU0EgT0FF UCB3aXRoIFNIQS0xIGNvdWxkIHVzZSAiUk9TMSIgb3IgIlJPUzE2MCIuDQoNCi0tDQpKYW1lcyBN YW5nZXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3NlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP Zg0KPiBLYXJlbiBPJ0Rvbm9naHVlDQo+IFNlbnQ6IFRodXJzZGF5LCAzMCBBdWd1c3QgMjAxMiA3 OjMwIEFNDQo+IFRvOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0 ZXJzDQo+DQo+IEZvbGtzLA0KPg0KPiBHaXZlbiB0aGUgY29uZnVzaW9uIGFyb3VuZCB0aGUgb3Jp Z2luYWwgdmVyc2lvbiBvZiB0aGlzIHBvbGwsIEknZCBsaWtlDQo+IHRvIHRyeSBhZ2Fpbi4NCj4N Cj4gVGhlIGJhc2ljIHF1ZXN0aW9uIGlzIHVuY2hhbmdlZCwgdGhlIHJvb20gY291bnQgZnJvbSBW YW5jb3V2ZXIgaGFzIGJlZW4NCj4gY29ycmVjdGVkLCBhbmQgYSBjbGFyaWZpY2F0aW9uIHJlZ2Fy ZGluZyB0aGUgc3RhdHVzIG9mIFNIQTEgaW4gdGhlIE9BRVANCj4gc3BlY2lmaWNhdGlvbiBoYXMg YmVlbiBhZGRlZC4gIEZvciB0aG9zZSBvZiB5b3Ugd2hvIHZvdGVkIGFuZCBmZWVsIHlvdQ0KPiBt YXkgaGF2ZSBtaXN1bmRlcnN0b29kIHRoZSBxdWVzdGlvbiBvciB2b3RlZCBpbmNvcnJlY3RseSwg cGxlYXNlIGZlZWwNCj4gZnJlZSB0byB1cGRhdGUgeW91ciBhbnN3ZXIuDQo+DQo+IFF1ZXN0aW9u Og0KPiBTaG91bGQgU0hBMSAoYW5kIG1nZjFTSEExKSBiZSB0aGUgZGVmYXVsdCBwYXJhbWV0ZXJz IGZvciB0aGVzZQ0KPiBhbGdvcml0aG1zPw0KPiBOb3RlOiAgVGhlc2UgYXJlIHRoZSBkZWZhdWx0 IHBhcmFtZXRlcnMgc3BlY2lmaWVkIGluIFJGQyAzNDQ3LCBTZWN0aW9uDQo+IEEuMi4xLCBhbmQg YXJlIHdpZGVseSBkZXBsb3llZC4NCj4NCj4gUm9vbSB2b3RlOiAgNSB5ZXMsIDAgbm8sIDMgZGlz Y3Vzcw0KPg0KPiBUaGFua3MsDQo+IEthcmVuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+IGpvc2VAaWV0Zi5v cmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0KDQot LQ0KLS1CcmVubw0K --_000_4E1F6AAD24975D4BA5B1680429673943667AEF8BTK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXnigJlyZSBpbiB0aGUgZmlyc3QgY2F0ZWdvcnksIGlu IHdoaWNoIGEga2V5IHNpemUgaXMgcmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxnb3Jp dGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpv c2UtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuZ2VyLCBKYW1lcyBI PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDU6MTEgUE08YnI+ DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IEJyZW5vIGRlIE1lZGVpcm9zPGJyPg0KPGI+Q2M6PC9i PiBqb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gKFJFRE8pIFBP TEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB3aGF0IGFib3V0IFJTMjU2LCBSUzM4NCwg YW5kIFJTNTEyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBNaWtlIEpvbmVzDQo8YSBocmVmPSJtYWlsdG86W21haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb21dIj5bbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV08L2E+ DQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDEwOjA3IEFNPGJy Pg0KPGI+VG86PC9iPiBCcmVubyBkZSBNZWRlaXJvczsgTWFuZ2VyLCBKYW1lcyBIPGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNB LVBTUyBkZWZhdWx0IHBhcmFtZXRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVyZSBhIGtleSBzaXplIGlzIHJlcXVpcmVkIHRv IGZ1bGx5IHNwZWNpZnkgdGhlIGFsZ29yaXRobSwgaXTigJlzIGluY2x1ZGVkIGluIHRoZSBuYW1l LiZuYnNwOyBFeGFtcGxlczombmJzcDsgSFMyNTYsIEExMjhHQ00uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldoZXJlIHRoZSBzaXplIGlzbuKAmXQgcmVxdWlyZWQgdG8gZnVsbHkgc3Bl Y2lmeSB0aGUgYWxnb3JpdGhtLCBpdCBpc27igJl0LiZuYnNwOyBFeGFtcGxlczombmJzcDsgUlNB MV81LCBSU0EtT0FFUCwgRUNTSC1FUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIGluY29uc2lzdGVuY3kuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2Ut Ym91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmciPm1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5CcmVubyBkZSBNZWRlaXJvczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAy OSwgMjAxMiA1OjAxIFBNPGJyPg0KPGI+VG86PC9iPiBNYW5nZXIsIEphbWVzIEg8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0Et UFNTIGRlZmF1bHQgcGFyYW1ldGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29u Y3VyIHdpdGggdGhlIGFuYWx5c2lzIHRoYXQgJ1JTQS1PQUVQJyB0ZXJtaW5vbG9neSBhcHBlYXJz IGluY29uc2lzdGVudCB3aXRoIG90aGVyIGFjcm9ueW0gdXNhZ2UuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IEF1ZyAyOSwgMjAxMiBhdCA0OjU4IFBNLCBNYW5nZXIsIEphbWVzIEggJmx0OzxhIGhyZWY9Im1h aWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+Jmd0OyBTaG91bGQgU0hBMSAoYW5kIG1nZjFTSEExKSBiZSB0aGUgZGVmYXVsdCBwYXJhbWV0 ZXJzIGZvciB0aGVzZTxicj4NCiZndDsgYWxnb3JpdGhtcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZG9u4oCZdCBoYXZlICZxdW90O2FsZ29yaXRobSBw YXJhbWV0ZXJzJnF1b3Q7IGluIEpPU0Ug4oCTIHRoYXQgaXMgdGhlIHN1YmplY3Qgb2YgYSBzZXBh cmF0ZSBQT0xMICgmcXVvdDtTdXBwb3J0IG11bHRpcGxlIHR5cGVzIGZvciBhbGdvcml0aG1zJnF1 b3Q7KS4gSk9TRSBjdXJyZW50bHkgaGFzIGFsZ29yaXRobSBsYWJlbHMgd2l0aCBubyBwYXJhbWV0 ZXJzLjxicj4NCjxicj4NCkNvbnNlcXVlbnRseSB0aGlzIHF1ZXN0aW9uIGlzIHJlYWxseSBhc2tp bmcgb25lIG9mIHRoZSBmb2xsb3dpbmc6PGJyPg0KPGJyPg0KUTEuIFNob3VsZCBSU0EgT0FFUCB3 aXRoIFNIQS0xIGJlIGRlZmluZWQgZm9yIHVzZSB3aXRoIEpPU0U/IFBlcmhhcHMgYWRkaXRpb25h bGx5LCBzaG91bGQgaXQgYmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudD88YnI+DQpUaGUgY29yZSBv ZiB0aGlzIHF1ZXN0aW9uIGlzIHdoZXRoZXIgU0hBLTEgaXMgY3J5cHRvZ3JhcGhpY2FsbHktY29t cHJvbWlzZWQgZW5vdWdoIHRoYXQgd2Ugc2hvdWxkbid0IHVzZSBpdCBpbiBuZXcgY3J5cHRvIHNw ZWNzLCBvciBpcyBpdHMgd2lkZXNwcmVhZC1hdmFpbGFiaWxpdHkgbW9yZSBpbXBvcnRhbnQgdGhh biBhbnkgY3J5cHRvIHdlYWtuZXNzPzxicj4NCjxicj4NClEyLiBTaG91bGQgdGhlIGxhYmVsICZx dW90O1JTQS1PQUVQJnF1b3Q7IGJlIHVzZWQgZm9yIFJTQSBPQUVQIHdpdGggU0hBLTE/PGJyPg0K PGJyPg0KTXkgYW5zd2VyIHRvIFEyIGlzIE5PLiBUaGUgJnF1b3Q7UlNBLU9BRVAmcXVvdDsgbGFi ZWwgaXMgaW5jb25zaXN0ZW50IHdpdGggb3RoZXIgSk9TRSBhbGcgbmFtZXMuIEpXQSBzcGVjaWZp ZXMgJnF1b3Q7SFM1MTImcXVvdDssICZxdW90O1JTNTEyJnF1b3Q7LCAmcXVvdDtFUzUxMiZxdW90 OywgYW5kICZxdW90O0NTNTEyJnF1b3Q7IHdoZXJlIHRoZSBTeHh4IHN1ZmZpeCBpbmRpY2F0ZXMg YSBoYXNoIGFsZ29yaXRobS4gUlNBIE9BRVAgd2l0aCBTSEEtMSBjb3VsZCB1c2UgJnF1b3Q7Uk9T MSZxdW90OyBvciAmcXVvdDtST1MxNjAmcXVvdDsuPGJyPg0KPGJyPg0KLS08YnI+DQpKYW1lcyBN YW5nZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQom Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiA8YSBocmVmPSJt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2Vz QGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPGJyPg0KJmd0OyBLYXJlbiBPJ0Rvbm9naHVlPGJy Pg0KJmd0OyBTZW50OiBUaHVyc2RheSwgMzAgQXVndXN0IDIwMTIgNzozMCBBTTxicj4NCiZndDsg VG86IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4N CiZndDsgU3ViamVjdDogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1 bHQgcGFyYW1ldGVyczxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEZvbGtzLDxicj4NCiZndDs8YnI+DQomZ3Q7 IEdpdmVuIHRoZSBjb25mdXNpb24gYXJvdW5kIHRoZSBvcmlnaW5hbCB2ZXJzaW9uIG9mIHRoaXMg cG9sbCwgSSdkIGxpa2U8YnI+DQomZ3Q7IHRvIHRyeSBhZ2Fpbi48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaGUgYmFzaWMgcXVlc3Rpb24gaXMgdW5jaGFuZ2VkLCB0aGUgcm9vbSBjb3VudCBmcm9tIFZh bmNvdXZlciBoYXMgYmVlbjxicj4NCiZndDsgY29ycmVjdGVkLCBhbmQgYSBjbGFyaWZpY2F0aW9u IHJlZ2FyZGluZyB0aGUgc3RhdHVzIG9mIFNIQTEgaW4gdGhlIE9BRVA8YnI+DQomZ3Q7IHNwZWNp ZmljYXRpb24gaGFzIGJlZW4gYWRkZWQuICZuYnNwO0ZvciB0aG9zZSBvZiB5b3Ugd2hvIHZvdGVk IGFuZCBmZWVsIHlvdTxicj4NCiZndDsgbWF5IGhhdmUgbWlzdW5kZXJzdG9vZCB0aGUgcXVlc3Rp b24gb3Igdm90ZWQgaW5jb3JyZWN0bHksIHBsZWFzZSBmZWVsPGJyPg0KJmd0OyBmcmVlIHRvIHVw ZGF0ZSB5b3VyIGFuc3dlci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBRdWVzdGlvbjo8YnI+DQomZ3Q7 IFNob3VsZCBTSEExIChhbmQgbWdmMVNIQTEpIGJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgZm9y IHRoZXNlPGJyPg0KJmd0OyBhbGdvcml0aG1zPzxicj4NCiZndDsgTm90ZTogJm5ic3A7VGhlc2Ug YXJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgc3BlY2lmaWVkIGluIFJGQyAzNDQ3LCBTZWN0aW9u PGJyPg0KJmd0OyBBLjIuMSwgYW5kIGFyZSB3aWRlbHkgZGVwbG95ZWQuPGJyPg0KJmd0Ozxicj4N CiZndDsgUm9vbSB2b3RlOiAmbmJzcDs1IHllcywgMCBubywgMyBkaXNjdXNzPGJyPg0KJmd0Ozxi cj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgS2FyZW48YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBqb3NlIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pvc2U8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi0tIDxicj4NCi0tQnJlbm88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B1680429673943667AEF8BTK5EX14MBXC284r_-- From James.H.Manger@team.telstra.com Wed Aug 29 18:13:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0B11E8102 for ; Wed, 29 Aug 2012 18:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyAsx7dbyoPE for ; Wed, 29 Aug 2012 18:13:26 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9132211E80F5 for ; Wed, 29 Aug 2012 18:13:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,337,1344175200"; d="scan'208,217";a="94270483" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 30 Aug 2012 11:13:25 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6819"; a="85975773" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 30 Aug 2012 11:13:24 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Thu, 30 Aug 2012 11:13:23 +1000 From: "Manger, James H" To: Mike Jones Date: Thu, 30 Aug 2012 11:13:22 +1000 Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: AQHNhi1oMG2bBx4eNkynEaO7ZDjUypdxd/uAgAAArACAAAB5IIAAAeVggAAGENCAAAMHYA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114FC6C4739@WSMSG3153V.srv.dir.telstra.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FC6C4501@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEF8B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667AEF8B@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FC6C4739WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:13:27 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FC6C4739WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm8gMzg0LWJpdCBrZXkgaW52b2x2ZWQgaW4gUlMzODQgKFJTQVNTQS1QS0NTMS1W MV81IHdpdGggU0hBLTM4NCkuIEl0IGludm9sdmVzLCBzYXksIGEgMjA0OC1iaXQgUlNBIGtleS4N Cg0KV2hlbiB5b3Ugc2F5IOKAnGtleSBzaXpl4oCdIGRvIHlvdSBhY3R1YWxseSBtZWFuIOKAnGlt cG9ydGFudCBzaXpl4oCdLCBpbnN0ZWFkIG9mIOKAnHNpemUgb2YgYSBjcnlwdG8ga2V54oCdPw0K DQpQZXJoYXBzIHRoZSBoYXNoIHNpemUgYW5kIGhhc2ggYWxnb3JpdGhtIGFyZSDigJxtb3JlIGlt cG9ydGFudOKAnSBpbiBhbiBSU0Egc2lnbmF0dXJlIHRoYW4gaW4gYW4gUlNBIGVuY3J5cHRpb24g cGFkZGluZyBzY2hlbWUsIHRob3VnaCB0aGF0IGlzIGEgZmFpcmx5IHN1YnRsZSBoYWlyIHRvIGJl IHNwbGl0dGluZyB3aGVuIG5hbWluZyBKT1NFIGFsZ29yaXRobXMuIFdlIHdvdWxkIG5lZWQgdG8g c3RvcCB0YWxraW5nIGFib3V0IOKAnGhhc2ggYWxnb3JpdGhtc+KAnSBhbmQgc3RhcnQgdGFsa2lu ZyBhYm91dCwgc2F5LCDigJxjb2xsaXNpb24tcmVzaXN0YW50IGhhc2ggYWxnb3JpdGhtc+KAnSBh bmQg4oCccHNldWRvcmFuZG9tIGZ1bmN0aW9uc+KAnSBpZiB3ZSB3YW50IHRvIHNwbGl0IHRoYXQg aGFpci4NCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2Vu dDogVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDEwOjMyIEFNDQpUbzogTWFuZ2VyLCBKYW1lcyBI OyBCcmVubyBkZSBNZWRlaXJvcw0KQ2M6IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbam9z ZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0ZXJzDQoNClRo ZXnigJlyZSBpbiB0aGUgZmlyc3QgY2F0ZWdvcnksIGluIHdoaWNoIGEga2V5IHNpemUgaXMgcmVx dWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxnb3JpdGhtLg0KDQpGcm9tOiBqb3NlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5nZXIsIEphbWVzIEgNClNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDI5LCAyMDEyIDU6MTEgUE0NClRvOiBNaWtlIEpvbmVzOyBCcmVubyBkZSBN ZWRlaXJvcw0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQgcGFyYW1l dGVycw0KDQpTbyB3aGF0IGFib3V0IFJTMjU2LCBSUzM4NCwgYW5kIFJTNTEyPw0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb21dPG1haWx0bzpbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV0+DQpT ZW50OiBUaHVyc2RheSwgMzAgQXVndXN0IDIwMTIgMTA6MDcgQU0NClRvOiBCcmVubyBkZSBNZWRl aXJvczsgTWFuZ2VyLCBKYW1lcyBIDQpDYzogam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1Mg ZGVmYXVsdCBwYXJhbWV0ZXJzDQoNCldoZXJlIGEga2V5IHNpemUgaXMgcmVxdWlyZWQgdG8gZnVs bHkgc3BlY2lmeSB0aGUgYWxnb3JpdGhtLCBpdOKAmXMgaW5jbHVkZWQgaW4gdGhlIG5hbWUuICBF eGFtcGxlczogIEhTMjU2LCBBMTI4R0NNLg0KV2hlcmUgdGhlIHNpemUgaXNu4oCZdCByZXF1aXJl ZCB0byBmdWxseSBzcGVjaWZ5IHRoZSBhbGdvcml0aG0sIGl0IGlzbuKAmXQuICBFeGFtcGxlczog IFJTQTFfNSwgUlNBLU9BRVAsIEVDU0gtRVMuDQoNCk5vIGluY29uc2lzdGVuY3kuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJl bm8gZGUgTWVkZWlyb3MNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDU6MDEgUE0N ClRvOiBNYW5nZXIsIEphbWVzIEgNCkNjOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBk ZWZhdWx0IHBhcmFtZXRlcnMNCg0KQ29uY3VyIHdpdGggdGhlIGFuYWx5c2lzIHRoYXQgJ1JTQS1P QUVQJyB0ZXJtaW5vbG9neSBhcHBlYXJzIGluY29uc2lzdGVudCB3aXRoIG90aGVyIGFjcm9ueW0g dXNhZ2UuDQoNCk9uIFdlZCwgQXVnIDI5LCAyMDEyIGF0IDQ6NTggUE0sIE1hbmdlciwgSmFtZXMg SCA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJA dGVhbS50ZWxzdHJhLmNvbT4+IHdyb3RlOg0KPiBTaG91bGQgU0hBMSAoYW5kIG1nZjFTSEExKSBi ZSB0aGUgZGVmYXVsdCBwYXJhbWV0ZXJzIGZvciB0aGVzZQ0KPiBhbGdvcml0aG1zPw0KV2UgZG9u 4oCZdCBoYXZlICJhbGdvcml0aG0gcGFyYW1ldGVycyIgaW4gSk9TRSDigJMgdGhhdCBpcyB0aGUg c3ViamVjdCBvZiBhIHNlcGFyYXRlIFBPTEwgKCJTdXBwb3J0IG11bHRpcGxlIHR5cGVzIGZvciBh bGdvcml0aG1zIikuIEpPU0UgY3VycmVudGx5IGhhcyBhbGdvcml0aG0gbGFiZWxzIHdpdGggbm8g cGFyYW1ldGVycy4NCg0KQ29uc2VxdWVudGx5IHRoaXMgcXVlc3Rpb24gaXMgcmVhbGx5IGFza2lu ZyBvbmUgb2YgdGhlIGZvbGxvd2luZzoNCg0KUTEuIFNob3VsZCBSU0EgT0FFUCB3aXRoIFNIQS0x IGJlIGRlZmluZWQgZm9yIHVzZSB3aXRoIEpPU0U/IFBlcmhhcHMgYWRkaXRpb25hbGx5LCBzaG91 bGQgaXQgYmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudD8NClRoZSBjb3JlIG9mIHRoaXMgcXVlc3Rp b24gaXMgd2hldGhlciBTSEEtMSBpcyBjcnlwdG9ncmFwaGljYWxseS1jb21wcm9taXNlZCBlbm91 Z2ggdGhhdCB3ZSBzaG91bGRuJ3QgdXNlIGl0IGluIG5ldyBjcnlwdG8gc3BlY3MsIG9yIGlzIGl0 cyB3aWRlc3ByZWFkLWF2YWlsYWJpbGl0eSBtb3JlIGltcG9ydGFudCB0aGFuIGFueSBjcnlwdG8g d2Vha25lc3M/DQoNClEyLiBTaG91bGQgdGhlIGxhYmVsICJSU0EtT0FFUCIgYmUgdXNlZCBmb3Ig UlNBIE9BRVAgd2l0aCBTSEEtMT8NCg0KTXkgYW5zd2VyIHRvIFEyIGlzIE5PLiBUaGUgIlJTQS1P QUVQIiBsYWJlbCBpcyBpbmNvbnNpc3RlbnQgd2l0aCBvdGhlciBKT1NFIGFsZyBuYW1lcy4gSldB IHNwZWNpZmllcyAiSFM1MTIiLCAiUlM1MTIiLCAiRVM1MTIiLCBhbmQgIkNTNTEyIiB3aGVyZSB0 aGUgU3h4eCBzdWZmaXggaW5kaWNhdGVzIGEgaGFzaCBhbGdvcml0aG0uIFJTQSBPQUVQIHdpdGgg U0hBLTEgY291bGQgdXNlICJST1MxIiBvciAiUk9TMTYwIi4NCg0KLS0NCkphbWVzIE1hbmdlcg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGpvc2UtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+IEth cmVuIE8nRG9ub2dodWUNCj4gU2VudDogVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDc6MzAgQU0N Cj4gVG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtq b3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRlcnMNCj4N Cj4gRm9sa3MsDQo+DQo+IEdpdmVuIHRoZSBjb25mdXNpb24gYXJvdW5kIHRoZSBvcmlnaW5hbCB2 ZXJzaW9uIG9mIHRoaXMgcG9sbCwgSSdkIGxpa2UNCj4gdG8gdHJ5IGFnYWluLg0KPg0KPiBUaGUg YmFzaWMgcXVlc3Rpb24gaXMgdW5jaGFuZ2VkLCB0aGUgcm9vbSBjb3VudCBmcm9tIFZhbmNvdXZl ciBoYXMgYmVlbg0KPiBjb3JyZWN0ZWQsIGFuZCBhIGNsYXJpZmljYXRpb24gcmVnYXJkaW5nIHRo ZSBzdGF0dXMgb2YgU0hBMSBpbiB0aGUgT0FFUA0KPiBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFk ZGVkLiAgRm9yIHRob3NlIG9mIHlvdSB3aG8gdm90ZWQgYW5kIGZlZWwgeW91DQo+IG1heSBoYXZl IG1pc3VuZGVyc3Rvb2QgdGhlIHF1ZXN0aW9uIG9yIHZvdGVkIGluY29ycmVjdGx5LCBwbGVhc2Ug ZmVlbA0KPiBmcmVlIHRvIHVwZGF0ZSB5b3VyIGFuc3dlci4NCj4NCj4gUXVlc3Rpb246DQo+IFNo b3VsZCBTSEExIChhbmQgbWdmMVNIQTEpIGJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgZm9yIHRo ZXNlDQo+IGFsZ29yaXRobXM/DQo+IE5vdGU6ICBUaGVzZSBhcmUgdGhlIGRlZmF1bHQgcGFyYW1l dGVycyBzcGVjaWZpZWQgaW4gUkZDIDM0NDcsIFNlY3Rpb24NCj4gQS4yLjEsIGFuZCBhcmUgd2lk ZWx5IGRlcGxveWVkLg0KPg0KPiBSb29tIHZvdGU6ICA1IHllcywgMCBubywgMyBkaXNjdXNzDQo+ DQo+IFRoYW5rcywNCj4gS2FyZW4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gam9zZSBtYWlsaW5nIGxpc3QNCj4gam9zZUBpZXRmLm9yZzxtYWls dG86am9zZUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9qb3NlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K am9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQoNCi0tDQotLUJy ZW5vDQo= --_000_255B9BB34FB7D647A506DC292726F6E114FC6C4739WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5 IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9u MT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGVyZSBpcyBubyAz ODQtYml0IGtleSBpbnZvbHZlZCBpbiBSUzM4NCAoUlNBU1NBLVBLQ1MxLVYxXzUgd2l0aCBTSEEt Mzg0KS4gSXQgaW52b2x2ZXMsIHNheSwgYSAyMDQ4LWJpdCBSU0Ega2V5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+V2hlbiB5b3Ugc2F5IOKAnGtleSBzaXpl4oCdIGRvIHlvdSBhY3R1YWxseSBtZWFuIOKA nGltcG9ydGFudCBzaXpl4oCdLCBpbnN0ZWFkIG9mIOKAnHNpemUgb2YgYSBjcnlwdG8ga2V54oCd PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGVyaGFwcyB0aGUgaGFzaCBzaXplIGFuZCBoYXNoIGFsZ29y aXRobSBhcmUg4oCcbW9yZSBpbXBvcnRhbnTigJ0gaW4gYW4gUlNBIHNpZ25hdHVyZSB0aGFuIGlu IGFuIFJTQSBlbmNyeXB0aW9uIHBhZGRpbmcgc2NoZW1lLCB0aG91Z2ggdGhhdCBpcyBhIGZhaXJs eSBzdWJ0bGUgaGFpciB0byBiZSBzcGxpdHRpbmcgd2hlbiBuYW1pbmcgSk9TRSBhbGdvcml0aG1z LiBXZSB3b3VsZCBuZWVkIHRvIHN0b3AgdGFsa2luZyBhYm91dCDigJxoYXNoIGFsZ29yaXRobXPi gJ0gYW5kIHN0YXJ0IHRhbGtpbmcgYWJvdXQsIHNheSwg4oCcY29sbGlzaW9uLXJlc2lzdGFudCBo YXNoIGFsZ29yaXRobXPigJ0gYW5kIOKAnHBzZXVkb3JhbmRvbSBmdW5jdGlvbnPigJ0gaWYgd2Ug d2FudCB0byBzcGxpdCB0aGF0IGhhaXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1l cyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj48Yj5TZW50OjwvYj4gVGh1cnNk YXksIDMwIEF1Z3VzdCAyMDEyIDEwOjMyIEFNPGJyPjxiPlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBI OyBCcmVubyBkZSBNZWRlaXJvczxicj48Yj5DYzo8L2I+IGpvc2VAaWV0Zi5vcmc8YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVs dCBwYXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZXnigJlyZSBpbiB0aGUgZmlyc3QgY2F0ZWdvcnks IGluIHdoaWNoIGEga2V5IHNpemUgaXMgcmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxn b3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1h aWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxh IGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpqb3NlLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hbmdlciwgSmFtZXMgSDxicj48Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgNToxMSBQTTxicj48Yj5Ubzo8L2I+ IE1pa2UgSm9uZXM7IEJyZW5vIGRlIE1lZGVpcm9zPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBS ZTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQgcGFyYW1ldGVy czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U28gd2hhdCBhYm91dCBSUzI1NiwgUlMzODQsIGFu ZCBSUzUxMj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gTWlr ZSBKb25lcyA8YSBocmVmPSJtYWlsdG86W21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b21dIj5bbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbV08L2E+IDxicj48Yj5TZW50 OjwvYj4gVGh1cnNkYXksIDMwIEF1Z3VzdCAyMDEyIDEwOjA3IEFNPGJyPjxiPlRvOjwvYj4gQnJl bm8gZGUgTWVkZWlyb3M7IE1hbmdlciwgSmFtZXMgSDxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4g UkU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+V2hlcmUgYSBrZXkgc2l6ZSBpcyByZXF1aXJlZCB0byBmdWxseSBzcGVj aWZ5IHRoZSBhbGdvcml0aG0sIGl04oCZcyBpbmNsdWRlZCBpbiB0aGUgbmFtZS4mbmJzcDsgRXhh bXBsZXM6Jm5ic3A7IEhTMjU2LCBBMTI4R0NNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoZXJlIHRoZSBz aXplIGlzbuKAmXQgcmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxnb3JpdGhtLCBpdCBp c27igJl0LiZuYnNwOyBFeGFtcGxlczombmJzcDsgUlNBMV81LCBSU0EtT0FFUCwgRUNTSC1FUy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5ObyBpbmNvbnNpc3RlbmN5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9z ZS1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8 L2I+QnJlbm8gZGUgTWVkZWlyb3M8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI5 LCAyMDEyIDU6MDEgUE08YnI+PGI+VG86PC9iPiBNYW5nZXIsIEphbWVzIEg8YnI+PGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGI+ U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVm YXVsdCBwYXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5Db25jdXIgd2l0aCB0aGUgYW5hbHlzaXMgdGhhdCAnUlNB LU9BRVAnIHRlcm1pbm9sb2d5IGFwcGVhcnMgaW5jb25zaXN0ZW50IHdpdGggb3RoZXIgYWNyb255 bSB1c2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPk9u IFdlZCwgQXVnIDI5LCAyMDEyIGF0IDQ6NTggUE0sIE1hbmdlciwgSmFtZXMgSCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iIHRhcmdldD0iX2JsYW5r Ij5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4mZ3Q7IFNob3VsZCBTSEExIChhbmQgbWdmMVNIQTEp IGJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgZm9yIHRoZXNlPGJyPiZndDsgYWxnb3JpdGhtcz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+V2UgZG9u4oCZdCBoYXZlICZxdW90O2FsZ29yaXRobSBwYXJhbWV0ZXJzJnF1b3Q7IGlu IEpPU0Ug4oCTIHRoYXQgaXMgdGhlIHN1YmplY3Qgb2YgYSBzZXBhcmF0ZSBQT0xMICgmcXVvdDtT dXBwb3J0IG11bHRpcGxlIHR5cGVzIGZvciBhbGdvcml0aG1zJnF1b3Q7KS4gSk9TRSBjdXJyZW50 bHkgaGFzIGFsZ29yaXRobSBsYWJlbHMgd2l0aCBubyBwYXJhbWV0ZXJzLjxicj48YnI+Q29uc2Vx dWVudGx5IHRoaXMgcXVlc3Rpb24gaXMgcmVhbGx5IGFza2luZyBvbmUgb2YgdGhlIGZvbGxvd2lu Zzo8YnI+PGJyPlExLiBTaG91bGQgUlNBIE9BRVAgd2l0aCBTSEEtMSBiZSBkZWZpbmVkIGZvciB1 c2Ugd2l0aCBKT1NFPyBQZXJoYXBzIGFkZGl0aW9uYWxseSwgc2hvdWxkIGl0IGJlIG1hbmRhdG9y eSB0byBpbXBsZW1lbnQ/PGJyPlRoZSBjb3JlIG9mIHRoaXMgcXVlc3Rpb24gaXMgd2hldGhlciBT SEEtMSBpcyBjcnlwdG9ncmFwaGljYWxseS1jb21wcm9taXNlZCBlbm91Z2ggdGhhdCB3ZSBzaG91 bGRuJ3QgdXNlIGl0IGluIG5ldyBjcnlwdG8gc3BlY3MsIG9yIGlzIGl0cyB3aWRlc3ByZWFkLWF2 YWlsYWJpbGl0eSBtb3JlIGltcG9ydGFudCB0aGFuIGFueSBjcnlwdG8gd2Vha25lc3M/PGJyPjxi cj5RMi4gU2hvdWxkIHRoZSBsYWJlbCAmcXVvdDtSU0EtT0FFUCZxdW90OyBiZSB1c2VkIGZvciBS U0EgT0FFUCB3aXRoIFNIQS0xPzxicj48YnI+TXkgYW5zd2VyIHRvIFEyIGlzIE5PLiBUaGUgJnF1 b3Q7UlNBLU9BRVAmcXVvdDsgbGFiZWwgaXMgaW5jb25zaXN0ZW50IHdpdGggb3RoZXIgSk9TRSBh bGcgbmFtZXMuIEpXQSBzcGVjaWZpZXMgJnF1b3Q7SFM1MTImcXVvdDssICZxdW90O1JTNTEyJnF1 b3Q7LCAmcXVvdDtFUzUxMiZxdW90OywgYW5kICZxdW90O0NTNTEyJnF1b3Q7IHdoZXJlIHRoZSBT eHh4IHN1ZmZpeCBpbmRpY2F0ZXMgYSBoYXNoIGFsZ29yaXRobS4gUlNBIE9BRVAgd2l0aCBTSEEt MSBjb3VsZCB1c2UgJnF1b3Q7Uk9TMSZxdW90OyBvciAmcXVvdDtST1MxNjAmcXVvdDsuPGJyPjxi cj4tLTxicj5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4mZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmci Pmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8 YnI+Jmd0OyBLYXJlbiBPJ0Rvbm9naHVlPGJyPiZndDsgU2VudDogVGh1cnNkYXksIDMwIEF1Z3Vz dCAyMDEyIDc6MzAgQU08YnI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmci Pmpvc2VAaWV0Zi5vcmc8L2E+PGJyPiZndDsgU3ViamVjdDogW2pvc2VdIChSRURPKSBQT0xMOiBS U0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQgcGFyYW1ldGVyczxicj4mZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V Uz4mZ3Q7IEZvbGtzLDxicj4mZ3Q7PGJyPiZndDsgR2l2ZW4gdGhlIGNvbmZ1c2lvbiBhcm91bmQg dGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgdGhpcyBwb2xsLCBJJ2QgbGlrZTxicj4mZ3Q7IHRvIHRy eSBhZ2Fpbi48YnI+Jmd0Ozxicj4mZ3Q7IFRoZSBiYXNpYyBxdWVzdGlvbiBpcyB1bmNoYW5nZWQs IHRoZSByb29tIGNvdW50IGZyb20gVmFuY291dmVyIGhhcyBiZWVuPGJyPiZndDsgY29ycmVjdGVk LCBhbmQgYSBjbGFyaWZpY2F0aW9uIHJlZ2FyZGluZyB0aGUgc3RhdHVzIG9mIFNIQTEgaW4gdGhl IE9BRVA8YnI+Jmd0OyBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGFkZGVkLiAmbmJzcDtGb3IgdGhv c2Ugb2YgeW91IHdobyB2b3RlZCBhbmQgZmVlbCB5b3U8YnI+Jmd0OyBtYXkgaGF2ZSBtaXN1bmRl cnN0b29kIHRoZSBxdWVzdGlvbiBvciB2b3RlZCBpbmNvcnJlY3RseSwgcGxlYXNlIGZlZWw8YnI+ Jmd0OyBmcmVlIHRvIHVwZGF0ZSB5b3VyIGFuc3dlci48YnI+Jmd0Ozxicj4mZ3Q7IFF1ZXN0aW9u Ojxicj4mZ3Q7IFNob3VsZCBTSEExIChhbmQgbWdmMVNIQTEpIGJlIHRoZSBkZWZhdWx0IHBhcmFt ZXRlcnMgZm9yIHRoZXNlPGJyPiZndDsgYWxnb3JpdGhtcz88YnI+Jmd0OyBOb3RlOiAmbmJzcDtU aGVzZSBhcmUgdGhlIGRlZmF1bHQgcGFyYW1ldGVycyBzcGVjaWZpZWQgaW4gUkZDIDM0NDcsIFNl Y3Rpb248YnI+Jmd0OyBBLjIuMSwgYW5kIGFyZSB3aWRlbHkgZGVwbG95ZWQuPGJyPiZndDs8YnI+ Jmd0OyBSb29tIHZvdGU6ICZuYnNwOzUgeWVzLCAwIG5vLCAzIGRpc2N1c3M8YnI+Jmd0Ozxicj4m Z3Q7IFRoYW5rcyw8YnI+Jmd0OyBLYXJlbjxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgam9zZSBtYWlsaW5nIGxpc3Q8YnI+Jmd0 OyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8 L2E+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pmpvc2UgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3Nl QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxicj48YnIgY2xlYXI9YWxsPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPi0tIDxicj4tLUJy ZW5vPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48 L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E114FC6C4739WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Wed Aug 29 18:33:50 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC221F8489 for ; Wed, 29 Aug 2012 18:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.833 X-Spam-Level: X-Spam-Status: No, score=-3.833 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPUH5ZdumgRo for ; Wed, 29 Aug 2012 18:33:49 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 57BC821F848B for ; Wed, 29 Aug 2012 18:33:48 -0700 (PDT) Received: from mail105-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 Aug 2012 01:33:47 +0000 Received: from mail105-am1 (localhost [127.0.0.1]) by mail105-am1-R.bigfish.com (Postfix) with ESMTP id 6A76A1E0079; Thu, 30 Aug 2012 01:33:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371Ic89bh542M1432Ic857h4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail105-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail105-am1 (localhost.localdomain [127.0.0.1]) by mail105-am1 (MessageSwitch) id 1346290425314895_12055; Thu, 30 Aug 2012 01:33:45 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.254]) by mail105-am1.bigfish.com (Postfix) with ESMTP id 4A6F82E0047; Thu, 30 Aug 2012 01:33:45 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 Aug 2012 01:33:42 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 30 Aug 2012 01:33:38 +0000 From: Mike Jones To: "Manger, James H" Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: AQHNhi1oMG2bBx4eNkynEaO7ZDjUypdxd/uAgAAArACAAAB5IIAAAeVggAAGENCAAAMHYIAADfUg Date: Thu, 30 Aug 2012 01:33:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AF0FA@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FC6C4501@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEF8B@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FC6C4739@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FC6C4739@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667AF0FATK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:33:50 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667AF0FATK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZS4gIHMva2V5IHNpemUvc2l6ZS9nIGluIG15IGRlc2NyaXB0aW9uIGJlbG93LiAgU29tZXRp bWVzIHRoZSBzaXplcyBhcmUgZm9yIHRoaW5ncyBsaWtlIGhhc2ggZnVuY3Rpb24gb3V0cHV0IHNp emUsIHJhdGhlciB0aGFuIGtleSBzaXplLg0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0 bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMjksIDIwMTIgNjoxMyBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBqb3NlQGlldGYub3JnDQpT dWJqZWN0OiBSRTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQg cGFyYW1ldGVycw0KDQpUaGVyZSBpcyBubyAzODQtYml0IGtleSBpbnZvbHZlZCBpbiBSUzM4NCAo UlNBU1NBLVBLQ1MxLVYxXzUgd2l0aCBTSEEtMzg0KS4gSXQgaW52b2x2ZXMsIHNheSwgYSAyMDQ4 LWJpdCBSU0Ega2V5Lg0KDQpXaGVuIHlvdSBzYXkg4oCca2V5IHNpemXigJ0gZG8geW91IGFjdHVh bGx5IG1lYW4g4oCcaW1wb3J0YW50IHNpemXigJ0sIGluc3RlYWQgb2Yg4oCcc2l6ZSBvZiBhIGNy eXB0byBrZXnigJ0/DQoNClBlcmhhcHMgdGhlIGhhc2ggc2l6ZSBhbmQgaGFzaCBhbGdvcml0aG0g YXJlIOKAnG1vcmUgaW1wb3J0YW504oCdIGluIGFuIFJTQSBzaWduYXR1cmUgdGhhbiBpbiBhbiBS U0EgZW5jcnlwdGlvbiBwYWRkaW5nIHNjaGVtZSwgdGhvdWdoIHRoYXQgaXMgYSBmYWlybHkgc3Vi dGxlIGhhaXIgdG8gYmUgc3BsaXR0aW5nIHdoZW4gbmFtaW5nIEpPU0UgYWxnb3JpdGhtcy4gV2Ug d291bGQgbmVlZCB0byBzdG9wIHRhbGtpbmcgYWJvdXQg4oCcaGFzaCBhbGdvcml0aG1z4oCdIGFu ZCBzdGFydCB0YWxraW5nIGFib3V0LCBzYXksIOKAnGNvbGxpc2lvbi1yZXNpc3RhbnQgaGFzaCBh bGdvcml0aG1z4oCdIGFuZCDigJxwc2V1ZG9yYW5kb20gZnVuY3Rpb25z4oCdIGlmIHdlIHdhbnQg dG8gc3BsaXQgdGhhdCBoYWlyLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IGpvc2UtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2Ut Ym91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXT4g T24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IFRodXJzZGF5LCAzMCBBdWd1c3QgMjAxMiAx MDozMiBBTQ0KVG86IE1hbmdlciwgSmFtZXMgSDsgQnJlbm8gZGUgTWVkZWlyb3MNCkNjOiBqb3Nl QGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtqb3NlXSAoUkVE TykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRlcnMNCg0KVGhleeKAmXJl IGluIHRoZSBmaXJzdCBjYXRlZ29yeSwgaW4gd2hpY2ggYSBrZXkgc2l6ZSBpcyByZXF1aXJlZCB0 byBmdWxseSBzcGVjaWZ5IHRoZSBhbGdvcml0aG0uDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hbmdlciwgSmFtZXMgSA0KU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMjksIDIwMTIgNToxMSBQTQ0KVG86IE1pa2UgSm9uZXM7IEJyZW5vIGRlIE1lZGVpcm9z DQpDYzogam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb am9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0ZXJzDQoN ClNvIHdoYXQgYWJvdXQgUlMyNTYsIFJTMzg0LCBhbmQgUlM1MTI/DQoNCi0tDQpKYW1lcyBNYW5n ZXINCg0KRnJvbTogTWlrZSBKb25lcyBbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bV08bWFpbHRvOlttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXT4NClNlbnQ6IFRo dXJzZGF5LCAzMCBBdWd1c3QgMjAxMiAxMDowNyBBTQ0KVG86IEJyZW5vIGRlIE1lZGVpcm9zOyBN YW5nZXIsIEphbWVzIEgNCkNjOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0K U3ViamVjdDogUkU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBTUyBkZWZhdWx0 IHBhcmFtZXRlcnMNCg0KV2hlcmUgYSBrZXkgc2l6ZSBpcyByZXF1aXJlZCB0byBmdWxseSBzcGVj aWZ5IHRoZSBhbGdvcml0aG0sIGl04oCZcyBpbmNsdWRlZCBpbiB0aGUgbmFtZS4gIEV4YW1wbGVz OiAgSFMyNTYsIEExMjhHQ00uDQpXaGVyZSB0aGUgc2l6ZSBpc27igJl0IHJlcXVpcmVkIHRvIGZ1 bGx5IHNwZWNpZnkgdGhlIGFsZ29yaXRobSwgaXQgaXNu4oCZdC4gIEV4YW1wbGVzOiAgUlNBMV81 LCBSU0EtT0FFUCwgRUNTSC1FUy4NCg0KTm8gaW5jb25zaXN0ZW5jeS4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmVubyBkZSBN ZWRlaXJvcw0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTIgNTowMSBQTQ0KVG86IE1h bmdlciwgSmFtZXMgSA0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQg cGFyYW1ldGVycw0KDQpDb25jdXIgd2l0aCB0aGUgYW5hbHlzaXMgdGhhdCAnUlNBLU9BRVAnIHRl cm1pbm9sb2d5IGFwcGVhcnMgaW5jb25zaXN0ZW50IHdpdGggb3RoZXIgYWNyb255bSB1c2FnZS4N Cg0KT24gV2VkLCBBdWcgMjksIDIwMTIgYXQgNDo1OCBQTSwgTWFuZ2VyLCBKYW1lcyBIIDxKYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPG1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tPj4gd3JvdGU6DQo+IFNob3VsZCBTSEExIChhbmQgbWdmMVNIQTEpIGJlIHRoZSBk ZWZhdWx0IHBhcmFtZXRlcnMgZm9yIHRoZXNlDQo+IGFsZ29yaXRobXM/DQpXZSBkb27igJl0IGhh dmUgImFsZ29yaXRobSBwYXJhbWV0ZXJzIiBpbiBKT1NFIOKAkyB0aGF0IGlzIHRoZSBzdWJqZWN0 IG9mIGEgc2VwYXJhdGUgUE9MTCAoIlN1cHBvcnQgbXVsdGlwbGUgdHlwZXMgZm9yIGFsZ29yaXRo bXMiKS4gSk9TRSBjdXJyZW50bHkgaGFzIGFsZ29yaXRobSBsYWJlbHMgd2l0aCBubyBwYXJhbWV0 ZXJzLg0KDQpDb25zZXF1ZW50bHkgdGhpcyBxdWVzdGlvbiBpcyByZWFsbHkgYXNraW5nIG9uZSBv ZiB0aGUgZm9sbG93aW5nOg0KDQpRMS4gU2hvdWxkIFJTQSBPQUVQIHdpdGggU0hBLTEgYmUgZGVm aW5lZCBmb3IgdXNlIHdpdGggSk9TRT8gUGVyaGFwcyBhZGRpdGlvbmFsbHksIHNob3VsZCBpdCBi ZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50Pw0KVGhlIGNvcmUgb2YgdGhpcyBxdWVzdGlvbiBpcyB3 aGV0aGVyIFNIQS0xIGlzIGNyeXB0b2dyYXBoaWNhbGx5LWNvbXByb21pc2VkIGVub3VnaCB0aGF0 IHdlIHNob3VsZG4ndCB1c2UgaXQgaW4gbmV3IGNyeXB0byBzcGVjcywgb3IgaXMgaXRzIHdpZGVz cHJlYWQtYXZhaWxhYmlsaXR5IG1vcmUgaW1wb3J0YW50IHRoYW4gYW55IGNyeXB0byB3ZWFrbmVz cz8NCg0KUTIuIFNob3VsZCB0aGUgbGFiZWwgIlJTQS1PQUVQIiBiZSB1c2VkIGZvciBSU0EgT0FF UCB3aXRoIFNIQS0xPw0KDQpNeSBhbnN3ZXIgdG8gUTIgaXMgTk8uIFRoZSAiUlNBLU9BRVAiIGxh YmVsIGlzIGluY29uc2lzdGVudCB3aXRoIG90aGVyIEpPU0UgYWxnIG5hbWVzLiBKV0Egc3BlY2lm aWVzICJIUzUxMiIsICJSUzUxMiIsICJFUzUxMiIsIGFuZCAiQ1M1MTIiIHdoZXJlIHRoZSBTeHh4 IHN1ZmZpeCBpbmRpY2F0ZXMgYSBoYXNoIGFsZ29yaXRobS4gUlNBIE9BRVAgd2l0aCBTSEEtMSBj b3VsZCB1c2UgIlJPUzEiIG9yICJST1MxNjAiLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YNCj4gS2FyZW4gTydE b25vZ2h1ZQ0KPiBTZW50OiBUaHVyc2RheSwgMzAgQXVndXN0IDIwMTIgNzozMCBBTQ0KPiBUbzog am9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogW2pvc2VdIChS RURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQgcGFyYW1ldGVycw0KPg0KPiBGb2xr cywNCj4NCj4gR2l2ZW4gdGhlIGNvbmZ1c2lvbiBhcm91bmQgdGhlIG9yaWdpbmFsIHZlcnNpb24g b2YgdGhpcyBwb2xsLCBJJ2QgbGlrZQ0KPiB0byB0cnkgYWdhaW4uDQo+DQo+IFRoZSBiYXNpYyBx dWVzdGlvbiBpcyB1bmNoYW5nZWQsIHRoZSByb29tIGNvdW50IGZyb20gVmFuY291dmVyIGhhcyBi ZWVuDQo+IGNvcnJlY3RlZCwgYW5kIGEgY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgdGhlIHN0YXR1 cyBvZiBTSEExIGluIHRoZSBPQUVQDQo+IHNwZWNpZmljYXRpb24gaGFzIGJlZW4gYWRkZWQuICBG b3IgdGhvc2Ugb2YgeW91IHdobyB2b3RlZCBhbmQgZmVlbCB5b3UNCj4gbWF5IGhhdmUgbWlzdW5k ZXJzdG9vZCB0aGUgcXVlc3Rpb24gb3Igdm90ZWQgaW5jb3JyZWN0bHksIHBsZWFzZSBmZWVsDQo+ IGZyZWUgdG8gdXBkYXRlIHlvdXIgYW5zd2VyLg0KPg0KPiBRdWVzdGlvbjoNCj4gU2hvdWxkIFNI QTEgKGFuZCBtZ2YxU0hBMSkgYmUgdGhlIGRlZmF1bHQgcGFyYW1ldGVycyBmb3IgdGhlc2UNCj4g YWxnb3JpdGhtcz8NCj4gTm90ZTogIFRoZXNlIGFyZSB0aGUgZGVmYXVsdCBwYXJhbWV0ZXJzIHNw ZWNpZmllZCBpbiBSRkMgMzQ0NywgU2VjdGlvbg0KPiBBLjIuMSwgYW5kIGFyZSB3aWRlbHkgZGVw bG95ZWQuDQo+DQo+IFJvb20gdm90ZTogIDUgeWVzLCAwIG5vLCAzIGRpc2N1c3MNCj4NCj4gVGhh bmtzLA0KPiBLYXJlbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBqb3NlIG1haWxpbmcgbGlzdA0KPiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3Nl QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1h aWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KDQoNCg0KLS0NCi0tQnJlbm8NCg== --_000_4E1F6AAD24975D4BA5B1680429673943667AF0FATK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ U3VyZS4mbmJzcDsgcy9rZXkgc2l6ZS9zaXplL2cgaW4gbXkgZGVzY3JpcHRpb24gYmVsb3cuJm5i c3A7IFNvbWV0aW1lcyB0aGUgc2l6ZXMgYXJlIGZvciB0aGluZ3MgbGlrZSBoYXNoIGZ1bmN0aW9u IG91dHB1dCBzaXplLCByYXRoZXIgdGhhbiBrZXkgc2l6ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBN YW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDY6MTMgUE08YnI+ DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IGpvc2VAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAvUlNBLVBT UyBkZWZhdWx0IHBhcmFtZXRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZXJlIGlzIG5vIDM4NC1iaXQga2V5IGludm9sdmVkIGluIFJTMzg0IChSU0FT U0EtUEtDUzEtVjFfNSB3aXRoIFNIQS0zODQpLiBJdCBpbnZvbHZlcywgc2F5LCBhIDIwNDgtYml0 IFJTQSBrZXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4geW91IHNh eSDigJxrZXkgc2l6ZeKAnSBkbyB5b3UgYWN0dWFsbHkgbWVhbiDigJxpbXBvcnRhbnQgc2l6ZeKA nSwgaW5zdGVhZCBvZiDigJxzaXplIG9mIGEgY3J5cHRvIGtleeKAnT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcyB0aGUgaGFzaCBzaXplIGFuZCBoYXNoIGFsZ29y aXRobSBhcmUg4oCcbW9yZSBpbXBvcnRhbnTigJ0gaW4gYW4gUlNBIHNpZ25hdHVyZSB0aGFuIGlu IGFuIFJTQSBlbmNyeXB0aW9uIHBhZGRpbmcgc2NoZW1lLCB0aG91Z2ggdGhhdCBpcyBhIGZhaXJs eQ0KIHN1YnRsZSBoYWlyIHRvIGJlIHNwbGl0dGluZyB3aGVuIG5hbWluZyBKT1NFIGFsZ29yaXRo bXMuIFdlIHdvdWxkIG5lZWQgdG8gc3RvcCB0YWxraW5nIGFib3V0IOKAnGhhc2ggYWxnb3JpdGht c+KAnSBhbmQgc3RhcnQgdGFsa2luZyBhYm91dCwgc2F5LCDigJxjb2xsaXNpb24tcmVzaXN0YW50 IGhhc2ggYWxnb3JpdGhtc+KAnSBhbmQg4oCccHNldWRvcmFuZG9tIGZ1bmN0aW9uc+KAnSBpZiB3 ZSB3YW50IHRvIHNwbGl0IHRoYXQgaGFpci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0 Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnXSI+DQpbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ108 L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgMzAgQXVndXN0IDIwMTIgMTA6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hbmdlciwgSmFt ZXMgSDsgQnJlbm8gZGUgTWVkZWlyb3M8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpq b3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQgcGFyYW1ldGVyczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1BVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZXnigJlyZSBpbiB0aGUgZmlyc3QgY2F0ZWdvcnksIGluIHdoaWNoIGEga2V5IHNpemUgaXMg cmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGUgYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+DQo8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuZ2Vy LCBKYW1lcyBIPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDU6 MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IEJyZW5vIGRlIE1lZGVpcm9zPGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSAoUkVETykgUE9MTDogUlNBLU9BRVAv UlNBLVBTUyBkZWZhdWx0IHBhcmFtZXRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNvIHdoYXQgYWJvdXQgUlMyNTYsIFJTMzg0LCBhbmQgUlM1MTI/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t QVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t QVUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2Ug Sm9uZXMNCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bV0iPlttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXTwvYT4NCjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgMzAgQXVndXN0IDIwMTIgMTA6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+ IEJyZW5vIGRlIE1lZGVpcm9zOyBNYW5nZXIsIEphbWVzIEg8YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogW2pvc2VdIChSRURPKSBQT0xMOiBSU0EtT0FFUC9SU0EtUFNTIGRlZmF1bHQg cGFyYW1ldGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldoZXJlIGEga2V5IHNpemUgaXMgcmVxdWlyZWQgdG8gZnVsbHkgc3BlY2lm eSB0aGUgYWxnb3JpdGhtLCBpdOKAmXMgaW5jbHVkZWQgaW4gdGhlIG5hbWUuJm5ic3A7IEV4YW1w bGVzOiZuYnNwOyBIUzI1NiwgQTEyOEdDTS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2hlcmUgdGhlIHNpemUgaXNu4oCZdCByZXF1aXJlZCB0byBmdWxseSBzcGVjaWZ5IHRoZSBhbGdv cml0aG0sIGl0IGlzbuKAmXQuJm5ic3A7IEV4YW1wbGVzOiZuYnNwOyBSU0ExXzUsIFJTQS1PQUVQ LCBFQ1NILUVTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8gaW5jb25zaXN0ZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYu b3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmpv c2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyZW5vIGRlIE1l ZGVpcm9zPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDI5LCAyMDEyIDU6MDEg UE08YnI+DQo8Yj5Ubzo8L2I+IE1hbmdlciwgSmFtZXMgSDxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBw YXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25jdXIgd2l0aCB0aGUg YW5hbHlzaXMgdGhhdCAnUlNBLU9BRVAnIHRlcm1pbm9sb2d5IGFwcGVhcnMgaW5jb25zaXN0ZW50 IHdpdGggb3RoZXIgYWNyb255bSB1c2FnZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDI5LCAyMDEy IGF0IDQ6NTggUE0sIE1hbmdlciwgSmFtZXMgSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iIHRhcmdldD0iX2JsYW5rIj5KYW1lcy5ILk1hbmdlckB0 ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IFNob3Vs ZCBTSEExIChhbmQgbWdmMVNIQTEpIGJlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgZm9yIHRoZXNl PGJyPg0KJmd0OyBhbGdvcml0aG1zPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBkb27igJl0IGhhdmUgJnF1b3Q7YWxnb3JpdGhtIHBhcmFtZXRlcnMmcXVv dDsgaW4gSk9TRSDigJMgdGhhdCBpcyB0aGUgc3ViamVjdCBvZiBhIHNlcGFyYXRlIFBPTEwgKCZx dW90O1N1cHBvcnQgbXVsdGlwbGUgdHlwZXMgZm9yIGFsZ29yaXRobXMmcXVvdDspLiBKT1NFIGN1 cnJlbnRseSBoYXMgYWxnb3JpdGhtIGxhYmVscyB3aXRoIG5vIHBhcmFtZXRlcnMuPGJyPg0KPGJy Pg0KQ29uc2VxdWVudGx5IHRoaXMgcXVlc3Rpb24gaXMgcmVhbGx5IGFza2luZyBvbmUgb2YgdGhl IGZvbGxvd2luZzo8YnI+DQo8YnI+DQpRMS4gU2hvdWxkIFJTQSBPQUVQIHdpdGggU0hBLTEgYmUg ZGVmaW5lZCBmb3IgdXNlIHdpdGggSk9TRT8gUGVyaGFwcyBhZGRpdGlvbmFsbHksIHNob3VsZCBp dCBiZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50Pzxicj4NClRoZSBjb3JlIG9mIHRoaXMgcXVlc3Rp b24gaXMgd2hldGhlciBTSEEtMSBpcyBjcnlwdG9ncmFwaGljYWxseS1jb21wcm9taXNlZCBlbm91 Z2ggdGhhdCB3ZSBzaG91bGRuJ3QgdXNlIGl0IGluIG5ldyBjcnlwdG8gc3BlY3MsIG9yIGlzIGl0 cyB3aWRlc3ByZWFkLWF2YWlsYWJpbGl0eSBtb3JlIGltcG9ydGFudCB0aGFuIGFueSBjcnlwdG8g d2Vha25lc3M/PGJyPg0KPGJyPg0KUTIuIFNob3VsZCB0aGUgbGFiZWwgJnF1b3Q7UlNBLU9BRVAm cXVvdDsgYmUgdXNlZCBmb3IgUlNBIE9BRVAgd2l0aCBTSEEtMT88YnI+DQo8YnI+DQpNeSBhbnN3 ZXIgdG8gUTIgaXMgTk8uIFRoZSAmcXVvdDtSU0EtT0FFUCZxdW90OyBsYWJlbCBpcyBpbmNvbnNp c3RlbnQgd2l0aCBvdGhlciBKT1NFIGFsZyBuYW1lcy4gSldBIHNwZWNpZmllcyAmcXVvdDtIUzUx MiZxdW90OywgJnF1b3Q7UlM1MTImcXVvdDssICZxdW90O0VTNTEyJnF1b3Q7LCBhbmQgJnF1b3Q7 Q1M1MTImcXVvdDsgd2hlcmUgdGhlIFN4eHggc3VmZml4IGluZGljYXRlcyBhIGhhc2ggYWxnb3Jp dGhtLiBSU0EgT0FFUCB3aXRoIFNIQS0xIGNvdWxkIHVzZSAmcXVvdDtST1MxJnF1b3Q7IG9yICZx dW90O1JPUzE2MCZxdW90Oy48YnI+DQo8YnI+DQotLTxicj4NCkphbWVzIE1hbmdlcjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVm PSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBPbiBCZWhhbGYgT2Y8YnI+DQomZ3Q7IEthcmVuIE8nRG9ub2dodWU8YnI+DQomZ3Q7IFNlbnQ6 IFRodXJzZGF5LCAzMCBBdWd1c3QgMjAxMiA3OjMwIEFNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0i bWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0 OiBbam9zZV0gKFJFRE8pIFBPTEw6IFJTQS1PQUVQL1JTQS1QU1MgZGVmYXVsdCBwYXJhbWV0ZXJz PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsgRm9sa3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgR2l2ZW4gdGhlIGNv bmZ1c2lvbiBhcm91bmQgdGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgdGhpcyBwb2xsLCBJJ2QgbGlr ZTxicj4NCiZndDsgdG8gdHJ5IGFnYWluLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBiYXNpYyBx dWVzdGlvbiBpcyB1bmNoYW5nZWQsIHRoZSByb29tIGNvdW50IGZyb20gVmFuY291dmVyIGhhcyBi ZWVuPGJyPg0KJmd0OyBjb3JyZWN0ZWQsIGFuZCBhIGNsYXJpZmljYXRpb24gcmVnYXJkaW5nIHRo ZSBzdGF0dXMgb2YgU0hBMSBpbiB0aGUgT0FFUDxicj4NCiZndDsgc3BlY2lmaWNhdGlvbiBoYXMg YmVlbiBhZGRlZC4gJm5ic3A7Rm9yIHRob3NlIG9mIHlvdSB3aG8gdm90ZWQgYW5kIGZlZWwgeW91 PGJyPg0KJmd0OyBtYXkgaGF2ZSBtaXN1bmRlcnN0b29kIHRoZSBxdWVzdGlvbiBvciB2b3RlZCBp bmNvcnJlY3RseSwgcGxlYXNlIGZlZWw8YnI+DQomZ3Q7IGZyZWUgdG8gdXBkYXRlIHlvdXIgYW5z d2VyLjxicj4NCiZndDs8YnI+DQomZ3Q7IFF1ZXN0aW9uOjxicj4NCiZndDsgU2hvdWxkIFNIQTEg KGFuZCBtZ2YxU0hBMSkgYmUgdGhlIGRlZmF1bHQgcGFyYW1ldGVycyBmb3IgdGhlc2U8YnI+DQom Z3Q7IGFsZ29yaXRobXM/PGJyPg0KJmd0OyBOb3RlOiAmbmJzcDtUaGVzZSBhcmUgdGhlIGRlZmF1 bHQgcGFyYW1ldGVycyBzcGVjaWZpZWQgaW4gUkZDIDM0NDcsIFNlY3Rpb248YnI+DQomZ3Q7IEEu Mi4xLCBhbmQgYXJlIHdpZGVseSBkZXBsb3llZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSb29tIHZv dGU6ICZuYnNwOzUgeWVzLCAwIG5vLCAzIGRpc2N1c3M8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFu a3MsPGJyPg0KJmd0OyBLYXJlbjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGpvc2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9z ZTwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5v cmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+LS0gPGJyPg0KLS1CcmVubzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943667AF0FATK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Wed Aug 29 18:52:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64321E803F for ; Wed, 29 Aug 2012 18:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSr22xtNwamP for ; Wed, 29 Aug 2012 18:52:33 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4F11E8105 for ; Wed, 29 Aug 2012 18:52:32 -0700 (PDT) Received: from mail115-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 Aug 2012 01:52:30 +0000 Received: from mail115-db3 (localhost [127.0.0.1]) by mail115-db3-R.bigfish.com (Postfix) with ESMTP id AC50A2A0217; Thu, 30 Aug 2012 01:52:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zzbb2dI98dI9371Ic85fh542M1432I1418Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah107ah34h1155h) Received-SPF: pass (mail115-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3 (MessageSwitch) id 1346291546857454_13462; Thu, 30 Aug 2012 01:52:26 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.229]) by mail115-db3.bigfish.com (Postfix) with ESMTP id C42783E003F; Thu, 30 Aug 2012 01:52:26 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 Aug 2012 01:52:26 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.176]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 30 Aug 2012 01:52:21 +0000 From: Mike Jones To: Stephen Farrell , "Manger, James H" Thread-Topic: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters Thread-Index: AQHNhi1oMG2bBx4eNkynEaO7ZDjUypdxd/uAgAAB1YCAABj6cA== Date: Thu, 30 Aug 2012 01:52:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667AF161@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <503EAE27.9030409@cs.tcd.ie> In-Reply-To: <503EAE27.9030409@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/mixed; boundary="_002_4E1F6AAD24975D4BA5B1680429673943667AF161TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:52:37 -0000 --_002_4E1F6AAD24975D4BA5B1680429673943667AF161TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fair question. I believe that the working group has been trying to choose = algorithms that are commonly available and so can result in widely deployed= interoperable implementations. Implementability across common development= platforms is a core goal. The attached spreadsheet is part of the data ga= thered to help us choose which algorithms to include, and whether to make t= hem REQUIRED/RECOMMENDED/OPTIONAL. (I presented this in Vancouver, as you'= ll recall.) BouncyCastle is the one library I'm aware of that supports both SHA-256 bas= ed and SHA-1 based OAEP parameters. Windows native may as well. (I know t= hat .NET doesn't.) I don't know about Ruby, Python, PHP, Java without Boun= cyCastle, Mac OS, Android, iOS, Windows Phone, node.js, RedHat, SUSE, Chrom= eOS, etc. If the working group is interested, we could certainly do the in= vestigation. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ste= phen Farrell Sent: Wednesday, August 29, 2012 5:05 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters On 08/30/2012 12:58 AM, Manger, James H wrote: > Consequently this question is really asking one of the following: >=20 > Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps addi= tionally, should it be mandatory to implement? > The core of this question is whether SHA-1 is cryptographically-compromis= ed enough that we shouldn't use it in new crypto specs, or is its widesprea= d-availability more important than any crypto weakness? Just on this part. DKIM and DANE both decided to go with to sha256 as the mandatory to implement digest alg. I think that is a trend. I don't see why JOSE would be different in that respect. If JOSE do choose = to stand out from the crowd and go with sha1 then I think you'll need to ju= stify that explicitly and convincingly. S. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_002_4E1F6AAD24975D4BA5B1680429673943667AF161TK5EX14MBXC284r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=18750; creation-date="Thu, 19 Jul 2012 17:04:00 GMT"; modification-date="Sat, 28 Jul 2012 02:24:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_002_4E1F6AAD24975D4BA5B1680429673943667AF161TK5EX14MBXC284r_-- From breno@google.com Thu Aug 30 13:31:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E518921F8598 for ; Thu, 30 Aug 2012 13:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPQA2y78I0-Z for ; Thu, 30 Aug 2012 13:31:13 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 372A221F8510 for ; Thu, 30 Aug 2012 13:31:13 -0700 (PDT) Received: by qadz3 with SMTP id z3so521117qad.10 for ; Thu, 30 Aug 2012 13:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=F/P1dGywHtpZGYs4USwvKFD0nPQqIHFbV9IceTenrhs=; b=OWH2WdEsLl6FNrnZ7u8SQPULY1koWHh07N5p9aGDxDrZu6vQwoiQSPyagvySqjvzJh 5NZT7JllqIrl94DAp87hh9dP3k6expTNuNVaZp+KITHp63j4ENSLrYz0W9kbiScAyg6R fJ0G+NtNekD+zDfVgfX3COxtRBxlyOEED5yUAENWeCdrAdaEAEHQ0B1cTYQ0q3/0hL+M VdE/Fqxd8vMyAvaX4+N6MEsn0DGZq/EhucYOJ5h7vFeRO5+14q+qpK64qRVVSGSxhjQJ sajLSuHf+lkTsXDyTBm1vgEOAJDoYFx2WgC7e6xboh1NMjtUei1WVIBq72bger2R6F9/ GGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=F/P1dGywHtpZGYs4USwvKFD0nPQqIHFbV9IceTenrhs=; b=Ynd0MPF3iMX3IukVZxtOyTe+6Kd4WPQrfpDu65Dq5gIpxSKuhiMEZgkOpYS7Cgvk4c D50aibufd22ow268pbR7o6EpKDILO3ZdbV2Jsoe/3Lm1ezTDnbGyOagaXwudpFWF+yfH +ssXdATLzyQHodT/+9AK6MuM2e/un7U7pgDSQ1YzcF5U/9h3tPMNskplSiBUDVAprdaG 1CJqRqC/krxcwZqHLtv8OMv65ptSGAtdWutYUtdRLCiI+TC6x7fN+VKlKPvQL5F9iNsC ErxGB1vyY4VrAXZg4zUDRHMhtbr6IQyva6lM0Rt0SMfJtBAPMSESsGsEqQcD/IMXoO73 Z77g== Received: by 10.224.202.71 with SMTP id fd7mr13608623qab.50.1346358672568; Thu, 30 Aug 2012 13:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.202.71 with SMTP id fd7mr13608605qab.50.1346358672378; Thu, 30 Aug 2012 13:31:12 -0700 (PDT) Received: by 10.229.52.144 with HTTP; Thu, 30 Aug 2012 13:31:11 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667AF0FA@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <503E89C1.2030409@isoc.org> <255B9BB34FB7D647A506DC292726F6E114FC6C4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEEF3@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FC6C4501@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AEF8B@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FC6C4739@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667AF0FA@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 30 Aug 2012 13:31:11 -0700 Message-ID: From: Breno de Medeiros To: Mike Jones Content-Type: multipart/alternative; boundary=20cf300fae59684a5a04c8818e67 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlZh+7RUQzp/MW10JRG+hnS6vJP2fjhAfT4uhP/T7PqVcvc+WmJQi3TQ2Orp3OvPFpi7ux9B/URndunO5KJjINZNrdrF4ojHTtNzGG/vmrXR5/FzZ8ouzQAb2Ubv0VMPKO65pC6Lp6fnp1x5HFeYMUPKDYGhryNzxP/avxB2r4Kq+LS4U7V3dJkkM5j7Eqc/6JdCPcN Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 20:31:15 -0000 --20cf300fae59684a5a04c8818e67 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right. The point here is that the RSA-OAEP standard itself allows for parametrization of the hash function output size. While the vast majority of current implementations use SHA-1, the standard itself allows for arbitrary hash function specification. See ftp://ftp.rsasecurity.com/pub/rsalabs/rsa_algorithm/rsa-oaep_spec.pdf, section 1.3, paragraph 5. On Wed, Aug 29, 2012 at 6:33 PM, Mike Jones wr= ote: > Sure. s/key size/size/g in my description below. Sometimes the sizes > are for things like hash function output size, rather than key size.**** > > ** ** > > *From:* Manger, James H [mailto:James.H.Manger@team.telstra.com] > *Sent:* Wednesday, August 29, 2012 6:13 PM > *To:* Mike Jones > > *Cc:* jose@ietf.org > *Subject:* RE: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters***= * > > ** ** > > There is no 384-bit key involved in RS384 (RSASSA-PKCS1-V1_5 with > SHA-384). It involves, say, a 2048-bit RSA key.**** > > ** ** > > When you say =93key size=94 do you actually mean =93important size=94, in= stead of > =93size of a crypto key=94?**** > > ** ** > > Perhaps the hash size and hash algorithm are =93more important=94 in an R= SA > signature than in an RSA encryption padding scheme, though that is a fair= ly > subtle hair to be splitting when naming JOSE algorithms. We would need to > stop talking about =93hash algorithms=94 and start talking about, say, > =93collision-resistant hash algorithms=94 and =93pseudorandom functions= =94 if we > want to split that hair.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Thursday, 30 August 2012 10:32 AM > *To:* Manger, James H; Breno de Medeiros > *Cc:* jose@ietf.org > *Subject:* Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters***= * > > ** ** > > They=92re in the first category, in which a key size is required to fully > specify the algorithm.**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] > *On Behalf Of *Manger, James H > *Sent:* Wednesday, August 29, 2012 5:11 PM > *To:* Mike Jones; Breno de Medeiros > *Cc:* jose@ietf.org > *Subject:* Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters***= * > > ** ** > > So what about RS256, RS384, and RS512?**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Thursday, 30 August 2012 10:07 AM > *To:* Breno de Medeiros; Manger, James H > *Cc:* jose@ietf.org > *Subject:* RE: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters***= * > > ** ** > > Where a key size is required to fully specify the algorithm, it=92s inclu= ded > in the name. Examples: HS256, A128GCM.**** > > Where the size isn=92t required to fully specify the algorithm, it isn=92= t. > Examples: RSA1_5, RSA-OAEP, ECSH-ES.**** > > ** ** > > No inconsistency.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] > *On Behalf Of *Breno de Medeiros > *Sent:* Wednesday, August 29, 2012 5:01 PM > *To:* Manger, James H > *Cc:* jose@ietf.org > *Subject:* Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters***= * > > ** ** > > Concur with the analysis that 'RSA-OAEP' terminology appears inconsistent > with other acronym usage.**** > > ** ** > > On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > > Should SHA1 (and mgf1SHA1) be the default parameters for these > > algorithms?**** > > We don=92t have "algorithm parameters" in JOSE =96 that is the subject of= a > separate POLL ("Support multiple types for algorithms"). JOSE currently h= as > algorithm labels with no parameters. > > Consequently this question is really asking one of the following: > > Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps > additionally, should it be mandatory to implement? > The core of this question is whether SHA-1 is > cryptographically-compromised enough that we shouldn't use it in new cryp= to > specs, or is its widespread-availability more important than any crypto > weakness? > > Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1? > > My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with other > JOSE alg names. JWA specifies "HS512", "RS512", "ES512", and "CS512" wher= e > the Sxxx suffix indicates a hash algorithm. RSA OAEP with SHA-1 could use > "ROS1" or "ROS160". > > -- > James Manger**** > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Karen O'Donoghue > > Sent: Thursday, 30 August 2012 7:30 AM > > To: jose@ietf.org > > Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters > >**** > > > Folks, > > > > Given the confusion around the original version of this poll, I'd like > > to try again. > > > > The basic question is unchanged, the room count from Vancouver has been > > corrected, and a clarification regarding the status of SHA1 in the OAEP > > specification has been added. For those of you who voted and feel you > > may have misunderstood the question or voted incorrectly, please feel > > free to update your answer. > > > > Question: > > Should SHA1 (and mgf1SHA1) be the default parameters for these > > algorithms? > > Note: These are the default parameters specified in RFC 3447, Section > > A.2.1, and are widely deployed. > > > > Room vote: 5 yes, 0 no, 3 discuss > > > > Thanks, > > Karen > > _______________________________________________ > > 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**** > > > > **** > > ** ** > > -- > --Breno**** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 --Breno --20cf300fae59684a5a04c8818e67 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Right. The point here is that the RSA-OAEP standard itself allows for param= etrization of the hash function output size. While the vast majority of cur= rent implementations use SHA-1, the standard itself allows for arbitrary ha= sh function specification. See=A0ftp://ftp.rsasecurity.com/pub/rsala= bs/rsa_algorithm/rsa-oaep_spec.pdf, section 1.3, paragraph 5.


On Wed, Aug 29, 2012 at 6:33 PM, Mike Jo= nes <Michael.Jones@microsoft.com> wrote:

Sure.=A0 s/key size/size/= g in my description below.=A0 Sometimes the sizes are for things like hash = function output size, rather than key size.

=A0<= /p>

From: Manger, = James H [mailto:James.H.Manger@team.telstra.com]
Sent: Wednesday, August 29, 2012 6:13 PM
To: Mike Jones


Cc: jose@ietf.org=
Subject: RE: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters=

=A0

There is n= o 384-bit key involved in RS384 (RSASSA-PKCS1-V1_5 with SHA-384). It involv= es, say, a 2048-bit RSA key.

=A0=

When you s= ay =93key size=94 do you actually mean =93important size=94, instead of =93= size of a crypto key=94?

=A0=

Perhaps th= e hash size and hash algorithm are =93more important=94 in an RSA signature= than in an RSA encryption padding scheme, though that is a fairly subtle hair to be splitting when naming JOSE algorithms. We would need to = stop talking about =93hash algorithms=94 and start talking about, say, =93c= ollision-resistant hash algorithms=94 and =93pseudorandom functions=94 if w= e want to split that hair.

=A0=

--<= u>

James Mang= er

=A0=

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, 30 August 2012 10:32 AM
To: Manger, James H; Breno de Medeiros
Cc: jose@ietf.org=
Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters=

=A0

They=92re in the first ca= tegory, in which a key size is required to fully specify the algorithm.<= /u>

=A0<= /p>

From: jose-bounces@iet= f.org [mailt= o:jose-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Wednesday, August 29, 2012 5:11 PM
To: Mike Jones; Breno de Medeiros
Cc: jose@ietf.org=
Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters=

=A0

So what ab= out RS256, RS384, and RS512?

=A0=

--<= u>

James Mang= er

=A0=

From: Mike Jon= es [= mailto:Michael.Jones@microsoft.com]
Sent: Thursday, 30 August 2012 10:07 AM
To: Breno de Medeiros; Manger, James H
Cc: jose@ietf.org=
Subject: RE: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters=

=A0

Where a key size is requi= red to fully specify the algorithm, it=92s included in the name.=A0 Example= s:=A0 HS256, A128GCM.

Where the size isn=92t re= quired to fully specify the algorithm, it isn=92t.=A0 Examples:=A0 RSA1_5, = RSA-OAEP, ECSH-ES.

=A0<= /p>

No inconsistency.<= u>

=A0<= /p>

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

=A0<= /p>

From: jose-bounces@iet= f.org [mailt= o:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros
Sent: Wednesday, August 29, 2012 5:01 PM
To: Manger, James H
Cc: jose@ietf.org=
Subject: Re: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters=

=A0

Concur with the analysis that 'RSA-OAEP' ter= minology appears inconsistent with other acronym usage.

=A0

On Wed, Aug 29, 2012 at 4:58 PM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:

> Should SHA1 (and= mgf1SHA1) be the default parameters for these
> algorithms?

We don=92t have "algorithm parameters" in = JOSE =96 that is the subject of a separate POLL ("Support multiple typ= es for algorithms"). JOSE currently has algorithm labels with no param= eters.

Consequently this question is really asking one of the following:

Q1. Should RSA OAEP with SHA-1 be defined for use with JOSE? Perhaps additi= onally, should it be mandatory to implement?
The core of this question is whether SHA-1 is cryptographically-compromised= enough that we shouldn't use it in new crypto specs, or is its widespr= ead-availability more important than any crypto weakness?

Q2. Should the label "RSA-OAEP" be used for RSA OAEP with SHA-1?<= br>
My answer to Q2 is NO. The "RSA-OAEP" label is inconsistent with = other JOSE alg names. JWA specifies "HS512", "RS512", &= quot;ES512", and "CS512" where the Sxxx suffix indicates a h= ash algorithm. RSA OAEP with SHA-1 could use "ROS1" or "ROS1= 60".

--
James Manger


> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Karen O'Donoghue
> Sent: Thursday, 30 August 2012 7:30 AM
> To: jose@ietf.org
> Subject: [jose] (REDO) POLL: RSA-OAEP/RSA-PSS default parameters
>

> Folks,
>
> Given the confusion around the original version of this poll, I'd = like
> to try again.
>
> The basic question is unchanged, the room count from Vancouver has bee= n
> corrected, and a clarification regarding the status of SHA1 in the OAE= P
> specification has been added. =A0For those of you who voted and feel y= ou
> may have misunderstood the question or voted incorrectly, please feel<= br> > free to update your answer.
>
> Question:
> Should SHA1 (and mgf1SHA1) be the default parameters for these
> algorithms?
> Note: =A0These are the default parameters specified in RFC 3447, Secti= on
> A.2.1, and are widely deployed.
>
> Room vote: =A05 yes, 0 no, 3 discuss
>
> Thanks,
> Karen
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
--Breno


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




--
--Breno<= br>
--20cf300fae59684a5a04c8818e67-- From ritou.06@gmail.com Fri Aug 31 21:08:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7741D21F84B5 for ; Fri, 31 Aug 2012 21:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooaf6ZsFOUi0 for ; Fri, 31 Aug 2012 21:08:40 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B12A21F846B for ; Fri, 31 Aug 2012 21:08:40 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1845761wgb.13 for ; Fri, 31 Aug 2012 21:08:39 -0700 (PDT) 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=rOCNgAQHlYKP3rDrdV6OcXe4vNHtEO4UJVUKyYDSiM4=; b=J+2IFM+XiWZN8PifCV/XYRPnK0/2w8ZESbe2vNBS3VAZ/O1i1uNjxHuDLzoWt1Fdji JDb7PSMaueOKjqMCex8vuqZZGi+oMVdbcO+rrZjU531bvSvNOVNMWD7NuVIewzKyhw3H zWG10uoWyODdaddfluSG/1q56kBbdYX9qPvl98KXk02Pn42xdYefDnx8gE1ulGRVbFDO 7ysQCZcYdc5qOo5qFRBCbt2GOm/9MiPYbyLCuGAfuvCJwzBFyDtdRWT6ECl2oJIIdnXU wZa+hmV6pSiV/izWuvjXxHf7dPGW9kSNkN+3O1Z2ceOcPBpQD2D2B2HQnk0aOJtoC2zJ qNDw== MIME-Version: 1.0 Received: by 10.216.236.38 with SMTP id v38mr6332708weq.222.1346472519537; Fri, 31 Aug 2012 21:08:39 -0700 (PDT) Received: by 10.216.216.82 with HTTP; Fri, 31 Aug 2012 21:08:39 -0700 (PDT) Date: Sat, 1 Sep 2012 13:08:39 +0900 Message-ID: From: Ryo Ito To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Is KID sufficently defined X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 04:08:41 -0000 YES > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Is the current text for KID sufficiently defined and understood? > > > Room vote: 2 yes, 0 no, 1 discuss -- ==================== Ryo Ito Email : ritou.06@gmail.com ==================== From ritou.06@gmail.com Fri Aug 31 21:10:16 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64C021F84B5 for ; Fri, 31 Aug 2012 21:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJENWzDeBn2X for ; Fri, 31 Aug 2012 21:10:16 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35B1421F84B2 for ; Fri, 31 Aug 2012 21:10:16 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1846087wgb.13 for ; Fri, 31 Aug 2012 21:10:15 -0700 (PDT) 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=FghvwcuXiIPddGOnWjQwyNIQVrQmgHpw9ca1N+/TVus=; b=iQIEFr8Dwl6c+MdyZGWTjiR/WCUz+7dnMCgoj01oPdbUasxhmmE8WLrf8MQjtbIXsh rKHj5KBjUgH2CUj2lalBkPXv6wOEr+MUI9SU6w+FR7FHL3mqKGJ6NpY8mHIVyFQhx2Dh rFcH20qJt5kHPw5L9nc3Nl7xKdJeX/U1u2ZcpR18R5cm7b5OXSacMp66shp0mjfsqjR4 lbHx9uxl6acCHZM2m4aX8Gtmjjn6qROBitlj63PDtYrYAZZhKV6fHZ4rFO9pDAeQIaBW n9eJkxrahNYNFv37JTLfyIur+pdLlo9Q8fr3sRFfhx47HDp2LgQrIebJ/PAamXeWTb9r 1I9g== MIME-Version: 1.0 Received: by 10.216.49.6 with SMTP id w6mr6057536web.207.1346472615407; Fri, 31 Aug 2012 21:10:15 -0700 (PDT) Received: by 10.216.216.82 with HTTP; Fri, 31 Aug 2012 21:10:15 -0700 (PDT) Date: Sat, 1 Sep 2012 13:10:15 +0900 Message-ID: From: Ryo Ito To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Criticality of understanding header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 04:10:17 -0000 YES > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > What should be the criticality of header fields as defined by the core > specification? > > YES - all headers fields are critical > NO - all header fields are non-critical > MAYBE - header fields are marked critical or criticality should be defined > by the application > DISCUSS - need to talk more > > Room vote: 2 yes, 0 no, 4 maybe, 3 discuss -- ==================== Ryo Ito Email : ritou.06@gmail.com ==================== From ritou.06@gmail.com Fri Aug 31 21:11:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDFD21F84D6 for ; Fri, 31 Aug 2012 21:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXQZkzTLXKFM for ; Fri, 31 Aug 2012 21:11:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B02F121F84CD for ; Fri, 31 Aug 2012 21:11:40 -0700 (PDT) Received: by weyu54 with SMTP id u54so2156831wey.31 for ; Fri, 31 Aug 2012 21:11:39 -0700 (PDT) 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=tyymnabP0PlOnKdTtenZJzlV8HZhN3htF1cRKvQp7l4=; b=fQez54wqPTgTmvFxut127JB55rBCvU5SLRad64/x8gnzIXcx//XL7woewJjiSQGZl1 4QpJy2I7xnjHRk6FJ1S7w944yJjgTsHasYAnfBhdW/LRKLjkulgxBdmaaZw1aX+WRvR6 YEILbob/Y9ucL8thzAN9prEaBsx9Em53Zi0Seryc6kIXaV9+7mlJGWIYpnCCdSbhcOHa HTTvT48xXxoECGbveSN9ZWsBBaYdKk6DjxRyrrM37CB9LP8669HxDSb+iBdhbev9nM3J I042dzX1zaysIxzasSQEWLGo7qZorq7rS/QwSP9rTAqddDyO1r128m6ihPEk1fp3woNc RHvw== MIME-Version: 1.0 Received: by 10.180.14.8 with SMTP id l8mr8864015wic.6.1346472699721; Fri, 31 Aug 2012 21:11:39 -0700 (PDT) Received: by 10.216.216.82 with HTTP; Fri, 31 Aug 2012 21:11:39 -0700 (PDT) Date: Sat, 1 Sep 2012 13:11:39 +0900 Message-ID: From: Ryo Ito To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Support Multiple types for algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 04:11:41 -0000 NO > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should support be mandated to allow an algorithm to be both a string and an > object > > Example: "alg":{"name":"EC-DH-SS", "random":"XXXXX", "KDF":"CS256", > "kid":"12345"} > > > Room vote: 1 yes, 5 no, 4 discuss -- ==================== Ryo Ito Email : ritou.06@gmail.com ==================== From ritou.06@gmail.com Fri Aug 31 21:12:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4521F84AF for ; Fri, 31 Aug 2012 21:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iiXcxxHsdlf for ; Fri, 31 Aug 2012 21:12:55 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 383FF21F84AE for ; Fri, 31 Aug 2012 21:12:55 -0700 (PDT) Received: by weyu54 with SMTP id u54so2157125wey.31 for ; Fri, 31 Aug 2012 21:12:54 -0700 (PDT) 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=pnUyHYQpACXTeGOJHqWYLvxUMclePp8KwIYp4R+Guao=; b=tzPUL1L7esooifv+vKyAWm3xhz+FONs8uvXakNfVwbPmBxf6HZH7OofbmMVIHAhTNh vzDvE2+SMCyRurKTNFowLVb+WGhsH+SQUHoz+zP8JTHOG5AbPKc+qwnGX1lcKZqHp8mX rZI4TucSztTzkJACA7DFFV+9vLvv3gBQVMsh/q7/p71/miaIVce0Il1ZnfojERGxE/O0 MJXZ30Nm+9h8KFPJTf99yTbU6BQZy0GpUnMOKO2FL8g9mm/0LiJu+5hySPGqvHk4nfHT EDLt2ruVD9biJa6GZkCPO95CsLDXMHk9S1hOLZizDL7hulKiZhTYGaTJxTYkOPPnVMf8 atdg== MIME-Version: 1.0 Received: by 10.180.74.133 with SMTP id t5mr8900254wiv.2.1346472774314; Fri, 31 Aug 2012 21:12:54 -0700 (PDT) Received: by 10.216.216.82 with HTTP; Fri, 31 Aug 2012 21:12:54 -0700 (PDT) Date: Sat, 1 Sep 2012 13:12:54 +0900 Message-ID: From: Ryo Ito To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Add other than pre-shared MAC key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 04:12:56 -0000 NO > > > If you voted at the face-2-face please do not vote again. If you want to > provide comments please change the title from POLL to DISCUSS. > > Should we add the ability to have a randomly generated MAC key protected by > a different key? The other key could be either a pre-shared symmetric key > or a public key. > > > > Room vote: 3 yes, 5 no, 3 discuss -- ==================== Ryo Ito Email : ritou.06@gmail.com ==================== From ritou.06@gmail.com Fri Aug 31 21:15:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5B21F84C5 for ; Fri, 31 Aug 2012 21:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIMW8NnnqxcY for ; Fri, 31 Aug 2012 21:15:10 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47A3021F84AF for ; Fri, 31 Aug 2012 21:15:10 -0700 (PDT) Received: by wicr5 with SMTP id r5so1784650wic.13 for ; Fri, 31 Aug 2012 21:15:09 -0700 (PDT) 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=UadOxHbyRUALB9jBRRS5jJKgVkp4HjqGOW99XSHT5rU=; b=ixtXCE7rkahzuJ5LXefnp0CS2ifXGL8g2Yy+AiKFM0U1X98OlstNO37QWaSOzECEKJ poSIxeKpkoJ8UPpdfD19goszlt6zcIHzX22RSUq11WAgU26H0nG/FIg1JptgYV0sS0o4 ZFhyIO63KKoQu0V0mwzNueopfnCed61MLvbq+5sfqkuaFnfZMipS+Gl/M1evU9Ufa87x H5IShkH3vZRAtUd1Jv+vTuwZQkeAvqP5+WMoQHYxNNbnZiZq0eJZwT4h4hIEzY7FNktL P4zeMA0x679+6Y40wdM9+EcmaKCUNDsMioosuRtpGmlsuws/YPsEkYEz8M/ZLQ5ulFf2 j+8w== MIME-Version: 1.0 Received: by 10.216.236.38 with SMTP id v38mr6340710weq.222.1346472909399; Fri, 31 Aug 2012 21:15:09 -0700 (PDT) Received: by 10.216.216.82 with HTTP; Fri, 31 Aug 2012 21:15:09 -0700 (PDT) Date: Sat, 1 Sep 2012 13:15:09 +0900 Message-ID: From: Ryo Ito To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [jose] POLL: Non AEAD algorithms as a single name X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 04:15:11 -0000 YES > > > If you voted at the face-2-face please do not vote again. If you want > to > provide comments please change the title from POLL to DISCUSS. > > Should we change the current treatment of AES-CBC + HMAC to use a > single > content encryption name. > > Old: {"enc":"A128CBC", "int":HS256", "kdf":"CS256"} > New: {"enc":"AES128CBC+HS256+CS256"} > > Exact name is still to be determined > > Room vote: 12 yes, 2 no, 0 discuss -- ==================== Ryo Ito Email : ritou.06@gmail.com ====================