Re: [lamps] Double signatures

Massimiliano Pala <m.pala@cablelabs.com> Wed, 12 September 2018 21:01 UTC

Return-Path: <M.Pala@cablelabs.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3B2130DD5 for <spasm@ietfa.amsl.com>; Wed, 12 Sep 2018 14:01:44 -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, 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=cablelabs.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 ohauAqjsqFCw for <spasm@ietfa.amsl.com>; Wed, 12 Sep 2018 14:01:38 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0094.outbound.protection.outlook.com [104.47.40.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A2A130EA9 for <spasm@ietf.org>; Wed, 12 Sep 2018 14:01:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EqGL1dsyM0osvIBhKjk7xdxl7haKHiTDs6ozqMW0gtg=; b=fmc8cRZYfod2xAUnLKyzLh71szis/YDhcMjvjvPevbnIuWly4ELHUrp2cUcouy8GL427i1320Wyll5o2dgMH4svvscgb4hv099ZK0L4gYxBXukQfQIaWNCmy6JROLkFnzBnjJTiY2VtCH04ulU1k7x5kNUd7U0X+py3buMNSgbw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=M.Pala@cablelabs.com;
Received: from Maxs-MacBook-Pro.local (192.160.73.16) by SN6PR06MB3886.namprd06.prod.outlook.com (2603:10b6:805:1c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.17; Wed, 12 Sep 2018 21:01:32 +0000
To: Russ Housley <housley@vigilsec.com>
Cc: SPASM <spasm@ietf.org>, Erik Andersen <era@x500.eu>
References: <005a01d44916$7c9cb560$75d62020$@x500.eu> <CAErg=HHhU9H-Ng8sUtXu2S+F0fr2tLOX6=8UR77gz0YLqtGyaA@mail.gmail.com> <004a01d44928$b1500d40$13f027c0$@augustcellars.com> <04ce01d4492a$39400ce0$abc026a0$@gmail.com> <003601d4499e$7c8be3b0$75a3ab10$@x500.eu> <BN6PR14MB110623B94ED97509FAE9F71283040@BN6PR14MB1106.namprd14.prod.outlook.com> <087c01d449db$c78e6350$56ab29f0$@gmail.com> <BN6PR14MB1106DBDE49673AED8E6C937383040@BN6PR14MB1106.namprd14.prod.outlook.com> <9A1A8BFC-9670-42EA-8D8D-B3DC2494CB95@cablelabs.com> <798ACAFB-7417-42F5-BF1C-6C0765606AC0@vigilsec.com>
From: Massimiliano Pala <m.pala@cablelabs.com>
Openpgp: preference=signencrypt
Autocrypt: addr=m.pala@cablelabs.com; prefer-encrypt=mutual; keydata= xsFNBFpzbjkBEADcaK4LIm2K+btBx3RBL1mbxkiXd2lY6B0aUiliykcth1WlbajO5JpI2DjA xacE3ynOeQslva3Y2WoBSMEcTqF4d+c09Uw/+GqtKQvSO6rPvuyT1/4ibeipUQhBD4SAWDii HAJS30jtFWPqWLMyjemFROxJnJAHf8rvMppq1ZinCRADFvuTUipV5OzD4KThH63bRsmH/yfh nPfaGDGcIkhX1K8ooXhjQuCoARMPCz7KWjjqdabxY+kdB9JkZxTMezcWUphNoXqrvvUo2igp RXpF40QDbJVC+5c5VEA7C6VfWSJuTeS2YmiahLdUDvz8R/VRoi0eQcQP4hugECUcb+T/+r9R dNcVnOl4Wv4ZDvGWmaiNupm3L4T3RmODfvdeNlAfdpFUhr6+phBqUYXeI3WmeHAj3Da0t+Lj eUemMGPkxlxuH6npbUYP2KngA8yYKZw6h48POzriF19U+QfrIeJxLfH9Bpe82OeG6W9srEVb UedG/0I1depD6EHb415ap5dktYlgQvp0tpI4p4XYf8HQJ4I0lCEPsKpG8hfrFppSS8EpskEC hIXJjwaTlI7ve5mMLEiVp60h48/sCAvBhx6AEHZt+UEX8FND2FO8+g8qB9mSgv+S3/4D7TCw FtWu6fV91StDtEW9sw7nr08gra2jz9Xd/Ept7et9xyb/LBmTMwARAQABzShNYXNzaW1pbGlh bm8gUGFsYSA8bS5wYWxhQGNhYmxlbGFicy5jb20+wsGUBBMBCAA+FiEE7tpc4hFswtYW7GFR QznkRk1SfM8FAlpzbjkCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQQznk Rk1SfM87IA/9GeQoGwHvPi4wVK92jbQlVF91UTks8rSlP8VBkuMAqYKJ7Ex08E6uav3+rnw3 AnM3YMvSVQWefD2O1sdSr4p9ZqqYVz15FR1N0pfbnfKu6QoXkPKdeh8Lsg5ZPIo5Kgf+Ijvg YCoCYv8OGKsr5/pS5W3DHrRWo37JgecQPVS0mBnmmYVXmVO/OudEUQvjGiaKx/AkmBSRq4se 6D+q8sfNtInUOmFVT6dV04v7qZn3fq8UqiOlxBRjxJ/SJfPUXbqMAS8vJgmtNiSHQCwQ5xOy PyAMfBYLUgbUAQNNVBJjtBSd+6eAvUuHmC/P8lvQzT+n4gQ/WA21xF5trXksOE+eEuED4Y9B dS5XdSkikMBJy7JNxzdceLGevPXObe/4lt9mTxUCG3/7g+UMH0HPgsShHBycDEmrY4x05g5H D0c+qvTBNTk2NjjU8ZPjWRPfEqB+w85thbFeEB1PUk8hK4A+YzFbwm3ixJGEI4Jcep3WvK3Q ua3DOcprbFzFeoc9kjdXyQaciR3i/I6tvYcPfSImCajndaeDyIKOb1xAhd6nw8vds4GByXCT /VzWiUlKYGIem8CVYWfageTugxSSDtkpDGn+xCYwJKXkU6uRUpMxtdMQ4go76PHzJqWm+p3D Q11LV2tBxOyYA6TrnxAgFehc/BiejJZowUUerWJ627PCXWvOwU0EWnNuOQEQANLmB7iOz1ol CR5FRU8v/beWcJqymqKDEAoJQ7u0FsHsjvfQmdc0kZs/JxB5OG3Qvg1RknOy64g1+BYJ3+uT gBNH95Q9W1iVtdfyNiH/4LjNSZN4qH8rJ+nft/nm3ixWkYfw2jRssXpCZ4kSVplSURZuYIk5 f9LYey0BH2Tvo69tCPD/qhtzcppD5nCk8Wxxi2CU05de1nok4Jmk1XTMNHdHfOzqWJUXVU0T aUKjJICbIaEsid5rUZZbSJHk5x0ewI4++xWyBHFWpgtqiaD4aDY+WDcT+zBcoxMvYokC4T28 SrRL0RaQHH7VKB1dEwULGQt4r4lA+u8psxUB497LxYkRX/DLzcDX9w410VAQWG2Li9yDIAUD O1EVoJzU5xvGBmRYJuycJ9drUduhlu/Uqr5rT515S4ysO8DlpIpDhhslF9MVwr6nUbCBWAUm +qSTRpoBPnvY8wN8kmQ1vu+xpMybBsMrVB73PKZs1w5qB7G6YZcFwY+22dXPpp2jg58rozz0 BAq7YhRHuTzKQwlJVN0q28RCZamTnYucdotJ/51fST3XokdTcUj/JzdyWTWKJHVRtWhxgxem izomaDC7AFN/EXEVopRbwaIKGs9Vft0Ufr7j1HnDSIUZjQkO1bIXNhhJQYLgxc51MAZFzbPb M21y8h4tSlRb3f5lHcKp0tpFABEBAAHCwXwEGAEIACYWIQTu2lziEWzC1hbsYVFDOeRGTVJ8 zwUCWnNuOQIbDAUJCWYBgAAKCRBDOeRGTVJ8z9BYD/4lTTc5YXbMzSTOtkfhdYO2MYNv2QfU FTN1af0JjcReNZm4T1aGFijsy5xM31P/Wqnq9T+H+AnPQ9er22gtyw3dcUvQ/x+16i0utzsd zQJNTPty5K22cUrGBOQvaOdc8uSYPC94VYTFCQ9lMmPWMZKcAgwE03YzzAeks06QHJHIUbv0 /iabu6VO2emNvnCVuNbrbzMGpYihlvKJS+H+QcQueZ6CU+YypS/yyf3FHnp1xPJmRWtYc7vh 7VpIPSQYReeQ0eZwZvRxuCUjg5td7qqBz7AKw3PxQu1wnn/3mO+ofy3tfotbEm2kRDt9G/gq 4Qn7GwvDLPzDEdF/dPBOMxNFhr4vmJ36AwgkOajw97Lie2Q+P9r5/rwhgbFTjc5Bm4Kr5SPn 3Q3td2frq4tF0E/6R71SiLoGhZKt2QPjp7zv30Ogzy0FkAsCsjFo6hy3XmRd+/NY0Ye1auQJ YZtGgM5YDaj87iqj/7tKrcwGtMSuXK+bvsni3FB4zJShiQicqYifSCnXeRk4CSM/U8bW4JZO GBIduSJ9In2mx/e0m2YAT+kuprqQcFL60i6qaTi9dLm3Qu40+kgLu39/O9D0b5biuvzxIIsd +O+s8s6OVH+XCG5DSX6b9jRrKb/62JD1O2wOAuA/zmGfNXrEgSDiUBLMkD0UUTyjkrWRVrWn PZ7WIw==
Organization: CableLabs
Message-ID: <af01c991-c052-37a8-a14e-aa432f05470d@cablelabs.com>
Date: Wed, 12 Sep 2018 15:01:25 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <798ACAFB-7417-42F5-BF1C-6C0765606AC0@vigilsec.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030502080809000507070707"
X-Originating-IP: [192.160.73.16]
X-ClientProxiedBy: MWHPR20CA0040.namprd20.prod.outlook.com (2603:10b6:300:ed::26) To SN6PR06MB3886.namprd06.prod.outlook.com (2603:10b6:805:1c::31)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 02340667-eedb-446f-299b-08d618f2ec2b
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:SN6PR06MB3886;
X-Microsoft-Exchange-Diagnostics: 1; SN6PR06MB3886; 3:sVHFnn8aUod4OMBDKxpOfSnXpvfWrRgMIRokdUJKSe4u8FiQvhD+7uWrBe3VSfYPzgwww3szbqSb0EeKmU46y946c+QraQAWYvMVTXgzvcaTeoXl1ZXx12uqLnSmbDLpTzEicQ2ZNvbvljrIXGKSfzhtqOgLQqR3n5dL9TQ292hlwJGrQG7qrGQi1pY0ONtvWGIcdLro4cjCzMKI3mSh3c6tkHgygnxKNs8avlYmc3n2maNHbvS5BK88x4z/o8uc; 25:Fv2xurgzgp/W/9vemXS54yxc/GgQHbPu+mHbeHx1SOxQ4EaUxajl8mozGreAUx9QAt0w1ti50TyzcwgbEQjHro11J1R7QaMLv97fk1H+AeNTX35ic8NGj1c8zGA16h97YNVbV4HwPUD4IsW8DlKwvtctZodWnV2ySEGCv/L0TjVJfXhmaceYaSsjK4V8nXHCHLBYrynFTVCk9g+uN/0mFGKV6JzahMFBqdyB1Wv0H+wJ9dOKZR3ej+DC7s6gknwr27ljemxdJxaUeUqhYDMJV58bR4HcevvRFtmLitlkSApycDT+Rl9iSx2RvBvF8X+NATB8ybpFCztQkuG92UL3ew==; 31:7LRMPy5x1Vo7VJFmJXqc6CLNakLp65m/o/Alem1McK4KHaJmc3vYB4WUgREN3ayg7zO7xmEde26uc3C6QgdecP+HcWq6hvPFcFTJB8W+W2ioBTjKey3onZWNt/t5qAO8Iu+Pl1TYPj+XJLwilksq941XFrQqV1iNMRq/4h2wnDutCvD0ez6j4kP69NUvYXI11Bk+E4V/yZaBdmpt3LtHbn2HxaGAo4OrhVXZnTKxTLY=
X-MS-TrafficTypeDiagnostic: SN6PR06MB3886:
X-Microsoft-Exchange-Diagnostics: 1; SN6PR06MB3886; 20:HBOJzKuyjMu5CSloHHK/v02FBFNR8nR5ZGbikxXKcrdf4vsH7iuCSlX9Mq0E4hku2xKpcnLXXO3f+NQ1w/Se1X6peJw8PDw5Qg03631prFeh6Cuufm0M4Sm1S4CSooPYnauos48qW08F5g1MpYv4Ou/ZlC8wnalyWSFHvdWveCQ9U8yQipBlmTHkQ0Gl2rapKhkypmahLeKG71nKesCyhUlCvt7xBc1fjpbnbaX3ZF3PPm/db7jt/nYEfmgV8shZrTfwfVfAknXD8ADBifHVitD++V78iHluPH+TErNf6Ig1iY+zLNY8Xto05AbR5JTnzlxgKr/RpKor4MF2yhzrXBcPLtLIeceCKs7fzhUv/6adTojtSgO5sLIs18Tud641FRiTkGRR4fMZkTMGki0DJ/oRzX+hAw/HKmGjzBhDjcul1/JH11/jSbebJpYYgS2/l10NTvSCPD8RGYznzEzpqWfXHNYAvZfE4jZGbbuJ6CRNMVkaCMh9dc2WfyNLMvgJ; 4:zgxB/Y1JaOOxsg9xsVfOAwFujWQbn7bSM9WQAQ24jEUfibcj2BlQvHRwB/luNiNvMZslWxZcIHtlYtpzDAEgbRytyX0oprOJy9UROVU+ENVlaLko4akos3T6ADqa2wBREhyW0LXugy8yH2GwZYgykyARnMnHfBK6uyqAGe5bzk7Xz0nVIzzzv94GSFmLf05FYWCKgV1V5ryCC9lydkNKLTnt5r5QlV/nLQ0xZ8Pr0iQQcqgyAB+odElS31j2/0qHmQFUXvHQa5xt9QG9PvRr9a87rQVMmFXfS3wy/c1XkuXx3y573baLRQTXiC1LqElJaRIEdOA80PtyH1Nz7DtiC6DO9rDkvQcEiNmAo6Nrh4rNJXox4QRecSnK3A7mgHY2
X-Microsoft-Antispam-PRVS: <SN6PR06MB388664F5A75645B2298DDC779F1B0@SN6PR06MB3886.namprd06.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705)(85827821059158);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699050); SRVR:SN6PR06MB3886; BCL:0; PCL:0; RULEID:; SRVR:SN6PR06MB3886;
X-Forefront-PRVS: 07935ACF08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39850400004)(136003)(189003)(199004)(51444003)(53754006)(97736004)(16526019)(76176011)(6486002)(36916002)(33964004)(81156014)(966005)(478600001)(72206003)(52116002)(316002)(58126008)(8936002)(16586007)(68736007)(81166006)(54906003)(53936002)(236005)(54896002)(6306002)(54556002)(31686004)(66066001)(65806001)(106356001)(16200700003)(65956001)(53946003)(84326002)(6512007)(105586002)(6916009)(561944003)(26005)(6666003)(36756003)(733005)(2616005)(476003)(8676002)(956004)(486006)(25786009)(4326008)(31696002)(6246003)(86362001)(186003)(11346002)(2906002)(65826007)(5024004)(14444005)(3846002)(606006)(6116002)(5660300001)(446003)(7736002)(53546011)(6506007)(229853002)(93886005)(386003)(64126003)(568964002)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR06MB3886; H:Maxs-MacBook-Pro.local; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
Received-SPF: None (protection.outlook.com: cablelabs.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR06MB3886; 23:2yuQMQp9wiB6AHuVT13+UgPVzrLUgRdBm4XlHloe9?= =?us-ascii?Q?kStZyfxt38E65I1rHVuEV+r+PYicC9Q1c6z2c/kgTLz74WSi0fvR5nGNUl9v?= =?us-ascii?Q?wikHf7mmAHPj7dHTqo3qMNUY3eKMRkNknSYWn4R6/f5cyXerAKe4r/3Pp164?= =?us-ascii?Q?loUX9MfBeAl4NP8IF949hyuq9vjHrVaIGiiF0YZ95OsZ4bDxz/5o1Ppg9szf?= =?us-ascii?Q?FHIZ+wwrRMx0Mk2nEfHxyleIKaZgcSNopRrUHtSYlIG3smiIbgPm7aEQt2+A?= =?us-ascii?Q?+KEUwGOMzgFxPuOqRgr+SyiokJx3vJG1qo/BKMUPepRvsOtm4ovFUkgu9+Ql?= =?us-ascii?Q?R6QiJqcXhhxdO8G0R+whH59gw5e7SvqUY2v6D07EHZ7R/aAVIXurQrkLtDi8?= =?us-ascii?Q?znGiT+vt8WX2D5/R3WPo+d67WG+5J8KLgnUYWOWZ4X/bVbg2CvJRVDBrs969?= =?us-ascii?Q?+dsChE7dx9/k2zt7O7T5245Rl7wdnoLRYwBzx+c4sJsEdO6p8JY26ExDHEhG?= =?us-ascii?Q?RSX26Mca+MrMIrjapDknGlwtf3LyvXMyEb/Ns/eHYmHRi03i1hOS/GfgNN4f?= =?us-ascii?Q?3RNmrZwvsT7ejYlKfapB4N15VyRT4Lqux+O5Q6SzRW1T+kHlX7/j/zx9eA1D?= =?us-ascii?Q?W8GczkkARzJ5WVgHWSY7mCSEv6sY/5QPQFY6zQa3FBf6jhbO31Uwh86uU+mh?= =?us-ascii?Q?aPzDO4NqOvurveypd9iRSLiJFCCr/WAQYNWb51wWkNPb+OdoKJhzpcx7oF7n?= =?us-ascii?Q?fmKHoLLTQTIZFY0VQ5rQWfZrjbMYZDkeI4vcNnMhYSPspxZ0EQwgCcZZS9tI?= =?us-ascii?Q?p2f4xXuM+7oB8VvbWp43GxAjmzuH4YSaqI5BSWyGvgqz6dYPvACFUVjwatQP?= =?us-ascii?Q?frBgLSwOY+t4YaKlna5j8qwnQmGG9yA7lRwwRrWPxh7lfO7nlsYbqH3Q5yGt?= =?us-ascii?Q?TyFxaGfsOgyWPewc2rZhE0drmadS0LqD4VJxoSTDj2C6i2lrHqrm1WJtoyOZ?= =?us-ascii?Q?zL/mhGEczBVh0DApwXK5nFILC8C6uOAI0Zm9ajMW3uOrul7QRxSrqpa/MIBo?= =?us-ascii?Q?CDHbFKaHhoSOBwLLny8VErD/eSlozOUt2kt4t89JsCNbc2cR5lyxki27ysrI?= =?us-ascii?Q?9j9ixcJ3xc+SdkkhuxHmfmHsyqw/qRrARwQzXABgqZnbsZMArPFPzk3Y1T72?= =?us-ascii?Q?gcj1Fts4x0LAVlVoGulp8J/709quefDmbCM7HS3t0AC/cWk5IvH3tGLzOEiR?= =?us-ascii?Q?nhw7YNOvRooMFE9/kI78RD1MBBoiJzWN+Urzc0h1cC7bcan7FAxyogrbWgZr?= =?us-ascii?Q?aTMC6wkEBOe3HL2argqCq+XfwG1maAJwKmGl7xgwtPC+wNPDBo/RGCEl0cDr?= =?us-ascii?Q?A7fTRtM9MF7oJA5DHJRoDBjbnc+oKmm6GlBAL0S+oOTNOZgxlWIHH7GSDHkt?= =?us-ascii?Q?ZKRnfDqZDxnjVyaB6+4e952+TIW2ckyn/iCRK7H1NxIJ4hXjb5IJFMoloxJ1?= =?us-ascii?Q?KWI7THCWaf/MzXPDFg9DtlfL/wpqCH1wfYMdkdxHUwpGkixylP5aQ409QY0W?= =?us-ascii?Q?RlBnhvFGx7jFmXDEQREnDwOEkNTf8LaNdT2Aciko827QG2QwZXpxW39JFQdP?= =?us-ascii?Q?MllacrrtPe1ai/u8J9t2OBPiTtA87Ga/KbQ47jFHki2AVttAS1T4dPe8jwAB?= =?us-ascii?Q?hzYpPA1TIGQlGcRiNl3zFTZi9q4F4QS5pWepIaT0cnKsnY=3D?=
X-Microsoft-Antispam-Message-Info: q1eDFXmMIVbYImFcXyJTlKO/nf9pUQtNNul0ga2DCRCeReUyBwtTjPLgG7NtS53jsSndHNNu6MeE3+PrMMwNzlD0wggTNZQQxhbUs42UFgIpBdEez2bdDJbAQH/21wgtKzYA8HD5p1LrzKzGH4vbWh+Xj7kg27yV6uYgPxT/Tc7VBwjzPth6LQhx+jnL5yUh4mmoAKDxUA7P/U2B8BBgp8CvuDqyXkWnj7I5yomXiokNhDXEoH54KANAVZaJ6V1Ar32aXQcFyQZpBiBo0OLc49DZEhzllCSH0QMGfHXqkYQK0jlWeYO90Ya7eBfdj/CxS9ayBq3Rd+3vOaQDsov+dm/JMMUh/91Zb3un4DXoh+s=
X-Microsoft-Exchange-Diagnostics: 1; SN6PR06MB3886; 6:BpdOvfoEjMRv/nBXDAUiWySAWOA0DuT4bbU55cU59gj9fRzf3+nu4LlhEiOYT40Gs+lVetWOseIA8wUYqggyaTlw+sMfgOY6O9IMDP8hjoObV0296TDJyEtDqhTCyoPSWcbtUuoCjEeJM6wg2wyh4qjgVLc/DVngpi5mv/auCk3oulNlsXasmm1+H1BvGgT/tqlmrWRP8MIldMKnHOBg7/V0ORZreJMEOVEWuhQXuHB873EzmSItPbXdjNV+1I7OC9iIXl0kP9+8bBqepcBzEVa2tO3Xgow1NgphWjvpYXjPPhyFb7AMZ1WFigJCeu3RjZmhJP9Am9wpZwMc6MfiYZ/yc6CHF9hUwG93LLYpkkSzNylVajnmcb/Wz1FwGLNu7HRNzwt96Q5qVwFT019yKo8Krt/5uuhW4hcedKdLH/lsE5BTdx6kc6jCwkdBHOg59OeSJmO1XSFFxo4lw9vRCg==; 5:wxBanq+AvQhzykvkDnGz/yoiKWOCQTPOPp/IV8qAd2qw80V3gFeeynCL9zNrCu+9CaO33uvEHnLxPBEi+2Ql0O0Pqp3afNck/z7rhwCsAP2GgzEKOKDR8n5IHKWGGx1/ndl4Spbvu1yHZfnMxt7+fZ5DJPAF4sPtlhYOGk1g3/c=; 7:LOt4GTsvdL/8lmJs6twqsHHP6VJs9ahz56F98nZFXcT5Fa/+9+61EFdFWrhPzjJEulD7iRgYCIHsK5R4pmX2BcPh6ehPO6EeP/bvi1cCQs5TIrOPy9T+v/pS+BGQkE+1+aQ9gJCZcsjNt9ns+ZIQYblJ7vmhtBxQpJskc393qHSAJXruoJNtRsQexc0mKr/2R85LIFJVVwW9tA5B+a63tcnOWemhDpA06Kej7yp1WNGxtEcilFjORKWAvcQd4L7y
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; SN6PR06MB3886; 20:ChGZ5VDlLV4MggelYwuXzfHJlLSrbs7BjV+CCTKRl593+RgngllydW6eUnsDK7dCe7/+eZ4E3f8E/Q0LsUUPVjcQ61JjxeICgRmiwqjn9sgolLZ5Ny6ONZEz6Qm9TnWA2JwTyKCBva9qmQPitjhwZIbAcMsPcfAysOjaRse7zoA=
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2018 21:01:32.3364 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 02340667-eedb-446f-299b-08d618f2ec2b
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB3886
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/72My-acPcEJkF5VsbnEthjCnJzw>
Subject: Re: [lamps] Double signatures
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2018 21:01:45 -0000

Hi Russ, all,

my personal position is that the signer MUST use all the keys that have
digitalSignature set, the verifier shall verify all the signatures for
which it does have support for.

The rationale for this is that if I certify a public key in the
certificate, you should be able to use the private key to generate the
signature, therefore the approach is the same as usual: sign with your
key. In this case, it just happens that to generate the signature you
have to generate multiple ones and then combine them together.

For the application that verifies those signatures, it is always a
question of what is the threshold that is acceptable for the application
(in terms of risk) in case it does not support all of the algorithms
that are used to generate the composite signature. Ideally it would
verify all, but it may decide to verify less (at least one).

I also saw the other e-mail from Jim on this topic and I think it could
be a good idea - the use of the two OIDs is another way to go to codify
the validation process required. Technically, that makes sense to me,
however I am conflicted as this approach requires that the signer has an
understanding of what the verifier's capabilities are... I think that
defining two OIDs for the signatures could still be useful because the
signer might then decide the "recommended"/"intended" verification
behavior... I can see some use-cases that might have a composite key
with { RSA, EC } and the "Must-Verify-All" OID for the signature, and
another use-case where we have a composite key with { RSA, HASH-BASED }
and for the signature "Must-Verify-At-Least-One".

Does this make sense?

Cheers,
Max


On 9/12/18 6:12 AM, Russ Housley wrote:
> Max:
>
> During a transition to quantum-resistant signatures, a signer wants to
> put a traditional signature and a quantum-resistant signature on an
> object.  Given your description of keyUsage and extendedKeyUsage, both
> would have the digitalSignature bit set.  How does a client know if
> just one or both signatures must be valid?
>
> As Jim Schaad already said, RFC 5752 talks about this issue when a CMS
> SignedData contains more than one SignerInfo.
>
> Russ
>
>
>> On Sep 11, 2018, at 4:45 PM, Max Pala <M.Pala@cablelabs.com
>> <mailto:M.Pala@cablelabs.com>> wrote:
>>
>> Hi All,
>>
>> I am working on a similar - but different - solution, in particular I
>> solve the issue of (a) being able to combine more than one public
>> key, (b) only one (actually two) OIDs required, and (c) simply the
>> processing by re-utilizing the same data structures we have today.
>>
>> I particular, I define a “composite public key” and “composite
>> signature”.
>>
>> The first one encodes in the key value’s BITSTRING the DER value of
>> the SEQUENCE of public keys (each of which is a the
>> subjectPublicKeyInfo structure) and uses a specific OID that
>> identifies the public key type. The parameters of the compositeKey
>> algorithm can be used to encode the keyUsage and the extendedKeyUsage
>> for each of the keys in the composite key.
>>
>> The same approach is used for the “Composite Signature” case where
>> the value of the signature is the DER representation of the SEQUENCE
>> of signatures made with each of the keys.
>>
>> As soon as I have some spare time, I will submit the draft - maybe
>> this could be discussed in Bangkok?
>>
>> This simple idea allows us to have all the other procedures related
>> to PKIs work - this means we can combine ECC with RSA or with a
>> Quantum-Resistant algorithm (when finally available and
>> standardized). A step forward for the deployment of hybrid-PKIs where
>> multiple Lagos for keys can be used to authenticate data, certs,
>> revocation data, etc... we plan to use this in our infrastructures to
>> provide a transitional path for post-Quantum transition and to
>> further improve the algorithm-agility capability of PKIs.
>>
>> What do you think?
>>
>> Cheers,
>> Max
>>
>>
>>
>>
>> ---
>>
>> Cheers,
>> Max
>> On Sep 11, 2018, at 8:38 AM, Tim Hollebeek
>> <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com>> wrote:
>>
>>> Unfortunately, “not every combination needs to be covered”
>>> introduces a lot of politics around choosing which combinations
>>> “need to be covered”, a subject on which inevitably not everyone
>>> agrees.  I would rather avoid all those discussions and the
>>> unnecessary work they represent.
>>>  
>>> I personally don’t think a single AlgID which implies a SEQUENCE of
>>> ALG IDs is an improvement over a SEQUENCE of ALG IDs, or its moral
>>> equivalent.  For simple hybrid use cases, there is also a lot of
>>> value in having the classical algorithm ID being the same as it
>>> usually is, to allow easier interoperability with older systems that
>>> don’t understand the newer algorithms (and can blissfully ignore them).
>>>  
>>> -Tim
>>>  
>>> *From:* Santosh Chokhani <santosh.chokhani@gmail.com
>>> <mailto:santosh.chokhani@gmail.com>> 
>>> *Sent:* Tuesday, September 11, 2018 10:29 AM
>>> *To:* Tim Hollebeek <tim.hollebeek@digicert.com
>>> <mailto:tim.hollebeek@digicert.com>>; 'Erik Andersen' <era@x500.eu
>>> <mailto:era@x500.eu>>; 'SPASM' <spasm@ietf.org
>>> <mailto:spasm@ietf.org>>; x500standard@freelists.org
>>> <mailto:x500standard@freelists.org>
>>> *Subject:* RE: [lamps] Double signatures
>>>  
>>> Thanks Tim.
>>>  
>>> There are ways to accommodate your concern.
>>>  
>>> One way to handle this is defining a single Alg ID A which implies a
>>> SEQUENCE of ALG IDs and define the relying party rules in terms of
>>> its ability to process one or all ALG IDs.
>>>  
>>> Another way to do this is not every combination needs to be covered
>>> and the user community defines its own  Alg ID Xi which maps to a
>>> SEQUENCE of ALG IDs.
>>>  
>>> *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Tim
>>> Hollebeek
>>> *Sent:* Tuesday, September 11, 2018 10:03 AM
>>> *To:* Erik Andersen <era@x500.eu <mailto:era@x500.eu>>; 'SPASM'
>>> <spasm@ietf.org <mailto:spasm@ietf.org>>; x500standard@freelists.org
>>> <mailto:x500standard@freelists.org>
>>> *Subject:* Re: [lamps] Double signatures
>>>  
>>> Doesn’t the combinatoric explosion render this completely impractical?
>>>  
>>> You need N_c x N_pq algorithm identifiers just to handle the simple
>>> hybrid use case where a single classical algorithm is being used in
>>> conjunction with a single post-quantum algorithm.
>>>  
>>> And there are people who want to use multiple post-quantum
>>> algorithms to hedge against potential yet to be discovered
>>> weaknesses in post-quantum algorithms.
>>>  
>>> I’m not really looking forward to trying to allocate or manage O(N_c
>>> x N_pq^3) algorithm identifiers…
>>>  
>>> -Tim
>>>  
>>> *From:* Spasm <spasm-bounces@ietf.org
>>> <mailto:spasm-bounces@ietf.org>> *On Behalf Of *Erik Andersen
>>> *Sent:* Tuesday, September 11, 2018 3:10 AM
>>> *To:* 'SPASM' <spasm@ietf.org
>>> <mailto:spasm@ietf.org>>; x500standard@freelists.org
>>> <mailto:x500standard@freelists.org>
>>> *Subject:* Re: [lamps] Double signatures
>>>  
>>> Hi Santosh,
>>>  
>>> You have proposed something like this before. It still puzzling in
>>> my brain. As I understand, it requires that we define a particular
>>> algorithm that has a parameter that includes the things you suggest.
>>> It is worthy to be analysed.
>>>  
>>> Erik
>>>  
>>> *Fra:* Spasm [mailto:spasm-bounces@ietf.org] *På vegne af *Santosh
>>> Chokhani
>>> *Sendt:* 10 September 2018 19:18
>>> *Til:* 'Jim Schaad' <ietf@augustcellars.com
>>> <mailto:ietf@augustcellars.com>>; 'Ryan Sleevi'
>>> <ryan-ietf@sleevi.com <mailto:ryan-ietf@sleevi.com>>; era@x500.eu
>>> <mailto:era@x500.eu>
>>> *Cc:* 'SPASM' <spasm@ietf.org
>>> <mailto:spasm@ietf.org>>; x500standard@freelists.org
>>> <mailto:x500standard@freelists.org>
>>> *Emne:* Re: [lamps] Double signatures
>>>  
>>> Why not let algorithm identifier dictate the number of signatures
>>> and their syntax?
>>>  
>>> *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Jim Schaad
>>> *Sent:* Monday, September 10, 2018 1:07 PM
>>> *To:* 'Ryan Sleevi' <ryan-ietf@sleevi.com
>>> <mailto:ryan-ietf@sleevi.com>>; era@x500.eu <mailto:era@x500.eu>
>>> *Cc:* 'SPASM' <spasm@ietf.org
>>> <mailto:spasm@ietf.org>>; x500standard@freelists.org
>>> <mailto:x500standard@freelists.org>
>>> *Subject:* Re: [lamps] Double signatures
>>>  
>>> Ryan,
>>>  
>>> The discussion in London dealt with a completely different proposal
>>> than this one.  While I think there are problems with this that need
>>> to be dealt with they are mostly not the same set.
>>>  
>>> Erik,
>>>  
>>> Why is this considered to be a preferred solution to defining a new
>>> signature algorithm which contains as the parameter the sequence of
>>> algorithm identifiers and as the signature value a sequence of
>>> signature values.  The problem with just defining the extension to
>>> SIGNED is that one needs to make sure that the set of signature
>>> algorithms and parameters are also part of the data to be signed and
>>> I am not seeing that highlighted here.
>>>  
>>> Jim
>>>  
>>>  
>>> *From:* Spasm <spasm-bounces@ietf.org
>>> <mailto:spasm-bounces@ietf.org>> *On Behalf Of *Ryan Sleevi
>>> *Sent:* Monday, September 10, 2018 8:53 AM
>>> *To:* era@x500.eu <mailto:era@x500.eu>
>>> *Cc:* SPASM <spasm@ietf.org
>>> <mailto:spasm@ietf.org>>; x500standard@freelists.org
>>> <mailto:x500standard@freelists.org>
>>> *Subject:* Re: [lamps] Double signatures
>>>  
>>>
>>>  
>>>
>>> On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <era@x500.eu
>>> <mailto:era@x500.eu>> wrote:
>>>
>>>     Hi Folk,
>>>      
>>>     In ITU-T we have plans to allow for double signatures using the
>>>     SIGNED parametrized data type defined in X.509 to cope with
>>>     situation as described in the internet draft: “Multiple
>>>     Public-Key Algorithm X.509 Certificates
>>>     (draft-truskovsky-lamps-pq-hybrid-x509-01)”
>>>      
>>>     We suggest to enhance the SIGNED data type as shown below:
>>>      
>>>     *SIGNED{ToBeSigned} ::= SEQUENCE {*
>>>     *  COMPONENTS OF SIGNATURE,*
>>>     *  ......,*
>>>     *  altAlgorithmIdentifier 
>>>     AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,*
>>>     *  altSignature            BIT STRING OPTIONAL *
>>>     *  **} (WITH COMPONENTS {..., altAlgorithmIdentifier PRESENT,
>>>     altSignature PRESENT } |*
>>>     *     WITH COMPONENTS {..., altAlgorithmIdentifier ABSENT, 
>>>     altSignature ABSENT } )*
>>>     * *
>>>     We are open to comments. We know that IETF is not a heavy user
>>>     of this data type.
>>>      
>>>     We have no intention to use this extended data type for
>>>     certificates and CRLs.
>>>      
>>>     For your information, SIGNATURE is defined as:
>>>      
>>>     *SIGNATURE ::= SEQUENCE {*
>>>     *  algorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}},*
>>>     *  signature            BIT STRING,*
>>>     *  ...... }*
>>>
>>>  
>>> From the discussions in London (101), there were a number of
>>> challenges identified during the discussion
>>> - https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt -
>>> that fundamentally questioned that approach.
>>>  
>>> Has the ITU-T addressed or resolved those concerns? Are they not
>>> applicable for some reason specific to ITU-T? 
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org <mailto:Spasm@ietf.org>
>> https://www.ietf.org/mailman/listinfo/spasm
>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
CableLabs
Principal Architect
Security Services, R&D