From nobody Thu Feb 20 00:47:06 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8667A12083A; Thu, 20 Feb 2020 00:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 1UZKT6IIn9o3; Thu, 20 Feb 2020 00:47:02 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2041.outbound.protection.outlook.com [40.107.20.41]) (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 57B26120850; Thu, 20 Feb 2020 00:46:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IR5f5aI5PbYzDPbslje7hgVdI8GbtTTJZB7BCe/nMd6UuJiLfSf959HvilIO5PtJsYTpLTZpPnwYpnnd46AtrFLPVgGfY8WuZGA49a5UGi0+0voQjEb+ecCGy+LyfjDtqO8cVBuviNRFpP+KEsaxaxUFj0e8WLjUfQhcSZqtoGp/ygXJoSzbGUwR/qqoToW58C1LBw3ZwRHq25qMn0Ox6txr27rEKRkXcVFSnT83AYVYZ8YW2a0Enrvl3m7oyWjQhgSbLe+Hft1/VubJnDtRPJheDLFtOy0WwcKWzI2Hb1BG0mwCeSlaIDzY8fTurDS2oOOemcB81q5viSzRYFX/SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kueBrEu79ADUIS6YVn64shSFL3tIKtY9jdqyrNTUcgg=; b=Eak9RZ2O+iE0YPxwie3+FI3TO0dw22CbtThBPYgdGulnf3V3ps7SLC4Zi35kNMJ4Gb2HwQ4AEEJiuyT0QN175HKAZ7VHhXOlxk9OWERpN7lDVVZC9U3Gm+/8fCUgrDzCs1yzIwLsETaSGDwNChOFIvngOrYRwKmhy7HbLYoV0pynk5wC/IU7bPQr0iJsgh/Cjs+1x9exJfiOsXx8UXFwWEy43xc4rkXOaFlaOUsagsfkZJ2KTtBnQO6tIpYaK15WxP7yX8Bb4MXinPBmD8tOpIM3drfap/UPvnISX/tvN7YD2We7d7GC2i5gsO1P7wprTVe107Fy8mVC4OLKKE8yYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kueBrEu79ADUIS6YVn64shSFL3tIKtY9jdqyrNTUcgg=; b=NCx1AAqcjM8zY2yr4GprWj6vmHOaG5jZzIYtWqtFKnJd1jiiVAB/+xEpbVwDX11EkJg+wmg0+XGzEvtj72Kq1+hlEScdJ9CUsRdfa6ifGnPZU3vnvBqigVVr48FuvD8iRZHo/0h6k9/7D2+ni/hCwSJ73mUG9GBzIH8VnbN96IM= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4806.eurprd07.prod.outlook.com (20.177.197.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.12; Thu, 20 Feb 2020 08:46:57 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2750.016; Thu, 20 Feb 2020 08:46:57 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" CC: "secdispatch-chairs@ietf.org" Thread-Topic: Call for agenda items at IETF107 Thread-Index: AQHV58pPKtDJJVWKpEuFcbAW1O/Kyw== Date: Thu, 20 Feb 2020 08:46:57 +0000 Message-ID: <6D7F681C-435A-4361-B3C0-5197BF444F27@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afae97ff-e64f-41d6-f73b-08d7b5e17196 x-ms-traffictypediagnostic: AM6PR07MB4806: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 031996B7EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(81166006)(81156014)(2906002)(36756003)(316002)(5660300002)(4744005)(26005)(6506007)(8676002)(44832011)(2616005)(8936002)(186003)(6916009)(66446008)(9326002)(66556008)(66476007)(86362001)(478600001)(6512007)(33656002)(76116006)(4326008)(64756008)(6486002)(71200400001)(66946007)(91956017)(450100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4806; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q/rHTK3CbU0sBisV9OkYFwEF9kHJvDoS/YY5fdHixVWFSSHynhL8BpdetJ86kBB5Q3rhyQn7vpYkq1pQsA2Sx8C5iNpLMkjW6iimi6rqjgXyPhJYzRk4Se4BOJzcL1+m6WgdwnOmojp1dZRqz4LcRuSo2WLVqMmrtKMeo1A73GKIDIn47vu2/C/FekLxmsmeyKK0P+q5f6aS4ca2t9MlMTTzMPRHnNVdlI0dC0olm3VCy9w9RFQMt7FcSMgW1S9AItl/vAo+HOLfJmmlWRl91VRM2MhTeSelCMT5dW3BJp4b8hL3XeU2CF9AEY+5WmkqstHB7t2QSoYvXvitMyWM+f+74ZO4qXbju6SuQW7eV7K+z0n/YWLQ32hfIJcDxQkAQj2blpYRCWX6o8cD5XlqZSdAYx1/spYWICzE5qgf+Vop3iwMIzGVz05UkhJanN8l x-ms-exchange-antispam-messagedata: mff8WAQkaAurWsc8NuGTubKWxqVH7K6Rr2SjyjDhYbSuZkTK4yImICN9ZRFMJYXVkQKug840QFKolYX8A/qMDcQ7xtGEgERE7EdrwSg2LMR4AJPRly6p93SlFTqWseWzFrwgkIx+C6ksaViZW3lo2w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6D7F681C435A4361B3C05197BF444F27ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: afae97ff-e64f-41d6-f73b-08d7b5e17196 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 08:46:57.3273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hsutX5hhAdiU+Y35VHO0vsXLCNfmuO9ww+2cqfjRdnTOA58Sy8iMb+jOZdjf+SzrkrjkBHZwQnwKCpNkVxgIuiTmmHdCVPj6ZpaJqI8Qkyiefh3faR5k3//d4qEgDcFp X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4806 Archived-At: Subject: [Secdispatch] Call for agenda items at IETF107 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 08:47:05 -0000 --_000_6D7F681C435A4361B3C05197BF444F27ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNlY0Rpc3BhdGNoIHdpbGwgbWVldCBhdCBJRVRGMTA3LiAgTm93IGl04oCZcyB0aGUg dGltZSB0byBzdGFydCBwcmVwYXJpbmcgdGhlIGRpc2N1c3Npb24gdG8gbWFrZSB0aGUgYmVzdCB1 c2Ugb2Ygb3VyIHZhbHVhYmxlIGZhY2UtdG8tZmFjZSB0aW1lLiBQbGVhc2UgY29uc2lkZXIgc3Rh cnRpbmcgb3IgcGlja2luZyB1cCBtYWlsIGRpc2N1c3Npb24gb24gdG9waWNzIHlvdeKAmWQgbGlr ZSB0byBicmluZyB1cC4NCg0KSWYgeW91IHdvdWxkIGxpa2UgdGltZSBvbiB0aGUgYWdlbmRhLCBz ZW5kIHlvdXIgcmVxdWVzdCB0byB0aGUgbWFpbGluZyBsaXN0LiAgSGVscGZ1bCBpdGVtcyB0byBp bmNsdWRlIGluIHlvdXIgcmVxdWVzdCAoaWYga25vd24vYXBwbGljYWJsZSkgYXJlOg0KDQooMSkg cG9pbnRlcnMgdG8gYSBkcmFmdChzKQ0KKDIpIHBvaW50ZXJzIHRvIG9uZ29pbmcvcHJpb3IgZGlz Y3Vzc2lvbnMNCigzKSBwb2ludGVycyB0byBpbXBsZW1lbnRhdGlvbnMNCig0KSBwb2ludGVycyB0 byBhbnkgb3RoZXIgYmFja2dyb3VuZCBtYXRlcmlhbHMNCig1KSBzdW1tYXJpemluZyBwcmlvciBl bmdhZ2VtZW50IHdpdGggZXhpc3RpbmcgV0dzDQooNikgc3VtbWFyaXppbmcgd2hvIHdvdWxkIHdh bnQgdG8gYWR2YW5jZSB0aGlzIHdvcmsNCig3KSBkZXNpcmVkIG5leHQgc3RlcHMNCg0KSWYgbmVl ZGVkLCBwcmVjZWRlbmNlIGluIHRoZSBtZWV0aW5nIHdpbGwgYmUgZ2l2ZW4gdG8gZG9jdW1lbnRz IHRoYXQgaGF2ZSBkZW1vbnN0cmF0ZWQgaW50ZXJlc3QgaW4gdGhlIGZvcm0gb2YgYWN0aXZlIGRy YWZ0cyBhbmQgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24uDQoNCklmIHlvdSBoYXZlIHF1ZXN0aW9u cywgcGxlYXNlIHJlYWNoIG91dCB0byB0aGUgY28tY2hhaXJzLg0KDQpGcmFuY2VzY2ENCg== --_000_6D7F681C435A4361B3C05197BF444F27ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <35E86AFA3DF28341BFFE8C74CCE25C72@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1H QiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+U2VjRGlzcGF0Y2ggd2lsbCBtZWV0IGF0IElFVEYxMDcuICZuYnNwO05vdyBp dOKAmXMgdGhlIHRpbWUgdG8gc3RhcnQgcHJlcGFyaW5nIHRoZSBkaXNjdXNzaW9uIHRvIG1ha2Ug dGhlIGJlc3QgdXNlIG9mIG91ciB2YWx1YWJsZSBmYWNlLXRvLWZhY2UgdGltZS4gUGxlYXNlIGNv bnNpZGVyIHN0YXJ0aW5nIG9yIHBpY2tpbmcgdXAgbWFpbCBkaXNjdXNzaW9uIG9uIHRvcGljcw0K IHlvdeKAmWQgbGlrZSB0byBicmluZyB1cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPklmIHlvdSB3b3VsZCBsaWtlIHRpbWUgb24gdGhlIGFnZW5kYSwgc2VuZCB5 b3VyIHJlcXVlc3QgdG8gdGhlIG1haWxpbmcgbGlzdC4mbmJzcDsgSGVscGZ1bCBpdGVtcyB0byBp bmNsdWRlIGluIHlvdXIgcmVxdWVzdCAoaWYga25vd24vYXBwbGljYWJsZSkgYXJlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDEpIHBvaW50ZXJzIHRvIGEgZHJh ZnQocyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDIpIHBvaW50ZXJzIHRvIG9uZ29pbmcvcHJpb3IgZGlz Y3Vzc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDMpIHBvaW50ZXJzIHRvIGltcGxlbWVudGF0aW9u czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4oNCkgcG9pbnRlcnMgdG8gYW55IG90aGVyIGJhY2tncm91bmQg bWF0ZXJpYWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPig1KSBzdW1tYXJpemluZyBwcmlvciBlbmdhZ2Vt ZW50IHdpdGggZXhpc3RpbmcgV0dzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPig2KSBzdW1tYXJpemluZyB3 aG8gd291bGQgd2FudCB0byBhZHZhbmNlIHRoaXMgd29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4oNykg ZGVzaXJlZCBuZXh0IHN0ZXBzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5JZiBuZWVkZWQsIHByZWNlZGVuY2UgaW4gdGhlIG1lZXRpbmcgd2lsbCBiZSBnaXZlbiB0 byBkb2N1bWVudHMgdGhhdCBoYXZlIGRlbW9uc3RyYXRlZCBpbnRlcmVzdCBpbiB0aGUgZm9ybSBv ZiBhY3RpdmUgZHJhZnRzIGFuZCBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHlvdSBoYXZlIHF1ZXN0aW9ucywgcGxl YXNlIHJlYWNoIG91dCB0byB0aGUgY28tY2hhaXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6D7F681C435A4361B3C05197BF444F27ericssoncom_-- From nobody Thu Feb 20 06:14:49 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE241208A1 for ; Thu, 20 Feb 2020 06:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Tp3cdtItJITQ for ; Thu, 20 Feb 2020 06:14:41 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (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 5A2621208AA for ; Thu, 20 Feb 2020 06:14:40 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id EAC9C2E4CAE6 for ; Thu, 20 Feb 2020 15:14:36 +0100 (CET) Received: from s498.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id CC4E42E284E8 for ; Thu, 20 Feb 2020 15:14:36 +0100 (CET) Received: from s473.loopia.se (unknown [172.22.191.6]) by s498.loopia.se (Postfix) with ESMTP id C85FB47085A for ; Thu, 20 Feb 2020 15:14:36 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s645.loopia.se ([172.22.191.5]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with LMTP id hCLlGjnc483v for ; Thu, 20 Feb 2020 15:14:36 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s645.loopia.se (Postfix) with ESMTPSA id 05BD5156E555 for ; Thu, 20 Feb 2020 15:14:35 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Thu, 20 Feb 2020 15:14:35 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3665056476_439323597" Archived-At: Subject: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 14:14:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3665056476_439323597 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable All, =20 I would like to request a timeslot at secdispatch at the next IETF meeting = in Vancouver. =20 I would like to present the Signature Validation Token (SVT) effort as a po= tential standardization work within the IETF. =20 Current specifications for SVT are developed on GitHub as part of a Swedish= Government Funded project to address the need to validate signed document i= n a distant future. Current specifications are found here: https://docs.swedenconnect.se/techni= cal-framework/index.html#sigval The main document contains some more rationale for the work. =20 There specifications are supported by running code and by September 2020 we= will provide a complete implementation as free open source code. =20 What=E2=80=99s new with SVT and why would the IETF be interested in this? =20 SVT address the problem of signature validation in the future. Even a dista= nt future. This is currently an increasing real problem for which no standar= dization body has presented a good solution yet. =20 All previous attempts to address long term validation of electronically sig= ned documents provide very complex solutions, such as the ETSI AdES profiles= . The basic approach has been to collect data and time stamps necessary to cr= eate a virtual =E2=80=9Ctime machine=E2=80=9D that can bring the verifier to a point in = time in the past when the document was fresh and the signing certificate was= valid and unrevoked. The problem with this approach is that it creates exponential complexity ov= er time to a point where the complexity destroys any reasonable chance to su= cceed to prove the validity. =20 The SVT is an extremely simple counterproposal with none of the complexity = of the traditional solutions. =20 The idea is simple: Instead of providing tons of data making it possible to= validate the original signature and signing certificate, provide one simple= signed statement from a validation service that validated the documents whe= n it was fresh. This is captured in the Signature Validation Token (SVT). The SVT can be si= gned by a really secure signature and will have the data necessary to valida= te all claims of the original signature without relying on the original algo= rithms, etc. =20 The interesting aspect of this approach is that the complexity is reduced t= o a small fraction of the traditional long-term-validation approaches tried = before. A single token with a few KB of data, protected by just 1 signature = is all you need. =20 The IETF could be interested for a number of reasons: =20 IETF has done similar work in the past (LTANS and their evidence records) The token format is based on JWT from IETF The token could be used with IETF signature formats such as CMS and JOSE The proposed format is very simple and would not consume too much work (The= re is a lot of value with limited effort) No other standardization organization is doing anything in conflict with th= is effort =20 I=E2=80=99m kind of expecting a lot of negative opinions due to the subject itsel= f, but even if rejected, it would be valuable to get input from the IETF. We are doing this project as research to gain experience and to evaluate if= our claims are true and that it can fulfill all necessary legal requirement= s. If this succeeds, it may have a large impact on the use and cost of electro= nic records in digital archives. =20 Best regards =20 Stefan Santesson =20 --B_3665056476_439323597 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

All= ,

 

I would like to request a timeslot at secdispatch at the next I= ETF meeting in Vancouver.=

 

=

I would like to present the Signature Validation Token (SVT) effo= rt as a potential standardization work within the IETF.

 

Current specifications for SVT are = developed on GitHub as part of a Swedish Government Funded project to addres= s the need to validate signed document in a distant future.

Current specifications are = found here: https://docs.swedenconnect.se/technical-framework/index.html#sig= val

The main document contains some more rationale for the work.=

 

There specific= ations are supported by running code and by September 2020 we will provide a= complete implementation as free open source code.

 

<= b>What=E2=80=99s new with SVT and why would t= he IETF be interested in this?

 

SVT address the problem of signature validat= ion in the future. Even a distant future. This is currently an increasing re= al problem for which no standardization body has presented a good solution y= et.

 

All previous attempts to address long term validation of electronically sig= ned documents provide very complex solutions, such as the ETSI AdES profiles= .

The basic approach has been to collect data and time stamps necessary to = create a virtual =E2=80=9Ctime machine=E2=80=9D that can bring the verifier to a point i= n time in the past when the document was fresh and the signing certificate w= as valid and unrevoked.

The problem with this approach is that it creates exponential c= omplexity over time to a point where the complexity destroys any reasonable = chance to succeed to prove the validity.

 

The SVT is an extremely simple counterproposal wit= h none of the complexity of the traditional solutions.

=

 

The idea is = simple: Instead of providing tons of data making it possible to validate the= original signature and signing certificate, provide one simple signed state= ment from a validation service that validated the documents when it was fres= h.

This is captured in the Signature Validation Token (SVT). The SVT can be= signed by a really secure signature and will have the data necessary to val= idate all claims of the original signature without relying on the original a= lgorithms, etc.

  

The interesting aspect o= f this approach is that the complexity is reduced to a small fraction of the= traditional long-term-validation approaches tried before. A single token wi= th a few KB of data, protected by just 1 signature is all you need.

 

The IETF could be inter= ested for a number of reasons:

 

  • IETF has done simila= r work in the past (LTANS and their evidence records)
  • The token format is based on JWT from IETF
  • The token could be used with = IETF signature formats such as CMS and JOSE
  • No other standardization organization is = doing anything in conflict with this effort

 

I=E2=80=99m kind of expecting = a lot of negative opinions due to the subject itself, but even if rejected, = it would be valuable to get input from the IETF.

We are doing this project = as research to gain experience and to evaluate if our claims are true and th= at it can fulfill all necessary legal requirements.

If this succeeds, it ma= y have a large impact on the use and cost of electronic records in digital a= rchives.

 

Best regards=

 

Stefan Santesson

&= nbsp;

--B_3665056476_439323597-- From nobody Tue Feb 25 17:24:57 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923AE3A07BC for ; Tue, 25 Feb 2020 17:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QQSa6QcN3uCh for ; Tue, 25 Feb 2020 17:24:53 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B4C5C3A07BB for ; Tue, 25 Feb 2020 17:24:50 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01Q1OdSR007044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Feb 2020 20:24:41 -0500 Date: Tue, 25 Feb 2020 17:24:38 -0800 From: Benjamin Kaduk To: Stefan Santesson Cc: secdispatch@ietf.org Message-ID: <20200226012438.GM56312@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 01:24:56 -0000 On Thu, Feb 20, 2020 at 03:14:35PM +0100, Stefan Santesson wrote: > All, > > > > I would like to request a timeslot at secdispatch at the next IETF meeting in Vancouver. > > > > I would like to present the Signature Validation Token (SVT) effort as a potential standardization work within the IETF. > > > > Current specifications for SVT are developed on GitHub as part of a Swedish Government Funded project to address the need to validate signed document in a distant future. > > Current specifications are found here: https://docs.swedenconnect.se/technical-framework/index.html#sigval > > The main document contains some more rationale for the work. > > > > There specifications are supported by running code and by September 2020 we will provide a complete implementation as free open source code. > > > > What’s new with SVT and why would the IETF be interested in this? > > > > SVT address the problem of signature validation in the future. Even a distant future. This is currently an increasing real problem for which no standardization body has presented a good solution yet. > > > > All previous attempts to address long term validation of electronically signed documents provide very complex solutions, such as the ETSI AdES profiles.. > > The basic approach has been to collect data and time stamps necessary to create a virtual “time machine” that can bring the verifier to a point in time in the past when the document was fresh and the signing certificate was valid and unrevoked. > > The problem with this approach is that it creates exponential complexity over time to a point where the complexity destroys any reasonable chance to succeed to prove the validity. > > > > The SVT is an extremely simple counterproposal with none of the complexity of the traditional solutions. > > > > The idea is simple: Instead of providing tons of data making it possible to validate the original signature and signing certificate, provide one simple signed statement from a validation service that validated the documents when it was fresh. > > This is captured in the Signature Validation Token (SVT). The SVT can be signed by a really secure signature and will have the data necessary to validate all claims of the original signature without relying on the original algorithms, etc. Are there any technical mechanisms (e.g., blockchain with periodic timestamps) to mitigate the requirement to trust the validation/re-signing service? There are probably some solution sketches in the list archives here or on saag ("merkle tree" might be a good search term). -Ben > > > The interesting aspect of this approach is that the complexity is reduced to a small fraction of the traditional long-term-validation approaches tried before. A single token with a few KB of data, protected by just 1 signature is all you need. > > > > The IETF could be interested for a number of reasons: > > > IETF has done similar work in the past (LTANS and their evidence records) > The token format is based on JWT from IETF > The token could be used with IETF signature formats such as CMS and JOSE > The proposed format is very simple and would not consume too much work (There is a lot of value with limited effort) > No other standardization organization is doing anything in conflict with this effort > > > I’m kind of expecting a lot of negative opinions due to the subject itself, but even if rejected, it would be valuable to get input from the IETF. > > We are doing this project as research to gain experience and to evaluate if our claims are true and that it can fulfill all necessary legal requirements. > > If this succeeds, it may have a large impact on the use and cost of electronic records in digital archives. > > > > Best regards > > > > Stefan Santesson > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Wed Feb 26 02:12:03 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8923A1218 for ; Wed, 26 Feb 2020 02:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lh9RBKbljjbT for ; Wed, 26 Feb 2020 02:12:00 -0800 (PST) Received: from smtp2.outgoing.loopia.se (smtp2.outgoing.loopia.se [93.188.3.37]) (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 D2F2E3A1217 for ; Wed, 26 Feb 2020 02:11:59 -0800 (PST) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 4A91F2E7B598 for ; Wed, 26 Feb 2020 11:11:54 +0100 (CET) Received: from s499.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 2C1542E27BC2; Wed, 26 Feb 2020 11:11:54 +0100 (CET) Received: from s470.loopia.se (unknown [172.22.191.6]) by s499.loopia.se (Postfix) with ESMTP id 2580A1CDAF0F; Wed, 26 Feb 2020 11:11:54 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.6]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id VloNa0TZP148; Wed, 26 Feb 2020 11:11:53 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id 9F83C1CDAF09; Wed, 26 Feb 2020 11:11:53 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Wed, 26 Feb 2020 11:11:52 +0100 From: Stefan Santesson To: Benjamin Kaduk CC: Message-ID: Thread-Topic: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF References: <20200226012438.GM56312@kduck.mit.edu> In-Reply-To: <20200226012438.GM56312@kduck.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 10:12:02 -0000 Hi, Great question! We have not yet identified any reason to create any mechanisms within the p= resent specification even though we recognize that this concept could be sup= ported by external mechanisms such as block chaining and hash trees etc. However. I'm more than willing to discuss whether anything should be added = to the specifications. The basic claim and idea is that storing a claim from a trusted authority t= hat a particular certificate was valid at a certain point in time is no diff= erent from storing a claim that the whole signature was valid at a certain p= oint in time. This change of how things are done (from the former to the latter) do howev= er have an extreme positive effect on the simplicity of the solution. This is the only parameter that is fixed. Everything else can be discussed. Stefan Santesson=20 =EF=BB=BFOn 2020-02-26, 02:25, "Secdispatch on behalf of Benjamin Kaduk" wrote: =20 Are there any technical mechanisms (e.g., blockchain with periodic timestamps) to mitigate the requirement to trust the validation/re-sign= ing service? There are probably some solution sketches in the list archive= s here or on saag ("merkle tree" might be a good search term). =20 -Ben =20 =20 =20 =20 From nobody Fri Feb 28 14:37:19 2020 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C073A1F3D; Fri, 28 Feb 2020 14:35:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: secdispatch@ietf.org, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931033.19931.14231709127244638142@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:10 -0800 Archived-At: Subject: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 107 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:17 -0000 Dear Francesca Palombini, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secdispatch Session 1 (2:00 requested) Monday, 23 March 2020, Afternoon Session II 1550-1750 Room Name: Plaza B/C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/secdispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: saag dispatch ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secevent suit teep tls tokbind trans cbor core gendispatch Technology Overlap: httpbis People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. Please schedule for a session of at least 2h. ---------------------------------------------------------