From nobody Tue May 5 13:05:59 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1AB1B307F for ; Tue, 5 May 2015 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHPDV4Qgpuq for ; Tue, 5 May 2015 13:05:53 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193141B3082 for ; Tue, 5 May 2015 13:05:47 -0700 (PDT) Received: from Philemon (c-24-20-67-136.hsd1.or.comcast.net [24.20.67.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9DBE038F3A for ; Tue, 5 May 2015 13:05:46 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 5 May 2015 13:04:24 -0700 Message-ID: <018f01d0876e$af7224b0$0e566e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdCHbqAlTBZdZEGzTKabFWyl5oyS3g== Archived-At: Subject: [Cose] Any one alive? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:05:55 -0000 I sent out a number of messages on Thursday and have gotten no input. Please look at them and respond. Jim From nobody Tue May 5 23:56:14 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BED1A7D80 for ; Tue, 5 May 2015 23:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvV2aNdh29DF for ; Tue, 5 May 2015 23:56:10 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28EF1A86E1 for ; Tue, 5 May 2015 23:56:09 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so597138lbb.3 for ; Tue, 05 May 2015 23:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=2i1hmZZHJgAlhBAOUtPsyDRvB+PGy7TELB6bFT5LPwg=; b=TbRHlYhWVThB6xUCL0CIKuTrEi6sVnCOgx+mBN57BUyH4LYQnTasysFBx0IB6jYReC LI7WL/zCIyIYJEby4fJMeMt2HDBIevGNXNtlB3Unkw2D0wCnU6xEwEfWAWT36lX0rLLV c/qAex2O4kJjAQel6rAe/Twk8lUUVC5zo/OGB7/p3eba7SVRpRrtsmxX3yMoZRAhi7PX KyDcSdTLUjKNtFwAUVtaez2732J9gbZtEZdVaYq/LuiOWbP0XFZWGj/QbIg2C+/MNjlk ksSKGK+5GFpI689psQs8bHYyQnd64eWEQPHUbhGR71XQ+K5SqczKbiJ648UDuUyk2pDf O3IQ== X-Gm-Message-State: ALoCoQnJz4D8yDr2h7RNbNkmNQp5grHlgHKAJKTLgxykE7e3pkT4/W6hYJPt9ghxHLrhc13bQ4SW X-Received: by 10.152.243.9 with SMTP id wu9mr26807098lac.63.1430895368431; Tue, 05 May 2015 23:56:08 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by mx.google.com with ESMTPSA id lu12sm159239lac.49.2015.05.05.23.56.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 23:56:07 -0700 (PDT) Message-ID: <5549BAFF.6020408@sics.se> Date: Wed, 06 May 2015 08:55:59 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: cose@ietf.org References: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> In-Reply-To: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000202040605020406000306" Archived-At: Subject: Re: [Cose] Key management in the World of COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 06:56:12 -0000 This is a cryptographically signed message in MIME format. --------------ms000202040605020406000306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 05/01/2015 12:57 AM, Jim Schaad wrote: > I wanted to try and look closer at Carsten's call for more numbers in > different applications, but before I can do that I need to figure out w= hat > applications there are and which ones are currently thought to be of gr= eater > importance. I have tried to start by looking at the different security= > constructs that may be used for these applications in terms of what the= > needed security characteristics are. [...] > 3. Integrity and low-level origination based on a long term shared key= : [...] > > 8. Confidentiality, integrity and low-level origination based on a long= term > Which of these ten scenarios do we believe are going to be commonly use= d? > What percentage of the time do we think these options are going to be u= sed? > This will give us some starting data to look at which structures are go= ing > to be the most commonly used and get a start on which fields in the > structures are going to be present. There will be some follow on quest= ions > to try and make this determination. I'm only conjecturing (which is why I kept quiet initially) but since=20 our common experience is that people tend to be lazy when it comes to=20 security, I would guess that these will be the most commonly used cases. Why do I think so? Because these cases seem to be the most easy to=20 configure and administrate, so that's what the majority is going to use. Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms000202040605020406000306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA1MDYwNjU1NTlaMCMGCSqGSIb3DQEJBDEW BBTu5ylFiWQzawzuumZVXQN1qSEIqTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAtYUJBEJD8elY3GGiS4SgP6flA0gg7g05GES4hGspVXqwLh2s+JG3+TP5rEBZQZwE/O+e g78MsOp02ssZ2e/CR8uuUbRzJ+lHulp/kPkDZugk1jTCDo8HoNFpOMPIBe0Ngl6DGsf2GTMy QxyzAlExm/gXLaE5CCnfDs2pOGrqiZiU2dER1qHgDSBUiFii3uMjbLjW3kM2hgnEMNK5bIiB ookYEGAa3BSI+eLbb5A2rDM8I6kxJwdscBUh4+LspsEyPv1wqfGnJHERXjlbcEdAJed8NTj8 XeKB3Pe9S1fLBcifjdF2QK7LDX+deLTdSBjOPCbZN7nWuJJ87+jqvH5YHAAAAAAAAA== --------------ms000202040605020406000306-- From nobody Wed May 6 00:02:32 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9827A1A86E8 for ; Wed, 6 May 2015 00:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4BTHktF7gES for ; Wed, 6 May 2015 00:02:30 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56DB1A7028 for ; Wed, 6 May 2015 00:02:29 -0700 (PDT) Received: by laat2 with SMTP id t2so705229laa.1 for ; Wed, 06 May 2015 00:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=UbRHh8UOjctmvZ977a/jpfZhE8cQ2CWv1IOYi7udre4=; b=NBz+CLwu8fhr9aF9LEz1mn8Ozfmpm5aWC2jsA7OWKPRNGQiQvc8Lab/ohwBtnCxwIL Zgr9FSCY2GZBYEtTrvP/0k646BbsVFWf9gLC9Mci3FCK7Fsj6pOuhmdcOTYYDcbNt/qv v6EmH2W1dymQ5hRKgWkxDzPcUBjer0X4/xIBN7MyjNAHd4FBQ8Pk8eSP2QJ8C/6q5dxE AtPRFjh7q9NpOGIY4HoG0+86+SdFAui9TD2ExDlmXtvrejvNSuKtDapkJcQpL38uAsUb FvLVASXq4RRe/MchmyIwtfVz0EJKUzJrFdzcok8Ht8bm5NzM483h8KmeUa/zb/SbsaVv 27Fg== X-Gm-Message-State: ALoCoQmnOFQWxUftq6Bc4k/rNBStamnbjhtBsHjRoN0mHXgtYJeaIIVgqYNrzoAjay5n8hiO1/yI X-Received: by 10.153.7.133 with SMTP id dc5mr2383007lad.17.1430895748233; Wed, 06 May 2015 00:02:28 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by mx.google.com with ESMTPSA id u10sm166790lbb.30.2015.05.06.00.02.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 00:02:27 -0700 (PDT) Message-ID: <5549BC81.1050808@sics.se> Date: Wed, 06 May 2015 09:02:25 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: cose@ietf.org References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> In-Reply-To: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090803050600090008090407" Archived-At: Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 07:02:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090803050600090008090407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 05/01/2015 12:58 AM, Jim Schaad wrote: > Question: Identification of objects: > a) CBOR Tag - either general or specific to each type > b) Required Identifier > c) Use the same techniques as JOSE > > Discussion: > > One of the things that I have never liked with the JOSE document is the= > method that is used to determine the type of object that one is dealing= > with. I would lie to get this corrected so that it is simple to make = this > determination. Why was it done this way in JOSE in the first place? A CBOR tag sounds neat, can the CBOR experts tell us if there are any=20 negative implications? /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms090803050600090008090407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA1MDYwNzAyMjVaMCMGCSqGSIb3DQEJBDEW BBQhzXUCktpur2uXAX36OAqG6OGEhjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAj4kiB1m1IDNaTtNk8eA2rnNLtl88934HHCKc17Q2e+3XAeJopfxjB1IWQm9Lk0uFOhRb lrXyz0Vu1rRL3JdM1GWkHVQDaeZuBc/AYNUjwEvvYMaVnIFDBigrfJsWLxEHt2HCECA3nxEm Am/KQU2Mo9D3O77LegRm1luxbXA82jBpDmAovheblUovqyJCx3vlFc9tp91FzZ5GdUy7tf+f TPKpI9YIbezJhZ+yBdGhaBc4iiKRsyFPoC9Zp7455ARP8cuix6sMcVdUHc5/KSJFe5n9CDce ajMX0gp+zJWMJCXZICueEbSsCwngLrHHLzJPH87wXmoJbH6rUH7YlV/FZQAAAAAAAA== --------------ms090803050600090008090407-- From nobody Wed May 6 02:34:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26A61A9071 for ; Wed, 6 May 2015 02:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmd6dpBcDdG6 for ; Wed, 6 May 2015 02:34:33 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04331A87E8 for ; Wed, 6 May 2015 02:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t469YTq3021942; Wed, 6 May 2015 11:34:29 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lhXnK0XrszDj7Y; Wed, 6 May 2015 11:34:29 +0200 (CEST) Message-ID: <5549E023.1020600@tzi.org> Date: Wed, 06 May 2015 11:34:27 +0200 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ludwig Seitz References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> <5549BC81.1050808@sics.se> In-Reply-To: <5549BC81.1050808@sics.se> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 09:34:34 -0000 > Why was it done this way in JOSE in the first place? Can't answer that one. > A CBOR tag sounds neat, can the CBOR experts tell us if there are any > negative implications? Well, first of all, there should be no security implications of any of this, as this identification information is not protected. So we should have full freedom in doing what fits our applications. Many applications already know the type of the object to be expected from the context, so there isn't even a need for self-describing identification. E.g., in a CoAP environment, we could simply have three different media types for the different types of COSE object. Other applications would indeed derive a benefit from a self-describing property. These applications may, again, from context, know that they are handling a COSE object, but not which one. This is the situation that is addressed by the current draft, which includes an identifying number right at the start of the top-level array. If an application could be handling other objects than COSE ones, where these other objects also are encoded in CBOR, would benefit from a CBOR tag. Usage of such a tag could be left optional to also benefit those applications that already have the contextual information. >From an encoding overhead point of view, not providing identifying information is of course best. The solution to put in a small integer in the top-level array consistently costs a single byte, independent of whether the information is needed or not (of course, in the latter case there is still a diagnostic value of that redundancy). A CBOR tag can be encoded in a single byte, but there are only very few code points for that (24 in total, of which 9 are allocated by RFC 7049). So I would expect us to go for a tag value that allows encoding in two bytes (there are 217 of these code points left, so taking three or four should not be a problem). So the cost would be two bytes if needed, and zero bytes if supplied by context. For the purposes of draft-selander-ace-object-security-01.txt, the type of the object should always be known from the context, so here going for an optional tag could actually be used to save a byte. Grüße, Carsten From nobody Wed May 6 06:04:43 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1551A8A77 for ; Wed, 6 May 2015 06:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Cd-xjf6TkLI for ; Wed, 6 May 2015 06:04:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92C11A0217 for ; Wed, 6 May 2015 06:04:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-80-554a11645879 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 19.6C.28096.4611A455; Wed, 6 May 2015 15:04:36 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Wed, 6 May 2015 15:04:35 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Key management in the World of COSE Thread-Index: AdCDmFbhTIQQ0AuDSXqf2/HXRZJL7wEZNxeA Date: Wed, 6 May 2015 13:04:35 +0000 Message-ID: References: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> In-Reply-To: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: <0B63AF4EF69F8747BB3A69F65B899333@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RjdF0CvUYOZ6U4tpW6eyWqye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4s/E7Y8GJFsaK18fb2RoYpzQydjFyckgI mEi8eHaVCcIWk7hwbz1bFyMXh5DAUUaJLafvsoEkhAQWMUqcm5cCYrMJuEg8aHgE1iAi4CGx a/cnZhBbWMBcYvH15WwQcQuJe09XsUDYRhL7dl0DW8YioCJxteckWC8vUM2ms2dZIObbS3zZ 2gNmcwo4SEzacZsdxGYEOuj7qTVg9cwC4hK3nsyHOlRAYsme88wQtqjEy8f/WEFsUQE9iZXX m4Bu4ACKK0os75cDMZkFNCXW79KHmGItseD6UhYIW1FiSvdDdohrBCVOznzCMoFRfBaSZbMQ umch6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKj7eCW31Y7GA8+dzzE KMDBqMTDu6DUM1SINbGsuDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYzCPzU7vxxYbiVUs2zbnJVcp+2uHQkUf5D5o75onhZn3EQ1qdcnjl6rY3Cd8buoKWRv+m7D NeonIv7OSsuQndFa8SDOSWsLY/+LgzU7baZ9vcf216JEzztm+/YX2Y+05b13e/sahBaXXZ5T W9cwYx0D+1FZrvLjn742ePqcWyd4xXfjgbkbX+1XYinOSDTUYi4qTgQAxtikq5cCAAA= Archived-At: Subject: Re: [Cose] Key management in the World of COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 13:04:42 -0000 SGkgSmltDQoNClNvcnJ5IGZvciB0aGUgZGVsYXkuIEkgZmlyc3QgZGVzY3JpYmUgdGhlIG5lZWRz IEkgc2VlIGZyb20gYW4gQUNFIHBvaW50IG9mDQp2aWV3LCBhbmQgdGhlbiBsYXRlciB0cnkgdG8g bWFwIHRoaXMgdG8gdGhlIGV4YW1wbGVzIGluIHlvdXIgbWFpbC4NCg0KRnJvbSB0aGUgQUNFIHBl cnNwZWN0aXZlIHRoZXJlIGFyZSBhdCBsZWFzdCB0d28gc29ydHMgb2YgaW5mb3JtYXRpb24gZmxv d3MNCndoZXJlIENPU0Ugb2JqZWN0cyBtYXkgYmUgcmVsZXZhbnQgKHNlZSBzZWN0aW9ucyAyLjMt Mi40IG9mDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWdlcmRlcy1hY2UtYWN0b3JzLTA1 LnR4dCk6DQoNCkEuIFRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHBvdGVudGlhbGx5IGNvbnN0cmFp bmVkIGVuZHBvaW50cy4gVGhpcw0KaW5jbHVkZXMgd3JhcHBlZCBzdWJzZXRzIG9mIENvQVAgbWVz c2FnZXMsIGUuZy4gcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zLg0KDQpCLiAiQ29udHJvbCBpbmZv cm1hdGlvbuKAnSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcy4gVGhpcyBpbmNsdWRlIGluZm9ybWF0 aW9uDQpuZWNlc3NhcnkgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG9mIHRo ZSBvdGhlciBwb3RlbnRpYWxseQ0KY29uc3RyYWluZWQgZW5kcG9pbnQsIGluY2x1ZGluZyB3cmFw cGVkIGtleXMvc2VjdXJpdHkgY29udGV4dHMsDQpjcmVkZW50aWFscyBzdWNoIGFzIHB1YmxpYyBr ZXlzIG9yIGNlcnRpZmljYXRlcyBvciBvdGhlciBhc3NlcnRpb25zLg0KDQoNCkFub3RoZXIgYXNz dW1wdGlvbiB0aGF0IG1heSBiZSBpbXBvcnRhbnQgaGVyZSBpcyB0aGF0IHdlIGFzc3VtZSB0aGF0 IGluDQpzb21lIGNhc2VzIHdlIGNhbiBhc3N1bWUgc29tZSBzZWN1cml0eSBzdGF0ZSBjYW4gYmUg a2VwdCBiZXR3ZWVuIHNlbmRlcg0KYW5kIHJlY2VpdmVyIG92ZXIgc2V2ZXJhbCBtZXNzYWdlIGV4 Y2hhbmdlcyAoa2V5cywga2V5IGlkZW50aWZpZXJzLA0Kc2VxdWVuY2UgbnVtYmVycywgLiAuIC4p LiBJIGRvbuKAmXQga25vdyBpZiB5b3VyIGV4YW1wbGVzIGFzc3VtZSBzb21lIGFzcGVjdA0Kb2Yg c3RhdGVsZXNzbmVzcz8NCg0KDQpJbiB0ZXJtcyBvZiBtZXNzYWdlIHByb3RlY3Rpb24sIGhlcmUg YXJlIHRoZSBzZWN1cml0eSBjb25zdHJ1Y3RzIHdlIGhhZCBpbg0KbWluZDoNCg0KYS4gU3ltbWV0 cmljIGludGVncml0eSBwcm90ZWN0aW9uICDigJQgZS5nLiBNQUMoc2ssIG0pDQpiLiBTeW1tZXRy aWMgZW5jcnlwdGlvbiArIHN5bW1ldHJpYyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiDigJQgZS5nLiBB RUFEKHNrLCBtKQ0KYy4gQXN5bW1ldHJpYyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiDigJQgZS5nLiBT aWduKFBySywgbSkNCmQuIFN5bW1ldHJpYyBlbmNyeXB0aW9uICsgYXN5bW1ldHJpYyBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiDigJQgZS5nLiBBRVMoc2ssDQptKTsgU2lnbihQckssIEFFUyhzaywgbSkp DQoNCnNrPXN5bW1ldHJpYyBrZXksIG09bWVzc2FnZSwgUHJLPXByaXZhdGUga2V5LCBQSz1wdWJs aWMga2V5DQoNCldlIGFzc3VtZSBpbiBhbGwgdGhlc2UgY29uc3RydWN0cyB0aGF0IHRoZSBrZXlz IHVzZWQgYXJlIHByZS1lc3RhYmxpc2hlZCwNCm9yIHRoYXQgbmV3IHN5bW1ldHJpYyBrZXlzIGNh biBiZWNvbWUgZXN0YWJsaXNoZWQuDQoNCkluIG9yZGVyIHRvIHJlZmVyZW5jZSBhIHByZS1lc3Rh Ymxpc2hlZCBrZXkgd2UgYXNzdW1lIHRoZXJlIGlzIGEga2V5DQppZGVudGlmaWVyIGFzc29jaWF0 ZWQgdG8gdGhlIGtleSwgZS5nLiB1c2luZyB0aGUgImtpZCIgcGFyYW1ldGVyLCBvciBzb21lDQp2 YXJpYW50IGFsbG93aW5nIGRpc3RpbmN0aW9uIGJldHdlZW4gc3ltbWV0cmljL2FzeW1tZXRyaWMg a2V5IGhlcmUgZGVub3RlZA0KInNraWQiLyJha2lkIi4gVGhlIGlkZW50aWZlcnMgbmVlZGVkIGRp ZmZlciBiZXR3ZWVuIHRoZSBjYXNlczoNCg0KYS4gc2tpZCA9IDxpZGVudGlmaWVyIG9mIHNrPg0K Yi4gc2tpZCA9IDxpZGVudGlmaWVyIG9mIHNrPg0KYy4gYWtpZCA9IDxpZGVudGlmaWVyIG9mIFBL Pg0KZC4gc2tpZCA9IDxpZGVudGlmaWVyIG9mIHNrPiwgYWtpZCA9IDxpZGVudGlmaWVyIG9mIFBL Pg0KDQpUbyBhbGxvdyBlc3RhYmxpc2htZW50IG9mIG5ldyBzeW1tZXRyaWMga2V5cyB3ZSBzZWUg dXNlIGZvciB0aGUgZm9sbG93aW5nDQptZXRob2RzIGluIGNvbWJpbmF0aW9uIHdpdGggYS1kLg0K DQooaSkgQUVTKHNrMSwgc2syKSANCihpaSkgRW5jKFBLLCBzazIpDQooaWlpKSBFQ0RILUVTDQoN CihpKSBhbmQgKGlpKSBhcmUga2V5IHB1c2ggbWV0aG9kcyBiYXNlZCBvbiBrbm93biByZWNpcGll bnQga2V5IChzazEgYW5kDQpQSywgcmVzcGVjdGl2ZWx5KS4gTWV0aG9kIChpaWkpIGFzc3VtZXMg dGhlIGluY2x1c2lvbiBvZiBzZW5kZXIgImVwayINCmhlYWRlciBwYXJhbWV0ZXIgYW5kIHVzaW5n IGEga25vd24gc3RhdGljIERILWtleSBvZiB0aGUgcmVjZWl2ZXIgKGFuZA0Ka25vd24gS0RGIGV0 Yy4pDQoNCldoZW4gdGhpcyBrZXkgZXN0YWJsaXNobWVudCBpcyBwYXJ0IG9mIGEgbWVzc2FnZSBl eGNoYW5nZSBhcyBhYm92ZSwgaXQNCnJlcGxhY2VzIHRoZSAic2tpZCIgcGFyYW1ldGVyIHVzZWQg aW4gb25lIG9mIHRoZSBtZXRob2RzIGEtZCBhYm92ZS4gSXQNCnNob3VsZCBhY3R1YWxseSByZXN1 bHQgaW4gdGhlIGdlbmVyYXRpb24gb2YgYSBuZXcga2V5IGlkZW50aWZpZXIgInNraWQiDQpmb3Ig dGhlIGVzdGFibGlzaGVkIGtleSwgd2hpY2ggY2FuIGJlIHJlZmVyZW5jZWQgaW4gbGF0ZXIgZXhj aGFuZ2VzLg0KDQpXZSBhbHNvIHNlZSB0aGUgbmVlZCBmb3IgZXN0YWJsaXNoaW5nIGtleXMgYW5k IGtleSBpZGVudGlmaWVycyB3aXRob3V0DQpjb21iaW5pbmcgdGhhdCB3aXRoIG90aGVyIG1lc3Nh Z2UgZXhjaGFuZ2UsIGkuZS4gaW50ZWdyYXRpbmcgdGhlIGtleQ0KZXN0YWJsaXNobWVudCBtZXRo b2RzIHdpdGggcmVsZXZhbnQgaW50ZWdyaXR5IHByb3RlY3Rpb24gc3VjaCBhcyBmb3INCmV4YW1w bGU6DQoNCihpKSArIGEgKGtleSB0cmFuc3BvcnQgb2Ygc3ltbWV0cmljIGtleSB3aXRoIGludGVn cml0eSBwcm90ZWN0aW9uLCBiYXNlZA0Kb24gc2hhcmVkIGtleSkNCihpaSkgKyBjIChrZXkgdHJh bnNwb3J0IG9mIHN5bW1ldHJpYyBrZXkgd2l0aCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgYmFzZWQN Cm9uIGFzeW1tZXRyaWMga2V5cykNCihpaWkpICsgYSAoREgga2V5IGVzdGFibGlzaG1lbnQgYmFz ZWQgb24gc2VuZGVyIGVwaGVtZXJhbCBQSyBhbmQgcmVjZWl2ZXINCnN0YXRpYyBQSywgYXV0aGVu dGljYXRlZCB3aXRoIHNoYXJlZCBrZXkpDQoNCg0KRnVydGhlciBjb21tZW50cyBpbmxpbmU6DQoN Cg0KDQpPbiAyMDE1LTA1LTAxIDAwOjU3LCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFy cy5jb20+IHdyb3RlOg0KDQo+SSB3YW50ZWQgdG8gdHJ5IGFuZCBsb29rIGNsb3NlciBhdCBDYXJz dGVuJ3MgY2FsbCBmb3IgbW9yZSBudW1iZXJzIGluDQo+ZGlmZmVyZW50IGFwcGxpY2F0aW9ucywg YnV0IGJlZm9yZSBJIGNhbiBkbyB0aGF0IEkgbmVlZCB0byBmaWd1cmUgb3V0IHdoYXQNCj5hcHBs aWNhdGlvbnMgdGhlcmUgYXJlIGFuZCB3aGljaCBvbmVzIGFyZSBjdXJyZW50bHkgdGhvdWdodCB0 byBiZSBvZg0KPmdyZWF0ZXINCj5pbXBvcnRhbmNlLiAgSSBoYXZlIHRyaWVkIHRvIHN0YXJ0IGJ5 IGxvb2tpbmcgYXQgdGhlIGRpZmZlcmVudCBzZWN1cml0eQ0KPmNvbnN0cnVjdHMgdGhhdCBtYXkg YmUgdXNlZCBmb3IgdGhlc2UgYXBwbGljYXRpb25zIGluIHRlcm1zIG9mIHdoYXQgdGhlDQo+bmVl ZGVkIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcyBhcmUuDQo+DQo+MS4gSW50ZWdyaXR5IGJhc2Vk IG9uIHJlY2lwaWVudCBhc3ltbWV0cmljIGtleTogIEkgZXhwZWN0IHRoYXQgdGhpcyBpcw0KPm5v dCBhDQo+Y29tbW9uIHNjZW5hcmlvIHRvIGhhcHBlbiBmb3IgQ29SRSBzeXN0ZW1zLiAgVGhpcyBz Y2VuYXJpbyByZXF1aXJlcyB0aGF0DQo+dGhlDQo+c2VuZGVyIGdldCBhIGNlcnRpZmllZCBwdWJs aWMga2V5IGZvciB0aGUgcmVjaXBpZW50IGFuZCB1c2VzIHRoYXQsIGFsb25nDQo+d2l0aCBzb21l IGVwaGVtZXJhbCBkYXRhIGxvY2FsIHRvIGl0LCB0byBjcmVhdGUgYSBzaG9ydCB0ZXJtIHNoYXJl ZCBzZWNyZXQNCj51c2VkIHRvIHByb3RlY3QgdGhlIGludGVncml0eSBvZiB0aGUgbWVzc2FnZS4g IFRoaXMgc2NlbmFyaW8gcHJvdmlkZXMgbm8NCj5pbmRpY2F0aW9uIG9mIHdoZXJlIHRoZSBkYXRh IG9yaWdpbmF0ZWQsIHRodXMgaXQgY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGENCj5tZXNzYWdlIGZv ciBtdWx0aXBsZSByZWNpcGllbnRzLiAgQW4gZXhhbXBsZSBvZiBob3cgdGhpcyB3b3VsZCBiZQ0K PmltcGxlbWVudGVkIGlzIHRoZSB1c2Ugb2YgQ0JDLU1BQyB3aXRoIEVDREgtRVMga2V5IGFncmVl bWVudCBwbHVzIEtERi4NCg0KRG8geW91IG1lYW4gIml0IGNhbiBOT1QgYmUgdXNlZCB0byBjcmVh dGUgYSBtZXNzYWdlIGZvciBtdWx0aXBsZQ0KcmVjaXBpZW50c+KAnT8gSSBkb27igJl0IHNlZSB0 aGF0IGl0IGFjdHVhbGx5IHByb3ZpZGVzIGludGVncml0eSwgc2luY2UgYW55b25lDQpjb3VsZCB3 cmFwIGEgc3ltbWV0cmljIGtleSB3aXRoIHRoZSByZWNpcGllbnQgcHVibGljIGtleSBhbmQgcmVw bGFjZSB0aGUNCk1BQy4gSW4gYW55IGNhc2UsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIHByb2JhYmx5 IG5vdCBhIGNvbW1vbiBzY2VuYXJpby4NCg0KDQo+DQo+Mi4gSW50ZWdyaXR5IGFuZCBsb3ctbGV2 ZWwgb3JpZ2luYXRpb24gYmFzZWQgb24gYSBzaG9ydCB0ZXJtIHNoYXJlZCBrZXk6DQo+VW5kZXIg dGhlIGN1cnJlbnQgc3lzdGVtIHRoaXMgd291bGQgYmUgc2V0dXAgdXNpbmcgYSBEVExTIHNlc3Np b24gYWxvbmcNCj53aXRoDQo+YW4gZXh0cmFjdG9yIHRvIGVzdGFibGlzaCB0aGUga2V5LiAgVGhl IGtleSB3b3VsZCBiZSBmb3IgInNob3J0LXRlcm0iIHVzZQ0KPihpLmUuICBob3VycyBub3QgZGF5 cyBvciB3ZWVrcykuICBUaGUgb3B0aW9uIG9ubHkgcHJvdmlkZXMgZm9yDQo+cG9pbnQtdG8tcG9p bnQgaW50ZWdyaXR5IG5vdCBlbmQtdG8tZW5kIGludGVncml0eS4gIEludGVncml0eSBjYW4gYmUN Cj5mb3JnZWQNCj5ieSBhbnkgcGFydHkgdGhhdCBrbm93cyB0aGUgc2hhcmVkLXNlY3JldC4gIElu IHRoaXMgbW9kZSwgdGhlcmUgbmVlZHMgdG8NCj5iZQ0KPmEgc2luZ2xlIHJlY2lwaWVudCBvZiB0 aGUgbWVzc2FnZS4gIElmIHRoaXMgY29uZGl0aW9uIGlzIG1ldCwgb3JpZ2luYXRpb24NCj5pcw0K PnNob3duIGJ5IHNheWluZyAiSSBkaWQgbm90IG1ha2UgdGhpcyBtZXNzYWdlIHNvIHRoZSBvdGhl ciBwYXJ0eSBtdXN0IGhhdmUNCj5kb25lIHNvLiIgT3JpZ2luIG9mIHRoZSBtZXNzYWdlIGNhbm5v dCBiZSBwcm92ZWQgdG8gYSB0aGlyZCBwYXJ0eS4gIEFuDQo+ZXhhbXBsZSBvZiBob3cgdGhpcyB3 b3VsZCBiZSBpbXBsZW1lbnRlZCBpcyB0aGUgdXNlIG9mIENCQy1NQUMgd2l0aCBkaXJlY3QNCj5r ZXkuDQoNClRoaXMgY29ycmVzcG9uZHMgdG8gYS4gYWJvdmUuDQoNCj4NCj4zLiAgSW50ZWdyaXR5 IGFuZCBsb3ctbGV2ZWwgb3JpZ2luYXRpb24gYmFzZWQgb24gYSBsb25nIHRlcm0gc2hhcmVkIGtl eToNCj5VbmRlciB0aGUgY3VycmVudCBzeXN0ZW0gdGhpcyB3b3VsZCBiZSBzZXR1cCB1c2luZyBh IHBhaXItd2lzZSBrZXkNCj5lc3RhYmxpc2hlZCBiZXR3ZWVuIHR3byBlbnRpdGllcy4gIFRoZSBr ZXkgd291bGQgYmUgZm9yICJsb25nLXRlcm0iIHVzZQ0KPihpLmUuICB3ZWVrcyBvciBtb250aHMp LiAgR2l2ZW4gdGhhdCB0aGlzIGlzIGEgbG9uZyB0ZXJtIHVzZWQga2V5LCB0aGUNCj5wcm9ibGVt IG9mIHJlcGxheSBhbmQgcG90ZW50aWFsIGZvcmdlcmllcyBpcyBncmVhdGVyLiAgIEZvciB0aGlz IHJlYXNvbiwNCj5zb21lIHR5cGUgb2Yga2V5IGRlcml2YXRpb24gb24gdGhlIHNoYXJlZCBzZWN1 cml0eSB3b3VsZCBiZSBzdWdnZXN0ZWQuIFRoZQ0KPm9wdGlvbiBvbmx5IHByb3ZpZGVzIGZvciBl bmQtdG8tZW5kIGludGVncml0eSBiZXR3ZWVuIHRoZSBwYXJ0aWVzLg0KPkludGVncml0eSBjYW4g YmUgZm9yZ2VkIGJ5IGFueSBwYXJ0eSB0aGF0IGtub3dzIHRoZSBzaGFyZWQtc2VjcmV0LiAgSW4N Cj50aGlzDQo+bW9kZSwgdGhlcmUgbmVlZHMgdG8gYmUgYSBzaW5nbGUgcmVjaXBpZW50IG9mIHRo ZSBtZXNzYWdlLiAgSWYgdGhpcw0KPmNvbmRpdGlvbiBpcyBtZXQsIG9yaWdpbmF0aW9uIGlzIHNo b3duIGJ5IHNheWluZyAiSSBkaWQgbm90IG1ha2UgdGhpcw0KPm1lc3NhZ2Ugc28gdGhlIG90aGVy IHBhcnR5IG11c3QgaGF2ZSBkb25lIHNvLiIgT3JpZ2luIG9mIHRoZSBtZXNzYWdlDQo+Y2Fubm90 DQo+YmUgcHJvdmVkIHRvIGEgdGhpcmQgcGFydHkuICBBbiBleGFtcGxlIG9mIGhvdyB0aGlzIHdv dWxkIGJlIGltcGxlbWVudGVkDQo+aXMNCj50aGUgdXNlIG9mIENCQy1NQUMgd2l0aCBkaXJlY3Qg a2V5IHBsdXMgS0RGLg0KDQpJIHNlZSB0aGlzIGFzIGEgbWlub3IgdmFyaWFudCBvZiAyLiBJIGFz c3VtZSB0aGVyZSB3aWxsIGJlIHNvbWUgYWxnb3JpdGhtDQppZGVudGlmaWVyIHRoYXQgY291bGQg b3B0aW9uYWxseSByZWZlcmVuY2UgYSBLREYsIGFuZCBpZiBpdCBkb2VzIHRoZW4gaXQNCmlzIGNh c2UgMyBvdGhlcndpc2UgY2FzZSAyLiBPciB3aGF0IGVsc2UgaXMgdGhlIGRpZmZlcmVuY2U/DQoN Cg0KPg0KPjQuICBJbnRlZ3JpdHkgYW5kIGxvdy1sZXZlbCBvcmlnaW5hdGlvbiBiYXNlZCBvbiB0 d28gYXN5bW1ldHJpYyBrZXlzOiBUaGlzDQo+c2NlbmFyaW8gcmVxdWlyZXMgdGhhdCBib3RoIHRo ZSByZWNpcGllbnQgYW5kIHNlbmRlciBvZiB0aGUgbWVzc2FnZSBoYXZlDQo+d2VsbCBrbm93biBr ZXkgYWdyZWVtZW50IGtleXMuICBCb3RoIGVudGl0aWVzIG11c3QgYmUgYWJsZSB0byBnZXQgdGhl c2UNCj5laXRoZXIgZnJvbSBhIHRydXN0ZWQgdGhpcmQgcGFydHkgb3Igb3ZlciBzb21lIHR5cGUg b2YgcHJvdG9jb2wgdGhhdA0KPmluY2x1ZGVzIGRvaW5nIGEgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBj aGVjayBvbiBib3RoIHNpZGVzLiAgT25jZSB0aGlzIGlzDQo+ZG9uZSwgYSBvbmUtdGltZSBzaGFy ZWQgc2VjdXJpdHkgaXMgZ2VuZXJhdGVkIHRoYXQgaXMgdXNlZCB0byBwcm92aWRlIGJvdGgNCj5l bmQtdG8tZW5kIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBhIGRlZ3JlZSBvZiBvcmlnaW5hdGlv biBrbm93bGVkZ2UuDQo+T3JpZ2luYXRpb24gb2YgdGhlIG1lc3NhZ2UgY2Fubm90IGJlIHByb3Zl ZCB0byBhIHRoaXJkIHBhcnR5LiAgQm90aA0KPnBhcnRpZXMNCj5tdXN0IGhhdmUgYSBrZXkgdGhh dCBpcyBpbiB0aGUgc2FtZSBncm91cC4gIEEgdW5pcXVlbmVzcyB2YWx1ZSBtdXN0IGJlDQo+aW50 ZXJqZWN0ZWQgaW50byB0aGUga2V5IGFncmVlbWVudCBwcm9jZXNzIGJ5IGF0IGxlYXN0IG9uZSBv ZiB0aGUgcGFydGllcy4NCj5JdCBpcyBzdWZmaWNpZW50IHRoYXQgYSBjb3VudGVyIGJlIHVzZWQg Zm9yIHRoaXMgcHVycG9zZXMsIGl0IGlzIG5vdA0KPm5lY2Vzc2FyeSBmb3IgdGhpcyB2YWx1ZSB0 byBiZSByYW5kb20uICBBbiBleGFtcGxlIG9mIGhvdyB0aGlzIHdvdWxkIGJlDQo+aW1wbGVtZW50 ZWQgaXMgdGhlIHVzZSBvZiBDQkMtTUFDIHdpdGggYSBFQ0RILVNTIGtleSBhZ3JlZW1lbnQgcGx1 cyBLREYuDQoNCkkgZG9u4oCZdCBzZWUgaG93IHRoaXMgb3IgOS4gYWRkcyBtdWNoIHRvIHRoZSBz ZXR0aW5nIHdlIGxvb2sgYXQuDQoNCkVpdGhlciB0aGVyZSBpcyBhIHNoYXJlZCBzZWNyZXQgYmV0 d2VlbiB0aGUgc2VuZGVyIGFuZCByZWNlaXZlci4gVGhlbg0KdGhlcmUgaXMgbm8gbmVlZCB0byBk byBhIERpZmZpZS1IZWxsbWFuIHRvIGRlcml2ZSBhIGZyZXNoIHNoYXJlZCBzZWNyZXQsIGENCktE RiB3b3VsZCBkby4gT3IsIHRoZSBwdWJsaWMga2V5IG9mIHRoZSBzZW5kZXIgaXMgbm90IGtub3du IHRvIHRoZQ0KcmVjZWl2ZXIsIGFuZCB0aGVuIHRoaXMgc2VlbXMgdG8gYmUgdmVyeSBzaW1pbGFy IHRvIEVDREgtRVMgKDYuIGJlbG93KS4NCg0KDQo+DQo+NS4gSW50ZWdyaXR5IGFuZCBoaWdoLWxl dmVsIG9yaWdpbmF0aW9uIGJhc2VkIG9uIHNlbmRlciBhc3ltbWV0cmljIGtleToNCj5UaGlzIHNj ZW5hcmlvIHJlcXVpcmVzIHRoYXQgYSB0cnVlIHNpZ25hdHVyZSBhbGdvcml0aG0gYmUgZGVmaW5l ZCBhbmQgdXNlZA0KPmFzIHdlbGwgYXMgdGhlIGFiaWxpdHkgZm9yIGEgcmVjaXBpZW50IHRvIHF1 ZXJ5IGEgdHJ1c3RlZCB0aGlyZCBwYXJ0eSB0aGF0DQo+dGhlIGJpbmRpbmcgb2YgaWRlbnRpdHkg YW5kIHB1YmxpYyBrZXkgaXMgdHJ1ZS4gIFVzaW5nIHRoaXMgYWxsb3dzIGZvciB0aGUNCj5vcmln aW5hdGlvbiBhbmQgaW50ZWdyaXR5IG9mIGEgbWVzc2FnZSB0byBiZSBwcm92ZWQgdG8gYSB0aGly ZCBwYXJ0eSwgdGhlDQo+c2lnbmF0dXJlIGlzIG5vdCBkaXJlY3RlZCBhdCBhbnkgc3BlY2lmaWMg cGFydHkuICBBbiBleGFtcGxlIG9mIGhvdyB0aGlzDQo+d291bGQgYmUgaW1wbGVtZW50ZWQgaXMg dGhlIHVzZSBvZiBFQ0RTQSB3aXRoIFNIQS0yNTYuDQoNClRoaXMgY29ycmVzcG9uZHMgdG8gYy4g YWJvdmUNCg0KPg0KPjYuICBDb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSBiYXNlZCBvbiBy ZWNpcGllbnQgYXN5bW1ldHJpYyBrZXk6IFRoaXMNCj5zY2VuYXJpbyBzaGFyZXMgbW9zdCBvZiB0 aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFzIGRvZXMgc2NlbmFyaW8gMS4gIFRoZQ0KPnJlcXVpcmVk IGludGVncml0eSBjYW4gYmUgb2J0YWluZWQgYnkgdGhlIHVzZSBvZiBhbiBBRUFEIGFsZ29yaXRo bSByYXRoZXINCj50aGFuIGEgTUFDIGFsZ29yaXRobS4gIEFuIGV4YW1wbGUgb2YgaG93IHRoaXMg d291bGQgYmUgaW1wbGVtZW50ZWQgaXMgdGhlDQo+dXNlIG9mIEFFUy1DQ00gd2l0aCBFQ0RILUVT IGtleSBhZ3JlZW1lbnQgcGx1cyBLREYuDQoNClRoaXMgaXMgKGlpaSkgKyBiLiBhYm92ZQ0KDQo+ DQo+Ny4gIENvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5IGFuZCBsb3ctbGV2ZWwgb3JpZ2luYXRp b24gYmFzZWQgb24gYSBzaG9ydA0KPnRlcm0gc2hhcmVkIGtleTogVGhpcyBzY2VuYXJpbyBzaGFy ZXMgbW9zdCBvZiB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFzDQo+ZG9lcw0KPnNjZW5hcmlvIDIu ICAgVGhlIHJlcXVpcmVkIGludGVncml0eSBjYW4gYmUgb2J0YWluZWQgYnkgdGhlIHVzZSBvZiBh biBBRUFEDQo+YWxnb3JpdGhtIHJhdGhlciB0aGFuIGEgTUFDIGFsZ29yaXRobSAgQW4gZXhhbXBs ZSBvZiBob3cgdGhpcyB3b3VsZCBiZQ0KPmltcGxlbWVudGVkIGlzIHRoZSB1c2Ugb2YgQUVTLUND TSB3aXRoIGRpcmVjdCBrZXkuDQoNClRoaXMgY29ycmVzcG9uZHMgdG8gYi4gYWJvdmUuDQoNCj4N Cj44LiBDb25maWRlbnRpYWxpdHksIGludGVncml0eSBhbmQgbG93LWxldmVsIG9yaWdpbmF0aW9u IGJhc2VkIG9uIGEgbG9uZw0KPnRlcm0NCj5zaGFyZWQga2V5OiAgVGhpcyBzY2VuYXJpbyBzaGFy ZXMgbW9zdCBvZiB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFzIGRvZXMNCj5zY2VuYXJpbyAzLiAg VGhlIHJlcXVpcmVkIGludGVncml0eSBjYW4gYmUgb2J0YWluZWQgYnkgdGhlIHVzZSBvZiBhbiBB RUFEDQo+YWxnb3JpdGhtIHJhdGhlciB0aGFuIGEgTUFDIGFsZ29yaXRobS4gIEFuIGV4YW1wbGUg b2YgaG93IHRoaXMgd291bGQgYmUNCj5pbXBsZW1lbnRlZCBpcyB0aGUgdXNlIG9mIEFFUy1DQ00g d2l0aCBkaXJlY3Qga2V5IHBsdXMgS0RGLg0KDQpBZ2FpbiBhIG1pbm9yIHZhcmlhbnQgb2YgNy4N Cg0KPg0KPjkuIENvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5IGFuZCBsb3ctbGV2ZWwgb3JpZ2lu YXRpb24gYmFzZWQgb24gdHdvDQo+YXN5bW1ldHJpYyBrZXlzOiAgVGhpcyBzY2VuYXJpbyBzaGFy ZXMgbW9zdCBvZiB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFzDQo+ZG9lcyBzY2VuYXJpbyA0LiAg ICBUaGUgcmVxdWlyZWQgaW50ZWdyaXR5IGNhbiBiZSBvYnRhaW5lZCBieSB0aGUgdXNlIG9mDQo+ YW4NCj5BRUFEIGFsZ29yaXRobSByYXRoZXIgdGhhbiBhIE1BQyBhbGdvcml0aG0uICBBbiBleGFt cGxlIG9mIGhvdyB0aGlzIHdvdWxkDQo+YmUNCj5pbXBsZW1lbnRlZCBpcyB0aGUgdXNlIG9mIEFF Uy1DQ00gd2l0aCBFQ0RILVNTIGtleSBhZ3JlZW1lbnQgcGx1cyBLREYuDQoNClNlZSBzY2VuYXJp byA0IGFib3ZlDQoNCj4NCj4xMC4gQ29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIGhpZ2gt bGV2ZWwgb3JpZ2luYXRpb24gYmFzZWQgb24gc2VuZGVyDQo+YXN5bW1ldHJpYyBrZXk6ICBUaGlz IHNjZW5hcmlvIHNoYXJlcyB0aGUgaW50ZWdyaXR5IGFuZCBvcmlnaW5hdGlvbg0KPnJlcXVpcmVt ZW50cyBvZiBzY2VuYXJpbyA1LCBob3dldmVyIHRoZSBhbGdvcml0aG0gY2hvaWNlIHRoZXJlIGRv ZXMgbm90DQo+cHJvdmlkZSBhbiBjb25maWRlbnRpYWxpdHkuICBBIGRpZmZlcmVudCBjb25maWRl bnRpYWxpdHkgbWVjaGFuaXNtIG11c3QgYmUNCj51c2VkLiAgQW55IG9mIHRoZSBtZXRob2RzIHVz ZWQgaW4gc2NlbmFyaW9zIDUtOSBjb3VsZCBiZSB1c2VkIGZvciB0aGlzDQo+cHVycG9zZS4gIEdl dHRpbmcgYm90aCBzZXRzIG9mIGZ1bmN0aW9uYWxpdHkgd2lsbCByZXF1aXJlZCB0aGUgdXNlIG9m IGENCj53cmFwcGVkIG1lc3NhZ2Ugc2NlbmFyaW8gd2hlcmUgdGhlIHNpZ25lZCBtZXNzYWdlIGlz IHdyYXBwZWQgaW5zaWRlIG9mIGFuDQo+ZW5jcnlwdGVkIG1lc3NhZ2UuICAoQXR0ZW1wdGluZyB0 byBkbyBib3RoIGluIHRoZSBzYW1lIG1lc3NhZ2Ugd2FzIHJlbW92ZWQNCj5iZXR3ZWVuIFBLQ1Mg IzcgYW5kIENNUyBkdWUgdG8gc2VjdXJpdHkgZmxhd3MuICBJdCB3YXMgcG9zc2libGUgdG8gYm90 aA0KPmRldGVybWluZSB3aG8gdGhlIG1lc3NhZ2Ugc2lnbmVyIHdhcyBhbmQgdG8gZG8gdHJhZmZp YyBhbmFseXNpcyBvbiB0aGUNCj5jb250ZW50IG9mIHRoZSBtZXNzYWdlIGJ5IGxvb2tpbmcgYXQg dGhlIGhhc2ggb2YgdGhlIHJlc3VsdGluZyBzaWduYXR1cmUuKQ0KDQoNCldlIGFyZSBsb29raW5n IGZvciBzb21ldGhpbmcgbGlrZSBkLiBhYm92ZS4gSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZw0K ZGlmZmVyZW50PyBUaGUgY29tbWVudCBhYm91dCBzZWN1cml0eSBmbGF3IGluIFBLQ1MjNyBzZWVt cyBmcm9tIHlvdXIgc2hvcnQNCmV4cGxhbmF0aW9uIHRvIHJlbGF0ZSB0byBzaWduLXRoZW4tZW5j cnlwdCwgaXMgdGhlcmUgYWxzbyBhbiBpc3N1ZSB3aXRoDQplbmNyeXB0LXRoZW4tc2lnbj8NCg0K QSBjb21iaW5hdGlvbiBvZiA3IGFuZCA1IGlzIGFuIG9wdGlvbiB0byBkLCBidXQgcmVwbGFjaW5n IGFuIEFFQUQgd2l0aCBBRVMNCnByb2JhYmx5IGJlIG1vcmUgb3B0aW1hbC4NCg0KDQo+DQo+V2hp Y2ggb2YgdGhlc2UgdGVuIHNjZW5hcmlvcyBkbyB3ZSBiZWxpZXZlIGFyZSBnb2luZyB0byBiZSBj b21tb25seSB1c2VkPw0KPldoYXQgcGVyY2VudGFnZSBvZiB0aGUgdGltZSBkbyB3ZSB0aGluayB0 aGVzZSBvcHRpb25zIGFyZSBnb2luZyB0byBiZQ0KPnVzZWQ/DQoNCkl0IGlzIGRpZmZpY3VsdCB0 byBwcmVkaWN0LCBidXQgSSB3b3VsZCBleHBlY3QgdGhlIG1lc3NhZ2VzIHJlbGF0ZWQgdG8NCmlu dGVyYWN0aW9uIGJhc2VkIG9uIGV4aXN0aW5nIGtleXMgKEEpIHdvdWxkIGJlIG1vcmUgcHJldmFs ZW50IHRoYW4gdGhlDQptZXNzYWdlIHJlbGF0ZWQgdG8gY29udHJvbCBpbmZvcm1hdGlvbiBhbmQg ZXN0YWJsaXNobWVudCBvZiBrZXlzIChCKS4NCkZ1cnRoZXIgdGhhdCBwb2ludC10by1wb2ludCBt ZXNzYWdlcyB3b3VsZCBiZSBtb3JlIHByZXZhbGVudCB0aGFuDQpwb2ludC10by1tdWx0aXBvaW50 LiBIZW5jZSB0aGUgbW9zdCBjb21tb24gd291bGQgYmUgYS4gYW5kIGIuLCBmb2xsb3dlZCBieQ0K Yy4gYW5kIGQuLCBmb2xsb3dlZCBieSAoaSktKGlpaSkgaW4gY29tYmluYXRpb24gd2l0aCBhLWQu DQoNCkfDtnJhbg0KDQo+VGhpcyB3aWxsIGdpdmUgdXMgc29tZSBzdGFydGluZyBkYXRhIHRvIGxv b2sgYXQgd2hpY2ggc3RydWN0dXJlcyBhcmUgZ29pbmcNCj50byBiZSB0aGUgbW9zdCBjb21tb25s eSB1c2VkIGFuZCBnZXQgYSBzdGFydCBvbiB3aGljaCBmaWVsZHMgaW4gdGhlDQo+c3RydWN0dXJl cyBhcmUgZ29pbmcgdG8gYmUgcHJlc2VudC4gIFRoZXJlIHdpbGwgYmUgc29tZSBmb2xsb3cgb24N Cj5xdWVzdGlvbnMNCj50byB0cnkgYW5kIG1ha2UgdGhpcyBkZXRlcm1pbmF0aW9uLg0KPg0KPkpp bQ0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Q29zZSBtYWlsaW5nIGxpc3QNCj5Db3NlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== From nobody Wed May 6 14:28:34 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF01AD370 for ; Wed, 6 May 2015 14:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZACkAYcKyAq for ; Wed, 6 May 2015 14:28:32 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915A11ACDD7 for ; Wed, 6 May 2015 14:28:32 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t46LST3h052526 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2015 14:28:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> Date: Wed, 6 May 2015 14:28:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22B93624-1F44-46CE-BB71-D03AB58ABB06@vpnc.org> References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2098) Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 21:28:33 -0000 On Apr 30, 2015, at 3:58 PM, Jim Schaad wrote: > Question: Identification of objects: > a) CBOR Tag - either general or specific to each type > b) Required Identifier > c) Use the same techniques as JOSE (a) is OK, but (b) is more definitive. (c) is, as you point out, = wasteful of program space. I would more highly support (b) because it is a single byte whereas (a) = might be one or more bytes. --Paul Hoffman= From nobody Wed May 6 14:30:19 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E37D1B2FA9 for ; Wed, 6 May 2015 14:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj1xhBIvIDP6 for ; Wed, 6 May 2015 14:30:18 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757681ACDD7 for ; Wed, 6 May 2015 14:30:18 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t46LUG7p052559 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2015 14:30:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> Date: Wed, 6 May 2015 14:30:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <724B1E60-A92F-42EB-B7BD-732A6B19ECCA@vpnc.org> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2098) Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 21:30:19 -0000 On Apr 30, 2015, at 3:59 PM, Jim Schaad wrote: > Question: Flattened encoding - > a) Roll into parent map > b) Just be a map > c) Single element in array If the top level is an array, clearly (c) is the right way to go. = Otherwise, both (a) and (b) seem similar in code size and data size. --Paul Hoffman= From nobody Wed May 6 21:02:51 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CA51A8AF9 for ; Wed, 6 May 2015 21:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_pwwlbN5Wir for ; Wed, 6 May 2015 21:02:47 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F971A8AF5 for ; Wed, 6 May 2015 21:02:47 -0700 (PDT) Received: from Philemon (c-71-237-245-2.hsd1.or.comcast.net [71.237.245.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 73C682C9EE; Wed, 6 May 2015 21:02:46 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> In-Reply-To: Date: Wed, 6 May 2015 21:01:24 -0700 Message-ID: <035901d0887a$7ccde3c0$7669ab40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIiDDTO/LtF93LmyDHgR+orETQ1MQHuzG0UnL1iptA= Archived-At: Subject: Re: [Cose] Key management in the World of COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 04:02:50 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Wednesday, May 06, 2015 6:05 AM > To: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] Key management in the World of COSE >=20 > Hi Jim >=20 > Sorry for the delay. I first describe the needs I see from an ACE = point of view, > and then later try to map this to the examples in your mail. >=20 > From the ACE perspective there are at least two sorts of information = flows > where COSE objects may be relevant (see sections 2.3-2.4 of > http://www.ietf.org/id/draft-gerdes-ace-actors-05.txt): >=20 > A. The interaction between potentially constrained endpoints. This = includes > wrapped subsets of CoAP messages, e.g. resource representations. >=20 > B. "Control information=E2=80=9D for constrained devices. This include = information > necessary for authentication and authorization of the other = potentially > constrained endpoint, including wrapped keys/security contexts, = credentials > such as public keys or certificates or other assertions. >=20 >=20 > Another assumption that may be important here is that we assume that = in > some cases we can assume some security state can be kept between = sender > and receiver over several message exchanges (keys, key identifiers, > sequence numbers, . . .). I don=E2=80=99t know if your examples assume = some aspect > of statelessness? >=20 >=20 > In terms of message protection, here are the security constructs we = had in > mind: >=20 > a. Symmetric integrity protection =E2=80=94 e.g. MAC(sk, m) b. = Symmetric > encryption + symmetric integrity protection =E2=80=94 e.g. AEAD(sk, m) = c. > Asymmetric integrity protection =E2=80=94 e.g. Sign(PrK, m) d. = Symmetric encryption > + asymmetric integrity protection =E2=80=94 e.g. AES(sk, m); Sign(PrK, = AES(sk, m)) >=20 > sk=3Dsymmetric key, m=3Dmessage, PrK=3Dprivate key, PK=3Dpublic key >=20 > We assume in all these constructs that the keys used are = pre-established, or > that new symmetric keys can become established. >=20 > In order to reference a pre-established key we assume there is a key > identifier associated to the key, e.g. using the "kid" parameter, or = some > variant allowing distinction between symmetric/asymmetric key here > denoted "skid"/"akid". The identifers needed differ between the cases: >=20 > a. skid =3D > b. skid =3D > c. akid =3D > d. skid =3D , akid =3D >=20 > To allow establishment of new symmetric keys we see use for the = following > methods in combination with a-d. >=20 > (i) AES(sk1, sk2) > (ii) Enc(PK, sk2) > (iii) ECDH-ES >=20 > (i) and (ii) are key push methods based on known recipient key (sk1 = and PK, > respectively). Method (iii) assumes the inclusion of sender "epk" > header parameter and using a known static DH-key of the receiver (and > known KDF etc.) >=20 > When this key establishment is part of a message exchange as above, it > replaces the "skid" parameter used in one of the methods a-d above. It > should actually result in the generation of a new key identifier = "skid" > for the established key, which can be referenced in later exchanges. >=20 > We also see the need for establishing keys and key identifiers without > combining that with other message exchange, i.e. integrating the key > establishment methods with relevant integrity protection such as for > example: >=20 > (i) + a (key transport of symmetric key with integrity protection, = based on > shared key) > (ii) + c (key transport of symmetric key with integrity protection, = based on > asymmetric keys) > (iii) + a (DH key establishment based on sender ephemeral PK and = receiver > static PK, authenticated with shared key) >=20 >=20 > Further comments inline: >=20 >=20 >=20 > On 2015-05-01 00:57, "Jim Schaad" wrote: >=20 > >I wanted to try and look closer at Carsten's call for more numbers in > >different applications, but before I can do that I need to figure out > >what applications there are and which ones are currently thought to = be > >of greater importance. I have tried to start by looking at the > >different security constructs that may be used for these applications > >in terms of what the needed security characteristics are. > > > >1. Integrity based on recipient asymmetric key: I expect that this = is > >not a common scenario to happen for CoRE systems. This scenario > >requires that the sender get a certified public key for the recipient > >and uses that, along with some ephemeral data local to it, to create = a > >short term shared secret used to protect the integrity of the = message. > >This scenario provides no indication of where the data originated, = thus > >it can be used to create a message for multiple recipients. An = example > >of how this would be implemented is the use of CBC-MAC with ECDH-ES > key > >agreement plus KDF. >=20 > Do you mean "it can NOT be used to create a message for multiple > recipients=E2=80=9D? I don=E2=80=99t see that it actually provides = integrity, since anyone could > wrap a symmetric key with the recipient public key and replace the = MAC. In > any case, I agree that this is probably not a common scenario. Do not conflate the concepts of integrity with the origination. This = method only provides integrity. The message has not been changed since = it was sent. You have no idea who sent it. It could be somebody who = just generated an ephemeral key and did the key agreement operation and = sent you a message. There is no need to postulate somebody who changed = a message that they received. In this case all you know is that the = message was not sent since it was changed, not who sent it. Thus a = message can be sent to multiple people - they all can verify that the = integrity on the message is intact and none of them can know who sent = the message. >=20 >=20 > > > >2. Integrity and low-level origination based on a short term shared = key: > >Under the current system this would be setup using a DTLS session = along > >with an extractor to establish the key. The key would be for > >"short-term" use (i.e. hours not days or weeks). The option only > >provides for point-to-point integrity not end-to-end integrity. > >Integrity can be forged by any party that knows the shared-secret. = In > >this mode, there needs to be a single recipient of the message. If > >this condition is met, origination is shown by saying "I did not make > >this message so the other party must have done so." Origin of the > >message cannot be proved to a third party. An example of how this > >would be implemented is the use of CBC-MAC with direct key. >=20 > This corresponds to a. above. No it does not - not the addition of origination that was missing in the = first case. >=20 > > > >3. Integrity and low-level origination based on a long term shared = key: > >Under the current system this would be setup using a pair-wise key > >established between two entities. The key would be for "long-term" = use > >(i.e. weeks or months). Given that this is a long term used key, = the > >problem of replay and potential forgeries is greater. For this = reason, > >some type of key derivation on the shared security would be = suggested. > >The option only provides for end-to-end integrity between the = parties. > >Integrity can be forged by any party that knows the shared-secret. = In > >this mode, there needs to be a single recipient of the message. If > >this condition is met, origination is shown by saying "I did not make > >this message so the other party must have done so." Origin of the > >message cannot be proved to a third party. An example of how this > >would be implemented is the use of CBC-MAC with direct key plus KDF. >=20 > I see this as a minor variant of 2. I assume there will be some = algorithm > identifier that could optionally reference a KDF, and if it does then = it is case > 3 otherwise case 2. Or what else is the difference? The difference here is a question of how long one can use a single = shared key without having problems and how to increase that time period. = If you just got a new key from a key agreement operation, then you can = use it for a while. On the other hand if you have a key which is hard = coded into the device, it makes sense to send messages which are not = encoded with that key but with a secret derived from that key. This = means that compromise of the key is a two operation reversal rather than = a single operation reversal. Both the integrity on the message and the = KDF need to be reversed. >=20 >=20 > > > >4. Integrity and low-level origination based on two asymmetric keys: > >This scenario requires that both the recipient and sender of the > >message have well known key agreement keys. Both entities must be = able > >to get these either from a trusted third party or over some type of > >protocol that includes doing a proof-of-possession check on both = sides. > >Once this is done, a one-time shared security is generated that is = used > >to provide both end-to-end integrity protection and a degree of = origination > knowledge. > >Origination of the message cannot be proved to a third party. Both > >parties must have a key that is in the same group. A uniqueness = value > >must be interjected into the key agreement process by at least one of > >the parties. > >It is sufficient that a counter be used for this purposes, it is not > >necessary for this value to be random. An example of how this would = be > >implemented is the use of CBC-MAC with a ECDH-SS key agreement plus > KDF. >=20 > I don=E2=80=99t see how this or 9. adds much to the setting we look = at. >=20 > Either there is a shared secret between the sender and receiver. Then = there > is no need to do a Diffie-Hellman to derive a fresh shared secret, a = KDF > would do. Or, the public key of the sender is not known to the = receiver, and > then this seems to be very similar to ECDH-ES (6. below). The assumption in this case is that one does know the public key of the = recipient - either it is hard coded in the system or there is a method = of querying for it. It is quite possible that this is not a commonly = used scenario. >=20 >=20 > > > >5. Integrity and high-level origination based on sender asymmetric = key: > >This scenario requires that a true signature algorithm be defined and > >used as well as the ability for a recipient to query a trusted third > >party that the binding of identity and public key is true. Using = this > >allows for the origination and integrity of a message to be proved to = a > >third party, the signature is not directed at any specific party. An > >example of how this would be implemented is the use of ECDSA with = SHA- > 256. >=20 > This corresponds to c. above >=20 > > > >6. Confidentiality and integrity based on recipient asymmetric key: > >This scenario shares most of the same functionality as does scenario = 1. > >The required integrity can be obtained by the use of an AEAD = algorithm > >rather than a MAC algorithm. An example of how this would be > >implemented is the use of AES-CCM with ECDH-ES key agreement plus > KDF. >=20 > This is (iii) + b. above Note - this case does not tell you who sent the message - note the = absence of origination from the title. This is the reason for doing = ECDH-SS instead. >=20 > > > >7. Confidentiality, integrity and low-level origination based on a > >short term shared key: This scenario shares most of the same > >functionality as does > >scenario 2. The required integrity can be obtained by the use of an = AEAD > >algorithm rather than a MAC algorithm An example of how this would = be > >implemented is the use of AES-CCM with direct key. >=20 > This corresponds to b. above. >=20 > > > >8. Confidentiality, integrity and low-level origination based on a = long > >term shared key: This scenario shares most of the same functionality > >as does scenario 3. The required integrity can be obtained by the = use > >of an AEAD algorithm rather than a MAC algorithm. An example of how > >this would be implemented is the use of AES-CCM with direct key plus > >KDF. >=20 > Again a minor variant of 7. >=20 > > > >9. Confidentiality, integrity and low-level origination based on two > >asymmetric keys: This scenario shares most of the same functionality = as > >does scenario 4. The required integrity can be obtained by the use = of > >an > >AEAD algorithm rather than a MAC algorithm. An example of how this > >would be implemented is the use of AES-CCM with ECDH-SS key > agreement > >plus KDF. >=20 > See scenario 4 above >=20 > > > >10. Confidentiality, integrity and high-level origination based on > >sender asymmetric key: This scenario shares the integrity and > >origination requirements of scenario 5, however the algorithm choice > >there does not provide an confidentiality. A different = confidentiality > >mechanism must be used. Any of the methods used in scenarios 5-9 = could > >be used for this purpose. Getting both sets of functionality will > >required the use of a wrapped message scenario where the signed > message > >is wrapped inside of an encrypted message. (Attempting to do both in > >the same message was removed between PKCS #7 and CMS due to security > >flaws. It was possible to both determine who the message signer was > >and to do traffic analysis on the content of the message by looking = at > >the hash of the resulting signature.) >=20 >=20 > We are looking for something like d. above. I think this is something > different? The comment about security flaw in PKCS#7 seems from your > short explanation to relate to sign-then-encrypt, is there also an = issue with > encrypt-then-sign? No - my note relates to sign-and-encrypt. It is not a problem here for = either sign-then-encrypt or encrypt-then-sign. Depending on what you = want to do with the message, sign-then-encrypt is a better thing to do. = Note since this is asymmetric it is not the same issue as the = MAC-then-encrypt issues that TLS has. >=20 > A combination of 7 and 5 is an option to d, but replacing an AEAD with = AES > probably be more optimal. >=20 >=20 > > > >Which of these ten scenarios do we believe are going to be commonly > used? > >What percentage of the time do we think these options are going to be > >used? >=20 > It is difficult to predict, but I would expect the messages related to > interaction based on existing keys (A) would be more prevalent than = the > message related to control information and establishment of keys (B). > Further that point-to-point messages would be more prevalent than = point- > to-multipoint. Hence the most common would be a. and b., followed by = c. > and d., followed by (i)-(iii) in combination with a-d. >=20 > G=C3=B6ran >=20 > >This will give us some starting data to look at which structures are > >going to be the most commonly used and get a start on which fields in > >the structures are going to be present. There will be some follow on > >questions to try and make this determination. > > > >Jim > > > > > >_______________________________________________ > >Cose mailing list > >Cose@ietf.org > >https://www.ietf.org/mailman/listinfo/cose From nobody Thu May 7 00:11:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FAD1B2A45 for ; Thu, 7 May 2015 00:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tim2GI9kJ_1A for ; Thu, 7 May 2015 00:11:51 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3981A874C for ; Thu, 7 May 2015 00:11:49 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-ff-554b1034ce97 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.75.28096.4301B455; Thu, 7 May 2015 09:11:48 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Thu, 7 May 2015 09:11:47 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Key management in the World of COSE Thread-Index: AdCDmFbhTIQQ0AuDSXqf2/HXRZJL7wEZNxeAABshSAAACtcyAA== Date: Thu, 7 May 2015 07:11:47 +0000 Message-ID: References: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> <035901d0887a$7ccde3c0$7669ab40$@augustcellars.com> In-Reply-To: <035901d0887a$7ccde3c0$7669ab40$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RtdEwDvUoP+nrMW0rVNZLVZP/87m wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGU8OH6OseDaTsaK5/2TmBoYv2xh7GLk5JAQ MJE48eUaE4QtJnHh3nq2LkYuDiGBo4wSjxbeYoFwFjFK3Px4HqyKTcBF4kHDIzBbRMBDYtfu T8wgtrCAucTi68vZIOIWEveermKBsJ0kOvctYwWxWQRUJE5O+AJUz8HBC1Qzd3MhxPwljBIn 5u0C6+UUcJB48+EI2ExGoIu+n1oDtotZQFzi1pP5UJcKSCzZc54ZwhaVePn4H9h8UQE9iZXX m9hA5ksIKElM25oGYjILaEqs36UPMcVa4sL5D8wQtqLElO6H7CA2r4CgxMmZT1gmMIrPQrJs FkL3LCTds5B0z0LSvYCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYLwd3PLbagfjweeO hxgFOBiVeHgVjnuFCrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBcXnihYRp8Vuvfmn4MW+L/Pzb1XHX03/erFByPLOE6el2yfVH3kXo3jqUO2NpxVn/dM5P 81auCz93JkJw1cvV094JxPsu4o+pkXrz9AyHj2f1yQXfeziUrI9179n2f5sLl9y+Xgu1J+H5 LXX9N/Wln/lecPXfMVHljp29a2y//sHsBefUD2S29CixFGckGmoxFxUnAgCqRd/WmAIAAA== Archived-At: Subject: Re: [Cose] Key management in the World of COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 07:11:54 -0000 DQoNCk9uIDIwMTUtMDUtMDcgMDY6MDEsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21d DQo+PiBTZW50OiBXZWRuZXNkYXksIE1heSAwNiwgMjAxNSA2OjA1IEFNDQo+PiBUbzogSmltIFNj aGFhZDsgY29zZUBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtDb3NlXSBLZXkgbWFuYWdlbWVu dCBpbiB0aGUgV29ybGQgb2YgQ09TRQ0KPj4gDQo+PiBIaSBKaW0NCj4+IA0KPj4gU29ycnkgZm9y IHRoZSBkZWxheS4gSSBmaXJzdCBkZXNjcmliZSB0aGUgbmVlZHMgSSBzZWUgZnJvbSBhbiBBQ0Ug cG9pbnQNCj4+b2YgdmlldywNCj4+IGFuZCB0aGVuIGxhdGVyIHRyeSB0byBtYXAgdGhpcyB0byB0 aGUgZXhhbXBsZXMgaW4geW91ciBtYWlsLg0KPj4gDQo+PiBGcm9tIHRoZSBBQ0UgcGVyc3BlY3Rp dmUgdGhlcmUgYXJlIGF0IGxlYXN0IHR3byBzb3J0cyBvZiBpbmZvcm1hdGlvbg0KPj5mbG93cw0K Pj4gd2hlcmUgQ09TRSBvYmplY3RzIG1heSBiZSByZWxldmFudCAoc2VlIHNlY3Rpb25zIDIuMy0y LjQgb2YNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMt MDUudHh0KToNCj4+IA0KPj4gQS4gVGhlIGludGVyYWN0aW9uIGJldHdlZW4gcG90ZW50aWFsbHkg Y29uc3RyYWluZWQgZW5kcG9pbnRzLiBUaGlzDQo+PmluY2x1ZGVzDQo+PiB3cmFwcGVkIHN1YnNl dHMgb2YgQ29BUCBtZXNzYWdlcywgZS5nLiByZXNvdXJjZSByZXByZXNlbnRhdGlvbnMuDQo+PiAN Cj4+IEIuICJDb250cm9sIGluZm9ybWF0aW9u4oCdIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBU aGlzIGluY2x1ZGUNCj4+aW5mb3JtYXRpb24NCj4+IG5lY2Vzc2FyeSBmb3IgYXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gb2YgdGhlIG90aGVyIHBvdGVudGlhbGx5DQo+PiBjb25zdHJh aW5lZCBlbmRwb2ludCwgaW5jbHVkaW5nIHdyYXBwZWQga2V5cy9zZWN1cml0eSBjb250ZXh0cywN Cj4+Y3JlZGVudGlhbHMNCj4+IHN1Y2ggYXMgcHVibGljIGtleXMgb3IgY2VydGlmaWNhdGVzIG9y IG90aGVyIGFzc2VydGlvbnMuDQo+PiANCj4+IA0KPj4gQW5vdGhlciBhc3N1bXB0aW9uIHRoYXQg bWF5IGJlIGltcG9ydGFudCBoZXJlIGlzIHRoYXQgd2UgYXNzdW1lIHRoYXQgaW4NCj4+IHNvbWUg Y2FzZXMgd2UgY2FuIGFzc3VtZSBzb21lIHNlY3VyaXR5IHN0YXRlIGNhbiBiZSBrZXB0IGJldHdl ZW4gc2VuZGVyDQo+PiBhbmQgcmVjZWl2ZXIgb3ZlciBzZXZlcmFsIG1lc3NhZ2UgZXhjaGFuZ2Vz IChrZXlzLCBrZXkgaWRlbnRpZmllcnMsDQo+PiBzZXF1ZW5jZSBudW1iZXJzLCAuIC4gLikuIEkg ZG9u4oCZdCBrbm93IGlmIHlvdXIgZXhhbXBsZXMgYXNzdW1lIHNvbWUNCj4+YXNwZWN0DQo+PiBv ZiBzdGF0ZWxlc3NuZXNzPw0KPj4gDQo+PiANCj4+IEluIHRlcm1zIG9mIG1lc3NhZ2UgcHJvdGVj dGlvbiwgaGVyZSBhcmUgdGhlIHNlY3VyaXR5IGNvbnN0cnVjdHMgd2UgaGFkDQo+PmluDQo+PiBt aW5kOg0KPj4gDQo+PiBhLiBTeW1tZXRyaWMgaW50ZWdyaXR5IHByb3RlY3Rpb24gIOKAlCBlLmcu IE1BQyhzaywgbSkgYi4gU3ltbWV0cmljDQo+PiBlbmNyeXB0aW9uICsgc3ltbWV0cmljIGludGVn cml0eSBwcm90ZWN0aW9uIOKAlCBlLmcuIEFFQUQoc2ssIG0pIGMuDQo+PiBBc3ltbWV0cmljIGlu dGVncml0eSBwcm90ZWN0aW9uIOKAlCBlLmcuIFNpZ24oUHJLLCBtKSBkLiBTeW1tZXRyaWMNCj4+ ZW5jcnlwdGlvbg0KPj4gKyBhc3ltbWV0cmljIGludGVncml0eSBwcm90ZWN0aW9uIOKAlCBlLmcu IEFFUyhzaywgbSk7IFNpZ24oUHJLLCBBRVMoc2ssDQo+Pm0pKQ0KPj4gDQo+PiBzaz1zeW1tZXRy aWMga2V5LCBtPW1lc3NhZ2UsIFBySz1wcml2YXRlIGtleSwgUEs9cHVibGljIGtleQ0KPj4gDQo+ PiBXZSBhc3N1bWUgaW4gYWxsIHRoZXNlIGNvbnN0cnVjdHMgdGhhdCB0aGUga2V5cyB1c2VkIGFy ZQ0KPj5wcmUtZXN0YWJsaXNoZWQsIG9yDQo+PiB0aGF0IG5ldyBzeW1tZXRyaWMga2V5cyBjYW4g YmVjb21lIGVzdGFibGlzaGVkLg0KPj4gDQo+PiBJbiBvcmRlciB0byByZWZlcmVuY2UgYSBwcmUt ZXN0YWJsaXNoZWQga2V5IHdlIGFzc3VtZSB0aGVyZSBpcyBhIGtleQ0KPj4gaWRlbnRpZmllciBh c3NvY2lhdGVkIHRvIHRoZSBrZXksIGUuZy4gdXNpbmcgdGhlICJraWQiIHBhcmFtZXRlciwgb3IN Cj4+c29tZQ0KPj4gdmFyaWFudCBhbGxvd2luZyBkaXN0aW5jdGlvbiBiZXR3ZWVuIHN5bW1ldHJp Yy9hc3ltbWV0cmljIGtleSBoZXJlDQo+PiBkZW5vdGVkICJza2lkIi8iYWtpZCIuIFRoZSBpZGVu dGlmZXJzIG5lZWRlZCBkaWZmZXIgYmV0d2VlbiB0aGUgY2FzZXM6DQo+PiANCj4+IGEuIHNraWQg PSA8aWRlbnRpZmllciBvZiBzaz4NCj4+IGIuIHNraWQgPSA8aWRlbnRpZmllciBvZiBzaz4NCj4+ IGMuIGFraWQgPSA8aWRlbnRpZmllciBvZiBQSz4NCj4+IGQuIHNraWQgPSA8aWRlbnRpZmllciBv ZiBzaz4sIGFraWQgPSA8aWRlbnRpZmllciBvZiBQSz4NCj4+IA0KPj4gVG8gYWxsb3cgZXN0YWJs aXNobWVudCBvZiBuZXcgc3ltbWV0cmljIGtleXMgd2Ugc2VlIHVzZSBmb3IgdGhlDQo+PmZvbGxv d2luZw0KPj4gbWV0aG9kcyBpbiBjb21iaW5hdGlvbiB3aXRoIGEtZC4NCj4+IA0KPj4gKGkpIEFF UyhzazEsIHNrMikNCj4+IChpaSkgRW5jKFBLLCBzazIpDQo+PiAoaWlpKSBFQ0RILUVTDQo+PiAN Cj4+IChpKSBhbmQgKGlpKSBhcmUga2V5IHB1c2ggbWV0aG9kcyBiYXNlZCBvbiBrbm93biByZWNp cGllbnQga2V5IChzazEgYW5kDQo+PlBLLA0KPj4gcmVzcGVjdGl2ZWx5KS4gTWV0aG9kIChpaWkp IGFzc3VtZXMgdGhlIGluY2x1c2lvbiBvZiBzZW5kZXIgImVwayINCj4+IGhlYWRlciBwYXJhbWV0 ZXIgYW5kIHVzaW5nIGEga25vd24gc3RhdGljIERILWtleSBvZiB0aGUgcmVjZWl2ZXIgKGFuZA0K Pj4ga25vd24gS0RGIGV0Yy4pDQo+PiANCj4+IFdoZW4gdGhpcyBrZXkgZXN0YWJsaXNobWVudCBp cyBwYXJ0IG9mIGEgbWVzc2FnZSBleGNoYW5nZSBhcyBhYm92ZSwgaXQNCj4+IHJlcGxhY2VzIHRo ZSAic2tpZCIgcGFyYW1ldGVyIHVzZWQgaW4gb25lIG9mIHRoZSBtZXRob2RzIGEtZCBhYm92ZS4g SXQNCj4+IHNob3VsZCBhY3R1YWxseSByZXN1bHQgaW4gdGhlIGdlbmVyYXRpb24gb2YgYSBuZXcg a2V5IGlkZW50aWZpZXIgInNraWQiDQo+PiBmb3IgdGhlIGVzdGFibGlzaGVkIGtleSwgd2hpY2gg Y2FuIGJlIHJlZmVyZW5jZWQgaW4gbGF0ZXIgZXhjaGFuZ2VzLg0KPj4gDQo+PiBXZSBhbHNvIHNl ZSB0aGUgbmVlZCBmb3IgZXN0YWJsaXNoaW5nIGtleXMgYW5kIGtleSBpZGVudGlmaWVycyB3aXRo b3V0DQo+PiBjb21iaW5pbmcgdGhhdCB3aXRoIG90aGVyIG1lc3NhZ2UgZXhjaGFuZ2UsIGkuZS4g aW50ZWdyYXRpbmcgdGhlIGtleQ0KPj4gZXN0YWJsaXNobWVudCBtZXRob2RzIHdpdGggcmVsZXZh bnQgaW50ZWdyaXR5IHByb3RlY3Rpb24gc3VjaCBhcyBmb3INCj4+IGV4YW1wbGU6DQo+PiANCj4+ IChpKSArIGEgKGtleSB0cmFuc3BvcnQgb2Ygc3ltbWV0cmljIGtleSB3aXRoIGludGVncml0eSBw cm90ZWN0aW9uLA0KPj5iYXNlZCBvbg0KPj4gc2hhcmVkIGtleSkNCj4+IChpaSkgKyBjIChrZXkg dHJhbnNwb3J0IG9mIHN5bW1ldHJpYyBrZXkgd2l0aCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwNCj4+ YmFzZWQgb24NCj4+IGFzeW1tZXRyaWMga2V5cykNCj4+IChpaWkpICsgYSAoREgga2V5IGVzdGFi bGlzaG1lbnQgYmFzZWQgb24gc2VuZGVyIGVwaGVtZXJhbCBQSyBhbmQNCj4+cmVjZWl2ZXINCj4+ IHN0YXRpYyBQSywgYXV0aGVudGljYXRlZCB3aXRoIHNoYXJlZCBrZXkpDQo+PiANCj4+IA0KPj4g RnVydGhlciBjb21tZW50cyBpbmxpbmU6DQo+PiANCj4+IA0KPj4gDQo+PiBPbiAyMDE1LTA1LTAx IDAwOjU3LCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KPj4g DQo+PiA+SSB3YW50ZWQgdG8gdHJ5IGFuZCBsb29rIGNsb3NlciBhdCBDYXJzdGVuJ3MgY2FsbCBm b3IgbW9yZSBudW1iZXJzIGluDQo+PiA+ZGlmZmVyZW50IGFwcGxpY2F0aW9ucywgYnV0IGJlZm9y ZSBJIGNhbiBkbyB0aGF0IEkgbmVlZCB0byBmaWd1cmUgb3V0DQo+PiA+d2hhdCBhcHBsaWNhdGlv bnMgdGhlcmUgYXJlIGFuZCB3aGljaCBvbmVzIGFyZSBjdXJyZW50bHkgdGhvdWdodCB0byBiZQ0K Pj4gPm9mIGdyZWF0ZXIgaW1wb3J0YW5jZS4gIEkgaGF2ZSB0cmllZCB0byBzdGFydCBieSBsb29r aW5nIGF0IHRoZQ0KPj4gPmRpZmZlcmVudCBzZWN1cml0eSBjb25zdHJ1Y3RzIHRoYXQgbWF5IGJl IHVzZWQgZm9yIHRoZXNlIGFwcGxpY2F0aW9ucw0KPj4gPmluIHRlcm1zIG9mIHdoYXQgdGhlIG5l ZWRlZCBzZWN1cml0eSBjaGFyYWN0ZXJpc3RpY3MgYXJlLg0KPj4gPg0KPj4gPjEuIEludGVncml0 eSBiYXNlZCBvbiByZWNpcGllbnQgYXN5bW1ldHJpYyBrZXk6ICBJIGV4cGVjdCB0aGF0IHRoaXMg aXMNCj4+ID5ub3QgYSBjb21tb24gc2NlbmFyaW8gdG8gaGFwcGVuIGZvciBDb1JFIHN5c3RlbXMu ICBUaGlzIHNjZW5hcmlvDQo+PiA+cmVxdWlyZXMgdGhhdCB0aGUgc2VuZGVyIGdldCBhIGNlcnRp ZmllZCBwdWJsaWMga2V5IGZvciB0aGUgcmVjaXBpZW50DQo+PiA+YW5kIHVzZXMgdGhhdCwgYWxv bmcgd2l0aCBzb21lIGVwaGVtZXJhbCBkYXRhIGxvY2FsIHRvIGl0LCB0byBjcmVhdGUgYQ0KPj4g PnNob3J0IHRlcm0gc2hhcmVkIHNlY3JldCB1c2VkIHRvIHByb3RlY3QgdGhlIGludGVncml0eSBv ZiB0aGUgbWVzc2FnZS4NCj4+ID5UaGlzIHNjZW5hcmlvIHByb3ZpZGVzIG5vIGluZGljYXRpb24g b2Ygd2hlcmUgdGhlIGRhdGEgb3JpZ2luYXRlZCwgdGh1cw0KPj4gPml0IGNhbiBiZSB1c2VkIHRv IGNyZWF0ZSBhIG1lc3NhZ2UgZm9yIG11bHRpcGxlIHJlY2lwaWVudHMuICBBbiBleGFtcGxlDQo+ PiA+b2YgaG93IHRoaXMgd291bGQgYmUgaW1wbGVtZW50ZWQgaXMgdGhlIHVzZSBvZiBDQkMtTUFD IHdpdGggRUNESC1FUw0KPj4ga2V5DQo+PiA+YWdyZWVtZW50IHBsdXMgS0RGLg0KPj4gDQo+PiBE byB5b3UgbWVhbiAiaXQgY2FuIE5PVCBiZSB1c2VkIHRvIGNyZWF0ZSBhIG1lc3NhZ2UgZm9yIG11 bHRpcGxlDQo+PiByZWNpcGllbnRz4oCdPyBJIGRvbuKAmXQgc2VlIHRoYXQgaXQgYWN0dWFsbHkg cHJvdmlkZXMgaW50ZWdyaXR5LCBzaW5jZQ0KPj5hbnlvbmUgY291bGQNCj4+IHdyYXAgYSBzeW1t ZXRyaWMga2V5IHdpdGggdGhlIHJlY2lwaWVudCBwdWJsaWMga2V5IGFuZCByZXBsYWNlIHRoZSBN QUMuDQo+PkluDQo+PiBhbnkgY2FzZSwgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgcHJvYmFibHkgbm90 IGEgY29tbW9uIHNjZW5hcmlvLg0KPg0KPkRvIG5vdCBjb25mbGF0ZSB0aGUgY29uY2VwdHMgb2Yg aW50ZWdyaXR5IHdpdGggdGhlIG9yaWdpbmF0aW9uLiAgVGhpcw0KPm1ldGhvZCBvbmx5IHByb3Zp ZGVzIGludGVncml0eS4gIFRoZSBtZXNzYWdlIGhhcyBub3QgYmVlbiBjaGFuZ2VkIHNpbmNlDQo+ aXQgd2FzIHNlbnQuICBZb3UgaGF2ZSBubyBpZGVhIHdobyBzZW50IGl0LiAgSXQgY291bGQgYmUg c29tZWJvZHkgd2hvDQo+anVzdCBnZW5lcmF0ZWQgYW4gZXBoZW1lcmFsIGtleSBhbmQgZGlkIHRo ZSBrZXkgYWdyZWVtZW50IG9wZXJhdGlvbiBhbmQNCj5zZW50IHlvdSBhIG1lc3NhZ2UuICBUaGVy ZSBpcyBubyBuZWVkIHRvIHBvc3R1bGF0ZSBzb21lYm9keSB3aG8gY2hhbmdlZCBhDQo+bWVzc2Fn ZSB0aGF0IHRoZXkgcmVjZWl2ZWQuICBJbiB0aGlzIGNhc2UgYWxsIHlvdSBrbm93IGlzIHRoYXQg dGhlDQo+bWVzc2FnZSB3YXMgbm90IHNlbnQgc2luY2UgaXQgd2FzIGNoYW5nZWQsIG5vdCB3aG8g c2VudCBpdC4NCg0KT0suIFRoZXJlIGFyZSBvdGhlciBhc3BlY3RzIG9mIGludGVncml0eSB3aGlj aCBhcmUgc3RpbGwgbm90IHNvdXJjZSBvcmlnaW4NCmF1dGhlbnRpY2F0aW9uLCBlLmcuIHdoZXJl IHRoZSB2ZXJpZmllciBoYXMgY2FuIGFzc2VydCB0aGUgdmVyaWZpY2F0aW9uDQprZXkgYnV0IHdp dGhvdXQgYmVpbmcgYWJsZSB0byBhdXRoZW50aWNhdGUgdGhlIHByb3Zlci4gQnV0IHRoYXQgaXMg YQ0KZGlmZmVyZW50IHNldHRpbmcuDQoNCg0KDQoNCj4gVGh1cyBhIG1lc3NhZ2UgY2FuIGJlIHNl bnQgdG8gbXVsdGlwbGUgcGVvcGxlIC0gdGhleSBhbGwgY2FuIHZlcmlmeSB0aGF0DQo+dGhlIGlu dGVncml0eSBvbiB0aGUgbWVzc2FnZSBpcyBpbnRhY3QgYW5kIG5vbmUgb2YgdGhlbSBjYW4ga25v dyB3aG8gc2VudA0KPnRoZSBtZXNzYWdlLg0KDQpTaW5jZSBpbiB0aGlzIGNhc2UgdGhlIGludGVn cml0eSBpcyBiYXNlZCBvbiByZWNpcGllbnQgYXN5bW1ldHJpYyBrZXksIEkNCmFzc3VtZSB0aGVy ZSB3b3VsZCBiZSBvbmUgaW5zdGFuY2Ugb2YgcHVibGljIGtleSBlbmNyeXB0ZWQgc2VjcmV0IGZv ciBlYWNoDQpyZWNlaXZlci4gSSBkb27igJl0IHRoaW5rIHRoYXQgd2lsbCBiZSBhIGNvbW1vbiBz Y2VuYXJpbyBmb3IgaW50ZWdyaXR5Lg0KDQo+DQo+DQo+PiANCj4+IA0KPj4gPg0KPj4gPjIuIElu dGVncml0eSBhbmQgbG93LWxldmVsIG9yaWdpbmF0aW9uIGJhc2VkIG9uIGEgc2hvcnQgdGVybSBz aGFyZWQNCj4+a2V5Og0KPj4gPlVuZGVyIHRoZSBjdXJyZW50IHN5c3RlbSB0aGlzIHdvdWxkIGJl IHNldHVwIHVzaW5nIGEgRFRMUyBzZXNzaW9uIGFsb25nDQo+PiA+d2l0aCBhbiBleHRyYWN0b3Ig dG8gZXN0YWJsaXNoIHRoZSBrZXkuICBUaGUga2V5IHdvdWxkIGJlIGZvcg0KPj4gPiJzaG9ydC10 ZXJtIiB1c2UgKGkuZS4gIGhvdXJzIG5vdCBkYXlzIG9yIHdlZWtzKS4gIFRoZSBvcHRpb24gb25s eQ0KPj4gPnByb3ZpZGVzIGZvciBwb2ludC10by1wb2ludCBpbnRlZ3JpdHkgbm90IGVuZC10by1l bmQgaW50ZWdyaXR5Lg0KPj4gPkludGVncml0eSBjYW4gYmUgZm9yZ2VkIGJ5IGFueSBwYXJ0eSB0 aGF0IGtub3dzIHRoZSBzaGFyZWQtc2VjcmV0LiAgSW4NCj4+ID50aGlzIG1vZGUsIHRoZXJlIG5l ZWRzIHRvIGJlIGEgc2luZ2xlIHJlY2lwaWVudCBvZiB0aGUgbWVzc2FnZS4gIElmDQo+PiA+dGhp cyBjb25kaXRpb24gaXMgbWV0LCBvcmlnaW5hdGlvbiBpcyBzaG93biBieSBzYXlpbmcgIkkgZGlk IG5vdCBtYWtlDQo+PiA+dGhpcyBtZXNzYWdlIHNvIHRoZSBvdGhlciBwYXJ0eSBtdXN0IGhhdmUg ZG9uZSBzby4iIE9yaWdpbiBvZiB0aGUNCj4+ID5tZXNzYWdlIGNhbm5vdCBiZSBwcm92ZWQgdG8g YSB0aGlyZCBwYXJ0eS4gIEFuIGV4YW1wbGUgb2YgaG93IHRoaXMNCj4+ID53b3VsZCBiZSBpbXBs ZW1lbnRlZCBpcyB0aGUgdXNlIG9mIENCQy1NQUMgd2l0aCBkaXJlY3Qga2V5Lg0KPj4gDQo+PiBU aGlzIGNvcnJlc3BvbmRzIHRvIGEuIGFib3ZlLg0KPg0KPk5vIGl0IGRvZXMgbm90IC0gbm90IHRo ZSBhZGRpdGlvbiBvZiBvcmlnaW5hdGlvbiB0aGF0IHdhcyBtaXNzaW5nIGluIHRoZQ0KPmZpcnN0 IGNhc2UuDQoNCg0KSSB1bmRlcnN0YW5kIHlvdXIgZGlzdGluY3Rpb24uIEluIGVzc2VuY2Ugd2Ug bWFrZSBkaWZmZXJlbnQgYXNzdW1wdGlvbnMNCmhvdyB0aGUgZGlyZWN0IGtleSB3YXMgZXN0YWJs aXNoZWQuIFlvdSBhc3N1bWUgRFRMUyBoYXZlIGJlZW4gcnVuLiBJbiBteQ0KdGV4dCBJIG9ubHkg YXNzdW1lIHRoYXQgdGhlcmUgaXMgYSBrZXkgaWRlbnRpZmllciBhc3NvY2lhdGVkIHRvIHRoZSBr ZXkNCmFuZCB0aGV5IGFyZSBib3RoIGtub3duIHRvIHRoZSB2ZXJpZmllci4gSG93IHRoZSBrZXkg d2FzIGVzdGFibGlzaGVkIGFuZA0Kd2hldGhlciB0aGUga2V5IGhvbGRlciB3YXMgYXV0aGVudGlj YXRlZCBpcyBsZWZ0IG9wZW4uIEluIGJvdGggYSBhbmQgMiB3ZQ0KYWdyZWUgdGhhdCB0aGlzIGlz IGltcGxlbWVudGVkIHVzaW5nIGEgTUFDLiBXaHkgZG9lcyBpdCBtYXR0ZXIgZm9yIHRoZQ0KZm9y bWF0IGhvdyB0aGUga2V5IHdhcyBlc3RhYmxpc2hlZD8NCg0KPg0KPj4gDQo+PiA+DQo+PiA+My4g IEludGVncml0eSBhbmQgbG93LWxldmVsIG9yaWdpbmF0aW9uIGJhc2VkIG9uIGEgbG9uZyB0ZXJt IHNoYXJlZA0KPj5rZXk6DQo+PiA+VW5kZXIgdGhlIGN1cnJlbnQgc3lzdGVtIHRoaXMgd291bGQg YmUgc2V0dXAgdXNpbmcgYSBwYWlyLXdpc2Uga2V5DQo+PiA+ZXN0YWJsaXNoZWQgYmV0d2VlbiB0 d28gZW50aXRpZXMuICBUaGUga2V5IHdvdWxkIGJlIGZvciAibG9uZy10ZXJtIiB1c2UNCj4+ID4o aS5lLiAgd2Vla3Mgb3IgbW9udGhzKS4gIEdpdmVuIHRoYXQgdGhpcyBpcyBhIGxvbmcgdGVybSB1 c2VkIGtleSwgdGhlDQo+PiA+cHJvYmxlbSBvZiByZXBsYXkgYW5kIHBvdGVudGlhbCBmb3JnZXJp ZXMgaXMgZ3JlYXRlci4gICBGb3IgdGhpcw0KPj5yZWFzb24sDQo+PiA+c29tZSB0eXBlIG9mIGtl eSBkZXJpdmF0aW9uIG9uIHRoZSBzaGFyZWQgc2VjdXJpdHkgd291bGQgYmUgc3VnZ2VzdGVkLg0K Pj4gPlRoZSBvcHRpb24gb25seSBwcm92aWRlcyBmb3IgZW5kLXRvLWVuZCBpbnRlZ3JpdHkgYmV0 d2VlbiB0aGUgcGFydGllcy4NCj4+ID5JbnRlZ3JpdHkgY2FuIGJlIGZvcmdlZCBieSBhbnkgcGFy dHkgdGhhdCBrbm93cyB0aGUgc2hhcmVkLXNlY3JldC4gIEluDQo+PiA+dGhpcyBtb2RlLCB0aGVy ZSBuZWVkcyB0byBiZSBhIHNpbmdsZSByZWNpcGllbnQgb2YgdGhlIG1lc3NhZ2UuICBJZg0KPj4g PnRoaXMgY29uZGl0aW9uIGlzIG1ldCwgb3JpZ2luYXRpb24gaXMgc2hvd24gYnkgc2F5aW5nICJJ IGRpZCBub3QgbWFrZQ0KPj4gPnRoaXMgbWVzc2FnZSBzbyB0aGUgb3RoZXIgcGFydHkgbXVzdCBo YXZlIGRvbmUgc28uIiBPcmlnaW4gb2YgdGhlDQo+PiA+bWVzc2FnZSBjYW5ub3QgYmUgcHJvdmVk IHRvIGEgdGhpcmQgcGFydHkuICBBbiBleGFtcGxlIG9mIGhvdyB0aGlzDQo+PiA+d291bGQgYmUg aW1wbGVtZW50ZWQgaXMgdGhlIHVzZSBvZiBDQkMtTUFDIHdpdGggZGlyZWN0IGtleSBwbHVzIEtE Ri4NCj4+IA0KPj4gSSBzZWUgdGhpcyBhcyBhIG1pbm9yIHZhcmlhbnQgb2YgMi4gSSBhc3N1bWUg dGhlcmUgd2lsbCBiZSBzb21lDQo+PmFsZ29yaXRobQ0KPj4gaWRlbnRpZmllciB0aGF0IGNvdWxk IG9wdGlvbmFsbHkgcmVmZXJlbmNlIGEgS0RGLCBhbmQgaWYgaXQgZG9lcyB0aGVuDQo+Pml0IGlz IGNhc2UNCj4+IDMgb3RoZXJ3aXNlIGNhc2UgMi4gT3Igd2hhdCBlbHNlIGlzIHRoZSBkaWZmZXJl bmNlPw0KPg0KPlRoZSBkaWZmZXJlbmNlIGhlcmUgaXMgYSBxdWVzdGlvbiBvZiBob3cgbG9uZyBv bmUgY2FuIHVzZSBhIHNpbmdsZSBzaGFyZWQNCj5rZXkgd2l0aG91dCBoYXZpbmcgcHJvYmxlbXMg YW5kIGhvdyB0byBpbmNyZWFzZSB0aGF0IHRpbWUgcGVyaW9kLiAgSWYgeW91DQo+anVzdCBnb3Qg YSBuZXcga2V5IGZyb20gYSBrZXkgYWdyZWVtZW50IG9wZXJhdGlvbiwgdGhlbiB5b3UgY2FuIHVz ZSBpdA0KPmZvciBhIHdoaWxlLiAgT24gdGhlIG90aGVyIGhhbmQgaWYgeW91IGhhdmUgYSBrZXkg d2hpY2ggaXMgaGFyZCBjb2RlZA0KPmludG8gdGhlIGRldmljZSwgaXQgbWFrZXMgc2Vuc2UgdG8g c2VuZCBtZXNzYWdlcyB3aGljaCBhcmUgbm90IGVuY29kZWQNCj53aXRoIHRoYXQga2V5IGJ1dCB3 aXRoIGEgc2VjcmV0IGRlcml2ZWQgZnJvbSB0aGF0IGtleS4gIFRoaXMgbWVhbnMgdGhhdA0KPmNv bXByb21pc2Ugb2YgdGhlIGtleSBpcyBhIHR3byBvcGVyYXRpb24gcmV2ZXJzYWwgcmF0aGVyIHRo YW4gYSBzaW5nbGUNCj5vcGVyYXRpb24gcmV2ZXJzYWwuICBCb3RoIHRoZSBpbnRlZ3JpdHkgb24g dGhlIG1lc3NhZ2UgYW5kIHRoZSBLREYgbmVlZA0KPnRvIGJlIHJldmVyc2VkLg0KDQpZZXMgSSBh Z3JlZSB3aXRoIHRoYXQuIFdoYXQgSSB0aG91Z2h0IHRoYXQgY291bGQgYmUgaW1wbGljaXQgaW4g dGhlIGNpcGhlcg0Kc3VpdGUgZGVmaW5pdGlvbi4gQWdhaW4gSSBkb27igJl0IHNlZSBob3cgaXQg aW1wYWN0cyB0aGUgZm9ybWF0Lg0KDQo+DQo+PiANCj4+IA0KPj4gPg0KPj4gPjQuICBJbnRlZ3Jp dHkgYW5kIGxvdy1sZXZlbCBvcmlnaW5hdGlvbiBiYXNlZCBvbiB0d28gYXN5bW1ldHJpYyBrZXlz Og0KPj4gPlRoaXMgc2NlbmFyaW8gcmVxdWlyZXMgdGhhdCBib3RoIHRoZSByZWNpcGllbnQgYW5k IHNlbmRlciBvZiB0aGUNCj4+ID5tZXNzYWdlIGhhdmUgd2VsbCBrbm93biBrZXkgYWdyZWVtZW50 IGtleXMuICBCb3RoIGVudGl0aWVzIG11c3QgYmUgYWJsZQ0KPj4gPnRvIGdldCB0aGVzZSBlaXRo ZXIgZnJvbSBhIHRydXN0ZWQgdGhpcmQgcGFydHkgb3Igb3ZlciBzb21lIHR5cGUgb2YNCj4+ID5w cm90b2NvbCB0aGF0IGluY2x1ZGVzIGRvaW5nIGEgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBjaGVjayBv biBib3RoIHNpZGVzLg0KPj4gPk9uY2UgdGhpcyBpcyBkb25lLCBhIG9uZS10aW1lIHNoYXJlZCBz ZWN1cml0eSBpcyBnZW5lcmF0ZWQgdGhhdCBpcyB1c2VkDQo+PiA+dG8gcHJvdmlkZSBib3RoIGVu ZC10by1lbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gYW5kIGEgZGVncmVlIG9mDQo+Pm9yaWdpbmF0 aW9uDQo+PiBrbm93bGVkZ2UuDQo+PiA+T3JpZ2luYXRpb24gb2YgdGhlIG1lc3NhZ2UgY2Fubm90 IGJlIHByb3ZlZCB0byBhIHRoaXJkIHBhcnR5LiAgQm90aA0KPj4gPnBhcnRpZXMgbXVzdCBoYXZl IGEga2V5IHRoYXQgaXMgaW4gdGhlIHNhbWUgZ3JvdXAuICBBIHVuaXF1ZW5lc3MgdmFsdWUNCj4+ ID5tdXN0IGJlIGludGVyamVjdGVkIGludG8gdGhlIGtleSBhZ3JlZW1lbnQgcHJvY2VzcyBieSBh dCBsZWFzdCBvbmUgb2YNCj4+ID50aGUgcGFydGllcy4NCj4+ID5JdCBpcyBzdWZmaWNpZW50IHRo YXQgYSBjb3VudGVyIGJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZXMsIGl0IGlzIG5vdA0KPj4gPm5l Y2Vzc2FyeSBmb3IgdGhpcyB2YWx1ZSB0byBiZSByYW5kb20uICBBbiBleGFtcGxlIG9mIGhvdyB0 aGlzIHdvdWxkIGJlDQo+PiA+aW1wbGVtZW50ZWQgaXMgdGhlIHVzZSBvZiBDQkMtTUFDIHdpdGgg YSBFQ0RILVNTIGtleSBhZ3JlZW1lbnQgcGx1cw0KPj4gS0RGLg0KPj4gDQo+PiBJIGRvbuKAmXQg c2VlIGhvdyB0aGlzIG9yIDkuIGFkZHMgbXVjaCB0byB0aGUgc2V0dGluZyB3ZSBsb29rIGF0Lg0K Pj4gDQo+PiBFaXRoZXIgdGhlcmUgaXMgYSBzaGFyZWQgc2VjcmV0IGJldHdlZW4gdGhlIHNlbmRl ciBhbmQgcmVjZWl2ZXIuIFRoZW4NCj4+dGhlcmUNCj4+IGlzIG5vIG5lZWQgdG8gZG8gYSBEaWZm aWUtSGVsbG1hbiB0byBkZXJpdmUgYSBmcmVzaCBzaGFyZWQgc2VjcmV0LCBhIEtERg0KPj4gd291 bGQgZG8uIE9yLCB0aGUgcHVibGljIGtleSBvZiB0aGUgc2VuZGVyIGlzIG5vdCBrbm93biB0byB0 aGUNCj4+cmVjZWl2ZXIsIGFuZA0KPj4gdGhlbiB0aGlzIHNlZW1zIHRvIGJlIHZlcnkgc2ltaWxh ciB0byBFQ0RILUVTICg2LiBiZWxvdykuDQo+DQo+VGhlIGFzc3VtcHRpb24gaW4gdGhpcyBjYXNl IGlzIHRoYXQgb25lIGRvZXMga25vdyB0aGUgcHVibGljIGtleSBvZiB0aGUNCj5yZWNpcGllbnQg LSBlaXRoZXIgaXQgaXMgaGFyZCBjb2RlZCBpbiB0aGUgc3lzdGVtIG9yIHRoZXJlIGlzIGEgbWV0 aG9kIG9mDQo+cXVlcnlpbmcgZm9yIGl0LiAgSXQgaXMgcXVpdGUgcG9zc2libGUgdGhhdCB0aGlz IGlzIG5vdCBhIGNvbW1vbmx5IHVzZWQNCj5zY2VuYXJpby4NCg0KVGhpcyBpcyBhIGNhc2Ugd2hl cmUgdGhlIHRydXN0ZWQgdGhpcmQgcGFydHkgKGF1dGhvcml6YXRpb24gc2VydmVyKSBpbiB0aGUN CkFDRSBhcmNoaXRlY3R1cmUgc2hvdWxkIHN0ZXAgaW4gYW5kIHN1cHBvcnQgdGhlIGF1dGhlbnRp Y2F0aW9uIHByb2Nlc3MgYnkNCnByb3ZpZGluZyB0aGUgcmVjaXBpZW50IHB1YmxpYyBrZXkgdG8g dGhlIHNlbmRlciAoYXMgdGhlbiB3b3VsZCBuZWVkIHRvIGJlDQpzcGVjaWZpZWQgaW4gQUNFKS4N Cg0KDQo+DQo+PiANCj4+IA0KPj4gPg0KPj4gPjUuIEludGVncml0eSBhbmQgaGlnaC1sZXZlbCBv cmlnaW5hdGlvbiBiYXNlZCBvbiBzZW5kZXIgYXN5bW1ldHJpYyBrZXk6DQo+PiA+VGhpcyBzY2Vu YXJpbyByZXF1aXJlcyB0aGF0IGEgdHJ1ZSBzaWduYXR1cmUgYWxnb3JpdGhtIGJlIGRlZmluZWQg YW5kDQo+PiA+dXNlZCBhcyB3ZWxsIGFzIHRoZSBhYmlsaXR5IGZvciBhIHJlY2lwaWVudCB0byBx dWVyeSBhIHRydXN0ZWQgdGhpcmQNCj4+ID5wYXJ0eSB0aGF0IHRoZSBiaW5kaW5nIG9mIGlkZW50 aXR5IGFuZCBwdWJsaWMga2V5IGlzIHRydWUuICBVc2luZyB0aGlzDQo+PiA+YWxsb3dzIGZvciB0 aGUgb3JpZ2luYXRpb24gYW5kIGludGVncml0eSBvZiBhIG1lc3NhZ2UgdG8gYmUgcHJvdmVkIHRv IGENCj4+ID50aGlyZCBwYXJ0eSwgdGhlIHNpZ25hdHVyZSBpcyBub3QgZGlyZWN0ZWQgYXQgYW55 IHNwZWNpZmljIHBhcnR5LiAgQW4NCj4+ID5leGFtcGxlIG9mIGhvdyB0aGlzIHdvdWxkIGJlIGlt cGxlbWVudGVkIGlzIHRoZSB1c2Ugb2YgRUNEU0Egd2l0aCBTSEEtDQo+PiAyNTYuDQo+PiANCj4+ IFRoaXMgY29ycmVzcG9uZHMgdG8gYy4gYWJvdmUNCj4+IA0KPj4gPg0KPj4gPjYuICBDb25maWRl bnRpYWxpdHkgYW5kIGludGVncml0eSBiYXNlZCBvbiByZWNpcGllbnQgYXN5bW1ldHJpYyBrZXk6 DQo+PiA+VGhpcyBzY2VuYXJpbyBzaGFyZXMgbW9zdCBvZiB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5 IGFzIGRvZXMgc2NlbmFyaW8gMS4NCj4+ID5UaGUgcmVxdWlyZWQgaW50ZWdyaXR5IGNhbiBiZSBv YnRhaW5lZCBieSB0aGUgdXNlIG9mIGFuIEFFQUQgYWxnb3JpdGhtDQo+PiA+cmF0aGVyIHRoYW4g YSBNQUMgYWxnb3JpdGhtLiAgQW4gZXhhbXBsZSBvZiBob3cgdGhpcyB3b3VsZCBiZQ0KPj4gPmlt cGxlbWVudGVkIGlzIHRoZSB1c2Ugb2YgQUVTLUNDTSB3aXRoIEVDREgtRVMga2V5IGFncmVlbWVu dCBwbHVzDQo+PiBLREYuDQo+PiANCj4+IFRoaXMgaXMgKGlpaSkgKyBiLiBhYm92ZQ0KPg0KPk5v dGUgLSB0aGlzIGNhc2UgZG9lcyBub3QgdGVsbCB5b3Ugd2hvIHNlbnQgdGhlIG1lc3NhZ2UgLSBu b3RlIHRoZQ0KPmFic2VuY2Ugb2Ygb3JpZ2luYXRpb24gZnJvbSB0aGUgdGl0bGUuICBUaGlzIGlz IHRoZSByZWFzb24gZm9yIGRvaW5nDQo+RUNESC1TUyBpbnN0ZWFkLg0KDQpJIGFncmVlIHdpdGgg eW91ciBkaXN0aW5jdGlvbi4gU2FtZSBxdWVzdGlvbiBhcyBhYm92ZSBhYm91dCB3aHkgaXQgbWF0 dGVycw0KaG93IHRoZSBrZXkgd2FzIGVzdGFibGlzaGVkLg0KDQo+DQo+PiANCj4+ID4NCj4+ID43 LiAgQ29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIGxvdy1sZXZlbCBvcmlnaW5hdGlvbiBi YXNlZCBvbiBhDQo+PiA+c2hvcnQgdGVybSBzaGFyZWQga2V5OiBUaGlzIHNjZW5hcmlvIHNoYXJl cyBtb3N0IG9mIHRoZSBzYW1lDQo+PiA+ZnVuY3Rpb25hbGl0eSBhcyBkb2VzDQo+PiA+c2NlbmFy aW8gMi4gICBUaGUgcmVxdWlyZWQgaW50ZWdyaXR5IGNhbiBiZSBvYnRhaW5lZCBieSB0aGUgdXNl IG9mIGFuDQo+PkFFQUQNCj4+ID5hbGdvcml0aG0gcmF0aGVyIHRoYW4gYSBNQUMgYWxnb3JpdGht ICBBbiBleGFtcGxlIG9mIGhvdyB0aGlzIHdvdWxkIGJlDQo+PiA+aW1wbGVtZW50ZWQgaXMgdGhl IHVzZSBvZiBBRVMtQ0NNIHdpdGggZGlyZWN0IGtleS4NCj4+IA0KPj4gVGhpcyBjb3JyZXNwb25k cyB0byBiLiBhYm92ZS4NCj4+IA0KPj4gPg0KPj4gPjguIENvbmZpZGVudGlhbGl0eSwgaW50ZWdy aXR5IGFuZCBsb3ctbGV2ZWwgb3JpZ2luYXRpb24gYmFzZWQgb24gYSBsb25nDQo+PiA+dGVybSBz aGFyZWQga2V5OiAgVGhpcyBzY2VuYXJpbyBzaGFyZXMgbW9zdCBvZiB0aGUgc2FtZSBmdW5jdGlv bmFsaXR5DQo+PiA+YXMgZG9lcyBzY2VuYXJpbyAzLiAgVGhlIHJlcXVpcmVkIGludGVncml0eSBj YW4gYmUgb2J0YWluZWQgYnkgdGhlIHVzZQ0KPj4gPm9mIGFuIEFFQUQgYWxnb3JpdGhtIHJhdGhl ciB0aGFuIGEgTUFDIGFsZ29yaXRobS4gIEFuIGV4YW1wbGUgb2YgaG93DQo+PiA+dGhpcyB3b3Vs ZCBiZSBpbXBsZW1lbnRlZCBpcyB0aGUgdXNlIG9mIEFFUy1DQ00gd2l0aCBkaXJlY3Qga2V5IHBs dXMNCj4+ID5LREYuDQo+PiANCj4+IEFnYWluIGEgbWlub3IgdmFyaWFudCBvZiA3Lg0KPj4gDQo+ PiA+DQo+PiA+OS4gQ29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIGxvdy1sZXZlbCBvcmln aW5hdGlvbiBiYXNlZCBvbiB0d28NCj4+ID5hc3ltbWV0cmljIGtleXM6ICBUaGlzIHNjZW5hcmlv IHNoYXJlcyBtb3N0IG9mIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkNCj4+YXMNCj4+ID5kb2VzIHNj ZW5hcmlvIDQuICAgIFRoZSByZXF1aXJlZCBpbnRlZ3JpdHkgY2FuIGJlIG9idGFpbmVkIGJ5IHRo ZSB1c2UNCj4+b2YNCj4+ID5hbg0KPj4gPkFFQUQgYWxnb3JpdGhtIHJhdGhlciB0aGFuIGEgTUFD IGFsZ29yaXRobS4gIEFuIGV4YW1wbGUgb2YgaG93IHRoaXMNCj4+ID53b3VsZCBiZSBpbXBsZW1l bnRlZCBpcyB0aGUgdXNlIG9mIEFFUy1DQ00gd2l0aCBFQ0RILVNTIGtleQ0KPj4gYWdyZWVtZW50 DQo+PiA+cGx1cyBLREYuDQo+PiANCj4+IFNlZSBzY2VuYXJpbyA0IGFib3ZlDQo+PiANCj4+ID4N Cj4+ID4xMC4gQ29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIGhpZ2gtbGV2ZWwgb3JpZ2lu YXRpb24gYmFzZWQgb24NCj4+ID5zZW5kZXIgYXN5bW1ldHJpYyBrZXk6ICBUaGlzIHNjZW5hcmlv IHNoYXJlcyB0aGUgaW50ZWdyaXR5IGFuZA0KPj4gPm9yaWdpbmF0aW9uIHJlcXVpcmVtZW50cyBv ZiBzY2VuYXJpbyA1LCBob3dldmVyIHRoZSBhbGdvcml0aG0gY2hvaWNlDQo+PiA+dGhlcmUgZG9l cyBub3QgcHJvdmlkZSBhbiBjb25maWRlbnRpYWxpdHkuICBBIGRpZmZlcmVudCBjb25maWRlbnRp YWxpdHkNCj4+ID5tZWNoYW5pc20gbXVzdCBiZSB1c2VkLiAgQW55IG9mIHRoZSBtZXRob2RzIHVz ZWQgaW4gc2NlbmFyaW9zIDUtOSBjb3VsZA0KPj4gPmJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZS4g IEdldHRpbmcgYm90aCBzZXRzIG9mIGZ1bmN0aW9uYWxpdHkgd2lsbA0KPj4gPnJlcXVpcmVkIHRo ZSB1c2Ugb2YgYSB3cmFwcGVkIG1lc3NhZ2Ugc2NlbmFyaW8gd2hlcmUgdGhlIHNpZ25lZA0KPj4g bWVzc2FnZQ0KPj4gPmlzIHdyYXBwZWQgaW5zaWRlIG9mIGFuIGVuY3J5cHRlZCBtZXNzYWdlLiAg KEF0dGVtcHRpbmcgdG8gZG8gYm90aCBpbg0KPj4gPnRoZSBzYW1lIG1lc3NhZ2Ugd2FzIHJlbW92 ZWQgYmV0d2VlbiBQS0NTICM3IGFuZCBDTVMgZHVlIHRvIHNlY3VyaXR5DQo+PiA+Zmxhd3MuICBJ dCB3YXMgcG9zc2libGUgdG8gYm90aCBkZXRlcm1pbmUgd2hvIHRoZSBtZXNzYWdlIHNpZ25lciB3 YXMNCj4+ID5hbmQgdG8gZG8gdHJhZmZpYyBhbmFseXNpcyBvbiB0aGUgY29udGVudCBvZiB0aGUg bWVzc2FnZSBieSBsb29raW5nIGF0DQo+PiA+dGhlIGhhc2ggb2YgdGhlIHJlc3VsdGluZyBzaWdu YXR1cmUuKQ0KPj4gDQo+PiANCj4+IFdlIGFyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlrZSBk LiBhYm92ZS4gSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZw0KPj4gZGlmZmVyZW50PyBUaGUgY29t bWVudCBhYm91dCBzZWN1cml0eSBmbGF3IGluIFBLQ1MjNyBzZWVtcyBmcm9tIHlvdXINCj4+IHNo b3J0IGV4cGxhbmF0aW9uIHRvIHJlbGF0ZSB0byBzaWduLXRoZW4tZW5jcnlwdCwgaXMgdGhlcmUg YWxzbyBhbg0KPj5pc3N1ZSB3aXRoDQo+PiBlbmNyeXB0LXRoZW4tc2lnbj8NCj4NCj5ObyAtIG15 IG5vdGUgcmVsYXRlcyB0byBzaWduLWFuZC1lbmNyeXB0LiAgSXQgaXMgbm90IGEgcHJvYmxlbSBo ZXJlIGZvcg0KPmVpdGhlciBzaWduLXRoZW4tZW5jcnlwdCBvciBlbmNyeXB0LXRoZW4tc2lnbi4g IERlcGVuZGluZyBvbiB3aGF0IHlvdQ0KPndhbnQgdG8gZG8gd2l0aCB0aGUgbWVzc2FnZSwgc2ln bi10aGVuLWVuY3J5cHQgaXMgYSBiZXR0ZXIgdGhpbmcgdG8gZG8uDQo+Tm90ZSBzaW5jZSB0aGlz IGlzIGFzeW1tZXRyaWMgaXQgaXMgbm90IHRoZSBzYW1lIGlzc3VlIGFzIHRoZQ0KPk1BQy10aGVu LWVuY3J5cHQgaXNzdWVzIHRoYXQgVExTIGhhcy4NCg0KQ291bGQgeW91IHBsZWFzZSBleHBsYWlu IG9yIHByb3ZpZGUgYSBwb2ludGVyIHRvIHNvbWUgcmVmZXJlbmNlIHdoYXQgaXMNCnRoZSBwcm9i bGVtIHdpdGggZCBhbmQgd2h5IHNpZ24tdGhlbi1lbmNyeXB0IHdvdWxkIGJlIGJldHRlcj8NCg0K VGhhbmtzDQpHw7ZyYW4NCg0KPg0KPj4gDQo+PiBBIGNvbWJpbmF0aW9uIG9mIDcgYW5kIDUgaXMg YW4gb3B0aW9uIHRvIGQsIGJ1dCByZXBsYWNpbmcgYW4gQUVBRCB3aXRoDQo+PkFFUw0KPj4gcHJv YmFibHkgYmUgbW9yZSBvcHRpbWFsLg0KPj4gDQo+PiANCj4+ID4NCj4+ID5XaGljaCBvZiB0aGVz ZSB0ZW4gc2NlbmFyaW9zIGRvIHdlIGJlbGlldmUgYXJlIGdvaW5nIHRvIGJlIGNvbW1vbmx5DQo+ PiB1c2VkPw0KPj4gPldoYXQgcGVyY2VudGFnZSBvZiB0aGUgdGltZSBkbyB3ZSB0aGluayB0aGVz ZSBvcHRpb25zIGFyZSBnb2luZyB0byBiZQ0KPj4gPnVzZWQ/DQo+PiANCj4+IEl0IGlzIGRpZmZp Y3VsdCB0byBwcmVkaWN0LCBidXQgSSB3b3VsZCBleHBlY3QgdGhlIG1lc3NhZ2VzIHJlbGF0ZWQg dG8NCj4+IGludGVyYWN0aW9uIGJhc2VkIG9uIGV4aXN0aW5nIGtleXMgKEEpIHdvdWxkIGJlIG1v cmUgcHJldmFsZW50IHRoYW4gdGhlDQo+PiBtZXNzYWdlIHJlbGF0ZWQgdG8gY29udHJvbCBpbmZv cm1hdGlvbiBhbmQgZXN0YWJsaXNobWVudCBvZiBrZXlzIChCKS4NCj4+IEZ1cnRoZXIgdGhhdCBw b2ludC10by1wb2ludCBtZXNzYWdlcyB3b3VsZCBiZSBtb3JlIHByZXZhbGVudCB0aGFuIHBvaW50 LQ0KPj4gdG8tbXVsdGlwb2ludC4gSGVuY2UgdGhlIG1vc3QgY29tbW9uIHdvdWxkIGJlIGEuIGFu ZCBiLiwgZm9sbG93ZWQgYnkgYy4NCj4+IGFuZCBkLiwgZm9sbG93ZWQgYnkgKGkpLShpaWkpIGlu IGNvbWJpbmF0aW9uIHdpdGggYS1kLg0KPj4gDQo+PiBHw7ZyYW4NCj4+IA0KPj4gPlRoaXMgd2ls bCBnaXZlIHVzIHNvbWUgc3RhcnRpbmcgZGF0YSB0byBsb29rIGF0IHdoaWNoIHN0cnVjdHVyZXMg YXJlDQo+PiA+Z29pbmcgdG8gYmUgdGhlIG1vc3QgY29tbW9ubHkgdXNlZCBhbmQgZ2V0IGEgc3Rh cnQgb24gd2hpY2ggZmllbGRzIGluDQo+PiA+dGhlIHN0cnVjdHVyZXMgYXJlIGdvaW5nIHRvIGJl IHByZXNlbnQuICBUaGVyZSB3aWxsIGJlIHNvbWUgZm9sbG93IG9uDQo+PiA+cXVlc3Rpb25zIHRv IHRyeSBhbmQgbWFrZSB0aGlzIGRldGVybWluYXRpb24uDQo+PiA+DQo+PiA+SmltDQo+PiA+DQo+ PiA+DQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID5Db3NlIG1haWxpbmcgbGlzdA0KPj4gPkNvc2VAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCj4NCg0K From nobody Thu May 7 01:16:27 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD671B2F56; Thu, 7 May 2015 01:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzCdSWNH44kn; Thu, 7 May 2015 01:16:24 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D873D1B2F59; Thu, 7 May 2015 01:16:21 -0700 (PDT) Received: by layy10 with SMTP id y10so25048163lay.0; Thu, 07 May 2015 01:16:20 -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=teCKepUGGPlduFkTKZJsngibYdnqqSbILouO6SCvqfk=; b=SctmIC+lpomXQ3OazGY9vuFNZ4vCgKDBYV5KPOKMWG7ATA2jwBINAczcnfhHvBfkAf maHFD6rrK1b5ZTOd6eQJhAyE56EhpHrxyN1o7SkU87zU9w733pIPQUO/oRCH8KppOaMo uczK/3bq8ZXTzPsmRNM/1oIFQDC6ECDcsjqK6BhNwRTuhKyXsJCQkrWkq9dYalYLQU/0 evrYbqchBojR5ngtg7aylxgJX2svk9HWeuWdp3qO/+pRTMKqSm6ffxMEWhyWZiRppok0 Jo3vetUocM2plPtb80wP+MPsGoifImtMGrmrEWJPUH5+6Ecxpc7cHJM4oAkHTbp5ZtwY IljA== MIME-Version: 1.0 X-Received: by 10.112.199.133 with SMTP id jk5mr2185866lbc.32.1430986580370; Thu, 07 May 2015 01:16:20 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 7 May 2015 01:16:20 -0700 (PDT) In-Reply-To: <56BE4DD7-DE1F-4D58-80B9-AE5E26A53263@vpnc.org> References: <20150428143033.5998.43672.idtracker@ietfa.amsl.com> <56BE4DD7-DE1F-4D58-80B9-AE5E26A53263@vpnc.org> Date: Thu, 7 May 2015 04:16:20 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c264becd28d60515798606 Archived-At: Cc: Stephen Farrell , Kepeng Li , The IESG , "cose@ietf.org" Subject: Re: [Cose] Stephen Farrell's Block on charter-ietf-cose-00-00: (with BLOCK and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:16:25 -0000 --001a11c264becd28d60515798606 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 29, 2015 at 11:46 AM, Paul Hoffman wrote: > On Apr 29, 2015, at 8:41 AM, Kepeng Li wrote: > >> The milestone dates are nonsense. I'll buy the chairs a > >> beverage if they happen though. It is fine if folks want > >> to believe those dates though. > > > > > > I checked the other charters, usually they put one year between > submitting > > a document as WG item and submitting a document to the IESG. > > > > Also we need a F2F meeting to discuss the drafts before adopting them, so > > I propose to change June to July. > > > > How about this: > > > > OLD: > > Jan 2016 Submit COSE constrained-appropriate algorithms to the IESG, for > > publication as a Proposed Standard > > Jan 2016 Submit COSE specification to the IESG, for publication as a > > Proposed Standard > > Jun 2015 Submit COSE constrained-appropriate algorithms as a WG item > > Jun 2015 Submit COSE specification as a WG item > > > > > > NEW: > > Jul 2016 Submit COSE constrained-appropriate algorithms to the IESG, for > > publication as a Proposed Standard > > Jul 2016 Submit COSE specification to the IESG, for publication as a > > Proposed Standard > > Jul 2015 Submit COSE constrained-appropriate algorithms as a WG item > > Jul 2015 Submit COSE specification as a WG item > > This was meant to be a short-lived WG for two focused items; it should not > take a year to do this. Stephen might be right and we miss the goal of > finishing this year, but I'd like to make him buy someone a beverage. > Please do reach this goal, I'd appreciate the win ;-) > > I also disagree that we need a F2F meeting on this at all. The mailing > list is already working well on the early hard questions. If we can meet at > an IETF meeting, great. If we need additional meetings, we can have a > virtual interim. Please: let's not make this a "reason to travel" WG. > Meeting F2F is fine, we won't set any restrictions/expectations on that up front. Thanks, Kathleen > > --Paul Hoffman > -- Best regards, Kathleen --001a11c264becd28d60515798606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 29, 2015 at 11:46 AM, Paul Hoffman <paul.hoffman@vpnc.= org> wrote:
On Apr 29, 2015, at 8:41 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:
>> The milestone dates are nonsense. I'll buy the chairs a
>> beverage if they happen though. It is fine if folks want
>> to believe those dates though.
>
>
> I checked the other charters, usually they put one year between submit= ting
> a document as WG item and submitting a document to the IESG.
>
> Also we need a F2F meeting to discuss the drafts before adopting them,= so
> I propose to change June to July.
>
> How about this:
>
> OLD:
> Jan 2016 Submit COSE constrained-appropriate algorithms to the IESG, f= or
> publication as a Proposed Standard
> Jan 2016 Submit COSE specification to the IESG, for publication as a > Proposed Standard
> Jun 2015 Submit COSE constrained-appropriate algorithms as a WG item > Jun 2015 Submit COSE specification as a WG item
>
>
> NEW:
> Jul 2016 Submit COSE constrained-appropriate algorithms to the IESG, f= or
> publication as a Proposed Standard
> Jul 2016 Submit COSE specification to the IESG, for publication as a > Proposed Standard
> Jul 2015 Submit COSE constrained-appropriate algorithms as a WG item > Jul 2015 Submit COSE specification as a WG item

This was meant to be a short-lived WG for two focused items; it shou= ld not take a year to do this. Stephen might be right and we miss the goal = of finishing this year, but I'd like to make him buy someone a beverage= .

Please do reach this goal, I'd ap= preciate the win ;-)=C2=A0

I also disagree that we need a F2F meeting on this at all. The mailing list= is already working well on the early hard questions. If we can meet at an = IETF meeting, great. If we need additional meetings, we can have a virtual = interim. Please: let's not make this a "reason to travel" WG.=

Meeting F2F is fine, we won't set = any restrictions/expectations on that up front.

Th= anks,
Kathleen
=C2=A0

--Paul Hoffman



--

Best regards,
Kathleen
--001a11c264becd28d60515798606-- From nobody Thu May 7 01:19:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ACB1B2E05; Thu, 7 May 2015 01:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tErQ3ZDm9vIY; Thu, 7 May 2015 01:19:43 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E4C1AD079; Thu, 7 May 2015 01:19:42 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so25461018lbb.0; Thu, 07 May 2015 01:19:41 -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=0uGovqMpGMsPZXms4hsnqXZdlFIuGDuXeJWbC0ge1II=; b=XSaBc7eik5T8PHi9bv9BLs2an8MxTQx3jLZ0lajbm7LuGV/kzzRCGBORlNjeT2lM1v ZPrKufyVZbRdFJWJ1f3+3XtfxmdvQAHUf0XTbLnrx51FQ2mAM+1Vo4qM+gvdlkvbH8oz PuuYMy7HPKPMFFs6Wesig31z2cN3CNY3bvURaf38nfBzMPcX8rbdOOKDTNbfPz8GFS1T TeHwdodT7n8qhoVujtzW491SufP97ZX6VnFEj4sZ1/vt4cWBiVVn3MxJ9Sy/WkK8YLko 2JSetOcIoEYU0DDSrjTmYQWtLr2NkBGvl7o1dZeUd+0a4ZPuqJcuTb51ZS/DW0CIXNoL KqIQ== MIME-Version: 1.0 X-Received: by 10.112.202.194 with SMTP id kk2mr2192391lbc.0.1430986781173; Thu, 07 May 2015 01:19:41 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 7 May 2015 01:19:41 -0700 (PDT) In-Reply-To: References: <20150428143033.5998.43672.idtracker@ietfa.amsl.com> <39E2589A-483F-4DEE-AD5E-71AC75F1CAE3@vpnc.org> <553FAFFF.6010208@cs.tcd.ie> <522FAB4F-8E59-4D27-BE42-42DED9092D93@vpnc.org> <0F925919-5A1F-4087-AF8E-11F9C408C006@gmail.com> Date: Thu, 7 May 2015 04:19:41 -0400 Message-ID: From: Kathleen Moriarty To: Kepeng Li Content-Type: multipart/alternative; boundary=001a11c37232c52b5f0515799287 Archived-At: Cc: The IESG , Stephen Farrell , Paul Hoffman , "cose@ietf.org" Subject: Re: [Cose] Stephen Farrell's Block on charter-ietf-cose-00-00: (with BLOCK and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 08:19:44 -0000 --001a11c37232c52b5f0515799287 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll make these updates today to the charter under review today. Thank you, Kathleen On Wed, Apr 29, 2015 at 11:29 AM, Kepeng Li wrote: > >I can do it, but it would be good to hear from more than one person and > >to see if there is better wording as requested. > > > I can help to consolidate the proposed changes and hopefully make it > easier for you. :-) > > The proposed changes so far: > > 1) Add one paragraph below (proposed by Paul): > The COSE WG will not innovate in terms of cryptography. The specifiation > of algorithms in COSE is limited to those in RFCs or active IETF WG > documents. > > > 2) Remove one sentence below (proposed by Paul): > COSE will rely on the JOSE registries, and will expand them with > additional information when necessary. > > > 3) Change one sentence below (proposed by Stephen) > OLD: > The working group will coordinate its progress with the ACE, DICE and COR= E > working groups to ensure that we are fulfilling the needs of these > Constituencies. > > > NEW: > The working group will coordinate its progress with the ACE, DICE and COR= E > working groups to ensure that we are fulfilling the needs of these > Constituencies to the extent relevant to their work. > > > Thanks, > > Kind Regards > Kepeng > > > > =E5=9C=A8 29/4/15 12:38 am=EF=BC=8C "Kathleen Moriarty" > =E5=86=99=E5=85=A5: > > > > > > >Sent from my iPhone > > > >> On Apr 28, 2015, at 12:27 PM, Paul Hoffman > >>wrote: > >> > >>> On Apr 28, 2015, at 9:06 AM, Stephen Farrell > >>> wrote: > >>> > >>> tl;dr - make that or an equivalent change and I'll s/block/yes/ > >> > >> Cool, thanks. I'm a bit embarrassed to admit that I don't know how to > >>make a change to a proposed charter while it is in IESG evaluation. Doe= s > >>someone for the not-yet-WG do so? Or does the sponsoring AD do so? > >> > > > >I can do it, but it would be good to hear from more than one person and > >to see if there is better wording as requested. > > > >Thanks, > >Kathleen > > > > > > --=20 Best regards, Kathleen --001a11c37232c52b5f0515799287 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll make these updates today to the charter under rev= iew today.

Thank you,
Kathleen

On Wed, Apr 29, 2015 = at 11:29 AM, Kepeng Li <kepeng.lkp@alibaba-inc.com>= wrote:
>I can do it,= but it would be good to hear from more than one person and
>to see if there is better wording as requested.


I can help to consolidate the proposed changes and hopefully make it=
easier for you. :-)

The proposed changes so far:

1) Add one paragraph below (proposed by Paul):
The COSE WG will not innovate in terms of cryptography.=C2= =A0 The specifiation
of algorithms in COSE is limited to those in RFCs or active IETF WG
documents.


2) Remove one sentence below (proposed by Paul):
COSE will rely on the JOSE registries, and will expand the= m with
additional information when necessary.


3) Change one sentence below (proposed by Stephen)
OLD:
The working group will coordinate its progress with the ACE, DICE and CORE<= br> working groups to ensure that we are fulfilling the needs of these
Constituencies.


NEW:
The working group will coordinate its progress with the ACE, DICE and CORE<= br> working groups to ensure that we are fulfilling the needs of these
Constituencies to the extent relevant to their work.


Thanks,

Kind Regards
Kepeng



=E5=9C=A8 29/4/15 12:38 am=EF=BC=8C "Kathleen Moriarty" <kathleen.moriarty.ietf@gmail= .com>
=E5=86=99=E5=85=A5:

>
>
>Sent from my iPhone
>
>> On Apr 28, 2015, at 12:27 PM, Paul Hoffman <paul.hoffman@vpnc.org>
>>wrote:
>>
>>> On Apr 28, 2015, at 9:06 AM, Stephen Farrell
>>><stephen.farrel= l@cs.tcd.ie> wrote:
>>>
>>> tl;dr - make that or an equivalent change and I'll s/block= /yes/
>>
>> Cool, thanks. I'm a bit embarrassed to admit that I don't = know how to
>>make a change to a proposed charter while it is in IESG evaluation.= Does
>>someone for the not-yet-WG do so? Or does the sponsoring AD do so?<= br> >>
>
>I can do it, but it would be good to hear from more than one person and=
>to see if there is better wording as requested.
>
>Thanks,
>Kathleen

>





--
=

Best regards,
Kathleen
--001a11c37232c52b5f0515799287-- From nobody Thu May 7 02:21:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4E1A005C; Thu, 7 May 2015 02:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2n9JtnVv6ya; Thu, 7 May 2015 02:21:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 150521A0054; Thu, 7 May 2015 02:21:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507092113.28231.14010.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 02:21:13 -0700 Archived-At: Cc: cose@ietf.org Subject: [Cose] Stephen Farrell's Yes on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 09:21:14 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-cose-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cose/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments. Just preserving a part of that below as it may be of use to other ADs in their evaluations. I was initially skeptical of this work, doubting that there is really sufficient real interest in CBOR to justify spending the time on a WG. However, (just about) enough people argued that they would or are using CBOR to convince me that there could well be a real constituency here. And given that, I'd prefer the work be done in the IETF rather than ad-hoc and possibly by some folks who'd prioritise constrained-system requirements too much over security and privacy requirements. So in the end, I'm for doing this. From nobody Thu May 7 13:00:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B5C1A92E7 for ; Thu, 7 May 2015 13:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qih57kuib3Zj for ; Thu, 7 May 2015 13:00:16 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D2E1A90D4 for ; Thu, 7 May 2015 13:00:16 -0700 (PDT) Received: from Philemon (c-24-20-67-136.hsd1.or.comcast.net [24.20.67.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id BD99F2CA06; Thu, 7 May 2015 13:00:15 -0700 (PDT) From: "Jim Schaad" To: "'Ludwig Seitz'" , References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> <5549BC81.1050808@sics.se> In-Reply-To: <5549BC81.1050808@sics.se> Date: Thu, 7 May 2015 12:58:53 -0700 Message-ID: <000401d08900$3f109100$bd31b300$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsJwC5M2J6P0ogmMRJ78f4EU04JwICODagnSlQ2PA= Content-Language: en-us Archived-At: Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:00:18 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Ludwig Seitz > Sent: Wednesday, May 06, 2015 12:02 AM > To: cose@ietf.org > Subject: Re: [Cose] Issue: Identification of the top level objects >=20 > On 05/01/2015 12:58 AM, Jim Schaad wrote: > > Question: Identification of objects: > > a) CBOR Tag - either general or specific to each type > > b) Required Identifier > > c) Use the same techniques as JOSE > > > > Discussion: > > > > One of the things that I have never liked with the JOSE document is > > the method that is used to determine the type of object that one is dealing > > with. I would lie to get this corrected so that it is simple to = make this > > determination. >=20 > Why was it done this way in JOSE in the first place? The major focus of the JOSE working group tended to be on the compact encoding and in this case it was deemed to not be necessary to have as = the number of separation characters gave adequate indication of the type of message it was. This was not as true for the JSON encoding where there = were some kind of kludgy methods of doing the identification. There were = several attempts to get this clarified up, but the push back was too large among = the people who were only interested in the compact format. Jim >=20 > A CBOR tag sounds neat, can the CBOR experts tell us if there are any > negative implications? >=20 > /Ludwig >=20 > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se From nobody Thu May 7 13:33:13 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F291AD084 for ; Thu, 7 May 2015 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpso1uPza8Op for ; Thu, 7 May 2015 13:33:11 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F337B1AD0D0 for ; Thu, 7 May 2015 13:33:10 -0700 (PDT) Received: from Philemon (c-24-20-67-136.hsd1.or.comcast.net [24.20.67.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 55E4538F04; Thu, 7 May 2015 13:33:10 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <724B1E60-A92F-42EB-B7BD-732A6B19ECCA@vpnc.org> In-Reply-To: <724B1E60-A92F-42EB-B7BD-732A6B19ECCA@vpnc.org> Date: Thu, 7 May 2015 13:31:47 -0700 Message-ID: <00e601d08904$d7eecb90$87cc62b0$@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: AQJBW2regVOc1KgJrCGEY9SFfcIRjgEKuL5HnIb8NDA= Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:33:12 -0000 Paul, Based on your comment I am not sure if I was clear about what I was asking - Please let me know either way. 1. Gives a result of {"unprotected":xxx, "cipher_text":xxx, "header":xxx, "encryptd_key":xxx } 2. Gives a result of {"unprotected"xxx", "cipher_text"xxx, "recipients":{"header":xxx, "encrypted_key":xxx }} 3 Gives a result of {"unprotected":xxx", "cipher_text":xxx, "recipients:[{"header":xxx, "encrypted_key":xxx}]} Labels disappear if the top level is an array and not a map - but no other significant changes. Jim > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, May 06, 2015 2:30 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [Cose] Issue: Encoding for a single recipient or structure > > On Apr 30, 2015, at 3:59 PM, Jim Schaad wrote: > > Question: Flattened encoding - > > a) Roll into parent map > > b) Just be a map > > c) Single element in array > > If the top level is an array, clearly (c) is the right way to go. Otherwise, both > (a) and (b) seem similar in code size and data size. > > --Paul Hoffman= From nobody Thu May 7 13:54:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5D1B29F2 for ; Thu, 7 May 2015 13:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQO2h7uByv3H for ; Thu, 7 May 2015 13:54:27 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553C91A8730 for ; Thu, 7 May 2015 13:54:27 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t47KsO9P041320 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2015 13:54:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <00e601d08904$d7eecb90$87cc62b0$@augustcellars.com> Date: Thu, 7 May 2015 13:54:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA52A2F-1612-487E-9096-4EE939B99BD2@vpnc.org> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <724B1E60-A92F-42EB-B7BD-732A6B19ECCA@vpnc.org> <00e601d08904$d7eecb90$87cc62b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.2098) Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:54:28 -0000 On May 7, 2015, at 1:31 PM, Jim Schaad wrote: > Based on your comment I am not sure if I was clear about what I was = asking - > Please let me know either way. >=20 > 1. Gives a result of {"unprotected":xxx, "cipher_text":xxx, = "header":xxx, > "encryptd_key":xxx } > 2. Gives a result of {"unprotected"xxx", "cipher_text"xxx, > "recipients":{"header":xxx, "encrypted_key":xxx }} > 3 Gives a result of {"unprotected":xxx", "cipher_text":xxx, > "recipients:[{"header":xxx, "encrypted_key":xxx}]} >=20 > Labels disappear if the top level is an array and not a map - but no = other > significant changes. Right, I completely misunderstood your shorthand. Given these, (c) seems = better: it keeps the structure predictable, with a possible reduction of = code for processing the structure (but not much, admittedly). --Paul Hoffman= From nobody Sun May 10 22:56:47 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E241A00FD for ; Sun, 10 May 2015 22:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbHXrqyoxJO6 for ; Sun, 10 May 2015 22:56:44 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F751A00E0 for ; Sun, 10 May 2015 22:56:43 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2014138F1C for ; Sun, 10 May 2015 22:56:43 -0700 (PDT) From: "Jim Schaad" To: Date: Sun, 10 May 2015 22:55:18 -0700 Message-ID: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_027F_01D08B74.6343CF80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCLqYqqIpBM2Wx4Q8mhu5BRuxfBUQ== Content-Language: en-us Archived-At: Subject: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 05:56:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_027F_01D08B74.6343CF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have spent a couple of days looking at messages that are likely to be sent for the world of CoRE/ACE based on the draft https://tools.ietf.org/html/draft-selander-ace-object-security-01 and the response on key management that I got back recently. I have made several assumptions in doing the computations. I have included my spreadsheet of the different cases so that you can look at where I had assigned bytes used. If people have other cases where they would like to get sizes computed, please send them to me and I can run the numbers. Case #1 - MAC on a content using a direct key. I am assuming, probably without cause, that this is going to be the most common message type sent. (It could be case #2 instead). The details of the message that I am looking at are: - We use a one byte internal identifier for the message type - We are protecting the algorithm identifier and a nonce. - We are carrying no unprotected headers - We are using a nonce which is one byte long - increasing the size of the nonce would uniformly increase the size of the message for both configurations - A payload of 19 bytes is assumed and it is assumed that the content is being carried inside of the message. - The algorithm for the MAC is HMAC-SHA-256 and the tag is truncated to 16 bytes. - A key identifier of 8 bytes is used. - There is no AAD field built into the message, but there may be external AAD information passed in (i.e. carried in the message header). - Assuming a single recipient and the recipient information structure is encoded as a map w/o an array wrapper. - In this case using maps takes 62 octets and using arrays takes 63 octets. Case #2 - Encryption on a content using a direct key. The details of the message that I am looking at are: - We use a one byte internal identifier for the message type - We are protecting the algorithm identifier - We are carrying no unprotected headers - We are carrying an IV of 8 bytes. This could be shortened under some circumstances, but that would be equal in both mappings. There is no reason to carry it as a protected header item as CCM and GCM both automatically include the IV value in the authenticated data computation. - A payload of 19 bytes is assumed and it is assumed that the content is being carried inside of the message. - The algorithm for the encryption is AES-128-CCM-64, the tag is 8 bytes. - A key identifier of 8 bytes is used. - There is no AAD field built into the message, but there may be external AAD information passed in (i.e. carried in the message header). - Assuming a single recipient and the recipient information structure is encoded as a map w/o an array wrapper. - In this case using maps takes 60 octets and using arrays takes 61 octets. Case #3 - Sign a message using an asymmetric key. The details of the message that I am looking at are: - We use a one byte internal identifier for the message type - We are protecting the algorithm identifier and the kid - We are carrying no unprotected headers - We are assuming that the payload it detached and not part of the message - The algorithm is ECDSA using P-256 - thus the signature value itself is 64 bytes. - In this case using maps takes 82 bytes and arrays takes 83 bytes. If content is included, then the array will be the same size as for map. Case #4 - Sign a message using an asymmetric key and encrypt it using a direct key. - For the signature, the conditions are the same as for case #3 with the exception that the content is carried in the message. - For the encrypt operation, the conditions are the same as for case #2. - For map, the size is 145 octets, for array the size is 146 octets. For all of the cases that I have provided above, I am using the minimal set of fields. If any other fields are added, for example unprotected attributes, then the balance tips from maps to arrays as the cost to add a field is 2 octets plus the data, whereas the cost to add a field to an array is just the size of the data. ------=_NextPart_000_027F_01D08B74.6343CF80 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="message-sizes.xlsx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message-sizes.xlsx" UEsDBBQABgAIAAAAIQDLn3dlfAEAAKgGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM ld9OwjAUxu9NfIelt4YV0BhjGFygXiqJ+AC1PWMNXdv0FIS392z8iSETQlwiN2u2nvN9vzbtt8Fo VZpkCQG1sxnrpV2WgJVOaTvL2Mf0pfPAEozCKmGchYytAdloeH01mK49YELdFjNWxOgfOUdZQCkw dR4szeQulCLSa5hxL+RczID3u917Lp2NYGMnVhpsOHiCXCxMTJ5X9HlDEsAgS8abwsorY8J7o6WI RMqXVh24dLYOKXXWNVhojzeEwXijQzXzu8G27422JmgFyUSE+CpKwuArw79cmH86N0+PizRQujzX EpSTi5J2IEUfQCgsAGJp0npMS6HtjvuIf12MvB56LYNU66uFz+ToXwjH7YVw3P0TR6R7CLx+/v1o 1DInDgLGtQFsebUb0VPOhQig3mOgxGod4Kf2CQ4pjBwXdHVb3oS97jF/ypNJcB4pWQOcD7CLzqq7 40kIQtSwD8+mENo7Uiqfb3iQglDlvgLV4M3r/8zwGwAA//8DAFBLAwQUAAYACAAAACEAtVUwI/UA AABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T76m5ICKGlu0xIuyFUHsAk 7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4rZ9WD6BiImdpFMcajhxh V93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl3JTlPYa/HlAtPNXBaggH eweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc0xHJ+yJjA54m2lxP9P+2 OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD//wMAUEsDBBQABgAIAAAA IQBs+1lMKQEAAOYEAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHMgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8lM1qxCAUhfeFvkNw35hkptNSxsyipTDbdvoAYm5imESD 1/7k7Svp1DQwOBvpRrhHPOfjenW7++q75AMMtloxkqcZSUAJXbWqYeTt8HxzTxK0XFW80woYGQHJ rry+2r5Ax607hLIdMHEuChmR1g4PlKKQ0HNM9QDK7dTa9Ny60jR04OLIG6BFlm2o+etByoVnsq8Y MfvK5R/GwSVf9tZ13Qp40uK9B2XPRFDBO/EoeaucKTcNWEa8lDpSQs9DrGJCfGpzRAlgZwgvIZ12 ViGYu5gwKLmB6tUad+E4Ay3kEEwRE8a3YQbx0qkzRQgm/2eYPASziQmDduzcy/NT+1OH4m9jxlv3 nmFOn0o6rcEWrGMy+EmYObx0Go71b0Po4ncqvwEAAP//AwBQSwMEFAAGAAgAAAAhAHZlgWd4AQAA sAIAAA8AAAB4bC93b3JrYm9vay54bWyMkstuwjAQRfeV+g+Wuy4OSXgUEZD6UtlUXdCyNvGEWDh2 ZBsCf9+JESkVXXTljOf4+t6Jp/NDpcgerJNGZ7TfiygBnRsh9Sajn8vX+zElznMtuDIaMnoER+ez 25tpY+x2bcyWoIB2GS29ryeMubyEirueqUFjpzC24h5Lu2GutsCFKwF8pVgcRUNWcanpSWFi/6Nh ikLm8GzyXQXan0QsKO7Rvitl7ehsWkgFX6dEhNf1O6/Q90FRorjzL0J6EBkdYGka+LVhd/XjTirs PiRRQtmsC/lhiYCC75RfYryzOs4rTuN42JLtKL4kNO7nUFuSw0pqYZqMpmMc7fFcJVg0obOSwpdB KUFPp703kJvSZ3Q0SpHjuZd7WPJ1RoMpdnFXmCbeGVaiQ9Qn7oDc9fG/taNeYJyYEjuR+GEXot+6 vcYR6fDkAo//xhHp8PQCDwav1RHpcEzZmUlbdRZaGCLnKsdJt0vrup8OhnGwy86PbfYNAAD//wMA UEsDBBQABgAIAAAAIQB8c4zytQQAAIUSAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDQueG1slFhN j6M4EL2vtP8BcdrZaEIM+UQJo3QQ7BxGWs3H3gkxCWrAWaC7p//9lG2wsSdE8Q3sR73yq/IzsP30 syysV1w3Oal2NprObAtXKTnl1Xln//gefVzbVtMm1SkpSIV39jtu7E/Bn39s30j93Fwwbi2IUDU7 +9K2V99xmvSCy6SZkiuuYCYjdZm0cFufneZa4+TEHioLx53Nlk6Z5JXNI/j1IzFIluUpDkn6UuKq 5UFqXCQt5N9c8mvTRyvTR8KVSf38cv2YkvIKIY55kbfvLKhtlan/+VyROjkWsO6faJ6kfWx281v4 Mk9r0pCsnUI4hyf6+5o3zsaBSMH2lMMKqOxWjbOdvUd+7G1sJ9gygf7L8VszuLba5PgNFzht8Qnq ZFtU/yMhzxT4GYZmELJhABoySdv8FR9wUezsGEFRm/8ZC70GCkdwDK97vojV7N/aOuEseSnar+Tt H5yfLy0QL0ADKoV/eg9xk0INgHrqLkTiYdImwbYmbxbUE/JsrgntDuSvxp4MtinFRgCGYA2s4zVA q63zCrml3WSsTHpi0gEiweaasLnAkwXffnz5K5r7EUIftk7GmOcLEZ3lFUtkPPfjIXIpkEoec4M8 9gAWq3aRCMglmTMxXHU05qMSq5BDgR6WfA9gQT5TWcIF49ZGIzqaBe4khLUzvebqYzEHhMsJ5McA I8VaGuT5BGCRJ9LkCJeaSIoc0HWPywFgSaOta8VYRkSnJvlon+8BLFi0Ng/XjGWjckd0NAvCtdAU aWWJe0SnuQygiLExSRPAIs21mlC4YWnqSfDREYmYCT2sEUULdrmaziio12VB5C4m7gRNIDm+c5He ixCFAmMGlLCRjkQmbrWnaJGh3pIwSb1EEwhchuXDTAeB67jowwQe5dnrtjMAxwCOKbjfU0gWRCkw MrIeihZL0HINYfLGEiATNjxWZCP3oYeJ4JcRuyL3TkPVCtHSD9FKeLSsILdoiEQLjSa3wLI4qlZG DoQUC9KShfSYKrJRVSYTE3pCigvJ5NlKQQTGJIdVJiMjQvecCCZv1p8PSwFUfiOHQfcsBiZv8t81 GZe+6TxsMhQt+k/WjgsNk7f4u+GR9btGFkLRgl9WtOO/aSHgAiytMX6T/Qf+CbG6dyB35UeeKzbY TN9hA2wM2Pg2VmkG16Tt9xQtxZDrY2pEMEuroYkEmdxVw2g3uMPdoLlhDJOUX6alrtSo7d1h28uI bKExTN4h8oz6m6KFpPLE4EQweY/IqJG9YSNr59gBJlnpNEkjNp4FMC+ONf39N5aY7pR0ZRSlAp7J u/+eooUwg7OU9xrM0m3hssMk8hawMTb9xlhL/k5GDuYnTwxg+IjrwSvpKWqyJrt07w1PSY0eshvk evCW/sEbPyU7MM9VB8utpeZqdEp6yikpQzKtgJF3gniZVJlM7OLJU+xCkwVEYExj+hv5gjf0BX27 wuS9XWTkC/D1P+hKmXsnHjUG6Mq/3cXSkV8CS227Qa8y3MGDAOzFUkfQvww00k0Erwj/PcC/5K/J GX9J6nNeNVaBM9g2syloX/P/Aey6JVc2Co16JG1Lyv7uAr97MHzaz6aebWWEtP0N/QUhfiAFvwAA AP//AwBQSwMEFAAGAAgAAAAhAG/rQTWAAwAAPgwAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0Mi54 bWyUVl1vmzAUfZ+0/4B4WhQ1YJpPRKjSIbI+VJq2de8OMQkqYAZu2v77XdvEDm5ShaeA78k95x47 Jw7u3orcOpC6yWi5tNHItS1SJnSblbul/fQnvpnbVsNwucU5LcnSfieNfRd+/RK80vq52RPCLOhQ Nkt7z1jlO06T7EmBmxGtSAmVlNYFZvBa75ymqgneii8VueO57tQpcFbasoNfX9ODpmmWkIgmLwUp mWxSkxwz0N/ss6o5diuSa9oVuH5+qW4SWlTQYpPlGXsXTW2rSPyHXUlrvMlh7jc0xsmxt3j50L7I kpo2NGUjaOdIoR9nXjgLBzqFwTaDCbjtVk3Spb1C/tpDthMGwqC/GXltTp4t7veG0mdeeNgubRda NCQnCZ/cwvBxIN9Jni/tCCHYs3+iK3+Glo7qefp87B+LPfpZW1uS4pec/aKvP0i22zM4EBOYmY/u b98j0iTgOVCPvIkSGmGGw6CmrxbsHyeuMD8NyJ9d+mYYJBwbAxiaNTDHIUSzwDmAtqQtrjvFW1V0 gEixeX3YPOBJw99Pj9/isR8jNAiclDNPXdVcyFpr4Hrsr0+ASAE7KsY9VKwArGb2dENpyFhY4Ska qUeuamyHHLbnasNXAFbkxtTRRHAbqzFfTUNvGE1bt8aGOAmIpkPQJ+y8sFXTHjrvAax0IsOOaGqY 1LEDztz1dgBY0xhzzQTLBdN5JF57ylcAVizGIY/mgmXR5Y75ahpGc+UpMrZlfUS0nusGHTMWfWQC WMmcdwVFCyHTFCFXL1iE4H/keo84WrHracT5j6AoDqE7BF3ijHmGwLiFAFR55hlt1hrzsUvHNpGe V28vRyvp5lmFIo8YwzkIHzGRyCIEYeShwRC+KmZDk675EEAKvAYw/EcM1JBIG9EdoVcmodNQMrRG UDwzAigRy5d2v1cs8f8YZaHuKDMRijKCuFsRmvoRmg2OXumwkVHZgtHwHFhvTterXtGEOtlkiAV5 whV99LpMfdLpHnXiSYtvfxQyoPRyl6lXQqHPIgqKZ/dfLmsDuvy9ogd9lj1QPMv/afp4vdKHo9X5 03snjYbiOf52+cL8cI/rkX4crfj1jrb8ZyOE3xS5LJNf3vPklazCO/KI611WNlZOUmBwR3Cmanmx E8+MVmIVfoAbyhgtjm97uKcTuKO5o1vbSillxxd+l1Q3//A/AAAA//8DAFBLAwQUAAYACAAAACEA 1RHiMCIDAABoCQAAGAAAAHhsL3dvcmtzaGVldHMvc2hlZXQzLnhtbJRWXW+bMBR9n7T/gHjaVjVg kpAEBao0FawPlaZt3Z4dMAkqYIadj/77XduJXdIPhZcE24dzzr2+12Z+c6hKa0daVtA6tNHAtS1S pzQr6nVoP/6Or6e2xTiuM1zSmoT2M2H2TfT503xP2ye2IYRbwFCz0N5w3gSOw9INqTAb0IbUsJLT tsIchu3aYU1LcCZfqkrHc13fqXBR24ohaC/hoHlepOSOptuK1FyRtKTEHPyzTdGwE1uVXkJX4fZp 21yntGqAYlWUBX+WpLZVpcH9uqYtXpUQ9wGNcHriloNX9FWRtpTRnA+AzlFGX8c8c2YOMEXzrIAI RNqtluShvUBBgnzbieYyQX8Ksmcvni2R7xWlT2LhPgttFygYKUkqIrcw/O3IkpRlaCcT2LJ/khQe gdDRjC+fT+yx3KEfrZWRHG9L/pPuv5NiveFQDmOIWAQeZM93hKWQcRAeeGPBmtISKODXqgpROpAx fJD/+yLjm9AeD8YTd4gAbaVbxmn1V80j6Um9Lp3dYY6jeUv3FpQA8LAGi4JCAQTytjzoCmwMYHDE IBW7CE3mzg4CTI+LSWdxqBcdENJqXh81D3Ty6Nfjw5d4FMSzr3MnF8JTT3NLV4nBJaMgMbh3PIx6 eFgAWEfsoa5wPJKJOLejZg22kwDYnIvTvQCwFne72slYbYKe7aj4fVQArFWMa5Va/yMVUfeXls4C wFplql0rlYlUMRF2YhEH4sUqANYq467KcnqmorTVrIm7oz3row1grY3OQoxnIJ5H3pWsZuQFMfJ1 PZvAlSWFRRKbABbOqRN2MtNBdYyiPo21EGht9Uw9hkVjdYmGwRKNTvLItJSyegQrr+dg0xhdr8Me Wb1FgNZekaGU+qAoN9VMd5X6tPot6vT6WVogCVLpvfz36mtxzpuY9I4eU/phZ8OV1aMdBNoIGe/H 5InuhqL85o19Z3oFPSDPV/+scaBUJW6J/HcQ4iIVTG8i1I6oO1HdPA1ekwfcrouaWSXJwaA7gOOh VZegfOa0kbOQqBXlcJedRhv4oiFwFbkDqIucUn4aiHtXfyNF/wEAAP//AwBQSwMEFAAGAAgAAAAh ABCAAmHZAwAAGg0AABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWyUV9tymzAQfe9M/4HhqZ1O jIVvMWOTccpA85BOp2navipY2EwAUaTYSb++KwlLRrnUvCRmtew5e/ZieXHxWBbOjjQsp9XSRYOh 65Aqpeu82izd2x/x2bnrMI6rNS5oRZbuE2HuRfj+3WJPm3u2JYQ7EKFiS3fLeR14Hku3pMRsQGtS wUlGmxJzeGw2HqsbgtfypbLw/OFw6pU4r1wVIWhOiUGzLE9JRNOHklRcBWlIgTnwZ9u8ZodoZXpK uBI39w/1WUrLGkLc5UXOn2RQ1ynT4GpT0QbfFZD3Ixrj9BBbPjwLX+ZpQxnN+ADCeYro85zn3tyD SOFinUMGQnanIdnSXaEg8UeuFy6kQD9zsmdHn52/lJY3KRZcEJq45vmrULhoraIqd5Tei9ev1kt3 CECMFCQV+jgY/u3IZ1KA+2oMhf2joMfB7zgaC2xPgx9/PhCJZTG/Nc6aZPih4N/p/gvJN1sO6EBJ yhKsnyLCUigOoA/8iYia0gJCwF+nzEWXgbj4Uf7f52u+XbrTwQwN56MZBEkfGKflL2VHkpN6XTKL MMfhoqF7B7oF4rAai95Dwew1eMAVvjE4AyMGeuxCNF54O0gwbQ+TzuFEH3oApNH8Pmg+4GThze31 h3gcxMj/uPAygTz1dXBJKzGOyThIjhxH2rHDQlTt1JxFiXXOPtIBlSBjKYXNR1mNbwccynM6ODhr cJOMwp5IefxPQqBoGkQzrU+XZKIc0XPHV4o07cHwEpw1QzTsIkdTS56OENBtJwtxCc4GZmrBzN6C Ebv35GKDs4ax+js6lyhWiomwZiHUWrbmKzWf9+EAzprDuZXp/EUOwvpfDgi+lU4XQnhrFqZPZOdF cCjm0Le0iKU9C+H800EQe2IS49NKdhSl0x6oz2ZaCW/N1+4POJQba9ZVM5Z2wRdpvshSPDE+hxKb KF2+fXbbCoG35mvtD1h1sqBqtGM0DWJ/dBhuZBUD1p2qvhzvBJzhG1A7m2y6XPuM+Aodz7hV8wgO hbaWGXgoybXiXfw+s79CneHXEdUWhEPR/O0aROdBhOY6fWtlJq1zuwotZ1OFLtc+C+QSHW8QZNZB Ozhqh8x1Dl2kPmviEh3vCWTIt0hqUxhzB8nvtQuEt+5V0/0KCA5fqn9rNgJ08XvNtn8826ajW3w1 23b/wTty5F9W2u81q8Jb529q1+KL8Xve//DOW/ijPrsYbrQG31S0xR+9jK/Mtv7qaqougDXekGvc bPKKOQXJIMPhACatUXdR+ZnTWlrhGnJHOVwpD09b+A1C4EY4HAC3jFJ+eBDXX/2rJvwHAAD//wMA UEsDBBQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAeGwvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/ D9h3IHRvbSe2Gwd1itixm61NG8Ruhx5pmZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8mW4et A/oV9khKshjLS9IGG9bVh0Qif3z/3+MjdfXag4ihQyIk5XHbq12ueojEPh/TOGh7d4b9SxsekgrH Y8x4TNrenEjv2tb7713FmyokEUGwPpabuO2FSiWblYr0YRjLyzwhMcxNuIiwglcRVMYCHwHdiFXW qtVmJcI09lCMIyB7ezKhPkFDTdLbyoj3GLzGSuoBn4mBJk2cFQY7ntY0Qs5llwl0iFnbAz5jfjQk D5SHGJYKJtpe1fy8ytbVCt5MFzG1Ym1hXd/80nXpgvF0zfAUwShnWuvXW1d2cvoGwNQyrtfrdXu1 nJ4BYN8HTa0sRZr1/katk9EsgOzjMu1utVGtu/gC/fUlmVudTqfRSmWxRA3IPtaX8BvVZn17zcEb kMU3lvD1zna323TwBmTxzSV8/0qrWXfxBhQyGk+X0Nqh/X5KPYdMONsthW8AfKOawhcoiIY8ujSL CY/VqliL8H0u+gDQQIYVjZGaJ2SCfYjiLo5GgmLNAG8SXJixQ75cGtK8kPQFTVTb+zDBkBELeq+e f//q+VP06vmT44fPjh/+dPzo0fHDHy0tZ+EujoPiwpfffvbn1x+jP55+8/LxF+V4WcT/+sMnv/z8 eTkQMmgh0Ysvn/z27MmLrz79/bvHJfBtgUdF+JBGRKJb5Agd8Ah0M4ZxJScjcb4VwxBTZwUOgXYJ 6Z4KHeCtOWZluA5xjXdXQPEoA16f3XdkHYRipmgJ5xth5AD3OGcdLkoNcEPzKlh4OIuDcuZiVsQd YHxYxruLY8e1vVkCVTMLSsf23ZA4Yu4zHCsckJgopOf4lJAS7e5R6th1j/qCSz5R6B5FHUxLTTKk IyeQFot2aQR+mZfpDK52bLN3F3U4K9N6hxy6SEgIzEqEHxLmmPE6nikclZEc4ogVDX4Tq7BMyMFc +EVcTyrwdEAYR70xkbJszW0B+hacfgNDvSp1+x6bRy5SKDoto3kTc15E7vBpN8RRUoYd0DgsYj+Q UwhRjPa5KoPvcTdD9Dv4Accr3X2XEsfdpxeCOzRwRFoEiJ6ZiRJfXifcid/BnE0wMVUGSrpTqSMa /13ZZhTqtuXwrmy3vW3YxMqSZ/dEsV6F+w+W6B08i/cJZMXyFvWuQr+r0N5bX6FX5fLF1+VFKYYq rRsS22ubzjta2XhPKGMDNWfkpjS9t4QNaNyHQb3OHDpJfhBLQnjUmQwMHFwgsFmDBFcfURUOQpxA 317zNJFApqQDiRIu4bxohktpazz0/sqeNhv6HGIrh8Rqj4/t8Loezo4bORkjVWDOtBmjdU3grMzW r6REQbfXYVbTQp2ZW82IZoqiwy1XWZvYnMvB5LlqMJhbEzobBP0QWLkJx37NGs47mJGxtrv1UeYW 44WLdJEM8ZikPtJ6L/uoZpyUxcqSIloPGwz67HiK1QrcWprsG3A7i5OK7Oor2GXeexMvZRG88BJQ O5mOLC4mJ4vRUdtrNdYaHvJx0vYmcFSGxygBr0vdTGIWwH2Tr4QN+1OT2WT5wputTDE3CWpw+2Ht vqSwUwcSIdUOlqENDTOVhgCLNScr/1oDzHpRCpRUo7NJsb4BwfCvSQF2dF1LJhPiq6KzCyPadvY1 LaV8pogYhOMjNGIzcYDB/TpUQZ8xlXDjYSqCfoHrOW1tM+UW5zTpipdiBmfHMUtCnJZbnaJZJlu4 KUi5DOatIB7oViq7Ue78qpiUvyBVimH8P1NF7ydwBbE+1h7w4XZYYKQzpe1xoUIOVSgJqd8X0DiY 2gHRAle8MA1BBXfU5r8gh/q/zTlLw6Q1nCTVAQ2QoLAfqVAQsg9lyUTfKcRq6d5lSbKUkImogrgy sWKPyCFhQ10Dm3pv91AIoW6qSVoGDO5k/LnvaQaNAt3kFPPNqWT53mtz4J/ufGwyg1JuHTYNTWb/ XMS8PVjsqna9WZ7tvUVF9MSizapnWQHMCltBK0371xThnFutrVhLGq81MuHAi8saw2DeECVwkYT0 H9j/qPCZ/eChN9QhP4DaiuD7hSYGYQNRfck2HkgXSDs4gsbJDtpg0qSsadPWSVst26wvuNPN+Z4w tpbsLP4+p7Hz5sxl5+TiRRo7tbBjazu20tTg2ZMpCkOT7CBjHGO+lBU/ZvHRfXD0Dnw2mDElTTDB pyqBoYcemDyA5LcczdKtvwAAAP//AwBQSwMEFAAGAAgAAAAhAJs9gGggAQAApQIAABQAAAB4bC9z aGFyZWRTdHJpbmdzLnhtbHSSwU7DMAyG70i8Q5QTHFjKDsBQ22kCIaFpaIftAazWtJFaJ8TutL49 GRMIpdox3///ju0kXx77Th0wsHVU6PtZphVS5WpLTaH3u7e7J61YgGroHGGhR2S9LK+vcmZRMUtc 6FbEPxvDVYs98Mx5pKh8utCDxGNoDPuAUHOLKH1n5ln2YHqwpFXlBpJCPy60Gsh+DfhyBvO5LnO2 ZS6lD06wEqxzI2VuTvAsDHRRClhZb5GE09D2UrX95Woexs7B5H6BJq1uDymBaS621mIQPEpqXnXN +2sK11N08k3aWYUAYxrerLbqhuNjdqh68Lep/hOKO/01pPqHowpTuAGfIrYNgQwBJwv/U9LI2k5G 2I0e1e7/Wk38ZuU3AAAA//8DAFBLAwQUAAYACAAAACEA0MxIlEgCAADsBAAADQAAAHhsL3N0eWxl cy54bWyklE2L2zAQhu+F/gehuyPHTbZJsL2QZA0L21JICr0qtuyI1YeR5NRp6X/vyHachD20sBdr NBo9emc0cvzYSoFOzFiuVYKnkxAjpnJdcFUl+Ps+CxYYWUdVQYVWLMFnZvFj+vFDbN1ZsN2RMYcA oWyCj87VK0JsfmSS2omumYKVUhtJHUxNRWxtGC2s3yQFicLwgUjKFe4JK5n/D0RS89rUQa5lTR0/ cMHduWNhJPPVc6W0oQcBUtvpjOYXdjd5g5c8N9rq0k0AR3RZ8py9VbkkSwKkNC61chblulEOagVo f8LqVemfKvNL3tlHpbH9hU5UgGeKSRrnWmiDHFQGhHUeRSXrIzZU8IPhPqykkotz7468oyvmECc5 pOadxOsYBgubuBCjqsgLAEcaQ3UcMyqDCRrs/bmG4xVcZI/p4v4RXRl6nkbzmw2kOzCND9oU0DjX elxcaSxY6UCo4dXRj07X8D1o56DKaVxwWmlFBZikh4wGpJMzIXa+uX6Ud+y2RKqRmXTPRYKhTX0R LiYkMpg9r594/i2tZ78bi9ryng/EG9l3osfjkb/vBH/1r0FA5wwIdGi4cFzdA7v0gVm01xKE/gac 7+x+9VJ2qETBStoItx8XE3y1v7CCNzIao77xk3YdIsFX+8Xf1PTBn8Fa92KhvWBEjeEJ/v20/rzc PmVRsAjXi2D2ic2D5Xy9DeazzXq7zZZhFG7+3Dy0dzyz7neQxvCwVlbAYzRDskOKu6svwTeTXn7X oyAbrv2SBLHjbyr9CwAA//8DAFBLAwQUAAYACAAAACEAcUKePHUBAADeBAAAEAAAAHhsL2NhbGND aGFpbi54bWxslE1ugzAQhfeVegfL+8YYkvRHgSyo7Au0B7CIG5DARBhV7e1r1T9j7Cz5eJ55fjNw Ov9MI/qWix5mVWO6KzCSqpsvg7rW+PODPb1gpFehLmKclazxr9T43Dw+nDoxdm0vBoVMBaVr3K/r 7Y0Q3fVyEno336Qyb77mZRKreVyuRN8WKS66l3KdRlIWxZFMpgBuTh1aasxLjIYa7zEajRNMPKbG k+GHQFhG3h2pgsYVOyTFmO0BtXhpJNvqd4gzFizZKtDNlQXg2pfBj1MA4BVNG2eEV6+ZJif+SsgM AWJrs7O8Sq/Kq/tnWa6k2Vnq/W/7skzJgjLkZ5Zqm3kKeNqOpaClx3QqgWwdcWpvuYdhZMT1iwaY bZTfukhjXQNgGbCuQcFdOjGxOVbmO4vn53MEpc8xVTrvsFouKwA+ASDMJQCE0+f/PGNincXEfooR sesYARsBAO86JmkVlve2ddN/AQsj9qvEgtCnR8KfqfkDAAD//wMAUEsDBBQABgAIAAAAIQD15ydZ nwEAAG0DAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJyTwW7bMAyG7wP6DoZ6buSkwTAEsoohbdHDhgWI251VmY6F2pIgskbSp69sIY2zDT3s RvInfnwkJXGz79qsh4DG2YLNZznLwGpXGbsr2GN5f/WNZUjKVqp1Fgp2AGQ38uKL2ATnIZABzKKF xYI1RH7FOeoGOoWzKNuo1C50imIadtzVtdFw6/RrB5b4Is+/ctgT2AqqK/9hyJLjqqf/Na2cHvjw qTz4CCzFd+9boxXFKeVPo4NDV1N2t9fQCj4VRaTbgn4Nhg4yF3yaiq1WLayjsaxViyD4qSAeQA1L 2ygTUIqeVj1ociFD8xbXtmDZs0IYcArWq2CUpYg1tKVkjFuPFORvF16wASAUPDak4hhOe6exWcrl 2BCD88bBIIFE4RyxNNQC/qo3KtA/iJdT4pEh8SacdRwmu5xPAT9Qk7b4RLv+REuDTIce9xjx/wBe u84re5Clw8Y8K8GPBfHD2Bd89KW7VQTHU50XxbZRAap43aN+KoiHeKXQDibrRtkdVMeev4XhYT2l 3yPny1l+ncc3M6kJfvon8h0AAP//AwBQSwMEFAAGAAgAAAAhACP1TLBHAQAAaQIAABEACAFkb2NQ cm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySUUvDMBSF 3wX/Q8l7m7SzMkPbgcoexIFgh+JbSO62YpOGJNrt35u2W63OBx+Tc+6Xcy7JFntZB59gbNWoHMUR QQEo3ohKbXO0LpfhHAXWMSVY3SjI0QEsWhSXFxnXlDcGnkyjwbgKbOBJylKuc7RzTlOMLd+BZDby DuXFTWMkc/5otlgz/s62gBNCrrEExwRzDHfAUI9EdEQKPiL1h6l7gOAYapCgnMVxFONvrwMj7Z8D vTJxysodtO90jDtlCz6Io3tvq9HYtm3UzvoYPn+MX1ePz33VsFLdrjigIhOccgPMNaZ4YNKvx1sY ExmeCN0Sa2bdyu97U4G4Pfzynuue29cY4CACH4wONU7Ky+zuvlyiIiFxGpI0jEmZzGg6p1c3b93z P+a7oMOFPIb4DzEuSUrTlJJkQjwBigyffY7iCwAA//8DAFBLAQItABQABgAIAAAAIQDLn3dlfAEA AKgGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAh ALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAtQMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AGz7WUwpAQAA5gQAABoAAAAAAAAAAAAAAAAA2wYAAHhsL19yZWxzL3dvcmtib29rLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAHZlgWd4AQAAsAIAAA8AAAAAAAAAAAAAAAAARAkAAHhsL3dvcmtib29r LnhtbFBLAQItABQABgAIAAAAIQB8c4zytQQAAIUSAAAYAAAAAAAAAAAAAAAAAOkKAAB4bC93b3Jr c2hlZXRzL3NoZWV0NC54bWxQSwECLQAUAAYACAAAACEAb+tBNYADAAA+DAAAGAAAAAAAAAAAAAAA AADUDwAAeGwvd29ya3NoZWV0cy9zaGVldDIueG1sUEsBAi0AFAAGAAgAAAAhANUR4jAiAwAAaAkA ABgAAAAAAAAAAAAAAAAAihMAAHhsL3dvcmtzaGVldHMvc2hlZXQzLnhtbFBLAQItABQABgAIAAAA IQAQgAJh2QMAABoNAAAYAAAAAAAAAAAAAAAAAOIWAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQ SwECLQAUAAYACAAAACEA+2KlbZQGAACnGwAAEwAAAAAAAAAAAAAAAADxGgAAeGwvdGhlbWUvdGhl bWUxLnhtbFBLAQItABQABgAIAAAAIQCbPYBoIAEAAKUCAAAUAAAAAAAAAAAAAAAAALYhAAB4bC9z aGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAAIQDQzEiUSAIAAOwEAAANAAAAAAAAAAAAAAAA AAgjAAB4bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAHFCnjx1AQAA3gQAABAAAAAAAAAAAAAA AAAAeyUAAHhsL2NhbGNDaGFpbi54bWxQSwECLQAUAAYACAAAACEA9ecnWZ8BAABtAwAAEAAAAAAA AAAAAAAAAAAeJwAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQAj9UywRwEAAGkCAAAR AAAAAAAAAAAAAAAAAPMpAABkb2NQcm9wcy9jb3JlLnhtbFBLBQYAAAAADgAOAJADAABxLAAAAAA= ------=_NextPart_000_027F_01D08B74.6343CF80-- From nobody Sun May 10 23:39:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2619D1A1B45 for ; Sun, 10 May 2015 23:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCawXe5L6myb for ; Sun, 10 May 2015 23:39:51 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECAD61A1B2C for ; Sun, 10 May 2015 23:39:50 -0700 (PDT) Received: by lagv1 with SMTP id v1so86454506lag.3 for ; Sun, 10 May 2015 23:39:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Kzl23zIZ0mIhxGWvIupQbVaGhG4a4qG4QnSzLmJpATI=; b=VHQSORbd2pxeolPuG/Wf7Sm2MAsDrstP52++IP7rXqqNs5c2i5t/iTuVftI/Zg7t0F 4h6jBvPO5DMaeZQ60Gdcp/Y5rAPBmvvAatGfMlm/P4cHGqLJv7rXX3SXWzmwTA0kGtpr uiIrkzM9HMD27eJtxop6SYfrudc/0q1m3XKvif+xhRgvHFkEouMYUtTkNEFpUuSIXIgf 4ehHvg3X1ddSpYgGsaXjQP1sk8rmFNStAffSpME44eDIz7u1Ie5nbsw1VKXI1PEayHdU u9kBr5eMlL9EvkaiZ+gbvaVYZusqvhZgMR5ieo8IHyf7Rkb+nFtoPBoZuYo/x9iDzapF YNqQ== X-Gm-Message-State: ALoCoQmcMYJ9seZyQefI/lQFHVTJyUOfzTdtbJHWjCCjDnVRZDYQqPEIVb2KlRUEQGYkgrPAMK9G X-Received: by 10.153.4.43 with SMTP id cb11mr7098240lad.122.1431326389487; Sun, 10 May 2015 23:39:49 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by mx.google.com with ESMTPSA id dc7sm2837215lad.22.2015.05.10.23.39.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2015 23:39:48 -0700 (PDT) Message-ID: <55504EA3.7030405@sics.se> Date: Mon, 11 May 2015 08:39:31 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: cose@ietf.org References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> In-Reply-To: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040802010005070506090303" Archived-At: Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 06:39:53 -0000 This is a cryptographically signed message in MIME format. --------------ms040802010005070506090303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 05/11/2015 07:55 AM, Jim Schaad wrote: > - A payload of 19 bytes is assumed and it is assumed that the > content is being carried inside of the message. Just a quick comment on that one. In the world of sensor networks, the=20 payload of a message will often be a sensor reading, which could be as=20 small as e.g. a single floating point number or even an integer. So we=20 should assume we will get a significant number of payloads in the order=20 of magnitude of 2-4 bytes. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms040802010005070506090303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA1MTEwNjM5MzFaMCMGCSqGSIb3DQEJBDEW BBTNSvwZw3S1CNsCAF5PsCMZ9qTVUjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAXqInUpnYymM+TtqeJKT8hg2O9/91yP2QamU6ZuoHzVDrtOiYOtEGLvmxERAALZNL9Lsy rc4o6d494a1aVi4YzB+jtqoC30lLZ4FuYkCMXYHMpr+hpVeVHC3FjarImU08GeLtLEkeXpjn lFVKCB1p3F2/AAaYM42Tr8qbXtEHxmvmsTNdlMvxAb8HO0A2X/fHHGezR8s37o3bERK18Ldh INyYWYBui+zKjywLDT69qGtfLNJRtNIt4h5R5cjoawj0OSKc/9d9q8ZHWU4Mkopv5wE95f2o f0YVf1BKbc/J+8cAJ9t263OAARPu4V36eT21EEujOWj6CxC4a1U7PpEgSQAAAAAAAA== --------------ms040802010005070506090303-- From nobody Mon May 11 07:40:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D931A89AC for ; Mon, 11 May 2015 07:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC0espA0ryBU for ; Mon, 11 May 2015 07:40:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BF01A89A0 for ; Mon, 11 May 2015 07:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1221; q=dns/txt; s=iport; t=1431355215; x=1432564815; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=RTZWMZwtNMIwIxKIAzIDi05nbTaUfjUx9YeIci8VfN0=; b=RldmYfk8qSlcJzEfOkvkHRkemWlve4CIfKHDvzKbGAke5E1dTAePw+W9 DazPrfM95MVooBMtSoUApUqqiL4R6owbU7n8pEYfA7+XEZRzz0b9VXa5t cy7062LQiDAccGYMaRDPHnIE466HxxRkpcLDWR3LiIgHgJD3nqwxH4qSF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B2BAA9vlBV/5NdJa1cgw9UXgaDGMFWCYFQhg0CgTA4FAEBAQEBAQGBCoQhAQEEI1URCw4KAgIFFgsCAgkDAgECAUUGAQwGAgEBiCi0KZNAAQEBAQEBAQEBAQEBAQEBAQEBARUEgSGKGIRSOoJogUUBBIwbikCGRYdZjn4jgggdgXFQgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,407,1427760000"; d="scan'208";a="148951592" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 11 May 2015 14:40:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4BEeFbc030838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 May 2015 14:40:15 GMT Received: from [10.129.24.109] (10.129.24.109) by xhc-rcd-x15.cisco.com (173.37.183.89) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 09:40:14 -0500 Message-ID: <5550BF4E.1080003@cisco.com> Date: Mon, 11 May 2015 08:40:14 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jim Schaad , References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> In-Reply-To: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.109] Archived-At: Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:40:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 4/30/15 4:58 PM, Jim Schaad wrote: > Question: Identification of objects: a) CBOR Tag - either > general or specific to each type b) Required Identifier c) Use > the same techniques as JOSE I would prefer (b), but could live with (a). (b) makes an object that is self-contained. I don't see a new top-level field with a simple enumerated integer value to be that expensive, but would defer to the rest of the group. I object to (c). As does Jim, I find the JOSE technique to be overly complex and really don't like it. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVUL9OAAoJEDWi+S0W7cO1D00H/iqK2od3xeJHtUDeCKDXjVWZ zs5Wen1AxYoDzvErNZX3RM7Tpi7zHkOje+YhV+qFbQ04RgFKaXlrrje1uF0pCzpC YxWgCmp9cSQviU3o6sbjQ1F0ZoO5tYXOY7FS6ZJx8ZqIMjMhR1zwlF/fOgQc+dXH adF1WruOXNuVVjcvq3FfuMYxUoH/4aW2Tx0RR3s/Rf1DCSBQH6irJTebS4Ph2alr QDn8H2y1rfLNWKN16XT8Tz9YlCKzhy3Db0SWamGQIXWRt31qMdayj7edQJ1Q1a1h EexAaCOE8Bgp7KLefWH8rIo9LrDt0asj7KRJvuIGeDXhKMScQeVW1Ygkh0XrJHQ= =tl1m -----END PGP SIGNATURE----- From nobody Mon May 11 07:48:10 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7B1A8A42 for ; Mon, 11 May 2015 07:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RUaFR_4LdjX for ; Mon, 11 May 2015 07:48:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B1B1A8A3A for ; Mon, 11 May 2015 07:48:07 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.160.10; Mon, 11 May 2015 14:47:45 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0160.009; Mon, 11 May 2015 14:47:45 +0000 From: Mike Jones To: =?utf-8?B?4oyYIE1hdHQgTWlsbGVy?= , Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Issue: Identification of the top level objects Thread-Index: AdCDmResR3Con3VeQQyPrJ6q3RWIkgIX0xYAAAAvRhA= Date: Mon, 11 May 2015 14:47:45 +0000 Message-ID: References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> <5550BF4E.1080003@cisco.com> In-Reply-To: <5550BF4E.1080003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [193.1.64.12] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(54524002)(377454003)(24454002)(102836002)(77096005)(66066001)(15975445007)(107886002)(189998001)(5001960100002)(40100003)(86612001)(62966003)(2656002)(54356999)(92566002)(2501003)(19580395003)(77156002)(76176999)(87936001)(575784001)(33656002)(2900100001)(46102003)(122556002)(86362001)(50986999)(99286002)(2950100001)(5001770100001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 14:47:45.1124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:48:09 -0000 Sk9TRSBhbHJlYWR5IGRlZmluZXMgYSAidHlwIiBoZWFkZXIgcGFyYW1ldGVyIGZvciBleGFjdGx5 IHRoaXMgcHVycG9zZSwgd2hpY2ggdXNlcyBNSU1FIFR5cGVzLiAgTGV0J3MganVzdCB1c2UgaXQs IHJhdGhlciB0aGFuIGludmVudGluZyBzb21ldGhpbmcgZGlmZmVyZW50LiAgVGhlIHZhbHVlIG9m IGRpdmVyZ2VuY2UgaW4gdGhpcyBjYXNlIGlzbid0IHdvcnRoIHRoZSBkaXZlcmdlbmNlLCBhdCBs ZWFzdCBhcyBJIHNlZSBpdC4NCg0KCQkJCUNoZWVycywNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgPyBNYXR0IE1pbGxlcg0KU2VudDogTW9uZGF5LCBNYXkgMTEsIDIw MTUgMzo0MCBQTQ0KVG86IEppbSBTY2hhYWQ7IGNvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb Q29zZV0gSXNzdWU6IElkZW50aWZpY2F0aW9uIG9mIHRoZSB0b3AgbGV2ZWwgb2JqZWN0cw0KDQot LS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQpIYXNoOiBTSEE1MTINCg0KT24gNC8z MC8xNSA0OjU4IFBNLCBKaW0gU2NoYWFkIHdyb3RlOg0KPiBRdWVzdGlvbjogIElkZW50aWZpY2F0 aW9uIG9mIG9iamVjdHM6IGEpICBDQk9SIFRhZyAtIGVpdGhlciBnZW5lcmFsIG9yIA0KPiBzcGVj aWZpYyB0byBlYWNoIHR5cGUgYikgIFJlcXVpcmVkIElkZW50aWZpZXIgYykgIFVzZSB0aGUgc2Ft ZSANCj4gdGVjaG5pcXVlcyBhcyBKT1NFDQoNCkkgd291bGQgcHJlZmVyIChiKSwgYnV0IGNvdWxk IGxpdmUgd2l0aCAoYSkuIChiKSBtYWtlcyBhbiBvYmplY3QgdGhhdCBpcyBzZWxmLWNvbnRhaW5l ZC4gSSBkb24ndCBzZWUgYSBuZXcgdG9wLWxldmVsIGZpZWxkIHdpdGggYSBzaW1wbGUgZW51bWVy YXRlZCBpbnRlZ2VyIHZhbHVlIHRvIGJlIHRoYXQgZXhwZW5zaXZlLCBidXQgd291bGQgZGVmZXIg dG8gdGhlIHJlc3Qgb2YgdGhlIGdyb3VwLg0KDQpJIG9iamVjdCB0byAoYykuIEFzIGRvZXMgSmlt LCBJIGZpbmQgdGhlIEpPU0UgdGVjaG5pcXVlIHRvIGJlIG92ZXJseSBjb21wbGV4IGFuZCByZWFs bHkgZG9uJ3QgbGlrZSBpdC4NCg0KDQotIC0tDQotIC0gbSZtDQoNCk1hdHQgTWlsbGVyIDwgbWFt aWxsZTJAY2lzY28uY29tID4NCkNpc2NvIFN5c3RlbXMsIEluYy4NCg0KLS0tLS1CRUdJTiBQR1Ag U0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHL01hY0dQRzIgdjIuMC4yMiAoRGFyd2luKQ0K Q29tbWVudDogR1BHVG9vbHMgLSBodHRwczovL2dwZ3Rvb2xzLm9yZw0KDQppUUVjQkFFQkNnQUdC UUpWVUw5T0FBb0pFRFdpK1MwVzdjTzFEMDBIL2lxSzJvZDN4ZUpIdFVEZUNLRFhqVldaDQp6czVX ZW4xQXhZb0R6dkVyTlpYM1JNN1RwaTd6SGtPamUrWWhWK3FGYlEwNFJnRkthWGxycmplMXVGMHBD enBDDQpZeFdnQ21wOWNTUXZpVTNvNnNialExRjBab081dFlYT1k3RlM2Wkp4OFpxSU1qTWhSMXp3 bEYvZk9nUWMrZFhIDQphZEYxV3J1T1hOdVZWamN2cTNGZnVNWXhVb0gvNGFXMlR4MFJSM3MvUmYx RENTQlFINmlySlRlYlM0UGgyYWxyDQpRRG44SDJ5MXJmTE5XS04xNlhUOFR6OVlsQ0t6aHkzRGIw U1dhbUdRSVhXUnQzMXFNZGF5ajdlZFFKMVExYTFoDQpFZXhBYUNPRThCZ3A3S0xlZldIOHJJbzlM ckR0MGFzajdLUkp2dUlHZURYaEtNU2NRZVZXMVlna2gwWHJKSFE9DQo9dGwxbQ0KLS0tLS1FTkQg UEdQIFNJR05BVFVSRS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpDb3NlIG1haWxpbmcgbGlzdA0KQ29zZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQo= From nobody Mon May 11 08:04:33 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A3C1A8AC4 for ; Mon, 11 May 2015 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.311 X-Spam-Level: * X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YLiM1h2Q9dT for ; Mon, 11 May 2015 08:04:29 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EA71A8AA8 for ; Mon, 11 May 2015 08:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 17B39E2036; Mon, 11 May 2015 11:04:28 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00627-03; Mon, 11 May 2015 11:04:25 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 54683E2034; Mon, 11 May 2015 11:04:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431356665; bh=2eXo8WhT9eGMkJzTbdxt3iZqQLpLs079yrjTvV2CUZI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=glMjoAWVDtv6M3ZbIBilnnpDeepXnYxe/43hORbQA2M5XnMyvToO7gQAw24mhwc6H cbgG0UuyXtVh7m5ZHFJXQ3pufCHFYGxrDB3V1TIYJnd21yM7BhcSodXWx7VC7RwCFC yPKuIYnO7GkFBakvcUG3FobTAgT9KKxKIZUo+n/o= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4BF4OUd018956; Mon, 11 May 2015 11:04:24 -0400 From: Derek Atkins To: "Jim Schaad" References: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> Date: Mon, 11 May 2015 11:04:24 -0400 In-Reply-To: <001901d08399$020fcfd0$062f6f70$@augustcellars.com> (Jim Schaad's message of "Thu, 30 Apr 2015 15:57:17 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management in the World of COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:04:32 -0000 Hi Jim, Sorry for the late LATE response. My current use case is purely #5. I see value in many of the others, but currently I only see myself using #5 in my current product line. -derek "Jim Schaad" writes: > I wanted to try and look closer at Carsten's call for more numbers in > different applications, but before I can do that I need to figure out what > applications there are and which ones are currently thought to be of greater > importance. I have tried to start by looking at the different security > constructs that may be used for these applications in terms of what the > needed security characteristics are. > > 1. Integrity based on recipient asymmetric key: I expect that this is not a > common scenario to happen for CoRE systems. This scenario requires that the > sender get a certified public key for the recipient and uses that, along > with some ephemeral data local to it, to create a short term shared secret > used to protect the integrity of the message. This scenario provides no > indication of where the data originated, thus it can be used to create a > message for multiple recipients. An example of how this would be > implemented is the use of CBC-MAC with ECDH-ES key agreement plus KDF. > > 2. Integrity and low-level origination based on a short term shared key: > Under the current system this would be setup using a DTLS session along with > an extractor to establish the key. The key would be for "short-term" use > (i.e. hours not days or weeks). The option only provides for > point-to-point integrity not end-to-end integrity. Integrity can be forged > by any party that knows the shared-secret. In this mode, there needs to be > a single recipient of the message. If this condition is met, origination is > shown by saying "I did not make this message so the other party must have > done so." Origin of the message cannot be proved to a third party. An > example of how this would be implemented is the use of CBC-MAC with direct > key. > > 3. Integrity and low-level origination based on a long term shared key: > Under the current system this would be setup using a pair-wise key > established between two entities. The key would be for "long-term" use > (i.e. weeks or months). Given that this is a long term used key, the > problem of replay and potential forgeries is greater. For this reason, > some type of key derivation on the shared security would be suggested. The > option only provides for end-to-end integrity between the parties. > Integrity can be forged by any party that knows the shared-secret. In this > mode, there needs to be a single recipient of the message. If this > condition is met, origination is shown by saying "I did not make this > message so the other party must have done so." Origin of the message cannot > be proved to a third party. An example of how this would be implemented is > the use of CBC-MAC with direct key plus KDF. > > 4. Integrity and low-level origination based on two asymmetric keys: This > scenario requires that both the recipient and sender of the message have > well known key agreement keys. Both entities must be able to get these > either from a trusted third party or over some type of protocol that > includes doing a proof-of-possession check on both sides. Once this is > done, a one-time shared security is generated that is used to provide both > end-to-end integrity protection and a degree of origination knowledge. > Origination of the message cannot be proved to a third party. Both parties > must have a key that is in the same group. A uniqueness value must be > interjected into the key agreement process by at least one of the parties. > It is sufficient that a counter be used for this purposes, it is not > necessary for this value to be random. An example of how this would be > implemented is the use of CBC-MAC with a ECDH-SS key agreement plus KDF. > > 5. Integrity and high-level origination based on sender asymmetric key: > This scenario requires that a true signature algorithm be defined and used > as well as the ability for a recipient to query a trusted third party that > the binding of identity and public key is true. Using this allows for the > origination and integrity of a message to be proved to a third party, the > signature is not directed at any specific party. An example of how this > would be implemented is the use of ECDSA with SHA-256. > > 6. Confidentiality and integrity based on recipient asymmetric key: This > scenario shares most of the same functionality as does scenario 1. The > required integrity can be obtained by the use of an AEAD algorithm rather > than a MAC algorithm. An example of how this would be implemented is the > use of AES-CCM with ECDH-ES key agreement plus KDF. > > 7. Confidentiality, integrity and low-level origination based on a short > term shared key: This scenario shares most of the same functionality as does > scenario 2. The required integrity can be obtained by the use of an AEAD > algorithm rather than a MAC algorithm An example of how this would be > implemented is the use of AES-CCM with direct key. > > 8. Confidentiality, integrity and low-level origination based on a long term > shared key: This scenario shares most of the same functionality as does > scenario 3. The required integrity can be obtained by the use of an AEAD > algorithm rather than a MAC algorithm. An example of how this would be > implemented is the use of AES-CCM with direct key plus KDF. > > 9. Confidentiality, integrity and low-level origination based on two > asymmetric keys: This scenario shares most of the same functionality as > does scenario 4. The required integrity can be obtained by the use of an > AEAD algorithm rather than a MAC algorithm. An example of how this would be > implemented is the use of AES-CCM with ECDH-SS key agreement plus KDF. > > 10. Confidentiality, integrity and high-level origination based on sender > asymmetric key: This scenario shares the integrity and origination > requirements of scenario 5, however the algorithm choice there does not > provide an confidentiality. A different confidentiality mechanism must be > used. Any of the methods used in scenarios 5-9 could be used for this > purpose. Getting both sets of functionality will required the use of a > wrapped message scenario where the signed message is wrapped inside of an > encrypted message. (Attempting to do both in the same message was removed > between PKCS #7 and CMS due to security flaws. It was possible to both > determine who the message signer was and to do traffic analysis on the > content of the message by looking at the hash of the resulting signature.) > > Which of these ten scenarios do we believe are going to be commonly used? > What percentage of the time do we think these options are going to be used? > This will give us some starting data to look at which structures are going > to be the most commonly used and get a start on which fields in the > structures are going to be present. There will be some follow on questions > to try and make this determination. > > Jim > > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 11 08:15:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFFB1A8AD9 for ; Mon, 11 May 2015 08:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZFJO8ufMyTN for ; Mon, 11 May 2015 08:15:38 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825DD1A8AC7 for ; Mon, 11 May 2015 08:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0F6E0E2036; Mon, 11 May 2015 11:15:35 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00655-06; Mon, 11 May 2015 11:15:33 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 933A4E2034; Mon, 11 May 2015 11:15:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431357333; bh=abIvuRJNLlWWwU86jMr0Ev8hArY1GvgYCehAM5DjLP0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=gQcnyBjpmTrvghj+t5dJcphjlbXDLKT+IuQ8Py+0ndAKydPN+NBqdlrST+TNQH+x8 fdGdEZNIxGoo5uMePWxge6nRwWDo4SiUFq00UeUPyk4oz6JksqAicpzS/PtXU0A6pf Yw2KseY07a/xwmQYljHZo3bUp/GEC5mezUz28BPA= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4BFFXNf019832; Mon, 11 May 2015 11:15:33 -0400 From: Derek Atkins To: =?utf-8?Q?=E2=8C=98?= Matt Miller References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> <5550BF4E.1080003@cisco.com> Date: Mon, 11 May 2015 11:15:33 -0400 In-Reply-To: <5550BF4E.1080003@cisco.com> (=?utf-8?Q?=22=E2=8C=98?= Matt Miller"'s message of "Mon, 11 May 2015 08:40:14 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , cose@ietf.org Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:15:38 -0000 =E2=8C=98 Matt Miller writes: > On 4/30/15 4:58 PM, Jim Schaad wrote: >> Question: Identification of objects: a) CBOR Tag - either >> general or specific to each type b) Required Identifier c) Use >> the same techniques as JOSE > > I would prefer (b), but could live with (a). (b) makes an object that > is self-contained. I don't see a new top-level field with a simple > enumerated integer value to be that expensive, but would defer to the > rest of the group. > > I object to (c). As does Jim, I find the JOSE technique to be overly > complex and really don't like it. +1 In my use case I'm nesting a bunch of objects so it would be useful to have them be tagged compactly. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 11 08:20:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202CC1A8BBE for ; Mon, 11 May 2015 08:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owGcY_6jQXow for ; Mon, 11 May 2015 08:20:47 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D701A8AFC for ; Mon, 11 May 2015 08:20:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5F85CE2036; Mon, 11 May 2015 11:20:43 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00627-09; Mon, 11 May 2015 11:20:41 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 761AFE2034; Mon, 11 May 2015 11:20:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431357641; bh=dpoYbe0YoT8WO0c0hrO8VjPt5ufOh3mqNBxgpv5oQeQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=s6f2lhvjLWrtPNZFGVbxDTbjsEGjO+gHCovdv4CgW51D/QV0/UcqrQ+NOMYaE1QU/ mWD06mCbStfd1nnLOPN4bMWOubwJXD9EeKr0E47zkcJuTBef4jMedeuQdLWBEsMTA2 BnRuPpnrVMTjKuCfJt6Td8xNcnA1SORroGZQsAnQ= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4BFKe9l020260; Mon, 11 May 2015 11:20:40 -0400 From: Derek Atkins To: Paul Hoffman References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <724B1E60-A92F-42EB-B7BD-732A6B19ECCA@vpnc.org> <00e601d08904$d7eecb90$87cc62b0$@augustcellars.com> <7FA52A2F-1612-487E-9096-4EE939B99BD2@vpnc.org> Date: Mon, 11 May 2015 11:20:40 -0400 In-Reply-To: <7FA52A2F-1612-487E-9096-4EE939B99BD2@vpnc.org> (Paul Hoffman's message of "Thu, 7 May 2015 13:54:24 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:20:48 -0000 Paul Hoffman writes: > On May 7, 2015, at 1:31 PM, Jim Schaad wrote: >> Based on your comment I am not sure if I was clear about what I was asking - >> Please let me know either way. >> >> 1. Gives a result of {"unprotected":xxx, "cipher_text":xxx, "header":xxx, >> "encryptd_key":xxx } >> 2. Gives a result of {"unprotected"xxx", "cipher_text"xxx, >> "recipients":{"header":xxx, "encrypted_key":xxx }} >> 3 Gives a result of {"unprotected":xxx", "cipher_text":xxx, >> "recipients:[{"header":xxx, "encrypted_key":xxx}]} >> >> Labels disappear if the top level is an array and not a map - but no other >> significant changes. > > Right, I completely misunderstood your shorthand. Given these, (c) > seems better: it keeps the structure predictable, with a possible > reduction of code for processing the structure (but not much, > admittedly). +1 -- it should always be an array of recipients, even if it only has a single element. > --Paul Hoffman > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 11 08:22:59 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9051A8BBE for ; Mon, 11 May 2015 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vealH64Rcdk for ; Mon, 11 May 2015 08:22:57 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8851A8F45 for ; Mon, 11 May 2015 08:22:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7DD0DE2036; Mon, 11 May 2015 11:22:50 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00655-10; Mon, 11 May 2015 11:22:47 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 8DFD8E2034; Mon, 11 May 2015 11:22:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431357767; bh=Vvtja5UEHFTjQ97sENmnBzDYioqSjfP8RTFsnnTauWc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=nQm235eMHTvWX4G8+8urapaFQFvraY7hc4l1/TUwEAS8NWBTW65d1HZm7zCz8MkCh 2wZspzQtGIjjxXSuvO1HArDvuMQVaf0s0bDkdJWHRi3oM/F5KA0M3I4iDXb0DjesKG 19shRVDEak0puRyzfsTNWRUtCZQgBDNG2JNI5znY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4BFMl3u020445; Mon, 11 May 2015 11:22:47 -0400 From: Derek Atkins To: "Jim Schaad" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> Date: Mon, 11 May 2015 11:22:47 -0400 In-Reply-To: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> (Jim Schaad's message of "Thu, 30 Apr 2015 16:00:01 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:22:58 -0000 I believe that yes, the map should be reused, however if we do that I wonder whether you need to add a tag that says whether it's an encrypted key or encrypted 'data'? -derek "Jim Schaad" writes: > Question: Reuse Encrypt body map for recipients > > Discussion: > > The concept of using the same structure for both recipients and the base > encryption map was introduced to the JOSE working group at the Denver > meeting. The JOSE working group rejected the idea as being too much of a > change to make in the current working code. The concept is that the same > data structure, with the same elements is used to encode both the content > encryption and each of the recipient structures. While in JOSE, many of the > same elements are not present in the recipient structure (i.e. iv and aad), > some of these elements later appeared as part of algorithm descriptions (iv > is a header parameter defined for AES-GCM key wrapping). > > Using the same structure for encrypting content as well as encrypting keys > allows for some neat tricks to be played at a later date if needed. One > example is that you could separate the key wrapping algorithm, and the > ECDH-KDF algorithm pair into separate layers. This allows one to move > towards a Chinese Menu method of selecting and using algorithms rather than > the current algorithm suite method. While I would not recommend that this > happen in the current specification, it might be nice to keep it open as an > option to be used in the future as new algorithms are added. > > Another advantage of doing this folding is in code size. In my > implementation, I have created the recipient class as inheriting from the > encryption body class. The recipient class contains only code that deals > with the cryptography of key management. All of the encoding/decoding is > handled by the base encryption class. If the structures are kept separate > as they are today then that code would need to be added to the recipient > class. While my code does not currently deal with idea of having multiple > layers of key management. I believe that this would be a minimal addition > to the current code base. > > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 11 08:28:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2E1A8AE3 for ; Mon, 11 May 2015 08:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QRw60KViNpr for ; Mon, 11 May 2015 08:28:34 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333691A9061 for ; Mon, 11 May 2015 08:28:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3544CE2036; Mon, 11 May 2015 11:28:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00872-04; Mon, 11 May 2015 11:28:14 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 27C34E2034; Mon, 11 May 2015 11:28:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431358094; bh=AfI1roEx4VVxpYERY5EIe24+vbwjQFtZIyHSxqw8iYA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=kJRpitjWGPdepgYSJnW9FHaILYIejz//REoXIXMa8yj/SzarjTBdoYguWmhsrCWBW jLQ/Bys/nFe/5p/EzNFl51msHNq+rHjJUe7k7wS3YCSJYLQseij+fI0bVzgtb6B7pm 9vJl0SYzQNbddDK3Cwpc6RnscBfCEIjpvB/6L3HQ= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4BFSDf5020968; Mon, 11 May 2015 11:28:13 -0400 From: Derek Atkins To: Ludwig Seitz References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> <55504EA3.7030405@sics.se> Date: Mon, 11 May 2015 11:28:13 -0400 In-Reply-To: <55504EA3.7030405@sics.se> (Ludwig Seitz's message of "Mon, 11 May 2015 08:39:31 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:28:35 -0000 Ludwig Seitz writes: > On 05/11/2015 07:55 AM, Jim Schaad wrote: > >> - A payload of 19 bytes is assumed and it is assumed that the >> content is being carried inside of the message. > > Just a quick comment on that one. In the world of sensor networks, the > payload of a message will often be a sensor reading, which could be as > small as e.g. a single floating point number or even an integer. So we > should assume we will get a significant number of payloads in the > order of magnitude of 2-4 bytes. In my experience we've found that it's better to combine a bunch of sensor readings together, specifically because they are so small that the added overhead of separating them because unwieldly. > /Ludwig -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 11 08:35:19 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170A21A9043 for ; Mon, 11 May 2015 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIq3wKFZtpBR for ; Mon, 11 May 2015 08:35:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5134D1A1B30 for ; Mon, 11 May 2015 08:35:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2927AE2036; Mon, 11 May 2015 11:35:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00862-06; Mon, 11 May 2015 11:35:10 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id BEE4BE2034; Mon, 11 May 2015 11:35:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431358510; bh=T2HZ/2FW3+IJXWVRTegHMyMceiqun34xP0HLf+0cr3Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=UtSryCkBTGaMvoo8R+B8d4id1SZ/UEh+3l/4o6OUP/REPS1N4yRmiAausJsabC01x mkEH8woSZdDJBqT0+1PxgcrR2ZF66T9KI6yxyzbGlqYXmnZI65A3eeFA6P8DlYlH6d 5FtkTX/Zp9S6G7FGLsARkmJaOB2GAwamIODHKtgY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4BFZAhT021454; Mon, 11 May 2015 11:35:10 -0400 From: Derek Atkins To: "Jim Schaad" References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> Date: Mon, 11 May 2015 11:35:10 -0400 In-Reply-To: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> (Jim Schaad's message of "Sun, 10 May 2015 22:55:18 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:35:18 -0000 Jim, "Jim Schaad" writes: > I have spent a couple of days looking at messages that are likely to be sent > for the world of CoRE/ACE based on the draft > https://tools.ietf.org/html/draft-selander-ace-object-security-01 and the > response on key management that I got back recently. I have made several > assumptions in doing the computations. I have included my spreadsheet of > the different cases so that you can look at where I had assigned bytes used. > If people have other cases where they would like to get sizes computed, > please send them to me and I can run the numbers. Thank you for this work! > Case #1 - MAC on a content using a direct key. I am assuming, probably [snip] > - In this case using maps takes 62 octets and using arrays takes 63 > octets. > > Case #2 - Encryption on a content using a direct key. The details of the [snip] > - In this case using maps takes 60 octets and using arrays takes 61 > octets. > > Case #3 - Sign a message using an asymmetric key. The details of the [snip] > - In this case using maps takes 82 bytes and arrays takes 83 bytes. > If content is included, then the array will be the same size as for map. > > Case #4 - Sign a message using an asymmetric key and encrypt it using a [snip] > - For map, the size is 145 octets, for array the size is 146 octets. > > For all of the cases that I have provided above, I am using the minimal set > of fields. If any other fields are added, for example unprotected > attributes, then the balance tips from maps to arrays as the cost to add a > field is 2 octets plus the data, whereas the cost to add a field to an array > is just the size of the data. So in the minimal case it definitely sounds like a map provides a tiny edge in the data size over an array. In my use case (#3 above) I do expect that I'll have the payload included as opposed to detacted, so in my case the sizes are equivalent. However I feel that a map also enables future extensions easier than an array, in particular if you have future optional features. Not that I can currently think of what extensions might occur, but I'm not omniscient either ;) Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 11 11:54:07 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B931A87EB for ; Mon, 11 May 2015 11:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSShADnkmmRL for ; Mon, 11 May 2015 11:54:03 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499EE1A87E3 for ; Mon, 11 May 2015 11:54:03 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 99E7B2CA47 for ; Mon, 11 May 2015 11:54:02 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 11 May 2015 11:52:37 -0700 Message-ID: <006b01d08c1b$a6831b00$f3895100$@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: AdCMD4iwiwDWGFPrQzmf6gFdLBxZmw== Content-Language: en-us Archived-At: Subject: [Cose] Parameterization of CCM mode X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:54:05 -0000 As part of looking at the sizes of encodings for items, I was looking at the use of CCM mode and trying to make guesses about what the parameters are that are going to be used in constrained devices. Trying to get the info from https://tools.ietf.org/html/draft-selander-ace-object-security-01 did not really help as it seemed to not have the correct set encoded into it. The parameters that I have identified for CCM are the following: 1) Key size - 128, 192, 256 2) M - number of octets in the authentication field - 4, 6, 8, 10, 12, 14, 16 3) L - number of octets in the length field - 2-8 octets The key size does not affect the size of the output so it is not a big issue relative to things. While I would guess that generally only 128-bit keys are used, it would probably makes sense to define at least 128 and 256 bit key algorithms The size of the authentication fields is currently defined as 8 from the Selander draft. It would make sense to have at least two sizes defined - 8 and 16, but I am not sure about other sizes. The hardest one to make decisions on is the message length field. For constrained devices this could be a very small value as a value of 2 would all for encrypting 2^(8*2) bytes and would allow for the key to be used a lot as one then has a nonce of 15-2=13 bytes (allowing for a key to be used ~ 2^13 times assuming no birthday attacks). Nonce values as 15-L bytes long and nonce values must not be re-used. On the other hand, for a more general usage it makes sense to have a larger value of L to allow for bigger messages with less key re-usage. The Selander draft appears to make the assumption that different keys are used in each direction when encrypting messages. This makes one problem easier - there is no need to divide up the nonce space so that nonce values are not re-used when encrypting messages. It also makes nonce usage easier because there is no need to try and synchronize the nonce value usage between the two parties. On the other hand, it means that there is more data that needs to be keep on the device as you now need 2 keys and 2 nonce counters for each pair-wise link which might be a space issue on the device. In the Selander draft, there was the idea of having both a nonce counter and salt value which is used to construct the nonce used in the encryption step. As far as I know there is no security reason to salt the nonce unless there is an expectation that the keys would ever be re-used. If new keys are generated each time that keys are generated then the salt is probably not necessary to have. However, use of a salt value can be used to divide up the nonce space if the same key value is used in both directions. While we need to do more research on figuring out how many times a key can be used based on the nonce length, this is probably not dependent on the values of L that we want to standardize. The more items we standardize the more selection different protocols will have, but I don't know how much parameterization the implementations support or if they are using fixed parameterization. Jim From nobody Mon May 11 13:38:38 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B27E1A901E for ; Mon, 11 May 2015 13:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcrjlEYJ_je0 for ; Mon, 11 May 2015 13:38:34 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14D61A902A for ; Mon, 11 May 2015 13:38:34 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4ABE72CA20; Mon, 11 May 2015 13:38:34 -0700 (PDT) From: "Jim Schaad" To: "'Ludwig Seitz'" , References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> <55504EA3.7030405@sics.se> In-Reply-To: <55504EA3.7030405@sics.se> Date: Mon, 11 May 2015 13:37:08 -0700 Message-ID: <007b01d08c2a$40b20cf0$c21626d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIRw4TV5Qa1tmqUq/LMooYCv8FDfgIaX6gznOP5J5A= Content-Language: en-us Archived-At: Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 20:38:36 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Ludwig Seitz > Sent: Sunday, May 10, 2015 11:40 PM > To: cose@ietf.org > Subject: Re: [Cose] Sizes of messages >=20 > On 05/11/2015 07:55 AM, Jim Schaad wrote: >=20 > > - A payload of 19 bytes is assumed and it is assumed that the > > content is being carried inside of the message. >=20 > Just a quick comment on that one. In the world of sensor networks, the > payload of a message will often be a sensor reading, which could be as small > as e.g. a single floating point number or even an integer. So we = should > assume we will get a significant number of payloads in the order of > magnitude of 2-4 bytes. >=20 > /Ludwig I kind of just chose an arbitrary number, this does not change what the overhead of sending a message is The break points on message sizes = from the size of CBOR are at 24/25 bytes (tag and length goes from 1 to 2 = bytes) and at 255/267 bytes (tag and length from 2 bytes to 3 bytes). The next break would be at 2^24 bytes. =20 If you care about the ratio of content to overhead then knowing an exact message size matters otherwise it probably doesn't. If you sizes are really that small, what are you doing about dealing = with replay - are you assuming that is all covered in the security overhead rather than in your base message size? Jim >=20 > -- > Ludwig Seitz, PhD > SICS Swedish ICT AB > Ideon Science Park > Building Beta 2 > Scheelev=E4gen 17 > SE-223 70 Lund >=20 > Phone +46(0)70-349 92 51 > http://www.sics.se From nobody Mon May 11 14:15:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C982A1A877F for ; Mon, 11 May 2015 14:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xuzo_2JroTHL for ; Mon, 11 May 2015 14:15:16 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039451A7035 for ; Mon, 11 May 2015 14:15:15 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0C17B2C9BB; Mon, 11 May 2015 14:15:14 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <001a01d08399$26fe9d80$74fbd880$@augustcellars.com> <5550BF4E.1080003@cisco.com> In-Reply-To: Date: Mon, 11 May 2015 14:13:49 -0700 Message-ID: <008001d08c2f$609603a0$21c20ae0$@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: AQHsJwC5M2J6P0ogmMRJ78f4EU04JwK6VZYVAisC6iadGOTvsA== Content-Language: en-us Archived-At: Subject: Re: [Cose] Issue: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 21:15:18 -0000 Of course in the world of JOSE, using this header cannot be done with a = simple single call.=20 First it can be placed in either the protected or unprotected headers = meaning that you have a couple of places to look. Second while the headers are called "protected" and "unprotected" and = are at the top level for an encrypted message. For a signed message the = headers are called "protected" and "header" and are part of the = signature field, meaning that there two different levels that need to be = looked at. Finally, the description for "typ" in JWS states This is intended for use by the application when more than one kind of object could be present in an application data structure that can contain a JWS; the application can use this value to disambiguate among the different kinds of objects that might be present. Which is not the same as saying it should be used to disambiguate = between an encrypted message, a MAC-ed message and a signed message. Without some changes, I am not sure that this really maps to the same = thing we are trying to accomplish. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, May 11, 2015 7:48 AM > To: =E2=8C=98 Matt Miller; Jim Schaad; cose@ietf.org > Subject: RE: [Cose] Issue: Identification of the top level objects >=20 > JOSE already defines a "typ" header parameter for exactly this = purpose, > which uses MIME Types. Let's just use it, rather than inventing = something > different. The value of divergence in this case isn't worth the = divergence, at > least as I see it. >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of ? Matt Miller > Sent: Monday, May 11, 2015 3:40 PM > To: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] Issue: Identification of the top level objects >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 4/30/15 4:58 PM, Jim Schaad wrote: > > Question: Identification of objects: a) CBOR Tag - either general = or > > specific to each type b) Required Identifier c) Use the same > > techniques as JOSE >=20 > I would prefer (b), but could live with (a). (b) makes an object that = is self- > contained. I don't see a new top-level field with a simple enumerated = integer > value to be that expensive, but would defer to the rest of the group. >=20 > I object to (c). As does Jim, I find the JOSE technique to be overly = complex > and really don't like it. >=20 >=20 > - -- > - - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org >=20 > iQEcBAEBCgAGBQJVUL9OAAoJEDWi+S0W7cO1D00H/iqK2od3xeJHtUDeCKDXj > VWZ > zs5Wen1AxYoDzvErNZX3RM7Tpi7zHkOje+YhV+qFbQ04RgFKaXlrrje1uF0pCzp > C > YxWgCmp9cSQviU3o6sbjQ1F0ZoO5tYXOY7FS6ZJx8ZqIMjMhR1zwlF/fOgQc+d > XH > adF1WruOXNuVVjcvq3FfuMYxUoH/4aW2Tx0RR3s/Rf1DCSBQH6irJTebS4Ph2a > lr > QDn8H2y1rfLNWKN16XT8Tz9YlCKzhy3Db0SWamGQIXWRt31qMdayj7edQJ1Q > 1a1h > EexAaCOE8Bgp7KLefWH8rIo9LrDt0asj7KRJvuIGeDXhKMScQeVW1Ygkh0XrJH > Q=3D > =3Dtl1m > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon May 11 14:43:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6142E1A90A0 for ; Mon, 11 May 2015 14:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeavTOIHEq9Q for ; Mon, 11 May 2015 14:43:26 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5A71A0041 for ; Mon, 11 May 2015 14:43:26 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0C4272C9BB; Mon, 11 May 2015 14:43:25 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> In-Reply-To: Date: Mon, 11 May 2015 14:42:00 -0700 Message-ID: <008401d08c33$504feb60$f0efc220$@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: AQHbZlBKHCCSWnQMz2VzSyrGcf61KQDaoPGQnVq9qfA= Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 21:43:28 -0000 At the present time, that information can easily be inferred by context. In the event that we want to talk about use the "recipient" structure as a top level object then I think this question would need to be revisited. Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Monday, May 11, 2015 8:23 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > I believe that yes, the map should be reused, however if we do that I > wonder whether you need to add a tag that says whether it's an encrypted > key or encrypted 'data'? > > -derek > > "Jim Schaad" writes: > > > Question: Reuse Encrypt body map for recipients > > > > Discussion: > > > > The concept of using the same structure for both recipients and the > > base encryption map was introduced to the JOSE working group at the > > Denver meeting. The JOSE working group rejected the idea as being too > > much of a change to make in the current working code. The concept is > > that the same data structure, with the same elements is used to encode > > both the content encryption and each of the recipient structures. > > While in JOSE, many of the same elements are not present in the > > recipient structure (i.e. iv and aad), some of these elements later > > appeared as part of algorithm descriptions (iv is a header parameter > defined for AES-GCM key wrapping). > > > > Using the same structure for encrypting content as well as encrypting > > keys allows for some neat tricks to be played at a later date if > > needed. One example is that you could separate the key wrapping > > algorithm, and the ECDH-KDF algorithm pair into separate layers. This > > allows one to move towards a Chinese Menu method of selecting and > > using algorithms rather than the current algorithm suite method. > > While I would not recommend that this happen in the current > > specification, it might be nice to keep it open as an option to be used in the > future as new algorithms are added. > > > > Another advantage of doing this folding is in code size. In my > > implementation, I have created the recipient class as inheriting from > > the encryption body class. The recipient class contains only code > > that deals with the cryptography of key management. All of the > encoding/decoding is > > handled by the base encryption class. If the structures are kept separate > > as they are today then that code would need to be added to the > > recipient class. While my code does not currently deal with idea of > > having multiple layers of key management. I believe that this would > > be a minimal addition to the current code base. > > > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Mon May 11 15:25:31 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32CB1A90EA for ; Mon, 11 May 2015 15:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW89zU5HTpuL for ; Mon, 11 May 2015 15:25:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF511A90CF for ; Mon, 11 May 2015 15:25:27 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.160.10; Mon, 11 May 2015 22:25:19 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0160.009; Mon, 11 May 2015 22:25:19 +0000 From: Mike Jones To: Jim Schaad , 'Derek Atkins' Thread-Topic: [Cose] Issue: Reuse the Enrypt structure for recipients Thread-Index: AdCDmVTi0lJyO1ENSaipAaz9l4o5TgIZQmWBAA08RwAAAVZ3kA== Date: Mon, 11 May 2015 22:25:19 +0000 Message-ID: References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> In-Reply-To: <008401d08c33$504feb60$f0efc220$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [5.149.172.123] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(19580405001)(189998001)(15974865002)(5001960100002)(40100003)(2656002)(2900100001)(19580395003)(87936001)(74316001)(86362001)(122556002)(86612001)(2950100001)(66066001)(76176999)(50986999)(54356999)(33656002)(102836002)(15975445007)(77096005)(99286002)(46102003)(5001770100001)(92566002)(76576001)(77156002)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 22:25:19.2961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:25:29 -0000 >From my point of view, the JOSE WG didn't reject encrypting a JWK to repres= ent the encrypted key because it was a change. The working group rejected = it because there was no need to carry any data that would remain unused abo= ut the encrypted key, when just the the encrypted key value itself would do= . Particularly in a space-constrained environment, carrying extra metadata= about a key that will only be discarded seems wasteful in the extreme. I would advocate having the encrypted_key value remain only an encrypted fo= rm of the CEK value, adding nothing extra. - Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, May 11, 2015 10:42 PM To: 'Derek Atkins' Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients At the present time, that information can easily be inferred by context. I= n the event that we want to talk about use the "recipient" structure as a t= op level object then I think this question would need to be revisited. Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Monday, May 11, 2015 8:23 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >=20 > I believe that yes, the map should be reused, however if we do that I=20 > wonder whether you need to add a tag that says whether it's an=20 > encrypted key or encrypted 'data'? >=20 > -derek >=20 > "Jim Schaad" writes: >=20 > > Question: Reuse Encrypt body map for recipients > > > > Discussion: > > > > The concept of using the same structure for both recipients and the=20 > > base encryption map was introduced to the JOSE working group at the=20 > > Denver meeting. The JOSE working group rejected the idea as being=20 > > too much of a change to make in the current working code. The=20 > > concept is that the same data structure, with the same elements is=20 > > used to encode both the content encryption and each of the recipient st= ructures. > > While in JOSE, many of the same elements are not present in the=20 > > recipient structure (i.e. iv and aad), some of these elements later=20 > > appeared as part of algorithm descriptions (iv is a header parameter > defined for AES-GCM key wrapping). > > > > Using the same structure for encrypting content as well as=20 > > encrypting keys allows for some neat tricks to be played at a later=20 > > date if needed. One example is that you could separate the key=20 > > wrapping algorithm, and the ECDH-KDF algorithm pair into separate=20 > > layers. This allows one to move towards a Chinese Menu method of=20 > > selecting and using algorithms rather than the current algorithm suite = method. > > While I would not recommend that this happen in the current=20 > > specification, it might be nice to keep it open as an option to be=20 > > used in the > future as new algorithms are added. > > > > Another advantage of doing this folding is in code size. In my=20 > > implementation, I have created the recipient class as inheriting=20 > > from the encryption body class. The recipient class contains only=20 > > code that deals with the cryptography of key management. All of the > encoding/decoding is > > handled by the base encryption class. If the structures are kept separate > > as they are today then that code would need to be added to the=20 > > recipient class. While my code does not currently deal with idea of=20 > > having multiple layers of key management. I believe that this would=20 > > be a minimal addition to the current code base. > > > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Mon May 11 15:31:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C875C1A90EA for ; Mon, 11 May 2015 15:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uh6BmIMlugr for ; Mon, 11 May 2015 15:31:39 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CA01A90CF for ; Mon, 11 May 2015 15:31:39 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D0D342CA48 for ; Mon, 11 May 2015 15:31:38 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 11 May 2015 15:30:13 -0700 Message-ID: <008501d08c3a$0c80bde0$258239a0$@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: AdCMObiyqe9RKIH7R3KD00qjqIElIg== Content-Language: en-us Archived-At: Subject: [Cose] Reuse of Content Encryption Keys X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:31:40 -0000 I want to call the groups attention to this RFC "RFC 3185: Reuse of CMS Content Encryption Keys" (https://tools.ietf.org/html/rfc3185). The draft talks about a method in CMS to start with an asymmetric operation on a CMS message followed by sending a number of messages back and forth that use a symmetric key which can be computed from the original CEK value. I don't know that it makes any sense for the group to adopt a similar methodology, but I did want to make sure that group did at least see it. Jim From nobody Mon May 11 15:40:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881E21A92B8 for ; Mon, 11 May 2015 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOgLKfKmNeD3 for ; Mon, 11 May 2015 15:40:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C6A1A923D for ; Mon, 11 May 2015 15:40:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5A91BED5; Mon, 11 May 2015 23:40:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBIb8-W3DTPU; Mon, 11 May 2015 23:40:43 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BFB4DBEAA; Mon, 11 May 2015 23:40:43 +0100 (IST) Message-ID: <55512FEB.4030209@cs.tcd.ie> Date: Mon, 11 May 2015 23:40:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jim Schaad , cose@ietf.org References: <008501d08c3a$0c80bde0$258239a0$@augustcellars.com> In-Reply-To: <008501d08c3a$0c80bde0$258239a0$@augustcellars.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cose] Reuse of Content Encryption Keys X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:40:49 -0000 On 11/05/15 23:30, Jim Schaad wrote: > I want to call the groups attention to this RFC "RFC 3185: Reuse of CMS > Content Encryption Keys" (https://tools.ietf.org/html/rfc3185). Now there's a blast from the past:-) > The draft > talks about a method in CMS to start with an asymmetric operation on a CMS > message followed by sending a number of messages back and forth that use a > symmetric key which can be computed from the original CEK value. > > I don't know that it makes any sense for the group to adopt a similar > methodology, but I did want to make sure that group did at least see it. As a co-author, I can say that 3185 is, as far as I know, universally unimplemented;-) It was developed as part of a Diameter e2e security proposal that in the end didn't fly - iirc, the scenario was something like Alice sends ciphertext to Bob who needs to be able to immediately send ciphertext back to Alice with low overhead. I think the idea may still be useful sometime though, but 3185 may be (rightly) considered too hacky nowadays, but maybe with s/reverse bytes/use-KDF/ and a bit more work, the basic concept might be acceptable. (And if that turns out to be the case then well spotted Jim!) S. > > Jim > > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > From nobody Mon May 11 15:48:30 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09C1A92BC for ; Mon, 11 May 2015 15:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQmDpxiwoIiu for ; Mon, 11 May 2015 15:48:27 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0881A9110 for ; Mon, 11 May 2015 15:48:18 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 420D42CA3C; Mon, 11 May 2015 15:48:18 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Derek Atkins'" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> In-Reply-To: Date: Mon, 11 May 2015 15:46:52 -0700 Message-ID: <008601d08c3c$6049a570$20dcf050$@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: AQHbZlBKHCCSWnQMz2VzSyrGcf61KQDaoPGQAgu3YXUBfWV+bJ0+jerw Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:48:29 -0000 I don't understand what you are arguing for or against. Are you saying don't do the reuse of the structure? Are you saying don't do the extra tagging of encrypted key vs encrypted content? Are you saying something completely different? jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, May 11, 2015 3:25 PM > To: Jim Schaad; 'Derek Atkins' > Cc: cose@ietf.org > Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients > > From my point of view, the JOSE WG didn't reject encrypting a JWK to > represent the encrypted key because it was a change. The working group > rejected it because there was no need to carry any data that would remain > unused about the encrypted key, when just the the encrypted key value itself > would do. Particularly in a space-constrained environment, carrying extra > metadata about a key that will only be discarded seems wasteful in the > extreme. > > I would advocate having the encrypted_key value remain only an encrypted > form of the CEK value, adding nothing extra. > > - Mike > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Monday, May 11, 2015 10:42 PM > To: 'Derek Atkins' > Cc: cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > At the present time, that information can easily be inferred by context. In the > event that we want to talk about use the "recipient" structure as a top level > object then I think this question would need to be revisited. > > Jim > > > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Monday, May 11, 2015 8:23 AM > > To: Jim Schaad > > Cc: cose@ietf.org > > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > > > I believe that yes, the map should be reused, however if we do that I > > wonder whether you need to add a tag that says whether it's an > > encrypted key or encrypted 'data'? > > > > -derek > > > > "Jim Schaad" writes: > > > > > Question: Reuse Encrypt body map for recipients > > > > > > Discussion: > > > > > > The concept of using the same structure for both recipients and the > > > base encryption map was introduced to the JOSE working group at the > > > Denver meeting. The JOSE working group rejected the idea as being > > > too much of a change to make in the current working code. The > > > concept is that the same data structure, with the same elements is > > > used to encode both the content encryption and each of the recipient > structures. > > > While in JOSE, many of the same elements are not present in the > > > recipient structure (i.e. iv and aad), some of these elements later > > > appeared as part of algorithm descriptions (iv is a header parameter > > defined for AES-GCM key wrapping). > > > > > > Using the same structure for encrypting content as well as > > > encrypting keys allows for some neat tricks to be played at a later > > > date if needed. One example is that you could separate the key > > > wrapping algorithm, and the ECDH-KDF algorithm pair into separate > > > layers. This allows one to move towards a Chinese Menu method of > > > selecting and using algorithms rather than the current algorithm suite > method. > > > While I would not recommend that this happen in the current > > > specification, it might be nice to keep it open as an option to be > > > used > in the > > future as new algorithms are added. > > > > > > Another advantage of doing this folding is in code size. In my > > > implementation, I have created the recipient class as inheriting > > > from the encryption body class. The recipient class contains only > > > code that deals with the cryptography of key management. All of the > > encoding/decoding is > > > handled by the base encryption class. If the structures are kept > separate > > > as they are today then that code would need to be added to the > > > recipient class. While my code does not currently deal with idea of > > > having multiple layers of key management. I believe that this would > > > be a minimal addition to the current code base. > > > > > > > > > _______________________________________________ > > > Cose mailing list > > > Cose@ietf.org > > > https://www.ietf.org/mailman/listinfo/cose > > > > > > > > > > -- > > Derek Atkins 617-623-3745 > > derek@ihtfp.com www.ihtfp.com > > Computer and Internet Security Consultant > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon May 11 16:19:10 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464E11AC3A0 for ; Mon, 11 May 2015 16:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MIlwGE2EtMy for ; Mon, 11 May 2015 16:19:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F2C1AC39C for ; Mon, 11 May 2015 16:19:04 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.160.10; Mon, 11 May 2015 23:18:47 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0160.009; Mon, 11 May 2015 23:18:47 +0000 From: Mike Jones To: Jim Schaad , 'Derek Atkins' Thread-Topic: [Cose] Issue: Reuse the Enrypt structure for recipients Thread-Index: AdCDmVTi0lJyO1ENSaipAaz9l4o5TgIZQmWBAA08RwAAAVZ3kAAA7X0AAADXG1A= Date: Mon, 11 May 2015 23:18:46 +0000 Message-ID: References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> In-Reply-To: <008601d08c3c$6049a570$20dcf050$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [5.149.172.123] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(99286002)(74316001)(189998001)(19580395003)(122556002)(19580405001)(40100003)(77156002)(62966003)(93886004)(66066001)(86362001)(2900100001)(2950100001)(86612001)(46102003)(561944003)(2656002)(76176999)(54356999)(87936001)(15974865002)(50986999)(33656002)(77096005)(76576001)(92566002)(15975445007)(5001770100001)(102836002)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 23:18:46.1606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:19:07 -0000 What was presented to the JOSE working group in Denver by Richard Barnes wa= s the option of representing encrypted keys as encrypted JWK structures, ra= ther than just encrypted bare keys. The choice is between encrypting: {"kty":"oct", "alg":"A128KW", "k":"GawgguFyGrWKav7AX4VKUg"} or simply the bytes that "k" represents in base64url encoded form. Encrypt= ing just the bytes is smaller, and contains no redundant information that w= ill simply be discarded. That's why the JOSE working group rejected using encrypted JWKs as the encr= ypted_key representation. If the "encrypt structure" you're referring to i= s different than this, it would probably be good to explain what it is, how= you're proposing to reuse it, and why reusing it doesn't add extraneous un= used information, as Richard's proposal in Denver did. -- Mike -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Monday, May 11, 2015 11:47 PM To: Mike Jones; 'Derek Atkins' Cc: cose@ietf.org Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients I don't understand what you are arguing for or against. Are you saying don't do the reuse of the structure? Are you saying don't do the extra tagging of encrypted key vs encrypted con= tent? Are you saying something completely different? jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, May 11, 2015 3:25 PM > To: Jim Schaad; 'Derek Atkins' > Cc: cose@ietf.org > Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients >=20 > From my point of view, the JOSE WG didn't reject encrypting a JWK to=20 > represent the encrypted key because it was a change. The working=20 > group rejected it because there was no need to carry any data that=20 > would remain unused about the encrypted key, when just the the=20 > encrypted key value itself > would do. Particularly in a space-constrained environment, carrying=20 > extra metadata about a key that will only be discarded seems wasteful=20 > in the extreme. >=20 > I would advocate having the encrypted_key value remain only an=20 > encrypted form of the CEK value, adding nothing extra. >=20 > - Mike >=20 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Monday, May 11, 2015 10:42 PM > To: 'Derek Atkins' > Cc: cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >=20 > At the present time, that information can easily be inferred by context. In the > event that we want to talk about use the "recipient" structure as a=20 > top level > object then I think this question would need to be revisited. >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Monday, May 11, 2015 8:23 AM > > To: Jim Schaad > > Cc: cose@ietf.org > > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > > > I believe that yes, the map should be reused, however if we do that=20 > > I wonder whether you need to add a tag that says whether it's an=20 > > encrypted key or encrypted 'data'? > > > > -derek > > > > "Jim Schaad" writes: > > > > > Question: Reuse Encrypt body map for recipients > > > > > > Discussion: > > > > > > The concept of using the same structure for both recipients and=20 > > > the base encryption map was introduced to the JOSE working group=20 > > > at the Denver meeting. The JOSE working group rejected the idea=20 > > > as being too much of a change to make in the current working code. =20 > > > The concept is that the same data structure, with the same=20 > > > elements is used to encode both the content encryption and each of=20 > > > the recipient > structures. > > > While in JOSE, many of the same elements are not present in the=20 > > > recipient structure (i.e. iv and aad), some of these elements=20 > > > later appeared as part of algorithm descriptions (iv is a header=20 > > > parameter > > defined for AES-GCM key wrapping). > > > > > > Using the same structure for encrypting content as well as=20 > > > encrypting keys allows for some neat tricks to be played at a=20 > > > later date if needed. One example is that you could separate the=20 > > > key wrapping algorithm, and the ECDH-KDF algorithm pair into=20 > > > separate layers. This allows one to move towards a Chinese Menu=20 > > > method of selecting and using algorithms rather than the current=20 > > > algorithm suite > method. > > > While I would not recommend that this happen in the current=20 > > > specification, it might be nice to keep it open as an option to be=20 > > > used > in the > > future as new algorithms are added. > > > > > > Another advantage of doing this folding is in code size. In my=20 > > > implementation, I have created the recipient class as inheriting=20 > > > from the encryption body class. The recipient class contains only=20 > > > code that deals with the cryptography of key management. All of=20 > > > the > > encoding/decoding is > > > handled by the base encryption class. If the structures are kept > separate > > > as they are today then that code would need to be added to the=20 > > > recipient class. While my code does not currently deal with idea=20 > > > of having multiple layers of key management. I believe that this=20 > > > would be a minimal addition to the current code base. > > > > > > > > > _______________________________________________ > > > Cose mailing list > > > Cose@ietf.org > > > https://www.ietf.org/mailman/listinfo/cose > > > > > > > > > > -- > > Derek Atkins 617-623-3745 > > derek@ihtfp.com www.ihtfp.com > > Computer and Internet Security Consultant >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue May 12 00:53:07 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF78C1A1BCA for ; Tue, 12 May 2015 00:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2Bm_fWsMTQy for ; Tue, 12 May 2015 00:53:02 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F321A1B82 for ; Tue, 12 May 2015 00:53:02 -0700 (PDT) Received: by layy10 with SMTP id y10so110852404lay.0 for ; Tue, 12 May 2015 00:53:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=XDSzvMIP5kD8dVb1dGtXz6kzWo7wOcZy0ai9WVGFgEo=; b=AjqAszDPJhGoJVDRbLrvmMmzR6uImMEnVoX4/jns+XBTZfUXw24g5ohF/tDRvfNslj 5bVGZs3jnB3STVqhuXS7M+zK4L5vEb1pyZjDOIz49uVMeJWVICXvaYVJPCN5hoJTFAlQ G/y7eUAU42N2rjZe8EepD3N9MW2w3CbCMVTuzPOLQg2idJ95i64oVpFkxZAJOBPEY7S1 xp4aFnnNmGYYww957JLQyC9Gmt4mR9brFCqkMGPdXtMrQVeWzOQQi49pSQgeJ9iU8mR2 JvUL309wgjd/b8Y/HQ+VjtGoYJs9NwfsCgfVcZ74AVpUdkBy9Phh+PdtEjhzA4CKq05h oEGw== X-Gm-Message-State: ALoCoQktZYVHyc3Dl5rFVTUzOupn8vmGotMfw7lq+OtIauiEL3zHC1JHOAE9/n7n+N/diaFnsvqB X-Received: by 10.112.142.232 with SMTP id rz8mr10625552lbb.74.1431417180620; Tue, 12 May 2015 00:53:00 -0700 (PDT) Received: from [192.168.0.108] ([85.235.11.178]) by mx.google.com with ESMTPSA id r4sm3606146lae.13.2015.05.12.00.52.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 00:52:59 -0700 (PDT) Message-ID: <5551B159.1050708@sics.se> Date: Tue, 12 May 2015 09:52:57 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: cose@ietf.org References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> <55504EA3.7030405@sics.se> <007b01d08c2a$40b20cf0$c21626d0$@augustcellars.com> In-Reply-To: <007b01d08c2a$40b20cf0$c21626d0$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020705070204090802020406" Archived-At: Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 07:53:06 -0000 This is a cryptographically signed message in MIME format. --------------ms020705070204090802020406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 05/11/2015 10:37 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Ludwig Seitz >> Sent: Sunday, May 10, 2015 11:40 PM >> To: cose@ietf.org >> Subject: Re: [Cose] Sizes of messages >> >> On 05/11/2015 07:55 AM, Jim Schaad wrote: >> >>> - A payload of 19 bytes is assumed and it is assumed that the >>> content is being carried inside of the message. >> >> Just a quick comment on that one. In the world of sensor networks, the= >> payload of a message will often be a sensor reading, which could be as= > small >> as e.g. a single floating point number or even an integer. So we shoul= d >> assume we will get a significant number of payloads in the order of >> magnitude of 2-4 bytes. >> >> /Ludwig > > I kind of just chose an arbitrary number, this does not change what the= > overhead of sending a message is The break points on message sizes fr= om > the size of CBOR are at 24/25 bytes (tag and length goes from 1 to 2 by= tes) > and at 255/267 bytes (tag and length from 2 bytes to 3 bytes). The nex= t > break would be at 2^24 bytes. > > If you care about the ratio of content to overhead then knowing an exac= t > message size matters otherwise it probably doesn't. No argument about that, plus as Derek pointed out there are cases where=20 combining several of these values into one message makes sense. > > If you sizes are really that small, what are you doing about dealing wi= th > replay - are you assuming that is all covered in the security overhead > rather than in your base message size? > Yes, I'm one of the co-authors of draft-selander, so for replay=20 protection we are suggesting to apply the procedure described in section = 5.3 (using sequence numbers + key identifier). /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms020705070204090802020406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA1MTIwNzUyNTdaMCMGCSqGSIb3DQEJBDEW BBS9osiFQrkGx5E0RHzFeqF6nTXR5jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAjk/LRNNNNHIMPsP2x1JVnjJCpnd3TdTqKlSrbGOWOq4WkuYqDyTat4gU3oPzpO9V+V7k arwNXvufbSqkZ1HZf3rAqWOUbYR5mwvjo/WTCjdQizY6k8nIW1Hw5zJjZn+2A0hPE2GKeTAF bYLIQG7enEFkFrLKvFlegWNzm597GHfSXoJ32Obgjo+KIW1/1B8Xv3vf8BR3Sc147dnJ0uQy 2QWd6NRiobUJ/vo0qY1lUasgGlN1AIhHlnkBoYd19bkm3yFUlck8X8fmG43rFpjBpo45HxG9 hK5rCj6vEuW6O1uVjH1xS008NjaQdvunzROm6d2fYtAoX9OkahcrcZnHaQAAAAAAAA== --------------ms020705070204090802020406-- From nobody Tue May 12 04:21:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FCC1A884D for ; Tue, 12 May 2015 04:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnTrEdUbGBMZ for ; Tue, 12 May 2015 04:21:36 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66771A8843 for ; Tue, 12 May 2015 04:21:35 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-29-5551e23d652d Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.FA.02540.D32E1555; Tue, 12 May 2015 13:21:34 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Tue, 12 May 2015 13:21:33 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Sizes of messages Thread-Index: AdCLqYqqIpBM2Wx4Q8mhu5BRuxfBUQA/EG0A Date: Tue, 12 May 2015 11:21:32 +0000 Message-ID: References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> In-Reply-To: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RtfuUWCowcqj3BbTtk5ltVg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxYeIKxoIlZhXTllxib2D8YNLFyMkhIWAi sWLbCXYIW0ziwr31bF2MXBxCAkcZJXadmcQGkhASWMwo8fpcMIjNJuAi8aDhEROILSLgIbFr 9yfmLkYODmEBVYnfm8wgwmoS2x7MYISwjSTeT3gENoYFqORe/wqwVl4BC4mLLfNZIcbbS0x4 dxCshlPAQaLh8QSwOCPQPd9PrQGrZxYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+B1YvKqAnsfJ6 ExtEXFHi46t9jCCnMQtoSqzfpQ8xxlriy0uIcmagkindD9khzhGUODnzCcsERvFZSLbNQuie haR7FpLuWUi6FzCyrmIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjLSDW34b7GB8+dzxEKMA B6MSD++DK/6hQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGanphakFsUXleakFh9iZOLglGpg bFuytejl+U2rrO+lrJ95JEt9X8tnrlv6H1affiHnWNj9gP32mgsLn5yIOLWH7cWEBYIvHTb2 cTz+tGLuvrSj7v/zl+onvs2f3x7/Mm1OR/UxGw01b+ntlUFy9Wxmz3jy6hQcHt4zK/8wYVri y3D1ArXIAwuu/tYvOtprFKWsIK90zijKdpcHkxJLcUaioRZzUXEiABIUZtKVAgAA Archived-At: Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 11:21:39 -0000 DQoNCk9uIDIwMTUtMDUtMTEgMDc6NTUsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj5JIGhhdmUgc3BlbnQgYSBjb3VwbGUgb2YgZGF5cyBsb29raW5nIGF0 IG1lc3NhZ2VzIHRoYXQgYXJlIGxpa2VseSB0byBiZQ0KPnNlbnQNCj5mb3IgdGhlIHdvcmxkIG9m IENvUkUvQUNFIGJhc2VkIG9uIHRoZSBkcmFmdA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAxIGFuZCB0aGUNCj5yZXNwb25z ZSBvbiBrZXkgbWFuYWdlbWVudCB0aGF0IEkgZ290IGJhY2sgcmVjZW50bHkuICBJIGhhdmUgbWFk ZSBzZXZlcmFsDQo+YXNzdW1wdGlvbnMgaW4gZG9pbmcgdGhlIGNvbXB1dGF0aW9ucy4gIEkgaGF2 ZSBpbmNsdWRlZCBteSBzcHJlYWRzaGVldCBvZg0KPnRoZSBkaWZmZXJlbnQgY2FzZXMgc28gdGhh dCB5b3UgY2FuIGxvb2sgYXQgd2hlcmUgSSBoYWQgYXNzaWduZWQgYnl0ZXMNCj51c2VkLg0KPklm IHBlb3BsZSBoYXZlIG90aGVyIGNhc2VzIHdoZXJlIHRoZXkgd291bGQgbGlrZSB0byBnZXQgc2l6 ZXMgY29tcHV0ZWQsDQo+cGxlYXNlIHNlbmQgdGhlbSB0byBtZSBhbmQgSSBjYW4gcnVuIHRoZSBu dW1iZXJzLg0KPg0KPg0KPkNhc2UgIzEgLSBNQUMgb24gYSBjb250ZW50IHVzaW5nIGEgZGlyZWN0 IGtleS4gICBJIGFtIGFzc3VtaW5nLCBwcm9iYWJseQ0KPndpdGhvdXQgY2F1c2UsIHRoYXQgdGhp cyBpcyBnb2luZyB0byBiZSB0aGUgbW9zdCBjb21tb24gbWVzc2FnZSB0eXBlIHNlbnQuDQo+KEl0 IGNvdWxkIGJlIGNhc2UgIzIgaW5zdGVhZCkuICAgVGhlIGRldGFpbHMgb2YgdGhlIG1lc3NhZ2Ug dGhhdCBJIGFtDQo+bG9va2luZyBhdCBhcmU6DQo+CS0gIFdlIHVzZSBhIG9uZSBieXRlIGludGVy bmFsIGlkZW50aWZpZXIgZm9yIHRoZSBtZXNzYWdlIHR5cGUNCj4JLSAgV2UgYXJlIHByb3RlY3Rp bmcgdGhlIGFsZ29yaXRobSBpZGVudGlmaWVyIGFuZCBhIG5vbmNlLg0KPgktICBXZSBhcmUgY2Fy cnlpbmcgbm8gdW5wcm90ZWN0ZWQgaGVhZGVycw0KPgktICBXZSBhcmUgdXNpbmcgYSBub25jZSB3 aGljaCBpcyBvbmUgYnl0ZSBsb25nIC0gaW5jcmVhc2luZyB0aGUgc2l6ZQ0KPm9mIHRoZSBub25j ZSB3b3VsZCB1bmlmb3JtbHkgaW5jcmVhc2UgdGhlIHNpemUgb2YgdGhlIG1lc3NhZ2UgZm9yIGJv dGgNCj5jb25maWd1cmF0aW9ucw0KPgktICBBIHBheWxvYWQgb2YgMTkgYnl0ZXMgaXMgYXNzdW1l ZCBhbmQgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZQ0KPmNvbnRlbnQgaXMgYmVpbmcgY2FycmllZCBp bnNpZGUgb2YgdGhlIG1lc3NhZ2UuDQo+CS0gIFRoZSBhbGdvcml0aG0gZm9yIHRoZSBNQUMgaXMg SE1BQy1TSEEtMjU2IGFuZCB0aGUgdGFnIGlzDQo+dHJ1bmNhdGVkIHRvIDE2IGJ5dGVzLg0KPgkt ICBBIGtleSBpZGVudGlmaWVyIG9mIDggYnl0ZXMgaXMgdXNlZC4NCj4JLSAgVGhlcmUgaXMgbm8g QUFEIGZpZWxkIGJ1aWx0IGludG8gdGhlIG1lc3NhZ2UsIGJ1dCB0aGVyZSBtYXkgYmUNCj5leHRl cm5hbCBBQUQgaW5mb3JtYXRpb24gcGFzc2VkIGluIChpLmUuIGNhcnJpZWQgaW4gdGhlIG1lc3Nh Z2UgaGVhZGVyKS4NCj4JLSAgQXNzdW1pbmcgYSBzaW5nbGUgcmVjaXBpZW50IGFuZCB0aGUgcmVj aXBpZW50IGluZm9ybWF0aW9uDQo+c3RydWN0dXJlIGlzIGVuY29kZWQgYXMgYSBtYXAgdy9vIGFu IGFycmF5IHdyYXBwZXIuDQo+CS0gIEluIHRoaXMgY2FzZSB1c2luZyBtYXBzIHRha2VzIDYyIG9j dGV0cyBhbmQgdXNpbmcgYXJyYXlzIHRha2VzIDYzDQo+b2N0ZXRzLg0KPg0KPkNhc2UgIzIgLSBF bmNyeXB0aW9uIG9uIGEgY29udGVudCB1c2luZyBhIGRpcmVjdCBrZXkuICBUaGUgZGV0YWlscyBv ZiB0aGUNCj5tZXNzYWdlIHRoYXQgSSBhbSBsb29raW5nIGF0IGFyZToNCj4JLSAgV2UgdXNlIGEg b25lIGJ5dGUgaW50ZXJuYWwgaWRlbnRpZmllciBmb3IgdGhlIG1lc3NhZ2UgdHlwZQ0KPgktICBX ZSBhcmUgcHJvdGVjdGluZyB0aGUgYWxnb3JpdGhtIGlkZW50aWZpZXINCj4JLSAgV2UgYXJlIGNh cnJ5aW5nIG5vIHVucHJvdGVjdGVkIGhlYWRlcnMNCj4JLSAgV2UgYXJlIGNhcnJ5aW5nIGFuIElW IG9mIDggYnl0ZXMuICBUaGlzIGNvdWxkIGJlIHNob3J0ZW5lZCB1bmRlcg0KPnNvbWUgY2lyY3Vt c3RhbmNlcywgYnV0IHRoYXQgd291bGQgYmUgZXF1YWwgaW4gYm90aCBtYXBwaW5ncy4gIFRoZXJl IGlzIG5vDQo+cmVhc29uIHRvIGNhcnJ5IGl0IGFzIGEgcHJvdGVjdGVkIGhlYWRlciBpdGVtIGFz IENDTSBhbmQgR0NNIGJvdGgNCj5hdXRvbWF0aWNhbGx5IGluY2x1ZGUgdGhlIElWIHZhbHVlIGlu IHRoZSBhdXRoZW50aWNhdGVkIGRhdGEgY29tcHV0YXRpb24uDQo+CS0gIEEgcGF5bG9hZCBvZiAx OSBieXRlcyBpcyBhc3N1bWVkIGFuZCBpdCBpcyBhc3N1bWVkIHRoYXQgdGhlDQo+Y29udGVudCBp cyBiZWluZyBjYXJyaWVkIGluc2lkZSBvZiB0aGUgbWVzc2FnZS4NCj4JLSAgVGhlIGFsZ29yaXRo bSBmb3IgdGhlIGVuY3J5cHRpb24gaXMgQUVTLTEyOC1DQ00tNjQsIHRoZSB0YWcgaXMgIDgNCj5i eXRlcy4NCj4JLSAgQSBrZXkgaWRlbnRpZmllciBvZiA4IGJ5dGVzIGlzIHVzZWQuDQo+CS0gIFRo ZXJlIGlzIG5vIEFBRCBmaWVsZCBidWlsdCBpbnRvIHRoZSBtZXNzYWdlLCBidXQgdGhlcmUgbWF5 IGJlDQo+ZXh0ZXJuYWwgQUFEIGluZm9ybWF0aW9uIHBhc3NlZCBpbiAoaS5lLiBjYXJyaWVkIGlu IHRoZSBtZXNzYWdlIGhlYWRlcikuDQo+CS0gIEFzc3VtaW5nIGEgc2luZ2xlIHJlY2lwaWVudCBh bmQgdGhlIHJlY2lwaWVudCBpbmZvcm1hdGlvbg0KPnN0cnVjdHVyZSBpcyBlbmNvZGVkIGFzIGEg bWFwIHcvbyBhbiBhcnJheSB3cmFwcGVyLg0KPgktICBJbiB0aGlzIGNhc2UgdXNpbmcgbWFwcyB0 YWtlcyA2MCBvY3RldHMgYW5kIHVzaW5nIGFycmF5cyB0YWtlcyA2MQ0KPm9jdGV0cy4NCj4NCj5D YXNlICMzIC0gU2lnbiBhIG1lc3NhZ2UgdXNpbmcgYW4gYXN5bW1ldHJpYyBrZXkuICBUaGUgZGV0 YWlscyBvZiB0aGUNCj5tZXNzYWdlIHRoYXQgSSBhbSBsb29raW5nIGF0IGFyZToNCj4JLSAgV2Ug dXNlIGEgb25lIGJ5dGUgaW50ZXJuYWwgaWRlbnRpZmllciBmb3IgdGhlIG1lc3NhZ2UgdHlwZQ0K PgktICBXZSBhcmUgcHJvdGVjdGluZyB0aGUgYWxnb3JpdGhtIGlkZW50aWZpZXIgYW5kIHRoZSBr aWQNCj4JLSAgV2UgYXJlIGNhcnJ5aW5nIG5vIHVucHJvdGVjdGVkIGhlYWRlcnMNCj4JLSAgV2Ug YXJlIGFzc3VtaW5nIHRoYXQgdGhlIHBheWxvYWQgaXQgZGV0YWNoZWQgYW5kIG5vdCBwYXJ0IG9m IHRoZQ0KPm1lc3NhZ2UNCj4JLSAgVGhlIGFsZ29yaXRobSBpcyBFQ0RTQSB1c2luZyBQLTI1NiAt IHRodXMgdGhlIHNpZ25hdHVyZSB2YWx1ZQ0KPml0c2VsZiBpcyA2NCBieXRlcy4NCj4JLSAgSW4g dGhpcyBjYXNlIHVzaW5nIG1hcHMgdGFrZXMgODIgYnl0ZXMgYW5kIGFycmF5cyB0YWtlcyA4MyBi eXRlcy4NCj5JZiBjb250ZW50IGlzIGluY2x1ZGVkLCB0aGVuIHRoZSBhcnJheSB3aWxsIGJlIHRo ZSBzYW1lIHNpemUgYXMgZm9yIG1hcC4NCj4NCj5DYXNlICM0IC0gU2lnbiBhIG1lc3NhZ2UgdXNp bmcgYW4gYXN5bW1ldHJpYyBrZXkgYW5kIGVuY3J5cHQgaXQgdXNpbmcgYQ0KPmRpcmVjdCBrZXku DQo+CS0gRm9yIHRoZSBzaWduYXR1cmUsIHRoZSBjb25kaXRpb25zIGFyZSB0aGUgc2FtZSBhcyBm b3IgCWNhc2UNCj4jMyB3aXRoIHRoZSBleGNlcHRpb24gdGhhdCB0aGUgY29udGVudCBpcyBjYXJy aWVkIGluIHRoZSBtZXNzYWdlLg0KPgktIEZvciB0aGUgZW5jcnlwdCBvcGVyYXRpb24sIHRoZSBj b25kaXRpb25zIGFyZSB0aGUgc2FtZSBhcyBmb3IgY2FzZQ0KPiMyLg0KPgktIEZvciBtYXAsIHRo ZSBzaXplIGlzIDE0NSBvY3RldHMsIGZvciBhcnJheSB0aGUgc2l6ZSBpcyAxNDYgb2N0ZXRzLg0K Pg0KPkZvciBhbGwgb2YgdGhlIGNhc2VzIHRoYXQgSSBoYXZlIHByb3ZpZGVkIGFib3ZlLCBJIGFt IHVzaW5nIHRoZSBtaW5pbWFsDQo+c2V0DQo+b2YgZmllbGRzLiAgSWYgYW55IG90aGVyIGZpZWxk cyBhcmUgYWRkZWQsIGZvciBleGFtcGxlIHVucHJvdGVjdGVkDQo+YXR0cmlidXRlcywgdGhlbiB0 aGUgYmFsYW5jZSB0aXBzIGZyb20gbWFwcyB0byBhcnJheXMgYXMgdGhlIGNvc3QgdG8gYWRkIGEN Cj5maWVsZCBpcyAyIG9jdGV0cyBwbHVzIHRoZSBkYXRhLCB3aGVyZWFzIHRoZSBjb3N0IHRvIGFk ZCBhIGZpZWxkIHRvIGFuDQo+YXJyYXkNCj5pcyBqdXN0IHRoZSBzaXplIG9mIHRoZSBkYXRhLg0K Pg0KDQpJ4oCZbSBtaXNzaW5nIGFuIGVuY3J5cHQtdGhlbi1zaWduIGNhc2U6IEVuY3J5cHRpb24g b2YgY29udGVudCB1c2luZyBhDQpkaXJlY3Qga2V5IGFuZCBzaWduIGl0IHVzaW5nIGFuIGFzeW1t ZXRyaWMga2V5Lg0KDQpIZXJlIGlzIG9uZSB1c2UgY2FzZToNCg0KQ29uc3RyYWluZWQgbm9kZXMg cHVibGlzaCBhbmQgbXVsdGlwbGUgbm9kZXMgc3Vic2NyaWJlIHRvIHRoZQ0KcHVibGljYXRpb25z LiBUaGUgcHViLXN1YiBicm9rZXIgaXMgbm90IHRydXN0ZWQgd2l0aCB0aGUgcGxhaW4gdGV4dA0K cHVibGljYXRpb25zIG9mIGl0cyBwdWJsaXNoZXJzLCBidXQgb25seSBwdWJsaXNoZXMgaXRzIGFz c29jaWF0ZWQNCnB1Ymxpc2hlcnMgcHVibGljYXRpb25zLiBUaGUgcHVibGljYXRpb25zIGFyZSB0 aGVyZWZvcmUgZW5jcnlwdGVkIHdpdGggYQ0Kc3ltbWV0cmljIGtleSBzaGFyZWQgYW1vbmcgdGhl IHN1YnNjcmliZXJzLCBhbmQgZnVydGhlciBzaWduZWQgd2l0aCB0aGUNCnByaXZhdGUga2V5IG9m IHRoZSBwdWJsaXNoZXIuIFdpdGggYWNjZXNzIHRvIHRoZSBhdXRoZW50aWMga2V5IG9mIHRoZQ0K cHVibGlzaGVyLCB0aGUgc3Vic2NyaWJlcnMgYW5kIHRoZSBwdWItc3ViIGJyb2tlciBjYW4gdmVy aWZ5IHRoZQ0KcHVibGljYXRpb24gY29tZXMgZnJvbSB0aGUgcHVibGlzaGVyLg0KDQpJIGhvcGUg aXQgd291bGQgYmUgcG9zc2libGUgaW4gdGhpcyBjYXNlIHRvIGdldCBhIG1lc3NhZ2Ugc2l6ZSBj bG9zZXIgdG8NCmNhc2UgIzMgcmF0aGVyIHRoYW4gY2FzZSAjND8NCg0KR8O2cmFuDQoNCg0KDQoN Cg== From nobody Tue May 12 05:52:26 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12EB1B2C2B for ; Tue, 12 May 2015 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFhfuMZ7XueN for ; Tue, 12 May 2015 05:52:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D931B2C21 for ; Tue, 12 May 2015 05:52:19 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-96-5551f781bafb Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7A.D2.17665.187F1555; Tue, 12 May 2015 14:52:17 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Tue, 12 May 2015 14:52:16 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Parameterization of CCM mode Thread-Index: AdCMD4iwiwDWGFPrQzmf6gFdLBxZmwAovCMA Date: Tue, 12 May 2015 12:52:16 +0000 Message-ID: References: <006b01d08c1b$a6831b00$f3895100$@augustcellars.com> In-Reply-To: <006b01d08c1b$a6831b00$f3895100$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-ID: <202456F655A3624FA21C5B1C40E00314@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Rrfxe2Cowf8uRYtpW6eyWqye/p3N gclj45zpbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4vG0Jc8EK74o3K9vZGhg3eHYxcnJICJhI rG19ywphi0lcuLeerYuRi0NI4CijxKQrm6GcxYwSX5o62EGq2ARcJB40PGICsUUEPCR27f7E DGILCxhIbFzZAxU3lPg64wkjhG0ksXHWcrA4i4CqxIvWr2BzeAUsJB48aQCLCwnYS3zuOMEG YnMKOEgs37oTbCYj0EXfT60Bq2EWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/gf2gaiAnsTK601s EHFFifanDUA3cAD1akqs36UPMcZa4sexeWwQtqLElO6HUOcISpyc+YRlAqP4LCTbZiF0z0LS PQtJ9ywk3QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBEbbwS2/dXcwrn7teIhRgINR iYf3wRX/UCHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MC7t 3uzjZf/cM5Zd8sO1+swX82b2GRwUZl5Y8L637PuXyNUuezR+Cibl7rba+vBRdPmJaxIfpN79 W8pT9DHg9a1e9ehXR/mWm9ve+G3z0PR46ZLFftHz1d9oxm4pjl74p/yVt9M5PeEzAonK09ru GGSb/T/NuLLn4Lm4YMFThRlvtZzrXzqcrVRiKc5INNRiLipOBAD0koC9lwIAAA== Archived-At: Subject: Re: [Cose] Parameterization of CCM mode X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:52:23 -0000 DQpIaSBKaW0NCg0KVGhhbmtzIGZvciB0aGUgcmFwaWQgcHJvZ3Jlc3MuDQoNClNpbmNlIHRoZXJl IGFyZSBzZXZlcmFsIHJlZmVyZW5jZXMgdG8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAxLCBsZXQgbWUNCmdpdmUgc29tZSBj b250ZXh0IGFib3V0IHdoYXQgdGhpcyBkcmFmdCBpbnRlbmRlZCB0byBkbyB0aGF0IGlzIHJlbGV2 YW50IHRvDQpDT1NFIGZvciB0aG9zZSB0aGF0IGhhdmUgbm90IHJlYWQgaXQuIEZpcnN0IG9mIGFs bCwgaXQgZGlkIG5vdCBpbnRlbmQgdG8NCnNwZWNpZnkgYSBnZW5lcmljIGNvbXBhY3Qgc2VjdXJl IG1lc3NhZ2UgZm9ybWF0IGFzIGlzIHRoZSBvYmplY3RpdmUgb2YNCkNPU0UsIHNlZSBBcHBlbmRp eCBDOg0KDQoiRm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyBpdCBpcyBpbXBvcnRhbnQgdGhh dCB0aGUgbWVzc2FnZQ0KICAgZXhwYW5zaW9uIGR1ZSB0byBzZWN1cml0eSBvdmVyaGVhZCBpcyBr ZXB0IGF0IGEgbWluaW11bS4gIEFzIGFuDQogICBhdHRlbXB0IHRvIGFzc2VzcyB3aGF0IHRoaXMg bWluaW11bSBleHBhbnNpb24gY291bGQgYmUsIGFuIG9wdGltaXplZA0KICAgU2VjdXJlIE1lc3Nh Z2UgZm9ybWF0IGlzIGRlZmluZWQsIHRhaWxvci1tYWRlIGZvciB0aGlzIHNldHRpbmcuICBUaGlz DQogICBpcyBpbnRlbmRlZCBhcyBhIGJlbmNobWFyayBmb3IgZ2VuZXJpYyBjb250ZW50IGZvcm1h dHMsIHRvIGFsbG93IGFuDQogICBpbmZvcm1lZCBkZWNpc2lvbiBhYm91dCB3aGljaCBTZWN1cmUg TWVzc2FnZSBmb3JtYXQgdG8gbWFuZGF0ZSBpbiBhDQogICBmdXR1cmUgdmVyc2lvbiBvZiB0aGlz IGRyYWZ0LuKAnQ0KDQpUaGUgbWFpbiBkZXNpZ24gb2JqZWN0aXZlIHdhcyB0aHVzIHRvIGVzdGlt YXRlIGEgbWluaW11bSBtZXNzYWdlIHNpemUNCih1c2luZyBhIGJlc3Bva2UgZm9ybWF0IGNhbGxl ZCBDU00pIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgYmUgZmxleGlibGUgdG8NCnRha2UgaW50byBh Y2NvdW50IHRoZSBncmVhdCB2YXJpYXRpb24gb2Ygc2V0dGluZ3MgZm9yIHdoaWNoIHRoaXMgbWF5 IGJlDQphcHBsaWVkIGJ5IGFsbG93aW5nIGRpZmZlcmVudCBjaXBoZXJzdWl0ZXMsIGxlbmd0aHMg b2Yga2V5IGlkZW50aWZpZXJzIGFuZA0Kc2VxdWVuY2UgbnVtYmVycy4NCg0KQXMgaW5kaWNhdGVk IGJ5IHRoZSBsYXR0ZXIsIGFub3RoZXIgZGVzaWduIG9iamVjdGl2ZSB3YXMgdG8gaGF2ZSBidWls dC1pbg0Kc3VwcG9ydCBmb3IgcmVwbGF5IHByb3RlY3Rpb24gc3VpdGFibGUgZm9yIGNvbnN0cmFp bmVkIGRldmljZXMgaW5kZXBlbmRlbnQNCm9mIGNpcGhlciBzdWl0ZS4gSW4gdGhpcyByZXNwZWN0 IGluZGV4aW5nIHRoZSB1c2Ugb2YgYSBwYXJ0aWN1bGFyIGtleSB3aXRoDQphIHNlcXVlbmNlIG51 bWJlcnMgc2VlbWVkIGEgYmV0dGVyIGNhbmRpZGF0ZSB0aGFuIG5vbmNlcyBhbmQgdGltZSwNCmNv bnNpZGVyaW5nIHN0b3JhZ2UgYW5kIGluYWNjdXJhY3kgb2YgY2xvY2tzLiBTaW5jZSBkaWZmZXJl bnQgYXBwbGljYXRpb25zDQpoYXZlIGRpZmZlcmVudCByZXF1aXJlbWVudHMgaW4gdGVybXMgb2Yg bnVtYmVyIG9mIG1lc3NhZ2VzIHdlIGFsbG93ZWQgYQ0KdmFyaWFibGUgY291bnRlciBzaXplIGFu ZCB0byBtaW5pbWl6ZSBtZXNzYWdlIHNpemUgYSBkZWZhdWx0IHRydW5jYXRpb24gb2YNCmluaXRp YWwgc2VxdWVuY2UgbnVtYmVyIGJ5dGVzIGNvbnRhaW5pbmcgemVyb3MuIFNpbmNlIGRpZmZlcmVu dA0KYXBwbGljYXRpb25zIGhhdmUgdmFyeWluZyBkZWdyZWUgb2Ygc3RyaWN0bmVzcyBvbiByZXBs YXkgKHNsaWRpbmcgd2luZG93DQp0byBhbGxvdyByZW9yZGVyaW5nIGV0Yy4pIHdlIGxlZnQgdG8g dGhlIGFwcGxpY2F0aW9uIHRvIGRlZmluZSB0aGUgZXhhY3QNCnByb2Nlc3NpbmcgcnVsZXMuIEZp bmFsbHksIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgd2FzIG1hZGUgb24gbGVuZ3RocyBvZg0Ka2V5 IGlkZW50aWZpZXJzLCB3aGVyZSBkaWZmZXJlbnQgYXBwbGljYXRpb25zIG1heSByZXF1aXJlIGRp ZmZlcmVudCBzaXplcw0Kb2YgbmFtZSBzcGFjZXMuDQoNCg0KRnVydGhlciBjb21tZW50cyBpbmxp bmUNCg0KDQpPbiAyMDE1LTA1LTExIDIwOjUyLCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2Vs bGFycy5jb20+IHdyb3RlOg0KDQo+QXMgcGFydCBvZiBsb29raW5nIGF0IHRoZSBzaXplcyBvZiBl bmNvZGluZ3MgZm9yIGl0ZW1zLCBJIHdhcyBsb29raW5nIGF0DQo+dGhlDQo+dXNlIG9mIENDTSBt b2RlIGFuZCB0cnlpbmcgdG8gbWFrZSBndWVzc2VzIGFib3V0IHdoYXQgdGhlIHBhcmFtZXRlcnMg YXJlDQo+dGhhdCBhcmUgZ29pbmcgdG8gYmUgdXNlZCBpbiBjb25zdHJhaW5lZCBkZXZpY2VzLiAg VHJ5aW5nIHRvIGdldCB0aGUgaW5mbw0KPmZyb20gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHktMDEgZGlkDQo+bm90IHJlYWxseSBo ZWxwIGFzIGl0IHNlZW1lZCB0byBub3QgaGF2ZSB0aGUgY29ycmVjdCBzZXQgZW5jb2RlZCBpbnRv IGl0Lg0KPg0KPlRoZSBwYXJhbWV0ZXJzIHRoYXQgSSBoYXZlIGlkZW50aWZpZWQgZm9yIENDTSBh cmUgdGhlIGZvbGxvd2luZzoNCj4NCj4xKSAgS2V5IHNpemUgLSAxMjgsIDE5MiwgMjU2DQo+Mikg IE0gLSBudW1iZXIgb2Ygb2N0ZXRzIGluIHRoZSBhdXRoZW50aWNhdGlvbiBmaWVsZCAtIDQsIDYs IDgsIDEwLCAxMiwNCj4xNCwNCj4xNg0KPjMpICBMIC0gbnVtYmVyIG9mIG9jdGV0cyBpbiB0aGUg bGVuZ3RoIGZpZWxkIC0gMi04IG9jdGV0cw0KDQpMZW5ndGggb2YgbWVzc2FnZSBpcyBub3QgaW5j bHVkZWQgaW4gdGhlIENTTSBhcyB3ZSBhc3N1bWVkIHRoYXQgd291bGQgYmUNCmdpdmVuIGJ5IFVE UC4gVGhpcyBtYXkgYmUgYSB0b28gcmVzdHJpY3RpdmUgYXNzdW1wdGlvbiBmb3IgQ09TRS4NCkkg YmVsaWV2ZSBmb3IgVURQIHlvdSB3b3VsZCByZXF1aXJlIDE2IG9jdGV0cyBpbiB0aGUgbm9ybWFs IGNhc2UsIHNvbWVvbmUNCmVsc2UgY291bGQgY29ycmVjdCBtZSBvbiB0aGlzLg0KDQo+DQo+VGhl IGtleSBzaXplIGRvZXMgbm90IGFmZmVjdCB0aGUgc2l6ZSBvZiB0aGUgb3V0cHV0IHNvIGl0IGlz IG5vdCBhIGJpZw0KPmlzc3VlDQo+cmVsYXRpdmUgdG8gdGhpbmdzLiAgV2hpbGUgSSB3b3VsZCBn dWVzcyB0aGF0IGdlbmVyYWxseSBvbmx5IDEyOC1iaXQga2V5cw0KPmFyZSB1c2VkLCBpdCB3b3Vs ZCBwcm9iYWJseSBtYWtlcyBzZW5zZSB0byBkZWZpbmUgYXQgbGVhc3QgMTI4IGFuZCAyNTYgYml0 DQo+a2V5IGFsZ29yaXRobXMNCg0KQWdyZWUsIHRoYXQgc2hvdWxkIGJlIGVub3VnaC4NCg0KPg0K PlRoZSBzaXplIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBmaWVsZHMgaXMgY3VycmVudGx5IGRlZmlu ZWQgYXMgOCBmcm9tIHRoZQ0KPlNlbGFuZGVyIGRyYWZ0LiAgSXQgd291bGQgbWFrZSBzZW5zZSB0 byBoYXZlIGF0IGxlYXN0IHR3byBzaXplcyBkZWZpbmVkIC0NCj44DQo+YW5kIDE2LCBidXQgSSBh bSBub3Qgc3VyZSBhYm91dCBvdGhlciBzaXplcy4NCg0KQWdyZWUsIGdvb2QgY2hvaWNlLg0KDQo+ DQo+VGhlIGhhcmRlc3Qgb25lIHRvIG1ha2UgZGVjaXNpb25zIG9uIGlzIHRoZSBtZXNzYWdlIGxl bmd0aCBmaWVsZC4gIEZvcg0KPmNvbnN0cmFpbmVkIGRldmljZXMgdGhpcyBjb3VsZCBiZSBhIHZl cnkgc21hbGwgdmFsdWUgYXMgYSB2YWx1ZSBvZiAyIHdvdWxkDQo+YWxsIGZvciBlbmNyeXB0aW5n IDJeKDgqMikgYnl0ZXMgYW5kIHdvdWxkIGFsbG93IGZvciB0aGUga2V5IHRvIGJlIHVzZWQgYQ0K PmxvdCBhcyBvbmUgdGhlbiBoYXMgYSBub25jZSBvZiAxNS0yPTEzIGJ5dGVzIChhbGxvd2luZyBm b3IgYSBrZXkgdG8gYmUNCj51c2VkDQo+fiAyXjEzIHRpbWVzIGFzc3VtaW5nIG5vIGJpcnRoZGF5 IGF0dGFja3MpLiAgTm9uY2UgdmFsdWVzIGFzIDE1LUwgYnl0ZXMNCj5sb25nDQo+YW5kIG5vbmNl IHZhbHVlcyBtdXN0IG5vdCBiZSByZS11c2VkLiAgT24gdGhlIG90aGVyIGhhbmQsIGZvciBhIG1v cmUNCj5nZW5lcmFsDQo+dXNhZ2UgaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSBhIGxhcmdlciB2YWx1 ZSBvZiBMIHRvIGFsbG93IGZvciBiaWdnZXINCj5tZXNzYWdlcyB3aXRoIGxlc3Mga2V5IHJlLXVz YWdlLg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gc2l6 ZSBvZiBtZXNzYWdlIGFuZCBzaXplIG9mDQpub25jZS4NCg0KPg0KPlRoZSBTZWxhbmRlciBkcmFm dCBhcHBlYXJzIHRvIG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCBkaWZmZXJlbnQga2V5cyBhcmUN Cj51c2VkIGluIGVhY2ggZGlyZWN0aW9uIHdoZW4gZW5jcnlwdGluZyBtZXNzYWdlcy4gIFRoaXMg bWFrZXMgb25lIHByb2JsZW0NCj5lYXNpZXIgLSB0aGVyZSBpcyBubyBuZWVkIHRvIGRpdmlkZSB1 cCB0aGUgbm9uY2Ugc3BhY2Ugc28gdGhhdCBub25jZQ0KPnZhbHVlcw0KPmFyZSBub3QgcmUtdXNl ZCB3aGVuIGVuY3J5cHRpbmcgbWVzc2FnZXMuICBJdCBhbHNvIG1ha2VzIG5vbmNlIHVzYWdlDQo+ ZWFzaWVyDQo+YmVjYXVzZSB0aGVyZSBpcyBubyBuZWVkIHRvIHRyeSBhbmQgc3luY2hyb25pemUg dGhlIG5vbmNlIHZhbHVlIHVzYWdlDQo+YmV0d2VlbiB0aGUgdHdvIHBhcnRpZXMuICBPbiB0aGUg b3RoZXIgaGFuZCwgaXQgbWVhbnMgdGhhdCB0aGVyZSBpcyBtb3JlDQo+ZGF0YSB0aGF0IG5lZWRz IHRvIGJlIGtlZXAgb24gdGhlIGRldmljZSBhcyB5b3Ugbm93IG5lZWQgMiBrZXlzIGFuZCAyDQo+ bm9uY2UNCj5jb3VudGVycyBmb3IgZWFjaCBwYWlyLXdpc2UgbGluayB3aGljaCBtaWdodCBiZSBh IHNwYWNlIGlzc3VlIG9uIHRoZQ0KPmRldmljZS4NCg0KDQpVbmlxdWUga2V5cyBpbiBlYWNoIGRp cmVjdGlvbiBpcyBpbiBnZW5lcmFsIGdvb2QgcHJhY3RpY2UuIEluIHRoZSBjYXNlIG9mDQpzZW5k aW5nIG9uZSBtZXNzYWdlIHRvIG11bHRpcGxlIHJlY2VpdmVycywgZWFjaCByZWNlaXZlciBuZWVk cyBhIGtleSBhbmQgYQ0Kbm9uY2UgcGVyIHNlbmRlci4gV2UgdXNlZCB0aGF0IGFzIGEgZ2VuZXJh bCBwcmluY2lwbGUgZm9yIGFsbCBtZXNzYWdlcw0KYmVpbmcgcGFzc2VkLiBGb3Igbm9uY2Ugd2Ug cHJvcG9zZWQgdG8gcmV1c2UgdGhlIHNlcXVlbmNlIG51bWJlciArIGEgc2FsdA0KKHNlZSBiZWxv dyksIHNvIGl0IGlzIG9ubHkgdGhlIHNhbHQgdGhhdCBpcyBhZGRpdGlvbmFsbHkgc3RvcmVkLiBN b3Jlb3ZlciwNCmlmIGtleXMgYXJlIGNoYW5nZWQgZm9yIGVhY2ggbWVzc2FnZSB0aGVyZSBpcyBh bnl3YXkgbmVlZCB0byBzdG9yZSBhDQpyYW5kb20gdmFsdWUgZnJvbSB3aGljaCBuZXcga2V5cyBh cmUgZGVyaXZlZCAod2UgdXNlZCBhIGRpZmZlcmVudA0KYXBwcm9hY2gsIHNlZSBiZWxvdykuDQoN Cj4NCj5JbiB0aGUgU2VsYW5kZXIgZHJhZnQsIHRoZXJlIHdhcyB0aGUgaWRlYSBvZiBoYXZpbmcg Ym90aCBhIG5vbmNlIGNvdW50ZXINCj5hbmQNCj5zYWx0IHZhbHVlIHdoaWNoIGlzIHVzZWQgdG8g Y29uc3RydWN0IHRoZSBub25jZSB1c2VkIGluIHRoZSBlbmNyeXB0aW9uDQo+c3RlcC4NCj5BcyBm YXIgYXMgSSBrbm93IHRoZXJlIGlzIG5vIHNlY3VyaXR5IHJlYXNvbiB0byBzYWx0IHRoZSBub25j ZSB1bmxlc3MNCj50aGVyZQ0KPmlzIGFuIGV4cGVjdGF0aW9uIHRoYXQgdGhlIGtleXMgd291bGQg ZXZlciBiZSByZS11c2VkLiAgSWYgbmV3IGtleXMgYXJlDQo+Z2VuZXJhdGVkIGVhY2ggdGltZSB0 aGF0IGtleXMgYXJlIGdlbmVyYXRlZCB0aGVuIHRoZSBzYWx0IGlzIHByb2JhYmx5IG5vdA0KPm5l Y2Vzc2FyeSB0byBoYXZlLiAgIEhvd2V2ZXIsIHVzZSBvZiBhIHNhbHQgdmFsdWUgY2FuIGJlIHVz ZWQgdG8gZGl2aWRlIHVwDQo+dGhlIG5vbmNlIHNwYWNlIGlmIHRoZSBzYW1lIGtleSB2YWx1ZSBp cyB1c2VkIGluIGJvdGggZGlyZWN0aW9ucy4NCg0KQXMgbWVudGlvbmVkIGFib3ZlLCB3ZSBhbHJl YWR5IGFzc3VtZWQgdGhlcmUgd2lsbCBiZSBhIHVuaXF1ZSBzZXF1ZW5jZQ0KbnVtYmVyIGFzc29j aWF0ZWQgdG8gdGhpcyBrZXkgaWRlbnRpZmllciBhbmQgbWVzc2FnZS4gVGhlIGNvbWJpbmF0aW9u IG9mDQpzYWx0IGFuZCBzZXF1ZW5jZSBudW1iZXIgYmVjb21lcyBhbiB1bmlxdWUgbm9uY2UgZm9y IGVhY2ggbWVzc2FnZSB3aGljaA0KY2FuIGJlIHVzZWQgd2l0aCB0aGlzIGtleSB1bnRpbCB0aGUg Y291bnRlciB3cmFwcywgd2hlbiBrZXkgYW5kIGtleQ0KaWRlbnRpZmllciBuZWVkcyB0byBiZSB1 cGRhdGVkLiBTaW5jZSB0aGVyZSBpcyBhIHByb2Nlc3NpbmcgY29zdCB0byBjaGFuZ2UNCmtleSBm b3IgZWFjaCBtZXNzYWdlLCB3ZSB0aG91Z2h0IHRoaXMgY29uc3RydWN0aW9uIG9mIHVzaW5nIHRo ZSBrZXkgZm9yIGENCm51bWJlciBvZiB1bmlxdWUgbm9uY2VzIGNvdWxkIGJlIGZhdm9yYWJsZSB3 aXRob3V0IGNvbXByb21pc2luZyBzZWN1cml0eS4NCiANCg0KDQpHw7ZyYW4NCg0KDQo+DQo+V2hp bGUgd2UgbmVlZCB0byBkbyBtb3JlIHJlc2VhcmNoIG9uIGZpZ3VyaW5nIG91dCBob3cgbWFueSB0 aW1lcyBhIGtleSBjYW4NCj5iZSB1c2VkIGJhc2VkIG9uIHRoZSBub25jZSBsZW5ndGgsIHRoaXMg aXMgcHJvYmFibHkgbm90IGRlcGVuZGVudCBvbiB0aGUNCj52YWx1ZXMgb2YgTCB0aGF0IHdlIHdh bnQgdG8gc3RhbmRhcmRpemUuICBUaGUgbW9yZSBpdGVtcyB3ZSBzdGFuZGFyZGl6ZQ0KPnRoZQ0K Pm1vcmUgc2VsZWN0aW9uIGRpZmZlcmVudCBwcm90b2NvbHMgd2lsbCBoYXZlLCBidXQgSSBkb24n dCBrbm93IGhvdyBtdWNoDQo+cGFyYW1ldGVyaXphdGlvbiB0aGUgaW1wbGVtZW50YXRpb25zIHN1 cHBvcnQgb3IgaWYgdGhleSBhcmUgdXNpbmcgZml4ZWQNCj5wYXJhbWV0ZXJpemF0aW9uLg0KPg0K PkppbQ0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Q29zZSBtYWlsaW5nIGxpc3QNCj5Db3NlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== From nobody Tue May 12 09:54:01 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1A41A90A9 for ; Tue, 12 May 2015 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvu5eOvTGzX0 for ; Tue, 12 May 2015 09:53:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1754F1A90A7 for ; Tue, 12 May 2015 09:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1983; q=dns/txt; s=iport; t=1431449632; x=1432659232; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QEap+AAZV/y7hufZ+9xK6vr/oLrJrO+wbImcXFwyLbQ=; b=eLiu+Efk21d0QgYy4084NHZ5FPvG8zAloX56Fsn6hHZj9BRhT29ESAzY lhaA5zj6zaOUIawkVDcaO3tY6xldJRzh76m4imaK41lSYR4HYz73Wxt35 eau7qdmAAXzB+EJPvm3p51LJBeX7rVYgDKXRyJLEIY8DlM6F0CZBiWGjn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQAQL1JV/5ldJa1cgw9UXgaDGMNihg0CgTtMAQEBAQEBgQuEIQEBBCNVARALGAICBRYLAgIJAwIBAgFFBgEMAQUCAQGIKLYLk2oBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhihiEUjMHgmiBRQEEhmOFQYpOhkaBJINegluLOINVI4IIHYFxUIFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,416,1427760000"; d="scan'208";a="419061240" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 12 May 2015 16:53:51 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4CGrpk6007651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 16:53:51 GMT Received: from [10.129.24.109] (10.129.24.109) by xhc-rcd-x15.cisco.com (173.37.183.89) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 12 May 2015 11:53:51 -0500 Message-ID: <5552301E.6050805@cisco.com> Date: Tue, 12 May 2015 10:53:50 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Derek Atkins , Paul Hoffman References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <724B1E60-A92F-42EB-B7BD-732A6B19ECCA@vpnc.org> <00e601d08904$d7eecb90$87cc62b0$@augustcellars.com> <7FA52A2F-1612-487E-9096-4EE939B99BD2@vpnc.org> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.109] Archived-At: Cc: Jim Schaad , cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:54:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 5/11/15 9:20 AM, Derek Atkins wrote: > Paul Hoffman writes: > >> On May 7, 2015, at 1:31 PM, Jim Schaad >> wrote: >>> Based on your comment I am not sure if I was clear about what I >>> was asking - Please let me know either way. >>> >>> 1. Gives a result of {"unprotected":xxx, "cipher_text":xxx, >>> "header":xxx, "encryptd_key":xxx } 2. Gives a result of >>> {"unprotected"xxx", "cipher_text"xxx, >>> "recipients":{"header":xxx, "encrypted_key":xxx }} 3 Gives a >>> result of {"unprotected":xxx", "cipher_text":xxx, >>> "recipients:[{"header":xxx, "encrypted_key":xxx}]} >>> >>> Labels disappear if the top level is an array and not a map - >>> but no other significant changes. >> >> Right, I completely misunderstood your shorthand. Given these, >> (c) seems better: it keeps the structure predictable, with a >> possible reduction of code for processing the structure (but not >> much, admittedly). > > +1 -- it should always be an array of recipients, even if it only > has a single element. > I have a light preference for (2), but am fine to sticking with (3). This WG is arguably more at least as concerned with code size as with on-the-wire size, and (2) would require (slightly?) more code than (3). - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVUjAeAAoJEDWi+S0W7cO1/IMIAKZbQJDaAIlH/bvlSk1cHT++ zLw3KbX4EvIJgtGNIMqHxsQNTshd7WSWQQcw4ySzvI+dG0cExgmwKtbOWO2ezBiX blGAYP0Nn5KI0IF7ydEDa/7mxbWPDzqbXTwOMq8nhxvDpTs1XUnHhzM4HJroKknS P1bpC3uhbcgrRR1yOddu/zdu1E4HIMxZZylYv2ddztEYEwvtbPkDoBtVua7ig9jy KlpPQqa6rcuNhkUwJq6B3y7LkQClrqNpIYs5NYXV0jGpR0ocGyQCAzc1uIaqFcZI Q1fp4z9xLCGbSk7jdEP9LY5RAsUeSnund8wL8fShIls+U8bTEfAkIMQk6bzaVFY= =Gt7Z -----END PGP SIGNATURE----- From nobody Tue May 12 09:56:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13AF1A9108 for ; Tue, 12 May 2015 09:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiwPKQgprjk1 for ; Tue, 12 May 2015 09:55:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EB91A910A for ; Tue, 12 May 2015 09:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4129; q=dns/txt; s=iport; t=1431449755; x=1432659355; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X3bQMOpBPkr1wKEhcGdGlcfQcSie4apCe4BrT6SfUW0=; b=FLtyyrnjkrB3SXFLrdhEymiWI4lvwrRZhQz0O7YXVaOrlelJFfTXRosv GvFkTnFiSiDxz19jWsdUY+0s9NDnBcmJGfDaLGBQjfbRPRndmXcxdbpzz UzXatRdfI0F+6xiffs9e7A0/G4WkheWFQZzxL1ctkkpcagRA+EcHJiK94 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQA0MFJV/5xdJa1ZA4MPVF4GgxjDYAqGBQKBO0wBAQEBAQGBC4QgAQEBBAEBASAmJQoBDAQLDgMEAQEBAgIFFggDAgIJAwIBAgEVHwkIBgEMAQUCAQGIKA21eJNpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihiEUiMQBwYLgleBRQWGZYU/LooghkaHXY8NI4IIHYFxUIFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,416,1427760000"; d="scan'208";a="11261067" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 12 May 2015 16:55:54 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4CGtsGM011044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 16:55:54 GMT Received: from [10.129.24.109] (10.129.24.109) by xhc-rcd-x15.cisco.com (173.37.183.89) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 12 May 2015 11:55:53 -0500 Message-ID: <55523098.8030302@cisco.com> Date: Tue, 12 May 2015 10:55:52 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jim Schaad , "'Derek Atkins'" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> In-Reply-To: <008401d08c33$504feb60$f0efc220$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.109] Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:56:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I agree with Derek and Jim. I would like to reuse the structure, and I the context makes it clear enough to tell the difference. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 5/11/15 3:42 PM, Jim Schaad wrote: > At the present time, that information can easily be inferred by > context. In the event that we want to talk about use the > "recipient" structure as a top level object then I think this > question would need to be revisited. > > Jim > > >> -----Original Message----- From: Derek Atkins >> [mailto:derek@ihtfp.com] Sent: Monday, May 11, 2015 8:23 AM To: >> Jim Schaad Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the >> Enrypt structure for recipients >> >> I believe that yes, the map should be reused, however if we do >> that I wonder whether you need to add a tag that says whether >> it's an encrypted key or encrypted 'data'? >> >> -derek >> >> "Jim Schaad" writes: >> >>> Question: Reuse Encrypt body map for recipients >>> >>> Discussion: >>> >>> The concept of using the same structure for both recipients and >>> the base encryption map was introduced to the JOSE working >>> group at the Denver meeting. The JOSE working group rejected >>> the idea as being too much of a change to make in the current >>> working code. The concept is that the same data structure, >>> with the same elements is used to encode both the content >>> encryption and each of the recipient structures. While in JOSE, >>> many of the same elements are not present in the recipient >>> structure (i.e. iv and aad), some of these elements later >>> appeared as part of algorithm descriptions (iv is a header >>> parameter >> defined for AES-GCM key wrapping). >>> >>> Using the same structure for encrypting content as well as >>> encrypting keys allows for some neat tricks to be played at a >>> later date if needed. One example is that you could separate >>> the key wrapping algorithm, and the ECDH-KDF algorithm pair >>> into separate layers. This allows one to move towards a >>> Chinese Menu method of selecting and using algorithms rather >>> than the current algorithm suite method. While I would not >>> recommend that this happen in the current specification, it >>> might be nice to keep it open as an option to be used > in the >> future as new algorithms are added. >>> >>> Another advantage of doing this folding is in code size. In >>> my implementation, I have created the recipient class as >>> inheriting from the encryption body class. The recipient class >>> contains only code that deals with the cryptography of key >>> management. All of the >> encoding/decoding is >>> handled by the base encryption class. If the structures are >>> kept > separate >>> as they are today then that code would need to be added to the >>> recipient class. While my code does not currently deal with >>> idea of having multiple layers of key management. I believe >>> that this would be a minimal addition to the current code >>> base. >>> >>> >>> _______________________________________________ Cose mailing >>> list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose >>> >>> >> >> -- Derek Atkins 617-623-3745 derek@ihtfp.com >> www.ihtfp.com Computer and Internet Security Consultant > > _______________________________________________ Cose mailing list > Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVUjCYAAoJEDWi+S0W7cO1EEkH/i2p9ZMQKo7uzA1hQTUsrQ8U zMwEfVxVuRLjASnsoftLbhlqEI+qhS5mPbfOLm7mu8soRpsLCJWGIi3CxQDueM39 yYWuAqKlZLLmiRs+hUiBkfTJFH3hzZXoBSMKkkoBG3lFQ7Thd+qcL5oOqhbI6ZQZ Nwl1f0vGJcQNBIUeXaB0iyh0w/0AJ6SjH0CU4WNGf7PWZCtSSE6s/VuVVJ3MH8ai pveKXu+hYsGCxa59Jr9DDs0k6m2CiTRLYoVxOtu2aljIltCTm+PxkmzmTsB2k1hr nYRDsvXTvtetpCFEEYVrnXXKAh7x1tEnBJ9fZwuB2z07atzWybNZwcv2r2CX4S8= =m1Of -----END PGP SIGNATURE----- From nobody Tue May 12 11:16:15 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E371ACDEB for ; Tue, 12 May 2015 11:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv9jFPDP-HTE for ; Tue, 12 May 2015 11:16:11 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C801ACE29 for ; Tue, 12 May 2015 11:16:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C290EE2036; Tue, 12 May 2015 14:16:08 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11617-10; Tue, 12 May 2015 14:16:06 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D538EE2035; Tue, 12 May 2015 14:16:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431454565; bh=aJYk41taIElor9KxCTnTmDVZXmKY+TcT1mYsG43M07k=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=CUQXhOIsP3GZE+OE1xvkfeEVMw15p1GhRIqv8eprowYH1tLEK1Tsa+Zxzb1jfybKA 9To5OujnxG+OtD1bAcghARZ3r4N59zox0yJD0T4NxiwwuRMej3zZuu+py0HXBjDIfz bsWeoOtL5PobEkF9UPxEbzUwhCEcIbDqqrColaaA= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4CIG5lU004577; Tue, 12 May 2015 14:16:05 -0400 From: Derek Atkins To: Mike Jones References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> Date: Tue, 12 May 2015 14:16:05 -0400 In-Reply-To: (Mike Jones's message of "Mon, 11 May 2015 23:18:46 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , 'Derek Atkins' , "cose@ietf.org" Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:16:13 -0000 Mike Jones writes: > What was presented to the JOSE working group in Denver by Richard Barnes was the option of representing encrypted keys as encrypted JWK structures, rather than just encrypted bare keys. The choice is between encrypting: > {"kty":"oct", > "alg":"A128KW", > "k":"GawgguFyGrWKav7AX4VKUg"} > or simply the bytes that "k" represents in base64url encoded form. Encrypting just the bytes is smaller, and contains no redundant information that will simply be discarded. Is it necesarily redundant? What says that the key being encrypted (wrapped) is of the exact same algorithm/size/mode as the method being used to encrypt/wrap it? E.g., I can certainly posit a situation where I am encrypting an AES-128-CCM key with an AES-256-GCM key (Or even more, I could see encrypting a 3DES key with AES). In this case the extra information is definitely not redundant, and is certainly not derivable just from 'k'. I guess my question to you (not being as intimately familiar with JWKs) is whether the algorithm of the wrapped (encrypted) key is exposed somewhere outside the wrapping? > That's why the JOSE working group rejected using encrypted JWKs as the encrypted_key representation. If the "encrypt structure" you're referring to is different than this, it would probably be good to explain what it is, how you're proposing to reuse it, and why reusing it doesn't add extraneous unused information, as Richard's proposal in Denver did. ... > -- Mike -derek > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Monday, May 11, 2015 11:47 PM > To: Mike Jones; 'Derek Atkins' > Cc: cose@ietf.org > Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients > > I don't understand what you are arguing for or against. > > Are you saying don't do the reuse of the structure? > Are you saying don't do the extra tagging of encrypted key vs encrypted content? > Are you saying something completely different? > > jim > >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Monday, May 11, 2015 3:25 PM >> To: Jim Schaad; 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients >> >> From my point of view, the JOSE WG didn't reject encrypting a JWK to >> represent the encrypted key because it was a change. The working >> group rejected it because there was no need to carry any data that >> would remain unused about the encrypted key, when just the the >> encrypted key value > itself >> would do. Particularly in a space-constrained environment, carrying >> extra metadata about a key that will only be discarded seems wasteful >> in the extreme. >> >> I would advocate having the encrypted_key value remain only an >> encrypted form of the CEK value, adding nothing extra. >> >> - Mike >> >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Monday, May 11, 2015 10:42 PM >> To: 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >> >> At the present time, that information can easily be inferred by context. > In the >> event that we want to talk about use the "recipient" structure as a >> top > level >> object then I think this question would need to be revisited. >> >> Jim >> >> >> > -----Original Message----- >> > From: Derek Atkins [mailto:derek@ihtfp.com] >> > Sent: Monday, May 11, 2015 8:23 AM >> > To: Jim Schaad >> > Cc: cose@ietf.org >> > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >> > >> > I believe that yes, the map should be reused, however if we do that >> > I wonder whether you need to add a tag that says whether it's an >> > encrypted key or encrypted 'data'? >> > >> > -derek >> > >> > "Jim Schaad" writes: >> > >> > > Question: Reuse Encrypt body map for recipients >> > > >> > > Discussion: >> > > >> > > The concept of using the same structure for both recipients and >> > > the base encryption map was introduced to the JOSE working group >> > > at the Denver meeting. The JOSE working group rejected the idea >> > > as being too much of a change to make in the current working code. >> > > The concept is that the same data structure, with the same >> > > elements is used to encode both the content encryption and each of >> > > the recipient >> structures. >> > > While in JOSE, many of the same elements are not present in the >> > > recipient structure (i.e. iv and aad), some of these elements >> > > later appeared as part of algorithm descriptions (iv is a header >> > > parameter >> > defined for AES-GCM key wrapping). >> > > >> > > Using the same structure for encrypting content as well as >> > > encrypting keys allows for some neat tricks to be played at a >> > > later date if needed. One example is that you could separate the >> > > key wrapping algorithm, and the ECDH-KDF algorithm pair into >> > > separate layers. This allows one to move towards a Chinese Menu >> > > method of selecting and using algorithms rather than the current >> > > algorithm suite >> method. >> > > While I would not recommend that this happen in the current >> > > specification, it might be nice to keep it open as an option to be >> > > used >> in the >> > future as new algorithms are added. >> > > >> > > Another advantage of doing this folding is in code size. In my >> > > implementation, I have created the recipient class as inheriting >> > > from the encryption body class. The recipient class contains only >> > > code that deals with the cryptography of key management. All of >> > > the >> > encoding/decoding is >> > > handled by the base encryption class. If the structures are kept >> separate >> > > as they are today then that code would need to be added to the >> > > recipient class. While my code does not currently deal with idea >> > > of having multiple layers of key management. I believe that this >> > > would be a minimal addition to the current code base. >> > > >> > > >> > > _______________________________________________ >> > > Cose mailing list >> > > Cose@ietf.org >> > > https://www.ietf.org/mailman/listinfo/cose >> > > >> > > >> > >> > -- >> > Derek Atkins 617-623-3745 >> > derek@ihtfp.com www.ihtfp.com >> > Computer and Internet Security Consultant >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue May 12 11:23:07 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40E1B2EE8 for ; Tue, 12 May 2015 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.089 X-Spam-Level: X-Spam-Status: No, score=-1.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2gLmB5AgcXy for ; Tue, 12 May 2015 11:23:01 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561151ACE50 for ; Tue, 12 May 2015 11:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EB5EFE2036; Tue, 12 May 2015 14:22:59 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11964-02; Tue, 12 May 2015 14:22:58 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 630CDE2035; Tue, 12 May 2015 14:22:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431454978; bh=N8aceae9fPGfxeZ2ZPN5d7x7Y8Js60rJ4+cX39btLlM=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=jlOGbWb1FBKRFwbY4F+QFkaY5Px+ld4Ct1cLZZGeZU0ggq+W2ix3L1eSYqWnrcLol zqllEmOHyEP8eE2wW9W4b9Occnc4gk/+vVOll6funDg7+TXtW+89GHJ21/pnK9hugZ hmSx5ZsEVSp3GHvf3//fENLWP9lZtThBOqCaXKcQ= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4CIMvLe005005; Tue, 12 May 2015 14:22:57 -0400 From: Derek Atkins To: =?utf-8?Q?G=C3=B6ran?= Selander References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> Date: Tue, 12 May 2015 14:22:57 -0400 In-Reply-To: (=?utf-8?Q?=22G?= =?utf-8?Q?=C3=B6ran?= Selander"'s message of "Tue, 12 May 2015 11:21:32 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:23:02 -0000 G=C3=B6ran Selander writes: > On 2015-05-11 07:55, "Jim Schaad" wrote: > [snip] >>Case #2 - Encryption on a content using a direct key. The details of the >>message that I am looking at are: [snip] >> - In this case using maps takes 60 octets and using arrays takes 61 >>octets. >> >>Case #3 - Sign a message using an asymmetric key. The details of the >>message that I am looking at are: [snip] >> - In this case using maps takes 82 bytes and arrays takes 83 bytes. >>If content is included, then the array will be the same size as for map. >> >>Case #4 - Sign a message using an asymmetric key and encrypt it using a >>direct key. >> - For the signature, the conditions are the same as for case >>#3 with the exception that the content is carried in the message. >> - For the encrypt operation, the conditions are the same as for case >>#2. >> - For map, the size is 145 octets, for array the size is 146 octets. >> >>For all of the cases that I have provided above, I am using the minimal >>set >>of fields. If any other fields are added, for example unprotected >>attributes, then the balance tips from maps to arrays as the cost to add a >>field is 2 octets plus the data, whereas the cost to add a field to an >>array >>is just the size of the data. >> > > I=E2=80=99m missing an encrypt-then-sign case: Encryption of content usin= g a > direct key and sign it using an asymmetric key. This is the same as case #4 except that the ordering/processes are reversed. > Here is one use case: > [snip] > I hope it would be possible in this case to get a message size closer to > case #3 rather than case #4? Nope, your use case is exactly the same as case #4 and would be exactly the same size (assuming you're using a stream-like cipher and not a block-like cipher). The difference is only whether you encrypt the sign or sign then encrypt. The number of bytes required to hold the signature and encryption metadata doesn't change and cannot be combined just because you swap the order. > G=C3=B6ran -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue May 12 12:24:17 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2A71A8880 for ; Tue, 12 May 2015 12:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA7vkMfJGSnX for ; Tue, 12 May 2015 12:23:56 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0401ACEAC for ; Tue, 12 May 2015 12:23:56 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id F23E52CA28; Tue, 12 May 2015 12:23:55 -0700 (PDT) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <006b01d08c1b$a6831b00$f3895100$@augustcellars.com> In-Reply-To: Date: Tue, 12 May 2015 12:22:29 -0700 Message-ID: <014601d08ce8$fd094990$f71bdcb0$@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: AQFFi6Vgyo+kYY/pA3P33MoaH5S9XAIqBq/Cnn1QyFA= Content-Language: en-us Archived-At: Subject: Re: [Cose] Parameterization of CCM mode X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:24:06 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Tuesday, May 12, 2015 5:52 AM > To: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] Parameterization of CCM mode >=20 >=20 > Hi Jim >=20 > Thanks for the rapid progress. >=20 > Since there are several references to > https://tools.ietf.org/html/draft-selander-ace-object-security-01, let = me give > some context about what this draft intended to do that is relevant to = COSE for > those that have not read it. First of all, it did not intend to = specify a generic > compact secure message format as is the objective of COSE, see = Appendix C: >=20 > "For constrained environments it is important that the message > expansion due to security overhead is kept at a minimum. As an > attempt to assess what this minimum expansion could be, an = optimized > Secure Message format is defined, tailor-made for this setting. = This > is intended as a benchmark for generic content formats, to allow an > informed decision about which Secure Message format to mandate in a > future version of this draft.=E2=80=9D >=20 > The main design objective was thus to estimate a minimum message size = (using > a bespoke format called CSM) while at the same time be flexible to = take into > account the great variation of settings for which this may be applied = by > allowing different ciphersuites, lengths of key identifiers and = sequence > numbers. >=20 > As indicated by the latter, another design objective was to have = built-in support > for replay protection suitable for constrained devices independent of = cipher > suite. In this respect indexing the use of a particular key with a = sequence > numbers seemed a better candidate than nonces and time, considering = storage > and inaccuracy of clocks. Since different applications have different > requirements in terms of number of messages we allowed a variable = counter > size and to minimize message size a default truncation of initial = sequence > number bytes containing zeros. Since different applications have = varying > degree of strictness on replay (sliding window to allow reordering = etc.) we left > to the application to define the exact processing rules. Finally, = similar > considerations was made on lengths of key identifiers, where different > applications may require different sizes of name spaces. I used this draft as the only one that I found with some concrete = details about encryption. I did not use it because it was either a good = or bad design, just the only one that I found and thus the only starting = point I had. =20 >=20 >=20 > Further comments inline >=20 >=20 > On 2015-05-11 20:52, "Jim Schaad" wrote: >=20 > >As part of looking at the sizes of encodings for items, I was looking > >at the use of CCM mode and trying to make guesses about what the > >parameters are that are going to be used in constrained devices. > >Trying to get the info from > >https://tools.ietf.org/html/draft-selander-ace-object-security-01 did > >not really help as it seemed to not have the correct set encoded into = it. > > > >The parameters that I have identified for CCM are the following: > > > >1) Key size - 128, 192, 256 > >2) M - number of octets in the authentication field - 4, 6, 8, 10, = 12, > >14, > >16 > >3) L - number of octets in the length field - 2-8 octets >=20 > Length of message is not included in the CSM as we assumed that would = be > given by UDP. This may be a too restrictive assumption for COSE. > I believe for UDP you would require 16 octets in the normal case, = someone else > could correct me on this. I would start by suggesting that you re-read the CCM draft. L is a = parameter of the CCM algorithm, not a value in the wrapper. The length = of the plain text is included in the computation of the authentication = value. This is not anything about COSE or CSM, it is about CCM. >=20 > > > >The key size does not affect the size of the output so it is not a = big > >issue relative to things. While I would guess that generally only > >128-bit keys are used, it would probably makes sense to define at = least > >128 and 256 bit key algorithms >=20 > Agree, that should be enough. >=20 > > > >The size of the authentication fields is currently defined as 8 from > >the Selander draft. It would make sense to have at least two sizes > >defined - > >8 > >and 16, but I am not sure about other sizes. >=20 > Agree, good choice. >=20 > > > >The hardest one to make decisions on is the message length field. = For > >constrained devices this could be a very small value as a value of 2 > >would all for encrypting 2^(8*2) bytes and would allow for the key to > >be used a lot as one then has a nonce of 15-2=3D13 bytes (allowing = for a > >key to be used ~ 2^13 times assuming no birthday attacks). Nonce > >values as 15-L bytes long and nonce values must not be re-used. On = the > >other hand, for a more general usage it makes sense to have a larger > >value of L to allow for bigger messages with less key re-usage. >=20 > I don=E2=80=99t understand the relationship between size of message = and size of nonce. Again, I think you need to read the CCM draft. It has to do with how = the counter field is built internally for CCM. >=20 > > > >The Selander draft appears to make the assumption that different keys > >are used in each direction when encrypting messages. This makes one > >problem easier - there is no need to divide up the nonce space so = that > >nonce values are not re-used when encrypting messages. It also makes > >nonce usage easier because there is no need to try and synchronize = the > >nonce value usage between the two parties. On the other hand, it = means > >that there is more data that needs to be keep on the device as you = now > >need 2 keys and 2 nonce counters for each pair-wise link which might = be > >a space issue on the device. >=20 >=20 > Unique keys in each direction is in general good practice. In the case = of sending > one message to multiple receivers, each receiver needs a key and a = nonce per > sender. We used that as a general principle for all messages being = passed. For > nonce we proposed to reuse the sequence number + a salt (see below), = so it is > only the salt that is additionally stored. Moreover, if keys are = changed for each > message there is anyway need to store a random value from which new = keys > are derived (we used a different approach, see below). >=20 > > > >In the Selander draft, there was the idea of having both a nonce > >counter and salt value which is used to construct the nonce used in = the > >encryption step. > >As far as I know there is no security reason to salt the nonce unless > >there is an expectation that the keys would ever be re-used. If new > >keys are generated each time that keys are generated then the salt is > >probably not > >necessary to have. However, use of a salt value can be used to = divide up > >the nonce space if the same key value is used in both directions. >=20 > As mentioned above, we already assumed there will be a unique sequence > number associated to this key identifier and message. The combination = of salt > and sequence number becomes an unique nonce for each message which can > be used with this key until the counter wraps, when key and key = identifier needs > to be updated. Since there is a processing cost to change key for each = message, > we thought this construction of using the key for a number of unique = nonces > could be favorable without compromising security. Again - I think you need to read and understand the CCM draft. I don't = believe that the salt is required for anything, just the nonce works. = There is an independent counter for each message. When you say counter = above I am assuming that you are talking about a nonce counter. = Having a salt value potentially decreases the number of times that the = same key can be used as it reduces the range of the sequence number. jim >=20 >=20 >=20 > G=C3=B6ran >=20 >=20 > > > >While we need to do more research on figuring out how many times a = key > >can be used based on the nonce length, this is probably not dependent > >on the values of L that we want to standardize. The more items we > >standardize the more selection different protocols will have, but I > >don't know how much parameterization the implementations support or = if > >they are using fixed parameterization. > > > >Jim > > > > > >_______________________________________________ > >Cose mailing list > >Cose@ietf.org > >https://www.ietf.org/mailman/listinfo/cose From nobody Tue May 12 12:39:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B151A8A62 for ; Tue, 12 May 2015 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZGkcnHKvMvv for ; Tue, 12 May 2015 12:39:26 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52591A8955 for ; Tue, 12 May 2015 12:39:24 -0700 (PDT) Received: from Philemon (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 6A9462C9BB; Tue, 12 May 2015 12:39:24 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" , =?UTF-8?Q?'G=C3=B6ran_Selander'?= References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> In-Reply-To: Date: Tue, 12 May 2015 12:37:55 -0700 Message-ID: <014c01d08ceb$2674b3d0$735e1b70$@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: AQIRw4TV5Qa1tmqUq/LMooYCv8FDfgK0JaodAiqyvKqcz1fWcA== Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:39:28 -0000 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Tuesday, May 12, 2015 11:23 AM > To: G=C3=B6ran Selander > Cc: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] Sizes of messages >=20 > G=C3=B6ran Selander writes: >=20 > > On 2015-05-11 07:55, "Jim Schaad" wrote: > > > [snip] > >>Case #2 - Encryption on a content using a direct key. The details = of > >>the message that I am looking at are: > [snip] > >> - In this case using maps takes 60 octets and using arrays takes = 61 > >>octets. > >> > >>Case #3 - Sign a message using an asymmetric key. The details of = the > >>message that I am looking at are: > [snip] > >> - In this case using maps takes 82 bytes and arrays takes 83 = bytes. > >>If content is included, then the array will be the same size as for = map. > >> > >>Case #4 - Sign a message using an asymmetric key and encrypt it = using > >>a direct key. > >> - For the signature, the conditions are the same as for case > >>#3 with the exception that the content is carried in the message. > >> - For the encrypt operation, the conditions are the same as for = case > >>#2. > >> - For map, the size is 145 octets, for array the size is 146 = octets. > >> > >>For all of the cases that I have provided above, I am using the > >>minimal set of fields. If any other fields are added, for example > >>unprotected attributes, then the balance tips from maps to arrays as > >>the cost to add a field is 2 octets plus the data, whereas the cost = to > >>add a field to an array is just the size of the data. > >> > > > > I=E2=80=99m missing an encrypt-then-sign case: Encryption of content = using a > > direct key and sign it using an asymmetric key. >=20 > This is the same as case #4 except that the ordering/processes are = reversed. >=20 > > Here is one use case: > > > [snip] > > I hope it would be possible in this case to get a message size = closer > > to case #3 rather than case #4? >=20 > Nope, your use case is exactly the same as case #4 and would be = exactly the > same size (assuming you're using a stream-like cipher and not a = block-like > cipher). The difference is only whether you encrypt the sign or sign = then > encrypt. The number of bytes required to hold the signature and = encryption > metadata doesn't change and cannot be combined just because you swap > the order. >=20 > > G=C3=B6ran What Derek said, this is basically re-arranging the deck chairs on the = titanic, does not make much difference. In terms of the use case that you gave (and Derek snipped). I would = want to know who is doing the group key distribution mechanism to the = system. I would normally expect this to be the same entity as is doing = the re-distribution of the message so I don't know that I think this is = a very realistic use case. That entity is going to know all of the keys = that belong to everybody anyway. Jim >=20 > -derek >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Tue May 12 13:26:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26911AD062 for ; Tue, 12 May 2015 13:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYWhLAacHPmP for ; Tue, 12 May 2015 13:26:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13E51AD060 for ; Tue, 12 May 2015 13:26:12 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-ad-555261e2e741 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.EF.17665.2E162555; Tue, 12 May 2015 22:26:11 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Tue, 12 May 2015 22:26:10 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , 'Derek Atkins' Thread-Topic: [Cose] Sizes of messages Thread-Index: AQHQjOCrIpBM2Wx4Q8mhu5BRuxfBUZ14mwCAgAAvAYA= Date: Tue, 12 May 2015 20:26:09 +0000 Message-ID: References: <027e01d08baf$0fa1bd20$2ee53760$@augustcellars.com> <014c01d08ceb$2674b3d0$735e1b70$@augustcellars.com> In-Reply-To: <014c01d08ceb$2674b3d0$735e1b70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <419C1454ED0A884CB80BEE2A809B4099@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvje7jxKBQg5Z1TBbTtk5ltVg5aQe7 xerp39kcmD02zpnO5rFkyU8mj+VfH7AEMEdx2aSk5mSWpRbp2yVwZfx618FY8Iyz4lfjYpYG xiOcXYycHBICJhKz2+ezQ9hiEhfurWfrYuTiEBI4yigx8ddRJghnMaNE358TLCBVbAIuEg8a HjGB2CICnhJd046ygtjMAsoSjRsuAdVwcAgLqEr83mQGUaImse3BDEaQsIiAlcST3QkgYRag ikNHm9lAbF4BC4n577dD7T3NKNFwegVYglPAQWLbxQdgNiPQcd9PrWGCWCUucevJfCaIowUk luw5zwxhi0q8fPwP7BxRAT2Jldeb2CDiShIrtl8Cu4FZQFNi/S59iDHWEvufbWGBsBUlpnQ/ ZIe4R1Di5MwnLBMYJWYh2TYLoXsWku5ZSLpnIelewMi6ilG0OLW4ODfdyFgvtSgzubg4P08v L7VkEyMwLg9u+a27g3H1a8dDjAIcjEo8vAvsg0KFWBPLiitzDzFKc7AoifPaGR8KERJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cCo/fnJeZWNwVvL6iwemlupPG4oyHsm9leBS9t1gtG5q7oL Vx/bvvbF9aj92wUq3fk1lkQ9mqz+6aDQiyjVhmaDdkvdJMe9At9PWB7a/+XkZFHn1ma9F3qF K0wF2NXLjBhPVYrcVP4uGhWbOo35snbNgRfS7wz6T0Um/jXWe+fUxuG/V9Zxt7ESS3FGoqEW c1FxIgDRbbSZrAIAAA== Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Sizes of messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:26:15 -0000 DQoNCk9uIDIwMTUtMDUtMTIgMjE6MzcsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCj4NCj5JbiB0ZXJtcyBvZiB0aGUgdXNlIGNhc2UgdGhhdCB5b3UgZ2F2 ZSAoYW5kIERlcmVrIHNuaXBwZWQpLiAgSSB3b3VsZCB3YW50DQo+dG8ga25vdyB3aG8gaXMgZG9p bmcgdGhlIGdyb3VwIGtleSBkaXN0cmlidXRpb24gbWVjaGFuaXNtIHRvIHRoZSBzeXN0ZW0uDQo+ IEkgd291bGQgbm9ybWFsbHkgZXhwZWN0IHRoaXMgdG8gYmUgdGhlIHNhbWUgZW50aXR5IGFzIGlz IGRvaW5nIHRoZQ0KPnJlLWRpc3RyaWJ1dGlvbiBvZiB0aGUgbWVzc2FnZSBzbyBJIGRvbid0IGtu b3cgdGhhdCBJIHRoaW5rIHRoaXMgaXMgYQ0KPnZlcnkgcmVhbGlzdGljIHVzZSBjYXNlLiAgVGhh dCBlbnRpdHkgaXMgZ29pbmcgdG8ga25vdyBhbGwgb2YgdGhlIGtleXMNCj50aGF0IGJlbG9uZyB0 byBldmVyeWJvZHkgYW55d2F5Lg0KDQpUaGUga2V5IGRpc3RyaWJ1dGlvbiB3b3VsZCBiZSBkb25l IGJ5IGFuIEF1dGhvcml6YXRpb24gU2VydmVyIChzZWUgZS5nLg0KU2VjdGlvbiAyLjMgb2YgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VyZGVzLWFjZS1hY3RvcnMpDQp3 aGVyZWFzIHRoZSBwdWItc3ViIGJyb2tlciB3b3VsZCBiZSBhbiBpbnRlcm1lZGlhdGUgbm9kZSBi ZXR3ZWVuIHRoZQ0KZW5kcG9pbnRzIG9mIGZpZ3VyZSA3IChjb21wYXJlIHNlY3Rpb24gMy4xKS4g VGhlIGZ1bmN0aW9ucyBhcmUgZGlzdGluY3QsDQp0aGUgZm9ybWVyIGlzIGEgdHJ1c3RlZCB0aGly ZCBwYXJ0eSwgdGhlIGxhdHRlciBhIGZvcndhcmRpbmcgZnVuY3Rpb24sIGFuZA0KdGhleSBtYXkg d2VsbCBiZSBwZXJmb3JtZWQgYnkgZGlmZmVyZW50IGVudGl0aWVzLg0KDQpHw7ZyYW4NCg0KDQoN Cg== From nobody Wed May 13 01:23:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049EB1A1BB4 for ; Wed, 13 May 2015 01:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvxrPxqnc2FQ for ; Wed, 13 May 2015 01:23:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E1E1A1B9A for ; Wed, 13 May 2015 01:23:00 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-fd-555309e235ee Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.85.17665.2E903555; Wed, 13 May 2015 10:22:58 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Wed, 13 May 2015 10:22:58 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Parameterization of CCM mode Thread-Index: AdCMD4iwiwDWGFPrQzmf6gFdLBxZmwAovCMAAAlv7YAAH3LNgA== Date: Wed, 13 May 2015 08:22:57 +0000 Message-ID: References: <006b01d08c1b$a6831b00$f3895100$@augustcellars.com> <014601d08ce8$fd094990$f71bdcb0$@augustcellars.com> In-Reply-To: <014601d08ce8$fd094990$f71bdcb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <404968BE575B134ABA47ADB522C023C3@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VvcRZ3CowcyrphbTtk5ltVg9/Tub A5PHxjnT2TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx+sozloI5LhW3X+9ibWDc49TFyMkhIWAi 8fzsdHYIW0ziwr31bF2MXBxCAkcZJVafmMAI4SxmlNj0ahYjSBWbgIvEg4ZHTCC2iICHxK7d n5hBbGEBA4mNK3ug4oYSX2c8AarnALKdJGZc4QYJswioSrzedQoszCtgIbF5pSfE+CWMEvfu ngVr5RRwkNj++inYKkagg76fWgMWZxYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwpiiwroSay8 3sQGEVeUuDp9ORPILmYBTYn1u/QhTGuJaz/EISYqSkzpfgj2Oq+AoMTJmU9YJjCKz0KybBZC 8yyE5llImmchaV7AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzDODm75rbuDcfVrx0OM AhyMSjy8CS+CQoVYE8uKK3MPMUpzsCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wDi1zEmV3SMmmeWco/2pv1NvPzX6zbflaJQ3xy5ml1R1J1XD1BMGh5feiXNsY7u6fMne+62X 13/fxWc4K6RV4KtizK71rp91A3eEZeU+DbdQfXUnyWehs8IZ4dt3JFNN6+P4l6yqrKt7NNVp t7dw6uUX3Ys21D2yXvy89WXVjJrDM+PCsk+x+iixFGckGmoxFxUnAgAix+G6lAIAAA== Archived-At: Subject: Re: [Cose] Parameterization of CCM mode X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 08:23:43 -0000 DQoNCk9uIDIwMTUtMDUtMTIgMjE6MjIsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4gd3JvdGU6DQoNCg0KPg0KPj4gDQo+PiANCj4+IEZ1cnRoZXIgY29tbWVudHMgaW5saW5l DQo+PiANCj4+IA0KPj4gT24gMjAxNS0wNS0xMSAyMDo1MiwgIkppbSBTY2hhYWQiIDxpZXRmQGF1 Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4+IA0KPj4gPkFzIHBhcnQgb2YgbG9va2luZyBhdCB0 aGUgc2l6ZXMgb2YgZW5jb2RpbmdzIGZvciBpdGVtcywgSSB3YXMgbG9va2luZw0KPj4gPmF0IHRo ZSB1c2Ugb2YgQ0NNIG1vZGUgYW5kIHRyeWluZyB0byBtYWtlIGd1ZXNzZXMgYWJvdXQgd2hhdCB0 aGUNCj4+ID5wYXJhbWV0ZXJzIGFyZSB0aGF0IGFyZSBnb2luZyB0byBiZSB1c2VkIGluIGNvbnN0 cmFpbmVkIGRldmljZXMuDQo+PiA+VHJ5aW5nIHRvIGdldCB0aGUgaW5mbyBmcm9tDQo+PiA+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJp dHktMDEgZGlkDQo+PiA+bm90IHJlYWxseSBoZWxwIGFzIGl0IHNlZW1lZCB0byBub3QgaGF2ZSB0 aGUgY29ycmVjdCBzZXQgZW5jb2RlZCBpbnRvDQo+Pml0Lg0KPj4gPg0KPj4gPlRoZSBwYXJhbWV0 ZXJzIHRoYXQgSSBoYXZlIGlkZW50aWZpZWQgZm9yIENDTSBhcmUgdGhlIGZvbGxvd2luZzoNCj4+ ID4NCj4+ID4xKSAgS2V5IHNpemUgLSAxMjgsIDE5MiwgMjU2DQo+PiA+MikgIE0gLSBudW1iZXIg b2Ygb2N0ZXRzIGluIHRoZSBhdXRoZW50aWNhdGlvbiBmaWVsZCAtIDQsIDYsIDgsIDEwLCAxMiwN Cj4+ID4xNCwNCj4+ID4xNg0KPj4gPjMpICBMIC0gbnVtYmVyIG9mIG9jdGV0cyBpbiB0aGUgbGVu Z3RoIGZpZWxkIC0gMi04IG9jdGV0cw0KPj4gDQo+PiBMZW5ndGggb2YgbWVzc2FnZSBpcyBub3Qg aW5jbHVkZWQgaW4gdGhlIENTTSBhcyB3ZSBhc3N1bWVkIHRoYXQgd291bGQgYmUNCj4+IGdpdmVu IGJ5IFVEUC4gVGhpcyBtYXkgYmUgYSB0b28gcmVzdHJpY3RpdmUgYXNzdW1wdGlvbiBmb3IgQ09T RS4NCj4+IEkgYmVsaWV2ZSBmb3IgVURQIHlvdSB3b3VsZCByZXF1aXJlIDE2IG9jdGV0cyBpbiB0 aGUgbm9ybWFsIGNhc2UsDQo+PnNvbWVvbmUgZWxzZQ0KPj4gY291bGQgY29ycmVjdCBtZSBvbiB0 aGlzLg0KPg0KPkkgd291bGQgc3RhcnQgYnkgc3VnZ2VzdGluZyB0aGF0IHlvdSByZS1yZWFkIHRo ZSBDQ00gZHJhZnQuICBMIGlzIGENCj5wYXJhbWV0ZXIgb2YgdGhlIENDTSBhbGdvcml0aG0sIG5v dCBhIHZhbHVlIGluIHRoZSB3cmFwcGVyLiAgVGhlIGxlbmd0aA0KPm9mIHRoZSBwbGFpbiB0ZXh0 IGlzIGluY2x1ZGVkIGluIHRoZSBjb21wdXRhdGlvbiBvZiB0aGUgYXV0aGVudGljYXRpb24NCj52 YWx1ZS4gIFRoaXMgaXMgbm90IGFueXRoaW5nIGFib3V0IENPU0Ugb3IgQ1NNLCBpdCBpcyBhYm91 dCBDQ00uDQo+DQo+PiANCj4+ID4NCj4+ID5UaGUga2V5IHNpemUgZG9lcyBub3QgYWZmZWN0IHRo ZSBzaXplIG9mIHRoZSBvdXRwdXQgc28gaXQgaXMgbm90IGEgYmlnDQo+PiA+aXNzdWUgcmVsYXRp dmUgdG8gdGhpbmdzLiAgV2hpbGUgSSB3b3VsZCBndWVzcyB0aGF0IGdlbmVyYWxseSBvbmx5DQo+ PiA+MTI4LWJpdCBrZXlzIGFyZSB1c2VkLCBpdCB3b3VsZCBwcm9iYWJseSBtYWtlcyBzZW5zZSB0 byBkZWZpbmUgYXQgbGVhc3QNCj4+ID4xMjggYW5kIDI1NiBiaXQga2V5IGFsZ29yaXRobXMNCj4+ IA0KPj4gQWdyZWUsIHRoYXQgc2hvdWxkIGJlIGVub3VnaC4NCj4+IA0KPj4gPg0KPj4gPlRoZSBz aXplIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBmaWVsZHMgaXMgY3VycmVudGx5IGRlZmluZWQgYXMg OCBmcm9tDQo+PiA+dGhlIFNlbGFuZGVyIGRyYWZ0LiAgSXQgd291bGQgbWFrZSBzZW5zZSB0byBo YXZlIGF0IGxlYXN0IHR3byBzaXplcw0KPj4gPmRlZmluZWQgLQ0KPj4gPjgNCj4+ID5hbmQgMTYs IGJ1dCBJIGFtIG5vdCBzdXJlIGFib3V0IG90aGVyIHNpemVzLg0KPj4gDQo+PiBBZ3JlZSwgZ29v ZCBjaG9pY2UuDQo+PiANCj4+ID4NCj4+ID5UaGUgaGFyZGVzdCBvbmUgdG8gbWFrZSBkZWNpc2lv bnMgb24gaXMgdGhlIG1lc3NhZ2UgbGVuZ3RoIGZpZWxkLiAgRm9yDQo+PiA+Y29uc3RyYWluZWQg ZGV2aWNlcyB0aGlzIGNvdWxkIGJlIGEgdmVyeSBzbWFsbCB2YWx1ZSBhcyBhIHZhbHVlIG9mIDIN Cj4+ID53b3VsZCBhbGwgZm9yIGVuY3J5cHRpbmcgMl4oOCoyKSBieXRlcyBhbmQgd291bGQgYWxs b3cgZm9yIHRoZSBrZXkgdG8NCj4+ID5iZSB1c2VkIGEgbG90IGFzIG9uZSB0aGVuIGhhcyBhIG5v bmNlIG9mIDE1LTI9MTMgYnl0ZXMgKGFsbG93aW5nIGZvciBhDQo+PiA+a2V5IHRvIGJlIHVzZWQg fiAyXjEzIHRpbWVzIGFzc3VtaW5nIG5vIGJpcnRoZGF5IGF0dGFja3MpLiAgTm9uY2UNCj4+ID52 YWx1ZXMgYXMgMTUtTCBieXRlcyBsb25nIGFuZCBub25jZSB2YWx1ZXMgbXVzdCBub3QgYmUgcmUt dXNlZC4gIE9uIHRoZQ0KPj4gPm90aGVyIGhhbmQsIGZvciBhIG1vcmUgZ2VuZXJhbCB1c2FnZSBp dCBtYWtlcyBzZW5zZSB0byBoYXZlIGEgbGFyZ2VyDQo+PiA+dmFsdWUgb2YgTCB0byBhbGxvdyBm b3IgYmlnZ2VyIG1lc3NhZ2VzIHdpdGggbGVzcyBrZXkgcmUtdXNhZ2UuDQo+PiANCj4+IEkgZG9u 4oCZdCB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBzaXplIG9mIG1lc3NhZ2Ug YW5kIHNpemUgb2YNCj4+bm9uY2UuDQo+DQo+QWdhaW4sIEkgdGhpbmsgeW91IG5lZWQgdG8gcmVh ZCB0aGUgQ0NNIGRyYWZ0LiAgIEl0IGhhcyB0byBkbyB3aXRoIGhvdw0KPnRoZSBjb3VudGVyIGZp ZWxkIGlzIGJ1aWx0IGludGVybmFsbHkgZm9yIENDTS4NCj4NCj4+IA0KPj4gPg0KPj4gPlRoZSBT ZWxhbmRlciBkcmFmdCBhcHBlYXJzIHRvIG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCBkaWZmZXJl bnQga2V5cw0KPj4gPmFyZSB1c2VkIGluIGVhY2ggZGlyZWN0aW9uIHdoZW4gZW5jcnlwdGluZyBt ZXNzYWdlcy4gIFRoaXMgbWFrZXMgb25lDQo+PiA+cHJvYmxlbSBlYXNpZXIgLSB0aGVyZSBpcyBu byBuZWVkIHRvIGRpdmlkZSB1cCB0aGUgbm9uY2Ugc3BhY2Ugc28gdGhhdA0KPj4gPm5vbmNlIHZh bHVlcyBhcmUgbm90IHJlLXVzZWQgd2hlbiBlbmNyeXB0aW5nIG1lc3NhZ2VzLiAgSXQgYWxzbyBt YWtlcw0KPj4gPm5vbmNlIHVzYWdlIGVhc2llciBiZWNhdXNlIHRoZXJlIGlzIG5vIG5lZWQgdG8g dHJ5IGFuZCBzeW5jaHJvbml6ZSB0aGUNCj4+ID5ub25jZSB2YWx1ZSB1c2FnZSBiZXR3ZWVuIHRo ZSB0d28gcGFydGllcy4gIE9uIHRoZSBvdGhlciBoYW5kLCBpdCBtZWFucw0KPj4gPnRoYXQgdGhl cmUgaXMgbW9yZSBkYXRhIHRoYXQgbmVlZHMgdG8gYmUga2VlcCBvbiB0aGUgZGV2aWNlIGFzIHlv dSBub3cNCj4+ID5uZWVkIDIga2V5cyBhbmQgMiBub25jZSBjb3VudGVycyBmb3IgZWFjaCBwYWly LXdpc2UgbGluayB3aGljaCBtaWdodCBiZQ0KPj4gPmEgc3BhY2UgaXNzdWUgb24gdGhlIGRldmlj ZS4NCj4+IA0KPj4gDQo+PiBVbmlxdWUga2V5cyBpbiBlYWNoIGRpcmVjdGlvbiBpcyBpbiBnZW5l cmFsIGdvb2QgcHJhY3RpY2UuIEluIHRoZSBjYXNlDQo+Pm9mIHNlbmRpbmcNCj4+IG9uZSBtZXNz YWdlIHRvIG11bHRpcGxlIHJlY2VpdmVycywgZWFjaCByZWNlaXZlciBuZWVkcyBhIGtleSBhbmQg YQ0KPj5ub25jZSBwZXINCj4+IHNlbmRlci4gV2UgdXNlZCB0aGF0IGFzIGEgZ2VuZXJhbCBwcmlu Y2lwbGUgZm9yIGFsbCBtZXNzYWdlcyBiZWluZw0KPj5wYXNzZWQuIEZvcg0KPj4gbm9uY2Ugd2Ug cHJvcG9zZWQgdG8gcmV1c2UgdGhlIHNlcXVlbmNlIG51bWJlciArIGEgc2FsdCAoc2VlIGJlbG93 KSwgc28NCj4+aXQgaXMNCj4+IG9ubHkgdGhlIHNhbHQgdGhhdCBpcyBhZGRpdGlvbmFsbHkgc3Rv cmVkLiBNb3Jlb3ZlciwgaWYga2V5cyBhcmUNCj4+Y2hhbmdlZCBmb3IgZWFjaA0KPj4gbWVzc2Fn ZSB0aGVyZSBpcyBhbnl3YXkgbmVlZCB0byBzdG9yZSBhIHJhbmRvbSB2YWx1ZSBmcm9tIHdoaWNo IG5ldyBrZXlzDQo+PiBhcmUgZGVyaXZlZCAod2UgdXNlZCBhIGRpZmZlcmVudCBhcHByb2FjaCwg c2VlIGJlbG93KS4NCj4+IA0KPj4gPg0KPj4gPkluIHRoZSBTZWxhbmRlciBkcmFmdCwgdGhlcmUg d2FzIHRoZSBpZGVhIG9mIGhhdmluZyBib3RoIGEgbm9uY2UNCj4+ID5jb3VudGVyIGFuZCBzYWx0 IHZhbHVlIHdoaWNoIGlzIHVzZWQgdG8gY29uc3RydWN0IHRoZSBub25jZSB1c2VkIGluIHRoZQ0K Pj4gPmVuY3J5cHRpb24gc3RlcC4NCj4+ID5BcyBmYXIgYXMgSSBrbm93IHRoZXJlIGlzIG5vIHNl Y3VyaXR5IHJlYXNvbiB0byBzYWx0IHRoZSBub25jZSB1bmxlc3MNCj4+ID50aGVyZSBpcyBhbiBl eHBlY3RhdGlvbiB0aGF0IHRoZSBrZXlzIHdvdWxkIGV2ZXIgYmUgcmUtdXNlZC4gIElmIG5ldw0K Pj4gPmtleXMgYXJlIGdlbmVyYXRlZCBlYWNoIHRpbWUgdGhhdCBrZXlzIGFyZSBnZW5lcmF0ZWQg dGhlbiB0aGUgc2FsdCBpcw0KPj4gPnByb2JhYmx5IG5vdA0KPj4gPm5lY2Vzc2FyeSB0byBoYXZl LiAgIEhvd2V2ZXIsIHVzZSBvZiBhIHNhbHQgdmFsdWUgY2FuIGJlIHVzZWQgdG8NCj4+ZGl2aWRl IHVwDQo+PiA+dGhlIG5vbmNlIHNwYWNlIGlmIHRoZSBzYW1lIGtleSB2YWx1ZSBpcyB1c2VkIGlu IGJvdGggZGlyZWN0aW9ucy4NCj4+IA0KPj4gQXMgbWVudGlvbmVkIGFib3ZlLCB3ZSBhbHJlYWR5 IGFzc3VtZWQgdGhlcmUgd2lsbCBiZSBhIHVuaXF1ZSBzZXF1ZW5jZQ0KPj4gbnVtYmVyIGFzc29j aWF0ZWQgdG8gdGhpcyBrZXkgaWRlbnRpZmllciBhbmQgbWVzc2FnZS4gVGhlIGNvbWJpbmF0aW9u DQo+Pm9mIHNhbHQNCj4+IGFuZCBzZXF1ZW5jZSBudW1iZXIgYmVjb21lcyBhbiB1bmlxdWUgbm9u Y2UgZm9yIGVhY2ggbWVzc2FnZSB3aGljaCBjYW4NCj4+IGJlIHVzZWQgd2l0aCB0aGlzIGtleSB1 bnRpbCB0aGUgY291bnRlciB3cmFwcywgd2hlbiBrZXkgYW5kIGtleQ0KPj5pZGVudGlmaWVyIG5l ZWRzDQo+PiB0byBiZSB1cGRhdGVkLiBTaW5jZSB0aGVyZSBpcyBhIHByb2Nlc3NpbmcgY29zdCB0 byBjaGFuZ2Uga2V5IGZvciBlYWNoDQo+Pm1lc3NhZ2UsDQo+PiB3ZSB0aG91Z2h0IHRoaXMgY29u c3RydWN0aW9uIG9mIHVzaW5nIHRoZSBrZXkgZm9yIGEgbnVtYmVyIG9mIHVuaXF1ZQ0KPj5ub25j ZXMNCj4+IGNvdWxkIGJlIGZhdm9yYWJsZSB3aXRob3V0IGNvbXByb21pc2luZyBzZWN1cml0eS4N Cj4NCj5BZ2FpbiAtIEkgdGhpbmsgeW91IG5lZWQgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZCB0aGUg Q0NNIGRyYWZ0LiAgSSBkb24ndA0KPmJlbGlldmUgdGhhdCB0aGUgc2FsdCBpcyByZXF1aXJlZCBm b3IgYW55dGhpbmcsIGp1c3QgdGhlIG5vbmNlIHdvcmtzLg0KPlRoZXJlIGlzIGFuIGluZGVwZW5k ZW50IGNvdW50ZXIgZm9yIGVhY2ggbWVzc2FnZS4gIFdoZW4geW91IHNheSBjb3VudGVyDQo+YWJv dmUgSSBhbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgdGFsa2luZyBhYm91dCBhIG5vbmNlIGNvdW50 ZXIuICAgIEhhdmluZw0KPmEgc2FsdCB2YWx1ZSBwb3RlbnRpYWxseSBkZWNyZWFzZXMgdGhlIG51 bWJlciBvZiB0aW1lcyB0aGF0IHRoZSBzYW1lIGtleQ0KPmNhbiBiZSB1c2VkIGFzIGl0IHJlZHVj ZXMgdGhlIHJhbmdlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIuDQoNCk9LLCBwb2ludCB0YWtlbiwg c29ycnkgZm9yIGJlaW5nIGlnbm9yYW50LiBJdCBoYXMgYmVlbiBhbiBhbWJpdGlvbiB0byBiYXNl DQp0aGUgcHJvcG9zYWwgb24gdGhlIHNhbWUgcHJpbWl0aXZlcyBhcyBpcyByZWNvbW1lbmRlZCBi eSBDb0FQLCB3aGVyZSBJDQpiZWxpZXZlIEw9MyAoaS5lLiAxMiBieXRlcyBub25jZSkgaXMgZGVm YXVsdCwgZm9sbG93aW5nIFJGQzY2NTUuIEhvd2V2ZXINCmluIEFwcGVuZGl4IEMgYW5kIGluIHRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBvdXIgZHJhZnQgd2UgYXNzdW1lDQp0aGF0IHRo ZSBlbnRpcmUgQUVTIElWIG9mIDE2IGJ5dGVzLCBwYXJ0aXRpb25lZCBpbnRvIDggYnl0ZXMgc2Fs dA0KKGVzdGFibGlzaGVkIG91dCBvZiBiYW5kKSBhbmQgOCBieXRlcyBzZXF1ZW5jZSBudW1iZXIg KGluY2x1ZGVkIGluIHRoZQ0KbWVzc2FnZSksIGlzIGF2YWlsYWJsZSBhcyBub25jZSBmb3IgQ0NN IC0gd2hpY2ggaXMgcGxhaW4gd3JvbmcuIENoYW5naW5nDQp0aGF0IGZyb20gdG8gNCBieXRlcyBz YWx0IHdvdWxkIGNvcnJlY3QgdGhhdCBlcnJvciBhbmQgaGFybW9uaXplIHdpdGgNClJGQzY2NTUu IEkgd291bGQgYXNzdW1lIEw9MyBpcyBhIHN0cm9uZyBjYW5kaWRhdGUgZm9yIENPU0UuIFJGQzQz MDkNCm1hbmRhdGVzIEw9NCB0byBhY2NvbW1vZGF0ZSBqdW1ib2dyYW1zLCBidXQgSSBkb27igJl0 IGtub3cgaWYgdGhhdCBpcyBpbg0Kc2NvcGUgb2YgQ09TRS4NCg0KDQpHw7ZyYW4NCg0KDQo= From nobody Wed May 13 19:18:57 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2808F1A8982; Wed, 13 May 2015 19:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUkjfoVxHKXC; Wed, 13 May 2015 19:17:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 042A51A8971; Wed, 13 May 2015 19:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 19:17:46 -0700 Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 19:18:56 -0700 Cc: cose@ietf.org Subject: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 02:17:47 -0000 Ben Campbell has entered the following ballot position for charter-ietf-cose-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cose/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Maybe I am missing something, but I don't see an explicit statement of what COSE is setting out to accomplish until I get to the deliverables. I can infer it from the group name, and from the JOSE reference. But a sentence in the first paragraph to the effect that COSE seeks to create CBOR-based object signing and encryption formats would be helpful. (Probably right before the JOSE reference). From nobody Thu May 14 05:37:30 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7612A1A8AA0; Thu, 14 May 2015 05:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7sDSu_gdVla; Thu, 14 May 2015 05:37:24 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8693B1A9135; Thu, 14 May 2015 05:35:18 -0700 (PDT) Received: by layy10 with SMTP id y10so65286236lay.0; Thu, 14 May 2015 05:35:17 -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=FEgdkH2zXz5H+kOsp2fe9n9s/E5cWL09oTWtAUNaSHo=; b=OXyXiJlbHiac74c1/f/5+bc+DdSDbE2DncsyriloWXepYBDrQBZicC0vqxgi9cZxxs fUUnbvegmhdXa5dqfTIpVsieEAmrchDOjFH4RaZjjlju6xTK+hWmVNAhOmxGPM3OLGYK PnfeT8rwOtkP9ZCRchVjqB8rAfiOvTXiE+LurzvB9r4duLZZ2lMmrZnqi20hyDm3vjtV 2IOjxZOXX6Go0E6bI0MB1BzgDAOB/xXyMfuuwprPeOv0/hmdNnSLRaaLsBPZyYanpXJt r8W7nVZgsivOmlnpdFHiZFqhbVpv+vnemRge2rblvB/gGjD3ysw/Drt99W3ZFG5cjNN2 YsEQ== MIME-Version: 1.0 X-Received: by 10.152.4.72 with SMTP id i8mr3106078lai.32.1431606914641; Thu, 14 May 2015 05:35:14 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 14 May 2015 05:35:14 -0700 (PDT) In-Reply-To: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> References: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 08:35:14 -0400 Message-ID: From: Kathleen Moriarty To: Ben Campbell Content-Type: multipart/alternative; boundary=089e014942489af46a051609f51a Archived-At: Cc: The IESG , "cose@ietf.org" Subject: Re: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 12:37:26 -0000 --089e014942489af46a051609f51a Content-Type: text/plain; charset=UTF-8 Is there a proposal from the COSE list to address Ben's question? I'll be able to update it within the next 30 minutes, or later today. It might be tough to get to an agreed sentence or two in less than 30 though. Thank you, Kathleen On Wed, May 13, 2015 at 10:17 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > charter-ietf-cose-00-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-cose/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Maybe I am missing something, but I don't see an explicit statement of > what COSE is setting out to accomplish until I get to the deliverables. I > can infer it from the group name, and from the JOSE reference. But a > sentence in the first paragraph to the effect that COSE seeks to create > CBOR-based object signing and encryption formats would be helpful. > (Probably right before the JOSE reference). > > > -- Best regards, Kathleen --089e014942489af46a051609f51a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a proposal from the COSE list to address Ben'= s question?=C2=A0 I'll be able to update it within the next 30 minutes,= or later today.=C2=A0 It might be tough to get to an agreed sentence or tw= o in less than 30 though.

Thank you,
Kathleen<= /div>

On Wed= , May 13, 2015 at 10:17 PM, Ben Campbell <ben@nostrum.com> wro= te:
Ben Campbell has entered the followin= g ballot position for
charter-ietf-cose-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-cose/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Maybe I am missing something, but I don't see an explicit statement of<= br> what COSE is setting out to accomplish until I get to the deliverables. I can infer it from the group name, and from the JOSE reference. But a
sentence in the first paragraph to the effect that COSE seeks to create
CBOR-based object signing and encryption formats would be helpful.
(Probably right before the JOSE reference).





--

Best regards,
Kath= leen
--089e014942489af46a051609f51a-- From nobody Thu May 14 06:46:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33051AD357; Thu, 14 May 2015 06:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK8Q27FdnNmI; Thu, 14 May 2015 06:45:55 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C6A1B2A31; Thu, 14 May 2015 06:45:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0B697E2036; Thu, 14 May 2015 09:45:43 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26870-07; Thu, 14 May 2015 09:45:40 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 59F62E2035; Thu, 14 May 2015 09:45:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1431611140; bh=VihmYK69n2IWeAJnpKm60d2dFksZo8kWxv3+mA+T6w0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=mLboNpr+2JYg5t5u51H3ek5L5v4KO60xNOHmZ2dV7PBWFQp1dbZxrBotuqLYpF+sq pwBlH1sDmgmG8trZR2JX6T3ULiHvlvwBL1b+IGDgwmA+LRlyzGgNFlO0oXWNfSQcmM ceEYTTSAy6wVKCmWEujvARkRhaKFPc4IHYqYLXaE= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4EDjdG9019952; Thu, 14 May 2015 09:45:39 -0400 From: Derek Atkins To: Kathleen Moriarty References: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 09:45:39 -0400 In-Reply-To: (Kathleen Moriarty's message of "Thu, 14 May 2015 08:35:14 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Ben Campbell , The IESG , "cose@ietf.org" Subject: Re: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:45:57 -0000 How about: COSE seeks to create CBOR-based object signing and encryption formats. ... placed just before the JOSE reference? :) -derek Kathleen Moriarty writes: > Is there a proposal from the COSE list to address Ben's question?=C2=A0 I= 'll be able > to update it within the next 30 minutes, or later today.=C2=A0 It might b= e tough to > get to an agreed sentence or two in less than 30 though. > > Thank you, > Kathleen > > On Wed, May 13, 2015 at 10:17 PM, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > charter-ietf-cose-00-01: No Objection >=20=20=20=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut th= is > introductory paragraph, however.) > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-cose/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20=20=20=20 > Maybe I am missing something, but I don't see an explicit statement of > what COSE is setting out to accomplish until I get to the deliverable= s. I > can infer it from the group name, and from the JOSE reference. But a > sentence in the first paragraph to the effect that COSE seeks to crea= te > CBOR-based object signing and encryption formats would be helpful. > (Probably right before the JOSE reference). > > -- > > Best regards, > Kathleen > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu May 14 06:58:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0C1B2A5F; Thu, 14 May 2015 06:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRiIshZUWf8k; Thu, 14 May 2015 06:58:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387CC1B2A5C; Thu, 14 May 2015 06:58:15 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4EDw2x2077739 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 08:58:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Derek Atkins" Date: Thu, 14 May 2015 08:58:02 -0500 Message-ID: <5EE0EC5C-651A-403F-927F-66AC97E53B58@nostrum.com> In-Reply-To: References: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Kathleen Moriarty , The IESG , "cose@ietf.org" Subject: Re: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:58:16 -0000 That would work for me :-) On 14 May 2015, at 8:45, Derek Atkins wrote: > How about: > > COSE seeks to create CBOR-based object signing and encryption > formats. > > ... placed just before the JOSE reference? :) > > -derek > > Kathleen Moriarty writes: > >> Is there a proposal from the COSE list to address Ben's question?  >> I'll be able >> to update it within the next 30 minutes, or later today.  It might >> be tough to >> get to an agreed sentence or two in less than 30 though. >> >> Thank you, >> Kathleen >> >> On Wed, May 13, 2015 at 10:17 PM, Ben Campbell >> wrote: >> >> Ben Campbell has entered the following ballot position for >> charter-ietf-cose-00-01: No Objection >> >> When responding, please keep the subject line intact and reply to >> all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-cose/ >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> >> ---------------------------------------------------------------------- >> >> Maybe I am missing something, but I don't see an explicit statement >> of >> what COSE is setting out to accomplish until I get to the >> deliverables. I >> can infer it from the group name, and from the JOSE reference. But a >> sentence in the first paragraph to the effect that COSE seeks to >> create >> CBOR-based object signing and encryption formats would be helpful. >> (Probably right before the JOSE reference). >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu May 14 06:59:54 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0A91AC3B7; Thu, 14 May 2015 06:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G84aLqfyvfOs; Thu, 14 May 2015 06:59:47 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966191AC3EF; Thu, 14 May 2015 06:59:44 -0700 (PDT) Received: by qkgx75 with SMTP id x75so49659434qkg.1; Thu, 14 May 2015 06:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0QbQT0cO7sHFxvEarBk+y9yGwe+ahOH+Aa+QwsC9/WY=; b=NjJFOrY+S5jtqKrrrjKeZvIsD4wYRSpTYhTBjS72wQXRFV8UJzdXmX5LHptxgKV6G0 9kXO7NFgsfMFk1qSh8vLml2NppciXzTEhF8Mbkmy6xiMuxr3ggTisTrRpHfgv1kov0pD k134QhQMFKU8/+wL07gxRs6n9Zbad0iIjw03cbKNf6PNODNybu4pCPhOky4WlkledKWc a0mDI8DtFeMxxEt+u8f6nAf7PVIlmhk67oJoheVF2hVl/LBxT0QMHRdjg2wzgKpEyFPp 4loGaWWUtjuRWYYdOHcpATLZVf3vyjpxrsxTvt1dgGpjwLtekkxodWk79NRwOwE7P1tG nVcA== X-Received: by 10.55.18.139 with SMTP id 11mr9095064qks.5.1431611983886; Thu, 14 May 2015 06:59:43 -0700 (PDT) Received: from [10.7.18.87] (mobile-107-107-60-5.mycingular.net. [107.107.60.5]) by mx.google.com with ESMTPSA id 78sm17836047qht.45.2015.05.14.06.59.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 06:59:42 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <5EE0EC5C-651A-403F-927F-66AC97E53B58@nostrum.com> Date: Thu, 14 May 2015 09:59:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> <5EE0EC5C-651A-403F-927F-66AC97E53B58@nostrum.com> To: Ben Campbell Archived-At: Cc: Derek Atkins , The IESG , "cose@ietf.org" Subject: Re: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:59:49 -0000 Ok, thanks. I'll add it in a little later today. Kathleen=20 Sent from my iPhone > On May 14, 2015, at 9:58 AM, "Ben Campbell" wrote: >=20 > That would work for me :-) >=20 >> On 14 May 2015, at 8:45, Derek Atkins wrote: >>=20 >> How about: >>=20 >> COSE seeks to create CBOR-based object signing and encryption >> formats. >>=20 >> ... placed just before the JOSE reference? :) >>=20 >> -derek >>=20 >> Kathleen Moriarty writes: >>=20 >>> Is there a proposal from the COSE list to address Ben's question? I'll b= e able >>> to update it within the next 30 minutes, or later today. It might be to= ugh to >>> get to an agreed sentence or two in less than 30 though. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> On Wed, May 13, 2015 at 10:17 PM, Ben Campbell wrote: >>>=20 >>> Ben Campbell has entered the following ballot position for >>> charter-ietf-cose-00-01: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-cose/ >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> Maybe I am missing something, but I don't see an explicit statement of >>> what COSE is setting out to accomplish until I get to the deliverables. I= >>> can infer it from the group name, and from the JOSE reference. But a >>> sentence in the first paragraph to the effect that COSE seeks to create >>> CBOR-based object signing and encryption formats would be helpful. >>> (Probably right before the JOSE reference). >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> _______________________________________________ >>> Cose mailing list >>> Cose@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant From nobody Thu May 14 10:57:04 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C354F1B2CD1; Thu, 14 May 2015 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8z7yzPB7yPL; Thu, 14 May 2015 10:56:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91AE1B2CD0; Thu, 14 May 2015 10:56:57 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.160.10; Thu, 14 May 2015 17:56:56 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0160.009; Thu, 14 May 2015 17:56:56 +0000 From: Mike Jones To: Kathleen Moriarty , Ben Campbell Thread-Topic: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) Thread-Index: AQHQjkK+yH/+sVTcu0azVabJCUOZoJ17fB4TgAADWACAAAB5gIAAQiWg Date: Thu, 14 May 2015 17:56:55 +0000 Message-ID: References: <20150514021746.20660.97327.idtracker@ietfa.amsl.com> <5EE0EC5C-651A-403F-927F-66AC97E53B58@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [5.149.172.123] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 3:sEkdhHSSWqVv9QwwZyvSKZdB256Zh2bA6oKIlUITxKmGKRQnm3t3TqDwWH1hwYcPiaA4A1G7SyHXHnbZ6PfOqwejR/+IMeVRHvbhYObfP2OJETARAdSAf/KK+nERpwKPpl6KpPsfTUtXFbTA6FQicg==; 10:QICgrWgy0tVcgPG83EfgGG5WSY3+QOAi0cFbTQLaEc6KPjpZ8unQV+SsmO4WNHvXMAmwh5GiURcDLg5lylDfE5Eq2lwNrU+g+tCB1KwSAGI=; 6:b5DxkpNd+4h74CyULM67aTQNsZ23OgqnleVyIfL6EiJSGcZq2CtC5SFPM2S6Emu6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(51704005)(377454003)(52044002)(77096005)(2656002)(99286002)(230783001)(102836002)(15975445007)(33656002)(86612001)(106116001)(5001960100002)(2900100001)(561944003)(46102003)(66066001)(50986999)(76176999)(54356999)(71446004)(74316001)(189998001)(5001770100001)(92566002)(93886004)(76576001)(122556002)(62966003)(77156002)(2950100001)(40100003)(19580395003)(87936001)(86362001)(19580405001)(15974865002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2015 17:56:55.7073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: Derek Atkins , The IESG , "cose@ietf.org" Subject: Re: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 17:56:59 -0000 s/signing and encryption/signing, encryption, and key representation/ -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Thursday, May 14, 2015 7:00 AM To: Ben Campbell Cc: Derek Atkins; The IESG; cose@ietf.org Subject: Re: [Cose] Ben Campbell's No Objection on charter-ietf-cose-00-01:= (with COMMENT) Ok, thanks. I'll add it in a little later today. Kathleen=20 Sent from my iPhone > On May 14, 2015, at 9:58 AM, "Ben Campbell" wrote: >=20 > That would work for me :-) >=20 >> On 14 May 2015, at 8:45, Derek Atkins wrote: >>=20 >> How about: >>=20 >> COSE seeks to create CBOR-based object signing and encryption=20 >> formats. >>=20 >> ... placed just before the JOSE reference? :) >>=20 >> -derek >>=20 >> Kathleen Moriarty writes: >>=20 >>> Is there a proposal from the COSE list to address Ben's question? =20 >>> I'll be able to update it within the next 30 minutes, or later=20 >>> today. It might be tough to get to an agreed sentence or two in less t= han 30 though. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> On Wed, May 13, 2015 at 10:17 PM, Ben Campbell wrote: >>>=20 >>> Ben Campbell has entered the following ballot position for >>> charter-ietf-cose-00-01: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to=20 >>> all email addresses included in the To and CC lines. (Feel free to=20 >>> cut this introductory paragraph, however.) >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/charter-ietf-cose/ >>>=20 >>> -------------------------------------------------------------------- >>> -- >>> COMMENT: >>> -------------------------------------------------------------------- >>> -- >>>=20 >>> Maybe I am missing something, but I don't see an explicit statement=20 >>> of what COSE is setting out to accomplish until I get to the=20 >>> deliverables. I can infer it from the group name, and from the JOSE=20 >>> reference. But a sentence in the first paragraph to the effect that=20 >>> COSE seeks to create CBOR-based object signing and encryption formats w= ould be helpful. >>> (Probably right before the JOSE reference). >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> _______________________________________________ >>> Cose mailing list >>> Cose@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Sun May 17 18:19:07 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10E61A87C1; Fri, 15 May 2015 10:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTqK45HaNFRO; Fri, 15 May 2015 10:25:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 774A31A87AA; Fri, 15 May 2015 10:25:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 10:25:54 -0700 Archived-At: X-Mailman-Approved-At: Sun, 17 May 2015 18:19:04 -0700 Cc: cose WG Subject: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:25:56 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-05-25. CBOR Object Signing and Encryption (cose) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Kathleen Moriarty Mailing list Address: cose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: http://www.ietf.org/mail-archive/web/cose/ Charter: Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for the serialization of data structured to an extended version of the JSON data model. COSE seeks to create CBOR-based object signing and encryption formats. One motivation for COSE was to reuse functionality from the JOSE working group using the CBOR data representation as it is more amenable to constrained nodes and constrained node networks (RFC 7228). The JOSE working group recently completed producing representations for cryptographic keys, message authentication (MACs), encryption, and digital signatures, using JSON representation. The resulting formats will not be cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit compatibility will enable some simplification in the adaptation process. Criteria that should be considered in the decision making process, changing from JSON to CBOR encoding include: o Maintain the current JOSE paradigms and formatting where feasible. o Minimize message size, code size, and computational complexity to suit constrained environments, where this is expected to be used. o Improve security o Provide new functionality for additional use cases that were not required for JOSE. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs or active IETF WG documents. The working group will coordinate its progress with the ACE, DICE and CORE working groups to ensure that we are fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded. The WG will have two deliverables: 1. A standards-track specification covering the same cryptographic formats from JOSE, with optimizations for constrained device processing, expressed in CBOR; 2. Registration for algorithms (such as AES-CCM-8) that are appropriate for constrained environments. The Working Group will use a wiki to track desired use cases for its work, but does not intend to publish this as an RFC. Milestones: Jun 2015 - Submit COSE specification as a WG item Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item Jan 2016 - Submit COSE specification to the IESG, for publication as a Proposed Standard Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG, for publication as a Proposed Standard From nobody Sun May 17 18:19:08 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D96D1A8838 for ; Fri, 15 May 2015 10:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c9X1C-kM7ag for ; Fri, 15 May 2015 10:29:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AC41A883B for ; Fri, 15 May 2015 10:29:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515172908.31879.26277.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 10:29:08 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sun, 17 May 2015 18:19:04 -0700 Subject: [Cose] State changed: charter-ietf-cose-00-02 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:29:10 -0000 State changed to External review. URL: https://datatracker.ietf.org/doc/charter-ietf-cose/ From nobody Sun May 17 18:19:09 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2B81A883B; Fri, 15 May 2015 10:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGbbS8VcPYog; Fri, 15 May 2015 10:29:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 319641A8838; Fri, 15 May 2015 10:29:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515172943.30632.12549.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 10:29:43 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Sun, 17 May 2015 18:19:04 -0700 Subject: [Cose] Telechat update notice: X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:29:44 -0000 Telechat date has been changed to 2015-05-28 from 2015-05-14 ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-cose/ From nobody Mon May 18 09:49:17 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AEC1AD0D0 for ; Mon, 18 May 2015 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fxrXgJ6FNXR for ; Mon, 18 May 2015 09:49:13 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72F21AD0B2 for ; Mon, 18 May 2015 09:49:12 -0700 (PDT) Received: from HoldOver (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C74222C9F4; Mon, 18 May 2015 09:49:11 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" , "'Mike Jones'" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> In-Reply-To: Date: Mon, 18 May 2015 09:49:16 -0700 Message-ID: <010601d0918a$941ce3a0$bc56aae0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHbZlBKHCCSWnQMz2VzSyrGcf61KQDaoPGQAgu3YXUBfWV+bAJ/Bf9GAoiqjqsCclhIcp0NWBgQ Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:49:15 -0000 -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Tuesday, May 12, 2015 11:16 AM To: Mike Jones Cc: Jim Schaad; 'Derek Atkins'; cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients Mike Jones writes: > What was presented to the JOSE working group in Denver by Richard Barnes was the option of representing encrypted keys as encrypted JWK structures, rather than just encrypted bare keys. The choice is between encrypting: > {"kty":"oct", > "alg":"A128KW", > "k":"GawgguFyGrWKav7AX4VKUg"} > or simply the bytes that "k" represents in base64url encoded form. Encrypting just the bytes is smaller, and contains no redundant information that will simply be discarded. Is it necesarily redundant? What says that the key being encrypted (wrapped) is of the exact same algorithm/size/mode as the method being used to encrypt/wrap it? E.g., I can certainly posit a situation where I am encrypting an AES-128-CCM key with an AES-256-GCM key (Or even more, I could see encrypting a 3DES key with AES). In this case the extra information is definitely not redundant, and is certainly not derivable just from 'k'. I guess my question to you (not being as intimately familiar with JWKs) is whether the algorithm of the wrapped (encrypted) key is exposed somewhere outside the wrapping? [JLS] This depends on if you are carrying a key just as a content, or if you are carrying a key for use in the next layer down (i.e. as a recipient structure). In the first case, no there is no data and a JWK structure as the content would be necessary. In the latter case, the key type is known because it is advertised in the next layer down. Jim > That's why the JOSE working group rejected using encrypted JWKs as the encrypted_key representation. If the "encrypt structure" you're referring to is different than this, it would probably be good to explain what it is, how you're proposing to reuse it, and why reusing it doesn't add extraneous unused information, as Richard's proposal in Denver did. ... > -- Mike -derek > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Monday, May 11, 2015 11:47 PM > To: Mike Jones; 'Derek Atkins' > Cc: cose@ietf.org > Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients > > I don't understand what you are arguing for or against. > > Are you saying don't do the reuse of the structure? > Are you saying don't do the extra tagging of encrypted key vs encrypted content? > Are you saying something completely different? > > jim > >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Monday, May 11, 2015 3:25 PM >> To: Jim Schaad; 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients >> >> From my point of view, the JOSE WG didn't reject encrypting a JWK to >> represent the encrypted key because it was a change. The working >> group rejected it because there was no need to carry any data that >> would remain unused about the encrypted key, when just the the >> encrypted key value > itself >> would do. Particularly in a space-constrained environment, carrying >> extra metadata about a key that will only be discarded seems wasteful >> in the extreme. >> >> I would advocate having the encrypted_key value remain only an >> encrypted form of the CEK value, adding nothing extra. >> >> - Mike >> >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Monday, May 11, 2015 10:42 PM >> To: 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >> >> At the present time, that information can easily be inferred by context. > In the >> event that we want to talk about use the "recipient" structure as a >> top > level >> object then I think this question would need to be revisited. >> >> Jim >> >> >> > -----Original Message----- >> > From: Derek Atkins [mailto:derek@ihtfp.com] >> > Sent: Monday, May 11, 2015 8:23 AM >> > To: Jim Schaad >> > Cc: cose@ietf.org >> > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for >> > recipients >> > >> > I believe that yes, the map should be reused, however if we do that >> > I wonder whether you need to add a tag that says whether it's an >> > encrypted key or encrypted 'data'? >> > >> > -derek >> > >> > "Jim Schaad" writes: >> > >> > > Question: Reuse Encrypt body map for recipients >> > > >> > > Discussion: >> > > >> > > The concept of using the same structure for both recipients and >> > > the base encryption map was introduced to the JOSE working group >> > > at the Denver meeting. The JOSE working group rejected the idea >> > > as being too much of a change to make in the current working code. >> > > The concept is that the same data structure, with the same >> > > elements is used to encode both the content encryption and each >> > > of the recipient >> structures. >> > > While in JOSE, many of the same elements are not present in the >> > > recipient structure (i.e. iv and aad), some of these elements >> > > later appeared as part of algorithm descriptions (iv is a header >> > > parameter >> > defined for AES-GCM key wrapping). >> > > >> > > Using the same structure for encrypting content as well as >> > > encrypting keys allows for some neat tricks to be played at a >> > > later date if needed. One example is that you could separate the >> > > key wrapping algorithm, and the ECDH-KDF algorithm pair into >> > > separate layers. This allows one to move towards a Chinese Menu >> > > method of selecting and using algorithms rather than the current >> > > algorithm suite >> method. >> > > While I would not recommend that this happen in the current >> > > specification, it might be nice to keep it open as an option to >> > > be used >> in the >> > future as new algorithms are added. >> > > >> > > Another advantage of doing this folding is in code size. In my >> > > implementation, I have created the recipient class as inheriting >> > > from the encryption body class. The recipient class contains >> > > only code that deals with the cryptography of key management. >> > > All of the >> > encoding/decoding is >> > > handled by the base encryption class. If the structures are kept >> separate >> > > as they are today then that code would need to be added to the >> > > recipient class. While my code does not currently deal with idea >> > > of having multiple layers of key management. I believe that this >> > > would be a minimal addition to the current code base. >> > > >> > > >> > > _______________________________________________ >> > > Cose mailing list >> > > Cose@ietf.org >> > > https://www.ietf.org/mailman/listinfo/cose >> > > >> > > >> > >> > -- >> > Derek Atkins 617-623-3745 >> > derek@ihtfp.com www.ihtfp.com >> > Computer and Internet Security Consultant >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 18 09:59:06 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DEC1AD2F6 for ; Mon, 18 May 2015 09:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DtU43N_CzV4 for ; Mon, 18 May 2015 09:59:03 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1591AD1FE for ; Mon, 18 May 2015 09:59:03 -0700 (PDT) Received: from HoldOver (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 328AD38EFA for ; Mon, 18 May 2015 09:59:03 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 18 May 2015 09:59:07 -0700 Message-ID: <010701d0918b$f47d2bf0$dd7783d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01D09151.4824BC90" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCRi1xq+pygzAAzTiiOaC6bV19bYw== Content-Language: en-us Archived-At: Subject: [Cose] Recap: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:59:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0108_01D09151.4824BC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Question: Flattened encoding - > > a) Roll into parent map > > b) Just be a map > > c) Single element in array > Based on the messages, there seems to be no support for combining the two maps together into a single map. I have therefore removed that from my working copy of the draft. There was one request for allowing option b (where a single recipient can be represented as a single map entry rather than as an array of a single map). I have looked at code size, and there does not seem to be a lot of code associated with this option, but as there was no outcry for this option I have not included it. Unless others have opinions that they believe need to be expressed, I am closing this issue. ------=_NextPart_000_0108_01D09151.4824BC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> > Question: Flattened encoding = -

> > a)  Roll into = parent map

> > b)  Just = be a map

> > c)  Single = element in array

> =

 

 

Based on the = messages, there seems to be no support for combining the two maps = together into a single map.  I have therefore removed that from my = working copy of the draft.

 

There was = one request for allowing option b (where a single recipient can be = represented as a single map entry rather than as an array of a single = map).  I have looked at code size, and there does not seem to be a = lot of code associated with this option, but as there was no outcry for = this option I have not included it.

 

Unless = others have opinions that they believe need to be expressed, I am = closing this issue.

 

------=_NextPart_000_0108_01D09151.4824BC90-- From nobody Mon May 18 10:02:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6481A1BE5 for ; Mon, 18 May 2015 10:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2RywN4N-I5E for ; Mon, 18 May 2015 10:02:33 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EFE1ACDD9 for ; Mon, 18 May 2015 10:02:08 -0700 (PDT) Received: from HoldOver (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9CDEA38EF6 for ; Mon, 18 May 2015 10:02:07 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 18 May 2015 10:02:12 -0700 Message-ID: <010c01d0918c$626acdc0$27406940$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCRjASmOnaUEr4xSpeEwA6E4TiQMg== Content-Language: en-us Archived-At: Subject: [Cose] Recap: Reuse the Encrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 17:02:34 -0000 Question: Reuse Encrypt body map for recipients I saw no one saying that we should not reuse the same structure for encrypting both the main content and the recipient structures. The only comment that I saw that was even potentially not supportive was just a request from Mike that we not encrypt a JWK structure but just encrypt the key in this case. This is already the approach of my draft so this involves no changes in my working draft. Jim From nobody Mon May 18 10:15:53 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D052F1A1A3D for ; Mon, 18 May 2015 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9ahohO72n1z for ; Mon, 18 May 2015 10:15:51 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D74B1A03A6 for ; Mon, 18 May 2015 10:15:51 -0700 (PDT) Received: from HoldOver (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id C7E3238EF6 for ; Mon, 18 May 2015 10:15:50 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 18 May 2015 10:15:54 -0700 Message-ID: <012501d0918e$4d0f0d40$e72d27c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCRjIL6Rotw5ewfS8qNYqLRvEM3HQ== Content-Language: en-us Archived-At: Subject: [Cose] Recap: Identification of the top level objects X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 17:15:53 -0000 Question: Identification of objects: a) CBOR Tag - either general or specific to each type b) Required Identifier c) Use the same techniques as JOSE There was no support for option C. There was support for Option B There was some support for Option A, but only if it was optional. Mike Jones suggested that we should use the header parameter 'typ', I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the JWS document. At this point I will keep the field as mandatory and outside of the headers field. I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text. Jim From nobody Mon May 18 14:05:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C76C1A1A6E for ; Mon, 18 May 2015 14:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM_oBMNiIYTq for ; Mon, 18 May 2015 14:05:37 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CCA1A1A46 for ; Mon, 18 May 2015 14:05:37 -0700 (PDT) Received: from HoldOver (c-24-20-67-136.hsd1.or.comcast.net [24.20.67.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 74A852CA22 for ; Mon, 18 May 2015 14:05:36 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 18 May 2015 14:05:42 -0700 Message-ID: <016501d091ae$67909510$36b1bf30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCRq9rt20WbovolQKm1OfRYV6+NBg== Content-Language: en-us Archived-At: Subject: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:05:39 -0000 Questions: 1. Should we use integers only, integers and strings or strings only for indexing of maps? 2. Should we build one or more tables of values that allow for integers to be used rather than strings? 3. How many/what registries should be created or modified to indicate the use of integer values and keys? Discussion: There has been a general assumption that we are going to use integer values for keying of maps within COSE. However there is an interesting question, do we only use integer values or do we allow strings as well? Allowing for strings allows for easier creating of local keys and keys for testing purposes than restricting the type to just integers. However it might be easier to go through the keys if strings are not allowed. My presumption has been that both are going to be allowed. There is an interesting question of what registry tables we are going to create to hold the keys and values in. I believe that the following locations of integer values exist that need to be assigned to tables. If you feel this list is incomplete then say so: 1. Keys in top level maps. 2. Keys associated with protected and unprotected header fields 3. Values associated with top level keys 4. Values associated with the various protected and unprotected header keys. It is probably that we need to enumerate the list of all of the header keys and make a determination if we have a unique value table for that key or if we are going to use a common table for that key. As an example, it makes sense that there would be a unique table that holds all of the algorithm names in it. However, if one looks at the curve names for EC, these names could be placed in the algorithm name table, a separate curve table or in a common table that is used for generic purposes. Another question is what document should the different tables be created or updated in. It makes sense that this document could update the algorithm table. However, that could also be done in the algorithm document that the group is expected to create as well. There has been a desire expressed to update the mime-type table to have a column of integer values associated with it. This makes life much more fun as it is not clear that we want to have a document do this, but rather just a document that is going to have a procedure for doing so. Such a proceeding would require some thought if the one and two byte values are to be reserved for more commonly used mime types. Finally, are the values just positive integers or both positive and negative integers. Do we have reserved spaces for private usage in all of the tables and, for new tables, what are the rules for updating the table. This issue is somewhat open ended and some of the questions will more likely be addressed as the procedure goes along and we start writing text for the decisions that we are making. Jim From nobody Mon May 18 14:29:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEED01A6F27 for ; Mon, 18 May 2015 14:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPCeATRUmPJY for ; Mon, 18 May 2015 14:28:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E22E1ACD15 for ; Mon, 18 May 2015 14:28:58 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.172.17; Mon, 18 May 2015 21:28:40 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0172.012; Mon, 18 May 2015 21:28:40 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] ISSUE: Use of integer rather than string tags Thread-Index: AdCRq9rt20WbovolQKm1OfRYV6+NBgABX/HA Date: Mon, 18 May 2015 21:28:39 +0000 Message-ID: References: <016501d091ae$67909510$36b1bf30$@augustcellars.com> In-Reply-To: <016501d091ae$67909510$36b1bf30$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [66.194.79.10] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 3:0smqGP3i9cGw1uz/O93u7vL7lKHe+BOxdnsd4I+JBeLhMt8sRmXW7KVq0+SmIytEj3TRCGpt0yQ3X+f0rHX/nSZlr+IkGRS5D4H5HCndDsB+sm7fx1AGBY+ckvvd0j7l2hKFDzQCMZGBROtCfxoOow==; 10:aGHcedAbKbWd0qBXmNg+iarXQ7NLE7ZADAbKCWhWopFJrdOEuaTR+exv7dGfZgJZ3CUSb6vkfJdh51Dj6pFbGb1tzQRKXnz0wGc1v52Mogg=; 6:5VVhd7IUDInxX06MPh40pBZqKdmWqzqQCoszOfnwjwNh3Bdipt1kr0kAVzT5+3SA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(13464003)(122556002)(189998001)(40100003)(15975445007)(102836002)(64706001)(86612001)(105586002)(4001540100001)(81156007)(92566002)(33656002)(97736004)(68736005)(77096005)(106356001)(66066001)(77156002)(62966003)(99286002)(19580405001)(19580395003)(46102003)(74316001)(87936001)(5001960100002)(76576001)(50986999)(107886002)(101416001)(2900100001)(76176999)(86362001)(54356999)(2501003)(2656002)(5001860100001)(2950100001)(5001770100001)(5001920100001)(5001830100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 21:28:39.8987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:29:01 -0000 Support both. Lots of applications will have locally keys and using string= s gives them an easy way to use collision-resistant names for these keys, r= ather than having to register everything - even keys that will never be mea= ningful outside the application - with IANA in order to avoid collisions. = Letting people use strings will thereby help us conserve a scarce resource = - the short integer namespace. -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, May 18, 2015 2:06 PM To: cose@ietf.org Subject: [Cose] ISSUE: Use of integer rather than string tags Questions: 1. Should we use integers only, integers and strings or strings only for i= ndexing of maps? 2. Should we build one or more tables of values that allow for integers to= be used rather than strings? 3. How many/what registries should be created or modified to indicate the = use of integer values and keys? Discussion: There has been a general assumption that we are going to use integer values= for keying of maps within COSE. However there is an interesting question,= do we only use integer values or do we allow strings as well? Allowing fo= r strings allows for easier creating of local keys and keys for testing pur= poses than restricting the type to just integers. However it might be easi= er to go through the keys if strings are not allowed. My presumption has b= een that both are going to be allowed. There is an interesting question of what registry tables we are going to cr= eate to hold the keys and values in. I believe that the following location= s of integer values exist that need to be assigned to tables. If you feel = this list is incomplete then say so: 1. Keys in top level maps. 2. Keys associated with protected and unprotected header fields 3. Values= associated with top level keys 4. Values associated with the various prot= ected and unprotected header keys. It is probably that we need to enumerate the list of all of the header keys= and make a determination if we have a unique value table for that key or i= f we are going to use a common table for that key. As an example, it makes sense that there would be a unique table that holds all of the algorithm na= mes in it. However, if one looks at the curve names for EC, these names co= uld be placed in the algorithm name table, a separate curve table or in a c= ommon table that is used for generic purposes.=20 Another question is what document should the different tables be created or= updated in. It makes sense that this document could update the algorithm = table. However, that could also be done in the algorithm document that the= group is expected to create as well. There has been a desire expressed to= update the mime-type table to have a column of integer values associated w= ith it. This makes life much more fun as it is not clear that we want to h= ave a document do this, but rather just a document that is going to have a procedure for doing so. Such a proceeding would require some thought if the one and two byte values are to be reserved for more commonly used mime = types. Finally, are the values just positive integers or both positive and negativ= e integers. Do we have reserved spaces for private usage in all of the tab= les and, for new tables, what are the rules for updating the table. This issue is somewhat open ended and some of the questions will more likel= y be addressed as the procedure goes along and we start writing text for th= e decisions that we are making. Jim _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Wed May 20 11:12:56 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CF01A8A43 for ; Wed, 20 May 2015 11:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOhAbMjWkO7Q for ; Wed, 20 May 2015 11:12:50 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C969E1A8A52 for ; Wed, 20 May 2015 11:12:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3DC94E2036; Wed, 20 May 2015 14:12:45 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12652-01; Wed, 20 May 2015 14:12:43 -0400 (EDT) Received: from securerf.ihtfp.org (c-50-189-135-154.hsd1.ct.comcast.net [50.189.135.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C6B6AE2035; Wed, 20 May 2015 14:12:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432145562; bh=SmI4bYCv9lFqtfcOKQDxsrduhA6xSEPPnwqnRDI1H8g=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Jntectrs21kD7/D44kAol/uzhN9YBCjig55U83MJzi3kfAftlYT5SbcvKhwu+k048 RB+bSBCLY/Jm6AVluS3l4KkFiGviHLeV0CbIqvPSL1636apy0m/oU2mYK6/GJYtgZs L0Wn3qIiv3tgzq7/iBc/DosZ6YcJcE9C5oXw3x8A= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4KICZVo014592; Wed, 20 May 2015 14:12:35 -0400 From: Derek Atkins To: "Jim Schaad" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> <010601d0918a$941ce3a0$bc56aae0$@augustcellars.com> Date: Wed, 20 May 2015 14:12:35 -0400 In-Reply-To: <010601d0918a$941ce3a0$bc56aae0$@augustcellars.com> (Jim Schaad's message of "Mon, 18 May 2015 09:49:16 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: 'Mike Jones' , cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:12:52 -0000 "Jim Schaad" writes: > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Tuesday, May 12, 2015 11:16 AM > To: Mike Jones > Cc: Jim Schaad; 'Derek Atkins'; cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > Mike Jones writes: > >> What was presented to the JOSE working group in Denver by Richard Barnes > was the option of representing encrypted keys as encrypted JWK structures, > rather than just encrypted bare keys. The choice is between encrypting: >> {"kty":"oct", >> "alg":"A128KW", >> "k":"GawgguFyGrWKav7AX4VKUg"} >> or simply the bytes that "k" represents in base64url encoded form. > Encrypting just the bytes is smaller, and contains no redundant information > that will simply be discarded. > > Is it necesarily redundant? What says that the key being encrypted > (wrapped) is of the exact same algorithm/size/mode as the method being used > to encrypt/wrap it? > > E.g., I can certainly posit a situation where I am encrypting an AES-128-CCM > key with an AES-256-GCM key (Or even more, I could see encrypting a 3DES key > with AES). In this case the extra information is definitely not redundant, > and is certainly not derivable just from 'k'. > > I guess my question to you (not being as intimately familiar with JWKs) is > whether the algorithm of the wrapped (encrypted) key is exposed somewhere > outside the wrapping? > > [JLS] This depends on if you are carrying a key just as a content, or if > you are carrying a key for use in the next layer down (i.e. as a recipient > structure). In the first case, no there is no data and a JWK structure as > the content would be necessary. In the latter case, the key type is known > because it is advertised in the next layer down. This says to me that there are use-cases where the extra data is not redundant, so it should be possible to put it in there. > Jim -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed May 20 11:25:27 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C291A8A62 for ; Wed, 20 May 2015 11:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-QEINcbkKUW for ; Wed, 20 May 2015 11:25:23 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA981A8A55 for ; Wed, 20 May 2015 11:25:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 23F92E2036; Wed, 20 May 2015 14:25:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12652-02; Wed, 20 May 2015 14:25:18 -0400 (EDT) Received: from securerf.ihtfp.org (c-50-189-135-154.hsd1.ct.comcast.net [50.189.135.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id CC645E2035; Wed, 20 May 2015 14:25:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432146318; bh=CiCu/i+HL+sDwSNKJW3XAts5lKexsp3ahNi5cNKSvbc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=NkdqM9wcX6wT8Q35+i2MZrWkbW/xPfuRsLSeXeCE0HeqdZLWhQY76cn0js1a5CTVY ukw2qASuH6Td11VyoUcUvYRvkGqgwaZ4q7VLsiSx0nwlbKnr3cFWFALT2y+4sxRB/Z R1anKi6HWRgN9eREdOMzzDxh/Sj1MWVkLOs6sb0E= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4KIPGbw014748; Wed, 20 May 2015 14:25:16 -0400 From: Derek Atkins To: "Jim Schaad" References: <016501d091ae$67909510$36b1bf30$@augustcellars.com> Date: Wed, 20 May 2015 14:25:16 -0400 In-Reply-To: <016501d091ae$67909510$36b1bf30$@augustcellars.com> (Jim Schaad's message of "Mon, 18 May 2015 14:05:42 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 18:25:26 -0000 Hi Jim, "Jim Schaad" writes: > Questions: > 1. Should we use integers only, integers and strings or strings only for > indexing of maps? We should allow both integers and strings. > 2. Should we build one or more tables of values that allow for integers to > be used rather than strings? Yes. > 3. How many/what registries should be created or modified to indicate the > use of integer values and keys? We probably need "separate" registries for known keys/values in each of the maps we create. > Discussion: > > There has been a general assumption that we are going to use integer values > for keying of maps within COSE. However there is an interesting question, > do we only use integer values or do we allow strings as well? Allowing for > strings allows for easier creating of local keys and keys for testing > purposes than restricting the type to just integers. However it might be > easier to go through the keys if strings are not allowed. My presumption > has been that both are going to be allowed. > > There is an interesting question of what registry tables we are going to > create to hold the keys and values in. I believe that the following > locations of integer values exist that need to be assigned to tables. If > you feel this list is incomplete then say so: > > 1. Keys in top level maps. > 2. Keys associated with protected and unprotected header fields > 3. Values associated with top level keys > 4. Values associated with the various protected and unprotected header > keys. > > It is probably that we need to enumerate the list of all of the header keys > and make a determination if we have a unique value table for that key or if > we are going to use a common table for that key. As an example, it makes > sense that there would be a unique table that holds all of the algorithm > names in it. However, if one looks at the curve names for EC, these names > could be placed in the algorithm name table, a separate curve table or in a > common table that is used for generic purposes. It depends whether we want to have to say something like: alg => {ec_sha2 => p256} instead of alg => es256 Similar for AES. Do we need one registry with 'aes' and another with known "key sizes" (128, 256), or just two algorithm entries, aes128 and aes256? I would argue that it's "easier" to just have a single algorithm registry where "cipher-family" and "parameter" are combined. This does mean if we choose to include a dozen different ECC curves then we'd need a dozen entries in this table. Note also that I say this as a purveyor of a crypto algorithm where even just saying the parameter level (eg 2^128 level security) is not sufficient to nail down the actual parameters to use, as there are an infinite number of potential parameters at every security level. But like everyone else I would need to nail down parameter sets. > Another question is what document should the different tables be created or > updated in. It makes sense that this document could update the algorithm > table. However, that could also be done in the algorithm document that the > group is expected to create as well. There has been a desire expressed to > update the mime-type table to have a column of integer values associated > with it. This makes life much more fun as it is not clear that we want to > have a document do this, but rather just a document that is going to have a > procedure for doing so. Such a proceeding would require some thought if > the one and two byte values are to be reserved for more commonly used mime > types. I'm fine with this all being defined in a single COSE spec document. I don't feel we need to break it apart into multiple documents like JOSE did. Indeed, I would argue that a single cohesive document is easier to follow than what JOSE did. > Finally, are the values just positive integers or both positive and negative > integers. Do we have reserved spaces for private usage in all of the tables > and, for new tables, what are the rules for updating the table. For cleverness I think we can use both positives and negatives. We should reserve all 1-byte-resulting numbers. We should have some reserved spaces for private usage. As for the rules, I think the single-byte numbers should be Standard Required and the multi-byte numbers can be Expert Review. > This issue is somewhat open ended and some of the questions will more likely > be addressed as the procedure goes along and we start writing text for the > decisions that we are making. :) > Jim -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed May 20 12:29:04 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A991A8AC3 for ; Wed, 20 May 2015 12:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlUvc8MDy2fC for ; Wed, 20 May 2015 12:29:01 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F46A1A8BB7 for ; Wed, 20 May 2015 12:29:01 -0700 (PDT) Received: from HoldOver (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 067302CA0B; Wed, 20 May 2015 12:29:00 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <016501d091ae$67909510$36b1bf30$@augustcellars.com> In-Reply-To: Date: Wed, 20 May 2015 12:29:10 -0700 Message-ID: <000701d09333$3fa641e0$bef2c5a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE1tZrJJMzJio9nPTRuR95tavrVZQLhK4A2nqPwMSA= Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:29:03 -0000 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Wednesday, May 20, 2015 11:25 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [Cose] ISSUE: Use of integer rather than string tags > > Hi Jim, > > "Jim Schaad" writes: > > > Questions: > > 1. Should we use integers only, integers and strings or strings only > > for indexing of maps? > > We should allow both integers and strings. > > > 2. Should we build one or more tables of values that allow for > > integers to be used rather than strings? > > Yes. > > > 3. How many/what registries should be created or modified to indicate > > the use of integer values and keys? > > We probably need "separate" registries for known keys/values in each of the > maps we create. > > > Discussion: > > > > There has been a general assumption that we are going to use integer > > values for keying of maps within COSE. However there is an > > interesting question, do we only use integer values or do we allow > > strings as well? Allowing for strings allows for easier creating of > > local keys and keys for testing purposes than restricting the type to > > just integers. However it might be easier to go through the keys if > > strings are not allowed. My presumption has been that both are going to be > allowed. > > > > There is an interesting question of what registry tables we are going > > to create to hold the keys and values in. I believe that the > > following locations of integer values exist that need to be assigned > > to tables. If you feel this list is incomplete then say so: > > > > 1. Keys in top level maps. > > 2. Keys associated with protected and unprotected header fields 3. > > Values associated with top level keys 4. Values associated with the > > various protected and unprotected header keys. > > > > It is probably that we need to enumerate the list of all of the header > > keys and make a determination if we have a unique value table for that key > or if > > we are going to use a common table for that key. As an example, it makes > > sense that there would be a unique table that holds all of the > > algorithm names in it. However, if one looks at the curve names for > > EC, these names could be placed in the algorithm name table, a > > separate curve table or in a common table that is used for generic purposes. > > It depends whether we want to have to say something like: > > alg => {ec_sha2 => p256} instead of alg => es256 My assumption has been that we are going to use a similar naming scheme to that followed by JOSE. alg=> ec_sha2 - but the curve is defined in the key used. Thus ec_sha2 can be used for any of the NIST curves and any other curve that follows the same point convention. This means that we are going to get two versions of ECDH - one for the current {x,y} points and a new one for the {x} only points. In terms of doing something like ECHD - there are a number of other items that are defined in the algorithm id, i.e. not Chinese menu, that will lead to some proliferation of algorithms. But not as badly as TLS where a complete set of all algorithms are combined in a single suite value. Jim > > Similar for AES. Do we need one registry with 'aes' and another with known > "key sizes" (128, 256), or just two algorithm entries, aes128 and aes256? I > would argue that it's "easier" to just have a single algorithm registry where > "cipher-family" and "parameter" are combined. > > This does mean if we choose to include a dozen different ECC curves then we'd > need a dozen entries in this table. > > Note also that I say this as a purveyor of a crypto algorithm where even just > saying the parameter level (eg 2^128 level security) is not sufficient to nailsimi > down the actual parameters to use, as there are an infinite number of potential > parameters at every security level. But like everyone else I would need to nail > down parameter sets. > > > Another question is what document should the different tables be > > created or updated in. It makes sense that this document could update > > the algorithm table. However, that could also be done in the > > algorithm document that the group is expected to create as well. > > There has been a desire expressed to update the mime-type table to > > have a column of integer values associated with it. This makes life > > much more fun as it is not clear that we want to have a document do this, but > rather just a document that is going to have a > > procedure for doing so. Such a proceeding would require some thought if > > the one and two byte values are to be reserved for more commonly used > > mime types. > > I'm fine with this all being defined in a single COSE spec document. I don't feel > we need to break it apart into multiple documents like JOSE did. Indeed, I > would argue that a single cohesive document is easier to follow than what JOSE > did. > > > Finally, are the values just positive integers or both positive and > > negative integers. Do we have reserved spaces for private usage in > > all of the tables and, for new tables, what are the rules for updating the table. > > For cleverness I think we can use both positives and negatives. We should > reserve all 1-byte-resulting numbers. We should have some reserved spaces > for private usage. As for the rules, I think the single-byte numbers should be > Standard Required and the multi-byte numbers can be Expert Review. > > > This issue is somewhat open ended and some of the questions will more > > likely be addressed as the procedure goes along and we start writing > > text for the decisions that we are making. > > :) > > > Jim > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Wed May 20 12:30:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CCA1A8F43 for ; Wed, 20 May 2015 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le93K_wEGic0 for ; Wed, 20 May 2015 12:30:19 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F201F1A8F42 for ; Wed, 20 May 2015 12:30:18 -0700 (PDT) Received: from HoldOver (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2CC752CA00; Wed, 20 May 2015 12:30:18 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> <010601d0918a$941ce3a0$bc56aae0$@augustcellars.com> In-Reply-To: Date: Wed, 20 May 2015 12:30:27 -0700 Message-ID: <000801d09333$6da9e3d0$48fdab70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHbZlBKHCCSWnQMz2VzSyrGcf61KQDaoPGQAgu3YXUBfWV+bAJ/Bf9GAoiqjqsCclhIcgG8rBW0AdAIfPSc9EZFoA== Content-Language: en-us Archived-At: Cc: 'Mike Jones' , cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:30:20 -0000 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Wednesday, May 20, 2015 11:13 AM > To: Jim Schaad > Cc: 'Mike Jones'; cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > "Jim Schaad" writes: > > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Tuesday, May 12, 2015 11:16 AM > > To: Mike Jones > > Cc: Jim Schaad; 'Derek Atkins'; cose@ietf.org > > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > > > Mike Jones writes: > > > >> What was presented to the JOSE working group in Denver by Richard > >> Barnes > > was the option of representing encrypted keys as encrypted JWK > > structures, rather than just encrypted bare keys. The choice is between > encrypting: > >> {"kty":"oct", > >> "alg":"A128KW", > >> "k":"GawgguFyGrWKav7AX4VKUg"} > >> or simply the bytes that "k" represents in base64url encoded form. > > Encrypting just the bytes is smaller, and contains no redundant > > information that will simply be discarded. > > > > Is it necesarily redundant? What says that the key being encrypted > > (wrapped) is of the exact same algorithm/size/mode as the method being > > used to encrypt/wrap it? > > > > E.g., I can certainly posit a situation where I am encrypting an > > AES-128-CCM key with an AES-256-GCM key (Or even more, I could see > > encrypting a 3DES key with AES). In this case the extra information > > is definitely not redundant, and is certainly not derivable just from 'k'. > > > > I guess my question to you (not being as intimately familiar with > > JWKs) is whether the algorithm of the wrapped (encrypted) key is > > exposed somewhere outside the wrapping? > > > > [JLS] This depends on if you are carrying a key just as a content, or > > if you are carrying a key for use in the next layer down (i.e. as a > > recipient structure). In the first case, no there is no data and a > > JWK structure as the content would be necessary. In the latter case, > > the key type is known because it is advertised in the next layer down. > > This says to me that there are use-cases where the extra data is not redundant, > so it should be possible to put it in there. Not redundant in the first case or in the second case? Jim > > > Jim > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Fri May 22 08:32:56 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9331A01F4 for ; Fri, 22 May 2015 08:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODRhljs7OPEI for ; Fri, 22 May 2015 08:32:53 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF741A026E for ; Fri, 22 May 2015 08:32:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1603AE2036; Fri, 22 May 2015 11:32:31 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28626-07; Fri, 22 May 2015 11:32:30 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 3FF68E2035; Fri, 22 May 2015 11:32:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432308750; bh=DmT8CPUgN83+IV0TbJXuwnj4PRtj4mWGLjdo+o0Onig=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=al0sbEJn04qaitRJrNLr99SZlI9aoj2P9jmAfpKojZ9S8odvyHVDhOIQ2G+xheUho vrENkLNerlxdyVQJfcTFwZAizxdDCAkvIEgtwILHeLOktDhLNzBMKBht0jarszdKyX rctt7K06oBGg1XfHZVwjKYuoJSUtUAZp9nhgtPcY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4MFWTlG012545; Fri, 22 May 2015 11:32:29 -0400 From: Derek Atkins To: "Jim Schaad" References: <016501d091ae$67909510$36b1bf30$@augustcellars.com> <000701d09333$3fa641e0$bef2c5a0$@augustcellars.com> Date: Fri, 22 May 2015 11:32:29 -0400 In-Reply-To: <000701d09333$3fa641e0$bef2c5a0$@augustcellars.com> (Jim Schaad's message of "Wed, 20 May 2015 12:29:10 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: 'Derek Atkins' , cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:32:55 -0000 "Jim Schaad" writes: >> It depends whether we want to have to say something like: >> >> alg => {ec_sha2 => p256} instead of alg => es256 > > My assumption has been that we are going to use a similar naming scheme to > that followed by JOSE. > > alg=> ec_sha2 - but the curve is defined in the key used. Thus ec_sha2 can > be used for any of the NIST curves and any other curve that follows the same > point convention. > > This means that we are going to get two versions of ECDH - one for the > current {x,y} points and a new one for the {x} only points. > > In terms of doing something like ECHD - there are a number of other items > that are defined in the algorithm id, i.e. not Chinese menu, that will lead > to some proliferation of algorithms. But not as badly as TLS where a > complete set of all algorithms are combined in a single suite value. I am fine with this approach (although I thought JOSE combined the EC with the Signature and Key Size, e.g. { alg: ES256 }? > Jim -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri May 22 12:01:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0001D1A19E4; Fri, 22 May 2015 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwz6yDJfA161; Fri, 22 May 2015 12:01:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04A01A07BC; Fri, 22 May 2015 12:01:40 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.172.17; Fri, 22 May 2015 19:01:38 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0172.012; Fri, 22 May 2015 19:01:38 +0000 From: Mike Jones To: The IESG , IETF-Announce Thread-Topic: [Cose] WG Review: CBOR Object Signing and Encryption (cose) Thread-Index: AQHQkQikDPNsZ9VDmkWEn+79NegWnp2IYAkQ Date: Fri, 22 May 2015 19:01:38 +0000 Message-ID: References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> In-Reply-To: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e0:ed43::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 3:xcjRLojFUdAQS0xfjeMqY+7hl0Oxp/N5K370jeerdun1bQiBSj8YVwJF29DsOcAKhVw17BluuPXSE5Y553J51UD5691rWGsUrdLHAZ5sW8rAphgVYFWv9WGaIQi7VLAZqkVZDwGYVvX8n5nhQO377A==; 10:ja4viyI16AMDj//cNKBfLuGTHiZLG6hIBl9GIk/UzbFMVBMNCFhq/telFDw+fiAEi8uHPehb4a6+FT1+dZV3XCS+FR9JMr8v06lpjFqZhDs=; 6:5UvNJLbOSl7ZLWGJDyAuHkC2hUfnAhFAj6vrg3sF2MV8peek954Kusggoon6Ebvt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(45074003)(13464003)(189002)(199003)(2656002)(62966003)(105586002)(87936001)(450100001)(46102003)(19580405001)(5001860100001)(5001960100002)(5001770100001)(64706001)(5001830100001)(86362001)(99286002)(106356001)(92566002)(77156002)(76576001)(189998001)(54356999)(106116001)(76176999)(50986999)(97736004)(40100003)(77096005)(81156007)(4001540100001)(101416001)(122556002)(74316001)(15975445007)(102836002)(68736005)(2950100001)(2900100001)(19580395003)(33656002)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2015 19:01:38.4033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: cose WG Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 19:01:48 -0000 In my reviews of the charter draft, I had pointed out that the deliverables= should include a CBOR-based key representation format equivalent to the JS= ON-based key representation format specified in RFC 7517 (JWK). I had thou= ght that, as a result of these comments and concurrence by others participa= ting in the discussion, the sentence "COSE seeks to create CBOR-based objec= t signing and encryption formats" was going to be amended to "COSE seeks to= create CBOR-based object signing, encryption, and key representation forma= ts". But this apparently didn't occur. I approve of the creation of this working group, subject to the charter tex= t being amended to clarify that a JWK equivalent is a chartered work item. -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, May 15, 2015 10:26 AM To: IETF-Announce Cc: cose WG Subject: [Cose] WG Review: CBOR Object Signing and Encryption (cose) A new IETF working group has been proposed in the Security Area. The IESG h= as not made any determination yet. The following draft charter was submitte= d, and is provided for informational purposes only. Please send your commen= ts to the IESG mailing list (iesg at ietf.org) by 2015-05-25. CBOR Object Signing and Encryption (cose) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Kathleen Moriarty Mailing list Address: cose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: http://www.ietf.org/mail-archive/web/cose/ Charter: Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary f= ormat for the serialization of data structured to an extended version of th= e JSON data model. COSE seeks to create CBOR-based object signing and encry= ption formats. One motivation for COSE was to reuse functionality from the = JOSE working group using the CBOR data representation as it is more amenabl= e to constrained nodes and constrained node networks (RFC 7228). The JOSE working group recently completed producing representations for cry= ptographic keys, message authentication (MACs), encryption, and digital sig= natures, using JSON representation.=20 The resulting formats will not be cryptographically convertible from or to = JOSE formats. This lack of a need for bit-for-bit compatibility will enable= some simplification in the adaptation process. Criteria that should be considered in the decision making process, changing= from JSON to CBOR encoding include: o Maintain the current JOSE paradigms and formatting where feasible. o Minimize message size, code size, and computational complexity to sui= t constrained environments, where this is expected to be used. o Improve security o Provide new functionality for additional use cases that were not requ= ired for JOSE.=20 Key management and binding of keys to identities are out of scope for the w= orking group. The COSE WG will not innovate in terms of cryptography.=20 The specification of algorithms in COSE is limited to those in RFCs or acti= ve IETF WG documents. The working group will coordinate its progress with the ACE, DICE and CORE = working groups to ensure that we are fulfilling the needs of these constitu= encies to the extent relevant to their work. Other groups may be added to t= his list as the set of use cases is expanded. The WG will have two deliverables: 1. A standards-track specification covering the same cryptographic formats = from JOSE, with optimizations for constrained device processing, expressed = in CBOR; 2. Registration for algorithms (such as AES-CCM-8) that are approp= riate for constrained environments. The Working Group will use a wiki to track desired use cases for its work, = but does not intend to publish this as an RFC. Milestones: Jun 2015 - Submit COSE specification as a WG item Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item Jan 2016 - Submit COSE specification to the IESG, for publication as a Pr= oposed Standard Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG, fo= r publication as a Proposed Standard _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Fri May 22 12:53:27 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D178B1A874D for ; Fri, 22 May 2015 12:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXOYyFoEbJDE for ; Fri, 22 May 2015 12:53:24 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967421A8746 for ; Fri, 22 May 2015 12:53:23 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id F2DF538F15; Fri, 22 May 2015 12:53:22 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <016501d091ae$67909510$36b1bf30$@augustcellars.com> <000701d09333$3fa641e0$bef2c5a0$@augustcellars.com> In-Reply-To: Date: Fri, 22 May 2015 12:53:20 -0700 Message-ID: <027d01d094c8$f4aad1f0$de0075d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE1tZrJJMzJio9nPTRuR95tavrVZQLhK4A2ApWjTTsCgPm6055+W2qQ Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 19:53:26 -0000 -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Friday, May 22, 2015 8:32 AM To: Jim Schaad Cc: 'Derek Atkins'; cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags "Jim Schaad" writes: >> It depends whether we want to have to say something like: >> >> alg => {ec_sha2 => p256} instead of alg => es256 > > My assumption has been that we are going to use a similar naming > scheme to that followed by JOSE. > > alg=> ec_sha2 - but the curve is defined in the key used. Thus ec_sha2 can > be used for any of the NIST curves and any other curve that follows > the same point convention. > > This means that we are going to get two versions of ECDH - one for the > current {x,y} points and a new one for the {x} only points. > > In terms of doing something like ECHD - there are a number of other > items that are defined in the algorithm id, i.e. not Chinese menu, > that will lead to some proliferation of algorithms. But not as badly > as TLS where a complete set of all algorithms are combined in a single suite value. I am fine with this approach (although I thought JOSE combined the EC with the Signature and Key Size, e.g. { alg: ES256 }? [JLS] No that is actually hash size. jim > Jim -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri May 22 13:06:48 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5371A877D for ; Fri, 22 May 2015 13:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJJcT7lpu_lF for ; Fri, 22 May 2015 13:06:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6E31A8768 for ; Fri, 22 May 2015 13:06:44 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.172.17; Fri, 22 May 2015 20:06:23 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0172.012; Fri, 22 May 2015 20:06:18 +0000 From: Mike Jones To: Jim Schaad , 'Derek Atkins' Thread-Topic: [Cose] ISSUE: Use of integer rather than string tags Thread-Index: AdCRq9rt20WbovolQKm1OfRYV6+NBgBfn9i6AAI5IAAAXFXFxAAJF4EAAABMjpA= Date: Fri, 22 May 2015 20:06:17 +0000 Message-ID: References: <016501d091ae$67909510$36b1bf30$@augustcellars.com> <000701d09333$3fa641e0$bef2c5a0$@augustcellars.com> <027d01d094c8$f4aad1f0$de0075d0$@augustcellars.com> In-Reply-To: <027d01d094c8$f4aad1f0$de0075d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e0:ed43::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 3:zJvCQKIr6GtgR/kc5jOeex2LfEByd01XhsLZRI9nFrkPK5heZ6J5JnF6hivVP95nFH9RlWYSvJZT5QSZTsiZZn363tv/zzxTwk6wMCt3atXEqRqSU5nuAHnQmkZ/rasdHmEQ2StSjkpYPATrL1Xi/w==; 10:7bC7PSfJt7dbbBKU86pEQQ6mBwSrcy+W48EFhmL4NQlsD2E+on8Wim4DKuHeoIL+UXn3tlQKD/NYwRdw4Dy/KTVZPsXAbJAW7QteqaGoNz4=; 6:/c1ae84mGZArAP05DrJQaNovaovnhkdU396BUFjpMSjyx1c0JJVi6/26Nm9+t0fq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520002)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377454003)(189002)(199003)(122556002)(4001540100001)(19580395003)(2900100001)(33656002)(86612001)(64706001)(5001860100001)(40100003)(86362001)(189998001)(102836002)(77096005)(19580405001)(5001770100001)(15975445007)(106356001)(5001830100001)(99286002)(81156007)(68736005)(97736004)(2950100001)(50986999)(105586002)(54356999)(76176999)(2656002)(87936001)(76576001)(15974865002)(101416001)(77156002)(62966003)(92566002)(5001960100002)(74316001)(46102003)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2015 20:06:17.1359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] ISSUE: Use of integer rather than string tags X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 20:06:47 -0000 Derek, you're right that JOSE chose to use string identifiers for algorithm= s, rather than structured identifiers. That means that algorithm processin= g just requires table lookup, rather than structure parsing. There are no = modifiers or additional algorithm parameters specified separately, by desig= n. One of the ways that the working group tried to "keep simple things sim= ple". Cheers, -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, May 22, 2015 12:53 PM To: 'Derek Atkins' Cc: cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Friday, May 22, 2015 8:32 AM To: Jim Schaad Cc: 'Derek Atkins'; cose@ietf.org Subject: Re: [Cose] ISSUE: Use of integer rather than string tags "Jim Schaad" writes: >> It depends whether we want to have to say something like: >>=20 >> alg =3D> {ec_sha2 =3D> p256} instead of alg =3D> es256 > > My assumption has been that we are going to use a similar naming=20 > scheme to that followed by JOSE. > > alg=3D> ec_sha2 - but the curve is defined in the key used. Thus ec_sha= 2 can > be used for any of the NIST curves and any other curve that follows=20 > the same point convention. > > This means that we are going to get two versions of ECDH - one for the=20 > current {x,y} points and a new one for the {x} only points. > > In terms of doing something like ECHD - there are a number of other=20 > items that are defined in the algorithm id, i.e. not Chinese menu,=20 > that will lead to some proliferation of algorithms. But not as badly=20 > as TLS where a complete set of all algorithms are combined in a single suite value. I am fine with this approach (although I thought JOSE combined the EC with = the Signature and Key Size, e.g. { alg: ES256 }? [JLS] No that is actually hash size. jim > Jim -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Fri May 22 19:13:48 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7A81A8A6E; Fri, 22 May 2015 19:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crvTR0wiMEsx; Fri, 22 May 2015 19:13:38 -0700 (PDT) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id DD41D1A8A80; Fri, 22 May 2015 19:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1432347217; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=BLXbE3Yp+oP3GY9/WQYBVWtwiSv1/wkczvtz8gCjkoY=; b=OP98Jqtr6uAkKbtKJIcCgBdRpJpJiQC0MtTF60EmmjpW33HtW1vhLavK0Wsg/74lTqj3Qvz4cWg8UIYPv9qidtcMVdPP+bv0F4HNjiuQ8Ifka4N/FFP5cwUriLvGwl7hGFActjvEZuSmJLWakfzwBHMgdU6cQR+xc84d6cwaLfA= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R111e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05042; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.22.58.136(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 23 May 2015 10:13:33 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 23 May 2015 10:13:25 +0800 From: "Kepeng Li" To: Mike Jones , The IESG Message-ID: Thread-Topic: [Cose] WG Review: CBOR Object Signing and Encryption (cose) References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: cose WG Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 02:13:45 -0000 Hi Mike, According to the previous discussion, CBOR-based key representation format is implied as a charter item: http://www.ietf.org/mail-archive/web/cose/current/msg00022.html It should be fine to change the charter text as requested. OLD: COSE seeks to create CBOR-based object signing and encryption formats. NEW: COSE seeks to create CBOR-based object signing, encryption, and key representation formats. Kind Regards Kepeng=20 =D4=DA 23/5/15 3:01 am=A3=AC "Mike Jones" =D0=B4=C8=EB: >In my reviews of the charter draft, I had pointed out that the >deliverables should include a CBOR-based key representation format >equivalent to the JSON-based key representation format specified in RFC >7517 (JWK). I had thought that, as a result of these comments and >concurrence by others participating in the discussion, the sentence "COSE >seeks to create CBOR-based object signing and encryption formats" was >going to be amended to "COSE seeks to create CBOR-based object signing, >encryption, and key representation formats". But this apparently didn't >occur. > >I approve of the creation of this working group, subject to the charter >text being amended to clarify that a JWK equivalent is a chartered work >item. > > -- Mike > >-----Original Message----- >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of The IESG >Sent: Friday, May 15, 2015 10:26 AM >To: IETF-Announce >Cc: cose WG >Subject: [Cose] WG Review: CBOR Object Signing and Encryption (cose) > >A new IETF working group has been proposed in the Security Area. The IESG >has not made any determination yet. The following draft charter was >submitted, and is provided for informational purposes only. Please send >your comments to the IESG mailing list (iesg at ietf.org) by 2015-05-25. > >CBOR Object Signing and Encryption (cose) >------------------------------------------------ >Current Status: Proposed WG > >Assigned Area Director: > Kathleen Moriarty > >Mailing list > Address: cose@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/cose > Archive: http://www.ietf.org/mail-archive/web/cose/ > >Charter: > >Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary >format for the serialization of data structured to an extended version of >the JSON data model. COSE seeks to create CBOR-based object signing and >encryption formats. One motivation for COSE was to reuse functionality >from the JOSE working group using the CBOR data representation as it is >more amenable to constrained nodes and constrained node networks (RFC >7228). > >The JOSE working group recently completed producing representations for >cryptographic keys, message authentication (MACs), encryption, and >digital signatures, using JSON representation. > >The resulting formats will not be cryptographically convertible from or >to JOSE formats. This lack of a need for bit-for-bit compatibility will >enable some simplification in the adaptation process. > >Criteria that should be considered in the decision making process, >changing from JSON to CBOR encoding include: > o Maintain the current JOSE paradigms and formatting where feasible. > o Minimize message size, code size, and computational complexity to >suit constrained environments, where this is expected to be used. > o Improve security > o Provide new functionality for additional use cases that were not >required for JOSE. > >Key management and binding of keys to identities are out of scope for the >working group. The COSE WG will not innovate in terms of cryptography. >The specification of algorithms in COSE is limited to those in RFCs or >active IETF WG documents. > >The working group will coordinate its progress with the ACE, DICE and >CORE working groups to ensure that we are fulfilling the needs of these >constituencies to the extent relevant to their work. Other groups may be >added to this list as the set of use cases is expanded. > >The WG will have two deliverables: > >1. A standards-track specification covering the same cryptographic >formats from JOSE, with optimizations for constrained device processing, >expressed in CBOR; 2. Registration for algorithms (such as AES-CCM-8) >that are appropriate for constrained environments. >The Working Group will use a wiki to track desired use cases for its >work, but does not intend to publish this as an RFC. > >Milestones: > Jun 2015 - Submit COSE specification as a WG item > Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item > Jan 2016 - Submit COSE specification to the IESG, for publication as a >Proposed Standard > Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG, >for publication as a Proposed Standard > > >_______________________________________________ >Cose mailing list >Cose@ietf.org >https://www.ietf.org/mailman/listinfo/cose > >_______________________________________________ >Cose mailing list >Cose@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Fri May 22 19:15:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7F31A0063; Fri, 22 May 2015 11:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjwHG6hg-2Yj; Fri, 22 May 2015 11:52:09 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC631A0019; Fri, 22 May 2015 11:52:08 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so18982234lbb.0; Fri, 22 May 2015 11:52:07 -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:message-id:subject :from:to:cc:content-type; bh=4tPoluRdPKp+3jJCyB1LrBDDekt7aR8XNA/xbOeU7vI=; b=fqDhhPXoEw/H7fSZ0J/l/7Xr+xPhQSzxOEQV+MFFj6uMGcpRf0yR5BmGCogzsnzyid OxbmVcVtMA9punCV1Uj15BxAZqJKO5xhus4oC8BJkDDW9BkfjzSYUQkRZ21YkP3Vrv+8 eebziyM1H6bkslEM633b/OmJdfas0R+ZcOQJAfgLbqmHIaT1PnCXivTTU8+99GKnuExQ j00Mz1b6mZa2LdAwPeJnp2aDBUqfIoZAROLQeSjqUlKgyeqRUQiqsbZtvn0joHSf8euQ 2qE2eN180t6/rOEcjdgVphZf4YEZCPZTEx38uCLs3ckwaujEEbXewWQxhcShFRpbjLUW QlBA== MIME-Version: 1.0 X-Received: by 10.112.72.40 with SMTP id a8mr4647509lbv.58.1432320727065; Fri, 22 May 2015 11:52:07 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 22 May 2015 11:52:06 -0700 (PDT) In-Reply-To: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> Date: Fri, 22 May 2015 14:52:06 -0400 X-Google-Sender-Auth: odEqU-J44vQg-u-I_PibTbPE8ZA Message-ID: From: Phillip Hallam-Baker To: IETF Discussion Mailing List Content-Type: multipart/alternative; boundary=001a11c23e2e24317c0516b0287f Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 19:15:39 -0700 Cc: IETF-Announce , cose WG Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 18:52:12 -0000 --001a11c23e2e24317c0516b0287f Content-Type: text/plain; charset=UTF-8 As I stated in the JOSE working group, this is a very bad idea and should not go forward. When CBOR was proposed, the group working on it asserted that it was a private initiative, outside IETF process and they had no obligation to consider other design approaches. As a result they chose to design a new binary encoding that is not based on the JSON model, offers no advantages over the JSON model and requires protocols making use of the encoding to be hand tweaked on a case by case basis. If the CBOR group had been willing to accept input from outside their closed circle, this could have been avoided. The core problem with CBOR is that it appears that the network protocol specification community has made a consensus decision to base all future work on the JSON encoding specification. A binary encoding obviously cannot be compatible with JSON but it can be compatible with the JSON data model. CBOR throws away the JSON data model and replaces it with its own idiosyncratic approach. The 'need' for this new working group is purely the result of that decision. While it is 'possible' to encode JSON in CBOR and vice versa, the same is true of JSON and XML, XML and ASN.1 and JSON and ASN.1. Nobody disputes that it is possible to use CBOR as a binary encoding for JSON. The problem is that the introduction of a new and incompatible data model means that such a mapping has to be written by hand. It did not need to be this way. Many of us who commented on CBOR said that we do not want any encoding that changes the JSON data model. In fact the only limitations we find in JSON are the need to perform escaping on string literals and the lack of a binary blob type. Rather than develop a completely new encoding we would much prefer to simply add these two missing features to JSON. While the result is no longer a pure text encoding, it is close enough that we can add support by simply adding a few extra tags to the existing JSON encoding. One of the problems of dealing with a situation like this is that the first response is 'make your own proposal' and if you do that the response is to accuse detractors of clinging to their own scheme. For the record, the only reason I wrote my counter-proposal was to demonstrate that it is possible to develop a binary encoding of JSON that is efficient and does not require any further work to apply it to JOSE or any other JSON based protocol. This binary encoding is described in: https://www.ietf.org/archive/id/draft-hallambaker-jsonbcd-02.txt Since this encoding does not change the JSON data model, no additional specification is required to describe the application to JOSE. Applying the encoding to the example in the JOSE specification produces the following results: In JSON: 244 bytes Protected 35 / Payload 70 / Signature 32 In JSON-B: 165 bytes Protected 24 / Payload 70 / Signature 32 In JSON-C: 129 bytes Protected 13 / Payload 70 / Signature 32 JSON-B is JSON with minimal extensions to support binary encoding, JSON-C adds a compression capability. While a compression capability may or may not be desirable, it is useful to have data to make such a decision. The issue here is not just JOSE. If this precedent is accepted we can expect a demand for similar groups to repeat all the work that is being done in JSON in CBOR. So after we complete ACME we will have a proposal to start a CACME working group. And on and on and on. Choice of binary versus text encoding should be no more than a switch like choosing UTF8 encoding versus UTF16. If changing the position of the switch has knock on effects in the rest of the specification there is something seriously wrong with the design. Choice of encoding is not an 'editor war' issue because it is a choice that affects everyone in the user community. I want to see as much commonality across the design space as possible. JSON is not the perfect encoding but it does eliminate the primary objections to the use of XML and ASN.1, namely the fact that they impose a highly convoluted and complex set of rules for converting between data structures and the encoding. The fact that JSON can encode the same data with equivalent or better efficiency to XML shows that the rules are not necessary. JSON-B achieves similar efficiency to ASN.1 The only reason this group is necessary is that CBOR is not suited to IETF needs. Rather than starting a working group to rewrite IETF standards so they are suited to work in CBOR we should start a working group to make something that does the job of CBOR that is suited to use by the IETF. IESG should reject this WG proposal and all future proposals of this type. On Fri, May 15, 2015 at 1:25 PM, The IESG wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2015-05-25. > > CBOR Object Signing and Encryption (cose) > ------------------------------------------------ > Current Status: Proposed WG > > Assigned Area Director: > Kathleen Moriarty > > Mailing list > Address: cose@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/cose > Archive: http://www.ietf.org/mail-archive/web/cose/ > > Charter: > > Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary > format for the serialization of data structured to an extended version of > the JSON data model. COSE seeks to create CBOR-based object signing and > encryption formats. One motivation for COSE was to reuse functionality > from the JOSE working group using the CBOR data representation as it is > more amenable to constrained nodes and constrained node networks (RFC > 7228). > > The JOSE working group recently completed producing representations for > cryptographic keys, message authentication (MACs), encryption, and > digital signatures, using JSON representation. > > The resulting formats will not be cryptographically convertible from or > to JOSE formats. This lack of a need for bit-for-bit compatibility will > enable some simplification in the adaptation process. > > Criteria that should be considered in the decision making process, > changing from JSON to CBOR encoding include: > o Maintain the current JOSE paradigms and formatting where feasible. > o Minimize message size, code size, and computational complexity to > suit constrained environments, where this is expected to be used. > o Improve security > o Provide new functionality for additional use cases that were not > required for JOSE. > > Key management and binding of keys to identities are out of scope for the > working group. The COSE WG will not innovate in terms of cryptography. > The specification of algorithms in COSE is limited to those in RFCs or > active IETF WG documents. > > The working group will coordinate its progress with the ACE, DICE and > CORE working groups to ensure that we are fulfilling the needs of these > constituencies to the extent relevant to their work. Other groups may be > added to this list as the set of use cases is expanded. > > The WG will have two deliverables: > > 1. A standards-track specification covering the same cryptographic > formats from JOSE, with optimizations for constrained device processing, > expressed in CBOR; > 2. Registration for algorithms (such as AES-CCM-8) that are appropriate > for constrained environments. > The Working Group will use a wiki to track desired use cases for its > work, but does not intend to publish this as an RFC. > > Milestones: > Jun 2015 - Submit COSE specification as a WG item > Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item > Jan 2016 - Submit COSE specification to the IESG, for publication as a > Proposed Standard > Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG, > for publication as a Proposed Standard > > > --001a11c23e2e24317c0516b0287f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I stated in the JOSE working group, this is a very bad = idea and should not go forward.

When CBOR was proposed, = the group working on it asserted that it was a private initiative, outside = IETF process and they had no obligation to consider other design approaches= . As a result they chose to design a new binary encoding that is not based = on the JSON model, offers no advantages over the JSON model and requires pr= otocols making use of the encoding to be hand tweaked on a case by case bas= is.

If the CBOR group had been willing to accept i= nput from outside their closed circle, this could have been avoided.
<= div>

The core problem with CBOR is that it app= ears that the network protocol specification community has made a consensus= decision to base all future work on the JSON encoding specification. A bin= ary encoding obviously cannot be compatible with JSON but it can be compati= ble with the JSON data model. CBOR throws away the JSON data model and repl= aces it with its own idiosyncratic approach.=C2=A0

The 'need' for this new working group is purely the result of that= decision. While it is 'possible' to encode JSON in CBOR and vice v= ersa, the same is true of JSON and XML, XML and ASN.1 and JSON and ASN.1. N= obody disputes that it is possible to use CBOR as a binary encoding for JSO= N. The problem is that the introduction of a new and incompatible data mode= l means that such a mapping has to be written by hand.

=

It did not need to be this way. Many of us who commente= d on CBOR said that we do not want any encoding that changes the JSON data = model. In fact the only limitations we find in JSON are the need to perform= escaping on string literals and the lack of a binary blob type. Rather tha= n develop a completely new encoding we would much prefer to simply add thes= e two missing features to JSON. While the result is no longer a pure text e= ncoding, it is close enough that we can add support by simply adding a few = extra tags to the existing JSON encoding.=C2=A0

One of the problems of dealing with a situation like this is t= hat the first response is 'make your own proposal' and if you do th= at the response is to accuse detractors of clinging to their own scheme. Fo= r the record, the only reason I wrote my counter-proposal was to demonstrat= e that it is possible to develop a binary encoding of JSON that is efficien= t and does not require any further work to apply it to JOSE or any other JS= ON based protocol.


Since this = encoding does not change the JSON data model, no additional specification i= s required to describe the application to JOSE. Applying the encoding to th= e example in the JOSE specification produces the following results:
In JSON:   244 bytes
    Protected 35 / Payload 70 / Signature 32
In JSON-B: 165 bytes
    Protected 24 / Payload 70 / Signature 32
In JSON-C: 129 bytes
    Protected 13 / Payload 70 / Signature 32
JSON-B is JSON= with minimal extensions to support binary encoding, JSON-C adds a compress= ion capability. While a compression capability may or may not be desirable,= it is useful to have data to make such a decision.

The issue here is not just JOSE. If this precedent is accepted we can exp= ect a demand for similar groups to repeat all the work that is being done i= n JSON in CBOR. So after we complete ACME we will have a proposal to start = a CACME working group. And on and on and on.=C2=A0

Choice of binary versus text encoding should be no more than a switch like= choosing UTF8 encoding versus UTF16. If changing the position of the switc= h has knock on effects in the rest of the specification there is something = seriously wrong with the design.

Choice of enc= oding is not an 'editor war' issue because it is a choice that affe= cts everyone in the user community. I want to see as much commonality acros= s the design space as possible. JSON is not the perfect encoding but it doe= s eliminate the primary objections to the use of XML and ASN.1, namely the = fact that they impose a highly convoluted and complex set of rules for conv= erting between data structures and the encoding. The fact that JSON can enc= ode the same data with equivalent or better efficiency to XML shows that th= e rules are not necessary. JSON-B achieves similar efficiency to ASN.1=C2= =A0


The only reason this group is n= ecessary is that CBOR is not suited to IETF needs. Rather than starting a w= orking group to rewrite IETF standards so they are suited to work in CBOR w= e should start a working group to make something that does the job of CBOR = that is suited to use by the IETF.

IESG should rej= ect this WG proposal and all future proposals of this type.=C2=A0



On Fri, May 15, 2015 at 1:25 PM, The IESG <iesg-sec= retary@ietf.org> wrote:
A n= ew IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2015-05-25.

CBOR Object Signing and Encryption (cose)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
=C2=A0 Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

Mailing list
=C2=A0 Address: cose@ietf.org
=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/cose
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/cose/

Charter:

Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for the serialization of data structured to an extended version of the JSON data model. COSE seeks to create CBOR-based object signing and
encryption formats. One motivation for COSE was to reuse functionality
from the JOSE working group using the CBOR data representation as it is
more amenable to constrained nodes and constrained node networks (RFC
7228).

The JOSE working group recently completed producing representations for
cryptographic keys, message authentication (MACs), encryption, and
digital signatures, using JSON representation.

The resulting formats will not be cryptographically convertible from or
to JOSE formats. This lack of a need for bit-for-bit compatibility will
enable some simplification in the adaptation process.

Criteria that should be considered in the decision making process,
changing from JSON to CBOR encoding include:
=C2=A0 =C2=A0 o Maintain the current JOSE paradigms and formatting where fe= asible.
=C2=A0 =C2=A0 o Minimize message size, code size, and computational complex= ity to
suit constrained environments, where this is expected to=C2=A0 be used.
=C2=A0 =C2=A0 o Improve security
=C2=A0 =C2=A0 o Provide new functionality for additional use cases that wer= e not
required for JOSE.

Key management and binding of keys to identities are out of scope for the working group.=C2=A0 The COSE WG will not innovate in terms of cryptography= .
The specification of algorithms in COSE is limited to those in RFCs or
active IETF WG documents.

The working group will coordinate its progress with the ACE, DICE and
CORE working groups to ensure that we are fulfilling the needs of these
constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded.

The WG will have two deliverables:

1. A standards-track specification covering the same cryptographic
formats from JOSE, with optimizations for constrained device processing, expressed in CBOR;
2. Registration for algorithms (such as AES-CCM-8) that are appropriate
for constrained environments.
The Working Group will use a wiki to track desired use cases for its
work, but does not intend to publish this as an RFC.

Milestones:
=C2=A0 Jun 2015 - Submit COSE specification as a WG item
=C2=A0 Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG it= em
=C2=A0 Jan 2016 - Submit COSE specification to the IESG, for publication as= a
Proposed Standard
=C2=A0 Jan 2016 - Submit COSE constrained-appropriate algorithms to the IES= G,
for publication as a Proposed Standard



--001a11c23e2e24317c0516b0287f-- From nobody Fri May 22 19:15:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D3A1A87E6; Fri, 22 May 2015 14:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh7O-sZ-bpDg; Fri, 22 May 2015 14:04:18 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB31A8889; Fri, 22 May 2015 14:04:18 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id E9B5740120658; Fri, 22 May 2015 14:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=eYFIi3GMtP1n+c DQBhVe8HdcX4o=; b=e92ZHGhYsczgecBGcAVua0H5LC0Zxg2X7bH8n/u2XDCoXG 1BI1lTeNf/FwBD3RB2DErvunDAdv0MuY9eud4K9w28M/y0QlFfuc2BHWiutWCfbL y545KuxidDz+OYQUA2duu5Iy35BT3oEc+e3+hragicgnjsfanPzApTaGdP8/M= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 69A8F400DC13C; Fri, 22 May 2015 14:04:17 -0700 (PDT) Date: Fri, 22 May 2015 16:04:16 -0500 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20150522210306.GH3791@localhost> References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 19:15:39 -0700 Cc: IETF Discussion Mailing List , IETF-Announce , cose WG Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 21:04:19 -0000 On Fri, May 22, 2015 at 02:52:06PM -0400, Phillip Hallam-Baker wrote: > It did not need to be this way. Many of us who commented on CBOR said that > we do not want any encoding that changes the JSON data model. In fact the > only limitations we find in JSON are the need to perform escaping on string > literals and the lack of a binary blob type. Rather than develop a [...] Also inefficiency as to numbers. In a binary protocol ideally numbers could be sent in whatever format is easiest for the sender (e.g., little-endian IEEE754 doubles). All I wanted was: chunking for strings, which effectively takes care of the need for a binary type, and binary numbers. CBOR added a datetime type, optional tagging of items, and who knows what else. > IESG should reject this WG proposal and all future proposals of this type. +1 to this and Sam's take. Nico -- From nobody Fri May 22 19:15:43 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB18E1A8A08; Fri, 22 May 2015 16:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQAeJRvf8Upr; Fri, 22 May 2015 16:54:45 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3E1A89F5; Fri, 22 May 2015 16:54:44 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id B95F1400F8E11; Fri, 22 May 2015 16:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=i582FspZ1x27wZ o5BqYCTGi4un0=; b=xhtjILZPn3KY3PgzFN9870ylT4ZI+ebnOD+aC9uCDi/qKD 3OH5q33B0XHUhnvbvLT1mEfxdFF/6aoU6EyQtVgUqIF8gYHG8aWvPRjx9z6xZYc6 SOwPEuLcEYEC9U/05ls4kZ6rqbhv6aHEeb8/WVqDuMJOh0Yxu12wLAPMVqPT4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 6ECD7400F8E10; Fri, 22 May 2015 16:54:43 -0700 (PDT) Date: Fri, 22 May 2015 18:54:42 -0500 From: Nico Williams To: IETF Discussion Mailing List Message-ID: <20150522235442.GA2166@localhost> References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> <20150522210306.GH3791@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150522210306.GH3791@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 19:15:39 -0700 Cc: cose@ietf.org Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:54:46 -0000 I should clarify that my objection is to a working group IF a JOSE->CBOR mapping is trivial enough, and if it's not trivial due to CBOR having a different data model from JOSE, well, then there's Phillip's I-told-you- so. Also, COSE is predicated on constrained devices ("class 1"), and some thought convinces me that it is true that [at least a profile of] CBOR is easier to implement than JSON, but mostly that's a function of a) being able to use base-2 number representations on the wire, and b) not having to escape/unescape strings. Decimal<->IEEE754 conversions are easily the trickiest part of any decent JSON parser/encoder, so I'm quire prepared to believe that CBOR is easier to implement on class 1 constrained devices. Now, looking again at the WG proposal, there are deliverables that go beyond merely mapping JOSE onto CBOR, so perhaps there is enough work for a WG. Therefore I retract my opposition. Nico -- From nobody Tue May 26 12:50:38 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1701A212A; Tue, 26 May 2015 12:50:33 -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=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vTKjfVngySl; Tue, 26 May 2015 12:50:31 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12061A008F; Tue, 26 May 2015 12:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4QJoRR9003398; Tue, 26 May 2015 21:50:27 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lx5Vq1nGSz8xsg; Tue, 26 May 2015 21:50:27 +0200 (CEST) Message-ID: <5564CE81.7040904@tzi.org> Date: Tue, 26 May 2015 21:50:25 +0200 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Andrew Newton References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose WG , IETF Discussion Mailing List , "iesg@ietf.org" Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:50:33 -0000 Andrew Newton wrote: > Fair enough, however basing further IETF work on it may not be wrong but > does not seem right either. CBOR is getting a lot of traction in the constrained node networking space (the low-resource part of the "Internet of Things"), which is not surprising as it was designed for hat. Not basing further IETF work on CBOR would ensure the IETF loses impact there, and would accomplish what? > I also noticed that the active draft for this effort has a normative > dependency on CDDL. How best to write up the spec is indeed an interesting issue. For now, CDDL is a good way to discuss the draft, much better than lobbing around large quantities of ambiguous English prose. But then, CDDL is still being tweaked, and it is not clear that the IETF wants to give this language a role similar to the one ABNF has for text, or (even if that is at some point accepted as a reasonable thing to do) would want to reach a decision on something like this before COSE is done. So, once the remaining decisions have been taken, the CDDL snippets will probably move to an appendix, and will be replaced in their normative role by gobs of ambiguous English prose. With any luck, we may be able to generate that automatically from the CDDL (just as we are already checking the examples automatically against the CDDL). (Kudos, by the way, for the concepts the CDDL authors could steal from JCR; what a great source of inspiration.) Grüße, Carsten From nobody Wed May 27 03:40:46 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF41B2FDE for ; Tue, 26 May 2015 11:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zsklu54YJPD for ; Tue, 26 May 2015 11:31:39 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A421B2FDF for ; Tue, 26 May 2015 11:31:37 -0700 (PDT) Received: by wizk4 with SMTP id k4so86839548wiz.1 for ; Tue, 26 May 2015 11:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GRo0pQUsVQb1WHvmBCdgUmyRaAEhJi8CIX15wA7+RnE=; b=AnHbmqC09XSV8/R6B0L4nUXMV2UK0P61TLmdHORwY3eEIHSL6KtXgkHwLpoxttSr7A OJY3J11mZ5GzfGtGHzOtGca08+OjP/6Htx7fN9ZTnbMRM7O4Yc5+P9dk3oefMxbzg0yJ r2mrTZ9mfBPrGqwfzSd4HyZJxhrrVezPqdaNDFwLYTcrAR83zGcvMZ0jfuNBEA95PYv7 NDL3z7W1+Dkf5GBySQs+46N6eYP85w92IfKIinDJA6G7JD+sEH3wm76gW6WsO3nZYCAc 5olglx4ARB1Ts8Ez8t4YcY/HF12yKCsL6I9UUxVGyn8u4BKUCt9erzxdz3vTcKXwirwD MJvg== X-Gm-Message-State: ALoCoQkVF1BZdbHoE0/W6hppkNbBFw4uMQLnftW0j77MMskSyiP/rhF1LLYxNKSMV60CRNbJD2Pj MIME-Version: 1.0 X-Received: by 10.180.106.97 with SMTP id gt1mr11481702wib.37.1432665096204; Tue, 26 May 2015 11:31:36 -0700 (PDT) Received: by 10.194.249.99 with HTTP; Tue, 26 May 2015 11:31:36 -0700 (PDT) X-Originating-IP: [2001:500:4:15:6d13:f92f:21d4:d470] In-Reply-To: References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 14:31:36 -0400 Message-ID: From: Andrew Newton To: IETF Discussion Mailing List , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428066244d77051700560f Archived-At: X-Mailman-Approved-At: Wed, 27 May 2015 03:40:44 -0700 Cc: Phillip Hallam-Baker , cose WG Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:31:40 -0000 --f46d04428066244d77051700560f Content-Type: text/plain; charset=UTF-8 First, I appreciate the effort that went into this charter text. It is clear, understandable, and properly focused. That being said... On Fri, May 22, 2015 at 2:52 PM, Phillip Hallam-Baker wrote: > When CBOR was proposed, the group working on it asserted that it was a > private initiative, outside IETF process and they had no obligation to > consider other design approaches. There was an appeal regarding the publication of CBOR for which the outcome was: 1) IETF process was not followed, and 2) but the RFC is already published and some bells cannot be unrung. Fair enough, however basing further IETF work on it may not be wrong but does not seem right either. Phillip, having been active in the JSON wg and a known security-area participant, has a broader point that different design decisions may have been made had we known things would go this far. I also noticed that the active draft for this effort has a normative dependency on CDDL. Working groups such as TZDIST were told they could not normatively depend on JCR. Again, fair enough. But what is to happen here? Given the parallels drawn between CBOR and JSON, it would be unfortunate for the IETF to bless one "JSON schema language" without a wider discussion. I am not saying they shouldn't use CDDL, but it would be best if the relationship between it and JSON were more clearly understood. -andy --f46d04428066244d77051700560f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, I appreciate the effort that went into this ch= arter text. It is clear, understandable, and properly focused.
That being said...

On Fri, May 22, 2015 at 2:52 PM, P= hillip Hallam-Baker <phill@hall= ambaker.com> wrote:
> When CBOR was proposed, the group workin= g on it asserted that it was a
> private initiative, outside IETF pro= cess and they had no obligation to
> consider other design approaches= .

There was an appeal regarding the publication of CBOR for which th= e outcome was: 1) IETF process was not followed, and 2) but the RFC is alre= ady published and some bells cannot be unrung. Fair enough, however basing = further IETF work on it may not be wrong but does not seem right either. Ph= illip, having been active in the JSON wg and a known security-area particip= ant, has a broader point that different design decisions may have been made= had we known things would go this far.

I also noticed t= hat the active draft for this effort has a normative dependency on CDDL. Wo= rking groups such as TZDIST were told they could not normatively depend on = JCR. Again, fair enough. But what is to happen here? Given the parallels dr= awn between CBOR and JSON, it would be unfortunate for the IETF to bless on= e "JSON schema language" without a wider discussion. I am not say= ing they shouldn't use CDDL, but it would be best if the relationship b= etween it and JSON were more clearly understood.

-= andy
--f46d04428066244d77051700560f-- From nobody Wed May 27 03:56:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778B01ACD0A; Wed, 27 May 2015 03:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OHbUVYfIHZD; Wed, 27 May 2015 03:56:11 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132C91A87C5; Wed, 27 May 2015 03:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4RAu3Tg018915; Wed, 27 May 2015 12:56:03 +0200 (CEST) Received: from alma.local (unknown [IPv6:2002:8666:da7b:0:94cb:259:d06b:b7c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lxTbk5PCMz8xtC; Wed, 27 May 2015 12:56:02 +0200 (CEST) Date: Wed, 27 May 2015 12:56:02 +0200 From: Carsten Bormann To: Nico Williams , IETF Discussion Mailing List Message-ID: In-Reply-To: <20150522235442.GA2166@localhost> References: <20150515172554.1006.60355.idtracker@ietfa.amsl.com> <20150522210306.GH3791@localhost> <20150522235442.GA2166@localhost> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5565a2c2_dcc3b3a_7e3b" Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 10:56:12 -0000 --5565a2c2_dcc3b3a_7e3b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 23 May 2015 at 04:16:00, Nico Williams (nico=40cryptonector.com) wrote= : I should clarify that my objection is to a working group I=46 a JOSE->CBO= R=C2=A0 mapping is trivial enough,=C2=A0 The CBOR data model is a superset of the JSON data model, so a trivial tr= anslation of JOSE to CBOR is indeed trivial. Doing such a trivial mapping would be completely misguided, though, as CB= OR has additional capabilities, and the efficiencies we need in the const= rained node network environment are indeed made possible by those additio= nal capabilities =5B1=5D. =C2=A0So the main work of the WG will simply be= about how exactly to use those capabilities. =C2=A0(It all looks trivial= on a napkin, but a few bikesheds still have to be painted.) =C2=A0Any ot= her hypothetical approach that adds binary capabilities to the JSON data = model will need to do this kind of work, bold statements to the contrary = notwithstanding. The lack of a need for backward compatibility with dusty JavaScript decks= also means that a few unsavory details of JOSE can be cleaned up in the = process (e.g., JOSE muddles up MACs and signatures, which is easily fixed= ). =C2=A0The WG clearly is mandated to be rather conservative in those cl= eanups. Now, looking again at the WG proposal, there are deliverables that go=C2=A0= beyond merely mapping JOSE onto CBOR, so perhaps there is enough work=C2=A0= for a WG. Therefore I retract my opposition.=C2=A0 Thank you. Gr=C3=BC=C3=9Fe, Carsten =5B1=5D: http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf --5565a2c2_dcc3b3a_7e3b Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline