From nobody Fri Apr 2 10:05:26 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9063A1D4F; Fri, 2 Apr 2021 10:05: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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=0HQc7GDB; dkim=pass (1024-bit key) header.d=juniper.net header.b=hSeZnXkE 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 tTvKB6TOx7zZ; Fri, 2 Apr 2021 10:05:19 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 A35213A1D4D; Fri, 2 Apr 2021 10:05:19 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 132Gt6mE010929; Fri, 2 Apr 2021 10:05:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=5UxMQHTwhGrZw4OmHaf7xE7h7aGmVtmpGptdi3OK41Q=; b=0HQc7GDBx339p6wJ5jan/CT/l43Z9MOFnHLOV9S7wGYvtoi/X7n/T8FAvJylGhWJfgEQ 62Rbg1hkJlh+gtn7xzPUpmgAcBuyAwsjh3BKeLXirGMotv0yfMOa7jPYy2k2W3/jH0HT /dj0fBcqnO+7K6kOA9nQ3lSr1KqedyXm4oxDy9fIqOVA8VCZVh6ep0Iw4+sfbXIjxEje RUdgrtLGpkVHPE/SusnPc/yAR5fcEt5VF7gzc2k1cNDLP4M8aZS9IvnN9PA3k5h1Fgno rZs8Q7WZr0C4o2teDDdineXyMtd/LcSWzROJnSxAEMYwO28O87379PZ8rrqJIBW7wO9p pw== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) by mx0b-00273201.pphosted.com with ESMTP id 37nvd0h2yc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Apr 2021 10:05:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BBTaMpoH/oUh3ZULsyInuyH1QrTf31nY8b4X80zH4IacDFUEnVgbNfLYB8e51d6c1UarA0IXURc0aWPbF2c0DIuL84yMKiv9JLr4aVASoZN/Fe6vLD3+VfBRPf8chNC9Ty+fPoQFBtNu6A2Uf8CXPXxbKGk0DoukLXMqGbi8Aq+MJkt4YuAyJMhTNweVqA44fE4YNsFO7bhq8DufAAvoXornR+0q1Ys88JZ09UsLOEvx7a8wKIQVja4yTXV7vSOYRNNHaf0B4FvjAGRaVTG22n3EkZnvqDNzKgg/pk/FRm1HWhUA1FLolPUzor6mgOWjofus28q41HAc60AJT8Y4ow== 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=5UxMQHTwhGrZw4OmHaf7xE7h7aGmVtmpGptdi3OK41Q=; b=XiUCPKjCAC/e20gnMHNGhPmGiH2MdiXGnSBKDgQGVKfGRTiJacJxhDzMP89uK6XfOV2CmHSoPfi8SHPsHiOHU0Qv+l5ne9V78jvLan1scpBXJAFXQeda0uRErU2qmkRJrgfuVDAQexNLxd/jxqAhzhLszZwcadt7t/to+tp3xqdh2T7+3PXQ2VhLlgfHU2D2sbnUTTK8m0cBSC4pdHo0UcaTuwftsm4ntb2emcTAnazsSTntb32qdMpLjrvfzG5CRBcMWQ+179WRllAT1E8xiKNW8FcX3rMaMfNSJlc6NBL0fO64zkQTmIgViL+uZ9u9Y1q6WVj3vA/1W8ZWuDcijQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5UxMQHTwhGrZw4OmHaf7xE7h7aGmVtmpGptdi3OK41Q=; b=hSeZnXkEMBv9wd2DnIOdw8q4iIRZ762aP/eb7JsX6cOMVnDQ/J5L995EDVlhh3UebnG8wq/lkeg8Fqo9YQ+hbDpd3CazBSCIQbwz1qc5Y4+CPzXpTso1ngFrdEf0A0hFhJPfOq7syeAcWEoPARnAaIDewiBY7KdZf2/3ZjejmYM= Received: from BLAPR05MB7378.namprd05.prod.outlook.com (2603:10b6:208:298::10) by BL0PR05MB5618.namprd05.prod.outlook.com (2603:10b6:208:6c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.15; Fri, 2 Apr 2021 17:05:13 +0000 Received: from BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::a935:fb1d:c457:972a]) by BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::a935:fb1d:c457:972a%3]) with mapi id 15.20.4020.009; Fri, 2 Apr 2021 17:05:13 +0000 From: Guy Fedorkow To: Laurence Lundblade , Ira McDonald CC: "rats@ietf.org" , "Smith, Ned" , Eliot Lear , "iotops@ietf.org" , Henk Birkholz Thread-Topic: [Rats] 802.1AR device identity Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOAgACzxwCAAAOuAIAXhE8AgArnz9A= Date: Fri, 2 Apr 2021 17:05:13 +0000 Message-ID: References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> In-Reply-To: <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-04-02T17:05:11Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5a445a5e-2f44-4422-99ff-1bfb948e0c55; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f8ffc18-c90e-4751-e9b4-08d8f5f97b23 x-ms-traffictypediagnostic: BL0PR05MB5618: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:989; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +0zbJ7OcUf7jg9Yp9xtmEsJDNcJCA2lJvUitGdod6OOZX8ltAT6qrHwsskHZY7+nJo/iWCB4L7ynXtVnNn7H29ygRxj1FoHJNH+CszKCX260NZFOV7WXweYj5HQz0wzthCfFWTFqHxwybejxecGopF8zJjtx42xk2afEJet2FQ1DFw2KHodsXpnkwykyec2dMs8pX/vvoJ2lbj6diW4JRD89bA2rjHd8HJFnOE53oUjYZznEfy5XT38MQpM6NNyp9HOQo/7ao6Kq966H7wfKtJW2Qw091BfHDggcYPrXmk/qaVDRYq0YUVitgk3tBhdOKLQuTHFjeaoorGaPlgglgQK70q142FbMEUzgEN5qfrdCSjgTzQXSHr8l2yGQHFO7hMgPllMoGsA5cg72EsoPZiwHOVTnH+pvrH4shJj8M0GgdaYSLBEW1RrGoeyYyyV+eJwuiTxWGEkpE0PthHB/V7tIFDDfuMM+bZn4SAsPEpz5VSNOKHU/fghr54CNUkWNVfZUOp5uQRCOI8PyXpSeu6wxuPdZdlXbw0w62xVSJRnVMiWsjmQ1Zthh/xaHB5SuVrRtxR3bMvirXYhdgM/m5WqAI34KMqlNez7oO717XvYEay/uJ9cSl+99z/PupFydhtQM3Ir89F3CXhoWu7SjwCjkfgFbt7hxbtxnFxSkyLCZU9nzcf3E8Aoa/K3OLsFfNDPVd77JKqD1onp5zp6cFArj3YQp5Q+M5r4SJdskUGxS7r7Tgu7T7pDXZsqIh6ZpbYT1MQJwIoES8Fj5nHKILQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR05MB7378.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(366004)(396003)(136003)(26005)(6506007)(8936002)(9686003)(4326008)(54906003)(66556008)(186003)(66446008)(2906002)(7696005)(110136005)(66476007)(52536014)(55016002)(53546011)(966005)(83380400001)(33656002)(5660300002)(66946007)(38100700001)(76116006)(316002)(8676002)(86362001)(71200400001)(9326002)(478600001)(166002)(64756008)(134034003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?2KP4hxzT7rjJhhtkBtNdO8Ilu+KnEfvy4ysycTPisjl++YRPWljAFzjQ3o0+?= =?us-ascii?Q?JJ1PJ8Es/OeG005hwu/1SVyCbXi/azsypre0rztjSJ7qnE/dJrtSSZCpkB31?= =?us-ascii?Q?N6N1ghdx7EHOq4tu/W3Qx8BejCCKJ40K5QE0g3S4I9XlPN54IspFzO2xQ/Z1?= =?us-ascii?Q?9tbumh8tsof+WHNX8XQPHUvfRxWuJQXQxF4GKMsG+CAXsIYYk2ubTeYKg0P9?= =?us-ascii?Q?IOJV2iYfQE7mC2Iqrx/adsP5e+KhyfwQPpvDdYZKklmic3td3J/eT4KOpkNO?= =?us-ascii?Q?Xhpb/BYZlaBxuN4b+Ji5UMKUCQH5eBGKM7XgtvDQXLNPsmtK4wvT95zg0L+4?= =?us-ascii?Q?6XT3O0TbUoSA+WjTQ3yp2TeAoBqAPLoOgPdwrPxAx7oT63bRhtU9zMNrX+/s?= =?us-ascii?Q?95Nf5rUHOKsNPHfJ7YWC7x9niXcOUb/nykvUwFySaz0vSE229mpHN6Akcz78?= =?us-ascii?Q?UhMIxLoXeMmatg1FvOCTpZvH8+pDjqFshuIbOBZt4LdUyRHUPFnysQ70htJy?= =?us-ascii?Q?NQArvj56W3GUaYmAa9JlSDjz9UuS5OsqGuT8hWGtK/GNQ+F5CjAbuSrNL1Hl?= =?us-ascii?Q?368w6vuONq/1iDZc0/J9iCksawLnj+GsDUeF15BuEwqpgrGMMicZcfT7CruQ?= =?us-ascii?Q?TbqqAVuZPjPIQoYeuNK6KQg0G1MexSRG3LuyTZSoeJwlojyfRPkcvr9Fb4QS?= =?us-ascii?Q?rhoFRLpGJom9yUf6zzJRJNEmtdfzlzEHmAesPk+JQz9kvpks0BG/Ur6S3GRz?= =?us-ascii?Q?gw5ADhEYklbrYDK6cGYvtFxIp0Sbxf5MSOgFjrte/zGQyTgOi6A8yzetGIwU?= =?us-ascii?Q?8JdRKj36YVGZnSKptxbc9RKJTNyuXYtFxyw0IkZ0DzFnVL+/rdSphlsPXxJl?= =?us-ascii?Q?+wWozm6+Epjge/jhftJm37GSx1jYNNyB9vFrk2UW11hfpqt2dHLiYGl1W2RZ?= =?us-ascii?Q?ALAW5y4pOkp8hmpH/DrLPUsvy2hjOZiWViuUUM86GPwsSdqsRgDTyeYvRYwp?= =?us-ascii?Q?aKoiPqRB7BGrPbFDlsc1a+5//1OPC/pOFoRdsePNMz4A+E+UnWOTVFapnMTq?= =?us-ascii?Q?gpPlSIVEOIi6hOmhitm8MTHVa4suBC+78O/m0j+dh+YUGXppV0d3+KtISxQ5?= =?us-ascii?Q?gWAT90mgdgGXXRoFmrB7msLYMKHs2QNL4/cV64WiJ1DXfVTxqHvToi2Z7fCG?= =?us-ascii?Q?DnUCMUBnlB9vAnBQShf89ySsvwOr+qK6Rs58pgVuJWFFFh+gqXzHW+7d7Sky?= =?us-ascii?Q?cbQhs0XLxcnf57tMqryIuaA6zkfN0bskSLlbyr+AA0wtRcAyDOZ3P91WIrAZ?= =?us-ascii?Q?EcjNKxbVgqG5fr+Vsw48xT6V?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BLAPR05MB7378A9F73457513AC951F82FBA7A9BLAPR05MB7378namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR05MB7378.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f8ffc18-c90e-4751-e9b4-08d8f5f97b23 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2021 17:05:13.3238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oUE1RmB6/en1B5xhmraA6fOi563o4vtgGmNNKx2yzERxcybVg5fuQ1ePkX+koyJTO+WeX6kxFpYtjv6vDtBX1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5618 X-Proofpoint-GUID: pxymHr1tJ2nMTsJ7K0GVDjfqXUYX4YCX X-Proofpoint-ORIG-GUID: pxymHr1tJ2nMTsJ7K0GVDjfqXUYX4YCX X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-04-02_09:2021-04-01, 2021-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 clxscore=1011 bulkscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 impostorscore=0 phishscore=0 malwarescore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103310000 definitions=main-2104020119 Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 17:05:25 -0000 --_000_BLAPR05MB7378A9F73457513AC951F82FBA7A9BLAPR05MB7378namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laurence, I agree that IDevID is intended to persist through the device's lifetime,= while LDevID is meant to represent the current owner. In TCG-land, an IDevID is not advised for signing attestation evidence; i= ts role is limited to identity, providing proof of the supplier and the rea= l-world identity of the device (i.e., serial number). With TPM1.2 it's actually not possible to use the IDevID to sign TPM atte= station evidence, as a counter-measure to block spoofing by an attacker, so= the TCG docs advise a separate attestation key with a binding that links t= hem to the same TPM. I think that's not actually necessary in TPM2, althou= gh the advice for separation remains. So in that context the sentence "[EAT] separates the signing scheme from = the identification scheme" seems puzzling. But in the EAT environment, where there's no technological block to an at= tacker with access to the key to spoof an attestation result, I agree that = the DevID could be used to sign an EAT token carrying attestation evidence. Let me know if I'm missing the point! Thx /guy Juniper Business Use Only From: Laurence Lundblade Sent: Friday, March 26, 2021 2:21 PM To: Ira McDonald Cc: rats@ietf.org; Smith, Ned ; Eliot Lear ; Guy Fedorkow ; iotops@ietf.org Subject: Re: [Rats] 802.1AR device identity [External Email. Be cautious of content] I got my copy of 802-1AR. I've made a PR that 1) Adds an SUEID to EAT that is similar to LDevID in that it can change = on device life-cycle events 2) Adds a whole appendix discussing the relation of IDevID to EAT >From reading 802.1AR, it's pretty clear that IDevID is permanent. Here's on= e sentence: These additional operations can include deletion of the IDevID certificate = or IDevID key, which can be logically equivalent to decommissioning the dev= ice, 802.1AR also provides for an LDevID that is less permanent in the ways that= Giri seems to be asking for. Please take a lot at the PR. It does a little compare and contrast between = EAT and IDevID. I am interested in comments on it. LL On Mar 11, 2021, at 11:13 AM, Ira McDonald > wrote: Hi Laurence, Thanks to the wonderful *free* IEEE Get 802 program, you can go to this lin= k (from Guy earlier) and create your own durable free Get 802 account and then download IEEE 802= .1AR-2018 (and anything else from the whole IEEE 802 series that you need). https://1.ieee802.org/security/802-1ar/ Cheers, - Ira On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade > wrote: I want to unpack and unfold a few things here. Permanence / Lifecycle / Privacy - I think the main topic here is about whe= n an ID changes relative to the lifecycle of the device and how this relate= s to privacy. Compromise - I think compromise due to algorithms being compromised or the = device being owned or such is a separate topic. Discussion of it seems orth= ogonal, should go into security considerations and really comes down to cer= tification in the end if you really want to lock it down. I'm not sure which is meant by "immutability" in the previous emails. My intent in the definition of UEID was that it is truly permanent. It does= n't change at any time in the lifecycle of the device. This is the simplest= case to describe. It is not at all privacy preserving for some use cases (= e.g., mobile phone), but is OK for others (e.g., dumb sensor). I was thinking other folks might define other IDs for other use cases. Mayb= e the time has come to invent one or two of those and put them in EAT. Some Solutions One possibility is an SUEID, a semi-permanent UEID (maybe not use SPUIED). = It is allowed to change in major events in the devices lifecycle such as ev= ents when ownership changes, the managing entity changes or on factory rese= t. I think this lines up with the way some MAC addresses are managed for pr= ivacy reasons. This line up is good because a UEID can be an IEEE MAC. An RP might receive an EAT with only an UEID, only an SPUEID or both. The R= P can decide what they want to use. Another one is for the Attester to authenticate the Verifier and/or Relying= Party and generate a distinct UEID or SUEID just for use by that RP. This = is a solution to the privacy issue. I've actually done an implementation of= this one. A related solution is to have a privacy proxy between the Attester and the = Verifier that makes RP-specific UEIDs or SUEIDs. Separation of ID from Attestation Key An ID that is not signed is nearly useless because anyone can forge it so w= e're always talking about some sort of signing. EAT intentionally separates the ID from the signing key. I haven't read IDe= vID, but I don't think it has this separation. The reason EAT separates the= m is to have a lot of flexibility to deal with the privacy and lifecycle is= sues that come up in real deployments for chip makers and complex supply ch= ains. For example, FIDO uses group attestation keys to deal with the privacy issu= e. One key is put into 100,000 plus devices which makes it statistically no= t very useful for tracking users. Maybe the device manufacture uses this ta= ctic for billions of devices. Then maybe a use case involving only millions= of these devices needs a truly global ID and have the means to program it.= This can work if the keys and IDs are separate. Or maybe the manufacturer changes signing schemes moving from a primitive M= AC to EC-based pub key and onto some sort of DAA while maintaining the same= scheme for device IDs. Possible harmonization with other Device IDs? I noticed that birkholz-rats-suit-claims mentio= ns a device ID based on UUIDs. We should probably take a look at how this r= elates UEID. There's probably others to check out. We probably want to re u= se a lot of the claims from Evidence in Attestation Results so they can be = pass-through for the Verifier. Note also that UUIDs are obsolete now. LL P.S., Any suggestions on how to get access to IEEE IDevID? I'm not part of = a big company. I tried joining IEEE once, but that wasn't enough to get acc= ess. _______________________________________________ RATS mailing list RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats _______________________________________________ RATS mailing list RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats --_000_BLAPR05MB7378A9F73457513AC951F82FBA7A9BLAPR05MB7378namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Laurence,

  I agree that IDevID is intended to persist th= rough the device’s lifetime, while LDevID is meant to represent the c= urrent owner.

  In TCG-land, an IDevID is not advised for sig= ning attestation evidence; its role is limited to identity, providing proof= of the supplier and the real-world identity of the device (i.e., serial nu= mber). 

  With TPM1.2 it’s actually not poss= ible to use the IDevID to sign TPM attestation evidence, as a counter-measu= re to block spoofing by an attacker, so the TCG docs advise a separate atte= station key with a binding that links them to the same TPM.  I think that’s not actually necessary in TPM2, altho= ugh the advice for separation remains.

  So in that context the sentence “[EAT] = separates the signing scheme from the identification scheme” seems pu= zzling.

 

  But in the EAT environment, where there’= ;s no technological block to an attacker with access to the key to spoof an= attestation result, I agree that the DevID could be used to sign an EAT to= ken carrying attestation evidence.

 

  Let me know if I’m missing the point!

Thx

/guy

 

 

 

Juniper Business Use Only

From: Laurence Lundblade <lgl@island-resor= t.com>
Sent: Friday, March 26, 2021 2:21 PM
To: Ira McDonald <blueroofmusic@gmail.com>
Cc: rats@ietf.org; Smith, Ned <ned.smith@intel.com>; Eliot Lea= r <lear@cisco.com>; Guy Fedorkow <gfedorkow@juniper.net>; iotop= s@ietf.org
Subject: Re: [Rats] 802.1AR device identity

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

I got my copy of 802-1AR.

 

I’ve made a PR that

   1) Adds an SUEID to EAT that is similar= to LDevID in that it can change on device life-cycle events

   2) Adds a whole appendix discussing the= relation of IDevID to EAT

 

From reading 802.1AR, it’s pretty clear that I= DevID is permanent. Here’s one sentence:

These additional operations can include deletion of the IDev= ID certificate or IDevID key, which can be logically equivalent to decommissioning the device, 

802.1AR also provides for an LDevID that is less per= manent in the ways that Giri seems to be asking for.

 

Please take a lot at the PR. It does a little compar= e and contrast between EAT and IDevID. I am interested in comments on it.

 

LL

 

 

 

On Mar 11, 2021, at 11:13 AM, Ira McDonald <blueroofmusic@gmail.com> wrote= :

 

Hi Laurence,

 

Thanks to the wonderful *free* IEEE Get 802 program,= you can go to this link (from Guy earlier)

and create your own durable free Get 802 account and= then download IEEE 802.1AR-2018 (and

anything else from the whole IEEE 802 series that yo= u need).

 

 

Cheers,

- Ira

 

 

 

On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade &= lt;lgl@island-resort.com> w= rote:

I want to unpack and unfold a few things here. =

 

Permanence / Lifecycle / Privacy —&nbs= p;I think the main topic here is about when an ID changes relative to t= he lifecycle of the device and how this relates to privacy.

 

Compromise — I think compromi= se due to algorithms being compromised or the device being owned or such is= a separate topic. Discussion of it seems orthogonal, should go into securi= ty considerations and really comes down to certification in the end if you really want to lock it down.

 

I’m not sure which is meant by “immutabi= lity” in the previous emails.

 

My intent in the definition of UEID was that it is t= ruly permanent. It doesn’t change at any time in the lifecycle of the= device. This is the simplest case to describe. It is not at all privacy pr= eserving for some use cases (e.g., mobile phone), but is OK for others (e.g., dumb sensor). 

 

I was thinking other folks might define other IDs fo= r other use cases. Maybe the time has come to invent one or two of those an= d put them in EAT.

 

Some Solutions

One possibility is an SUEID, a semi-permanent UEID (= maybe not use SPUIED). It is allowed to change in major events in the devic= es lifecycle such as events when ownership changes, the managing entity cha= nges or on factory reset. I think this lines up with the way some MAC addresses are managed for privacy reas= ons. This line up is good because a UEID can be an IEEE MAC.

 

An RP might receive an EAT with only an UEID, only a= n SPUEID or both. The RP can decide what they want to use.

 

 

Another one is for the Attester to authenticate the = Verifier and/or Relying Party and generate a distinct UEID or SUEID just fo= r use by that RP. This is a solution to the privacy issue. I’ve actua= lly done an implementation of this one.

 

 

A related solution is to have a privacy proxy betwee= n the Attester and the Verifier that makes RP-specific UEIDs or SUEIDs.

 

 

Separation of ID from Attestation Key

An ID that is not signed is nearly useless because a= nyone can forge it so we’re always talking about some sort of signing= .

 

EAT intentionally separates the ID from the signing = key. I haven’t read IDevID, but I don’t think it has this separ= ation. The reason EAT separates them is to have a lot of flexibility to dea= l with the privacy and lifecycle issues that come up in real deployments for chip makers and complex supply chains.

 

For example, FIDO uses group attestation keys to dea= l with the privacy issue. One key is put into 100,000 plus devices which ma= kes it statistically not very useful for tracking users. Maybe the device m= anufacture uses this tactic for billions of devices. Then maybe a use case involving only millions of these devices= needs a truly global ID and have the means to program it. This can work if= the keys and IDs are separate.

 

Or maybe the manufacturer changes signing schemes mo= ving from a primitive MAC to EC-based pub key and onto some sort of DAA whi= le maintaining the same scheme for device IDs.

 

 

Possible harmonization with other Device IDs?=

I noticed that birkholz-rats-suit-claims mentions a device ID based on UUIDs. We should probably take a look at how this rel= ates UEID. There’s probably others to check out. We probably want to = re use a lot of the claims from Evidence in Attestation Results so they can= be pass-through for the Verifier.

 

Note also that UUIDs are obsolete now.

 

LL

 

 

P.S., Any suggestions on how to get access to IEEE I= DevID? I’m not part of a big company. I tried joining IEEE once, but = that wasn’t enough to get access.

 

 

 

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/ra= ts

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

 

--_000_BLAPR05MB7378A9F73457513AC951F82FBA7A9BLAPR05MB7378namp_-- From nobody Mon Apr 5 13:12:35 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3B33A2632 for ; Mon, 5 Apr 2021 13:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 14oKhko0IX7W for ; Mon, 5 Apr 2021 13:12:24 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 4E1CF3A25FF for ; Mon, 5 Apr 2021 13:12:24 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id o126so19200940lfa.0 for ; Mon, 05 Apr 2021 13:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hZeqV9YpkduFjiRMVdoYzeIx6D3YmrGrMW2Sw3Plck0=; b=cNyNYcwLrHZ5mKxOnUWiXV/TwYXsdIty8m+JhUVKcUvnegAmNwltMZ5mok/6huIbFS kit5nB5NMeqoqUy4nZPzwQEXE5iw9IW+MEWnibh9jBp4yjfAX3B8jbKSWY1YiZxdz/1K aFElg1rWMImUsHsQNepwwVblIkOJ0HoRQ+wPVi0MzQZp5X6qr4JfaTWWS5u8L463wyoT pwqzfI/YccLi9k6OPGa930zLFqNzCwV+JpBSqd+1Ah4FKWb6RTWAOtgTXn9d8MuYaofq IEqAwczCmh8oIt7yuWQUxWmsRCK8n2QXrNBNBMOBI6ZJTqgmM6yLnjhXLwa6NybyLrso 3Irg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hZeqV9YpkduFjiRMVdoYzeIx6D3YmrGrMW2Sw3Plck0=; b=fXJyJfH7I8x5AIY9Hj0dXTQJfeEA12/OM0zyLXO9w+lgBLeSGIpHKCxHTKiiT177Zw qGs0R6Oqkd9IGInkdDYokG/D34uWlKpsWrts5gM6/C+gGmkEnMpOdFQwl/n5dRDwCLF/ WsivFEsrTanjQ2oQyW4AWBWm/YjDlvhxpe7zmUOkRM8oCAkyfL4VzdXSztEk2hike0QS mHYpfxjodlZO09H1Bik7gCTGDBD58J3e7UMq0kMfJUrHGWduohbMI9UYx60ncn5QBpJW mRhBDa8tcg5BnMzWlXxQmSbYE2OJXtRx5nE8u7RgWnH6a7Vr+Po9/GaIMi6fISv6UUKR Ia2w== X-Gm-Message-State: AOAM530EANmus+uaP+Hd/ueWUEiiBn9MUQP7IqInxgFHS20p9BqY2rXf lKHKXQFEJyWUpQbBYp9cw50XSuhhZvA7XglSXQ1MSA== X-Google-Smtp-Source: ABdhPJyLAdsZQbgc1C+eUQACms3bRQaMub+G1/mJM6XRJL8yis71S0X7xjCBXsxMb1DI/dEHYRDFNxObpxL/MrFJTn0= X-Received: by 2002:ac2:490b:: with SMTP id n11mr17856770lfi.491.1617653536512; Mon, 05 Apr 2021 13:12:16 -0700 (PDT) MIME-Version: 1.0 References: <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> <21967.1617129551@localhost> <53C7C8C0-1995-4FEB-98D5-3F3EF26F3527@tzi.org> <08b7f4d5-03a6-3cd1-e36b-9e57932517d2@ericsson.com> In-Reply-To: <08b7f4d5-03a6-3cd1-e36b-9e57932517d2@ericsson.com> From: Warren Kumari Date: Mon, 5 Apr 2021 16:11:40 -0400 Message-ID: To: Mohit Sethi M Cc: Carsten Bormann , Michael Richardson , "t2trg@irtf.org" , "iotops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000069ed6e05bf3f5030" Archived-At: Subject: Re: [Iotops] Secure IoT Bootstrapping: A Survey X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 20:12:34 -0000 --00000000000069ed6e05bf3f5030 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2021 at 4:54 PM Mohit Sethi M wrote: > Dear Carsten, Michael, > > On 3/30/21 11:11 PM, Carsten Bormann wrote: > > On 30. Mar 2021, at 20:39, Michael Richardson > wrote: > >> > >> Carsten Bormann wrote: > >>>> Very well timed. I look forward to discussing this. > >>> Thanks! > >>> Now would be a good time to get some initial feedback =E2=80=94 we pl= an to > >>> adopt it as an RG document on April 6th. > >> I wonder if having it adopted in IOTOPS might make more sense. > > Certainly =E2=80=94 addressing that might be part of that feedback. > > It appears to me that the document would be covered by its charter, eve= n > if "Taking input and discussing issues=E2=80=9D is not that well-defined = an > activity. > > It is not clear to me whether working on this in the WG would give the > document a new spin, beyond its current approach as a survey, and whether > that would actually be a welcome change to the authors and consumers of > that document. > > Input from WG members and leadership could help understand this. > > Speaking for myself: I feel that such a survey document is better-suited > for a research group (RG) rather than a working group (WG). I agree -- this does seem like it's better suited for the RG, but I do suggest that it also be discussed in IoTops, just to get it more visibility and feedback.... W > It would be > in line with the previous security document from T2TRG: "Internet of > Things (IoT) Security: State of the Art and Challenges" > (https://tools.ietf.org/html/rfc8576). I am not fundamentally opposed to > pursuing this in IoTops but I feel that perhaps an evolution of this > document (Carsten writes about a new spin) in the near future would be > more suitable for IoTops. I am of course interested in contributing to > that potential future document as well. > > --Mohit > > > > > Gr=C3=BC=C3=9Fe, Carsten > > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --00000000000069ed6e05bf3f5030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 30, 2021 at 4:54 PM Mohi= t Sethi M <mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> wrote:
Dear Carsten, Michael,

On 3/30/21 11:11 PM, Carsten Bormann wrote:
> On 30. Mar 2021, at 20:39, Michael Richardson <mcr+ietf@sandelman.ca> wrot= e:
>>
>> Carsten Bormann <cabo@tzi.org> wrote:
>>>> Very well timed.=C2=A0 I look forward to discussing this.<= br> >>> Thanks!
>>> Now would be a good time to get some initial feedback =E2=80= =94 we plan to
>>> adopt it as an RG document on April 6th.
>> I wonder if having it adopted in IOTOPS might make more sense.
> Certainly =E2=80=94 addressing that might be part of that feedback. > It appears to me that the document would be covered by its charter, ev= en if "Taking input and discussing issues=E2=80=9D is not that well-de= fined an activity.
> It is not clear to me whether working on this in the WG would give the= document a new spin, beyond its current approach as a survey, and whether = that would actually be a welcome change to the authors and consumers of tha= t document.
> Input from WG members and leadership could help understand this.

Speaking for myself: I feel that such a survey document is better-suited for a research group (RG) rather than a working group (WG).


<no-hats>
I agree -- this does seem like = it's better suited for the RG, but I do suggest that it also be discuss= ed in IoTops, just to get it more visibility and feedback....

W
<= br>
=C2=A0
It would be
in line with the previous security document from T2TRG: "Internet of <= br> Things (IoT) Security: State of the Art and Challenges"
(https://tools.ietf.org/html/rfc8576). I am not fundamentall= y opposed to
pursuing this in IoTops but I feel that perhaps an evolution of this
document (Carsten writes about a new spin) in the near future would be
more suitable for IoTops. I am of course interested in contributing to
that potential future document as well.

--Mohit

>
> Gr=C3=BC=C3=9Fe, Carsten
>
--
Iotops mailing list
Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--00000000000069ed6e05bf3f5030-- From nobody Tue Apr 6 06:52:50 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FDB3A220A; Tue, 6 Apr 2021 06:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 9VksFz0WPZhf; Tue, 6 Apr 2021 06:52:38 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C29D33A2218; Tue, 6 Apr 2021 06:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1617717131; d=isode.com; s=june2016; i=@isode.com; bh=zbBiiTwwdwftq6QoyCfsKW2bjOR+moKKfDHO0+MKP3M=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VmTg+JMx8IFzqbNTtvVMVLwjh4sjS6za/T5BOZGSFnZQflSv05Lh37gH3CqYcOIzOMfwFu ENRUXMhu0OraihfRfZdBHI8lKOm/rUaMDiiZfmJardjzZrZIoKGm3mxVJSkF53Ny5WKaPh xKN88eTobTLQKbXLpVZOLexM3ZQ+Mag=; Received: from [192.168.1.222] (host31-49-142-19.range31-49.btcentralplus.com [31.49.142.19]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 6 Apr 2021 14:52:11 +0100 To: iotops@ietf.org From: Alexey Melnikov Cc: "iotops-chairs@ietf.org" Message-ID: <4e492887-b34a-e7a6-c02a-421b6b56b6bd@isode.com> Date: Tue, 6 Apr 2021 14:52:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Iotops] IOTOPS interim meeting on April 20th and request for agenda items X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 13:52:49 -0000 Dear IOTOPS participants, As per feedback during our first meeting @ IETF 110, we will be holding a 2 hour long virtual interim meeting on April 20th, 4pm-6pm (UTC+1). Henk and I are working on the agenda. If you would like to present, please email your requests to iotops-chairs@ietf.org Below is the link for joining the meeting on April 20th: https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e Best Regards, Alexey, on behalf of chairs. From nobody Tue Apr 13 12:26:36 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C563A247A for ; Tue, 13 Apr 2021 12:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 S_sOxMKQQ6Xu for ; Tue, 13 Apr 2021 12:26:28 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (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 299FF3A2490 for ; Tue, 13 Apr 2021 12:26:28 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id WOg6lkd9prKaTWOg6lB8WH; Tue, 13 Apr 2021 12:26:27 -0700 X-CMAE-Analysis: v=2.4 cv=NrkUz+RJ c=1 sm=1 tr=0 ts=6075f063 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=xt6ew7UTAAAA:8 a=OUXY8nFuAAAA:8 a=K6EGIJCdAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=QyXUC8HyAAAA:8 a=AUd_NHdVAAAA:8 a=0XtbOteLAAAA:20 a=dHJOhkScAAAA:8 a=uherdBYGAAAA:8 a=fJKHkNSBhjea5dGItl8A:9 a=QEXdDO2ut3YA:10 a=uhck6Ij_AI0iXQIot0IA:9 a=EEPkUL_1XtRU81fs:21 a=_W_S_7VecoQA:10 a=tn93DeGZTgJ6DdWMtdD4:22 a=cAcMbU7R10T-QSRYIcO_:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 a=0Jc9p3VZYLcdQ-t9l-12:22 a=Ef4yma5cpRUEJWN9UqBm:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6FE77F6B-3ED6-4F30-807C-36AEBBC41A39" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 13 Apr 2021 12:26:26 -0700 In-Reply-To: Cc: Ira McDonald , "rats@ietf.org" , "Smith, Ned" , Eliot Lear , "iotops@ietf.org" , Henk Birkholz To: Guy Fedorkow References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfFwWGNPQUoY6UokyGzTBNeaBjpCeXKwVXxMD8HHCwfnsuWphU4X20yziZFuPTrHfyIDqHov1jqSEA12cG4n8pgcpg8uOrE8vxTxS2HRWSPA4tdz4LmDZ XkzihHzsxNdo4VfF3aO+fTysSZ0Z0gF8IU6aWmLcg0kt+Nu+Vvyd6ytAolyMeYZvXnmk7549Y67dA+yd8wmB9XaVDU/3uCP1wZYYJVotLVU9SoKioCOWtPiu 1PQHQlxDegb8hjJtxihcauiyXoxoxMKQoPm3fxriFI/Zcxtia8EdG3cqYDnTHdmuz0puBqkZAKztEv4g39PVjh5SSz4ZDe6FCy0IGAA1TPQh1210OnRWWisX FaI3Xr5quOWDTwjHOI23QvT4K2mjMg== Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 19:26:35 -0000 --Apple-Mail=_6FE77F6B-3ED6-4F30-807C-36AEBBC41A39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the comments, Guy. Appreciate it. Agreed that repurposing IDevID keys for EAT might be a bit weird and = wrong, but it is still really useful to understand how they are intended = to work and are actually used to help with the design of EAT. 802.1AR section 7.2.5 say the keys can be used for signing. Appendix B = has it participating in an EAT-TLS session and gives some other very = general use cases. No matter what, the key has to be used to sign a = nonce for proof of possession, so there is some signing of external data = going on. = https://www.trustedcomputinggroup.org/wp-content/uploads/TPM_Keys_for_Plat= form_Identity_v1_0_r3_Final.pdf lists a whole bunch more use cases like = IKE. Do these really get implemented?=20 What are the popular and widely deployed use cases for IDevID? I kind of want EAT to learn from IDevID here. To understand what IDevID = is about so that EAT is more capable and fits in better with use cases. LL > On Apr 2, 2021, at 10:05 AM, Guy Fedorkow = wrote: >=20 > Hi Laurence, > I agree that IDevID is intended to persist through the device=E2=80=99= s lifetime, while LDevID is meant to represent the current owner. > In TCG-land, an IDevID is not advised for signing attestation = evidence; its role is limited to identity, providing proof of the = supplier and the real-world identity of the device (i.e., serial = number).=20 > With TPM1.2 it=E2=80=99s actually not possible to use the IDevID to = sign TPM attestation evidence, as a counter-measure to block spoofing by = an attacker, so the TCG docs advise a separate attestation key with a = binding that links them to the same TPM. I think that=E2=80=99s not = actually necessary in TPM2, although the advice for separation remains. > So in that context the sentence =E2=80=9C[EAT] separates the signing = scheme from the identification scheme=E2=80=9D seems puzzling. > =20 > But in the EAT environment, where there=E2=80=99s no technological = block to an attacker with access to the key to spoof an attestation = result, I agree that the DevID could be used to sign an EAT token = carrying attestation evidence. > =20 > Let me know if I=E2=80=99m missing the point! > Thx > /guy > =20 > =20 > =20 > Juniper Business Use Only > From: Laurence Lundblade >=20 > Sent: Friday, March 26, 2021 2:21 PM > To: Ira McDonald > > Cc: rats@ietf.org ; Smith, Ned = >; Eliot Lear = >; Guy Fedorkow = >; iotops@ietf.org = > Subject: Re: [Rats] 802.1AR device identity > =20 > [External Email. Be cautious of content] > =20 > I got my copy of 802-1AR. > =20 > I=E2=80=99ve made a PR = that > 1) Adds an SUEID to EAT that is similar to LDevID in that it can = change on device life-cycle events > 2) Adds a whole appendix discussing the relation of IDevID to EAT > =20 > =46rom reading 802.1AR, it=E2=80=99s pretty clear that IDevID is = permanent. Here=E2=80=99s one sentence: > These additional operations can include deletion of the IDevID = certificate or IDevID key, which can be logically equivalent to = decommissioning the device,=20 > 802.1AR also provides for an LDevID that is less permanent in the ways = that Giri seems to be asking for. > =20 > Please take a lot at the PR. It does a little compare and contrast = between EAT and IDevID. I am interested in comments on it. > =20 > LL > =20 > =20 > =20 >=20 > On Mar 11, 2021, at 11:13 AM, Ira McDonald > wrote: > =20 > Hi Laurence, > =20 > Thanks to the wonderful *free* IEEE Get 802 program, you can go to = this link (from Guy earlier) > and create your own durable free Get 802 account and then download = IEEE 802.1AR-2018 (and > anything else from the whole IEEE 802 series that you need). > =20 > https://1.ieee802.org/security/802-1ar/ = > =20 > Cheers, > - Ira > =20 > =20 > =20 > On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade = > wrote: > I want to unpack and unfold a few things here.=20 > =20 > Permanence / Lifecycle / Privacy =E2=80=94 I think the main topic here = is about when an ID changes relative to the lifecycle of the device and = how this relates to privacy. > =20 > Compromise =E2=80=94 I think compromise due to algorithms being = compromised or the device being owned or such is a separate topic. = Discussion of it seems orthogonal, should go into security = considerations and really comes down to certification in the end if you = really want to lock it down. > =20 > I=E2=80=99m not sure which is meant by =E2=80=9Cimmutability=E2=80=9D = in the previous emails. > =20 > My intent in the definition of UEID was that it is truly permanent. It = doesn=E2=80=99t change at any time in the lifecycle of the device. This = is the simplest case to describe. It is not at all privacy preserving = for some use cases (e.g., mobile phone), but is OK for others (e.g., = dumb sensor).=20 > =20 > I was thinking other folks might define other IDs for other use cases. = Maybe the time has come to invent one or two of those and put them in = EAT. > =20 > Some Solutions > One possibility is an SUEID, a semi-permanent UEID (maybe not use = SPUIED). It is allowed to change in major events in the devices = lifecycle such as events when ownership changes, the managing entity = changes or on factory reset. I think this lines up with the way some MAC = addresses are managed for privacy reasons. This line up is good because = a UEID can be an IEEE MAC. > =20 > An RP might receive an EAT with only an UEID, only an SPUEID or both. = The RP can decide what they want to use. > =20 > =20 > Another one is for the Attester to authenticate the Verifier and/or = Relying Party and generate a distinct UEID or SUEID just for use by that = RP. This is a solution to the privacy issue. I=E2=80=99ve actually done = an implementation of this one. > =20 > =20 > A related solution is to have a privacy proxy between the Attester and = the Verifier that makes RP-specific UEIDs or SUEIDs. > =20 > =20 > Separation of ID from Attestation Key > An ID that is not signed is nearly useless because anyone can forge it = so we=E2=80=99re always talking about some sort of signing. > =20 > EAT intentionally separates the ID from the signing key. I haven=E2=80=99= t read IDevID, but I don=E2=80=99t think it has this separation. The = reason EAT separates them is to have a lot of flexibility to deal with = the privacy and lifecycle issues that come up in real deployments for = chip makers and complex supply chains. > =20 > For example, FIDO uses group attestation keys to deal with the privacy = issue. One key is put into 100,000 plus devices which makes it = statistically not very useful for tracking users. Maybe the device = manufacture uses this tactic for billions of devices. Then maybe a use = case involving only millions of these devices needs a truly global ID = and have the means to program it. This can work if the keys and IDs are = separate. > =20 > Or maybe the manufacturer changes signing schemes moving from a = primitive MAC to EC-based pub key and onto some sort of DAA while = maintaining the same scheme for device IDs. > =20 > =20 > Possible harmonization with other Device IDs? > I noticed that birkholz-rats-suit-claims = mentions a device ID based on UUIDs. We = should probably take a look at how this relates UEID. There=E2=80=99s = probably others to check out. We probably want to re use a lot of the = claims from Evidence in Attestation Results so they can be pass-through = for the Verifier. > =20 > Note also that UUIDs are obsolete now. > =20 > LL > =20 > =20 > P.S., Any suggestions on how to get access to IEEE IDevID? I=E2=80=99m = not part of a big company. I tried joining IEEE once, but that wasn=E2=80=99= t enough to get access. > =20 > =20 > =20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats = > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats = --Apple-Mail=_6FE77F6B-3ED6-4F30-807C-36AEBBC41A39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the comments, Guy. Appreciate it.
Agreed that repurposing IDevID keys = for EAT might be a bit weird and wrong, but it is still really useful to = understand how they are intended to work and are actually used to help = with the design of EAT.

802.1AR section 7.2.5 say the keys can be used for signing. = Appendix B has it participating in an EAT-TLS session and gives some = other very general use cases.  No matter what, the key has to be = used to sign a nonce for proof of possession, so there is some signing = of external data going on.

https://www.trustedcomputinggroup.org/wp-content/uploads/TPM_Ke= ys_for_Platform_Identity_v1_0_r3_Final.pdf lists a whole bunch more = use cases like IKE. Do these really get implemented? 

What are the popular and = widely deployed use cases for IDevID?

I kind of want EAT to learn from IDevID = here. To understand what IDevID is about so that EAT is more capable and = fits in better with use cases.

LL


On Apr 2, 2021, at 10:05 AM, Guy Fedorkow <gfedorkow@juniper.net> wrote:

Hi Laurence,
  I agree that IDevID = is intended to persist through the device=E2=80=99s lifetime, while = LDevID is meant to represent the current owner.
  In TCG-land, an = IDevID is not advised for signing attestation evidence; its role is = limited to identity, providing proof of the supplier and the real-world = identity of the device (i.e., serial number). 
  With TPM1.2 = it=E2=80=99s actually not possible to use the IDevID to sign TPM = attestation evidence, as a counter-measure to block spoofing by an = attacker, so the TCG docs advise a separate attestation key with a = binding that links them to the same TPM.  I think that=E2=80=99s = not actually necessary in TPM2, although the advice for separation = remains.
  So = in that context the sentence =E2=80=9C[EAT] separates the signing scheme = from the identification scheme=E2=80=9D seems puzzling.
 
  But in the EAT = environment, where there=E2=80=99s no technological block to an attacker = with access to the key to spoof an attestation result, I agree that the = DevID could be used to sign an EAT token carrying attestation = evidence.
 
  Let me know if = I=E2=80=99m missing the point!
Thx
/guy
 
 
 
Juniper Business Use Only
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, March 26, 2021 2:21 = PM
To: Ira McDonald <blueroofmusic@gmail.com>Cc: rats@ietf.org; Smith, Ned <ned.smith@intel.com>; = Eliot Lear <lear@cisco.com>; Guy = Fedorkow <gfedorkow@juniper.net>; iotops@ietf.org
Subject: Re: [Rats] 802.1AR device = identity
 
[External Email. Be = cautious of content]
 
I got my copy of = 802-1AR.
 
I=E2=80=99ve made a PR that
  =  1) Adds an SUEID to EAT that is similar to LDevID in that it can = change on device life-cycle events
   2) Adds a whole appendix = discussing the relation of IDevID to EAT
 
=46rom= reading 802.1AR, it=E2=80=99s pretty clear that IDevID is permanent. = Here=E2=80=99s one sentence:
These additional operations can include deletion of the = IDevID certificate or IDevID key, which can be logically equivalent to = decommissioning the device, 
802.1AR also provides for an LDevID = that is less permanent in the ways that Giri seems to be asking for.
 
Please= take a lot at the PR. It does a little compare and contrast between EAT = and IDevID. I am interested in comments on it.
 
LL
 
 

 

On Mar 11, 2021, at 11:13 AM, Ira = McDonald <blueroofmusic@gmail.com> wrote:
 
Hi Laurence,
 
Thanks= to the wonderful *free* IEEE Get 802 program, you can go to this link = (from Guy earlier)
and create your own durable free Get 802 account = and then download IEEE 802.1AR-2018 (and
anything = else from the whole IEEE 802 series that you need).
 
https://1.ieee802.org/security/802-1ar/
 
Cheers,
- Ira
 
 
 
On Thu, Mar 11, 2021 at 2:02 PM Laurence = Lundblade <lgl@island-resort.com> wrote:
I want to unpack and = unfold a few things here. 
 
Permanence / Lifecycle / Privacy =E2=80=94 I = think the main topic here is about when an ID changes relative to the = lifecycle of the device and how this relates to privacy.
 
Compromise =E2=80=94 I think compromise due to = algorithms being compromised or the device being owned or such is a = separate topic. Discussion of it seems orthogonal, should go into = security considerations and really comes down to certification in the = end if you really want to lock it down.
 
I=E2=80= =99m not sure which is meant by =E2=80=9Cimmutability=E2=80=9D in the = previous emails.
 
My intent in the definition of UEID was = that it is truly permanent. It doesn=E2=80=99t change at any time in the = lifecycle of the device. This is the simplest case to describe. It is = not at all privacy preserving for some use cases (e.g., mobile phone), = but is OK for others (e.g., dumb sensor). 
 
I = was thinking other folks might define other IDs for other use cases. = Maybe the time has come to invent one or two of those and put them in = EAT.
 
Some Solutions
One = possibility is an SUEID, a semi-permanent UEID (maybe not use SPUIED). = It is allowed to change in major events in the devices lifecycle such as = events when ownership changes, the managing entity changes or on factory = reset. I think this lines up with the way some MAC addresses are managed = for privacy reasons. This line up is good because a UEID can be an IEEE = MAC.
 
An RP might receive an EAT with only an = UEID, only an SPUEID or both. The RP can decide what they want to = use.
 
 
Another one is for the Attester to authenticate the Verifier = and/or Relying Party and generate a distinct UEID or SUEID just for use = by that RP. This is a solution to the privacy issue. I=E2=80=99ve = actually done an implementation of this one.
 
 
A = related solution is to have a privacy proxy between the Attester and the = Verifier that makes RP-specific UEIDs or SUEIDs.
 
 
Separation of ID from Attestation Key
An ID = that is not signed is nearly useless because anyone can forge it so = we=E2=80=99re always talking about some sort of signing.
 
EAT = intentionally separates the ID from the signing key. I haven=E2=80=99t = read IDevID, but I don=E2=80=99t think it has this separation. The = reason EAT separates them is to have a lot of flexibility to deal with = the privacy and lifecycle issues that come up in real deployments for = chip makers and complex supply chains.
 
For = example, FIDO uses group attestation keys to deal with the privacy = issue. One key is put into 100,000 plus devices which makes it = statistically not very useful for tracking users. Maybe the device = manufacture uses this tactic for billions of devices. Then maybe a use = case involving only millions of these devices needs a truly global ID = and have the means to program it. This can work if the keys and IDs are = separate.
 
Or maybe the manufacturer changes = signing schemes moving from a primitive MAC to EC-based pub key and onto = some sort of DAA while maintaining the same scheme for device IDs.
 
 
Possible harmonization with other Device IDs?
I noticed = that birkholz-rats-suit-claims mentions a device ID based = on UUIDs. We should probably take a look at how this relates UEID. = There=E2=80=99s probably others to check out. We probably want to re use = a lot of the claims from Evidence in Attestation Results so they can be = pass-through for the Verifier.
 
Note = also that UUIDs are obsolete now.
 
LL
 
 
P.S., = Any suggestions on how to get access to IEEE IDevID? I=E2=80=99m not = part of a big company. I tried joining IEEE once, but that wasn=E2=80=99t = enough to get access.
 
 
 
_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

= --Apple-Mail=_6FE77F6B-3ED6-4F30-807C-36AEBBC41A39-- From nobody Thu Apr 15 10:10:14 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56B3A2776 for ; Thu, 15 Apr 2021 10:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fraunhofer.onmicrosoft.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 meM0nmYVOd9Q for ; Thu, 15 Apr 2021 10:10:07 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 CF6193A2770 for ; Thu, 15 Apr 2021 10:10:05 -0700 (PDT) IronPort-SDR: kE9MffzFLDIho/Y7vE4kT8Svqi6T38ujmFCuvcqdJbunhKglLscd8h+3FP1NsOVV7jZzqTSs5B GIV8gO5kcP7g== IronPort-PHdr: =?us-ascii?q?A9a23=3ATaKxrhEI5lQBLwv4G9lokp1GftgY04WcBSYc9?= =?us-ascii?q?4YnhrRSc6+q45XlOgnF6O5wiEPSNa3a5u5Kze3MvPOoVW8B5MOHt3YPONxJW?= =?us-ascii?q?gQegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aF?= =?us-ascii?q?hD2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDKt9VQj5FrN6Axz?= =?us-ascii?q?RXEuD1Edrc++A=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H2AADZcXhg/xmnZsA+HBwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggEEAQELAYFSKSh+gUELhDhXgnIBAYU5iECZbIFCDIEFA1Q?= =?us-ascii?q?LAQEBAQEBAQEBBAECAQEqCAIEAQGFB4FAASU3Bg4CAwEBDAEBBgEBAQEBBgQ?= =?us-ascii?q?CAoEAhVANhk8EJB0BATgEFEQCNA4dDQgBAYJtAYJVAw4gAQEDC0CPJpBtAos?= =?us-ascii?q?YgTKBAYIEAQEGgTcCAQ1BMhKCWBhYgTQHAwYJAYEvAYJ3hkuEEicQgVVCgRM?= =?us-ascii?q?nD4QugVwCAgEXehKDUYJgggZkgRcEZlufAw2KUI9WgigsB4FzgRyBIAYLg1S?= =?us-ascii?q?EYpMRBQsfgzwSinuEbHYGiXqGUKEGl0gCBAIEBQIOAQEGYoEIgX5NJIIRGIE?= =?us-ascii?q?PUBcCDleNSAwLC4ECAQiCQ4UUhUdxAjYCBgEJAQEDCQF7iwMBgQ4BAQ?= X-IPAS-Result: =?us-ascii?q?A2H2AADZcXhg/xmnZsA+HBwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?gEEAQELAYFSKSh+gUELhDhXgnIBAYU5iECZbIFCDIEFA1QLAQEBAQEBAQEBB?= =?us-ascii?q?AECAQEqCAIEAQGFB4FAASU3Bg4CAwEBDAEBBgEBAQEBBgQCAoEAhVANhk8EJ?= =?us-ascii?q?B0BATgEFEQCNA4dDQgBAYJtAYJVAw4gAQEDC0CPJpBtAosYgTKBAYIEAQEGg?= =?us-ascii?q?TcCAQ1BMhKCWBhYgTQHAwYJAYEvAYJ3hkuEEicQgVVCgRMnD4QugVwCAgEXe?= =?us-ascii?q?hKDUYJgggZkgRcEZlufAw2KUI9WgigsB4FzgRyBIAYLg1SEYpMRBQsfgzwSi?= =?us-ascii?q?nuEbHYGiXqGUKEGl0gCBAIEBQIOAQEGYoEIgX5NJIIRGIEPUBcCDleNSAwLC?= =?us-ascii?q?4ECAQiCQ4UUhUdxAjYCBgEJAQEDCQF7iwMBgQ4BAQ?= X-URL-LookUp-ScanningError: 1 X-IronPort-AV: E=Sophos;i="5.82,225,1613430000"; d="ics'?scan'208";a="41905118" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2021 19:10:02 +0200 IronPort-SDR: GlQGEjVK9pEAtilWvDK/xaomonQNOKvbA5/hdzQM24c0yoURdhe2NSYOcVv1I06HnszfayCCo5 yWsrE2kibWYow1BYqL3l+PAiQYwPI6GAw= IronPort-PHdr: =?us-ascii?q?A9a23=3AvnqhoxbdOUXyCdHZsk1m+j//LTDXhN3EVjU94?= =?us-ascii?q?4c7i79IbqWo9ojjO0qa//h2kVvVRu3z6v9YhazRqa+zEWAD4JPUtncEfdQMU?= =?us-ascii?q?hIekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBU?= =?us-ascii?q?hn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCErcgKx4V4I7s3y?= =?us-ascii?q?hzHr2EOd+kFrV4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AlNgZN6Pk9HpNnMBcTu2jsMiAIKoaSvp033?= =?us-ascii?q?AA0UdtRRtJNvGJjszGppQm/DL9lTp5YhAdsP+aPq3oex3h3LpUxaVUAru4Rg?= =?us-ascii?q?nhvwKTXeJfxK/v2SfpFSG71uM178pdWpNzAtHxElR25PySiGLTL/8b3NKF/K?= =?us-ascii?q?q07N2z815RS2hRBJ1d0w=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAwBVcnhg/z6wYZk+HBwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBSYE4BAEBCwEBgVEpKAdMK1okQwuEOFeCcgEBhTmIQGkBmQK?= =?us-ascii?q?BQgyBBQNUCwEDAQEBAQEEAQIBASoIAgQBAYUHgT0CJjcGDgIDAQEMAQEFAQE?= =?us-ascii?q?BAgEGBHEThVANQwEMAYV1BCQdAQEUJAQURAI0BwcdDQgBAYJtAYJVAw4gAgM?= =?us-ascii?q?LQI8mkG0CixiBMoEBggQBAQaBNwIBDUEyEoJYGFiBNAcDBgkBgS8BgneGS4Q?= =?us-ascii?q?SN4FVQoETJw+ELoFcAgIBF3oSg1GCYIIGZIEXBGZbnwMNilCPVoIoLAeBc4E?= =?us-ascii?q?cgSAGC4NUhGKTEQULH4M8Eop7hGx2Bol6hlChBpdIAgQCBAUCDgEBBmKBCCS?= =?us-ascii?q?BWU0kghEYgQ9QFwIOV41IDAsLgQIBCIJDhRSFR3ECNgIGAQkBAQMJAXuCX4g?= =?us-ascii?q?kAYEOAQE?= X-IronPort-AV: E=Sophos;i="5.82,225,1613430000"; d="ics'?scan'208";a="108817090" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO XCH-HYBRID-02.ads.fraunhofer.de) ([153.97.176.62]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2021 19:09:57 +0200 Received: from XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Thu, 15 Apr 2021 19:09:56 +0200 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5 via Frontend Transport; Thu, 15 Apr 2021 19:09:56 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MAEw8A+R3Dnr4jvdiey1oyfLeDURWUyehQA/Ks+5bkY3XVfC2aqjkeXSFNHhTbf7P20am54wtDz+F2eh+k2bO+xw0UV2RSY8ZQjIi1U79sBm3N8ItWzN2IqzKBdFENY+4GJlIAaLTfkE1b5ugecYPQipHAaen8Y7rCWxGXOt1Wa+qGCBmh5hESVPucLWFm4gm1IrIHc3uUju6XFagfmUDaAcRmTu7ARqgfh3yCiWwiWvmjrhsQxzj9v52whsdlnIHgxsG3By8g1C7WjT2Nlm599J9FX070s9nVG/c6gbOVdTZ8hIHifxtfVcAnA6KkRCiGyoJlWpJes6ql2c19oZnA== 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=v6RNWOfchl1kX1fuMbCBwsoNP+igmNFg5s74Ay1d8FI=; b=lJQtTenEokxVQiyGW17EWgTo3Y6HEks+Y9ojOt1CgXP0zqxjXS0vgQBwUx28Nk0TXZDdauwGoX1dB4V13rwcXd4MKDuZRVYsTV5+09gbZ7e832RCmZSb4+qWENrRi8Vf5LQYJmHqroDqa9RAQEShS4T4xJNplx7N25LBs2PF6r9Tr7xWsb5NG0mR1Cg/1khDsCrmHxRzxQfXm79s7HAM8/c3xmrayJEwO8fsEFIbfLbaYcx+Xcda8RowFur7vqskI7VNtVvybXuP/YYFNxUxSBh5kpSwsjw2Y6avgQkNxpsWKNqy6W3jW41cOpshjtOkw4CHbvu4UXrZsG+WcaOlaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v6RNWOfchl1kX1fuMbCBwsoNP+igmNFg5s74Ay1d8FI=; b=KcI7hkPWA7HjhH0bEuRn4QU2YS5T92hKwbWU+kzwtma8Cs1sdJIlEx3QbC3GOqxu11DR0OJxzK2T/A/d0Z/Fk0rB8BHKKnEtMpCP8AvCqwtP03yrLOaVTF4TKFkh4YKZt6x54fFVc2GOe1g6QCfRnlJ6CovKoC8cdrnxYplKPpw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from AM9P194MB1316.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:3aa::19) by AM0P194MB0594.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:163::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Thu, 15 Apr 2021 17:09:55 +0000 Received: from AM9P194MB1316.EURP194.PROD.OUTLOOK.COM ([fe80::f190:c3b1:4213:d69f]) by AM9P194MB1316.EURP194.PROD.OUTLOOK.COM ([fe80::f190:c3b1:4213:d69f%7]) with mapi id 15.20.4020.022; Thu, 15 Apr 2021 17:09:55 +0000 From: Henk Birkholz To: IOTOPS Working Group Reply-To: "iotops-chairs@ietf.org" Message-ID: <1318ac7a-a0bc-15c6-e3bc-c3c3384aca24@sit.fraunhofer.de> Date: Thu, 15 Apr 2021 19:09:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/mixed; boundary="------------9EB977DBCC6E72E8406B6DA8" Content-Language: en-US X-Originating-IP: [79.234.119.37] X-ClientProxiedBy: PR2P264CA0006.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101::18) To AM9P194MB1316.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:3aa::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.234.119.37) by PR2P264CA0006.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Thu, 15 Apr 2021 17:09:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f6353e08-219c-4350-24e7-08d900314aad X-MS-TrafficTypeDiagnostic: AM0P194MB0594: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Z2gARp3KApzMSI0ByYzYuSIBASXnQDp7er0STJZLBaOw3R1AmHVNX06Kx6qidLdXJ7h0+p77IYHg7UJuqfAD11QShRaPJvxcI4jUl+XKcm4EzL22cCSCHXt9+er9yQj8ZshzPV5BmAMowKDfwoEKzyIrP4qmBQgrsqpJKOQgiy7SzEazW8FpNJeqK+xbWrNzXbGqFU7Zssnvr0yFPz895vhtes6vgv0lwRXe/pq4YvF4jOEehKxTyicoHlyCgDbLlhlXXkLH1ns9YqQXWT0x0Azbt3i0PcesUAfIvtwH3vzXjf8Jm2Rhf+Mr5gO1Vgmb1GoH9DuOi/dJ+r5Rz3EaDemkQB6DC3sAvQ9B8kuryOuRk/kXO6mTkvxwNjSqgy5QQ5PPLz3edUeHYRwOSTsCcSb+Yd7lVTyI8e3BPI1bWHCxsKbAgpAEgfY60fU1S/c+wpbW8gBFsGSARjxScXrNQ9Hd5tstJIXbTZ9TB9QWccQC4sfbusdQbAjrdv9H6aC1JL/OD4lfVuUWfBIzslJIfBf/h0wQBRGL7CDlq091pbUB3UwMpPnwKTiyevMe16V6PspYsX1bbJS8isYvAyHuAFeE7L6MB7YYm2En+5jUSMQ7TsZJvGd1byC58jHcjOgu5/40WLP0hHt2W9WtAXO+Odidx3HuxVv1CqlRaDqli63JqI5S1whBy4rEMRzAbHEEKfxmddqiBmSgzfyf5ICxzDYFYFGIhrggOozdsnmKmPl/DxEnqM+Oi6ZVpIGgO63zDO53YaGd2qKa9StfYpITOAcG0YalBWYuwcdGDejrKVA= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P194MB1316.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(396003)(39850400004)(346002)(6486002)(38100700002)(16799955002)(6916009)(16576012)(186003)(16526019)(33964004)(66806009)(83380400001)(235185007)(66616009)(31696002)(66556008)(2616005)(316002)(86362001)(8936002)(2906002)(8796002)(956004)(5660300002)(66476007)(478600001)(38350700002)(31686004)(44832011)(26005)(52116002)(66946007)(966005)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?cnVKVHlYeVJ0RDNQMmFEaFFqa1pnQ3g5TmJ1T3N1d25IY2FjMkRaS1hnUThu?= =?utf-8?B?S2kyVXNBWWFua3ZjUytRNFFyNzY3SEVZNU5pczFBRTk5ekVKbGE4ZnVJci92?= =?utf-8?B?MG1IMXB3Nk9MY3VRcHdFMVJmNVNCZ21jNEdoRVJWY1ByVjlhd3Q1bWhDVWZI?= =?utf-8?B?MDBjQ3R1bi9ZK0IwS3RMWnk5NjFxNG5NZGloNmE4M2R0VVNrb2ZKYjgyRURJ?= =?utf-8?B?NlFNNWo2NHVFbmNRNUladTQzUHU3YkE5L0FUcW1ybS9Ldi9UM0lCWFhIMXYz?= =?utf-8?B?RDdTbFJKSksxSUZjQU1JcFVrUEdqMDB0KzMvbUwwd2JWZ010WDl1TFNLaHRi?= =?utf-8?B?NmtrNFM5enVBN055MDU1UnAvSFpXREUrYWZnS3ExMFdYVEp3WHZkTTV4cC9w?= =?utf-8?B?Y2pqUFV3cHpyUmZuMzd2QUVTVnRWV0JsK3FTdUdhelIxM0wzR2YyVkIwQW1X?= =?utf-8?B?RElEalRPczZLNmJQMzJtM3BxOHY4MWcvZjVPRmRQYnVtKzIrRmJtMjFoV1VH?= =?utf-8?B?VUhkTDdlVE44V2NSM1p4Ym9qT3NnK21OWXArdXN2ZHFHNjM4YnZ0azducUR2?= =?utf-8?B?TGtKcXpzNjFUTzBxdFNubnZnY2VqeERXbTg0eE1saXgyUVlXWWQya3ZlNmov?= =?utf-8?B?VDZCWFRwemE0cCtReWhJVTdVMlIrQXZ3enIzeXpxMi9NNmhaeTdqL2VPQlpV?= =?utf-8?B?eGxxOTgxZW5oNEU0MUZjamVjZVROSVRDUTdpTmFwT2V0K0d3VlZqM2MyREFL?= =?utf-8?B?aDdOT3ZmZWx4WTc0TkdMaSs1emtycU0yMUFPbXIwTStiaWxBdFFUcGJ2T0FS?= =?utf-8?B?YlhoOWpPblloTytzWUdBODNhZytIcUd1SE1tbGZkdnpQMjRWR0JxZGs2a1o3?= =?utf-8?B?c1hDRHdXR0pteWo1SmNVdUtSdzBQSU1ZR2RXLzBDSk5nY0Y0bEYxR0h0cXJP?= =?utf-8?B?bFVBc3JlbWRFRFJCSUIrcGVobTFlT1NudlpjNUdJTTIyM2RBRmZaRG5jeWls?= =?utf-8?B?MXpKbldmS0laSU5HWGRlQU0vZ2FTclB3MURJOHRXQVB4dW9JZ25zUXNQQXRy?= =?utf-8?B?WGdHM0lPOUpPZjR6Y01nNWlNUHFIdmNaK0xjZDNYaVdEZ3BJaWFTQmp5V3Fl?= =?utf-8?B?MWpxOHk1bWN2cWxtdG1KQ0tiQW9Cbk5uWS9rbW8veEY2QkNnQVJFWjV0VUdH?= =?utf-8?B?VmhqWnVpTVVHSUJTeDA5SFk3cytrdVV0TjJVcy9RUVpIbzI4cHdiaXBBZ2p2?= =?utf-8?B?OFlPdkJoREpLY2h0bkRNT3N5bkUwTXVxY1J3WTlrcUs2aXZOajFkQTJSekkw?= =?utf-8?B?Ykd5c2NzZm5iallXYWVoaW5BcU1mci9wdmUvZVlzeFJ5NUhzQ0tmWVEzTUxU?= =?utf-8?B?eEtXL1pHWFNld1JJelRxOXNLajZUVFN2ZU5BV28yK2JveWgwTFBNVlRvQ0to?= =?utf-8?B?SmNMaHlWQytkSCtrQU1xS3dSeEw5UXlsMXg3WlFMYmlqTzZJZkppQkFRVmlZ?= =?utf-8?B?OGNsOTNZVG5BQWVYUUlzblZiTHMvNTR0RUR6VERuejNkK0k4OTVUZHpCN3F6?= =?utf-8?B?d0hDV1RqTy83UVd6ZGlDSEVkQ2RWOU9mRGh6NFZNNUR2UEZmVVFZNFMrRWtK?= =?utf-8?B?aUpsY2NxUXB3eW80cFBDbW5wblN6QWoweXM3b2tNbWE4dEpMY3M3Y1RSL29p?= =?utf-8?B?THMwWG9oaVNQa1BCaXozRE1leU95alB0NVZ3ckY2QksxRWdzUjdhL1M3cmJD?= =?utf-8?Q?qR/3X7g11X/cL/LwoM8n5+zNG3K4bdNYzsfaIVY?= X-MS-Exchange-CrossTenant-Network-Message-Id: f6353e08-219c-4350-24e7-08d900314aad X-MS-Exchange-CrossTenant-AuthSource: AM9P194MB1316.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2021 17:09:55.6870 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oYcMiMGjoEhun9/sxybmIiIEfkHwrVxEP34DhMNioaHFpggMNzEdILL/orHsIVwd+Ll3B8stl1kwHigx8dyfO1v+PHTH3BWX64BIEKxQ03s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0594 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 17:10:12 -0000 --------------9EB977DBCC6E72E8406B6DA8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear IOTOPS members, a quick reminder that the first IOTOPS WG virtual interim is coming up this Tuesday at 15:00 UTC via Webex: > https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e The preliminary agenda (only confirmed presentations) can be found at: > https://datatracker.ietf.org/doc/agenda-interim-2021-iotops-01-iotops-01/ The virtual interim duration is scheduled to be 2 hours of which a significant amount is dedicated to discussions on presentations and beyond. Please, find attached the information to join the meeting. For the IOTOPS co-chairs, Henk --------------9EB977DBCC6E72E8406B6DA8 Content-Type: text/calendar; charset=UTF-8; name="ietf-interim-2021-iotops-01-invite.ics" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ietf-interim-2021-iotops-01-invite.ics" BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH PRODID:-//IETF//datatracker.ietf.org ical agenda//EN BEGIN:VTIMEZONE TZID:UTC BEGIN:STANDARD TZOFFSETFROM:+0000 TZOFFSETTO:+0000 TZNAME:UTC DTSTART:19000101T000000 RDATE:19000101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:ietf-interim-2021-iotops-01-13632-iotops SUMMARY:IoT Operations WG Virtual Interim (ietf-interim-2021-iotops-01) LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e STATUS:CONFIRMED CLASS:PUBLIC ORGANIZER;CN="IOTOPS Working Group":MAILTO:iotops-chairs@ietf.org DTSTART;TZID=UTC:20210420T150000 DTEND;TZID=UTC:20210420T170000 DTSTAMP:20210322T093140Z DESCRIPTION: Agenda: https://datatracker.ietf.org/meeting/interim-2021-iotops-01/materials/agenda-interim-2021-iotops-01-iotops-01\n \nMinutes (Minutes interim-2021-iotops-01: Tue 15:00): https://codimd.ietf.org/notes-ietf-interim-2021-iotops-01-iotops?edit\n END:VEVENT END:VCALENDAR --------------9EB977DBCC6E72E8406B6DA8-- From nobody Fri Apr 16 10:55:19 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC51B3A2E28; Fri, 16 Apr 2021 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.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 wLb9k42Ek_oi; Fri, 16 Apr 2021 10:55:11 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 5A52E3A2E25; Fri, 16 Apr 2021 10:55:10 -0700 (PDT) IronPort-SDR: tJBeZLP/tWY6ASIVCc7csHUzgHETpSwcPFug16wKTo/HWPCG0fsBMocA21mJOWQMZ1PyVHvYUQ pMhHmsOW0mJw== X-IronPort-AV: E=McAfee;i="6200,9189,9956"; a="194637271" X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208,217";a="194637271" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2021 10:55:07 -0700 IronPort-SDR: /FdPzPbY0pFOT4qSC05eeMyB6eImkX5nGSjM85jroCPYDYASDkWeXwbFKP8CgGyViWNb1tcz0e XkCNeMfQBs/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208,217";a="533527927" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga004.jf.intel.com with ESMTP; 16 Apr 2021 10:55:07 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 10:55:06 -0700 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 10:55:06 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Fri, 16 Apr 2021 10:55:06 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.171) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Fri, 16 Apr 2021 10:55:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1ATzJkDsE8F/CsjusRjVBd9r3nVC6j+WECUNqfH2m5L5leOIcSrWPte6PYjL65ATx19SeQTw7HB5x45uPvk2mQRCFr49qVogSxOVBTLGA962cY3ZrB2C1h27sVZywj/b2cle9aIVIPsOwG7SNCDmOGR5ORmYmqTc7qhU6Ry6lnecvGBxSKa54CxiaMYoIlwCXH6y4KgtF+9zGxzuVarBlR69aveDJEzoZrY7nVnRkMrlWx3+zyCa53X5e2o1erpYKidCjqshsL3VZMJ0hxt0W6mFadohIgk30uf8NOq+pNc0wBDBh3+L0cTK2M2hOfSV2k7pcnYZpLXv2d6ps5VfA== 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=f2MUVIUsyso/UlD9MFy/qtrW1I10hc0+TZvFn11slAw=; b=FkCL3BlBRJpCe2bw27BO5WUgpum5IuWtRNxhot9nD3vFHnzQyTGHmJao5TPG5/HR6vibywHBdMpgNXcjPaX7fs4BENXYS6B0pEQkEr9TjYpPv2zXhmKO8u0opJXx0xTXAI31HLoU34Ie8dsODn/LMfPruqZk1ISOT+MXutLk8FmkIUBsBfjDsazHdFWC4IbzE4QnBNPwtSiCKHrVC6LzB3Rjq4g47W8h8t5CAXwSbm8EJkrnVcJGYlwkrZpK82byzszPIx4qiLPe9l4Vna/0tMDewRCzUKDFDFzbhWuaztJsSElXNfvMAK2nGClJsEv+31hGFCBsE9mbTwoJ17d0nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f2MUVIUsyso/UlD9MFy/qtrW1I10hc0+TZvFn11slAw=; b=GNuYc/XqCLs8Jmm7EsfbaLOGuZlmtsBXEd6ZqMmd5FQ+BNGzJKCQLfDgAns828G5EIK/WE2qw15Ndj0gBOJpQbIcStpUaDkxGctp+6mCkEtnGBJbHozm9sdQFYz2TMm33PKWztxyg8QcARGHeT8EDCGa0BlfpHWfxNchd69CdQU= Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by CO1PR11MB4945.namprd11.prod.outlook.com (2603:10b6:303:9c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Fri, 16 Apr 2021 17:55:01 +0000 Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2%6]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 17:55:00 +0000 From: "Smith, Ned" To: Laurence Lundblade , Guy Fedorkow CC: Ira McDonald , "rats@ietf.org" , Eliot Lear , "iotops@ietf.org" , "Henk Birkholz" Thread-Topic: [Rats] 802.1AR device identity Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOAgACzxwCAAAOuAIAXhE8AgArnz9CAEXR1AIAEKBoA Date: Fri, 16 Apr 2021 17:55:00 +0000 Message-ID: References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com> In-Reply-To: <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [50.53.43.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b696b0d0-f829-482e-cd68-08d90100c149 x-ms-traffictypediagnostic: CO1PR11MB4945: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:308; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZxpSYOBAAiqVPPZdOejoYfWGsRizzQlu1yiWtZ8jjcH4YT6p1adccwul4pYZWy8JuvG8YFVszEVMlnHx2s2VWVG5GgisgRgp8Sd559w4FGGXzM8RIl4Q+ivpgWDpi6zk1M8WWgD9U0osX1Hc9MZKbGgNZXvwVMLQ2L0EUx1ZOCA9zyAMHnZtUX3aI0PPhUSjFT6hYOCqQbVRCRw6lTVFYohHfLxSX/OTHzFkZlarYW1PL2S6v3vB+vM/RPmuqQ1Y4JyRZNcIALaBPPIMoeuaL6w7k0AODNqXexhuzpQKRgb07ALbagun+uwvbnP09NabYj+Bh+/eIvfZ6btXh+nuyFq3G9L5CYCrKgfWtCCZnenwlzHwoQWio9Fp+5k2KHLOtGgIYB6ujtVAYd2jXtsgKnk+1m0HUncJ+cKx9eGDdA3RMOSqeDujBhxySRn8E0cDtS9517xrrN1JvgwB44MUzizUWJ3PW8tBtWjKph3NjakbFk2JjBjgB7u7I2Zf0nfA8Y6MdmS/hhKUQgHQJrD4YbQ7CSQt0JuoZTWW8+FkeX05o3wnzshQVbeOe60hGFklThNk5W3DesxUy2/nAbEjyGgyLGdErSGiaCNlei4r8ab6Ud0hWNfzATxCFv203ZALx/Evw721V3DJFTeg3gu20adLZgf1q3wTTEhSWXwu3kFJPeDEjHls0dBkyyaiiW7MffDNlOe/xWvCN55mTvmS3teKOQ7Eeb7UhPpGFcd+SMTrJ4jdJli1FBxL0SlSUOv3/34FO//5DdhmayKfvoUHwr4JxMVE9+z66rUhB7WGbD4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(396003)(366004)(346002)(136003)(5660300002)(83380400001)(2906002)(26005)(316002)(6486002)(8676002)(110136005)(478600001)(6506007)(966005)(122000001)(38100700002)(186003)(6512007)(53546011)(64756008)(66446008)(66476007)(4326008)(54906003)(166002)(33656002)(71200400001)(76116006)(2616005)(8936002)(66556008)(86362001)(36756003)(66946007)(134034003)(15398625002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?dS9rS21lVVVuUWZXcElYanpzVzNlYjVaaHgycHNncWFrV3BFNlhVLzZpWnVO?= =?utf-8?B?MkxkSkhjYThuRUJlTENyRlhodDZxMmMxUmFwaWNONkJkN08rYUtFVS9yQlVv?= =?utf-8?B?d1ZGUkY1aHdVTFpGM1pNYUN5eVF6YnBqRkZXb2swRDMvdENka2c1ZmM2MXd4?= =?utf-8?B?SzZiUDRUejVpNCtRM013bmJ5dFE1RncxTVVBZkxQM1ozeHA0YjZCdXMvTjdZ?= =?utf-8?B?VE43U0xCTE5SU1NvY2VuVk9MN3ZsVXVTd1p2cm9DenJ1cFlEK0pNM0J2aWFS?= =?utf-8?B?QUlEdEZ3bFhITEUrc1JMbVZoelF4WGd5cms4dDVzVzZkUU5hYTJJcGZUZ3d3?= =?utf-8?B?V3ErM0d5Zm4xQkk3L3hTV2JLZ1dnZ3BCVHpnOSsvclpkMzNEZmY2Uzhad0FR?= =?utf-8?B?NWkvRmRIeVV5UUMxNGFKQS96QlZrQWNNVVRsWStOL2lIalJ4aUtmSXVFbmFo?= =?utf-8?B?YVV4VnhmUUxCc1IxanFkbFNnYXR6Z3g0dEc1cDZXSkVmYnMwaWp5MW5xeEdV?= =?utf-8?B?SlNBWW9vbGt5VGFUWUo4OVJWendmLytVRThkaDBXMFY1eVFhVGZweDhMRDlx?= =?utf-8?B?cVZIaGhxQ3J5TytaV1I3K0dheUVDZkpEdXlJZjlCVUZndHVmNTBDNkF1VG9s?= =?utf-8?B?YnNPY1Z2Zzgwazd1Mkh3Sk5XeUZiejVJajRMUVByL3NsZm53MG9lMUJwdHpZ?= =?utf-8?B?b0w1YWpIc1M1UVROanRnZERMTWdwYkF4OWYvUTZGWDRvREQxL0x1RDEwUFJO?= =?utf-8?B?NXZaSk1qT3dWRUdmU2h5QXhuMUdBeC9kVUlDNUNhQU16Vi9xWGFVem5oU0hG?= =?utf-8?B?V0M3RGwydGZScUJLRTduSENlNHVMMG5YTmR4YkM0MFJDTlpzRE1CSlpEYXJw?= =?utf-8?B?WjlHQkYyS0tiSXZMYjFkemx5S2U4T3RmdzJPOVIzNkNFcjhnZ3NWdk10ZzZF?= =?utf-8?B?VW0yZ2l1bVczaktuVFRKNXllcEthS2hraDd6b2JzWllDTzN3WER2cTd4WlBz?= =?utf-8?B?bWlmeHpSWXJxV2JOeUc1aVJrQVhJS1hWY3o4ODRqaVcyMFNTLy9KeWxHZTEw?= =?utf-8?B?dE1FVllLMFc3TUJ2aDhKUzBneFhQaGU0ZWtlYVNCY3lXS1dXVENIQzZQZjJN?= =?utf-8?B?UzlET0ZZSzEyZlNxSzBxYWNja0NzOVYvOW1WQnlXdHhQN3IvUzRLdUZOK2RL?= =?utf-8?B?UG9HYythOGZnSkN4b2QxaC9QWmlVSkRhVDBZTFIrbkNPNTFva0F5TUh1WEVO?= =?utf-8?B?Ymg0QytDZjZIZitqandqZVNaKzdkSmFsOEZ5U0xoeHdYTzA4emFPSkRIMm9K?= =?utf-8?B?bnFaYjhEd0NzLzAvR25wbnRwbjZZMStiUUhxai9QUThBOEx5VWFFUlZ2RUdm?= =?utf-8?B?OW9XRjFIMERDSm05bWprWWFLNXM3U2xiSWxZK3JwcWltQkRtVjViS3hIdkJ5?= =?utf-8?B?NjBFakFKRk9WanV1VkJmSUZmY1JpejM1Q1VqSXNzVStobFlOeWZwcE10VE5u?= =?utf-8?B?ejI4dTVOdTNwUUxwTU5Qd0R4dGMwQU1xVDR6d0RCajI3N2R0UkNlRHUvVjFp?= =?utf-8?B?OGhlN2Q0OWtycHlHNVpyRXNsbnhTVVhBckNnZ28rLzVJdE5jWWtDUko1R3ZP?= =?utf-8?B?VFVQS3VkMUlmeVFFSEwzRFppajB5MDNYRDl3Smx3ZFdsUHhVdkVBZFY5Wmla?= =?utf-8?B?NjJKbU5HUHBDUWlHTVQ3dm52ZFkrVHVYeGRqREdCRVFNZm1YZkpiL2hDdjBt?= =?utf-8?Q?xIjX6qSfH+i8RRmJ4gs8zXATrM0kIx02ulz18xh?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BD13AD1F0E35464C9D062CE4AC1372B3intelcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b696b0d0-f829-482e-cd68-08d90100c149 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 17:55:00.3515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QoZlVQbtMr6+O/NEgxMfK792+kMpeKGCkrxy85wbbZShCamb/NaLunhDr4lnWhuimOo3+GNOvS7HeERBCZ7ckg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4945 X-OriginatorOrg: intel.com Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 17:55:17 -0000 --_000_BD13AD1F0E35464C9D062CE4AC1372B3intelcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGV2aWNlIG9uYm9hcmRpbmcgaXMgcHJvYmFibHkgdGhlIG1vc3QgcHJldmFsZW50IHVzZSBjYXNl IGZvciBJRGV2SUQuIEJ1dCB0aGF0IGlzIG9ubHkgYSBndWVzcy4NCg0KRnJvbTogTGF1cmVuY2Ug THVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb20+DQpEYXRlOiBUdWVzZGF5LCBBcHJpbCAx MywgMjAyMSBhdCAxMjoyNiBQTQ0KVG86IEd1eSBGZWRvcmtvdyA8Z2ZlZG9ya293QGp1bmlwZXIu bmV0Pg0KQ2M6IElyYSBNY0RvbmFsZCA8Ymx1ZXJvb2ZtdXNpY0BnbWFpbC5jb20+LCAicmF0c0Bp ZXRmLm9yZyIgPHJhdHNAaWV0Zi5vcmc+LCAiU21pdGgsIE5lZCIgPG5lZC5zbWl0aEBpbnRlbC5j b20+LCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbT4sICJpb3RvcHNAaWV0Zi5vcmciIDxpb3Rv cHNAaWV0Zi5vcmc+LCBIZW5rIEJlcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVy LmRlPg0KU3ViamVjdDogUmU6IFtSYXRzXSA4MDIuMUFSIGRldmljZSBpZGVudGl0eQ0KDQpUaGFu a3MgZm9yIHRoZSBjb21tZW50cywgR3V5LiBBcHByZWNpYXRlIGl0Lg0KDQpBZ3JlZWQgdGhhdCBy ZXB1cnBvc2luZyBJRGV2SUQga2V5cyBmb3IgRUFUIG1pZ2h0IGJlIGEgYml0IHdlaXJkIGFuZCB3 cm9uZywgYnV0IGl0IGlzIHN0aWxsIHJlYWxseSB1c2VmdWwgdG8gdW5kZXJzdGFuZCBob3cgdGhl eSBhcmUgaW50ZW5kZWQgdG8gd29yayBhbmQgYXJlIGFjdHVhbGx5IHVzZWQgdG8gaGVscCB3aXRo IHRoZSBkZXNpZ24gb2YgRUFULg0KDQo4MDIuMUFSIHNlY3Rpb24gNy4yLjUgc2F5IHRoZSBrZXlz IGNhbiBiZSB1c2VkIGZvciBzaWduaW5nLiBBcHBlbmRpeCBCIGhhcyBpdCBwYXJ0aWNpcGF0aW5n IGluIGFuIEVBVC1UTFMgc2Vzc2lvbiBhbmQgZ2l2ZXMgc29tZSBvdGhlciB2ZXJ5IGdlbmVyYWwg dXNlIGNhc2VzLiAgTm8gbWF0dGVyIHdoYXQsIHRoZSBrZXkgaGFzIHRvIGJlIHVzZWQgdG8gc2ln biBhIG5vbmNlIGZvciBwcm9vZiBvZiBwb3NzZXNzaW9uLCBzbyB0aGVyZSBpcyBzb21lIHNpZ25p bmcgb2YgZXh0ZXJuYWwgZGF0YSBnb2luZyBvbi4NCg0KaHR0cHM6Ly93d3cudHJ1c3RlZGNvbXB1 dGluZ2dyb3VwLm9yZy93cC1jb250ZW50L3VwbG9hZHMvVFBNX0tleXNfZm9yX1BsYXRmb3JtX0lk ZW50aXR5X3YxXzBfcjNfRmluYWwucGRmIGxpc3RzIGEgd2hvbGUgYnVuY2ggbW9yZSB1c2UgY2Fz ZXMgbGlrZSBJS0UuIERvIHRoZXNlIHJlYWxseSBnZXQgaW1wbGVtZW50ZWQ/DQoNCldoYXQgYXJl IHRoZSBwb3B1bGFyIGFuZCB3aWRlbHkgZGVwbG95ZWQgdXNlIGNhc2VzIGZvciBJRGV2SUQ/DQoN Ckkga2luZCBvZiB3YW50IEVBVCB0byBsZWFybiBmcm9tIElEZXZJRCBoZXJlLiBUbyB1bmRlcnN0 YW5kIHdoYXQgSURldklEIGlzIGFib3V0IHNvIHRoYXQgRUFUIGlzIG1vcmUgY2FwYWJsZSBhbmQg Zml0cyBpbiBiZXR0ZXIgd2l0aCB1c2UgY2FzZXMuDQoNCkxMDQoNCg0KDQpPbiBBcHIgMiwgMjAy MSwgYXQgMTA6MDUgQU0sIEd1eSBGZWRvcmtvdyA8Z2ZlZG9ya293QGp1bmlwZXIubmV0PG1haWx0 bzpnZmVkb3Jrb3dAanVuaXBlci5uZXQ+PiB3cm90ZToNCg0KSGkgTGF1cmVuY2UsDQogIEkgYWdy ZWUgdGhhdCBJRGV2SUQgaXMgaW50ZW5kZWQgdG8gcGVyc2lzdCB0aHJvdWdoIHRoZSBkZXZpY2Xi gJlzIGxpZmV0aW1lLCB3aGlsZSBMRGV2SUQgaXMgbWVhbnQgdG8gcmVwcmVzZW50IHRoZSBjdXJy ZW50IG93bmVyLg0KICBJbiBUQ0ctbGFuZCwgYW4gSURldklEIGlzIG5vdCBhZHZpc2VkIGZvciBz aWduaW5nIGF0dGVzdGF0aW9uIGV2aWRlbmNlOyBpdHMgcm9sZSBpcyBsaW1pdGVkIHRvIGlkZW50 aXR5LCBwcm92aWRpbmcgcHJvb2Ygb2YgdGhlIHN1cHBsaWVyIGFuZCB0aGUgcmVhbC13b3JsZCBp ZGVudGl0eSBvZiB0aGUgZGV2aWNlIChpLmUuLCBzZXJpYWwgbnVtYmVyKS4NCiAgV2l0aCBUUE0x LjIgaXTigJlzIGFjdHVhbGx5IG5vdCBwb3NzaWJsZSB0byB1c2UgdGhlIElEZXZJRCB0byBzaWdu IFRQTSBhdHRlc3RhdGlvbiBldmlkZW5jZSwgYXMgYSBjb3VudGVyLW1lYXN1cmUgdG8gYmxvY2sg c3Bvb2ZpbmcgYnkgYW4gYXR0YWNrZXIsIHNvIHRoZSBUQ0cgZG9jcyBhZHZpc2UgYSBzZXBhcmF0 ZSBhdHRlc3RhdGlvbiBrZXkgd2l0aCBhIGJpbmRpbmcgdGhhdCBsaW5rcyB0aGVtIHRvIHRoZSBz YW1lIFRQTS4gIEkgdGhpbmsgdGhhdOKAmXMgbm90IGFjdHVhbGx5IG5lY2Vzc2FyeSBpbiBUUE0y LCBhbHRob3VnaCB0aGUgYWR2aWNlIGZvciBzZXBhcmF0aW9uIHJlbWFpbnMuDQogIFNvIGluIHRo YXQgY29udGV4dCB0aGUgc2VudGVuY2Ug4oCcW0VBVF0gc2VwYXJhdGVzIHRoZSBzaWduaW5nIHNj aGVtZSBmcm9tIHRoZSBpZGVudGlmaWNhdGlvbiBzY2hlbWXigJ0gc2VlbXMgcHV6emxpbmcuDQoN CiAgQnV0IGluIHRoZSBFQVQgZW52aXJvbm1lbnQsIHdoZXJlIHRoZXJl4oCZcyBubyB0ZWNobm9s b2dpY2FsIGJsb2NrIHRvIGFuIGF0dGFja2VyIHdpdGggYWNjZXNzIHRvIHRoZSBrZXkgdG8gc3Bv b2YgYW4gYXR0ZXN0YXRpb24gcmVzdWx0LCBJIGFncmVlIHRoYXQgdGhlIERldklEIGNvdWxkIGJl IHVzZWQgdG8gc2lnbiBhbiBFQVQgdG9rZW4gY2FycnlpbmcgYXR0ZXN0YXRpb24gZXZpZGVuY2Uu DQoNCiAgTGV0IG1lIGtub3cgaWYgSeKAmW0gbWlzc2luZyB0aGUgcG9pbnQhDQpUaHgNCi9ndXkN Cg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCkZyb206IExhdXJlbmNlIEx1bmRibGFk ZSA8bGdsQGlzbGFuZC1yZXNvcnQuY29tPG1haWx0bzpsZ2xAaXNsYW5kLXJlc29ydC5jb20+Pg0K U2VudDogRnJpZGF5LCBNYXJjaCAyNiwgMjAyMSAyOjIxIFBNDQpUbzogSXJhIE1jRG9uYWxkIDxi bHVlcm9vZm11c2ljQGdtYWlsLmNvbTxtYWlsdG86Ymx1ZXJvb2ZtdXNpY0BnbWFpbC5jb20+Pg0K Q2M6IHJhdHNAaWV0Zi5vcmc8bWFpbHRvOnJhdHNAaWV0Zi5vcmc+OyBTbWl0aCwgTmVkIDxuZWQu c21pdGhAaW50ZWwuY29tPG1haWx0bzpuZWQuc21pdGhAaW50ZWwuY29tPj47IEVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+OyBHdXkgRmVkb3Jrb3cgPGdm ZWRvcmtvd0BqdW5pcGVyLm5ldDxtYWlsdG86Z2ZlZG9ya293QGp1bmlwZXIubmV0Pj47IGlvdG9w c0BpZXRmLm9yZzxtYWlsdG86aW90b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtSYXRzXSA4 MDIuMUFSIGRldmljZSBpZGVudGl0eQ0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9m IGNvbnRlbnRdDQoNCkkgZ290IG15IGNvcHkgb2YgODAyLTFBUi4NCg0KSeKAmXZlIG1hZGUgYSBQ UjxodHRwczovL2dpdGh1Yi5jb20vaWV0Zi1yYXRzLXdnL2VhdC9wdWxsLzEwMT4gdGhhdA0KICAg MSkgQWRkcyBhbiBTVUVJRCB0byBFQVQgdGhhdCBpcyBzaW1pbGFyIHRvIExEZXZJRCBpbiB0aGF0 IGl0IGNhbiBjaGFuZ2Ugb24gZGV2aWNlIGxpZmUtY3ljbGUgZXZlbnRzDQogICAyKSBBZGRzIGEg d2hvbGUgYXBwZW5kaXggZGlzY3Vzc2luZyB0aGUgcmVsYXRpb24gb2YgSURldklEIHRvIEVBVA0K DQpGcm9tIHJlYWRpbmcgODAyLjFBUiwgaXTigJlzIHByZXR0eSBjbGVhciB0aGF0IElEZXZJRCBp cyBwZXJtYW5lbnQuIEhlcmXigJlzIG9uZSBzZW50ZW5jZToNClRoZXNlIGFkZGl0aW9uYWwgb3Bl cmF0aW9ucyBjYW4gaW5jbHVkZSBkZWxldGlvbiBvZiB0aGUgSURldklEIGNlcnRpZmljYXRlIG9y IElEZXZJRCBrZXksIHdoaWNoIGNhbiBiZSBsb2dpY2FsbHkgZXF1aXZhbGVudCB0byBkZWNvbW1p c3Npb25pbmcgdGhlIGRldmljZSwNCjgwMi4xQVIgYWxzbyBwcm92aWRlcyBmb3IgYW4gTERldklE IHRoYXQgaXMgbGVzcyBwZXJtYW5lbnQgaW4gdGhlIHdheXMgdGhhdCBHaXJpIHNlZW1zIHRvIGJl IGFza2luZyBmb3IuDQoNClBsZWFzZSB0YWtlIGEgbG90IGF0IHRoZSBQUi4gSXQgZG9lcyBhIGxp dHRsZSBjb21wYXJlIGFuZCBjb250cmFzdCBiZXR3ZWVuIEVBVCBhbmQgSURldklELiBJIGFtIGlu dGVyZXN0ZWQgaW4gY29tbWVudHMgb24gaXQuDQoNCkxMDQoNCg0KDQpPbiBNYXIgMTEsIDIwMjEs IGF0IDExOjEzIEFNLCBJcmEgTWNEb25hbGQgPGJsdWVyb29mbXVzaWNAZ21haWwuY29tPG1haWx0 bzpibHVlcm9vZm11c2ljQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBMYXVyZW5jZSwNCg0KVGhh bmtzIHRvIHRoZSB3b25kZXJmdWwgKmZyZWUqIElFRUUgR2V0IDgwMiBwcm9ncmFtLCB5b3UgY2Fu IGdvIHRvIHRoaXMgbGluayAoZnJvbSBHdXkgZWFybGllcikNCmFuZCBjcmVhdGUgeW91ciBvd24g ZHVyYWJsZSBmcmVlIEdldCA4MDIgYWNjb3VudCBhbmQgdGhlbiBkb3dubG9hZCBJRUVFIDgwMi4x QVItMjAxOCAoYW5kDQphbnl0aGluZyBlbHNlIGZyb20gdGhlIHdob2xlIElFRUUgODAyIHNlcmll cyB0aGF0IHlvdSBuZWVkKS4NCg0KaHR0cHM6Ly8xLmllZWU4MDIub3JnL3NlY3VyaXR5LzgwMi0x YXIvPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovMS5pZWVlODAyLm9yZy9zZWN1 cml0eS84MDItMWFyL19fOyEhTkV0NnlNYU8tZ2shVklnZm9KSVp3NmYtdFFUV3AwU2pvLVZyTFpR LU1wSlJidHhzSmFVQ3p0c2h6cWZ5M1poQ2dOUDJIbjMxUS1sc0xKcyQ+DQoNCkNoZWVycywNCi0g SXJhDQoNCg0KDQpPbiBUaHUsIE1hciAxMSwgMjAyMSBhdCAyOjAyIFBNIExhdXJlbmNlIEx1bmRi bGFkZSA8bGdsQGlzbGFuZC1yZXNvcnQuY29tPG1haWx0bzpsZ2xAaXNsYW5kLXJlc29ydC5jb20+ PiB3cm90ZToNCkkgd2FudCB0byB1bnBhY2sgYW5kIHVuZm9sZCBhIGZldyB0aGluZ3MgaGVyZS4N Cg0KUGVybWFuZW5jZSAvIExpZmVjeWNsZSAvIFByaXZhY3kg4oCUIEkgdGhpbmsgdGhlIG1haW4g dG9waWMgaGVyZSBpcyBhYm91dCB3aGVuIGFuIElEIGNoYW5nZXMgcmVsYXRpdmUgdG8gdGhlIGxp ZmVjeWNsZSBvZiB0aGUgZGV2aWNlIGFuZCBob3cgdGhpcyByZWxhdGVzIHRvIHByaXZhY3kuDQoN CkNvbXByb21pc2Ug4oCUIEkgdGhpbmsgY29tcHJvbWlzZSBkdWUgdG8gYWxnb3JpdGhtcyBiZWlu ZyBjb21wcm9taXNlZCBvciB0aGUgZGV2aWNlIGJlaW5nIG93bmVkIG9yIHN1Y2ggaXMgYSBzZXBh cmF0ZSB0b3BpYy4gRGlzY3Vzc2lvbiBvZiBpdCBzZWVtcyBvcnRob2dvbmFsLCBzaG91bGQgZ28g aW50byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgcmVhbGx5IGNvbWVzIGRvd24gdG8gY2Vy dGlmaWNhdGlvbiBpbiB0aGUgZW5kIGlmIHlvdSByZWFsbHkgd2FudCB0byBsb2NrIGl0IGRvd24u DQoNCknigJltIG5vdCBzdXJlIHdoaWNoIGlzIG1lYW50IGJ5IOKAnGltbXV0YWJpbGl0eeKAnSBp biB0aGUgcHJldmlvdXMgZW1haWxzLg0KDQpNeSBpbnRlbnQgaW4gdGhlIGRlZmluaXRpb24gb2Yg VUVJRCB3YXMgdGhhdCBpdCBpcyB0cnVseSBwZXJtYW5lbnQuIEl0IGRvZXNu4oCZdCBjaGFuZ2Ug YXQgYW55IHRpbWUgaW4gdGhlIGxpZmVjeWNsZSBvZiB0aGUgZGV2aWNlLiBUaGlzIGlzIHRoZSBz aW1wbGVzdCBjYXNlIHRvIGRlc2NyaWJlLiBJdCBpcyBub3QgYXQgYWxsIHByaXZhY3kgcHJlc2Vy dmluZyBmb3Igc29tZSB1c2UgY2FzZXMgKGUuZy4sIG1vYmlsZSBwaG9uZSksIGJ1dCBpcyBPSyBm b3Igb3RoZXJzIChlLmcuLCBkdW1iIHNlbnNvcikuDQoNCkkgd2FzIHRoaW5raW5nIG90aGVyIGZv bGtzIG1pZ2h0IGRlZmluZSBvdGhlciBJRHMgZm9yIG90aGVyIHVzZSBjYXNlcy4gTWF5YmUgdGhl IHRpbWUgaGFzIGNvbWUgdG8gaW52ZW50IG9uZSBvciB0d28gb2YgdGhvc2UgYW5kIHB1dCB0aGVt IGluIEVBVC4NCg0KU29tZSBTb2x1dGlvbnMNCk9uZSBwb3NzaWJpbGl0eSBpcyBhbiBTVUVJRCwg YSBzZW1pLXBlcm1hbmVudCBVRUlEIChtYXliZSBub3QgdXNlIFNQVUlFRCkuIEl0IGlzIGFsbG93 ZWQgdG8gY2hhbmdlIGluIG1ham9yIGV2ZW50cyBpbiB0aGUgZGV2aWNlcyBsaWZlY3ljbGUgc3Vj aCBhcyBldmVudHMgd2hlbiBvd25lcnNoaXAgY2hhbmdlcywgdGhlIG1hbmFnaW5nIGVudGl0eSBj aGFuZ2VzIG9yIG9uIGZhY3RvcnkgcmVzZXQuIEkgdGhpbmsgdGhpcyBsaW5lcyB1cCB3aXRoIHRo ZSB3YXkgc29tZSBNQUMgYWRkcmVzc2VzIGFyZSBtYW5hZ2VkIGZvciBwcml2YWN5IHJlYXNvbnMu IFRoaXMgbGluZSB1cCBpcyBnb29kIGJlY2F1c2UgYSBVRUlEIGNhbiBiZSBhbiBJRUVFIE1BQy4N Cg0KQW4gUlAgbWlnaHQgcmVjZWl2ZSBhbiBFQVQgd2l0aCBvbmx5IGFuIFVFSUQsIG9ubHkgYW4g U1BVRUlEIG9yIGJvdGguIFRoZSBSUCBjYW4gZGVjaWRlIHdoYXQgdGhleSB3YW50IHRvIHVzZS4N Cg0KDQpBbm90aGVyIG9uZSBpcyBmb3IgdGhlIEF0dGVzdGVyIHRvIGF1dGhlbnRpY2F0ZSB0aGUg VmVyaWZpZXIgYW5kL29yIFJlbHlpbmcgUGFydHkgYW5kIGdlbmVyYXRlIGEgZGlzdGluY3QgVUVJ RCBvciBTVUVJRCBqdXN0IGZvciB1c2UgYnkgdGhhdCBSUC4gVGhpcyBpcyBhIHNvbHV0aW9uIHRv IHRoZSBwcml2YWN5IGlzc3VlLiBJ4oCZdmUgYWN0dWFsbHkgZG9uZSBhbiBpbXBsZW1lbnRhdGlv biBvZiB0aGlzIG9uZS4NCg0KDQpBIHJlbGF0ZWQgc29sdXRpb24gaXMgdG8gaGF2ZSBhIHByaXZh Y3kgcHJveHkgYmV0d2VlbiB0aGUgQXR0ZXN0ZXIgYW5kIHRoZSBWZXJpZmllciB0aGF0IG1ha2Vz IFJQLXNwZWNpZmljIFVFSURzIG9yIFNVRUlEcy4NCg0KDQpTZXBhcmF0aW9uIG9mIElEIGZyb20g QXR0ZXN0YXRpb24gS2V5DQpBbiBJRCB0aGF0IGlzIG5vdCBzaWduZWQgaXMgbmVhcmx5IHVzZWxl c3MgYmVjYXVzZSBhbnlvbmUgY2FuIGZvcmdlIGl0IHNvIHdl4oCZcmUgYWx3YXlzIHRhbGtpbmcg YWJvdXQgc29tZSBzb3J0IG9mIHNpZ25pbmcuDQoNCkVBVCBpbnRlbnRpb25hbGx5IHNlcGFyYXRl cyB0aGUgSUQgZnJvbSB0aGUgc2lnbmluZyBrZXkuIEkgaGF2ZW7igJl0IHJlYWQgSURldklELCBi dXQgSSBkb27igJl0IHRoaW5rIGl0IGhhcyB0aGlzIHNlcGFyYXRpb24uIFRoZSByZWFzb24gRUFU IHNlcGFyYXRlcyB0aGVtIGlzIHRvIGhhdmUgYSBsb3Qgb2YgZmxleGliaWxpdHkgdG8gZGVhbCB3 aXRoIHRoZSBwcml2YWN5IGFuZCBsaWZlY3ljbGUgaXNzdWVzIHRoYXQgY29tZSB1cCBpbiByZWFs IGRlcGxveW1lbnRzIGZvciBjaGlwIG1ha2VycyBhbmQgY29tcGxleCBzdXBwbHkgY2hhaW5zLg0K DQpGb3IgZXhhbXBsZSwgRklETyB1c2VzIGdyb3VwIGF0dGVzdGF0aW9uIGtleXMgdG8gZGVhbCB3 aXRoIHRoZSBwcml2YWN5IGlzc3VlLiBPbmUga2V5IGlzIHB1dCBpbnRvIDEwMCwwMDAgcGx1cyBk ZXZpY2VzIHdoaWNoIG1ha2VzIGl0IHN0YXRpc3RpY2FsbHkgbm90IHZlcnkgdXNlZnVsIGZvciB0 cmFja2luZyB1c2Vycy4gTWF5YmUgdGhlIGRldmljZSBtYW51ZmFjdHVyZSB1c2VzIHRoaXMgdGFj dGljIGZvciBiaWxsaW9ucyBvZiBkZXZpY2VzLiBUaGVuIG1heWJlIGEgdXNlIGNhc2UgaW52b2x2 aW5nIG9ubHkgbWlsbGlvbnMgb2YgdGhlc2UgZGV2aWNlcyBuZWVkcyBhIHRydWx5IGdsb2JhbCBJ RCBhbmQgaGF2ZSB0aGUgbWVhbnMgdG8gcHJvZ3JhbSBpdC4gVGhpcyBjYW4gd29yayBpZiB0aGUg a2V5cyBhbmQgSURzIGFyZSBzZXBhcmF0ZS4NCg0KT3IgbWF5YmUgdGhlIG1hbnVmYWN0dXJlciBj aGFuZ2VzIHNpZ25pbmcgc2NoZW1lcyBtb3ZpbmcgZnJvbSBhIHByaW1pdGl2ZSBNQUMgdG8gRUMt YmFzZWQgcHViIGtleSBhbmQgb250byBzb21lIHNvcnQgb2YgREFBIHdoaWxlIG1haW50YWluaW5n IHRoZSBzYW1lIHNjaGVtZSBmb3IgZGV2aWNlIElEcy4NCg0KDQpQb3NzaWJsZSBoYXJtb25pemF0 aW9uIHdpdGggb3RoZXIgRGV2aWNlIElEcz8NCkkgbm90aWNlZCB0aGF0IGJpcmtob2x6LXJhdHMt c3VpdC1jbGFpbXM8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1iaXJraG9sei1yYXRzLXN1aXQtY2xhaW1zLTAxLnR4dF9fOyEhTkV0NnlN YU8tZ2shVklnZm9KSVp3NmYtdFFUV3AwU2pvLVZyTFpRLU1wSlJidHhzSmFVQ3p0c2h6cWZ5M1po Q2dOUDJIbjMxZDE5TTdsdyQ+IG1lbnRpb25zIGEgZGV2aWNlIElEIGJhc2VkIG9uIFVVSURzLiBX ZSBzaG91bGQgcHJvYmFibHkgdGFrZSBhIGxvb2sgYXQgaG93IHRoaXMgcmVsYXRlcyBVRUlELiBU aGVyZeKAmXMgcHJvYmFibHkgb3RoZXJzIHRvIGNoZWNrIG91dC4gV2UgcHJvYmFibHkgd2FudCB0 byByZSB1c2UgYSBsb3Qgb2YgdGhlIGNsYWltcyBmcm9tIEV2aWRlbmNlIGluIEF0dGVzdGF0aW9u IFJlc3VsdHMgc28gdGhleSBjYW4gYmUgcGFzcy10aHJvdWdoIGZvciB0aGUgVmVyaWZpZXIuDQoN Ck5vdGUgYWxzbyB0aGF0IFVVSURzIGFyZSBvYnNvbGV0ZSBub3cuDQoNCkxMDQoNCg0KUC5TLiwg QW55IHN1Z2dlc3Rpb25zIG9uIGhvdyB0byBnZXQgYWNjZXNzIHRvIElFRUUgSURldklEPyBJ4oCZ bSBub3QgcGFydCBvZiBhIGJpZyBjb21wYW55LiBJIHRyaWVkIGpvaW5pbmcgSUVFRSBvbmNlLCBi dXQgdGhhdCB3YXNu4oCZdCBlbm91Z2ggdG8gZ2V0IGFjY2Vzcy4NCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSQVRTIG1haWxpbmcgbGlzdA0K UkFUU0BpZXRmLm9yZzxtYWlsdG86UkFUU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcmF0czxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhdHNfXzshIU5FdDZ5TWFPLWdrIVZJZ2Zv SkladzZmLXRRVFdwMFNqby1WckxaUS1NcEpSYnR4c0phVUN6dHNoenFmeTNaaENnTlAySG4zMV9L b0FBa0kkPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClJBVFMgbWFpbGluZyBsaXN0DQpSQVRTQGlldGYub3JnPG1haWx0bzpSQVRTQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYXRzDQoNCg== --_000_BD13AD1F0E35464C9D062CE4AC1372B3intelcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2lu ZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4 dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5EZXZpY2Ugb25ib2FyZGluZyBpcyBwcm9iYWJseSB0aGUgbW9zdCBwcmV2YWxl bnQgdXNlIGNhc2UgZm9yIElEZXZJRC4gQnV0IHRoYXQgaXMgb25seSBhIGd1ZXNzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5MYXVyZW5jZSBMdW5kYmxhZGUgJmx0O2xnbEBpc2xhbmQtcmVzb3J0LmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgQXByaWwgMTMsIDIwMjEgYXQgMTI6MjYg UE08YnI+DQo8Yj5UbzogPC9iPkd1eSBGZWRvcmtvdyAmbHQ7Z2ZlZG9ya293QGp1bmlwZXIubmV0 Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SXJhIE1jRG9uYWxkICZsdDtibHVlcm9vZm11c2ljQGdtYWls LmNvbSZndDssICZxdW90O3JhdHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3JhdHNAaWV0Zi5vcmcmZ3Q7 LCAmcXVvdDtTbWl0aCwgTmVkJnF1b3Q7ICZsdDtuZWQuc21pdGhAaW50ZWwuY29tJmd0OywgRWxp b3QgTGVhciAmbHQ7bGVhckBjaXNjby5jb20mZ3Q7LCAmcXVvdDtpb3RvcHNAaWV0Zi5vcmcmcXVv dDsgJmx0O2lvdG9wc0BpZXRmLm9yZyZndDssIEhlbmsgQmVya2hvbHogJmx0O2hlbmsuYmlya2hv bHpAc2l0LmZyYXVuaG9mZXIuZGUmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbUmF0c10g ODAyLjFBUiBkZXZpY2UgaWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5UaGFua3MgZm9yIHRoZSBjb21tZW50cywgR3V5LiBBcHByZWNpYXRlIGl0 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BZ3JlZWQgdGhhdCByZXB1 cnBvc2luZyBJRGV2SUQga2V5cyBmb3IgRUFUIG1pZ2h0IGJlIGEgYml0IHdlaXJkIGFuZCB3cm9u ZywgYnV0IGl0IGlzIHN0aWxsIHJlYWxseSB1c2VmdWwgdG8gdW5kZXJzdGFuZCBob3cgdGhleSBh cmUgaW50ZW5kZWQgdG8gd29yayBhbmQgYXJlIGFjdHVhbGx5IHVzZWQgdG8gaGVscCB3aXRoIHRo ZSBkZXNpZ24gb2YgRUFULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjgwMi4xQVIgc2VjdGlvbiA3LjIuNSBzYXkgdGhlIGtleXMgY2FuIGJlIHVzZWQgZm9y IHNpZ25pbmcuIEFwcGVuZGl4IEIgaGFzIGl0IHBhcnRpY2lwYXRpbmcgaW4gYW4gRUFULVRMUyBz ZXNzaW9uIGFuZCBnaXZlcyBzb21lIG90aGVyIHZlcnkgZ2VuZXJhbCB1c2UgY2FzZXMuICZuYnNw O05vIG1hdHRlciB3aGF0LCB0aGUga2V5IGhhcyB0byBiZSB1c2VkIHRvIHNpZ24gYSBub25jZQ0K IGZvciBwcm9vZiBvZiBwb3NzZXNzaW9uLCBzbyB0aGVyZSBpcyBzb21lIHNpZ25pbmcgb2YgZXh0 ZXJuYWwgZGF0YSBnb2luZyBvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGEgaHJlZj0iaHR0cHM6Ly93d3cudHJ1c3RlZGNvbXB1dGluZ2dyb3VwLm9yZy93cC1jb250 ZW50L3VwbG9hZHMvVFBNX0tleXNfZm9yX1BsYXRmb3JtX0lkZW50aXR5X3YxXzBfcjNfRmluYWwu cGRmIj5odHRwczovL3d3dy50cnVzdGVkY29tcHV0aW5nZ3JvdXAub3JnL3dwLWNvbnRlbnQvdXBs b2Fkcy9UUE1fS2V5c19mb3JfUGxhdGZvcm1fSWRlbnRpdHlfdjFfMF9yM19GaW5hbC5wZGY8L2E+ DQogbGlzdHMgYSB3aG9sZSBidW5jaCBtb3JlIHVzZSBjYXNlcyBsaWtlIElLRS4gRG8gdGhlc2Ug cmVhbGx5IGdldCBpbXBsZW1lbnRlZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5XaGF0IGFyZSB0aGUgcG9wdWxhciBhbmQgd2lkZWx5IGRlcGxv eWVkIHVzZSBjYXNlcyBmb3IgSURldklEPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkkga2luZCBvZiB3YW50IEVBVCB0byBsZWFybiBmcm9tIElEZXZJRCBo ZXJlLiBUbyB1bmRlcnN0YW5kIHdoYXQgSURldklEIGlzIGFib3V0IHNvIHRoYXQgRUFUIGlzIG1v cmUgY2FwYWJsZSBhbmQgZml0cyBpbiBiZXR0ZXIgd2l0aCB1c2UgY2FzZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TEw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gQXByIDIs IDIwMjEsIGF0IDEwOjA1IEFNLCBHdXkgRmVkb3Jrb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmVk b3Jrb3dAanVuaXBlci5uZXQiPmdmZWRvcmtvd0BqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBMYXVyZW5jZSw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsgSSBhZ3JlZSB0aGF0IElEZXZJRCBpcyBpbnRlbmRlZCB0byBw ZXJzaXN0IHRocm91Z2ggdGhlIGRldmljZeKAmXMgbGlmZXRpbWUsIHdoaWxlIExEZXZJRCBpcyBt ZWFudCB0byByZXByZXNlbnQgdGhlIGN1cnJlbnQgb3duZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7IEluIFRDRy1sYW5kLCBhbiBJRGV2SUQgaXMgbm90IGFkdmlzZWQgZm9yIHNpZ25pbmcg YXR0ZXN0YXRpb24gZXZpZGVuY2U7IGl0cyByb2xlIGlzIGxpbWl0ZWQgdG8gaWRlbnRpdHksIHBy b3ZpZGluZyBwcm9vZiBvZiB0aGUgc3VwcGxpZXIgYW5kIHRoZSByZWFsLXdvcmxkIGlkZW50aXR5 IG9mIHRoZSBkZXZpY2UgKGkuZS4sIHNlcmlhbCBudW1iZXIpLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwO1dpdGggVFBNMS4yIGl04oCZcyBhY3R1YWxseSBub3QgcG9zc2li bGUgdG8gdXNlIHRoZSBJRGV2SUQgdG8gc2lnbiBUUE0gYXR0ZXN0YXRpb24gZXZpZGVuY2UsIGFz IGEgY291bnRlci1tZWFzdXJlIHRvIGJsb2NrIHNwb29maW5nIGJ5IGFuIGF0dGFja2VyLCBzbyB0 aGUgVENHIGRvY3MgYWR2aXNlIGEgc2VwYXJhdGUgYXR0ZXN0YXRpb24ga2V5IHdpdGggYSBiaW5k aW5nDQogdGhhdCBsaW5rcyB0aGVtIHRvIHRoZSBzYW1lIFRQTS4mbmJzcDsgSSB0aGluayB0aGF0 4oCZcyBub3QgYWN0dWFsbHkgbmVjZXNzYXJ5IGluIFRQTTIsIGFsdGhvdWdoIHRoZSBhZHZpY2Ug Zm9yIHNlcGFyYXRpb24gcmVtYWlucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgU28gaW4g dGhhdCBjb250ZXh0IHRoZSBzZW50ZW5jZSDigJxbRUFUXSBzZXBhcmF0ZXMgdGhlIHNpZ25pbmcg c2NoZW1lIGZyb20gdGhlIGlkZW50aWZpY2F0aW9uIHNjaGVtZeKAnSBzZWVtcyBwdXp6bGluZy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgQnV0 IGluIHRoZSBFQVQgZW52aXJvbm1lbnQsIHdoZXJlIHRoZXJl4oCZcyBubyB0ZWNobm9sb2dpY2Fs IGJsb2NrIHRvIGFuIGF0dGFja2VyIHdpdGggYWNjZXNzIHRvIHRoZSBrZXkgdG8gc3Bvb2YgYW4g YXR0ZXN0YXRpb24gcmVzdWx0LCBJIGFncmVlIHRoYXQgdGhlIERldklEIGNvdWxkIGJlIHVzZWQg dG8gc2lnbiBhbiBFQVQgdG9rZW4gY2FycnlpbmcgYXR0ZXN0YXRpb24NCiBldmlkZW5jZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgTGV0IG1l IGtub3cgaWYgSeKAmW0gbWlzc2luZyB0aGUgcG9pbnQhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGh4 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+L2d1eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPkZyb206PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5MYXVyZW5jZSBMdW5kYmxhZGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpsZ2xAaXNsYW5kLXJlc29ydC5jb20iPmxnbEBpc2xhbmQtcmVz b3J0LmNvbTwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXksIE1hcmNoIDI2LCAyMDIxIDI6MjEgUE08YnI+DQo8Yj5U bzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkly YSBNY0RvbmFsZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJsdWVyb29mbXVzaWNAZ21haWwuY29tIj5i bHVlcm9vZm11c2ljQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmF0 c0BpZXRmLm9yZyI+cmF0c0BpZXRmLm9yZzwvYT47IFNtaXRoLCBOZWQgJmx0OzxhIGhyZWY9Im1h aWx0bzpuZWQuc21pdGhAaW50ZWwuY29tIj5uZWQuc21pdGhAaW50ZWwuY29tPC9hPiZndDs7IEVs aW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSI+bGVhckBjaXNjby5j b208L2E+Jmd0OzsgR3V5IEZlZG9ya293DQogJmx0OzxhIGhyZWY9Im1haWx0bzpnZmVkb3Jrb3dA anVuaXBlci5uZXQiPmdmZWRvcmtvd0BqdW5pcGVyLm5ldDwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aW90b3Bz QGlldGYub3JnIj5pb3RvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbUmF0c10gODAy LjFBUiBkZXZpY2UgaWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtsaW5lLWhlaWdodDoxMi4wcHQ7YmFja2dyb3VuZDoj RkZFQjlDIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltFeHRlcm5hbCBFbWFpbC4g QmUgY2F1dGlvdXMgb2YgY29udGVudF08L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBnb3QgbXkgY29weSBvZiA4 MDItMUFSLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPknigJl2ZSBtYWRlIGEmbmJzcDs8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vaWV0Zi1yYXRzLXdnL2VhdC9wdWxsLzEwMSI+UFI8L2E+Jm5ic3A7 dGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyAmbmJzcDsxKSBB ZGRzIGFuIFNVRUlEIHRvIEVBVCB0aGF0IGlzIHNpbWlsYXIgdG8gTERldklEIGluIHRoYXQgaXQg Y2FuIGNoYW5nZSBvbiBkZXZpY2UgbGlmZS1jeWNsZSBldmVudHM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsgJm5ic3A7MikgQWRkcyBhIHdob2xlIGFwcGVuZGl4IGRp c2N1c3NpbmcgdGhlIHJlbGF0aW9uIG9mIElEZXZJRCB0byBFQVQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5Gcm9tIHJlYWRpbmcgODAyLjFBUiwgaXTigJlzIHByZXR0eSBjbGVhciB0aGF0IElEZXZJRCBp cyBwZXJtYW5lbnQuIEhlcmXigJlzIG9uZSBzZW50ZW5jZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGhlc2UgYWRkaXRpb25hbCBvcGVy YXRpb25zIGNhbiBpbmNsdWRlIGRlbGV0aW9uIG9mIHRoZSBJRGV2SUQgY2VydGlmaWNhdGUgb3Ig SURldklEIGtleSwgd2hpY2ggY2FuIGJlIGxvZ2ljYWxseSBlcXVpdmFsZW50IHRvIGRlY29tbWlz c2lvbmluZyB0aGUNCiBkZXZpY2UsJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjgwMi4x QVIgYWxzbyBwcm92aWRlcyBmb3IgYW4gTERldklEIHRoYXQgaXMgbGVzcyBwZXJtYW5lbnQgaW4g dGhlIHdheXMgdGhhdCBHaXJpIHNlZW1zIHRvIGJlIGFza2luZyBmb3IuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+UGxlYXNlIHRha2UgYSBsb3QgYXQgdGhlIFBSLiBJdCBkb2VzIGEgbGl0dGxlIGNvbXBh cmUgYW5kIGNvbnRyYXN0IGJldHdlZW4gRUFUIGFuZCBJRGV2SUQuIEkgYW0gaW50ZXJlc3RlZCBp biBjb21tZW50cyBvbiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5MTDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5PbiBNYXIgMTEsIDIwMjEsIGF0IDExOjEzIEFNLCBJcmEgTWNEb25hbGQgJmx0Ozxh IGhyZWY9Im1haWx0bzpibHVlcm9vZm11c2ljQGdtYWlsLmNvbSI+Ymx1ZXJvb2ZtdXNpY0BnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpIExhdXJlbmNlLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPlRoYW5rcyB0byB0aGUgd29uZGVyZnVsICpmcmVlKiBJRUVFIEdldCA4 MDIgcHJvZ3JhbSwgeW91IGNhbiBnbyB0byB0aGlzIGxpbmsgKGZyb20gR3V5IGVhcmxpZXIpPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+YW5kIGNyZWF0ZSB5b3VyIG93biBkdXJh YmxlIGZyZWUgR2V0IDgwMiBhY2NvdW50IGFuZCB0aGVuIGRvd25sb2FkIElFRUUgODAyLjFBUi0y MDE4IChhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5hbnl0aGluZyBlbHNl IGZyb20gdGhlIHdob2xlIElFRUUgODAyIHNlcmllcyB0aGF0IHlvdSBuZWVkKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6LzEu aWVlZTgwMi5vcmcvc2VjdXJpdHkvODAyLTFhci9fXzshIU5FdDZ5TWFPLWdrIVZJZ2ZvSkladzZm LXRRVFdwMFNqby1WckxaUS1NcEpSYnR4c0phVUN6dHNoenFmeTNaaENnTlAySG4zMVEtbHNMSnMk Ij5odHRwczovLzEuaWVlZTgwMi5vcmcvc2VjdXJpdHkvODAyLTFhci88L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi0gSXJh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gVGh1LCBNYXIgMTEsIDIwMjEgYXQg MjowMiBQTSBMYXVyZW5jZSBMdW5kYmxhZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpsZ2xAaXNsYW5k LXJlc29ydC5jb20iPmxnbEBpc2xhbmQtcmVzb3J0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB3YW50IHRvIHVucGFjayBhbmQgdW5mb2xkIGEgZmV3IHRo aW5ncyBoZXJlLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGI+UGVybWFuZW5jZSAvIExpZmVjeWNsZSAvIFByaXZhY3kmbmJzcDvi gJQmbmJzcDs8L2I+SSB0aGluayB0aGUgbWFpbiB0b3BpYyBoZXJlIGlzIGFib3V0IHdoZW4gYW4g SUQgY2hhbmdlcyByZWxhdGl2ZSB0byB0aGUgbGlmZWN5Y2xlIG9mIHRoZSBkZXZpY2UgYW5kIGhv dyB0aGlzIHJlbGF0ZXMgdG8gcHJpdmFjeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj5Db21wcm9t aXNlJm5ic3A74oCUJm5ic3A7PC9iPkkgdGhpbmsgY29tcHJvbWlzZSBkdWUgdG8gYWxnb3JpdGht cyBiZWluZyBjb21wcm9taXNlZCBvciB0aGUgZGV2aWNlIGJlaW5nIG93bmVkIG9yIHN1Y2ggaXMg YSBzZXBhcmF0ZSB0b3BpYy4gRGlzY3Vzc2lvbiBvZiBpdCBzZWVtcyBvcnRob2dvbmFsLCBzaG91 bGQgZ28gaW50byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgcmVhbGx5DQogY29tZXMgZG93 biB0byBjZXJ0aWZpY2F0aW9uIGluIHRoZSBlbmQgaWYgeW91IHJlYWxseSB3YW50IHRvIGxvY2sg aXQgZG93bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5J4oCZbSBub3Qgc3VyZSB3aGljaCBpcyBtZWFu dCBieSDigJxpbW11dGFiaWxpdHnigJ0gaW4gdGhlIHByZXZpb3VzIGVtYWlscy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5NeSBpbnRlbnQgaW4gdGhlIGRlZmluaXRpb24gb2YgVUVJRCB3YXMgdGhhdCBp dCBpcyB0cnVseSBwZXJtYW5lbnQuIEl0IGRvZXNu4oCZdCBjaGFuZ2UgYXQgYW55IHRpbWUgaW4g dGhlIGxpZmVjeWNsZSBvZiB0aGUgZGV2aWNlLiBUaGlzIGlzIHRoZSBzaW1wbGVzdCBjYXNlIHRv IGRlc2NyaWJlLiBJdCBpcyBub3QgYXQgYWxsIHByaXZhY3kgcHJlc2VydmluZyBmb3Igc29tZQ0K IHVzZSBjYXNlcyAoZS5nLiwgbW9iaWxlIHBob25lKSwgYnV0IGlzIE9LIGZvciBvdGhlcnMgKGUu Zy4sIGR1bWIgc2Vuc29yKS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHdhcyB0aGlua2lu ZyBvdGhlciBmb2xrcyBtaWdodCBkZWZpbmUgb3RoZXIgSURzIGZvciBvdGhlciB1c2UgY2FzZXMu IE1heWJlIHRoZSB0aW1lIGhhcyBjb21lIHRvIGludmVudCBvbmUgb3IgdHdvIG9mIHRob3NlIGFu ZCBwdXQgdGhlbSBpbiBFQVQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHU+U29tZSBTb2x1dGlvbnM8 L3U+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T25lIHBvc3NpYmlsaXR5IGlz IGFuIFNVRUlELCBhIHNlbWktcGVybWFuZW50IFVFSUQgKG1heWJlIG5vdCB1c2UgU1BVSUVEKS4g SXQgaXMgYWxsb3dlZCB0byBjaGFuZ2UgaW4gbWFqb3IgZXZlbnRzIGluIHRoZSBkZXZpY2VzIGxp ZmVjeWNsZSBzdWNoIGFzIGV2ZW50cyB3aGVuIG93bmVyc2hpcCBjaGFuZ2VzLCB0aGUgbWFuYWdp bmcgZW50aXR5IGNoYW5nZXMgb3Igb24NCiBmYWN0b3J5IHJlc2V0LiBJIHRoaW5rIHRoaXMgbGlu ZXMgdXAgd2l0aCB0aGUgd2F5IHNvbWUgTUFDIGFkZHJlc3NlcyBhcmUgbWFuYWdlZCBmb3IgcHJp dmFjeSByZWFzb25zLiBUaGlzIGxpbmUgdXAgaXMgZ29vZCBiZWNhdXNlIGEgVUVJRCBjYW4gYmUg YW4gSUVFRSBNQUMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gUlAgbWlnaHQgcmVjZWl2ZSBhbiBF QVQgd2l0aCBvbmx5IGFuIFVFSUQsIG9ubHkgYW4gU1BVRUlEIG9yIGJvdGguIFRoZSBSUCBjYW4g ZGVjaWRlIHdoYXQgdGhleSB3YW50IHRvIHVzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Bbm90aGVyIG9uZSBpcyBmb3IgdGhl IEF0dGVzdGVyIHRvIGF1dGhlbnRpY2F0ZSB0aGUgVmVyaWZpZXIgYW5kL29yIFJlbHlpbmcgUGFy dHkgYW5kIGdlbmVyYXRlIGEgZGlzdGluY3QgVUVJRCBvciBTVUVJRCBqdXN0IGZvciB1c2UgYnkg dGhhdCBSUC4gVGhpcyBpcyBhIHNvbHV0aW9uIHRvIHRoZSBwcml2YWN5IGlzc3VlLiBJ4oCZdmUg YWN0dWFsbHkgZG9uZSBhbiBpbXBsZW1lbnRhdGlvbg0KIG9mIHRoaXMgb25lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkEgcmVs YXRlZCBzb2x1dGlvbiBpcyB0byBoYXZlIGEgcHJpdmFjeSBwcm94eSBiZXR3ZWVuIHRoZSBBdHRl c3RlciBhbmQgdGhlIFZlcmlmaWVyIHRoYXQgbWFrZXMgUlAtc3BlY2lmaWMgVUVJRHMgb3IgU1VF SURzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjx1PlNlcGFyYXRpb24gb2YgSUQgZnJvbSBBdHRlc3RhdGlvbiBLZXk8L3U+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW4gSUQgdGhhdCBpcyBub3Qgc2lnbmVk IGlzIG5lYXJseSB1c2VsZXNzIGJlY2F1c2UgYW55b25lIGNhbiBmb3JnZSBpdCBzbyB3ZeKAmXJl IGFsd2F5cyB0YWxraW5nIGFib3V0IHNvbWUgc29ydCBvZiBzaWduaW5nLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkVBVCBpbnRlbnRpb25hbGx5IHNlcGFyYXRlcyB0aGUgSUQgZnJvbSB0aGUgc2lnbmlu ZyBrZXkuIEkgaGF2ZW7igJl0IHJlYWQgSURldklELCBidXQgSSBkb27igJl0IHRoaW5rIGl0IGhh cyB0aGlzIHNlcGFyYXRpb24uIFRoZSByZWFzb24gRUFUIHNlcGFyYXRlcyB0aGVtIGlzIHRvIGhh dmUgYSBsb3Qgb2YgZmxleGliaWxpdHkgdG8gZGVhbCB3aXRoIHRoZSBwcml2YWN5IGFuZA0KIGxp ZmVjeWNsZSBpc3N1ZXMgdGhhdCBjb21lIHVwIGluIHJlYWwgZGVwbG95bWVudHMgZm9yIGNoaXAg bWFrZXJzIGFuZCBjb21wbGV4IHN1cHBseSBjaGFpbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Rm9y IGV4YW1wbGUsIEZJRE8gdXNlcyBncm91cCBhdHRlc3RhdGlvbiBrZXlzIHRvIGRlYWwgd2l0aCB0 aGUgcHJpdmFjeSBpc3N1ZS4gT25lIGtleSBpcyBwdXQgaW50byAxMDAsMDAwIHBsdXMgZGV2aWNl cyB3aGljaCBtYWtlcyBpdCBzdGF0aXN0aWNhbGx5IG5vdCB2ZXJ5IHVzZWZ1bCBmb3IgdHJhY2tp bmcgdXNlcnMuIE1heWJlIHRoZSBkZXZpY2UgbWFudWZhY3R1cmUNCiB1c2VzIHRoaXMgdGFjdGlj IGZvciBiaWxsaW9ucyBvZiBkZXZpY2VzLiBUaGVuIG1heWJlIGEgdXNlIGNhc2UgaW52b2x2aW5n IG9ubHkgbWlsbGlvbnMgb2YgdGhlc2UgZGV2aWNlcyBuZWVkcyBhIHRydWx5IGdsb2JhbCBJRCBh bmQgaGF2ZSB0aGUgbWVhbnMgdG8gcHJvZ3JhbSBpdC4gVGhpcyBjYW4gd29yayBpZiB0aGUga2V5 cyBhbmQgSURzIGFyZSBzZXBhcmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PciBtYXliZSB0aGUg bWFudWZhY3R1cmVyIGNoYW5nZXMgc2lnbmluZyBzY2hlbWVzIG1vdmluZyBmcm9tIGEgcHJpbWl0 aXZlIE1BQyB0byBFQy1iYXNlZCBwdWIga2V5IGFuZCBvbnRvIHNvbWUgc29ydCBvZiBEQUEgd2hp bGUgbWFpbnRhaW5pbmcgdGhlIHNhbWUgc2NoZW1lIGZvciBkZXZpY2UgSURzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjx1PlBv c3NpYmxlIGhhcm1vbml6YXRpb24gd2l0aCBvdGhlciBEZXZpY2UgSURzPzwvdT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIG5vdGljZWQgdGhhdCZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt Ymlya2hvbHotcmF0cy1zdWl0LWNsYWltcy0wMS50eHRfXzshIU5FdDZ5TWFPLWdrIVZJZ2ZvSkla dzZmLXRRVFdwMFNqby1WckxaUS1NcEpSYnR4c0phVUN6dHNoenFmeTNaaENnTlAySG4zMWQxOU03 bHckIiB0YXJnZXQ9Il9ibGFuayI+Ymlya2hvbHotcmF0cy1zdWl0LWNsYWltczwvYT4mbmJzcDtt ZW50aW9ucw0KIGEgZGV2aWNlIElEIGJhc2VkIG9uIFVVSURzLiBXZSBzaG91bGQgcHJvYmFibHkg dGFrZSBhIGxvb2sgYXQgaG93IHRoaXMgcmVsYXRlcyBVRUlELiBUaGVyZeKAmXMgcHJvYmFibHkg b3RoZXJzIHRvIGNoZWNrIG91dC4gV2UgcHJvYmFibHkgd2FudCB0byByZSB1c2UgYSBsb3Qgb2Yg dGhlIGNsYWltcyBmcm9tIEV2aWRlbmNlIGluIEF0dGVzdGF0aW9uIFJlc3VsdHMgc28gdGhleSBj YW4gYmUgcGFzcy10aHJvdWdoIGZvciB0aGUgVmVyaWZpZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Tm90ZSBhbHNvIHRoYXQgVVVJRHMgYXJlIG9ic29sZXRlIG5vdy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5MTDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPlAuUy4sIEFueSBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZ2V0IGFjY2VzcyB0byBJ RUVFIElEZXZJRD8gSeKAmW0gbm90IHBhcnQgb2YgYSBiaWcgY29tcGFueS4gSSB0cmllZCBqb2lu aW5nIElFRUUgb25jZSwgYnV0IHRoYXQgd2FzbuKAmXQgZW5vdWdoIHRvIGdldCBhY2Nlc3MuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUkFUUyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UkFUU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJB VFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYXRzX187ISFORXQ2eU1hTy1n ayFWSWdmb0pJWnc2Zi10UVRXcDBTam8tVnJMWlEtTXBKUmJ0eHNKYVVDenRzaHpxZnkzWmhDZ05Q MkhuMzFfS29BQWtJJCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcmF0czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KUkFUUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UkFUU0BpZXRmLm9yZyI+ UkFUU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JhdHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cmF0czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BD13AD1F0E35464C9D062CE4AC1372B3intelcom_-- From nobody Fri Apr 16 11:22:22 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B333A3A301F; Fri, 16 Apr 2021 11:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 tYRaW85bABh0; Fri, 16 Apr 2021 11:22:16 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27753A301E; Fri, 16 Apr 2021 11:22:15 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6D240548056; Fri, 16 Apr 2021 20:22:08 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 690104400B2; Fri, 16 Apr 2021 20:22:08 +0200 (CEST) Date: Fri, 16 Apr 2021 20:22:08 +0200 From: Toerless Eckert To: "Smith, Ned" Cc: Laurence Lundblade , Guy Fedorkow , "rats@ietf.org" , Ira McDonald , Henk Birkholz , Eliot Lear , "iotops@ietf.org" Message-ID: <20210416182205.GF9065@faui48f.informatik.uni-erlangen.de> References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 18:22:21 -0000 There are uses of IDevID as crypto material for e.g. mutual authentication of seecured connection, seemingly designed by folks who where not really aware of the security properties. Aka: they are used for stuff that does not work. I would ignore such uses (irrelevant). For onboarding, one of the IMHO wisdoms developed in IEF WGs including netconf and anima is that you want to avoid the need for ongoing use of the IDevID by enrolling an LDevID during onboarding. Key exhaustion being one reason, but also higher utility of LDevID, such as (can i call it) attestation of who the owner of the device is (which IDevID does not say). I am not on top of EATs. If all the attestation is "immutable", aka: whatever the operator does (config, firmware changes), the vendor can guarantee that the attestation result will not be impacted by the owner/operator, then i think it is logically appropriate to use the IDevID. Key exhaustion of the IDevID could be avoided by creating a new keypair/certificate locally on the device/TPM and then just use the IDevID to sign that secondary cert (as a local TA). Call the new cert an Attestation-IDevID ? If the owner/operator can have an impact on the outcome of attestation, it should logically (IMHO) be signed with an LDevID. If the device does not want to support enrollment of LDevID, then hopefully expose in the attestation very explicitly any operator impact on the attestation result. Cheers Toerless On Fri, Apr 16, 2021 at 05:55:00PM +0000, Smith, Ned wrote: > Device onboarding is probably the most prevalent use case for IDevID. But that is only a guess. > > From: Laurence Lundblade > Date: Tuesday, April 13, 2021 at 12:26 PM > To: Guy Fedorkow > Cc: Ira McDonald , "rats@ietf.org" , "Smith, Ned" , Eliot Lear , "iotops@ietf.org" , Henk Berkholz > Subject: Re: [Rats] 802.1AR device identity > > Thanks for the comments, Guy. Appreciate it. > > Agreed that repurposing IDevID keys for EAT might be a bit weird and wrong, but it is still really useful to understand how they are intended to work and are actually used to help with the design of EAT. > > 802.1AR section 7.2.5 say the keys can be used for signing. Appendix B has it participating in an EAT-TLS session and gives some other very general use cases. No matter what, the key has to be used to sign a nonce for proof of possession, so there is some signing of external data going on. > > https://www.trustedcomputinggroup.org/wp-content/uploads/TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf lists a whole bunch more use cases like IKE. Do these really get implemented? > > What are the popular and widely deployed use cases for IDevID? > > I kind of want EAT to learn from IDevID here. To understand what IDevID is about so that EAT is more capable and fits in better with use cases. > > LL > > > > On Apr 2, 2021, at 10:05 AM, Guy Fedorkow > wrote: > > Hi Laurence, > I agree that IDevID is intended to persist through the device???s lifetime, while LDevID is meant to represent the current owner. > In TCG-land, an IDevID is not advised for signing attestation evidence; its role is limited to identity, providing proof of the supplier and the real-world identity of the device (i.e., serial number). > With TPM1.2 it???s actually not possible to use the IDevID to sign TPM attestation evidence, as a counter-measure to block spoofing by an attacker, so the TCG docs advise a separate attestation key with a binding that links them to the same TPM. I think that???s not actually necessary in TPM2, although the advice for separation remains. > So in that context the sentence ???[EAT] separates the signing scheme from the identification scheme??? seems puzzling. > > But in the EAT environment, where there???s no technological block to an attacker with access to the key to spoof an attestation result, I agree that the DevID could be used to sign an EAT token carrying attestation evidence. > > Let me know if I???m missing the point! > Thx > /guy > > > > Juniper Business Use Only > From: Laurence Lundblade > > Sent: Friday, March 26, 2021 2:21 PM > To: Ira McDonald > > Cc: rats@ietf.org; Smith, Ned >; Eliot Lear >; Guy Fedorkow >; iotops@ietf.org > Subject: Re: [Rats] 802.1AR device identity > > [External Email. Be cautious of content] > > I got my copy of 802-1AR. > > I???ve made a PR that > 1) Adds an SUEID to EAT that is similar to LDevID in that it can change on device life-cycle events > 2) Adds a whole appendix discussing the relation of IDevID to EAT > > From reading 802.1AR, it???s pretty clear that IDevID is permanent. Here???s one sentence: > These additional operations can include deletion of the IDevID certificate or IDevID key, which can be logically equivalent to decommissioning the device, > 802.1AR also provides for an LDevID that is less permanent in the ways that Giri seems to be asking for. > > Please take a lot at the PR. It does a little compare and contrast between EAT and IDevID. I am interested in comments on it. > > LL > > > > On Mar 11, 2021, at 11:13 AM, Ira McDonald > wrote: > > Hi Laurence, > > Thanks to the wonderful *free* IEEE Get 802 program, you can go to this link (from Guy earlier) > and create your own durable free Get 802 account and then download IEEE 802.1AR-2018 (and > anything else from the whole IEEE 802 series that you need). > > https://1.ieee802.org/security/802-1ar/ > > Cheers, > - Ira > > > > On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade > wrote: > I want to unpack and unfold a few things here. > > Permanence / Lifecycle / Privacy ??? I think the main topic here is about when an ID changes relative to the lifecycle of the device and how this relates to privacy. > > Compromise ??? I think compromise due to algorithms being compromised or the device being owned or such is a separate topic. Discussion of it seems orthogonal, should go into security considerations and really comes down to certification in the end if you really want to lock it down. > > I???m not sure which is meant by ???immutability??? in the previous emails. > > My intent in the definition of UEID was that it is truly permanent. It doesn???t change at any time in the lifecycle of the device. This is the simplest case to describe. It is not at all privacy preserving for some use cases (e.g., mobile phone), but is OK for others (e.g., dumb sensor). > > I was thinking other folks might define other IDs for other use cases. Maybe the time has come to invent one or two of those and put them in EAT. > > Some Solutions > One possibility is an SUEID, a semi-permanent UEID (maybe not use SPUIED). It is allowed to change in major events in the devices lifecycle such as events when ownership changes, the managing entity changes or on factory reset. I think this lines up with the way some MAC addresses are managed for privacy reasons. This line up is good because a UEID can be an IEEE MAC. > > An RP might receive an EAT with only an UEID, only an SPUEID or both. The RP can decide what they want to use. > > > Another one is for the Attester to authenticate the Verifier and/or Relying Party and generate a distinct UEID or SUEID just for use by that RP. This is a solution to the privacy issue. I???ve actually done an implementation of this one. > > > A related solution is to have a privacy proxy between the Attester and the Verifier that makes RP-specific UEIDs or SUEIDs. > > > Separation of ID from Attestation Key > An ID that is not signed is nearly useless because anyone can forge it so we???re always talking about some sort of signing. > > EAT intentionally separates the ID from the signing key. I haven???t read IDevID, but I don???t think it has this separation. The reason EAT separates them is to have a lot of flexibility to deal with the privacy and lifecycle issues that come up in real deployments for chip makers and complex supply chains. > > For example, FIDO uses group attestation keys to deal with the privacy issue. One key is put into 100,000 plus devices which makes it statistically not very useful for tracking users. Maybe the device manufacture uses this tactic for billions of devices. Then maybe a use case involving only millions of these devices needs a truly global ID and have the means to program it. This can work if the keys and IDs are separate. > > Or maybe the manufacturer changes signing schemes moving from a primitive MAC to EC-based pub key and onto some sort of DAA while maintaining the same scheme for device IDs. > > > Possible harmonization with other Device IDs? > I noticed that birkholz-rats-suit-claims mentions a device ID based on UUIDs. We should probably take a look at how this relates UEID. There???s probably others to check out. We probably want to re use a lot of the claims from Evidence in Attestation Results so they can be pass-through for the Verifier. > > Note also that UUIDs are obsolete now. > > LL > > > P.S., Any suggestions on how to get access to IEEE IDevID? I???m not part of a big company. I tried joining IEEE once, but that wasn???t enough to get access. > > > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Sat Apr 17 09:49:34 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D423A2945; Sat, 17 Apr 2021 09:49:33 -0700 (PDT) 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 uanR4vzA-ULX; Sat, 17 Apr 2021 09:49:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A013A2942; Sat, 17 Apr 2021 09:49:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1058938EE2; Sat, 17 Apr 2021 12:56:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BzEIWjR2_1kp; Sat, 17 Apr 2021 12:56:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5849B38ED3; Sat, 17 Apr 2021 12:56:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E0C8E48B; Sat, 17 Apr 2021 12:49:22 -0400 (EDT) From: Michael Richardson To: "Smith\, Ned" , Laurence Lundblade , Guy Fedorkow , "rats\@ietf.org" , Ira McDonald , Henk Birkholz , Eliot Lear , "iotops\@ietf.org" In-Reply-To: References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <7C6A5C38-A155-4368-ADE0-97CF16DB3DCC@island-resort.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2021 16:49:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Smith, Ned wrote: > Device onboarding is probably the most prevalent use case for > IDevID. But that is only a guess. I hope it will be, but I don't think it is now. I think that it is mostly used in desktop environments for NEA/Attestation. In the mobile space, I'm not sure the built-in credentials that exist are q= uite IDevID. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmB7EZIACgkQgItw+93Q 3WUJoggAwCsaaQ2MEJdtnNvIgb/fnZXzJOzHPsW/C4MbzwE1MiYeQM5uMUCPFyXq 4lh7Hz2KAEabGXJlwE2XDCwDNvSJGLkgF9yJvQawI623u+sf1rFu1/FlZDsz5ZGk VoAz+UperguYEHfrxJOIZJDjMz8P7aFmy1P1f/WkxZoQA6JV4gLNaE3rBrrt4aFo pmsbOESacwn2w5+u+cVgqNnnn30CpBHVN4e8pFe9Eox5OQ6NyHRW8XS34h62t67I 0Iven70pamR//8YFMQofRPx/CKSph7OSIdg6JJJnZNCM89PGiWW1rJZ8XiAtSBx9 1hrCJXe4mgqCaznbA2KrwQIN+k4/TQ== =cFqE -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 17 17:49:13 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415D43A3A15 for ; Sat, 17 Apr 2021 17:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 JbMpTNnsGKWh for ; Sat, 17 Apr 2021 17:49:07 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 ED1283A3A16 for ; Sat, 17 Apr 2021 17:49:06 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id z15so15611354qtj.7 for ; Sat, 17 Apr 2021 17:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hLQZUE7Hx+ydwdx62v2x1ABj98tUeVOu7dZvo3TuuEQ=; b=B0oHNI3rymouYU98kzBs9Ntxndg6TUt+/kUboLLOZbcclR/DweG/qopGa3PGgfp6G6 gmdYNxnwfEBe+YhAIRfxrAIoCZsDqhHMB0PjlLL02uwH0G6mMfTkdcyd4olrOFAeBQg6 dg500g/HLFgPb1wM/7DVxJxhvGKrUlNxi7goglS2kuRbEdHdn6buwfTg+d0b6JjZia5u b4rsRDHgKhpdHNq2atfFvmc4pKEOebBJ9h3ZovuZUjQXlU/CdvAqCwFQ5ChUbetMMQs6 baV3agvbN8UmIRr6w0DiWQl1s2cwM9xKBCgH07uW03tRXa7cj1EY89dvV0+jNIHDgxcI lRNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hLQZUE7Hx+ydwdx62v2x1ABj98tUeVOu7dZvo3TuuEQ=; b=Hn8jtQ4p3nj5LpfLsSpXVxrxADTSK/cSpHtPSH8o7NeUUehF4SxzGI81DEJE2zcOa9 z4V2WdpSCuOSaHbXr6Bj+aktqTmDKWZQn+XLvuAXzlGDWEzc3pLf4WLYn7jptLV74qlN SOWCrE+btkMDg1J7/NNjHp7AzesmCbS4FmTBvzizZAEV/Z8F/E9yJ5OMJah7zKTAwL3O bcwoo4TwJwSmSB0pQj99vkLwkw+63onFQe6bHc/wRSPpW5AYZ0cZi4TkYdqMxFuZKzGN EEKPe/8c/duo5JWNfxLBiozdUi7Gz1GkTgTHw1koW2fpmAiL0PWsufu2nw/XdiiBf7Kw 0mLw== X-Gm-Message-State: AOAM530Z4gzDcYxw9xY6ONfHoHTaD4z15SydyS3pxIA+UEOAD3kh59uq eMrpxZ0m0jLJeI8rZ/ycGfT5d9vA+H+nqNFzffKcIQ== X-Google-Smtp-Source: ABdhPJx9NCW2cZl+JQl6MYeDF2SgwHVHDwtwAoMRjzI89Lt8rA/u7bEOlMZHaFJfmrAsLcuCa3kKEeoxFVApMz7Tvzw= X-Received: by 2002:ac8:5655:: with SMTP id 21mr5900946qtt.187.1618706944820; Sat, 17 Apr 2021 17:49:04 -0700 (PDT) MIME-Version: 1.0 References: <22167.1615685681@localhost> In-Reply-To: From: Ash Wilson Date: Sat, 17 Apr 2021 17:48:52 -0700 Message-ID: To: Guy Fedorkow Cc: Michael Richardson , Eliot Lear , iotops@ietf.org Content-Type: multipart/alternative; boundary="00000000000071183505c034949a" Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 00:49:12 -0000 --00000000000071183505c034949a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joining the conversation a little late... I think that while the IdevID was originally intended to be a life-long birth certificate of sorts, improving the standard to allow certificate rotation could be useful. Keys become easier/cheaper to guess over time. Guessing the key will eventually be easier and less expensive than compromising the TPM which protects it. And not all implementations are created equal. For instance: https://en.m.wikipedia.org/wiki/ROCA_vulnerability . If the certificate can't be rotated, then even after a firmware update, you're stuck with a vulnerable private key in a patched TPM. Protocols exist to allow an entity to rotate its own certificate. If it were possible to safely do so, wouldn't the security posture of a device be improved by having some cryptographic agility for the identity's method for proof-of-possession? Rotation frequency recommendations can be related to the amount of time required to guess the private key. What if the device could rotate its own key in a shorter period of time than an adversary could guess it? If the device's name is universally unique and the certificate is discoverable using that name, then the certificate then becomes just a means of proving possession of the name. A manufacturer could support the rotation of IdevID certificates through an integration between the CA and the discovery mechanism. Certificate rotation like this could work with DANE for client identity. On Mon, Mar 15, 2021, 06:30 Guy Fedorkow wrote: > I agree with Michael. The IDevID in my point of view is as permanent as > the serial number on the box or the VIN on your car. > I think DevID could have privacy implications in some applications, so > within TCG there have been proposals to download the IDevID at the > customer's discretion, but in that case, it would have to be linked to > TPM's EK (another immutable key), so there's still only one possible IDev= ID > ever for a box. > As noted, LDevIDs can be made and destroyed at will. > /guy > > > > Juniper Business Use Only > > -----Original Message----- > From: RATS On Behalf Of Michael Richardson > Sent: Saturday, March 13, 2021 8:35 PM > To: Eliot Lear ; rats@ietf.org; > iotops@ietf.org > Subject: Re: [Rats] [Iotops] 802.1AR device identity > > [External Email. Be cautious of content] > > > Eliot Lear wrote: > > Yeah, this is an issue that comes up from time to time. How > > =E2=80=9Cimmutable=E2=80=9D should that iDevID be? > > I take the approach that the IDevID that was shipped from the factory can > not be replaced without a device recall. > > (It could be that there are modes where another IDevID can be installed, > but the original would not be removed. Whether this is an LDevID or IDev= ID > is open to intepretation) > > > I=E2=80=99ve had this thought in two > > different contexts: What if the signature algorithm, CA, or private > key > > used to protect the iDevID has been compromised? > > Then, the device is broken. > I think you would certainly agree that this can be the only answer if the > software signing key is compromised, right? > > > Can one recover with an update? > > What if there are attributes in the cert that I want to > > dink and share with the deployment? > > Please define "dink" for me. I know of only one definition from the > school yard. > Does this mean remove? replace? > > > I=E2=80=99d like to take that latter case off the table, but then w= e need to > > seriously think about RATS or SUIT providing a standard protected T= LV > > list that deployments could receive through a standard interface. > > These are attestations of a form, but they=E2=80=99re not really > measurements, > > as has been previously discussed here. > > Can you give me an example of one of these attributes? > This sounds like the FIDO situation, from section 6.3 of (my) the usecase > document: > > According to [fidotechnote] FIDO uses attestation to make claims > about the kind of device which is be used to enroll. Keypairs are > generated on a per-device _model_ basis, with a certificate having a > trust chain that leads back to a well-known root certificate. It is > expected that as many as 100,000 devices in a production run would > have the same public and private key pair. One assumes that this is > stored in a tamper-proof TPM so it is relatively difficult to get > this key out. The use of this key attests to the the device type, > and the kind of protections for keys that the relying party may > assume, not to the identity of the end user. > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > --00000000000071183505c034949a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joining the conversation a little late...=C2=A0

I think that while the IdevID was ori= ginally intended to be a life-long birth certificate of sorts, improving th= e standard to allow certificate rotation could be useful.=C2=A0

Keys become easier/cheaper to guess= over time. Guessing the key will eventually be easier and less expensive t= han compromising the TPM which protects it. And not all implementations are= created equal. For instance:=C2=A0https://en.m.wikipedia.org/wiki/ROCA_vulnerability . If the certificate can't be rotated, then even after a firmware up= date, you're stuck with a vulnerable private key in a patched TPM.

Protocols exist to allow an = entity to rotate its own certificate. If it were possible to safely do so, = wouldn't the security posture of a device be improved by having some cr= yptographic agility for the identity's method for proof-of-possession? = Rotation frequency recommendations can be related to the amount of time req= uired to guess the private key. What if the device could rotate its own key= in a shorter period of time than an adversary could guess it?

If the device's name is universa= lly unique and the certificate is discoverable using that name, then the ce= rtificate then becomes just a means of proving possession of the name.

=C2=A0A manufacturer could s= upport the rotation of IdevID certificates through an integration between t= he CA and the discovery mechanism.=C2=A0

<= div dir=3D"auto">Certificate rotation like this could work with DANE for cl= ient identity.

I agree with Mi= chael.=C2=A0 The IDevID in my point of view is as permanent as the serial n= umber on the box or the VIN on your car.=C2=A0
I think DevID could have privacy implications in some applications, so with= in TCG there have been proposals to download the IDevID at the customer'= ;s discretion, but in that case, it would have to be linked to TPM's EK= (another immutable key), so there's still only one possible IDevID eve= r for a box.
=C2=A0 As noted, LDevIDs can be made and destroyed at will.
/guy



Juniper Business Use Only

-----Original Message-----
From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richar= dson
Sent: Saturday, March 13, 2021 8:35 PM
To: Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org>; rats@ietf.= org; iotops@ietf.org
Subject: Re: [Rats] [Iotops] 802.1AR device identity

[External Email. Be cautious of content]


Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote: =C2=A0 =C2=A0 > Yeah, this is an issue that comes up from time to time.= =C2=A0 How
=C2=A0 =C2=A0 > =E2=80=9Cimmutable=E2=80=9D should that iDevID be?

I take the approach that the IDevID that was shipped from the factory can n= ot be replaced without a device recall.

(It could be that there are modes where another IDevID can be installed, bu= t the original would not be removed.=C2=A0 Whether this is an LDevID or IDe= vID is open to intepretation)

=C2=A0 =C2=A0 > I=E2=80=99ve had this thought in two
=C2=A0 =C2=A0 > different contexts: What if the signature algorithm, CA,= or private key
=C2=A0 =C2=A0 > used to protect the iDevID has been compromised?

Then, the device is broken.
I think you would certainly agree that this can be the only answer if the s= oftware signing key is compromised, right?

=C2=A0 =C2=A0 > Can one recover with an update?
=C2=A0 =C2=A0 > What if there are attributes in the cert that I want to<= br> =C2=A0 =C2=A0 > dink and share with the deployment?

Please define "dink" for me.=C2=A0 I know of only one definition = from the school yard.
Does this mean remove? replace?

=C2=A0 =C2=A0 > I=E2=80=99d like to take that latter case off the table,= but then we need to
=C2=A0 =C2=A0 > seriously think about RATS or SUIT providing a standard = protected TLV
=C2=A0 =C2=A0 > list that deployments could receive through a standard i= nterface.
=C2=A0 =C2=A0 > These are attestations of a form, but they=E2=80=99re no= t really measurements,
=C2=A0 =C2=A0 > as has been previously discussed here.

Can you give me an example of one of these attributes?
This sounds like the FIDO situation, from section 6.3 of (my) the usecase document:

=C2=A0 =C2=A0According to [fidotechnote] FIDO uses attestation to make clai= ms
=C2=A0 =C2=A0about the kind of device which is be used to enroll.=C2=A0 Key= pairs are
=C2=A0 =C2=A0generated on a per-device _model_ basis, with a certificate ha= ving a
=C2=A0 =C2=A0trust chain that leads back to a well-known root certificate.= =C2=A0 It is
=C2=A0 =C2=A0expected that as many as 100,000 devices in a production run w= ould
=C2=A0 =C2=A0have the same public and private key pair.=C2=A0 One assumes t= hat this is
=C2=A0 =C2=A0stored in a tamper-proof TPM so it is relatively difficult to = get
=C2=A0 =C2=A0this key out.=C2=A0 The use of this key attests to the the dev= ice type,
=C2=A0 =C2=A0and the kind of protections for keys that the relying party ma= y
=C2=A0 =C2=A0assume, not to the identity of the end user.


--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O= ( IPv6 I=C3=B8T consulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide



--
Iotops mailing list
Iot= ops@ietf.org
https://www.ietf.org/mailman/listinfo/iotops<= /a>
--00000000000071183505c034949a-- From nobody Sun Apr 18 06:52:05 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F03A18BE; Sun, 18 Apr 2021 06:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 J9WDxjyTqi6O; Sun, 18 Apr 2021 06:51:58 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1903A08E2; Sun, 18 Apr 2021 06:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4351; q=dns/txt; s=iport; t=1618753918; x=1619963518; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ZnrgSACDy265bfippjbwHZAMPq+WcKN64HohnWZ6RZA=; b=deAmgnn+1KIC+IVFR0icdj7Ha1UCbU5ZRDAI4eyk1XAQCCMFOz1IWiFO 0JCKiiREh0UzQNDCcQUnNgaAXeQ1FvGU0qaq9Em1+USgbhnZItgwp7G/N T0nDZT/p2oGV3JpX+uAqJrJg7/s76jz91+JuhynsUc9R8o+9Tp37Dv3Mk M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BHAADyOHxg/xbLJq1RCRkBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QESAQEBAQEBAQEBAQEBghKBI4JVAScSMYRDiQSISiUDh3uMTIggBAcBAQEKA?= =?us-ascii?q?wEBNAQBAYRQAoF0JjgTAgMBAQEDAgMBAQEBAQUBAQECAQYEcROFXYZEAQEBA?= =?us-ascii?q?QIBI1YFCwsECgoqAgJXBgoJgnEBgmYhqWp5gTKBAYRYhQ0QgToBgVKFLgGGU?= =?us-ascii?q?0OCC4E6DBCCXz6EDAqDQzaCKwSBZYEfghUBAUMOlFcBiGKBJp0HgxaDP4FGm?= =?us-ascii?q?AcEH5Q3kEuGTIt7ohCEAQIEBgUCFoFrI4FZMxoIGxVlAYI+PhIZDpxuPwMvO?= =?us-ascii?q?AIGAQkBAQMJjQ8BAQ?= IronPort-HdrOrdr: A9a23:TkDDr6PtFuU328BcTkOjsMiAIKoaSvp033AA3SlKOH9oW+afkN 2jm+le6A/shF8qNE0ItNicNMC7IE/02oVy5eAqV4uKfA6jg2ewKZEn0I2K+V3dMgnz7PRU26 slU6UWMrDNJHx7icq/3wWiCdYnx7C8n5yAvuvVw3dzQQwCUcgJhDtRMQqVHlZ7QwNLH/MCZf +hz/BarDmtc2l/VKqGL0QCNtKzxeHjpdbDaR4CCwVP0njrsRqYrJjnDhOfwhASFxRIzLtKyx miryXJooO+rvq81hjQk1X20q0Tst7gxtxfbfb87fQoFg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,231,1613433600"; d="asc'?scan'208,217";a="32728868" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Apr 2021 13:51:53 +0000 Received: from [10.61.144.102] ([10.61.144.102]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 13IDpqsZ025123 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Apr 2021 13:51:53 GMT From: Eliot Lear Message-Id: <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0666A8B7-607F-4184-B603-2304E93013A9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Sun, 18 Apr 2021 15:51:51 +0200 In-Reply-To: Cc: Laurence Lundblade , Ira McDonald , "rats@ietf.org" , "Smith, Ned" , "iotops@ietf.org" , Henk Birkholz To: Guy Fedorkow References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.102, [10.61.144.102] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 13:52:04 -0000 --Apple-Mail=_0666A8B7-607F-4184-B603-2304E93013A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_53FEE98E-1B7A-44FD-BCE2-04955DB5B26B" --Apple-Mail=_53FEE98E-1B7A-44FD-BCE2-04955DB5B26B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the delayed response: > On 2 Apr 2021, at 19:05, Guy Fedorkow wrote: >=20 > Hi Laurence, > I agree that IDevID is intended to persist through the device=E2=80=99= s lifetime, while LDevID is meant to represent the current owner. Yes, that was the original intent, and even the current intent. And = while that is necessary, it may not be sufficient for long supply chains = where ownership passes from one to another. The LDevID is an = owner-assigned name, and so the question is this: when an owner goes to = transfer, does it need to use the IDevID again or should it use the = LDevID? There are benefits and drawbacks to both, but if the LDevID is = used, then it is used as the IDevID would have been as part of that = transfer. The nice thing about FDO is that it keeps an entire record of = these sorts of transfers. Eliot --Apple-Mail=_53FEE98E-1B7A-44FD-BCE2-04955DB5B26B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry= for the delayed response:

On 2 Apr 2021, at 19:05, Guy = Fedorkow <gfedorkow@juniper.net> wrote:

Hi Laurence,
  I agree that IDevID is intended to = persist through the device=E2=80=99s lifetime, while LDevID is meant to = represent the current owner.

Yes, that was the original intent, and even the current = intent.  And while that is necessary, it may not be sufficient for = long supply chains where ownership passes from one to another.  The = LDevID is an owner-assigned name, and so the question is this: when an = owner goes to transfer, does it need to use the IDevID again or should = it use the LDevID?  There are benefits and drawbacks to both, but = if the LDevID is used, then it is used as the = IDevID would have been as part of that transfer.  The nice thing = about FDO is that it keeps an entire record of these sorts of = transfers.

Eliot

= --Apple-Mail=_53FEE98E-1B7A-44FD-BCE2-04955DB5B26B-- --Apple-Mail=_0666A8B7-607F-4184-B603-2304E93013A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB8OXgACgkQh7ZrRtnS ejObEQf/TMJVTvPdSyo+zqPjZRiLAR87mZMgWqpk4ZWBALtuM1MQnkWvdot/0MmB NdOvj+YgxcYcvhumjiYhWTRP9BayzLa9Tt8l6d3smvz6+ZG1RVtlgYdUj5jObOmG kPr25HB7LXMIw7EczoFGKZJlYGOy0v50+1nm3ex56U2M/b9fbhzn8wBjBMjv7rjM B2vsqclgJzGZefUbhK8zcwSFx3ZdXQxfzlZmyMZDeG4KxEViXoKpTKszfxgV9Ks5 KwvPssDdJIlWYwO0LGEQmU5lQFhcjrphnZPrw86VARm5BxBGWqmRmUsb9bF/v8ns ol17oUoLbWpqqsfF7qlVrQ0ggLOY9A== =FH4J -----END PGP SIGNATURE----- --Apple-Mail=_0666A8B7-607F-4184-B603-2304E93013A9-- From nobody Sun Apr 18 10:40:16 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78F73A20F2 for ; Sun, 18 Apr 2021 10:40:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Lhw8kQX76vaL for ; Sun, 18 Apr 2021 10:40:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9498D3A20F0 for ; Sun, 18 Apr 2021 10:40:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 16A1C300BE6 for ; Sun, 18 Apr 2021 13:31:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DwbIh3SjE3-n for ; Sun, 18 Apr 2021 13:31:19 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EA932300232; Sun, 18 Apr 2021 13:31:18 -0400 (EDT) From: Russ Housley Message-Id: <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D2BEF9E2-B8A5-427A-85B1-52680F2B2525"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Sun, 18 Apr 2021 13:31:19 -0400 In-Reply-To: <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> Cc: Guy Fedorkow , "Smith, Ned" , Henk Birkholz , "iotops@ietf.org" , "rats@ietf.org" , Laurence Lundblade , Ira McDonald To: Eliot Lear References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 17:40:16 -0000 --Apple-Mail=_D2BEF9E2-B8A5-427A-85B1-52680F2B2525 Content-Type: multipart/alternative; boundary="Apple-Mail=_C18FC50E-DED1-4B89-BF8A-A2A6BCE75F23" --Apple-Mail=_C18FC50E-DED1-4B89-BF8A-A2A6BCE75F23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 18, 2021, at 9:51 AM, Eliot Lear = wrote: >=20 > Signed PGP part > Sorry for the delayed response: >=20 >> On 2 Apr 2021, at 19:05, Guy Fedorkow > wrote: >>=20 >> Hi Laurence, >> I agree that IDevID is intended to persist through the device=E2=80=99= s lifetime, while LDevID is meant to represent the current owner. >=20 > Yes, that was the original intent, and even the current intent. And = while that is necessary, it may not be sufficient for long supply chains = where ownership passes from one to another. The LDevID is an = owner-assigned name, and so the question is this: when an owner goes to = transfer, does it need to use the IDevID again or should it use the = LDevID? There are benefits and drawbacks to both, but if the LDevID is = used, then it is used as the IDevID would have been as part of that = transfer. The nice thing about FDO is that it keeps an entire record of = these sorts of transfers. I think it depends on whether the new owner trusts the issuer of the = LDevID. If so, then leveraging the existing LDevID may be = straightforward. If the new owner does not trust the issuer of the = LDevID, then resetting the device to the factory default settings, which = would include the IDevID, makes a lot of sense. Russ --Apple-Mail=_C18FC50E-DED1-4B89-BF8A-A2A6BCE75F23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 18, 2021, at 9:51 AM, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Signed PGP = part
Sorry for the delayed = response:

On 2 Apr 2021, at 19:05, Guy = Fedorkow <gfedorkow@juniper.net> wrote:

Hi Laurence,
  I agree that IDevID is intended to = persist through the device=E2=80=99s lifetime, while LDevID is meant to = represent the current owner.

Yes, that was the original intent, and = even the current intent.  And while that is necessary, it may not = be sufficient for long supply chains where ownership passes from one to = another.  The LDevID is an owner-assigned name, and so the question = is this: when an owner goes to transfer, does it need to use the IDevID = again or should it use the LDevID?  There are benefits and = drawbacks to both, but if the LDevID is used, = then it is used as the IDevID would have been as part of that transfer. =  The nice thing about FDO is that it keeps an entire record of = these sorts of = transfers.

I think it depends on whether the new owner trusts the = issuer of the LDevID.  If so, then leveraging the existing LDevID = may be straightforward.  If the new owner does not trust the issuer = of the LDevID, then resetting the device to the factory default = settings, which would include the IDevID, makes a lot of = sense.

Russ

= --Apple-Mail=_C18FC50E-DED1-4B89-BF8A-A2A6BCE75F23-- --Apple-Mail=_D2BEF9E2-B8A5-427A-85B1-52680F2B2525 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE3ZgmxD9TboJgMKMUcGKjIhkfjnwFAmB8bOcACgkQcGKjIhkf jnybpA//Yy5OUYa6I+3Eh2QUW1Nvh5x2MmaAFBSBLTIcvSwexQSsbjkMGc9+nWCc UgXI3B7/7B2d1okVGLozOi2gsJC3EM4jgW6/BagQkdt7H3lkeznYr5J1JzR5yeDz DiDnsNIYDGjquSgFzUWtdZSCkwHqdsdFxS5OiZIkf0wDldDOfVdNdd2bS6G5F41x 6dO08/tRm6tltwCRgQmiquZfEteyr6DpEr3iDDgB+XuOB7N0WBWdHzD209/Zmrmt ztKg0hKbOQLWKcUVt2zQs1ly27CfEAfNkJPKev6fkMnLCupt5UV5v0+Ne0tbdZxI DiSKhgSoxXfo348oM5gb1q5T/YauKjcAwPKYg5LdJg5NrH0CRfuuPJeH+TpCZHIe AkG4KqXnp0DP5Xh2+e75Ma/s/hEszO8u+n+8GAb8UJaPt0f+8sw8CnYrRflMn7OR cQ/AyORUz92R09peRSKhYKPM50d/LxZpCtlobkcbhAlGzmIO6iw8/2wRAsI+DCut YbnvFnefEK5gipFWtyi8HXektQJXQhcSBRWBxcpi9YA4RcpsSnGeaEhi1ITQZ7we 300kGxsCceBWGtcEa69yVS2XXZ9hHQMsDW4SxXstbsk7RnuFUpyij4eFB3/h1HsO ljfKwDpQNFbxJnvTI5DMbpUxPtmGjjCBm/L00X47g7Ep+xeaBHA= =F41p -----END PGP SIGNATURE----- --Apple-Mail=_D2BEF9E2-B8A5-427A-85B1-52680F2B2525-- From nobody Mon Apr 19 05:24:17 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DF33A2F68; Mon, 19 Apr 2021 05:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=LgNR3n6p; dkim=pass (1024-bit key) header.d=juniper.net header.b=ZcJth+oH 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 Vocf3j91eGYE; Mon, 19 Apr 2021 05:24:06 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 0A3533A2F6D; Mon, 19 Apr 2021 05:24:05 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13JCHmTa010715; Mon, 19 Apr 2021 05:24:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=vJLibrWRG3ZoZ7aFMl6PJC04js0jJx3cLz1rYg/Yp4g=; b=LgNR3n6pLFiyKluwhT8BYvWuuETSrXQJqcnfoI2/pfXAUatZ7Ff2RJ9lvUPzvGl4qo8G XH3Hoa/dlYE3OJupO9cusLrE0hCG/X88PvcNV1PwS9xj4GUfC/L5GWrv+3pys2OGYBdJ +6vQCYAr+Vk7+ZcRw2KplZCS6OA4CpBeAjpXUbXHPF/GyBZO2KgP2lLGf5iFDrvpIelM ZTV2/pno4xw9N0qDmD9vnV+Fh44/bh1fnZvgh9Onb0PV+e0bSxHjRE6M8duy/aaJsSu6 QQtwH5BQONHjznbRdkosnS+07uKXkC6DnuEJfdlwl3YmXVIYZGtQK9/KteUGODyMY7e0 Bw== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) by mx0a-00273201.pphosted.com with ESMTP id 380q0ts5sx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Apr 2021 05:24:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T9o+ysUasbH9oih096TeQ2Jsw9s2JR6z6tGeHcVB99xEoGN+XemZD85LDbbPbO3UdDC4JoNLj0ifv7dQEsSaNZVtC0aizr6UAnXr4pq7NBU+OHhOi6VT360TEIPX4Qv74hMrecViuMo9SYt/1M1hrzzjQuEhZr2gsRd2lfv++7qbtYJntLqb9mdHRuFUTPwD1KWY4R6jvfo4mccUZIgWCX2Na5W4Uw+LrxZDThjH6qg4ZGImJ+e9ENZjOJ6762dai5pFmTaTq1SSJFGh213oLFw2ti8BwC8gorQcba9V5li8CpsHvrJvBgMZzFvNubiqjfPm5yeh5dfctxzApp1x8g== 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=vJLibrWRG3ZoZ7aFMl6PJC04js0jJx3cLz1rYg/Yp4g=; b=C9+2WIpNl0AKtqI3p1/EwE9OOa7VjUYNfLf/XfyhPX4xfQX7dCprEOHpVOw3IBvE/sBiv4LkuNQplRvPYl8ppBeEY3MWvwtN5U7aLWYYJOq0BJEzWqiReqRwH7oQX1p5srZ8IO9am4cbAk+VowTfS4GbVsojWQFoETmaiF//HjDzeaA5ryArrR9JpmPb7tHAIDEmxvTM7WUVSmpzw2VwiWbqRevqACBwb368MTy7gwpABXImoYzJpt0m89NU/ZZZVaZf9LbODcwEqdXlb8y00C42B/4uQgWlro989vMkhdYERbV57wbvLOGiEegisJuOrTSsbqZr8bGzc8zVjIXDgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vJLibrWRG3ZoZ7aFMl6PJC04js0jJx3cLz1rYg/Yp4g=; b=ZcJth+oHaZDb33qCmVFb4T0F3BgKEE7ksGStc8LDFPkZ+QIR+jBxj+uRilmKWU09D67UmLd+pwErQNliQTaMCnWIbFYWLmqxEZGKHAyo48ooAJHdfE3/2yxY5ch6SH6bc8Co2joPhn8sItDByogOFdd8SZ3Ux/sOB0+eitmqCAg= Received: from BLAPR05MB7378.namprd05.prod.outlook.com (2603:10b6:208:298::10) by BLAPR05MB7361.namprd05.prod.outlook.com (2603:10b6:208:292::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Mon, 19 Apr 2021 12:24:00 +0000 Received: from BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::a935:fb1d:c457:972a]) by BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::a935:fb1d:c457:972a%3]) with mapi id 15.20.4065.018; Mon, 19 Apr 2021 12:24:00 +0000 From: Guy Fedorkow To: Eliot Lear , Laurence Lundblade CC: Ira McDonald , "rats@ietf.org" , "Smith, Ned" , "iotops@ietf.org" , Henk Birkholz Thread-Topic: [Rats] 802.1AR device identity Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOAgACzxwCAAAOuAIAXhE8AgArnz9CAGPKigIABd0Xg Date: Mon, 19 Apr 2021 12:24:00 +0000 Message-ID: References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> In-Reply-To: <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-04-19T12:23:58Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5a60f453-789b-4854-91a3-ba6bcebed7d6; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [24.62.29.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd828a3a-ed82-42c5-c58a-08d9032e02ef x-ms-traffictypediagnostic: BLAPR05MB7361: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2GgbL42MFIN5cW6SKtO1fpGOowbl3hxL2fku9UtH8Brm3vEMG7BwkasMHkoD/IfQqrUry5AeJEX3XE4F3mNILOxjoa7Byj525t+CboOPuw6DpoRQf15z7rIr4YKGJ6wd8Mrc2RjgjKoKJmx4v+TsHj6Vxtcnv31mKnrOJ3LqApVh1Cd35DlWmmhUPnx6jiSd1XiEjddpPXw6A7udBoHJYXp8V0Zk9iSfrK9Ge5sMJVz533YP6GJprtcMRztT84PZwMrBjymD/DLZDpcbIgK/pW3ifirG0R6CLB/K+I/VOGIlRNCGbBg8Fss/ZBUlsWVRkAGM0Jmf7RqhwSyOlvOKy5ZjdB4IsuUFhdfnGFiPPS549HnOnOxt7B34nz2RDUaW7aLD/NimT1VHyAcfWftDRkLCjGpaaA+e2A25feNj5Na8Xd/ehX3dw4U6ZsfdV+Un3vrbLnrkx28KWGe3YT/URiE9SqKxQsZ7apy5baM+UK/I4L7eDk0Hd4cNC0My0jdX0wvgGP1UXUOcCFdfHbUEcoLQHX+x4HWlNCmMxLGCNNFOwi+nU5+0qbZskzCTyCg41mnPopS5y/zU8FkoS5jFM9GPQDb0l1YgwJ9G05/JqNw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR05MB7378.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(346002)(366004)(376002)(86362001)(6506007)(8936002)(122000001)(38100700002)(54906003)(7696005)(2906002)(66946007)(71200400001)(66556008)(4326008)(52536014)(66616009)(55016002)(110136005)(5660300002)(9686003)(66476007)(76116006)(66446008)(8676002)(64756008)(33656002)(316002)(4270600006)(26005)(186003)(99936003)(558084003)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Czr/Oiye26hr1zsCtVPyu/Ae8op56u40T56ImaHQyr6auh2UsnDiSTv6wj4S?= =?us-ascii?Q?hTOkz8Y0J0WcXti95I7JQBIE+CbmXmrOqPA996Get3NTSYqmFktlNLP06WTC?= =?us-ascii?Q?0fqs53VjjtWb7coKbtkeW65Th8LyFb913cZU654QsihE1BnKy2tiL1chqKZ2?= =?us-ascii?Q?hwRNCrhh8W/7n9AwnuqeS5Jrd3BUa2sHY/c4vY/G4TR1dh3GxY5k09WALlyA?= =?us-ascii?Q?qFLKmg2QKSAjqBKid4xuFeIUbxjU1fNFpwq6gtNSiezg3N61mZeJNXc63NTb?= =?us-ascii?Q?Uk0uExI3TEaNDGHA9tQtY8dwypIGIDeZ9cQ62mYk/Inaa2ecTWvo13182B8U?= =?us-ascii?Q?1nM5EM1oIFXJg2IrawHNqOVz8ixqrOoMAmTUZdtmwMa10CFYh6IUs+FCQKVh?= =?us-ascii?Q?b4rSuC+yrVt19+NNeNK+cDXYep8734Esm6c/M1RUIx9vtzreNjjT5qhbT/jy?= =?us-ascii?Q?1BLYEJFoKP8SMQD3tnnjUzaQJ1TWdwjEKoQbGPNq10mGcH4tGfkze/D+qSPB?= =?us-ascii?Q?q05PTiPoD7tRitG19nzM+na63cqVit3fincUvHjeUHRgQV1hJNAEW+xtdle7?= =?us-ascii?Q?Musya4wFhVaLHcjpc4UMQ2gmgTv3tOTpXXZnkoADmiyBjTK6kpK7gac/ESxP?= =?us-ascii?Q?vRnciDDTJ/+c0lLKgBLwDhboN1g97uMXJM/wha7uFW1pYHp4esdb+oTWwt8d?= =?us-ascii?Q?6SpiVyb9OEdTPEKF87ARqj6mkYeDL0Xp/PzfTgC1Iqgko8vtrBoXq7Ze8KEB?= =?us-ascii?Q?TYfVIW+IgpkRltCcPtYmXVAmSL0Nx86B0t0PJfGmG1YR4UU1eS2R+qvCRUg7?= =?us-ascii?Q?xpoKkKQ/xlTOWquQwR42IBvOCVJPtcN3nWwP4Sce8BBLxnE+o3Jrxc0BwV9p?= =?us-ascii?Q?U8xpfbmKnV83ZQryIJ6fBDYYnv9g5DcFQNNwXAySdGQHQ/qDy1cKIZySO5i1?= =?us-ascii?Q?8pb4GJp/qcG+2k7JClZ5p0VaAV6JdHLXU8++YKma/h43g8iS9QKqQUiivFDb?= =?us-ascii?Q?KFxgZQKdTwPbysFom0LQtFabuzfkfyNL1KRgxr6uxq/Le5EMZH/VyiEQOgkx?= =?us-ascii?Q?T6HPycdVTQntcSl7AccUrK0ek9sPDcT/c/t5R5wY2CsCkbXY0XiiXVsII7td?= =?us-ascii?Q?cPQf42YpyQf+wniODaK+U325X7pEDZq8ugghnC9K0mYJoh6dufH9RUohKqdd?= =?us-ascii?Q?1hV3t4yyXPF+N7bLOwQaPsGkYt8U1kQw3gi2X3NcuMDl0dqoM9t1H0cyH7Du?= =?us-ascii?Q?f1Nm4xsXQ3cLFn4xr25jsfIjp323c5hcPlhUbDD6z/o2ZuSMSh/4aeAs/3tE?= =?us-ascii?Q?bCw=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256 ; boundary="=-=ymdwEPK3CXo5sT=-=" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR05MB7378.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd828a3a-ed82-42c5-c58a-08d9032e02ef X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2021 12:24:00.0869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: z4gyPkSYUIZNxpF2LtHGRzbXFOAm/PdpAAdFtkv+jP6hE4L2+bIfE243Gefr5n4crFZPbkOj0XOntNiZt9UYdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7361 X-Proofpoint-ORIG-GUID: 2_8ODXR9Af9YF6fVRmF5_9aO_lnZGjHV X-Proofpoint-GUID: 2_8ODXR9Af9YF6fVRmF5_9aO_lnZGjHV X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-19_07:2021-04-16, 2021-04-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 spamscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 clxscore=1015 bulkscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104190087 Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 12:24:11 -0000 --=-=ymdwEPK3CXo5sT=-= Content-Type: multipart/alternative; boundary="=-=XJh/pPhNRedcWy=-=" --=-=XJh/pPhNRedcWy=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Laurence, I agree that onboarding is the most-obvious use-case. Security-related c= onfiguration that should be applied only to specific identified devices is = another use. I think of IDevID as the serial number plate the manufacturer etches into= a laptop, while LDevID is the asset tag the corporate IT department or its= outsourced supplier sticks on the laptop. If you=E2=80=99re using the laptop in the same corporate context, the ass= et tag number is the uniform identifier across the org, and that=E2=80=99s = likely to be the right thing to use. If you bought it on ebay, use the IDe= vID! But it seems clear 802.1AR wasn=E2=80=99t designed with the intent of tra= cking devices through a chain of owners. For that you might want something= like the TCG Platform Certificate. /guy =20 =20 From: Eliot Lear =20 Sent: Sunday, April 18, 2021 9:52 AM To: Guy Fedorkow Cc: Laurence Lundblade ; Ira McDonald ; rats@ietf.org; Smith, Ned ; iotops@ietf.o= rg; Henk Birkholz Subject: Re: [Rats] 802.1AR device identity =20 Sorry for the delayed response: On 2 Apr 2021, at 19:05, Guy Fedorkow > wrote: =20 Hi Laurence, I agree that IDevID is intended to persist through the device=E2=80=99s = lifetime, while LDevID is meant to represent the current owner. =20 Yes, that was the original intent, and even the current intent. And while = that is necessary, it may not be sufficient for long supply chains where ow= nership passes from one to another. The LDevID is an owner-assigned name, = and so the question is this: when an owner goes to transfer, does it need t= o use the IDevID again or should it use the LDevID? There are benefits and= drawbacks to both, but if the LDevID is used, then it is used as the IDevI= D would have been as part of that transfer. The nice thing about FDO is th= at it keeps an entire record of these sorts of transfers. =20 Eliot =20 --=-=XJh/pPhNRedcWy=-= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Laurence,

=C2=A0 I agr= ee that onboarding is the most-obvious use-case.=C2=A0 Security-related con= figuration that should be applied only to specific identified devices is an= other use.

=C2=A0 I think of IDevID as t= he serial number plate the manufacturer etches into a laptop, while LDevID = is the asset tag the corporate IT department or its outsourced supplier sti= cks on the laptop.

=C2=A0 If you=E2=80= =99re using the laptop in the same corporate context, the asset tag number = is the uniform identifier across the org, and that=E2=80=99s likely to be t= he right thing to use.=C2=A0 If you bought it on ebay, use the IDevID!=

=C2=A0 But it seems clear 802.1AR wasn=E2=80= =99t designed with the intent of tracking devices through a chain of owners= .=C2=A0 For that you might want something like the TCG Platform Certificate= .

=C2=A0 /guy

 

 

From: Eliot Lear <lear@cisco.com&= gt;
Sent: Sunday, April 18, 2021 9:52 AM
To: Guy Fedor= kow <gfedorkow@juniper.net>
Cc: Laurence Lundblade <lgl@= island-resort.com>; Ira McDonald <blueroofmusic@gmail.com>; rats@i= etf.org; Smith, Ned <ned.smith@intel.com>; iotops@ietf.org; Henk Birk= holz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Rats] = 802.1AR device identity

 

Sorry for the delayed response:<= /o:p>



On 2 Ap= r 2021, at 19:05, Guy Fedorkow <gfedorkow@juniper.net> wrote:

 

Hi Laurence,

  I agree that IDevID is inten= ded to persist through the device=E2=80=99s lifetime, while LDevID is meant= to represent the current owner.

 

Yes,= that was the original intent, and even the current intent.  And while= that is necessary, it may not be sufficient for long supply chains where o= wnership passes from one to another.  The LDevID is an owner-assigned = name, and so the question is this: when an owner goes to transfer, does it = need to use the IDevID again or should it use the LDevID?  There are b= enefits and drawbacks to both, but if the LDevID is used, then = it is used as the IDevID would have been as part of that transfer.  Th= e nice thing about FDO is that it keeps an entire record of these sorts of = transfers.

 <= /p>

Eliot

 

--=-=XJh/pPhNRedcWy=-=-- --=-=ymdwEPK3CXo5sT=-= Content-Type: application/pgp-signature; name="openpgp-digital-signature.asc" Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEESFo/zAtP6qpDox3gvr89Xqx03boFAmB9dlIACgkQvr89Xqx0 3bpVvwf+K7QSnR8mWtNfpICnKIpGNDPJTtGgArXuqxosGHMbh+zWxQM+PKoF8X2k G75fhJQi7dYzPWyNAYfueqr81Yq+KSNbHILVeIoQ4IuqtC9Uco0kw8F3soGK1HmU BhsILDylOoMU2F1SgRNjcPl6zVx0zmq6pZ+kkL+oLPBR+fJonPGauFKeuDIQxsqJ CgJMP+WcC/QvV8qhRCU4VQu5NMTUK30GmBMD50BARqab7X3Ani78Pp8Ocmx1MfLe J1mofq9hSOYAszNk2i8GPl3F3bjZlTXqh/6G+kLzDVFqb+c7H/tXTk/SbsSh4agj VI7pcCbnIKIDJhYns3Ni+JetYBK7uA== =vVHr -----END PGP SIGNATURE----- --=-=ymdwEPK3CXo5sT=-=-- From nobody Tue Apr 20 07:02:29 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8033A251D for ; Tue, 20 Apr 2021 07:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fraunhofer.onmicrosoft.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 8UPBk4-HEeeW for ; Tue, 20 Apr 2021 07:02:22 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 5BDC23A251A for ; Tue, 20 Apr 2021 07:02:21 -0700 (PDT) IronPort-SDR: H0B2YNfTiE+dsFWRGhYaY9enc0Fg8ZFe6iUGO96D1TlPXDHrNOGpcZ2Nx2fOCBAlesEDbg21fR RhJOv+KYfQNg== IronPort-PHdr: =?us-ascii?q?A9a23=3AKwlDvxOAbkF13wcinkwl6nf9WUAX047cNxMJ6?= =?us-ascii?q?pchl7NFe7ii+JKnJkHE+PFxlzfhXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXT?= =?us-ascii?q?BYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXE?= =?us-ascii?q?w/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjtgTN8McMiJZkKqE/x?= =?us-ascii?q?wGPrnYbE9k=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FVAABC3n5g/xoHYZk+HBwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBgX8GAQELAYFSKSh+gUELhDhXgnIBAYU5iEWZbYEuFAyBBQM?= =?us-ascii?q?YPAsBAQEBAQEBAQEEAQMBKggCBAEBAwOFAYFBASU1CA4CAwEBDAEBBgEBAQE?= =?us-ascii?q?BBgQCAoEAhVANg1U9DT4BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEFAkFHDBIBAR8EJB0BATgEFEQCNA4dDQgBAYJtAYJVAw4gAgMLQIw?= =?us-ascii?q?ukG0CixiBMoEBggQBAQaBNwIBDUEyEoJjGFiBNAcDBgkBgTABgneGS4QSJxC?= =?us-ascii?q?BVUKBEycPhC6BXAICARd6EoNRgmGCBoF7BGZbnxENilKPV4IoLAeBc4EcgSA?= =?us-ascii?q?GC4NUhGOTGQULIIM9Eop/hG12Bol7hlChD5dNAgQCBAUCDgEBBmJzAYISTSS?= =?us-ascii?q?CERiBD1AXAg5XjUgMCwuBAgEIgkOFFIVLcQI2AgYBCQEBAwkBe4sDAYEPAQE?= X-IPAS-Result: =?us-ascii?q?A2FVAABC3n5g/xoHYZk+HBwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?X8GAQELAYFSKSh+gUELhDhXgnIBAYU5iEWZbYEuFAyBBQMYPAsBAQEBAQEBA?= =?us-ascii?q?QEEAQMBKggCBAEBAwOFAYFBASU1CA4CAwEBDAEBBgEBAQEBBgQCAoEAhVANg?= =?us-ascii?q?1U9DT4BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAkFHD?= =?us-ascii?q?BIBAR8EJB0BATgEFEQCNA4dDQgBAYJtAYJVAw4gAgMLQIwukG0CixiBMoEBg?= =?us-ascii?q?gQBAQaBNwIBDUEyEoJjGFiBNAcDBgkBgTABgneGS4QSJxCBVUKBEycPhC6BX?= =?us-ascii?q?AICARd6EoNRgmGCBoF7BGZbnxENilKPV4IoLAeBc4EcgSAGC4NUhGOTGQULI?= =?us-ascii?q?IM9Eop/hG12Bol7hlChD5dNAgQCBAUCDgEBBmJzAYISTSSCERiBD1AXAg5Xj?= =?us-ascii?q?UgMCwuBAgEIgkOFFIVLcQI2AgYBCQEBAwkBe4sDAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.82,237,1613430000"; d="ics'?scan'208";a="42027673" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2021 16:02:18 +0200 IronPort-SDR: rL3hrQar1oKP6V+fZbTdaiRfL4uFx1x3RwhHKqmc7z6BPIB670OyGGQKTcs0ZL0NqgFdKdW79G af4LH+pzCp1U1UunVGfpRN48DtkxeOtCE= IronPort-PHdr: =?us-ascii?q?A9a23=3Ac58mqhNBPH87ONIgzc8l6nf9WUAX047cNxMJ6?= =?us-ascii?q?pchl7NFe7ii+JKnJkHE+PFxlzfhXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXT?= =?us-ascii?q?BYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXE?= =?us-ascii?q?w/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjtgTN8McMiJZkKqE/x?= =?us-ascii?q?wGPrnYbE9k=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Astqw/63pbkKfpdLq/jOgUgqjBCIkLtp033?= =?us-ascii?q?Aq2lEZdDV+dMuEm8ey2MkB3RjvhzoLHF0mk9aMOK6PKEmskKJdy48XILukQU?= =?us-ascii?q?3aqHKlRbsSj7fK7jX8F0TFmdJ1+Ktkc7dzE9H8SWV95PyR3CCWCNAlqePozI?= =?us-ascii?q?mNpcPzi0hgVhtrbaYI1WdEIyKWCFd/SgUDJZdRLuv72uN9qzCteWsaY62Abx?= =?us-ascii?q?FvMoT+jufWn5HrawNuPX8awTSJ5AnYj4LSIly91hcaXygn+8ZAzUH11yrj5q?= =?us-ascii?q?uitPm/jiLbvlWji6hrpA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAAD93X5g/z6wYZk+HBwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBSYE2BgEBCwEBgVEpKAdMK1pnC4Q4V4JyAQGFOYhFaAGZBIE?= =?us-ascii?q?uFAyBBQNUCwEDAQEBAQEEAQMBKggCBAEBhQeBPgImNQgOAgMBAQwBAQUBAQE?= =?us-ascii?q?CAQYEcROFUA1DAQwBhXUEJB0BARQkBBREAjQHBx0NCAEBgm0BglUDDiACAwt?= =?us-ascii?q?AjC+QbQKLGIEygQGCBAEBBoE3AgENQTISgmMYWIE0BwMGCQGBMAGCd4ZLhBI?= =?us-ascii?q?3gVVCgRMnD4QugVwCAgEXehKDUYJhggaBewRmW58RDYpSj1eCKCwHgXOBHIE?= =?us-ascii?q?gBguDVIRjkxkFCyCDPRKKf4RtdgaJe4ZQoQ+XTQIEAgQFAg4BAQZicwE4gVl?= =?us-ascii?q?NJIIRGIEPUBcCDleNSAwLC4ECAQiCQ4UUhUtxAjYCBgEJAQEDCQF7gl+IJAG?= =?us-ascii?q?BDwEB?= X-IronPort-AV: E=Sophos;i="5.82,237,1613430000"; d="ics'?scan'208";a="141109088" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO XCH-HYBRID-02.ads.fraunhofer.de) ([153.97.176.62]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2021 16:02:13 +0200 Received: from XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Tue, 20 Apr 2021 16:02:13 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5 via Frontend Transport; Tue, 20 Apr 2021 16:02:13 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iVCh8D0JUeIDUERGC1xa68VQFh7KB6GefVO4CdFyRSyj3HMPtFj6qbeZw1bO6rF0T1HVIESzpA4j81BSPrlMla7MbdgxCm54/u9EKBf2jkzdB5WfwF6Iq4lk4Kdk32z9Gn1B7FLoQOjSU7Qsow1uwGPS1nYabx9ZjGSC/oLDo+H9Gqf8nP4scYH8Shmv+FSvE3asVrNhQayh7Z0xzfA/oepiKGLukc0TukTE0j5DUV6D6KWV4NGTcgbvK7GztJig82z8jkKtYkAPfIOajyFRRYPvYe7sUsc1A+eceut7t7C+rGTsq9D71NqQNaI02+OsPkqXZ+9B1AqL2I9n51Cy5Q== 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=M1y+hbekahyDKN4+BnQvP/v3jvCX3dBJgdugTPhfB0M=; b=gr1yw/K0We5GY4OtFwTv9zyyOD5DvtrF/JVdgsVaBdiO59+Ux0nPxatGRblW6DjhLhpOFvIUFC6q66jRDRh7tOi2YrmtiGgDV/GYRZ5LfWrUF/ABMCSKcbJPmAE5jMI4h2efZInhT4rY+sX9N++gS2vn3Ng5q8dU8e1D7OEvL+Ou0/3BcAyyo/VZJijQz9UwEduuty0H8wvIIBQS+ZleMTGwRYjHscBRy9YqOlXT/iQbdqOwvOLJM6CqSYqLxzbM6uPAr6LSkpCh6hTPIl9lpkRQbdCg8v8LREHzQwktZNSK9oo+z39wkuwY9pYf/DNyrePA57jjlU6cSGDHVoKE7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M1y+hbekahyDKN4+BnQvP/v3jvCX3dBJgdugTPhfB0M=; b=FXmO1ePX9voc51fEQ3JVrh04bJPvGcie5UJ/ySF1NU9Gn0JJu45Sk0z/wS2UAQ7H19IBaynzmZ1JSwM6IRIyBnmVNXsYbGIMfoINark33hyxUtnTvFUD9eBHvDewUZg5SGR7JrhIKpgETzrEUFl/F5nDXQT8EeBYXY28oZQovPc= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by DBBP194MB1052.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:1e4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Tue, 20 Apr 2021 14:02:12 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0%4]) with mapi id 15.20.4042.024; Tue, 20 Apr 2021 14:02:12 +0000 From: Henk Birkholz Reply-To: "iotops-chairs@ietf.org" To: IOTOPS Working Group Message-ID: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> Date: Tue, 20 Apr 2021 16:02:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/mixed; boundary="------------C2ED31553F1384ADA3651F8E" Content-Language: en-US X-Originating-IP: [79.234.119.37] X-ClientProxiedBy: PR2P264CA0019.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101::31) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.234.119.37) by PR2P264CA0019.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Tue, 20 Apr 2021 14:02:11 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1166fadc-af65-410f-7ba3-08d90404e531 X-MS-TrafficTypeDiagnostic: DBBP194MB1052: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PM+fzf6GPODHS1ficYXM6hkS0E7xQyRwFKAKwDJ7fKjf1WygYodloka2CktCHhEnppuSd4uOAcs0AASxgViPwpYrM/vAdtzu+eSepxdfT4jozWKI9xBw8iph4HLqbgUUovuzyzjEix1Fgd9MP4b6q/sbjVjAK6n0BB3xp4FGDP4LO060WAum01CFsaJ2LjtFGcI4Y8QQDse4BH33j9j/CWG3N/Novbr95eiT5gRT72MQFQQjLBb7ha0871cqXE5ICRf5pZ58jzfKOBGGCda5xTQO23SI4yFJiEfuPRNuOA1nM870SCghhv/XoCfy1/pFDDhARr9KxtIiCCUAWcmw8kjzn+UnZ+aUtvo2sfQknZ5FYYF64W0HhpKCpq33SQPCzh0497XNUpnyBDH3/B/tBbpgg0tsJqc0VT9GspFrdgvZUcWoglQmiM1hUbT2nCsfkLC4Y6KLfBVfYG2QNkkVwl4VJXvsGe1IMK5tbPtkRhMlL9dmY/53qLBk82wr8CGQ3UJCSFXTbhzxxILzvYvR8PcXi2P2UBsT4nsfYGHYGU4WD8Ci9K1//7g4zdfJLnegbNSHlIPna5fhiJ0Pa2WW4Q4VSCQPeZyRth8rEBF2TNZdstDTQYfdevGCsXXP3JIGjQAp7CcbxnzaoZQs77yqv/rOGiJ9KvTpnYSkdksrm5amKOAk/tLGQsIrIndP4L29jtrdSanZ3N0I3Hy0BWL1tWmWX7JUyZHoKhyWrDUgMJ/o6kOJTZPAt2ZNgKYARkwfeWmMFU8TWAUnFYi7vgu6h8ZtuddJcNUmrL7ic1Dd4dU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(6486002)(498600001)(956004)(66556008)(66806009)(66616009)(2616005)(966005)(83380400001)(8936002)(186003)(38100700002)(52116002)(38350700002)(8796002)(6916009)(16526019)(5660300002)(31686004)(235185007)(2906002)(86362001)(31696002)(66946007)(26005)(16799955002)(44832011)(33964004)(16576012)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eWRidmF6Z3lKOTFBVW5KN0FzTzFTdW5yS2lTRVJ4NlJPdk1aOHJkcXpBNTBz?= =?utf-8?B?dmwzNTFSTzBnVUNRZFZCRkl2cHJrM0loYkY0RVRHdzl1dUM3MFNpRTY2Wjl4?= =?utf-8?B?NnpGNFRNUVVYbzNvcXNLRHlKczJ5dTN2VmxoR2phTHZ3b3AzV2VJQVpOUEhP?= =?utf-8?B?M09MdkxFOXVUSUoxd3NTUzF1NXpRS09nUXpobGlwT05LNGhCUkxReml4VFha?= =?utf-8?B?RER6OVE3cjM1WkRxdVg3R045NUd1bGV4dC9BS2t3Vk0yOWxsNjhqRnl2UXov?= =?utf-8?B?YW4xODdZc3RkMHpidFJXY1pEeEYwZ0hJMkQxbzJxcS9wZ0tEWVAzeVVsbnMy?= =?utf-8?B?OVVzTUtQdkN6enFldDJiQ2tNU3k3Q2xOd0s4MlJ4YzltS05PbVVYVU9kNFYw?= =?utf-8?B?clEySGNadER1OWdGV3lmdlBTUUt0LytJa3JpTmYyQW0vTnMvQ3hSUExnQkZ6?= =?utf-8?B?ZTNwNUhwNmJGV1V4ZnlnYW0vTWlSQmQ0L2FYUTY1SWg5Tm45UEplUnMrOEVh?= =?utf-8?B?UWVYdXN5VEQ3ZVV3NTQxK3AvSEZUcW82OFlZRTJCYi9oUEFkMGM1eFpaaXZH?= =?utf-8?B?TXI3V25xaFhzLzhkdVQrS1JRWnhNRFFWSlZ6R0RDSm1HcUpDV0ZBYW8xcjRO?= =?utf-8?B?N0UzUGZjVUNMRGFLVW9Ob09PNWVlNmhKVlNVVzBLeW5WTVZWeHlVc2lEaDdx?= =?utf-8?B?SnByK1g5allpOGw3dWFuemI2VEJMMFgrVU9sZHpuU2VQNEx1a1Nabk5VWTI4?= =?utf-8?B?L2lWcDk2N2RtMHJ3NFM2bDlSdVlESEtZRmk0clM2OGRML0FjV21vSlAzSzk1?= =?utf-8?B?VlpTZk1rVTF6ZjczOTFBdmlDWUdYTTV1cTNHVGRhWm1TN0pLbndjaXFiVmNH?= =?utf-8?B?VHQzaVNBb2FjR3V6OTRlK2ZBbXU1M0tDOWNUclB4eDBWRENnVS81cUg5YnEr?= =?utf-8?B?aGVGdXdNdEFsSG9aYXVOVkg5V3Y1L09kbzVoNmY2akQzeEs1VGlvR1N3Y0s3?= =?utf-8?B?ZmlKd3hpaTV5T2dFK0FIRmhqSXpVcVJjVnR2UWZvSTVYM0EreklpdEViTHVP?= =?utf-8?B?cHluTmJKTzUwVFd4RVdlcHd4TGtxbVhhaGJqNEg3MW9NMVl6dk1KRXUwL0J5?= =?utf-8?B?VnR2ZjRUMms1YnVPVWtqdEV3NlRxZWQra3k3bkEzZVdXUWx5ZWRCN3ZuWW8x?= =?utf-8?B?ZlNWTDZxR3BFbElpNHJRUWJySHNFeXVKM3dXd2dzSkIwMEI5K1RxMXZ1QXFO?= =?utf-8?B?a2NvU3R4VVV0SjY0TXJ3WnRRckRxZkNLeUc4VGFKaGlJR0VvdmdZSkxaNnZL?= =?utf-8?B?cVV0WnB1VGk5V3N4a2swNmtEdkVqY2lMUXhTYTFwcG02SWpkaEc1Y2FuSnhJ?= =?utf-8?B?cTdFQ283MlhwNHNVclVudDR4SjFuQWlUaGJyUjFnSHAzRjFNUkVhOVBkcC9z?= =?utf-8?B?RXZDbzlCQzRKWGtwb2ZuK2dYV1FuME1INFYzeHJESU1XdmtJVitUa2VpUmU1?= =?utf-8?B?OU5oM0ttUDhCOXdrZWNaQWxhQngzRHE0Z3BtdENKSXlHQmo2dmMwUnI4L0NU?= =?utf-8?B?My9rYzZoQXN0Y0thUmQ3cEpBQkhGT2RwdkhReVlJS01xVGV2aTdGVURScnR1?= =?utf-8?B?TlhQcHpqQWs0UzBvbjR3UXNFNTdLQmkwK1FhcWR6cUtQRmNmT3hmc3R5SEJF?= =?utf-8?B?QVFTem4rNFRSdWRXUktmaHJaaTdlTWd6RHhMUThvUUhZWVhBYk5Xem0vMjVX?= =?utf-8?Q?Ca8HmDLtjrwodhkUw7CMecO/+B+Cp9IrCuc2MJZ?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1166fadc-af65-410f-7ba3-08d90404e531 X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2021 14:02:12.1809 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XZkYtxGsszy0S5qYn/jDEeWDDAv5wuASqLnNgxwF5ewpj5ifXkQICAq+dUGOOnh2jiaCuA9M3Gz4ZxnB6boz2YIB5T8Q/hbT2IE1uT5NMUE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP194MB1052 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 14:02:27 -0000 --------------C2ED31553F1384ADA3651F8E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear IOTOPS members, a quick reminder that the first IOTOPS WG virtual interim is coming in an hour (Tuesday at 15:00 UTC) via Webex: > https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e The agenda can be found at: > https://datatracker.ietf.org/doc/agenda-interim-2021-iotops-01-iotops-01/ The virtual interim duration is scheduled to be 2 hours of which a significant amount is dedicated to discussions on presentations and beyond. Please, find attached the information to join the meeting. For the IOTOPS co-chairs, Henk --------------C2ED31553F1384ADA3651F8E Content-Type: text/calendar; charset=UTF-8; name="ietf-interim-2021-iotops-01-invite.ics" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ietf-interim-2021-iotops-01-invite.ics" BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH PRODID:-//IETF//datatracker.ietf.org ical agenda//EN BEGIN:VTIMEZONE TZID:UTC BEGIN:STANDARD TZOFFSETFROM:+0000 TZOFFSETTO:+0000 TZNAME:UTC DTSTART:19000101T000000 RDATE:19000101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:ietf-interim-2021-iotops-01-13632-iotops SUMMARY:IoT Operations WG Virtual Interim (ietf-interim-2021-iotops-01) LOCATION:https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e STATUS:CONFIRMED CLASS:PUBLIC ORGANIZER;CN="IOTOPS Working Group":MAILTO:iotops-chairs@ietf.org DTSTART;TZID=UTC:20210420T150000 DTEND;TZID=UTC:20210420T170000 DTSTAMP:20210322T093140Z DESCRIPTION: Agenda: https://datatracker.ietf.org/meeting/interim-2021-iotops-01/materials/agenda-interim-2021-iotops-01-iotops-01\n \nMinutes (Minutes interim-2021-iotops-01: Tue 15:00): https://codimd.ietf.org/notes-ietf-interim-2021-iotops-01-iotops?edit\n END:VEVENT END:VCALENDAR --------------C2ED31553F1384ADA3651F8E-- From nobody Tue Apr 20 08:09:22 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5783A3A278D for ; Tue, 20 Apr 2021 08:09:16 -0700 (PDT) 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 M_iLU__HLsfY for ; Tue, 20 Apr 2021 08:09:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB303A276C for ; Tue, 20 Apr 2021 08:09:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B35DF390EF for ; Tue, 20 Apr 2021 11:16:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9u--ITH8ank5 for ; Tue, 20 Apr 2021 11:16:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9748F390ED for ; Tue, 20 Apr 2021 11:16:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 25C51AC for ; Tue, 20 Apr 2021 11:09:08 -0400 (EDT) From: Michael Richardson To: IOTOPS Working Group In-Reply-To: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 15:09:18 -0000 --=-=-= Content-Type: text/plain ietf.Webex.com has screwed things up for webrtc users. My understanding is that there will be some new solution/URL posted in minutes. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmB+7pMACgkQgItw+93Q 3WUXVwgAvYe5vDVrVt3Kpk8lMwA1VsO7M4BGT6dK94qhB0b/StP59yU2YOo3jVTD d3v5/J9yxm1Ww/OsIDx92fxWgSngyVydT4+mQe1sWXnmhEU1DgGZ3cK6XrEwp5TD yNdEa9SmSJ5pFT+yelzxiIBxnq0AXoFegOtWjmOol1JlJVvw9XHq0keNBVWkGQbc JAxbGYpdfgQkjc8D2K4l3QJZGFil2GTaT9sUWy3E3n6vUb8Vs2NQ+rp5fyNLwqxN 2uFSwNnVwvykj+FR6hwIUJVLiWa7+lNb5kz8FBSsDasqlUCWGXy/cVoy2ocKgFTE mtW0pv2FCQid/aiXWaQf6XOIuRmTbg== =B3nM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 21 00:30:58 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA75E3A1878; Wed, 21 Apr 2021 00:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 egkz6Mc83oJ2; Wed, 21 Apr 2021 00:30:48 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F233A1875; Wed, 21 Apr 2021 00:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7873; q=dns/txt; s=iport; t=1618990247; x=1620199847; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=rXxMftjgn1CroWFlj98pHnakAl0BQvxIrQn1517uHx0=; b=CrbNkONMhcAggaQOecCVpexjAq2P0hzUInZchomQ4Av2oMuloxFctQKr caBG7qEIjkv3W63CKEfisiGfxk3DtkNaqp1fGBAKCF5krrITWB06sF3op Lmc8ilu3EwMR7cDqXnzuefLcb3rLJ24jS48RKECVe2DRTiZpW7e+oXLj2 s=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AFAACT039glxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCAQEBAQEBAQsBgSJTggIBJxIxhEOJBIhLJQOHe4xNi?= =?us-ascii?q?CAEBwEBAQoDAQE0BAEBhFACgXUmNwYOAgMBAQEDAgMBAQEBAQUBAQECAQYEF?= =?us-ascii?q?AEBAQEBAQEBaIVdhkQBAQEBAgEjVgULCxgnAwICRhEGE4JxAYJmIadYeoEyg?= =?us-ascii?q?QGEWIUQEIE6AYFShS4BhlNDgguBEigMEIJfPoJgBIR1NoIrBIFaZgYIYCINR?= =?us-ascii?q?AEBgSAbBxl3A5ENA4xLnQ2DF4M/gUaYCgQhg0+QapBMlzKcVlWEBAIEBgUCF?= =?us-ascii?q?oFqIoFbMxoIGxVlAYI+PhIZDo44jjY/Ay8CNgIGAQkBAQMJikstghcBAQ?= IronPort-HdrOrdr: A9a23:R7/w8aGnuYn/UKGzpLqEG8eALOonbusQ8zAX/mp2TgFYddHdqt C2kJ0gpHzJoRsYRX1Io7y9EYaaR3e0z/BIyK0cJ62rUgWjmGbAFu5fxLDvyTHhBCHyn9Q1vc wLHpRWMsH6DlRxkK/BgDWQLtBI+ri62ZHtr/zZyDNASh4CUdADnmIJbnf9LmRGAC9bGJE+CJ 2Qou1AqjbIQwVvUu2LQl8YQuPEu9rH0KjDXCdDLRsm5A6S5AnYjoLHLw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,238,1613433600"; d="asc'?scan'208,217";a="35199518" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 07:30:44 +0000 Received: from [10.61.144.102] ([10.61.144.102]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13L7UhOW003655 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 07:30:43 GMT From: Eliot Lear Message-Id: <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_44CE5AE1-1F8C-4744-BCE2-48C4025E48B9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 09:30:42 +0200 In-Reply-To: Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org To: Brian Smith References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.102, [10.61.144.102] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 07:30:53 -0000 --Apple-Mail=_44CE5AE1-1F8C-4744-BCE2-48C4025E48B9 Content-Type: multipart/alternative; boundary="Apple-Mail=_688762BC-0D0B-419B-A847-24F17517D850" --Apple-Mail=_688762BC-0D0B-419B-A847-24F17517D850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [+iotops] Brian, > On 21 Apr 2021, at 00:22, Brian Smith wrote: >=20 > Eliot Lear > wrote: >> The issue for me is library support. If libraries take the doc too = seriously, it screws the apps that really need to do the right thing for = their use cases. >=20 >=20 > What you're trying to prevent is the entire purpose of this, as I had = originally proposed it. The goal is to have library developers feel = comfortable removing the CN-ID support completely from their libraries. Thanks for being crisp in stating your intent. Let's turn the question around, because perhaps I am missing something. = Bearing in mind that there are literally hundreds of millions of devices = with long-lived certificates fielded today, what advice would you give = to those who support applications that have to interact with them? What = harm comes to any use case for there to be a non-default library flag, = as Victor mentioned there is with OpenSSL? I would claim that there are three unacceptable outcomes: Causing the app developers to write their own X.509 validation code =E2=80= =93 they=E2=80=99ll get it wrong. Freezing app developers on old versions of the libraries =E2=80=93 we = want app developers to update. Library developers ignoring the IETF. Let=E2=80=99s not give advice = they simply cannot follow. By the way, one reason many of these devices have long lived certs is = that they might sit in inventory for long periods of time before they = are ever taken out of the box. There are other reasons, as well. = Burned in certs can be there as a base level anti-counterfeiting = measure, for instance. And yes, there are lots of issues with burned in = anything, but there are engineering tradeoffs to be made. To Jim=E2=80=99s point, maybe it would be possible to say that the flag = should be unavailable for certs issued after a certain date, but that = date would have to be well into the future, and coordinated at least = with IEEE. That seems like a lot of work for something that, as Rich = rightly alludes, is really a vendor decision to intelligently make. Eliot --Apple-Mail=_688762BC-0D0B-419B-A847-24F17517D850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[+iotops]

Brian,

On 21 Apr 2021, at 00:22, Brian Smith <brian@briansmith.org> wrote:

Eliot = Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
The issue for me is library support.  If libraries take = the doc too seriously, it screws the apps that really need to do the = right thing for their use cases.

What you're trying to = prevent is the entire purpose of this, as I had originally proposed it. = The goal is to have library developers feel comfortable removing the = CN-ID support completely from their = libraries.

Thanks for being crisp in stating your = intent.

Let's turn the question = around, because perhaps I am missing something.  Bearing in mind = that there are literally hundreds of millions of devices with long-lived = certificates fielded today, what advice would you give to those who = support applications that have to interact with them?  What harm = comes to any use case for there to be a non-default library flag, as = Victor mentioned there is with OpenSSL?

I would claim that there are three unacceptable = outcomes:

  • Causing the app developers to write = their own X.509 validation code =E2=80=93 they=E2=80=99ll get it = wrong.
  • Freezing app developers on old versions of the = libraries =E2=80=93 we want app developers to update.
  • Library developers ignoring the IETF.  Let=E2=80=99s not = give advice they simply cannot follow.

By the way, one reason many of these devices have long = lived certs is that they might sit in inventory for long periods of time = before they are ever taken out of the box.  There are other = reasons, as well.  Burned in certs can be there as a base level = anti-counterfeiting measure, for instance.  And yes, there are lots = of issues with burned in anything, but there are engineering tradeoffs = to be made.

To = Jim=E2=80=99s point, maybe it would be possible to say that the flag = should be unavailable for certs issued after a certain date, but that = date would have to be well into the future, and coordinated at least = with IEEE.  That seems like a lot of work for something that, as = Rich rightly alludes, is really a vendor decision to intelligently = make.

Eliot

= --Apple-Mail=_688762BC-0D0B-419B-A847-24F17517D850-- --Apple-Mail=_44CE5AE1-1F8C-4744-BCE2-48C4025E48B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB/1KIACgkQh7ZrRtnS ejPjaQf/cV/YWirgmhOsBljbt7rhgpPBE52dTDC13J9uKJIvkj6z7AzXTZpmMUDK esF/EkWCd7GotklA4Ncd/TlAVeolQMlaDPJ1UoONLllvenCv1I2hAeCRwB2M/VrW UtGXCEeIiZA05hlLtKdIzjcZxApaZc8MmYsNLzuRd7tPX/O7T8NFU8d/iKseEzSm LR2y7ZTovxpZOSodqG6X5dMRh0AzZFq9InJT4HtvqkxuN5NEG7NOGFRoMKfQ4jKv l/QgDyFnmzfVqRT5UR4ApJHzbwoLth+2R0z8EpFctepOwvLrz7nZlkfVDt54T0mg f4exAi9a0x+Qpjf6vMTcfNMu/alhcA== =sq3g -----END PGP SIGNATURE----- --Apple-Mail=_44CE5AE1-1F8C-4744-BCE2-48C4025E48B9-- From nobody Wed Apr 21 00:34:38 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD13A18A3; Wed, 21 Apr 2021 00:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AEARce7O-uKc; Wed, 21 Apr 2021 00:34:27 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5815C3A18A2; Wed, 21 Apr 2021 00:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1178; q=dns/txt; s=iport; t=1618990467; x=1620200067; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Bjm6oOYQtRrTnL2J7bIZjeqdioZPhiPiywz6iqG68Mo=; b=KCaIECgrRp0CBY9rX5qpxz60cW7XTu/Mf/uDFRYTLqRDSKJKK3e4fSNp 0908n/A0vbTOwI0kTmjYywbd9yntXyN4td4QFaKiRhvp04y/YLYxLLOyG xq36GX/Tj9CnYeSdzQsC4yFusi+skcq95Af0O+8WLOFsu6IBeZRJyJXWP I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AOAADF1H9glxbLJq1aHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gcBAQsBg3cBJxKEdIgkYIhMKJBziXmBfAQHAQEBCgMBATQEAQGEUAKBdSY0C?= =?us-ascii?q?Q4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohV2GRQECAgEjVgULC?= =?us-ascii?q?0ICAlcGgwQBgmYhp1R6gTKBAYRYhRAQgToBgVKMAkOCC4E6DBCCXz6HWTaCK?= =?us-ascii?q?wSCQAZooSWdDYMXgz+BRpgKBCGDPQGQe5BMtF2EBAIEBgUCFoFUOIFbMxoIG?= =?us-ascii?q?xVlAYI/PRIZDo44jjY/A2cCBgEJAQEDCY0PAQE?= IronPort-HdrOrdr: A9a23:4bQK6aCft+DC9MvlHeku55DYdL4zR+YMi2QD/UoZc203TuWzkc eykPMHkSLlkTp5Yh0dsP2JJaXoexLh3LFv5415B92fdSng/FClNYRzqbblqgeBJwTb+vRG3a ltN4hyYeecMXFfjcL3pDa1CMwhxt7vys+VrNzTxXtsUg1mApsIh2xEIz2WHUFsSA5NCYBRLu v42uN8uzGidX4LB/7UOlA5WYH41r/2vaOjRRYHAhI9gTP+6Q+A2frdDwWS2AsYXndpx7ovmF K19TDR1+GEr+yxzAPa2ivoy6lu3PHlytdFGaW3+68oFgk= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,238,1613433600"; d="asc'?scan'208";a="35259842" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 07:34:20 +0000 Received: from [10.61.144.102] ([10.61.144.102]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13L7YJxL004598 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 07:34:20 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AF1C5865-33FD-421E-99CC-A18E8F37CA33"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 09:34:18 +0200 In-Reply-To: <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> Cc: Brian Smith , Jim Fenton , "Salz, Rich" , "uta@ietf.org" , iotops@ietf.org To: Eliot Lear References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.102, [10.61.144.102] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 07:34:33 -0000 --Apple-Mail=_AF1C5865-33FD-421E-99CC-A18E8F37CA33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One correction: > What harm comes to any use case for there to be a non-default library = flag, as Victor mentioned there is with OpenSSL? The flag is there. I don=E2=80=99t know the default state. Eliot --Apple-Mail=_AF1C5865-33FD-421E-99CC-A18E8F37CA33 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB/1XsACgkQh7ZrRtnS ejMtDAgApOYTwPmvzo/OqtkN8AFRxP1QhS6h8AoRGcGv6qHO24MmY/xQ+6kjdV8M 4usIlI+xrTH3Asos//QnYEDUWRBhizV6kKAlVh0Mn4FVFwXx1YlJe51VdE+Qj1eh fNbn/mK03FKdb91KpQMpzQyHwusEYfETL9T7tWIH9TDTJh9NAspbwnjeO2PGjHDo dTkRQrHSZX8VwEzDfYlC1oJQb0uNsYPiNywTmHF3EowbyRqEAyI/eZ8GUavJJney bjbqESmnAa9MvGh+BeNbJMIVumkbiOnSDAtJ9ymp3iGPsbL7Mf9pF2cMiIao44R8 x/VGtNxjgazdXe2nx+4kmv3C4OaRaw== =xLwq -----END PGP SIGNATURE----- --Apple-Mail=_AF1C5865-33FD-421E-99CC-A18E8F37CA33-- From nobody Wed Apr 21 08:54:49 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322DD3A2D3A for ; Wed, 21 Apr 2021 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 L3ySR3c5482G for ; Wed, 21 Apr 2021 08:54:42 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 9FEC93A2D39 for ; Wed, 21 Apr 2021 08:54:42 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id m12so9551703pgr.9 for ; Wed, 21 Apr 2021 08:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EvmaIeVQFbtl8mSyTpPF99Wbv2nUVFElISkaHB0OzeE=; b=Ll8UgYSlzjZn7G8FwOkZobKOZgZSHG2wLxXU292d7wwqYGYstQOAXJAJOlu7OfT8iI m7gZXTbHenUFXGGc4MhlVMIVls1ZRZmbHx5IVeDIud0kfZI1+qPeN6ZKIWjHbTiY4qDj hO+b0x+LEG5pPy29Qd9n9w2ycUHkQBdmDlPKPpfP7aiuoaYqBI+889lULnIVhEDN5nuz EMjqBWRmxAI04xzo4ktp3GqRL286mRrI1labo/kAJCZOBJcJ69xHVzAheGnipaJsKTvc Tpo0bdSiqz5shEKbwDVj2tVd4C59I4d/S3B65X761qxe8kGBJ50bEU44O+cSYTOcJc2g IdAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EvmaIeVQFbtl8mSyTpPF99Wbv2nUVFElISkaHB0OzeE=; b=eIJ8FfGi3Am+5HSTk8kS76XCIc53xZnAmIAl9FaOcAUdkxXMMLF06dTgIkBPqt8ffW L0gu4sGhsWB23iXfZRisCZJGM13lXVGsRXGkuD6WHbt4iv4Qa+5rbIOppIO7cpOB0lfR tq1/GYaCfeF5YQq23nbw/b+0y+ohD7PqtjNP1E2otiIdGdszUWbnytfKuRaYgC59RDwD PLM53LipEEPzB6S+zs40Hr8IR5VPMLi/oa8jdFcmRaulmzEdM/cR8H29oFOYotHgZnxh nQJQ0Yd7hIwZKrxDosgriXR6DBy7Qxe40oZcnm5oajBZhYYlu0FjmLMNrTokOsm6a+y9 RlFg== X-Gm-Message-State: AOAM530mIebaBHMBWTbt574qxk8wrwZocU2J2WAmQgWtM0tlYWO2NABh onOD9Kj5wXcqnn98MiP49MBbtB35wj4kszG8n1wzpw== X-Google-Smtp-Source: ABdhPJwSGO6H7e8vKCEz7eSoNDRWE+iDhcAJk0rP6gvqa6uLDp4awGnCk5ao2M1R2GSG1rearYAYPW88B+ljG1DPJhk= X-Received: by 2002:a65:5089:: with SMTP id r9mr22552118pgp.38.1619020480629; Wed, 21 Apr 2021 08:54:40 -0700 (PDT) MIME-Version: 1.0 References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> In-Reply-To: <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> From: Brian Smith Date: Wed, 21 Apr 2021 08:54:28 -0700 Message-ID: To: Eliot Lear Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1e25c05c07d9480" Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 15:54:47 -0000 --000000000000a1e25c05c07d9480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > [+iotops] > > Brian, > > On 21 Apr 2021, at 00:22, Brian Smith wrote: > > Eliot Lear wrote: > >> The issue for me is library support. If libraries take the doc too >> seriously, it screws the apps that really need to do the right thing for >> their use cases. >> >> > What you're trying to prevent is the entire purpose of this, as I had > originally proposed it. The goal is to have library developers feel > comfortable removing the CN-ID support completely from their libraries. > > > Thanks for being crisp in stating your intent. > > Let's turn the question around, because perhaps I am missing something. > Bearing in mind that there are literally hundreds of millions of devices > with long-lived certificates fielded today, what advice would you give to > those who support applications that have to interact with them? What har= m > comes to any use case for there to be a non-default library flag, as Vict= or > mentioned there is with OpenSSL? > I suspect OpenSSL would continue to do what it does because it does all kinds of stuff to support legacy implementations. My interest is in developing software for the Web PKI (what browsers do, roughly) and similar new systems where CN-ID isn't useful. Note that RFC 6125 and a rewrite of it wouldn't be relevant to the legacy systems that were designed before RFC 6125, or that were designed after RFC 6125 but chose to ignore the advice in RFC 6125 and so became legacy systems before they even shipped. I would claim that there are three unacceptable outcomes: > > - Causing the app developers to write their own X.509 validation code > =E2=80=93 they=E2=80=99ll get it wrong. > - Freezing app developers on old versions of the libraries =E2=80=93 w= e want > app developers to update. > - Library developers ignoring the IETF. Let=E2=80=99s not give advice= they > simply cannot follow. > > Most developers will be able to take the advice to avoid CN-IDs. It is becoming common for libraries to ignore CN-IDs by default (e.g. Golang's library [1]) or to not support them at all (in the case of webpki [2]). > By the way, one reason many of these devices have long lived certs is tha= t > they might sit in inventory for long periods of time before they are ever > taken out of the box. There are other reasons, as well. Burned in certs > can be there as a base level anti-counterfeiting measure, for instance. > And yes, there are lots of issues with burned in anything, but there are > engineering tradeoffs to be made. > > To Jim=E2=80=99s point, maybe it would be possible to say that the flag s= hould be > unavailable for certs issued after a certain date, but that date would ha= ve > to be well into the future, and coordinated at least with IEEE. That see= ms > like a lot of work for something that, as Rich rightly alludes, is really= a > vendor decision to intelligently make. > Are those certificates using the Subject Common Name field to identify a DNS name or an IP address, without having the subjectAltName populated? If not, then this proposal wouldn't affect them. This isn't saying "You must have a subjectAltName no matter what;" it's saying "You must have a subjectAltName using dNSName (iPAddress) to identify a subject by DNS name (IP address)." To your point that we should have a 10 year deprecation period: RFC 6125 was published just over 10 years ago, and already discouraged using the subject common name for DNS names and IP addresses. So I think we've already lived through the 10 year deprecation period. [1] https://golang.org/doc/go1.15#commonname [2] https://github.com/briansmith/webpki Cheers, Brian --=20 https://briansmith.org/ --000000000000a1e25c05c07d9480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot Lear <lear@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
[+iotops]

Brian,

On 21 Apr 2021, at 00:22, Brian Smith <brian@briansmith.org= > wrote:

Eliot Lear <= lear=3D40ci= sco.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
The issue for me is library support.=C2=A0 If libra= ries take the doc too seriously, it screws the apps that really need to do = the right thing for their use cases.

What you're trying to prevent= is the entire purpose of this, as I had originally proposed it. The goal i= s to have library developers feel comfortable removing the CN-ID support co= mpletely from their libraries.

Thanks for being crisp in stating your intent.

<= div>Let's turn the question around, because perhaps I am missing someth= ing.=C2=A0 Bearing in mind that there are literally hundreds of millions of= devices with long-lived certificates fielded today, what advice would you = give to those who support applications that have to interact with them?=C2= =A0 What harm comes to any use case for there to be a non-default library f= lag, as Victor mentioned there is with OpenSSL?

I suspect OpenSSL would continue to do what it does becaus= e it does all kinds of stuff to support legacy implementations.
<= br>
My interest is in developing software for the Web PKI (what b= rowsers do, roughly) and similar new systems where CN-ID isn't useful. = Note that RFC 6125 and a rewrite of it wouldn't be relevant to the lega= cy systems that were designed before RFC 6125, or that were designed after = RFC 6125 but chose to ignore the advice in RFC 6125 and so became legacy sy= stems before they even shipped.

I= would claim that there are three unacceptable outcomes:
    =
  • Causing the app developers to write their own X.509 validation code =E2= =80=93 they=E2=80=99ll get it wrong.
  • Freezing app developers on old= versions of the libraries =E2=80=93 we want app developers to update.
    • =
  • Library developers ignoring the IETF.=C2=A0 Let=E2=80=99s not give advi= ce they simply cannot follow.
Most d= evelopers will be able to take the advice to avoid CN-IDs. It is becoming c= ommon for libraries to ignore CN-IDs by default (e.g. Golang's library = [1]) or to not support them at all (in the case of webpki [2]).
= =C2=A0
By the way, one reason many of these devi= ces have long lived certs is that they might sit in inventory for long peri= ods of time before they are ever taken out of the box.=C2=A0 There are othe= r reasons, as well.=C2=A0 Burned in certs can be there as a base level anti= -counterfeiting measure, for instance.=C2=A0 And yes, there are lots of iss= ues with burned in anything, but there are engineering tradeoffs to be made= .

To Jim=E2=80=99s point, maybe it would be po= ssible to say that the flag should be unavailable for certs issued after a = certain date, but that date would have to be well into the future, and coor= dinated at least with IEEE.=C2=A0 That seems like a lot of work for somethi= ng that, as Rich rightly alludes, is really a vendor decision to intelligen= tly make.

Are those certifi= cates using the Subject Common Name field to identify a DNS name or an IP a= ddress, without having the subjectAltName populated? If not, then this prop= osal wouldn't affect them. This isn't saying "You must have a = subjectAltName no matter what;" it's saying "You must have a = subjectAltName using dNSName (iPAddress) to identify a subject by DNS name = (IP address)."

To your point that we should h= ave a 10 year deprecation period: RFC 6125 was published just over 10 years= ago, and already discouraged using the subject common name for DNS names a= nd IP addresses. So I think we've already lived through the 10 year=20 deprecation period.
=C2=A0
[1]=C2=A0https://golang.org/doc/go1.15#commonname

Cheers,
= Brian
--
--000000000000a1e25c05c07d9480-- From nobody Wed Apr 21 09:51:29 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1C93A2BB2; Wed, 21 Apr 2021 09:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.899 X-Spam-Level: X-Spam-Status: No, score=-11.899 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, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gDcZSP-IlkYi; Wed, 21 Apr 2021 09:51:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548243A2EF9; Wed, 21 Apr 2021 09:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1099; q=dns/txt; s=iport; t=1619023882; x=1620233482; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=CzlahQrfqhIcltZaO+nTVrM8YAs4x1B9DisBHIMy7Y4=; b=DEBDfGyQlNVNupO9ZPT+AbBo/3E5NcPLxOTJ2kRIuBhXfzIgDRF9ILKb 4tKvbDlbKQYM2JDtu1WdNpqm82RnD7hDoo2lXLf6rEOeIYJbQ4ycMSW9J gki9OZI++5G+ocZD0OeML8ST4KC21FORyNXLyQnqlrbYN2gsSXHgB8WSg Q=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AOAACiV4BglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gcBAQsBg3cBJxKEdIgkYJlsiXmBfAQHAQEBCgMBATQEAQGEUAKBdiY0CQ4CA?= =?us-ascii?q?wEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohV2GRQYjVhALQgICVwaDB?= =?us-ascii?q?AGDB6hDeoEygQGEWIUTEIE6AYFSjARDgguBOhyCXz6HWTaCKwSCRmihKZ0Ng?= =?us-ascii?q?xeDP4FGmA0EIYM+AZB8kE20XoQEAgQGBQIWgVQ4gVszGggbFWUBgj89EhkOj?= =?us-ascii?q?jiONj8DZwIGAQkBAQMJjQ8BAQ?= IronPort-HdrOrdr: A9a23:CRwqcquVKAECb/N9UUu208KQ7skD9NV00zAX/kB9WHVpW+aT/v re/8gz/xnylToXRTUcicmNUZPtfVrw/YN4iLNxAZ6MRw/j0VHDEKhD6s/YzyTkC2nC8IdmtZ tIV6RlEtX/ARxbgK/BjTWQN9YlzJ25/LuzheHYpk0DcShQZ6tt7xh0B2+geyUceCB8CZU0D5 aa7MZczgDQHEg/VNixBXUOQoH4yeHjqZSOW29lOzcXrC2HjTal89fBYnyl9yZbdS9TyrE/9m WAtAr16syYwpeG4y6Z8XPP5JJLn9ak8P9/PYinj8gYLSiEsHfOWLhc X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,240,1613433600"; d="asc'?scan'208";a="35276225" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 16:50:58 +0000 Received: from [10.61.144.117] ([10.61.144.117]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13LGov8V003625 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 16:50:57 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_97773005-FF72-4B8B-ADE2-5B43C895FC49"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 18:50:56 +0200 In-Reply-To: Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org To: Brian Smith References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.117, [10.61.144.117] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 16:51:27 -0000 --Apple-Mail=_97773005-FF72-4B8B-ADE2-5B43C895FC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, If this is scoped to dnsNames then I=E2=80=99m fine with it going = forward as is. Other names would be problematic. Eliot --Apple-Mail=_97773005-FF72-4B8B-ADE2-5B43C895FC49 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCAV/AACgkQh7ZrRtnS ejPA1Af/RYjLLsjVxc/5ccW5zJKn/n0PyzinmD6n8TPWRj+B/JlPrG80m+Qr5O8b 3Gi5LmsAXvr0MGqnaWaex1rwC5T7U0PwH7Rds670bu3uQv669YK2J+C0N+dSF28y PikiUDMU+D10/0ucXEaXDOvUq8SIetKF+MgT9tW5CMv7YcP/rLsPKYtQEQqCp5H1 e2QM42KgHoh2HLYiA+nLg69GNSXjal0ZCW8ef3kA7WxKS31Fc/CyZFu7wkWfZHWS QoPAox3nrIicAJezBZByoR+MT1pfP4yHE/ldv71p5HR7Y3AUgGEAfebvKuL2Kiui l9xQwZeUaXMG06jtwGCSQ514AuPR4g== =+lO5 -----END PGP SIGNATURE----- --Apple-Mail=_97773005-FF72-4B8B-ADE2-5B43C895FC49-- From nobody Wed Apr 21 11:26:10 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD33A322E for ; Wed, 21 Apr 2021 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 v4hZ6CVvqHg8 for ; Wed, 21 Apr 2021 11:26:02 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 3A4703A322F for ; Wed, 21 Apr 2021 11:25:59 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id c17so29681222pfn.6 for ; Wed, 21 Apr 2021 11:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KGHm05uqTMBSvO5fjmKyPppucc8I7pjt5tQKnTI+6JQ=; b=GfvjFvZTzlGdcVI0d4gXq+YBAAKh35mZVNFvLNeUcEqK2quOP9WDjvjqwEeb2BRXLA 4RVMNpaHrzGLO/JEyodhfdpaCClgzQrFfVoFQUrGYYLz5Bdmy0dIpbdJWPUlqZWZlnc6 ehTguj1+Pdk9zZev0rfHkCwhewvrsYFMyHrd7rUL3i7cgCqoPwrVDuAlnjlUOwqrGA4J XeSBSlELJNkSwFyYp7DAq0jZXn2xOME/ne7RDQ6DiXfKfWsmBNrLtzobcUPq9M0VHgPT /oUxwDelZZLyGs7rV35IEiRUh+AjeP6JabgN3q7CslQ7jgbxfogORnlAYS3IHGoRARM9 CqYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KGHm05uqTMBSvO5fjmKyPppucc8I7pjt5tQKnTI+6JQ=; b=KRrFWT4nsOZ0zRa3T2Ye9FyQCmsjyVtGqmqXXvCpdLjmEVeZxF+LfS5YNZvOHowO99 mkFb1WAhe2lAQW2ktjoZ0pXF8awYZVoPcu9xMcJukKV6QQAjF1H3sfCWo0/P70oQn3sd hPF+T6qJNasx4/jqTn9JvOSXDtiPAhbb6Fh1VWkccFhZxCPxsOjLJ3jZvmsCQ1MGs35H zCZ/HP9C/dpVX5pXPDC2bX7nzYJRFPR4T1YwPAubzpu6/fpV5wRV7bqUBFRBwRXJfRhv 4G3CGgsRsO8A3g/etdTlm64n8AWbWcln0ahlEcnpTNlbHDsIIX6vI3tHM7rmYjKIsABc 34KA== X-Gm-Message-State: AOAM530f3elXVqpCHePCWt+hHanDcgxSAFX7Fun/vWRylzgx5l8El2Uv NpZFMJNUt5h5dJNhO2b0xv+WmDD6CxSPAr9P/k8UtA== X-Google-Smtp-Source: ABdhPJxLcLcFppE+KDSJUY1hrSQoi5Gc0Ebgcta4mKKLdN50UlMZejIlBdqE37xMdmdSrfzLniAgjPa9D7OJTDOFz2I= X-Received: by 2002:a62:8c8c:0:b029:253:31e:55cb with SMTP id m134-20020a628c8c0000b0290253031e55cbmr30649044pfd.27.1619029557173; Wed, 21 Apr 2021 11:25:57 -0700 (PDT) MIME-Version: 1.0 References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> In-Reply-To: From: Brian Smith Date: Wed, 21 Apr 2021 11:25:45 -0700 Message-ID: To: Eliot Lear Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000a2f1c805c07fb1c4" Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 18:26:08 -0000 --000000000000a2f1c805c07fb1c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > If this is scoped to dnsNames then I=E2=80=99m fine with it going forward= as is. > Other names would be problematic. > Could you be more specific as to what other names would be problematic and list them explicitly? Here are the choices in a GeneralName: otherName [0] OtherName, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID Thanks, Brian --000000000000a2f1c805c07fb1c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot Lear <lear@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">If this is scoped to dnsNa= mes then I=E2=80=99m fine with it going forward as is.=C2=A0 Other names wo= uld be problematic.

Could you be more s= pecific as to what other names would be problematic and list them explicitl= y? Here are the choices in a GeneralName:

        otherName              =
         [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID

Thanks,
Bri= an
--000000000000a2f1c805c07fb1c4-- From nobody Wed Apr 21 11:48:42 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED683A32B4; Wed, 21 Apr 2021 11:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.898 X-Spam-Level: X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4MMa6iSkq22A; Wed, 21 Apr 2021 11:48:36 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9755F3A32B3; Wed, 21 Apr 2021 11:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4816; q=dns/txt; s=iport; t=1619030915; x=1620240515; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=KxHvqm+DFL8JqJDJosoFeY8mj4A6j/jLYWVzTzWcvK4=; b=MYbah1Ddf6YT35s0dz9fIyXFyUA+nF8uJLS03G30MvYsz2vFVjbPvdTb qA1WuLPXRJ3ZQ1oDtXtatu+yCvgxxdVPfXGdsaylijqJMaDdYScPf7mKD JusKagS4x+h0Y9wDL6hbKnIgslBiM1ul6ggaiGxa1Sttrft6OFQ3WilcU w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ABAABdcoBglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGBfwMBAQEBAQsBgSKCVQEnEjGEQ4kEiFAoh36MTYYkg?= =?us-ascii?q?XwEBwEBAQoDAQE0BAEBhFACgXYmNQgOAgMBAQEDAgMBAQEBAQUBAQECAQYEF?= =?us-ascii?q?AEBAQEBAQEBaIVdhkQBAQEDASNWBQsLBBQnAwICRhEGE4JxAYJmIahAeoEyg?= =?us-ascii?q?QGEWIUYEIE6AYFShS8BhlRDgguBOgwQgl8+h1k2gisEgkZoc58NgSmdDYMXg?= =?us-ascii?q?z+BRpgNBCGUO5BNtF6EBAIEBgUCFoFWAzOBWzMaCBsVOyoBgj4+EhkOjjiON?= =?us-ascii?q?j8DLzgCBgEJAQEDCY0PAQE?= IronPort-HdrOrdr: A9a23:2T9Rdq0Rfe+eTUhhe4n54gqjBDAkLtp033Aq2lEZdDV+eKWj5q OTtd4c0gL5jytUZWE4lbm7VJWobHvA+fdOgLU5EqylWGDd0leADIYn1of6xi2lJiuWzI5g/I NtabJ3BtG1LVUSt6vHyS25F9pl/9Wd6qCvgo7loEtFdg1hZ6F+4woRMG/yeXFefwVICYE0E5 CR/KN81l+dUE4KZce2DGRtZYb+juDM/aiWAyIuNloC4AmKgSjA0s+fLzGomjEDTjhI3bAutU /CngCR3NTEj9iLjjnBymTU85Na3OHE9+IGLsmNhs8JQw+c7TqVWA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,240,1613433600"; d="asc'?scan'208,217";a="35277593" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 18:48:33 +0000 Received: from [10.61.144.117] ([10.61.144.117]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13LImWA4029485 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 18:48:33 GMT From: Eliot Lear Message-Id: <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D9E4FAAE-F5BC-4039-8D10-EE207873C1A6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 20:48:31 +0200 In-Reply-To: Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org To: Brian Smith References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.117, [10.61.144.117] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 18:48:41 -0000 --Apple-Mail=_D9E4FAAE-F5BC-4039-8D10-EE207873C1A6 Content-Type: multipart/alternative; boundary="Apple-Mail=_13F5E770-0EBC-495D-84CB-168353E23224" --Apple-Mail=_13F5E770-0EBC-495D-84CB-168353E23224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Apr 2021, at 20:25, Brian Smith wrote: >=20 > Eliot Lear > wrote: > If this is scoped to dnsNames then I=E2=80=99m fine with it going = forward as is. Other names would be problematic. >=20 > Could you be more specific as to what other names would be problematic = and list them explicitly? Here are the choices in a GeneralName: >=20 > otherName [0] OtherName, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID >=20 The principle here is long-lived names. I can=E2=80=99t imagine [2] and = [7] being at issue. [1] and [4] are definitely in use in long-lived = environment. I don=E2=80=99t know about the rest. --Apple-Mail=_13F5E770-0EBC-495D-84CB-168353E23224 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 21 Apr 2021, at 20:25, Brian Smith <brian@briansmith.org> wrote:

Eliot = Lear <lear@cisco.com> wrote:
If this is scoped to dnsNames then = I=E2=80=99m fine with it going forward as is.  Other names would be = problematic.

Could you be more specific as to what = other names would be problematic and list them explicitly? Here are the = choices in a GeneralName:

        =
otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID



The principle here is = long-lived names.  I can=E2=80=99t imagine [2] and [7] being at = issue. [1] and [4] are definitely in use in long-lived environment. =  I don=E2=80=99t know about the rest.

= --Apple-Mail=_13F5E770-0EBC-495D-84CB-168353E23224-- --Apple-Mail=_D9E4FAAE-F5BC-4039-8D10-EE207873C1A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCAc38ACgkQh7ZrRtnS ejOJ+QgAzcEZOW3WzSEGjuUKZ2Q+85NeU4N6XWuzKd3jmYKvN4SC29OSdA1K1pJ1 aBYV3PbH7T3uCBxujrktKoSxFqbskcBTKpF+i9ZJd9qUrW6VoYKpyRLTZxfcY9xG HfAACt6gss4yxWgI6hdqF6vz8aKmFHRxy9TdZU0vi9qs5UmbdCaZ8EGmr/r0hq7Z FHPN4FNLmtbdPBt1vSv+1fczf0m+8Tiekjy8pBMTf0yjPmXbuIJlBSNLfv8ziGxy pddvJE5cVB80H6kpAxp4uWqDotKzbzmLhq08v0vxnUeAX+fbTLC+rid+tSUi1sFb ovf3fHoXalkg8ZTVWpmEGxtF0KpJ5Q== =vwJQ -----END PGP SIGNATURE----- --Apple-Mail=_D9E4FAAE-F5BC-4039-8D10-EE207873C1A6-- From nobody Wed Apr 21 13:31:37 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884B53A35A3 for ; Wed, 21 Apr 2021 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 zU5DvoPTUpuQ for ; Wed, 21 Apr 2021 13:31:27 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 30A8F3A15C2 for ; Wed, 21 Apr 2021 13:31:27 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id a12so29984459pfc.7 for ; Wed, 21 Apr 2021 13:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zc7J+V7ezzkeN86IBsiLov1+PkBmIjdYaw3fuHBwl9E=; b=H9cwx+lvd6ca7Ev27DInrbuUkGLLSBdTEB32NWZODKkkipLb5vzThD1JUeY/tpuLHR ccebDyN3U1erN5PmmM/5y8kOpAiOxul9EfScgTYiZBNf26k4b9Xao1YsTv9NlVjaq+W0 h4L9CcZ710az+RrL2yrwImohJgFDI1bcB61dIleaLWoIMHfd0bc57qcyhKGrK1YzikPB J8ZGLs0MM6YuBrNJm8laGpoJ68SiK9r0EK7BKdB1VE/CKibU7s1hZjcaHssb2WgWBnyl kHkCT0Nw9VrOwUj5pAoWAoOAEHILN9hB3yx27b1tKHbitNrnEGehNHcFBY5oQoCXw/P9 +plg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zc7J+V7ezzkeN86IBsiLov1+PkBmIjdYaw3fuHBwl9E=; b=Scm9IJL41+M1ozJEt8//zQr4jTDwPiDjiNd+vxFFSohn7ZuTMdD9E/SuR3cSCwt3IZ 8fx25qpjd/EdkCrPLF6zCVphzbSUrwcNaokjiW1neCL1PkZiymc6g7zsrFB68COv3Dfl +rFbcmrb8Xw41OHhOLIY1juzdOaPFjaPZAvOnLUz+TYkRb9s6zsygxt66o8K3l3jBHLY lR2zIL9YsLn9tBnMSsw5nDqT9MnRszn+PVe2sppJBeA6MXGX9Vkg1RxJAl+aSfgHdfhR lWED6FG6kq5wNbWeVH78WZFWyf7Ox6xcgZb3SaGmMIwayFoMgJUrwr5zIdfTNnk9EU8T ReGg== X-Gm-Message-State: AOAM533cPDWh9kJUi2azzxMd/KH5QLxXxKgor4sD+UfSRWwkGkBLylvs kpZUMzw4DXwC4mK0ycmgu2A0P8jmw5djI2ba2xdZaQ== X-Google-Smtp-Source: ABdhPJy6BZ+l/PP2clS0uMLGd/63jtsCwFScQNEh0VJ03dTG5e3BPfv9+aO49GY3ru5Mrqri36nfixnmkne4HFDbI5c= X-Received: by 2002:a17:90b:120b:: with SMTP id gl11mr13276112pjb.143.1619037085862; Wed, 21 Apr 2021 13:31:25 -0700 (PDT) MIME-Version: 1.0 References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> In-Reply-To: <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> From: Brian Smith Date: Wed, 21 Apr 2021 13:31:13 -0700 Message-ID: To: Eliot Lear Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000619d0605c0817241" Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 20:31:33 -0000 --000000000000619d0605c0817241 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > On 21 Apr 2021, at 20:25, Brian Smith wrote: > > otherName [0] OtherName, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID > > The principle here is long-lived names. I can=E2=80=99t imagine [2] and = [7] being > at issue. [1] and [4] are definitely in use in long-lived environment. I > don=E2=80=99t know about the rest. > OK, [2] is dNSName, and [7] is iPAddress. Those are the primary two types of identifiers that I'm targeting: I want the spec to say that certificate verifiers must not look for IP addresses or DNS names in the Common Name sub-field of the Subject field of a certificate. Regarding [4] directoryName, I don't think anybody is encoding an entire directoryName into the Common Name field of the subject field, so that's a non-issue. Regarding [1] rfc822Name, are you saying that you are worried about certificates with a subject like : CN=3D"foo@example.com" without an accompanying subjectAltName rfc822Name=3D"foo@example.com"? If so, is your concern about using these certificates in email applications? I would love for us to get to the point where we say email applications also must use only email addresses (rfc822Names) in the subjectAltName extension and not look in the CN of the subject field. For non-email applications, aren't they just using the subject field as a directoryName that's somewhat incomplete? Regardless, non-email address uses of CN=3Dfoo@example.com woul= d be (or could be made) out of scope of the revised spec. Cheers, Brian --=20 https://briansmith.org/ --000000000000619d0605c0817241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot Lear <lear@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On 21 Apr 2021, at 20:2= 5, Brian Smith <brian@briansmith.org> wrote:
        otherName                       [0=
]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID
The principle here is long-lived names.=C2=A0 I can=E2=80=99t imagine [2] = and [7] being at issue. [1] and [4] are definitely in use in long-lived env= ironment.=C2=A0 I don=E2=80=99t know about the rest.

OK, [2] is dNSName, and [7] is iPAddress. Those are t= he primary two types of identifiers that I'm targeting: I want the spec= to say that certificate verifiers must not look for IP addresses or DNS na= mes in the Common Name sub-field of the Subject field of a certificate.

Regarding [4] directoryName, I don't think anybod= y is encoding an entire directoryName into the Common Name field of the sub= ject field, so that's a non-issue.

Regarding [= 1] rfc822Name, are you saying that you are worried about certificates with = a subject like : CN=3D"foo@example.= com" without an accompanying subjectAltName rfc822Name=3D"foo@example.com"? If so, is your c= oncern about using these certificates in email applications? I would love f= or us to get to the point where we say email applications also must use onl= y email addresses (rfc822Names) in the subjectAltName extension and not loo= k in the CN of the subject field. For non-email applications, aren't th= ey just using the subject field as a directoryName that's somewhat inco= mplete? Regardless, non-email address uses of CN=3Dfoo@example.com would be (or could be made) out of scope of = the revised spec.

Cheers,
Brian=
--
--000000000000619d0605c0817241-- From nobody Wed Apr 21 16:20:09 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D303C3A3AE0; Wed, 21 Apr 2021 16:20:02 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.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 cKuKGT-FwXaw; Wed, 21 Apr 2021 16:19:58 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 9C2503A3ADF; Wed, 21 Apr 2021 16:19:57 -0700 (PDT) IronPort-SDR: HZmrIYRVUhYZ6kErcd8f99pDltj8PTU440MK9QbMleQRCutwnaMTuH3a3PomrAg/N8HKisWUnr iUxW1XGGeI7A== X-IronPort-AV: E=McAfee;i="6200,9189,9961"; a="192608540" X-IronPort-AV: E=Sophos;i="5.82,241,1613462400"; d="scan'208,217";a="192608540" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2021 16:19:56 -0700 IronPort-SDR: ZvqFwMIkxKI2CvUP85g3gbAzpS1qpSWHgMN/A1R6DPkfitp87wPJUQ5ovcseGtmM1wtJW4S7/L QuDqubCcDk7w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,241,1613462400"; d="scan'208,217";a="455543460" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga002.fm.intel.com with ESMTP; 21 Apr 2021 16:19:55 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 21 Apr 2021 16:19:55 -0700 Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 21 Apr 2021 16:19:54 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Wed, 21 Apr 2021 16:19:54 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.58) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 21 Apr 2021 16:19:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUrI2LJyyTyQtAPcLMIc50NGnccok4G8AvMMYGmTpvV+/cy7kf6Ds3krFsBpLrcf0OfkDPXFabRdTlZsNpoQx5bTdPiUBVydmJWHPwzRHRaUYCyBri4hiCYHri7N/utmtspb6a+XEIPQsE+3G5TJKGn9mD3FY7SDpUp33TXVRTCxRB05fcvkmdPBHgUD3Pqx/Q0rX06hkQq/KSLCPPi0BfQafxSbtNGueBhfcfnHDyovoCAfYOX/ENEaFNLE/+FncF93SpQpDH7/dSzU00bOmV3Bm3XnkcVxeeCFI10sxJFfZPz/0Vj08xkBQvYALP/lGCsVx17NogdxpdFdMDVZyw== 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=1K853MsLQiPv5zGJxIs/3OAGfmADGwcC6ycWjzQPEKg=; b=WkVP481hjguDsWv2ZdX4RGZmICuaFVXrSBwTD3ZsqxCEvXmA88ZO28mGL5BWZFhilrtas+eKUtigKukw57i6VLE/ZXRhXqWzLQ7R0ycww2iL3Evgy3wvu1r+Kw4NVgPCHpQwQUphRQlEnei+mpIG8TurRvLts8hygb0DQWwNUUcmd+tnZCXFyhl3wIANnEEXaRdL5tCTksOoBlxUZbn+7lOdX3ueAIogpBTdCbQDfx11ur5ESleKWnpDEJHHieT6LAsUfirQaX4u6Ux1cpQUmYGRRuPShCnXhyrg4h9Q5EDSClr4bxT0KASqj1K/MKcydIP7/f8HIvqm7CqV8cDx2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1K853MsLQiPv5zGJxIs/3OAGfmADGwcC6ycWjzQPEKg=; b=Hs3L4XmED12+mymC7krf/dyfGTvCck9YxbpNWo2M51A2LdjoLWFK2gjVA4ZamoShONOddmipO6RJPbCatyOspyu+TSKWw9RrQHeWUDCUquC7pzZQ71przLV2ogi7RhkL8xHCOwKf1pMoXvQc8T/enYC9lSybmJpWDYXiMdQUUeI= Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by MW3PR11MB4556.namprd11.prod.outlook.com (2603:10b6:303:5b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Wed, 21 Apr 2021 23:19:53 +0000 Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2%6]) with mapi id 15.20.4065.022; Wed, 21 Apr 2021 23:19:53 +0000 From: "Smith, Ned" To: Russ Housley , Eliot Lear CC: Guy Fedorkow , Henk Birkholz , "iotops@ietf.org" , "rats@ietf.org" , Laurence Lundblade , Ira McDonald Thread-Topic: [Rats] 802.1AR device identity Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOAgACzxwCAAAOuAIAXhE8AgArnz9CAGPKigIAAPVGAgASjCAA= Date: Wed, 21 Apr 2021 23:19:53 +0000 Message-ID: <2118D1F3-849F-4238-A2AE-054FF67144FF@intel.com> References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com> In-Reply-To: <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [50.53.43.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1faa6252-6cef-4ff6-76ba-08d9051bf815 x-ms-traffictypediagnostic: MW3PR11MB4556: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3b9XhcLiqyR9M59IrJI8tpbF1eCrpN7+P31bcMWpaTLV1dUhk0U1ZNLlzKx5VnlDydqL8+FVLNpcD4cZ69jLNvFAmZJ1AGT+r5oK51fu7fZMHkG9NrIGEBvqg/Zji592TBmN4ddCHxJbbLsYCNxfB4t9T9BjjsDJ72sUROyahUVxSgZRdSL4DAk+lC+yR1GE/Pi5zC6G517e+8n4xW5UwMyD/8GfxdJlT64TRWLwh4l6e7qYrSg8mQdPp4cr41Q0wz62pFZXFV75a1HNl99jsYT70acX3Dg8E5adhN1XemXhDsNRsloKWjEU6joCnmOWGHwnqE+XoENTH5cA+QDSjvQ9BEoUesIGyPUK7LN2AZjCHaZIw+PK1tOXxscUIR0MpfIO3Co95LNTvn//WkHF1hO5fJakbno8com7SovzKQ9qLfWiHH3cOCPq+WH8PwywNudNQxJ3ToNTInc+nOQFh+i7ibvBNbpX1q57f7D1iDue+oKIh44pr2uQvlIR6t0cXjFSWcZxxjpFr+WI84hAk3gCP5t3666iU0wXxXvJ3aqF6WeajS2Tlzo1mjpFd0f9oR/WF6JJkRZUwFX+UuFAPr8J/1287W8w3D2fkZ5YHUEb3EoXso061BxilhxtTZ0NQrs1CT6eTjA+ibjU0qpFIvSo6O/ANesMHoX9Jw7ctM4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(39860400002)(136003)(396003)(346002)(122000001)(33656002)(83380400001)(66946007)(8936002)(91956017)(26005)(54906003)(66476007)(5660300002)(86362001)(110136005)(38100700002)(6486002)(186003)(53546011)(8676002)(66556008)(2906002)(2616005)(71200400001)(64756008)(316002)(478600001)(6512007)(6506007)(36756003)(66446008)(4326008)(76116006)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?R2F1MjRSeU1Yb1l1YlVmbnpOenNLUmxmRnlCQ3R6VXJLZVNnU3RPazU4aEJT?= =?utf-8?B?eUNiR0czYWdWYmNVSkt1M20rS1pjVW5SWnc5K1grSG1HRW1MdU1IVjlpQWdw?= =?utf-8?B?SHRKa0RpVVBMakdndDNUNCtsRlVFR1l2aUxyemlXbUNReXJoV0F0S3lsZnBK?= =?utf-8?B?Qnlha0dHSXNzQzNhQmdwUDJKTVhvR1dMY0xUMmx0N1h2aEV5RjcwOWF0bzN1?= =?utf-8?B?U1ZZaTVWZ21TQ2E4bXkzWnlNWDIza3pIRlYzN09YTExPSnFJakp6aTk5T3VU?= =?utf-8?B?d2g1ckQxRWdBNXRoWHBmb21MOEtZODkyL3pSTnFNRWpDL3FFWGlHd0pYZ1hL?= =?utf-8?B?R1U0TkplR3kvVnBDRFAxeTY2L3hHNGNlRk45QjE2MzlzQnVWRTAvZ0hjblhm?= =?utf-8?B?UFBzM0ZGdVAxWTdubS96UFdtZngvYy95b2dVazV3Z1A2ZzdJcXc4cFhQcnFW?= =?utf-8?B?YmlUNWo2UUEycEdELzZ6bVJma2tvdTVHYjhNbjNpTjdmRlowS3pVdUtxczNi?= =?utf-8?B?QVErWlZCVUE1eVgwZmVnZ1I4cUVFSTJPNHcrNXlSRUxOTUlSanc2aWtIYXRC?= =?utf-8?B?NjZwcUJ2L2h0ZEFUNDQ4ajBQcXZFV3NoRWNjWjZCbU5KYXQ3aW4yb1ljQTZw?= =?utf-8?B?ZXBPQkZKSFVQUFYralZxTzd1Y2JCQmlZeStWY0lVRW52N0VVRzNFOTNLRERP?= =?utf-8?B?cDNxWlQwclpJZE03Wm5Od0dzTThJczFtSFY2RjRXVmE1RTNESVFCVjNuMzA0?= =?utf-8?B?djRwL2w4cXFQN0o1UkxUakMvditpUlFIcFlPcXFrdTdSc0xiOEdXNmdjU2xL?= =?utf-8?B?cXpVNlZNYUUrOW9BalFwRS9QT2tqNkttQ1QrR3ovU1krRjhLcVY0c3drSUlD?= =?utf-8?B?dzlOeW9MeUZzOFZFa1Q0Q3NWTWpWcjJSSGtVdWlYZVYxejAwV01BQTZvbjA5?= =?utf-8?B?NDF6SVU5TnJucXFtS08rTTNiOXNQN1JQT3hhRExXNk1TSUErbi82RHVSRnQ3?= =?utf-8?B?MnBiQVRvdDFxeXFTU21hdDAwMnpvMjZEdlVpZGllSDdKd3NhYzdNbk5uNzFO?= =?utf-8?B?R2dKeHp0SDBlcXpjOHZaVWpINU1qVmp3aVd5OU4vQ0pialhEMnQxSWVDcW9T?= =?utf-8?B?MXFFWmVHMW9KdTZzS0NGdm51UGlMTjVTeUcvN0M0VTZEMTN2Z1hoYndVMFp1?= =?utf-8?B?SU4zRUdUWjV3WkJST1JOcjVlbWhKcXNBb1QyQWJyZVRFTVRhYmtvWHRPUUZM?= =?utf-8?B?UHlybVVUL1c0c29OcUIvQlErSWx4TU05SkdNTkJnanZISmxmSmJ2QUVEWGox?= =?utf-8?B?VWFJakNneFZ0MUVpb2phdUwrTXZFdThuK2h6YkdkeEVxeit2NlQ2SzQyOHFI?= =?utf-8?B?VkQ4cU56YldVVzY5NUJ1VEtpeHQySG80d3FoYjJGa2FKcmp5NVNoZmI4MHhP?= =?utf-8?B?c2VjU29vNDc2MW9TcStqV2hTUUZKNE9zdDlnK1FpVmJQdnRFK3N5ejNON2NQ?= =?utf-8?B?Z01GSlArNzFBSmFkU05idDNUSHo1UGswNkZQeDlvWGVLS2V5UktBcHE0eXRp?= =?utf-8?B?UGR2aFZwelYyZzZvQWlUR2RTUzA1Nm1zVXBVcmttdFQzRjFmcUhzODRpVmhD?= =?utf-8?B?eTE2REdrVU9OZUZNeU5qc2lpK0JNaFBhRmNzRFJYeGdBRFBMSk03cnlGMk0x?= =?utf-8?B?SE0ySnFLc0RBMzlDeHBhK3lrQUYxOSs5cEZvL3NGNEl6ZnNDQ29qd2ZyUmc2?= =?utf-8?Q?Qaozg0A9axzR6BOhiU2hv6K4XjL7QydX8R8Y0kn?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_2118D1F3849F4238A2AE054FF67144FFintelcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1faa6252-6cef-4ff6-76ba-08d9051bf815 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 23:19:53.2504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FZAigPEiqCe2okoZzENI9uxbgIQ0rNWDJB95KFfy8vNjqZTLdlOoOdGE9JPzT0kNmiI0tbtuG4VZWOimgN4V2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4556 X-OriginatorOrg: intel.com Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 23:20:03 -0000 --_000_2118D1F3849F4238A2AE054FF67144FFintelcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgcmVhc29uYWJsZSwgaW4gdGhlIGNvbnRleHQgb2Ygb25ib2FyZGluZywgd2hlcmUgdGhl IG93bmVyIGlzbuKAmXQgYSBzdXBwbHkgY2hhaW4gZW50aXR5LCBidXQgdGhlIG5ldHdvcmsgb3du ZXIgd2hvIGlzIGdvaW5nIHRvIGRlcGxveSAvIG1hbmFnZSB0aGUgZGV2aWNlLiBPbmJvYXJkaW5n IG1pZ2h0IGludm9sdmUgc2VwYXJhdGVseSBldmFsdWF0aW5nIHRoZSBzdXBwbHkgY2hhaW4gcmlz ayBhbmQgYW55IOKAmG93bmVy4oCZIHRoYXQgbWlnaHQgYmUgYSBzdXBwbGllciBmcm9tIG9uYm9h cmRpbmcgcHJvY2Vzc2VzIHRoYXQgdGFrZSBhIGNsZWFuIHJvb20gYXBwcm9hY2ggdGhhdCB3aXBl IGNsZWFuIC8gcmVzZXQgdG8gbWZnIGRlZmF1bHRzLg0KDQpBbiBtZmcgSURldklEIGRlc2lnbiBt aWdodCBiZSBzdWNoIHRoYXQgdGFtcGVyaW5nIGJ5IHN1cHBseSBjaGFpbiDigJhvd25lcnPigJkg d291bGQgYmUgZGV0ZWN0ZWQgYW5kIGhlbmNlIHRydXN0aW5nIHRoZW0gaXNu4oCZdCByZWFsbHkg bmVjZXNzYXJ5LiBUaGUgZW5kIHVzZXIgLyBjdXN0b21lciBhcyDigJhvd25lcuKAmSBtaWdodCBv bmx5IGNhcmUgYWJvdXQgdHJ1c3RpbmcgdGhlIElEZXZJRCBtZmcgb3Igb25seSB0cnVzdGluZyBo aW0vaGVyIHNlbGYuDQoNCkZyb206IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+ DQpEYXRlOiBTdW5kYXksIEFwcmlsIDE4LCAyMDIxIGF0IDEwOjMxIEFNDQpUbzogRWxpb3QgTGVh ciA8bGVhcj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBHdXkgRmVkb3Jrb3cgPGdm ZWRvcmtvd0BqdW5pcGVyLm5ldD4sICJTbWl0aCwgTmVkIiA8bmVkLnNtaXRoQGludGVsLmNvbT4s IEhlbmsgQmVya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+LCAiaW90b3Bz QGlldGYub3JnIiA8aW90b3BzQGlldGYub3JnPiwgInJhdHNAaWV0Zi5vcmciIDxyYXRzQGlldGYu b3JnPiwgTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJlc29ydC5jb20+LCBJcmEgTWNE b25hbGQgPGJsdWVyb29mbXVzaWNAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFtSYXRzXSA4MDIu MUFSIGRldmljZSBpZGVudGl0eQ0KDQoNCg0KDQpPbiBBcHIgMTgsIDIwMjEsIGF0IDk6NTEgQU0s IEVsaW90IExlYXIgPGxlYXI9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmxlYXI9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KU2lnbmVkIFBHUCBwYXJ0DQpT b3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2U6DQoNCg0KT24gMiBBcHIgMjAyMSwgYXQgMTk6 MDUsIEd1eSBGZWRvcmtvdyA8Z2ZlZG9ya293QGp1bmlwZXIubmV0PG1haWx0bzpnZmVkb3Jrb3dA anVuaXBlci5uZXQ+PiB3cm90ZToNCg0KSGkgTGF1cmVuY2UsDQogIEkgYWdyZWUgdGhhdCBJRGV2 SUQgaXMgaW50ZW5kZWQgdG8gcGVyc2lzdCB0aHJvdWdoIHRoZSBkZXZpY2XigJlzIGxpZmV0aW1l LCB3aGlsZSBMRGV2SUQgaXMgbWVhbnQgdG8gcmVwcmVzZW50IHRoZSBjdXJyZW50IG93bmVyLg0K DQpZZXMsIHRoYXQgd2FzIHRoZSBvcmlnaW5hbCBpbnRlbnQsIGFuZCBldmVuIHRoZSBjdXJyZW50 IGludGVudC4gIEFuZCB3aGlsZSB0aGF0IGlzIG5lY2Vzc2FyeSwgaXQgbWF5IG5vdCBiZSBzdWZm aWNpZW50IGZvciBsb25nIHN1cHBseSBjaGFpbnMgd2hlcmUgb3duZXJzaGlwIHBhc3NlcyBmcm9t IG9uZSB0byBhbm90aGVyLiAgVGhlIExEZXZJRCBpcyBhbiBvd25lci1hc3NpZ25lZCBuYW1lLCBh bmQgc28gdGhlIHF1ZXN0aW9uIGlzIHRoaXM6IHdoZW4gYW4gb3duZXIgZ29lcyB0byB0cmFuc2Zl ciwgZG9lcyBpdCBuZWVkIHRvIHVzZSB0aGUgSURldklEIGFnYWluIG9yIHNob3VsZCBpdCB1c2Ug dGhlIExEZXZJRD8gIFRoZXJlIGFyZSBiZW5lZml0cyBhbmQgZHJhd2JhY2tzIHRvIGJvdGgsIGJ1 dCBpZiB0aGUgTERldklEIGlzIHVzZWQsIHRoZW4gaXQgaXMgdXNlZCBhcyB0aGUgSURldklEIHdv dWxkIGhhdmUgYmVlbiBhcyBwYXJ0IG9mIHRoYXQgdHJhbnNmZXIuICBUaGUgbmljZSB0aGluZyBh Ym91dCBGRE8gaXMgdGhhdCBpdCBrZWVwcyBhbiBlbnRpcmUgcmVjb3JkIG9mIHRoZXNlIHNvcnRz IG9mIHRyYW5zZmVycy4NCg0KSSB0aGluayBpdCBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIG5ldyBv d25lciB0cnVzdHMgdGhlIGlzc3VlciBvZiB0aGUgTERldklELiAgSWYgc28sIHRoZW4gbGV2ZXJh Z2luZyB0aGUgZXhpc3RpbmcgTERldklEIG1heSBiZSBzdHJhaWdodGZvcndhcmQuICBJZiB0aGUg bmV3IG93bmVyIGRvZXMgbm90IHRydXN0IHRoZSBpc3N1ZXIgb2YgdGhlIExEZXZJRCwgdGhlbiBy ZXNldHRpbmcgdGhlIGRldmljZSB0byB0aGUgZmFjdG9yeSBkZWZhdWx0IHNldHRpbmdzLCB3aGlj aCB3b3VsZCBpbmNsdWRlIHRoZSBJRGV2SUQsIG1ha2VzIGEgbG90IG9mIHNlbnNlLg0KDQpSdXNz DQoNCg== --_000_2118D1F3849F4238A2AE054FF67144FFintelcom_ Content-Type: text/html; charset="utf-8" Content-ID: <733F6B8CE607D344BC3B0C07A1C20B1D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246 bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkl0 IGlzIHJlYXNvbmFibGUsIGluIHRoZSBjb250ZXh0IG9mIG9uYm9hcmRpbmcsIHdoZXJlIHRoZSBv d25lciBpc27igJl0IGEgc3VwcGx5IGNoYWluIGVudGl0eSwgYnV0IHRoZSBuZXR3b3JrIG93bmVy IHdobyBpcyBnb2luZyB0byBkZXBsb3kgLyBtYW5hZ2UgdGhlIGRldmljZS4gT25ib2FyZGluZyBt aWdodCBpbnZvbHZlIHNlcGFyYXRlbHkgZXZhbHVhdGluZw0KIHRoZSBzdXBwbHkgY2hhaW4gcmlz ayBhbmQgYW55IOKAmG93bmVy4oCZIHRoYXQgbWlnaHQgYmUgYSBzdXBwbGllciBmcm9tIG9uYm9h cmRpbmcgcHJvY2Vzc2VzIHRoYXQgdGFrZSBhIGNsZWFuIHJvb20gYXBwcm9hY2ggdGhhdCB3aXBl IGNsZWFuIC8gcmVzZXQgdG8gbWZnIGRlZmF1bHRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkFuIG1mZyBJRGV2SUQgZGVzaWduIG1pZ2h0IGJlIHN1Y2ggdGhhdCB0YW1wZXJpbmcgYnkgc3Vw cGx5IGNoYWluIOKAmG93bmVyc+KAmSB3b3VsZCBiZSBkZXRlY3RlZCBhbmQgaGVuY2UgdHJ1c3Rp bmcgdGhlbSBpc27igJl0IHJlYWxseSBuZWNlc3NhcnkuIFRoZSBlbmQgdXNlciAvIGN1c3RvbWVy IGFzIOKAmG93bmVy4oCZIG1pZ2h0IG9ubHkgY2FyZSBhYm91dA0KIHRydXN0aW5nIHRoZSBJRGV2 SUQgbWZnIG9yIG9ubHkgdHJ1c3RpbmcgaGltL2hlciBzZWxmLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PlJ1c3MgSG91c2xleSAmbHQ7aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlN1bmRheSwgQXByaWwgMTgsIDIwMjEgYXQgMTA6MzEgQU08YnI+DQo8Yj5UbzogPC9iPkVs aW90IExlYXIgJmx0O2xlYXI9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj5HdXkgRmVkb3Jrb3cgJmx0O2dmZWRvcmtvd0BqdW5pcGVyLm5ldCZndDssICZxdW90 O1NtaXRoLCBOZWQmcXVvdDsgJmx0O25lZC5zbWl0aEBpbnRlbC5jb20mZ3Q7LCBIZW5rIEJlcmto b2x6ICZsdDtoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlJmd0OywgJnF1b3Q7aW90b3Bz QGlldGYub3JnJnF1b3Q7ICZsdDtpb3RvcHNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtyYXRzQGlldGYu b3JnJnF1b3Q7ICZsdDtyYXRzQGlldGYub3JnJmd0OywgTGF1cmVuY2UgTHVuZGJsYWRlICZsdDts Z2xAaXNsYW5kLXJlc29ydC5jb20mZ3Q7LCBJcmEgTWNEb25hbGQNCiAmbHQ7Ymx1ZXJvb2ZtdXNp Y0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbUmF0c10gODAyLjFBUiBk ZXZpY2UgaWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gQXBy IDE4LCAyMDIxLCBhdCA5OjUxIEFNLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVh cj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+bGVhcj00MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+U2lnbmVkIFBHUCBwYXJ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNvcnJ5 IGZvciB0aGUgZGVsYXllZCByZXNwb25zZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+T24gMiBBcHIgMjAyMSwgYXQgMTk6MDUsIEd1eSBGZWRvcmtvdyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdmZWRvcmtvd0BqdW5pcGVyLm5ldCI+Z2ZlZG9ya293QGp1bmlwZXIubmV0PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpIExh dXJlbmNlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyBJIGFncmVlIHRoYXQgSURldklEIGlz IGludGVuZGVkIHRvIHBlcnNpc3QgdGhyb3VnaCB0aGUgZGV2aWNl4oCZcyBsaWZldGltZSwgd2hp bGUgTERldklEIGlzIG1lYW50IHRvIHJlcHJlc2VudCB0aGUgY3VycmVudCBvd25lci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ WWVzLCB0aGF0IHdhcyB0aGUgb3JpZ2luYWwgaW50ZW50LCBhbmQgZXZlbiB0aGUgY3VycmVudCBp bnRlbnQuICZuYnNwO0FuZCB3aGlsZSB0aGF0IGlzIG5lY2Vzc2FyeSwgaXQgbWF5IG5vdCBiZSBz dWZmaWNpZW50IGZvciBsb25nIHN1cHBseSBjaGFpbnMgd2hlcmUgb3duZXJzaGlwIHBhc3NlcyBm cm9tIG9uZSB0byBhbm90aGVyLiAmbmJzcDtUaGUgTERldklEIGlzIGFuIG93bmVyLWFzc2lnbmVk DQogbmFtZSwgYW5kIHNvIHRoZSBxdWVzdGlvbiBpcyB0aGlzOiB3aGVuIGFuIG93bmVyIGdvZXMg dG8gdHJhbnNmZXIsIGRvZXMgaXQgbmVlZCB0byB1c2UgdGhlIElEZXZJRCBhZ2FpbiBvciBzaG91 bGQgaXQgdXNlIHRoZSBMRGV2SUQ/ICZuYnNwO1RoZXJlIGFyZSBiZW5lZml0cyBhbmQgZHJhd2Jh Y2tzIHRvIGJvdGgsIGJ1dCBpZiB0aGUgTERldklEDQo8Yj5pczwvYj4mbmJzcDt1c2VkLCB0aGVu IGl0IGlzIHVzZWQgYXMgdGhlIElEZXZJRCB3b3VsZCBoYXZlIGJlZW4gYXMgcGFydCBvZiB0aGF0 IHRyYW5zZmVyLiAmbmJzcDtUaGUgbmljZSB0aGluZyBhYm91dCBGRE8gaXMgdGhhdCBpdCBrZWVw cyBhbiBlbnRpcmUgcmVjb3JkIG9mIHRoZXNlIHNvcnRzIG9mIHRyYW5zZmVycy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayBpdCBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIG5l dyBvd25lciB0cnVzdHMgdGhlIGlzc3VlciBvZiB0aGUgTERldklELiAmbmJzcDtJZiBzbywgdGhl biBsZXZlcmFnaW5nIHRoZSBleGlzdGluZyBMRGV2SUQgbWF5IGJlIHN0cmFpZ2h0Zm9yd2FyZC4g Jm5ic3A7SWYgdGhlIG5ldyBvd25lciBkb2VzIG5vdCB0cnVzdCB0aGUgaXNzdWVyIG9mIHRoZSBM RGV2SUQsIHRoZW4gcmVzZXR0aW5nDQogdGhlIGRldmljZSB0byB0aGUgZmFjdG9yeSBkZWZhdWx0 IHNldHRpbmdzLCB3aGljaCB3b3VsZCBpbmNsdWRlIHRoZSBJRGV2SUQsIG1ha2VzIGEgbG90IG9m IHNlbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJ1 c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2118D1F3849F4238A2AE054FF67144FFintelcom_-- From nobody Thu Apr 22 07:26:00 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C293D3A0E6A; Thu, 22 Apr 2021 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3rKvLNiM2x6w; Thu, 22 Apr 2021 07:25:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08663A0E63; Thu, 22 Apr 2021 07:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3963; q=dns/txt; s=iport; t=1619101554; x=1620311154; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=EI4YVqek96I2qfUm233Mfh2Ubo2n2XNAQqtf3nfQnVc=; b=TOx5qGawXaOIqHzzj1NSoL7Qm4WhXytqpEtbz6F++hip2Z1BwzLObag3 IhNGlCyXRz8ag/tmun28YpXf8SRJ4RS3yBZnHdpS3ehHtvqjF8/xuLd5x vIqZ8vqVsD7KzESSqhUB5Svm5sTKOd5ZdoSd5jKf/Fr6ZAfSCYmamBBsP A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AMAADKhoFg/xbLJq1QAQkbAQEBAQEBAQEFAQEBEgEBA?= =?us-ascii?q?QMDAQEBgX4GAQEBCwGBIoJVAScShHSIJGCIaogBjE2GJBSBaAQHAQEBCgMBA?= =?us-ascii?q?TQEAQGEUAKBeSY0CQ4CAwEBAQMCAwEBAQEBBQEBAQIBBgRxE4VdhkUGI1YQC?= =?us-ascii?q?wQBPQICVwaDBAGDB6gseoEygQGEWIRkEIE6AYFShS8BhlRDgguBEycMEIJfP?= =?us-ascii?q?oQNAQcBCgGDODaCKwSCQAYIYIFYGmWRbItAgSmdD4MYg0GBRpgSBCGUPZBQt?= =?us-ascii?q?GmEBQIEBgUCFoFUOmlwMxoIGxVlAYI/PRIZDpxuPwNnAgYBCQEBAwmNDwEB?= IronPort-HdrOrdr: A9a23:ct7euK43RwwNHjNnjgPXwErXdLJzesId70hD6mlaQ3VuA6+lvu qpm+kW0gKxtSYJVBgb9eyoFaGcTRrnlKJdzpIWOd6ZNjXOmGztF4166Jun/juIIU3D38pQz7 1pfaQ7KNCYNzVHpOL75AX9LNo62tmA98mT6tv29HtmQQF0Z6wI1W4QYTqzKUF4SBJLApA0Dv Onl696jgC9cncaZNnTPBc4dtXEzue79q7OUFojDx4j5BLmt0LN1JfKVz6FwxwZTzRDhZAl/G StqX2e2oyT99em1xTby2jfq65zpeKk4N5CCMuQ4/JlTQnRtg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,242,1613433600"; d="asc'?scan'208,217";a="32877358" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Apr 2021 14:25:52 +0000 Received: from [10.61.144.111] ([10.61.144.111]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13MEPplQ032206 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Apr 2021 14:25:51 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2F08B112-EBCB-493C-A56B-C0E20477ABD9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 22 Apr 2021 16:25:50 +0200 In-Reply-To: Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org To: Brian Smith References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.111, [10.61.144.111] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 14:25:59 -0000 --Apple-Mail=_2F08B112-EBCB-493C-A56B-C0E20477ABD9 Content-Type: multipart/alternative; boundary="Apple-Mail=_E08B36AB-85FD-498C-85F0-B61836978365" --Apple-Mail=_E08B36AB-85FD-498C-85F0-B61836978365 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Actually, according to 802.1AR-2009, the subject MUST contain requires a = DN with serial number, and it may contain a SAN (e.g., don=E2=80=99t = count on it). That=E2=80=99s the major concern. To me, the rest is = really negotiable. Here=E2=80=99s the text: The DevID subject field shall uniquely identify the device associated = with the particular DevID credential within the issuer=E2=80=99s domain = of significance. The formatting of this field shall contain a unique = X.500 Distinguished Name (DN). This may include the unique device serial = number assigned by the manufacturer or any other suitable unique DN = value that the issuer prefers. In the case of a third-party CA or a = standards certification agency, this can contain the manufacturer=E2=80=99= s identity information. That=E2=80=99s a pretty broad range. I don=E2=80=99t claim that this is the only use of subjects, but it is = one such use. Email --Apple-Mail=_E08B36AB-85FD-498C-85F0-B61836978365 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Actually, according to 802.1AR-2009, the subject MUST contain = requires a DN with serial number, and it may contain a SAN (e.g., = don=E2=80=99t count on it).  That=E2=80=99s the major concern. =  To me, the rest is really negotiable.

Here=E2=80=99s the text:
=09 =09 =09

The DevID subject field shall uniquely identify the device = associated with the particular DevID credential within the issuer=E2=80=99s domain of significance. The formatting of = this field shall contain a unique X.500 Distinguished Name (DN). This may include the unique device serial = number assigned by the manufacturer or any other suitable unique DN value that the issuer prefers. In the = case of a third-party CA or a standards certification agency, this can contain the manufacturer=E2=80=99s = identity information. 

That=E2=80=99s a = pretty broad range.

I don=E2=80=99t claim that this is the only use of subjects, but it is one such = use.

Email 
= --Apple-Mail=_E08B36AB-85FD-498C-85F0-B61836978365-- --Apple-Mail=_2F08B112-EBCB-493C-A56B-C0E20477ABD9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCBh24ACgkQh7ZrRtnS ejOnWwf9GY2vJ3MJYTb3TC3d0LSY0T2AtJcEt0S0cWGZWEam0aswI9k0/CaQR9UY VQCNkkCSYsGa8zfZrP6Twl/fxHAuN1z0LjMACdhlyvx+/yQtdgl2f7Oz8cOqlO93 Iq16FqLaK3t8mHWh6YG7NvZHmETpzhWchmIywMLzvpdYTwkvx+2Xb+Z1Jvd/5VQy 3IlYeUfuyGivWt52umGX4ttOWqV18JhQAGNh0g8qG5Qf/5cIfVkf4subpzjKSpm5 fWRBr5BKXMhO7AX6OOoX0LxcUgR9g+A012i0uFvExsIoSFc+Kjbf7DQW8Dk7vRL5 JVBunDj8opEXWiaMupgd+qHDzwWGEw== =ZB1R -----END PGP SIGNATURE----- --Apple-Mail=_2F08B112-EBCB-493C-A56B-C0E20477ABD9-- From nobody Thu Apr 22 09:58:29 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE6F3A0A34 for ; Thu, 22 Apr 2021 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 LLc_hF5L7EeP for ; Thu, 22 Apr 2021 09:58:17 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 95D083A0A2C for ; Thu, 22 Apr 2021 09:58:17 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id p2so17809198pgh.4 for ; Thu, 22 Apr 2021 09:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pRzXP/wBYod4B7BSKKlgaOpaaoE0372iWicxeAV+Ncw=; b=shBye6uOTBzqDjhQpfkeXY5H5koiQenVcdBOMiWJM2CA2kMweq0Qy0eICTwS+1Wfe6 0WWV9GEmW0imS/d2uwaUN5cWMtn2INVPUm81vK8IemY/TdK5Hx9HvkNXbOrOs/2GG3RL A3mD593eCREiobAo8Q7RyreHQ/tZl7xW3olAx2MNb76gme9/I69B8fZ2PS1dic0aCcMP WjFLjxAnkCLdFj5H8QX9UQYviKqaQnaOOV2racvGCrGwqITdagc15VHaItU7yZGWyznA M+Vq3H7Ymrt6M+73EzDtur7Ajz6n2BqBe/NFOhps4rKvycqOeksU9mydfuMe9QjDzjKR 7how== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pRzXP/wBYod4B7BSKKlgaOpaaoE0372iWicxeAV+Ncw=; b=Rx0bYeeYI+z36OBAj/yZJiWwyJ+cK0sPLp8O02+KeL34yXzm7vBJsvqz4OrhWq2Jkq XPU9ltgIkzDv+LuHN7oyI1Pxll6qoIiGjZY7IWdDhyAqDWvg6TI4A+UktTyXtJuxiLbA 25bqlVlSYBEh+0Yv5fDps9yvsL38IQxivsOuLAGf9ANZ2/BPmMKAsDPrvF0LwnZ4rRMj w/IzN6MgNZtYio89PT7lUktclEKuRFeBCBHhMtin8VhNgQE7JV/P5H0XsEnI+Ca97mCe vjBXikWrc/z39Hb+qTCHpSXjVhiWFnqPK/CIVW0PjAs+bc5d0BMbWTFoTGJSORfGzTu4 L+6w== X-Gm-Message-State: AOAM5308+zvmdDn8nm3Ee81UCH9yqOhyBzoYNoaipLU0B49uKF0k8vNY w7dfLD0W5IhCk2lmo0zHC06vPxWQNoVJLILzxSN93A== X-Google-Smtp-Source: ABdhPJyr2oucFajQdQWaiUEvTV8aBwQrnKnnTAHZ3veZU0ICVcy99E5uRiiMuVa01SpswF3jdfeeZPgq0xKZw1GYTcY= X-Received: by 2002:a62:ac08:0:b029:25d:642e:8201 with SMTP id v8-20020a62ac080000b029025d642e8201mr1470468pfe.59.1619110696236; Thu, 22 Apr 2021 09:58:16 -0700 (PDT) MIME-Version: 1.0 References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> In-Reply-To: From: Brian Smith Date: Thu, 22 Apr 2021 09:58:05 -0700 Message-ID: To: Eliot Lear Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6cab405c092950d" Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 16:58:23 -0000 --000000000000e6cab405c092950d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > Actually, according to 802.1AR-2009, the subject MUST contain requires a > DN with serial number, and it may contain a SAN (e.g., don=E2=80=99t coun= t on it). > That=E2=80=99s the major concern. To me, the rest is really negotiable. > OK, great. I don't think what Rich or what I'm proposing is in conflict with that at all. The idea here is to tell certificate verifiers (relying parties): * If you're looking for a DNS name in a certificate, only look in the subjectAltName, Don't look in the Subject Common Name. * If you're looking for an IP address in a certificate, only look in the subjectAltName, Don't look in the Subject Common Name. That's it. In the case of 802.1AR-2009, the verifier is to look for a distinguished name (either the Subject or a directoryName subjectAltName), not a DNS name or an IP address, so the proposed guidance wouldn't apply. Note that RFC 6125 punted in IP addresses because they weren't commonly used in certificates in the working groups' judgement at the time, but now I think it is clear that an update to RFC 6125 should address IP addresses too. Cheers, Brian --000000000000e6cab405c092950d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot Lear <lear@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Actually, according to 802.1AR-2009, the subject MUST conta= in requires a DN with serial number, and it may contain a SAN (e.g., don=E2= =80=99t count on it).=C2=A0 That=E2=80=99s the major concern.=C2=A0 To me, = the rest is really negotiable.

OK, gr= eat. I don't think what Rich or what I'm proposing is in conflict w= ith that at all.

The idea here is to tell certific= ate verifiers (relying parties):
* If you're looking=C2=A0for= a DNS name in a certificate, only look in the subjectAltName, Don't lo= ok in the Subject Common Name.
* If you're looking for an IP = address in a certificate, only look in the subjectAltName,=C2=A0 Don't look in the Subject Common Name.

That= 9;s it.

In the case of=C2=A0 802.1AR-2009, the verifier is to look for a distinguished name (either the = Subject or a directoryName subjectAltName), not a DNS name or an IP address= , so the proposed guidance wouldn't apply.

Not= e that RFC 6125 punted in IP addresses because they weren't commonly us= ed in certificates in the working groups' judgement at the time, but no= w I think it is clear that an update to RFC 6125 should address IP addresse= s too.

Cheers,
Brian
--000000000000e6cab405c092950d-- From nobody Thu Apr 22 10:03:35 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888603A0AD3; Thu, 22 Apr 2021 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GkVhJzyvy7WC; Thu, 22 Apr 2021 10:03:29 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5955B3A0ACB; Thu, 22 Apr 2021 10:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5624; q=dns/txt; s=iport; t=1619111008; x=1620320608; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=LC01cWHXAe6P6xlWGKUuFKA0EjRV/bEx335sBW9VR74=; b=Z3uq/b1l3ygvPJo6vk7mwFhAyfy4XQONFZhzs0puLqxE/Aft5ohSugWh 19D4+NhZM9sTLGAoQF9WhWPFPmLiLCZXp9E252n2ljiMUR6EpSq9AbY4U cy9sR/4QSH+rKdfsqcpc5uthhZ5mrwg3SAcwAM3aqbSfA18EChspidh01 U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AFAAA0q4Fg/xbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGBfwMBAQEBAQsBg3cBJxIxhEOJBIhqA5RLhiSBfAQHA?= =?us-ascii?q?QEBCgMBATQEAQGEUAKBeSY1CA4CAwEBAQMCAwEBAQEBBQEBAQIBBgRxE4Vdh?= =?us-ascii?q?kQBAQEDASNWBQsLBBQnAwICRhEGE4JxAYJmIag1eoEygQGEWIRmEIE6AYFSh?= =?us-ascii?q?S8BhlRDgguBEycMEIJfPodZNoIrBIFVawUBaIFYf1icVIEpnQ+DGINBgUaYE?= =?us-ascii?q?gQhg1CQbZBQlzedMoQFAgQGBQIWgVYBN4FZMxoIGxVlAYI+PhIZDpxuPwMvO?= =?us-ascii?q?AIGAQkBAQMJjQ8BAQ?= IronPort-HdrOrdr: A9a23:kum4vK/SFf7Lo0u15dluk+BaI+orLtY04lQ7vn1ZYxY9SL36q+ mFmvMH2RjozAsAQX1Io7y9EYSJXH+0z/9IyKYLO7PKZmPbkUuuaLpv9I7zhwDnchefysd42b 17e6ZzTP38ZGIWse/f4A21V+kt28OG9qfAv4jj5kxgRw1rdK1shj0RYm2mO3Z7SwVcCZ0yGI D03LsjmxObZX8VYs6nb0NqY8H/obTw5fDbSC9DIxYm7QWU5AnYjILSIly/wgoUVS9JzPME92 XI+jaJgJmLgrWc1gLW0XPV4tBtvObZjvFHBMCKl6EuW1LRtjo= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,243,1613433600"; d="asc'?scan'208,217";a="32882677" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Apr 2021 17:03:26 +0000 Received: from [10.61.144.111] ([10.61.144.111]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 13MH3PH9026215 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Apr 2021 17:03:25 GMT From: Eliot Lear Message-Id: <184E8EE9-BD98-4887-BC01-E74FB6943600@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_ED670E55-B13D-4CE1-A8CD-E5595FDAB1E6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 22 Apr 2021 19:03:24 +0200 In-Reply-To: Cc: "Salz, Rich" , Jim Fenton , "uta@ietf.org" , iotops@ietf.org To: Brian Smith References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.111, [10.61.144.111] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 17:03:34 -0000 --Apple-Mail=_ED670E55-B13D-4CE1-A8CD-E5595FDAB1E6 Content-Type: multipart/alternative; boundary="Apple-Mail=_CE9992B0-47DE-4A9C-81C0-19BD8E2DE293" --Apple-Mail=_CE9992B0-47DE-4A9C-81C0-19BD8E2DE293 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Brian. I appreciate your patience. The below totally works for = me. Eliot > On 22 Apr 2021, at 18:58, Brian Smith wrote: >=20 > Eliot Lear > wrote: > Actually, according to 802.1AR-2009, the subject MUST contain requires = a DN with serial number, and it may contain a SAN (e.g., don=E2=80=99t = count on it). That=E2=80=99s the major concern. To me, the rest is = really negotiable. >=20 > OK, great. I don't think what Rich or what I'm proposing is in = conflict with that at all. >=20 > The idea here is to tell certificate verifiers (relying parties): > * If you're looking for a DNS name in a certificate, only look in the = subjectAltName, Don't look in the Subject Common Name. > * If you're looking for an IP address in a certificate, only look in = the subjectAltName, Don't look in the Subject Common Name. >=20 > That's it. >=20 > In the case of 802.1AR-2009, the verifier is to look for a = distinguished name (either the Subject or a directoryName = subjectAltName), not a DNS name or an IP address, so the proposed = guidance wouldn't apply. >=20 > Note that RFC 6125 punted in IP addresses because they weren't = commonly used in certificates in the working groups' judgement at the = time, but now I think it is clear that an update to RFC 6125 should = address IP addresses too. >=20 > Cheers, > Brian --Apple-Mail=_CE9992B0-47DE-4A9C-81C0-19BD8E2DE293 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Brian.  I appreciate your patience.  The = below totally works for me.


Eliot

On 22 Apr 2021, at 18:58, Brian Smith <brian@briansmith.org> wrote:

Eliot = Lear <lear@cisco.com> wrote:
Actually, according to 802.1AR-2009, the subject = MUST contain requires a DN with serial number, and it may contain a SAN = (e.g., don=E2=80=99t count on it).  That=E2=80=99s the major = concern.  To me, the rest is really = negotiable.

OK, great. I don't think what Rich or what I'm proposing is = in conflict with that at all.

The idea here is to tell certificate = verifiers (relying parties):
* If you're = looking for a DNS name in a certificate, only look in the = subjectAltName, Don't look in the Subject Common Name.
* If you're looking for an IP address in a certificate, only = look in the subjectAltName,  Don't look in the Subject Common Name.

That's it.

In the case of  802.1AR-2009, the verifier is to look for a distinguished name (either = the Subject or a directoryName subjectAltName), not a DNS name or an IP = address, so the proposed guidance wouldn't apply.
Note that RFC 6125 punted in IP = addresses because they weren't commonly used in certificates in the = working groups' judgement at the time, but now I think it is clear that = an update to RFC 6125 should address IP addresses too.

Cheers,
Brian

= --Apple-Mail=_CE9992B0-47DE-4A9C-81C0-19BD8E2DE293-- --Apple-Mail=_ED670E55-B13D-4CE1-A8CD-E5595FDAB1E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCBrFwACgkQh7ZrRtnS ejMpIgf6AkrQAq9yZniP+I/PFU/kCVwL0a4P7RrWyEAJ3BRiPiokW+qoc8Dn2zz8 xm51F8nMFi9xm/Gp2DzYH6sTjcfGOkjfKbDZFjRWqJKBd3NsG8aV83pwczJWlg+d 8K5yWqkghsPiUFFRcDbB3DcoowUCVAmCB0JDT5nWMsVrlprNaxGbNUtvWJG+HNHR VZFMXgSA2rYGVTNat0juIHZbekl4sgApR9Nf12DrceHgOrUIX3G5N9LDpMsRMzOp qyejertpb5Af7Up1a1WUSmMm5K6rr7eB5gsTm50Dim+CvgdaDnJLQ1dGWixpo7zm gIL9rmVv+0ozIEGyXCpQgJWCaPeoTQ== =AIqS -----END PGP SIGNATURE----- --Apple-Mail=_ED670E55-B13D-4CE1-A8CD-E5595FDAB1E6-- From nobody Thu Apr 22 10:49:00 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001063A1047; Thu, 22 Apr 2021 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 0wi4J0aNKZbk; Thu, 22 Apr 2021 10:48:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 DC6823A1041; Thu, 22 Apr 2021 10:48:52 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13MHdbpE012659; Thu, 22 Apr 2021 18:48:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=MC7mNysKSSkmtxwAMiv2fFvnszcnXFjrfLVTZkdCSYg=; b=R4uX0JvjlXEkpohaEkKL9RRm/0/N302uk5+1ZuygAULZqM8lNdXA6udvZC/NZP3b8j+y Q2A23lkAOuaXYhh4qJOkb4dbcBWg5Vwkkxr5lsWZuI7vIBCXg/3gsufTaSERjmGiudtV qWdrl6jkdsRY6pXdcFX2JuB0efz3RaqRVnJfJ3DeYYY+NSiqbdQ1JIAy1pUw4RmOSeTg tIdrIFmwtRvbLm436EsQ0qzWscKtPx/9a0UszyBjPYoR3M3vu5tGpBqYc6T2ekQnrSLM IE1lpAkp336diNDyNm9T2RKgOl0blChScKoQqE6Nc0gFOMsPECXnY23yZYvtqlORVmav Uw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 382nw91mfa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 18:48:45 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 13MHZ40t013260; Thu, 22 Apr 2021 10:48:44 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 382mnftmew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 10:48:44 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Apr 2021 13:48:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Apr 2021 13:48:43 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.015; Thu, 22 Apr 2021 13:48:43 -0400 From: "Salz, Rich" To: Eliot Lear , Brian Smith CC: Jim Fenton , "uta@ietf.org" , "iotops@ietf.org" Thread-Topic: [Uta] How should we change draft-ietf-use-san? Thread-Index: AQHXNTnKHqROQqsINkafTpLDOH8k26q8cbwAgAA0N4CAAJNJAIAAPXSAgABOooCAAItgAIAAmSMAgACMwQCAAA/GAIAAGn6AgAAGXYCAAAvugIABLD4AgAAqioCAAAF8AP//yZmA Date: Thu, 22 Apr 2021 17:48:42 +0000 Message-ID: <99B5A119-8CF2-4D3C-9D24-ADCC52D017A2@akamai.com> References: <413CBCFE-1FDF-458E-9F0E-E3D58F86E5D9@bluepopcorn.net> <8A41ED29-2448-4633-AC45-33DE98A6BC81@akamai.com> <7B51BB81-1C9D-4B2F-AF83-1E528E620AE7@cisco.com> <42739D1C-004F-4DAD-8023-8E9731B46E05@cisco.com> <4233FD89-F22D-4D09-8280-8D43453E6BD7@cisco.com> <184E8EE9-BD98-4887-BC01-E74FB6943600@cisco.com> In-Reply-To: <184E8EE9-BD98-4887-BC01-E74FB6943600@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_99B5A1198CF24D3C9D24ADCC52D017A2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-22_12:2021-04-22, 2021-04-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104220132 X-Proofpoint-ORIG-GUID: wFfMC7NrPewFjNxX2PpzoNu3bwWUmVO8 X-Proofpoint-GUID: wFfMC7NrPewFjNxX2PpzoNu3bwWUmVO8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-22_12:2021-04-22, 2021-04-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 clxscore=1011 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104220133 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint5 Archived-At: Subject: Re: [Iotops] [Uta] How should we change draft-ietf-use-san? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 17:48:58 -0000 --_000_99B5A1198CF24D3C9D24ADCC52D017A2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBiZWdpbm5pbmcgdG8gdGhpbmsgdGhhdCBkb2luZyBhIGNvbXBsZXRlIHJlLWlzc3VlIG9m IDYxMjUgd2lsbCBiZSBiZXR0ZXIsIGJlY2F1c2UgdHJ5aW5nIHRvIGZpdCB0aGUg4oCccGF0Y2ji gJ0gZGVzY3JpYmVkIGJlbG93IHNlZW1zIGF3a3dhcmQuICBPbiB0aGUgb3RoZXIgaGFuZCwgaWYg YW55b25lIGhhcyBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZG8gdGhhdCwgcGxlYXNlIHBvc3Qgb3Ig ZW1haWwgb3IgbWFrZSBhIFBSIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9yaWNoc2Fsei9kcmFmdC1y c2Fsei11c2Utc2FuDQoNCkZyb206IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPg0KRGF0ZTog VGh1cnNkYXksIEFwcmlsIDIyLCAyMDIxIGF0IDE6MDMgUE0NClRvOiBCcmlhbiBTbWl0aCA8YnJp YW5AYnJpYW5zbWl0aC5vcmc+DQpDYzogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPiwgSmlt IEZlbnRvbiA8ZmVudG9uQGJsdWVwb3Bjb3JuLm5ldD4sICJ1dGFAaWV0Zi5vcmciIDx1dGFAaWV0 Zi5vcmc+LCA8aW90b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVdGFdIEhvdyBzaG91bGQg d2UgY2hhbmdlIGRyYWZ0LWlldGYtdXNlLXNhbj8NCg0KVGhhbmtzLCBCcmlhbi4gIEkgYXBwcmVj aWF0ZSB5b3VyIHBhdGllbmNlLiAgVGhlIGJlbG93IHRvdGFsbHkgd29ya3MgZm9yIG1lLg0KDQoN CkVsaW90DQoNCg0KT24gMjIgQXByIDIwMjEsIGF0IDE4OjU4LCBCcmlhbiBTbWl0aCA8YnJpYW5A YnJpYW5zbWl0aC5vcmc8bWFpbHRvOmJyaWFuQGJyaWFuc21pdGgub3JnPj4gd3JvdGU6DQoNCkVs aW90IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0K QWN0dWFsbHksIGFjY29yZGluZyB0byA4MDIuMUFSLTIwMDksIHRoZSBzdWJqZWN0IE1VU1QgY29u dGFpbiByZXF1aXJlcyBhIEROIHdpdGggc2VyaWFsIG51bWJlciwgYW5kIGl0IG1heSBjb250YWlu IGEgU0FOIChlLmcuLCBkb27igJl0IGNvdW50IG9uIGl0KS4gIFRoYXTigJlzIHRoZSBtYWpvciBj b25jZXJuLiAgVG8gbWUsIHRoZSByZXN0IGlzIHJlYWxseSBuZWdvdGlhYmxlLg0KDQpPSywgZ3Jl YXQuIEkgZG9uJ3QgdGhpbmsgd2hhdCBSaWNoIG9yIHdoYXQgSSdtIHByb3Bvc2luZyBpcyBpbiBj b25mbGljdCB3aXRoIHRoYXQgYXQgYWxsLg0KDQpUaGUgaWRlYSBoZXJlIGlzIHRvIHRlbGwgY2Vy dGlmaWNhdGUgdmVyaWZpZXJzIChyZWx5aW5nIHBhcnRpZXMpOg0KKiBJZiB5b3UncmUgbG9va2lu ZyBmb3IgYSBETlMgbmFtZSBpbiBhIGNlcnRpZmljYXRlLCBvbmx5IGxvb2sgaW4gdGhlIHN1Ympl Y3RBbHROYW1lLCBEb24ndCBsb29rIGluIHRoZSBTdWJqZWN0IENvbW1vbiBOYW1lLg0KKiBJZiB5 b3UncmUgbG9va2luZyBmb3IgYW4gSVAgYWRkcmVzcyBpbiBhIGNlcnRpZmljYXRlLCBvbmx5IGxv b2sgaW4gdGhlIHN1YmplY3RBbHROYW1lLCAgRG9uJ3QgbG9vayBpbiB0aGUgU3ViamVjdCBDb21t b24gTmFtZS4NCg0KVGhhdCdzIGl0Lg0KDQpJbiB0aGUgY2FzZSBvZiAgODAyLjFBUi0yMDA5LCB0 aGUgdmVyaWZpZXIgaXMgdG8gbG9vayBmb3IgYSBkaXN0aW5ndWlzaGVkIG5hbWUgKGVpdGhlciB0 aGUgU3ViamVjdCBvciBhIGRpcmVjdG9yeU5hbWUgc3ViamVjdEFsdE5hbWUpLCBub3QgYSBETlMg bmFtZSBvciBhbiBJUCBhZGRyZXNzLCBzbyB0aGUgcHJvcG9zZWQgZ3VpZGFuY2Ugd291bGRuJ3Qg YXBwbHkuDQoNCk5vdGUgdGhhdCBSRkMgNjEyNSBwdW50ZWQgaW4gSVAgYWRkcmVzc2VzIGJlY2F1 c2UgdGhleSB3ZXJlbid0IGNvbW1vbmx5IHVzZWQgaW4gY2VydGlmaWNhdGVzIGluIHRoZSB3b3Jr aW5nIGdyb3VwcycganVkZ2VtZW50IGF0IHRoZSB0aW1lLCBidXQgbm93IEkgdGhpbmsgaXQgaXMg Y2xlYXIgdGhhdCBhbiB1cGRhdGUgdG8gUkZDIDYxMjUgc2hvdWxkIGFkZHJlc3MgSVAgYWRkcmVz c2VzIHRvby4NCg0KQ2hlZXJzLA0KQnJpYW4NCg0K --_000_99B5A1198CF24D3C9D24ADCC52D017A2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <0C41B2A0817E6247BF4F59F929536F26@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYmVnaW5uaW5nIHRvIHRoaW5rIHRoYXQgZG9pbmcgYSBj b21wbGV0ZSByZS1pc3N1ZSBvZiA2MTI1IHdpbGwgYmUgYmV0dGVyLCBiZWNhdXNlIHRyeWluZyB0 byBmaXQgdGhlIOKAnHBhdGNo4oCdIGRlc2NyaWJlZCBiZWxvdyBzZWVtcyBhd2t3YXJkLiZuYnNw OyBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgYW55b25lIGhhcyBzdWdnZXN0aW9ucyBvbiBob3cgdG8g ZG8gdGhhdCwgcGxlYXNlIHBvc3Qgb3IgZW1haWwgb3IgbWFrZQ0KIGEgUFIgYXQgaHR0cHM6Ly9n aXRodWIuY29tL3JpY2hzYWx6L2RyYWZ0LXJzYWx6LXVzZS1zYW48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkVsaW90IExlYXIgJmx0O2xlYXJAY2lzY28uY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgQXByaWwgMjIsIDIwMjEgYXQgMTowMyBQTTxi cj4NCjxiPlRvOiA8L2I+QnJpYW4gU21pdGggJmx0O2JyaWFuQGJyaWFuc21pdGgub3JnJmd0Ozxi cj4NCjxiPkNjOiA8L2I+UmljaCBTYWx6ICZsdDtyc2FsekBha2FtYWkuY29tJmd0OywgSmltIEZl bnRvbiAmbHQ7ZmVudG9uQGJsdWVwb3Bjb3JuLm5ldCZndDssICZxdW90O3V0YUBpZXRmLm9yZyZx dW90OyAmbHQ7dXRhQGlldGYub3JnJmd0OywgJmx0O2lvdG9wc0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtVdGFdIEhvdyBzaG91bGQgd2UgY2hhbmdlIGRyYWZ0LWlldGYt dXNlLXNhbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzLCBCcmlhbi4gJm5ic3A7SSBhcHByZWNpYXRlIHlvdXIgcGF0aWVuY2UuICZu YnNwO1RoZSBiZWxvdyB0b3RhbGx5IHdvcmtzIGZvciBtZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkVsaW90PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAyMiBBcHIgMjAyMSwgYXQgMTg6NTgsIEJyaWFuIFNtaXRoICZsdDs8 YSBocmVmPSJtYWlsdG86YnJpYW5AYnJpYW5zbWl0aC5vcmciPmJyaWFuQGJyaWFuc21pdGgub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29t Ij5sZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY3R1YWxseSwg YWNjb3JkaW5nIHRvIDgwMi4xQVItMjAwOSwgdGhlIHN1YmplY3QgTVVTVCBjb250YWluIHJlcXVp cmVzIGEgRE4gd2l0aCBzZXJpYWwgbnVtYmVyLCBhbmQgaXQgbWF5IGNvbnRhaW4gYSBTQU4gKGUu Zy4sIGRvbuKAmXQgY291bnQgb24gaXQpLiZuYnNwOyBUaGF04oCZcyB0aGUgbWFqb3IgY29uY2Vy bi4mbmJzcDsgVG8gbWUsIHRoZSByZXN0IGlzIHJlYWxseSBuZWdvdGlhYmxlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PSywgZ3JlYXQuIEkgZG9uJ3QgdGhpbmsgd2hhdCBSaWNoIG9yIHdoYXQgSSdtIHByb3Bvc2lu ZyBpcyBpbiBjb25mbGljdCB3aXRoIHRoYXQgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSBoZXJlIGlzIHRvIHRlbGwg Y2VydGlmaWNhdGUgdmVyaWZpZXJzIChyZWx5aW5nIHBhcnRpZXMpOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBJZiB5b3UncmUgbG9va2luZyZu YnNwO2ZvciBhIEROUyBuYW1lIGluIGEgY2VydGlmaWNhdGUsIG9ubHkgbG9vayBpbiB0aGUgc3Vi amVjdEFsdE5hbWUsIERvbid0IGxvb2sgaW4gdGhlIFN1YmplY3QgQ29tbW9uIE5hbWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIElmIHlvdSdy ZSBsb29raW5nIGZvciBhbiBJUCBhZGRyZXNzIGluIGEgY2VydGlmaWNhdGUsIG9ubHkgbG9vayBp biB0aGUgc3ViamVjdEFsdE5hbWUsJm5ic3A7IERvbid0IGxvb2sgaW4gdGhlIFN1YmplY3QgQ29t bW9uIE5hbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYXQncyBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gdGhlIGNhc2Ugb2YmbmJzcDsgODAyLjFBUi0yMDA5LCB0aGUgdmVy aWZpZXIgaXMgdG8gbG9vayBmb3IgYSBkaXN0aW5ndWlzaGVkIG5hbWUgKGVpdGhlciB0aGUgU3Vi amVjdCBvciBhIGRpcmVjdG9yeU5hbWUgc3ViamVjdEFsdE5hbWUpLCBub3QgYSBETlMgbmFtZSBv ciBhbiBJUCBhZGRyZXNzLCBzbyB0aGUgcHJvcG9zZWQgZ3VpZGFuY2Ugd291bGRuJ3QgYXBwbHku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5v dGUgdGhhdCBSRkMgNjEyNSBwdW50ZWQgaW4gSVAgYWRkcmVzc2VzIGJlY2F1c2UgdGhleSB3ZXJl bid0IGNvbW1vbmx5IHVzZWQgaW4gY2VydGlmaWNhdGVzIGluIHRoZSB3b3JraW5nIGdyb3Vwcycg anVkZ2VtZW50IGF0IHRoZSB0aW1lLCBidXQgbm93IEkgdGhpbmsgaXQgaXMgY2xlYXIgdGhhdCBh biB1cGRhdGUgdG8gUkZDIDYxMjUgc2hvdWxkIGFkZHJlc3MgSVAgYWRkcmVzc2VzIHRvby48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJp YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_99B5A1198CF24D3C9D24ADCC52D017A2akamaicom_-- From nobody Fri Apr 23 11:16:24 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE873A191A for ; Fri, 23 Apr 2021 11:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 ErfoIpAuT9cR for ; Fri, 23 Apr 2021 11:16:18 -0700 (PDT) Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) (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 44A223A1918 for ; Fri, 23 Apr 2021 11:16:18 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id a0Lfl0P0yrPTra0LglpyVh; Fri, 23 Apr 2021 11:16:16 -0700 X-CMAE-Analysis: v=2.4 cv=T89J89GQ c=1 sm=1 tr=0 ts=60830ef1 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=QyXUC8HyAAAA:8 a=tGX7uwomAAAA:8 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=K6EGIJCdAAAA:8 a=pGLkceISAAAA:8 a=Jg6--adYSNYXEHCzORYA:9 a=QEXdDO2ut3YA:10 a=OXrohY9_HIevfIkeyaAA:9 a=hy_OLbzDc93LghcN:21 a=_W_S_7VecoQA:10 a=ZFOOzkjxzLGrPE5HuMia:22 a=w1C3t2QeGrPiZgrLijVG:22 a=cAcMbU7R10T-QSRYIcO_:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <4A3F3EEE-23C2-4D3A-A503-C946ED772DB1@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4A1677D2-FA49-4D03-8ADF-A796DAB91517" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 23 Apr 2021 11:16:14 -0700 In-Reply-To: <2118D1F3-849F-4238-A2AE-054FF67144FF@intel.com> Cc: Russ Housley , Eliot Lear , Henk Birkholz , "iotops@ietf.org" , "rats@ietf.org" , Ira McDonald , Guy Fedorkow To: "Smith, Ned" References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com> <2118D1F3-849F-4238-A2AE-054FF67144FF@intel.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfJLKzwb4JRs6MaFT7oXIdZnI1uMabD1GHm8dU32bQaqwdej3OUvlVrgxL1AWXvdFkQs4Q3rih1ApNIV/VFuYl490GxU7HMMMyr3ptpqy9JEeULTeWFMF 0ZjWQoFAEN33Ox33+MqreKK58lRDNHhkb6f070/8kxJ4WpzgJoeNTkMmK9JQI6c2ehl1YVh5BNJN0CJbigx2rqAfNKh1T+cm3miOd+Bp+yjknwH0ilv56GNY /i98b9MzogiZvoL1NeAKpUuESLY0g05/8rXDqY6j+7okpENm8LSxZCd0/L2WlnLE27xM/9OngPXWTZmHNAJIZs5mgWgdDJf9W14IE/83FRPPWeW8WUS5Riie CVsTt22rmj3e7CxTwYgjYiD75Jn1YPMOjV8+eE3aG3PnUkHx7+y/wN6oGbeNF3OPpu1nelflvrYnjQ5CgQ/vifUYL7H26w== Archived-At: Subject: Re: [Iotops] [Rats] 802.1AR device identity X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:16:23 -0000 --Apple-Mail=_4A1677D2-FA49-4D03-8ADF-A796DAB91517 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for all the helpful responses and info here.=20 I believe the discussion and comments received validate the EAT design = of a UEID and an SUEID. UEID - Permanent. Set by device or chip manufacturer. - Can=E2=80=99t be changed by subsequent owners or any in down-stream = supply chain - Akin to IDevID SUEID - Semi-permanent. Can be set by new owners of the device, down stream = entities in the supply chain and so on - Changed on major device lifecycle events - Akin to LDevID The current SUIED PR doesn=E2=80=99t allow multiple SUIED=E2=80=99s the = way you can have multiple LDevIDs. I think EAT needs to allow multiple = SUIEDs. Option 1 =E2=80=94 A simple array of SUEIDs. You can=E2=80=99t really = tell one from another or who assigned them. Option 2 =E2=80=94 Each SUEID is a pair of the SUEID plus a string = naming the entity that created it or naming a type of SEUID. Option 3 ? My understanding is that one LDevID is distinguished from another by the = issuer in the LDevID certificate. EAT doesn=E2=80=99t have these = separate certificates. EAT can use the same attestation key to sign one UEID and many SUEIDs. = EAT can also have separate attestation keys for each SUEID. It can be = used to implement the IDevID/LDevID model and/or other models. LL > On Apr 21, 2021, at 4:19 PM, Smith, Ned wrote: >=20 > It is reasonable, in the context of onboarding, where the owner = isn=E2=80=99t a supply chain entity, but the network owner who is going = to deploy / manage the device. Onboarding might involve separately = evaluating the supply chain risk and any =E2=80=98owner=E2=80=99 that = might be a supplier from onboarding processes that take a clean room = approach that wipe clean / reset to mfg defaults. > =20 > An mfg IDevID design might be such that tampering by supply chain = =E2=80=98owners=E2=80=99 would be detected and hence trusting them = isn=E2=80=99t really necessary. The end user / customer as =E2=80=98owner=E2= =80=99 might only care about trusting the IDevID mfg or only trusting = him/her self.=20 > =20 > From: Russ Housley > Date: Sunday, April 18, 2021 at 10:31 AM > To: Eliot Lear > Cc: Guy Fedorkow , "Smith, Ned" = , Henk Berkholz , = "iotops@ietf.org" , "rats@ietf.org" , = Laurence Lundblade , Ira McDonald = > Subject: Re: [Rats] 802.1AR device identity > =20 > =20 >=20 >=20 >> On Apr 18, 2021, at 9:51 AM, Eliot Lear = > wrote: >> =20 >> Signed PGP part >> Sorry for the delayed response: >>=20 >>=20 >>> On 2 Apr 2021, at 19:05, Guy Fedorkow > wrote: >>> =20 >>> Hi Laurence, >>> I agree that IDevID is intended to persist through the device=E2=80=99= s lifetime, while LDevID is meant to represent the current owner. >> =20 >> Yes, that was the original intent, and even the current intent. And = while that is necessary, it may not be sufficient for long supply chains = where ownership passes from one to another. The LDevID is an = owner-assigned name, and so the question is this: when an owner goes to = transfer, does it need to use the IDevID again or should it use the = LDevID? There are benefits and drawbacks to both, but if the LDevID is = used, then it is used as the IDevID would have been as part of that = transfer. The nice thing about FDO is that it keeps an entire record of = these sorts of transfers. > =20 > I think it depends on whether the new owner trusts the issuer of the = LDevID. If so, then leveraging the existing LDevID may be = straightforward. If the new owner does not trust the issuer of the = LDevID, then resetting the device to the factory default settings, which = would include the IDevID, makes a lot of sense. > =20 > Russ > =20 > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats --Apple-Mail=_4A1677D2-FA49-4D03-8ADF-A796DAB91517 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for all the helpful responses and info here. 

I believe the discussion = and comments received validate the EAT design of a UEID and an = SUEID.

UEID
- Permanent. Set by device or = chip manufacturer.
- Can=E2=80=99t be changed by = subsequent owners or any in down-stream supply chain
- Akin to IDevID

SUEID
- = Semi-permanent. Can be set by new owners of the device, down stream = entities in the supply chain and so on
- Changed on = major device lifecycle events
- Akin to = LDevID


The current SUIED PR doesn=E2=80=99t = allow multiple SUIED=E2=80=99s the way you can have multiple LDevIDs. I = think EAT needs to allow multiple SUIEDs.

Option 1 =E2=80=94 A simple array of = SUEIDs. You can=E2=80=99t really tell one from another or who assigned = them.

Option 2 = =E2=80=94 Each SUEID is a pair of the SUEID plus a string naming the = entity that created it or naming a type of SEUID.
Option 3 ?

My understanding is that one LDevID is = distinguished from another by the issuer in the LDevID certificate. EAT = doesn=E2=80=99t have these separate certificates.

EAT= can use the same attestation key to sign one UEID and many SUEIDs. EAT = can also have separate attestation keys for each SUEID. It can be used = to implement the IDevID/LDevID model and/or other models.

LL



On Apr = 21, 2021, at 4:19 PM, Smith, Ned <ned.smith@intel.com>= wrote:

It is reasonable, in the context of = onboarding, where the owner isn=E2=80=99t a supply chain entity, but the = network owner who is going to deploy / manage the device. Onboarding = might involve separately evaluating the supply chain risk and any = =E2=80=98owner=E2=80=99 that might be a supplier from onboarding = processes that take a clean room approach that wipe clean / reset to mfg = defaults.
 
An mfg IDevID = design might be such that tampering by supply chain =E2=80=98owners=E2=80=99= would be detected and hence trusting them isn=E2=80=99t really = necessary. The end user / customer as =E2=80=98owner=E2=80=99 might only = care about trusting the IDevID mfg or only trusting him/her self. 
 
From: Russ Housley <housley@vigilsec.com>
Date: Sunday, April 18, 2021 = at 10:31 AM
To: Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org>
Cc: Guy = Fedorkow <gfedorkow@juniper.net>, "Smith, Ned" <ned.smith@intel.com>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>, "iotops@ietf.org" <iotops@ietf.org>, "rats@ietf.org" <rats@ietf.org>, Laurence = Lundblade <lgl@island-resort.com>, Ira McDonald <blueroofmusic@gmail.com>
Subject: Re: [Rats] 802.1AR = device identity
 
 


On Apr 18, 2021, at 9:51 AM, Eliot Lear = <lear=3D40cisco.com@dmarc.ietf.org> wrote:
 
Signed PGP part
Sorry for the delayed response:


On 2 Apr = 2021, at 19:05, Guy Fedorkow <gfedorkow@juniper.net> wrote:
 
Hi Laurence,
  I agree that IDevID is intended to persist through the = device=E2=80=99s lifetime, while LDevID is meant to represent the = current owner.
 
Yes,= that was the original intent, and even the current intent.  And = while that is necessary, it may not be sufficient for long supply chains = where ownership passes from one to another.  The LDevID is an = owner-assigned name, and so the question is this: when an owner goes to = transfer, does it need to use the IDevID again or should it use the = LDevID?  There are benefits and drawbacks to both, but if the = LDevID is used, then it is used as the IDevID would have = been as part of that transfer.  The nice thing about FDO is that it = keeps an entire record of these sorts of transfers.
 
I = think it depends on whether the new owner trusts the issuer of the = LDevID.  If so, then leveraging the existing LDevID may be = straightforward.  If the new owner does not trust the issuer of the = LDevID, then resetting the device to the factory default settings, which = would include the IDevID, makes a lot of sense.
 
Russ
 
_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

= --Apple-Mail=_4A1677D2-FA49-4D03-8ADF-A796DAB91517-- From nobody Fri Apr 23 11:25:50 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6624C3A195D for ; Fri, 23 Apr 2021 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 bFRKwiigOWFL for ; Fri, 23 Apr 2021 11:25:41 -0700 (PDT) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (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 9993B3A1968 for ; Fri, 23 Apr 2021 11:25:34 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id a0UelcBjrJOFra0UflMjsC; Fri, 23 Apr 2021 11:25:34 -0700 X-CMAE-Analysis: v=2.4 cv=BYkdbph2 c=1 sm=1 tr=0 ts=6083111e a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=K6EGIJCdAAAA:8 a=QyXUC8HyAAAA:8 a=tGX7uwomAAAA:8 a=OUXY8nFuAAAA:8 a=pGLkceISAAAA:8 a=XkE9mDRChnFo0TuJXdcA:9 a=QEXdDO2ut3YA:10 a=oFKmhllnjRHI4DwAK-gA:9 a=wGtt-9eU49lps_NA:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=ZFOOzkjxzLGrPE5HuMia:22 a=cAcMbU7R10T-QSRYIcO_:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <2CF19676-0CC1-4DB3-856F-3E0513218CC0@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E4432E82-ABCE-474C-909E-B97ACAD3001A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 23 Apr 2021 11:25:32 -0700 In-Reply-To: <4A3F3EEE-23C2-4D3A-A503-C946ED772DB1@island-resort.com> Cc: Henk Birkholz , "iotops@ietf.org" , "rats@ietf.org" , Russ Housley , Eliot Lear , Ira McDonald , Guy Fedorkow To: "Smith, Ned" References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com> <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com> <2118D1F3-849F-4238-A2AE-054FF67144FF@intel.com> <4A3F3EEE-23C2-4D3A-A503-C946ED772DB1@island-resort.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfCLWFgSxuG72k0gZJAiHfPfxLjemzWQBG35ggQKRVWiL84HHxRanPZmqf65LgcwnRHgdMSHfMMjMVDXJQpRQtkqt36/nRu9PW23Bdn/hMIz7s/4tFnW/ fdE+ZjInKnRmqDip6US3t+rtojdmuSWmy+qGnRf6Mj4l6kB7a8iwsAxklr6+Ds75KqiR2R+b/bimJKXihmCUvxIAm7IOjplfgZF3IdRDX+I/qtG5ghzZAoaS ycP504YlyklOyeVCcLqJfZjoIKuVa5HqWybtAfRerCCX89R/Hp01mW5Wra515SUTbyQAHjkJ4/vxlb3+ScoU/sOtKSuoL8AMk1FAaJhRhFMX0DwZkxgjX3ho m0zJo0FKa/ujbBiSFpw5xXHk2hfxOv/pzJylQdS4hbBggwx/CHBd5rW0n/TbqhiZMGw4WY1xxiI7+2p0fzUGOPfKzWSbVA== Archived-At: Subject: [Iotops] SUIT device identifier (was Re: [Rats] 802.1AR device identity) X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:25:46 -0000 --Apple-Mail=_E4432E82-ABCE-474C-909E-B97ACAD3001A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the spirit of trying to understand use cases for UEID and SUEID I = looked at SUIT device identifiers. I also think we should consider SUIT=E2=80=99s device identifier here. = It seems like a UEID or an SUEID could be used as the SUIT = device-identifier or to derive the SUIT device-identifier. The = description of SUIT=E2=80=99s device identifier is short, but I think = all the EAT UEID types fulfills SUITs semantic requirements =E2=80=94 = uniquely identifying the device. However, they differ in syntax and mechanics. I consider UUID=E2=80=99s obsolete for many of the use cases they are = applied to. These reasons are carefully described in Appendix B of EAT = . = Basically with the wide availability of good crypto-quality RNG=E2=80=99s,= the techniques UUID specifies are unnecessary and a burden. I think = SUIT device identifier is one of the use cases. Also, UUID=E2=80=99s are confusing because not all types can be used for = all use cases. My suggestion to solve this would be to make SUIT device identifiers = just byte strings that can be 128, 192 or 256 bits long. SUIT removes = the UUID format requirement for device identifiers. Then a type 1 UEID could just be used as is for a SUIT device = identifier.=20 Type 2 (MAC) and type 3 (IMEI) UEIDs could be run through a hash to make = a SUIT device identifier. If EAT were further along as a standard, I=E2=80=99d suggest SUIT just = used UEID, but I don=E2=80=99t think we want SUIT to become dependent on = EAT. What I=E2=80=99m proposing here gives a soft coupling. LL > On Apr 23, 2021, at 11:16 AM, Laurence Lundblade = wrote: >=20 > Thanks for all the helpful responses and info here.=20 >=20 > I believe the discussion and comments received validate the EAT design = of a UEID and an SUEID. >=20 > UEID > - Permanent. Set by device or chip manufacturer. > - Can=E2=80=99t be changed by subsequent owners or any in down-stream = supply chain > - Akin to IDevID >=20 > SUEID > - Semi-permanent. Can be set by new owners of the device, down stream = entities in the supply chain and so on > - Changed on major device lifecycle events > - Akin to LDevID >=20 >=20 > The current SUIED PR doesn=E2=80=99t allow multiple SUIED=E2=80=99s = the way you can have multiple LDevIDs. I think EAT needs to allow = multiple SUIEDs. >=20 > Option 1 =E2=80=94 A simple array of SUEIDs. You can=E2=80=99t really = tell one from another or who assigned them. >=20 > Option 2 =E2=80=94 Each SUEID is a pair of the SUEID plus a string = naming the entity that created it or naming a type of SEUID. >=20 > Option 3 ? >=20 > My understanding is that one LDevID is distinguished from another by = the issuer in the LDevID certificate. EAT doesn=E2=80=99t have these = separate certificates. >=20 >=20 > EAT can use the same attestation key to sign one UEID and many SUEIDs. = EAT can also have separate attestation keys for each SUEID. It can be = used to implement the IDevID/LDevID model and/or other models. >=20 > LL >=20 >=20 >=20 >> On Apr 21, 2021, at 4:19 PM, Smith, Ned > wrote: >>=20 >> It is reasonable, in the context of onboarding, where the owner = isn=E2=80=99t a supply chain entity, but the network owner who is going = to deploy / manage the device. Onboarding might involve separately = evaluating the supply chain risk and any =E2=80=98owner=E2=80=99 that = might be a supplier from onboarding processes that take a clean room = approach that wipe clean / reset to mfg defaults. >> =20 >> An mfg IDevID design might be such that tampering by supply chain = =E2=80=98owners=E2=80=99 would be detected and hence trusting them = isn=E2=80=99t really necessary. The end user / customer as =E2=80=98owner=E2= =80=99 might only care about trusting the IDevID mfg or only trusting = him/her self.=20 >> =20 >> From: Russ Housley > >> Date: Sunday, April 18, 2021 at 10:31 AM >> To: Eliot Lear > >> Cc: Guy Fedorkow >, "Smith, Ned" >, Henk Berkholz = >, "iotops@ietf.org = " >, = "rats@ietf.org " >, Laurence Lundblade >, Ira McDonald > >> Subject: Re: [Rats] 802.1AR device identity >> =20 >> =20 >>=20 >>=20 >>> On Apr 18, 2021, at 9:51 AM, Eliot Lear = > wrote: >>> =20 >>> Signed PGP part >>> Sorry for the delayed response: >>>=20 >>>=20 >>>> On 2 Apr 2021, at 19:05, Guy Fedorkow > wrote: >>>> =20 >>>> Hi Laurence, >>>> I agree that IDevID is intended to persist through the device=E2=80= =99s lifetime, while LDevID is meant to represent the current owner. >>> =20 >>> Yes, that was the original intent, and even the current intent. And = while that is necessary, it may not be sufficient for long supply chains = where ownership passes from one to another. The LDevID is an = owner-assigned name, and so the question is this: when an owner goes to = transfer, does it need to use the IDevID again or should it use the = LDevID? There are benefits and drawbacks to both, but if the LDevID is = used, then it is used as the IDevID would have been as part of that = transfer. The nice thing about FDO is that it keeps an entire record of = these sorts of transfers. >> =20 >> I think it depends on whether the new owner trusts the issuer of the = LDevID. If so, then leveraging the existing LDevID may be = straightforward. If the new owner does not trust the issuer of the = LDevID, then resetting the device to the factory default settings, which = would include the IDevID, makes a lot of sense. >> =20 >> Russ >> =20 >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats = > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats --Apple-Mail=_E4432E82-ABCE-474C-909E-B97ACAD3001A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
In the spirit of trying to understand use cases for UEID and = SUEID I looked at SUIT device identifiers.

I also think we should consider = SUIT=E2=80=99s device identifier here. It seems like a UEID or an SUEID = could be used as the SUIT device-identifier or to derive the SUIT = device-identifier. The description of SUIT=E2=80=99s device identifier = is short, but I think all the EAT UEID types fulfills SUITs semantic = requirements =E2=80=94 uniquely identifying the device.

However, = they differ in syntax and mechanics.

I consider UUID=E2=80=99s obsolete for = many of the use cases they are applied to. These reasons are carefully = described in Appendix B of EAT. Basically with the wide availability = of good crypto-quality RNG=E2=80=99s, the techniques UUID specifies are = unnecessary and a burden.  I think SUIT device identifier is one of = the use cases.

Also, UUID=E2=80=99s are confusing because not all types can = be used for all use cases.

My suggestion to solve this would be to make SUIT device = identifiers just byte strings that can be 128, 192 or 256 bits long. = SUIT removes the UUID format requirement for device = identifiers.

Then a type 1 UEID could just be used as is for a SUIT device = identifier. 

Type 2 (MAC) and type 3 (IMEI) UEIDs could be run through a = hash to make a SUIT device identifier.

If EAT were further along as a = standard, I=E2=80=99d suggest SUIT just used UEID, but I don=E2=80=99t = think we want SUIT to become dependent on EAT. What I=E2=80=99m = proposing here gives a soft coupling.

LL



On Apr 23, 2021, at 11:16 AM, = Laurence Lundblade <lgl@island-resort.com> wrote:

Thanks for all the = helpful responses and info here. 

I believe the discussion and comments = received validate the EAT design of a UEID and an SUEID.

UEID
- Permanent. Set by device or = chip manufacturer.
- Can=E2=80=99t be changed by = subsequent owners or any in down-stream supply chain
- Akin to IDevID

SUEID
- = Semi-permanent. Can be set by new owners of the device, down stream = entities in the supply chain and so on
- Changed on = major device lifecycle events
- Akin to = LDevID


The current SUIED PR doesn=E2=80=99t = allow multiple SUIED=E2=80=99s the way you can have multiple LDevIDs. I = think EAT needs to allow multiple SUIEDs.

Option 1 =E2=80=94 A simple array of = SUEIDs. You can=E2=80=99t really tell one from another or who assigned = them.

Option 2 = =E2=80=94 Each SUEID is a pair of the SUEID plus a string naming the = entity that created it or naming a type of SEUID.
Option 3 ?

My understanding is that one LDevID is = distinguished from another by the issuer in the LDevID certificate. EAT = doesn=E2=80=99t have these separate certificates.

EAT= can use the same attestation key to sign one UEID and many SUEIDs. EAT = can also have separate attestation keys for each SUEID. It can be used = to implement the IDevID/LDevID model and/or other models.

LL



On Apr 21, 2021, at 4:19 PM, Smith, Ned <ned.smith@intel.com>= wrote:

It is reasonable, in the context of = onboarding, where the owner isn=E2=80=99t a supply chain entity, but the = network owner who is going to deploy / manage the device. Onboarding = might involve separately evaluating the supply chain risk and any = =E2=80=98owner=E2=80=99 that might be a supplier from onboarding = processes that take a clean room approach that wipe clean / reset to mfg = defaults.
 
An mfg IDevID = design might be such that tampering by supply chain =E2=80=98owners=E2=80=99= would be detected and hence trusting them isn=E2=80=99t really = necessary. The end user / customer as =E2=80=98owner=E2=80=99 might only = care about trusting the IDevID mfg or only trusting him/her self. 
 
From: Russ Housley <housley@vigilsec.com>
Date: Sunday, April 18, 2021 = at 10:31 AM
To: Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org>
Cc: Guy = Fedorkow <gfedorkow@juniper.net>, "Smith, Ned" <ned.smith@intel.com>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>, "iotops@ietf.org" <iotops@ietf.org>, "rats@ietf.org" <rats@ietf.org>, Laurence = Lundblade <lgl@island-resort.com>, Ira McDonald <blueroofmusic@gmail.com>
Subject: Re: [Rats] 802.1AR = device identity
 
 


On Apr 18, 2021, at 9:51 AM, Eliot Lear = <lear=3D40cisco.com@dmarc.ietf.org> wrote:
 
Signed PGP part
Sorry for the delayed response:


On 2 Apr = 2021, at 19:05, Guy Fedorkow <gfedorkow@juniper.net> wrote:
 
Hi Laurence,
  I agree that IDevID is intended to persist through the = device=E2=80=99s lifetime, while LDevID is meant to represent the = current owner.
 
Yes,= that was the original intent, and even the current intent.  And = while that is necessary, it may not be sufficient for long supply chains = where ownership passes from one to another.  The LDevID is an = owner-assigned name, and so the question is this: when an owner goes to = transfer, does it need to use the IDevID again or should it use the = LDevID?  There are benefits and drawbacks to both, but if the = LDevID is used, then it is used as the IDevID would have = been as part of that transfer.  The nice thing about FDO is that it = keeps an entire record of these sorts of transfers.
 
I = think it depends on whether the new owner trusts the issuer of the = LDevID.  If so, then leveraging the existing LDevID may be = straightforward.  If the new owner does not trust the issuer of the = LDevID, then resetting the device to the factory default settings, which = would include the IDevID, makes a lot of sense.
 
Russ
 
_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

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

= --Apple-Mail=_E4432E82-ABCE-474C-909E-B97ACAD3001A-- From nobody Sun Apr 25 05:53:32 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF303A0E8D; Sun, 25 Apr 2021 05:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 v1IzCMz4lKoE; Sun, 25 Apr 2021 05:53:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBD83A086E; Sun, 25 Apr 2021 05:53:25 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FSnyB6VkJzyWV; Sun, 25 Apr 2021 14:53:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> Date: Sun, 25 Apr 2021 14:53:22 +0200 Cc: IOTOPS Working Group X-Mao-Original-Outgoing-Id: 641048002.3356479-40022afaa5813ce7c60619998c85bab4 Content-Transfer-Encoding: quoted-printable Message-Id: <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> To: "iotops-chairs@ietf.org" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2021 12:53:31 -0000 Can=E2=80=99t find the recording. Do you have a pointer? Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Apr 25 08:05:08 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7433A1511; Sun, 25 Apr 2021 08:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fraunhofer.onmicrosoft.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 zVo-lwUSG-V7; Sun, 25 Apr 2021 08:05:03 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 41CE03A150D; Sun, 25 Apr 2021 08:05:01 -0700 (PDT) IronPort-SDR: mBuVY6a1X7gKSq3yhPezBzt8+0+hzHn/96/PaDzqKPr4q/9lmiFlrfBvc9WgpyJBb4O60w3YiK w6lbaFMzOY00yo5+89qiTvPquL3VDnHkSpGp9nmV3HZTNWwItoWtXzJuE8kpezT+9qrkh/C6KW NwmiyUsf//84v3SV3u59EWDy81eYjn+dEdk4wQRRz8EFjfEuTt7GoYEPOzhBEeMLqlNVbwQq3m lHaui/LZ/xb8MWu+vqAEbZTVm+0rUydGu29cOr85HL01OQkoix5g88TnI8R3n+T0mAYRvlnSzS I4Y= IronPort-PHdr: =?us-ascii?q?A9a23=3AprpAFR9a6XTBjf9uWNvoyV9lXQAupqn0MwgJ6?= =?us-ascii?q?5Eul7NJdOG58o//OFDEjd1sgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBH?= =?us-ascii?q?xkClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHH?= =?us-ascii?q?BL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZpLQnwox/Yq88WhoVvMOA9x?= =?us-ascii?q?0ihnw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FaAQADhIVg/xmnZsBaGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFSAoFRUYI/C4Q4g0kBAYU5iD0wkHmISYE?= =?us-ascii?q?vgSQDVAsBAQEBAQEBAQEIATICBAEBAwOESgI1gUYBJUsCAwEBDAEBBgEBAQE?= =?us-ascii?q?BBgQCAoEAhVANQwEQAYMAgQgBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEFAjVTPgEFIw8BBQgBATcBDwkCDgoCAiYCAjIlBgEMAQcBAYJ?= =?us-ascii?q?tglYDLgEBA4takG0CixmBMoEBggQBAQaCTIJMGFiBOwkJAYEGKgGCeIZLhBM?= =?us-ascii?q?nEIFVQoE6D4FTgRk+gQSGVYJhwUYsB4F0gR2BIQYLm10FCyGDPwGQegaQUJU?= =?us-ascii?q?no00CBAIEBQIOAQEGNYE5BIF2TSSDOFAXAg6OHxeDWYpfcTgCBgEJAQEDCQF?= =?us-ascii?q?aIYJoiBsBgRABAQ?= X-IPAS-Result: =?us-ascii?q?A2FaAQADhIVg/xmnZsBaGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFSAoFRUYI/C4Q4g0kBAYU5iD0wkHmISYEvgSQDVAsBAQEBA?= =?us-ascii?q?QEBAQEIATICBAEBAwOESgI1gUYBJUsCAwEBDAEBBgEBAQEBBgQCAoEAhVANQ?= =?us-ascii?q?wEQAYMAgQgBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFA?= =?us-ascii?q?jVTPgEFIw8BBQgBATcBDwkCDgoCAiYCAjIlBgEMAQcBAYJtglYDLgEBA4tak?= =?us-ascii?q?G0CixmBMoEBggQBAQaCTIJMGFiBOwkJAYEGKgGCeIZLhBMnEIFVQoE6D4FTg?= =?us-ascii?q?Rk+gQSGVYJhwUYsB4F0gR2BIQYLm10FCyGDPwGQegaQUJUno00CBAIEBQIOA?= =?us-ascii?q?QEGNYE5BIF2TSSDOFAXAg6OHxeDWYpfcTgCBgEJAQEDCQFaIYJoiBsBgRABA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.82,250,1613430000"; d="scan'208";a="32301297" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2021 17:04:57 +0200 IronPort-SDR: 3EKWBIN675aH2khHCNfSJDlyg3wUsvHNsCV9KbgvRBXjmA/VJAF32ugUQPYIG3u4KoYUec791o timCMQyrIChcaMBxubCJ3ChWRiRNopxnU= IronPort-PHdr: =?us-ascii?q?A9a23=3AzGdDohAxTXzFyxlqjf4KUyQVlhdPi93PFgcI9?= =?us-ascii?q?poqja5Pea2//pPkeVbS/uhpkEShdYTW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBT?= =?us-ascii?q?AQMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeH?= =?us-ascii?q?xzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+B7Qqo8Ym4J/LKY2x?= =?us-ascii?q?BbT5HdFKIxr?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AKzz+aqE/lmpyaup2pLqFYZTXdLJzesId70?= =?us-ascii?q?hD6mlYcjYQWtCElsyogfQQ3QL1jjFUY307hdWcIsC7Lk/03aVepa0cJ62rUg?= =?us-ascii?q?WjgmunK4l+8ZDvqgeNJwTXzcQY76tpdsFFZeHYJURmjMr8/QmzG8shxt7Cy6?= =?us-ascii?q?yzmeLC1R5WLD1CQYsI1XYcNi+wFEpqSA5aQb8wE5SB7sRKzgDQBUg/RMK9G3?= =?us-ascii?q?UDQqz/vNXNjp3relorABQg5QmIg1qTmcHHOjKf2QoTVC4K/Kc6/QH+4nHEz4?= =?us-ascii?q?iAk9X+8B/T0GfP849b8eGO9vJvDNGB4/JlUgnEpR2vYO1aKtu/lRAz5Nqi8V?= =?us-ascii?q?M71OTLyi1QRfhbz1P0UiWLrQD22w/muQxemEPK7VODm3PsrYjYaVsBerN8rL?= =?us-ascii?q?lUeBfY9EYs1esUuMkgvxP7xu9qJCjNkyjn69/DWwsCrDvSnVMYnfMOlHsaaI?= =?us-ascii?q?MCadZq3Pwi1XlIG5QNFj+S0vFELMBSCqjnlZNrWG+BY2uclmdix8HEZAVJIj?= =?us-ascii?q?62BmIGusCTzgFMmmF4w0Yy1KUk7wY93aN4ZJ9e6+veNKN00JlIU88NdKp4QN?= =?us-ascii?q?wMWM2tFwX2MF7xGVPXBW6iOLAMOnrLpZKyyLIp5NuycJhN6JcpgpzOXH5RqG?= =?us-ascii?q?ZaQTOgNeS+mLlwtjzdSmS0WjrgjutE4YJih7H6TL33dQWeVVEHiaKb0rUiK/?= =?us-ascii?q?yef8z2FINdAvflI2erM51OxRfCV55bLmRbeNEJu+w8R0mFrqvwW8zXn92eVM?= =?us-ascii?q?yWCKvmED4iVG+6KGAERiLPKMJJ6V3udWT/hDTXRnPxam3y9Z99C8Hhjqou4b?= =?us-ascii?q?lIErcJnhkeiFy/6M3OAyZFqLYKcEx3J66isq7TnxjywU/4q0FSfjZNBEdc57?= =?us-ascii?q?vtF1lQoxURDk/yebEf//GWeWVY2mq7NgZyJvmmVDJ3lhBSw+aaPpaQzSctB5?= =?us-ascii?q?aMKWSBlUYeo3qMUtM6lrCc49zmPrc1FIwvVqA0NQijLW06pS9a7EN4LCMUTE?= =?us-ascii?q?7WET3jzY+/ioYPOe3Zf95gxCGxIcBVrnrbnV6Gpd4mQ0YaWzLGa7/VvS8eAx?= =?us-ascii?q?5vwnFh+a4Wh7SN3Ry1L3Ekveg+OFpQLFiMDKl+FwSDboVMkrXNcAV9JF36wg?= =?us-ascii?q?CyulUWQC7H5k8SjmvuIWmxdevQClRQgHxez53n6Uh5bGmbYkJ2ZE1rqIEVLx?= =?us-ascii?q?W1hl9DlcuwIoaj2WqYbVUPhtsQNzzIehM+CAJjzdLf7m/fpB+yUVEdgrk+NO?= =?us-ascii?q?3UC7ouN4zJ0nS2MYuSiOUtBPlP5qtoM9jor84GWe+SYBWuMTv9Eu8lsjbl4E?= =?us-ascii?q?oNCW1Rkj0Dnvzp0hG+szT98347HPbIIFNpA5scOMqR6mD4R/COlLV15OhFyt?= =?us-ascii?q?eYAyHUUJqhz6qSUhtobjX0ikSyR/szqZ9Vsbkp3YEDV6XzYH/t7jV/wB46LM?= =?us-ascii?q?3Ij0sQT6Rw3aDZNuZUDrgvUhMc2mBsqc+GI0QquDHnG+MSfVkiiHnAItOCio?= =?us-ascii?q?C434YHMwmkpAHqP0OY/DAY1/DZXzGb3bpyMdN7HU1mLGw94m9l5uWMasn5Dx?= =?us-ascii?q?irbfhK+B6fPmWmeLFQDIiDFrN4lGc23/i428uWfTH/wgbeoH9SJb9P6X+uRY?= =?us-ascii?q?eKOz23cNQ4uuCSCBCrmaul4Mm6kTfxR3+aUi0j9PN4XH1VSN9ChDkkhJAwyQ?= =?us-ascii?q?6oRMXM0xsYr2c=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSCAA4hIVg/z6wYZlaGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQAmBSQKBUVEHgVEkQwuEOINJAQGFOYZMgXA?= =?us-ascii?q?wOAGQQIhJgS+BJANUCwEDAQEBAQEIATEBAgQBAYRQAjWBQwImSwIDAQEMAQE?= =?us-ascii?q?FAQEBAgEGBHEThVANQwEBAQMHBIVxAQUjDwEFCAEBFCMBDwkCDgoCAiYCAjI?= =?us-ascii?q?HHgYBDAEHAQGCbYJWAy4CA4takG0CixmBMoEBggQBAQaCTIJMGFiBOwkJAYE?= =?us-ascii?q?GKgGCeIZLhBM3gVVCgToPgVOBGT6BBIZVgmHBRiwHgXSBHYEhBgubXQULIYM?= =?us-ascii?q?/AZB6BpBQlSejTQIEAgQFAg4BAQY1gTkEHIFZTSSDOFAXAg6OHxeDWYpfcTg?= =?us-ascii?q?CBgEJAQEDCQFYAQEhgl8JiBsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.82,250,1613430000"; d="scan'208";a="109508594" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO mobile.exch.fraunhofer.de) ([153.97.176.62]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2021 17:04:54 +0200 Received: from XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Sun, 25 Apr 2021 17:04:53 +0200 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5 via Frontend Transport; Sun, 25 Apr 2021 17:04:53 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aMlKLUW/LAAd3acxZKwrbnKmgMHTUqs2WswSAOjarywio0uGCeCnq6Cl05yoeqUUh5WNCzHAeHKZB/gWZowYuFYB76+oUQJFqqBt+vZDn8D5ri7b1H3vTQWrTxrWVByyfhLaf1LZwckMmI1/m8QtQoxVJncf6t0Wtv2h1wPNx40p1plAm6ANMGtp1mNW34ehTpHS3Ud6fIa9wV81CT/ctgcJTE+CtDT2feVxLhQ/65u/+oBvp3FappfHcd977nzBOzYUzeMcnjaxNESJ33DCg4FvilB8lIPyAWeoQRH1A/4pN27D8MdtuDCtFgEyj+Vwin0/tsjwBYUe1DKwW50xEQ== 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=VozzLhtLWWMZL13UCpV5b5uvGULvVdRwDlhQ11jt89g=; b=bzQqYHhnLlwvUvgzbt8OLgVda3zYLasOfpwvTekOVwxZTHCcb35tdh1GyxXZeTHue/OrMBaD1sKn2siQW5WvtYy/Mz5CIACktt4WGUuNC0h8yMIugxk3Wx1+0zU2nErj9v5kBhjsWxiXT+Wmau/USVj0ByiNcO4mhyxD1vQixabtNb0XNqIanJwswFw923Y0uenWNIJP57nFMWxLmu1p9O/HSeRqXGrEe3+5kDVFR/SpBep3sr06jHfear5mHCdUhMI5lRMXlF8aHYJ2z7kR/Pqly66cbbeU7TFf+1avPdMOuRapUzx9UkTlIKkt+ScVNZSdVEG2WjMVd5UjWX2f/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VozzLhtLWWMZL13UCpV5b5uvGULvVdRwDlhQ11jt89g=; b=KY71DVhPy34NcBTRFoWyjN4Vur+Qck9NW/xRrfOFYVantPFr0Y+83/8bAsvXULYLWZ0oVJFVM6itICfDFRy4sk3AsWib1CFDf5mAYGlrs6MTwESwhJ+bDyaZdMuaEbs4xhdrz4psYJB1gJ5shQ8u28Z7+siBdzpm5xw6oK1cHF0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by DB8P194MB0823.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:169::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20; Sun, 25 Apr 2021 15:04:52 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0%4]) with mapi id 15.20.4065.026; Sun, 25 Apr 2021 15:04:52 +0000 To: Carsten Bormann , "iotops-chairs@ietf.org" CC: IOTOPS Working Group References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> From: Henk Birkholz Message-ID: <2ff6d960-f652-dff8-bb85-f59bded4fb9e@sit.fraunhofer.de> Date: Sun, 25 Apr 2021 17:04:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.119.37] X-ClientProxiedBy: PR0P264CA0103.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:19::19) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.234.119.37) by PR0P264CA0103.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:19::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22 via Frontend Transport; Sun, 25 Apr 2021 15:04:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e5cac5af-59b2-4708-607a-08d907fb7a80 X-MS-TrafficTypeDiagnostic: DB8P194MB0823: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2733; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PfqfeYQ4BXQ/F1uAIcoj/CZWNohJmykGmqIGPetKAiE9Z+t2Nl2N6Ddj0ABzywZjJ16VQYCdiFezU6gQK/efaGIiLHH9utd64oe0MP+9/PF73N0cKjBYs9Bbt1zJWxZxQCjS8s0o+UXGZYot8ZDiIqGQyBT6n9MzSY1DezRZK7PYQ1Pa4NXyiAX4oVkbC/2aPSUcKpeHhHwN7TBJyL1mRk4ioptq9XL73hVIfASK9cOZzVlsUkJWJyPPZ+iJsvhFgOSR7WheUq/CyG3dwB9il7OrFS4AQs5R0ZGQn1tEHYoMq2uLtjziKC0nqHu32q9HVwDBmwbdtFevpaUeW5blkg8Le/y3YfkGq8OXK6oYXRWrhDgOBf2RS+z+m+qNbSmvQ+LobAa8rlBqoGMeeYGmpWFh/98iv/hQzM+xBiWKoUfsMVvZsJTE9/pfa4VXyAJj1Cl9WaJBYJhv+WtX1fSBUBI1k1kEE7rUFoZrFRMc+IyxGZD9jyp8mjb3WjnK06ihbaxU7Nb+6CpOqxwlXlmJr5FZ90pbKep/rRvs/ZdqhXEtNfMImj2IqX2AkmiVVrj+Zi9U2slDYnbsMaF7Gg12AMJy5RNgE/iMmUtaPZjlA8lUST7jNvjP33iYHaCbluDM8FgHq9eLJd3maxutgSeb5qdYK0TQcSfT5tnCvy/+ywHQGR4yxXgIhtZCtqevAJCsqCwob8aQBUE6+GTh5embpg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(396003)(346002)(376002)(136003)(366004)(53546011)(52116002)(6486002)(558084003)(83380400001)(66556008)(31696002)(86362001)(66476007)(44832011)(66946007)(186003)(2906002)(26005)(5660300002)(16526019)(8936002)(38100700002)(38350700002)(478600001)(16576012)(110136005)(4326008)(31686004)(956004)(2616005)(316002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Wm13bXpaL0tMaVZpQlBtU2FMVDZRbG9qWHZ5UEhUbU82ZnExei91b1BSRkRn?= =?utf-8?B?dFkxVGcyRTVKOU5MR092OEZRUGtJa1cvTUt1K0xBWXdyblcyRmpRVnlMZVAz?= =?utf-8?B?aFpLOThVOWVTN3UyanBIQ2p0YythMzd2RDVTN2FKUFdjTkl4WGsrZXE4b3Ba?= =?utf-8?B?MGNHVnhhVDhkUWpJVGNCM3VONjFpa1dWY05KRVdSN1BaaUw4VlJaVzNYNVRy?= =?utf-8?B?cWZSNjI2ZjlUK0tZdHUxYVJ1Skdjbk5rRVZ6cDltSysvWkV3WTg4MGd6emtG?= =?utf-8?B?S2lhR3c4dy92ZFB0TlE5T2g2YlBTaWhUb0N6cnpWajgra0xybDJqUm5RV3BY?= =?utf-8?B?WkVnQ1hsRC9TV1RScTFBeUNsWVNpa3VGRmdGMHdjb0lrSUZ1a0NKTHRRSEtv?= =?utf-8?B?RE11T1N0blBENXlBMlhFbjhrd2ZieDlVQzU4ZTQ5S2I5Wm4xYkNQYUp3b1Z2?= =?utf-8?B?azBVUkNtUzBXNW1PTUZoZThxUEhxeUpEdUF1TjZ6UHNwK3NYU1RKWFE4cFlN?= =?utf-8?B?TU1XNWJ6N29nNU5NQ3RiNExqZExUdzJieGZvSmtEK25vaG9WWDNLcEdiOUhz?= =?utf-8?B?bjRNeGV1MGN2Wk83Q09nOGRaNTJiN29teTlDdW5jdTVlQlAyUEt3cGxsWWRB?= =?utf-8?B?L28wOXZrWFEwZjRjcUFjYjRNbTlhTHNmWDFPRDFUakQreWU0U1o5QXNnL1cx?= =?utf-8?B?c1FuN3VqaVlWbENVK211RldpZUdEU0NGd1hWSGZSZW5YdXA1V3V6VmNxSS9E?= =?utf-8?B?elFsVUZGVlV6dlRrNmMvbGQ1ZzFmUTE0NEErZUs2bXhNQlgwamlzN0JEMnNl?= =?utf-8?B?YVFWQmplQko3eWVJVTNWZXpyQlhhbGRZT01rYm12R1pyNmZXQnUxdFArODBo?= =?utf-8?B?UWlDcmszbW4xUUhxOGl0ME03aDIyQWgrQ056UGxQTDQrNFZkWVJZTFY3L25X?= =?utf-8?B?MmE1aVFyc0FZaWlNV3c0Mk1vSGw3WGUrWkpFb29kYmNnNUliTFRjaHlYSjFH?= =?utf-8?B?c2Z6bnFTanJEUDJza2dwWnlwVEJ5NHE2d1prR3JrY2l5OEVxakRTKy9RdGV2?= =?utf-8?B?WVVWNUd4R3hySEdKMU9CaWlEWEdUMGtNQkdrdW02aW8xOWFXL29zR3lmclI1?= =?utf-8?B?UWJoVSt0OGU2bTlhRGFmYVRNYTJ4azJkbTNQQmtudk9KdDN0ZENYQ1dTVEx0?= =?utf-8?B?WUN4NnMwcHNBRXRaS2JoK24wcU8zK2RDZHpRSGVGblo4RHlUVndZYlErekNS?= =?utf-8?B?UTYrMnh1aWFmL1ZTNWJuR0hKV0phUU5nclRHeUM4STJITmdONW03UHZybFQw?= =?utf-8?B?VmJZR3hDMHIxOVE2a05ycGV1MnZhcGJaOTM0cGd6WFZ3Sy91SUt2M2hLa0pU?= =?utf-8?B?c2Z2UUtiM011bWQzTjdQRk1aV3c2N2szKzVsczJRYWpiQmtrc2NtQzRESUtO?= =?utf-8?B?bVNmSmhHalhXeTNUY2pLM3hCRkFBQm9HUGo0S042LzhhTHJoWjU3S0tOcHlk?= =?utf-8?B?OS81MFNBMVU0dVNqNXhHTU8wbVZxTVpoM3lWVE9STldsd2QwcjRBVzVuaCtm?= =?utf-8?B?RjI2cUVnbE45VGNvbVhBWWJOams0dEJWSHpkcTdFQkxyMkZseHZER1FNUDlP?= =?utf-8?B?bys2Qm0vR2JMa3NwamJ0ZXI5NStsdU5LY1NUQkR3RFI3T2tSakVwTDhONXBD?= =?utf-8?B?c0pyT3lWd3V5V1BKWm1mSklrZjhhZG5kakNneVlNVzNDSVNPQ0lIS3NQVWFI?= =?utf-8?Q?YHnC9+lf9dF4ckhO+GcquC5Y3qki3WKCiijYqEs?= X-MS-Exchange-CrossTenant-Network-Message-Id: e5cac5af-59b2-4708-607a-08d907fb7a80 X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2021 15:04:52.4389 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: S1bRnR82Od8vMLikjfNtrVEyVfQYbAJYwns57kzLUFdk7qbWB+dnPK8oBk0Qi5894bFw6nZ+HAnDVHSK5XYBRWIOR7I37KrDvOTJBNsk1oo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P194MB0823 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2021 15:05:06 -0000 Hi Carsten, I can't fond anything either. I'll ask secretary and will come back to this! Viele Grüße, Henk On 25.04.21 14:53, Carsten Bormann wrote: > Can’t find the recording. > > Do you have a pointer? > > Grüße, Carsten > From nobody Sun Apr 25 17:39:05 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E53A0AA6; Sun, 25 Apr 2021 17:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 a6NjFnZOY3aw; Sun, 25 Apr 2021 17:38:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA923A0A9C; Sun, 25 Apr 2021 17:38:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BDA9538BB6; Sun, 25 Apr 2021 20:46:55 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vABCaBgxaWQC; Sun, 25 Apr 2021 20:46:55 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ECD0238BB5; Sun, 25 Apr 2021 20:46:54 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2ABF3486; Sun, 25 Apr 2021 20:38:56 -0400 (EDT) From: Michael Richardson To: Henk Birkholz cc: Carsten Bormann , "iotops-chairs\@ietf.org" , IOTOPS Working Group In-Reply-To: <2ff6d960-f652-dff8-bb85-f59bded4fb9e@sit.fraunhofer.de> References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> <2ff6d960-f652-dff8-bb85-f59bded4fb9e@sit.fraunhofer.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 00:39:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Henk Birkholz wrote: > I can't fond anything either. I'll ask secretary and will come back t= o this! Henk, you should be able to find a URL on the webex site that can be shared. The secretariat takes ~week to get through them all. It also could be that, given the mis-settings that record was not pressed? I usually set the meetings up to auto-record. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCGC58ACgkQgItw+93Q 3WX+4gf8DXQWHfg9f/iryKfQQ2n/CUe/Ctf1vtqGB6NmlGj8kaSQfvAEyrlIQdYB w1ecRaMudQjrHDZGfMQV4TSgb8IKgdnRdeqKgnwztS6eMAY6cP7ohGoLAGcNlRAb 1x7CAYpXoQ4Npsa2ypcvsL6jDuHqiQuYCMH/6pHXvZkoIIgTQP+d/kN/JLgGOS/m RLRadsTQ9+c5923mhHqbu/0oVovPjbh3uDvvFp1+2YE7i3DlJAKCFJYVMz3M8ir4 PqThVctKBi7nveo4BRb2t7stQf3VaCRh2su6whJfPSUo5wv+48HOon7gfmQv3/+w 76WFPeC/E3Nc+XOx4HcXKw9uafBj8A== =XH3D -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 25 22:38:15 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036E93A085C; Sun, 25 Apr 2021 22:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fraunhofer.onmicrosoft.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 EevTCQt6yiKo; Sun, 25 Apr 2021 22:38:09 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 683EF3A0857; Sun, 25 Apr 2021 22:38:07 -0700 (PDT) IronPort-SDR: YdAKBWj4snqyxmlAw25UbOIEuj2bZ8KObjOnqcEEYSjof7noI9kPaKfWQmxZ8QCFkE62eaLHga m5TARWe0sKag== IronPort-PHdr: =?us-ascii?q?A9a23=3AfFJnPhRYxJzbA0axWmeBZaZrgtpso0XLVj590?= =?us-ascii?q?bIulq5Of6K//p/rIE3Y47B3gUTUWZnAg9pFhvbY9af6Vj9I7ZWAtSUEd5pBH?= =?us-ascii?q?18AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Tr2G8qzkIF?= =?us-ascii?q?Ua3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wNgJckJLw41?= =?us-ascii?q?x3JpXVFYaJayDAAGA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FQAgAvUYZg/xwBYJlaGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBUgKBUVGCPwuEOINJAQGFOYg8MJlCglMDVAsBAQE?= =?us-ascii?q?BAQEBAQEIATICBAEBAwOBVYJ1AjWBRgElSwIDAQEMAQEGAQEBAQEGBAICgQC?= =?us-ascii?q?FUA1DARABgwCBCAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQUCNVM+AQUjDwEFCAEBNwEPCQIYAgImAgIyJQYKAwEFAgEBgm2CVgMuAgO?= =?us-ascii?q?NP5BtAosZgTKBAYIEAQEGgkyCTRhYgTsJCQGBBioBgniGS4QTJxCBVUKBOg+?= =?us-ascii?q?BU4EZPoEEhlWCYYVwT7sHLAeBdIEdgSEGC5tdBQshlDoGkFC4dAIEAgQFAg4?= =?us-ascii?q?BAQY1gTeBfE0kgzhQFwIOjh8Xg1mKX3ECNgIGAQkBAQMJAVohgXmJCgGBEAE?= =?us-ascii?q?B?= X-IPAS-Result: =?us-ascii?q?A2FQAgAvUYZg/xwBYJlaGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBUgKBUVGCPwuEOINJAQGFOYg8MJlCglMDVAsBAQEBAQEBAQEIATICB?= =?us-ascii?q?AEBAwOBVYJ1AjWBRgElSwIDAQEMAQEGAQEBAQEGBAICgQCFUA1DARABgwCBC?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCNVM+AQUjD?= =?us-ascii?q?wEFCAEBNwEPCQIYAgImAgIyJQYKAwEFAgEBgm2CVgMuAgONP5BtAosZgTKBA?= =?us-ascii?q?YIEAQEGgkyCTRhYgTsJCQGBBioBgniGS4QTJxCBVUKBOg+BU4EZPoEEhlWCY?= =?us-ascii?q?YVwT7sHLAeBdIEdgSEGC5tdBQshlDoGkFC4dAIEAgQFAg4BAQY1gTeBfE0kg?= =?us-ascii?q?zhQFwIOjh8Xg1mKX3ECNgIGAQkBAQMJAVohgXmJCgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.82,251,1613430000"; d="scan'208";a="42187392" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 07:38:04 +0200 IronPort-SDR: jmGBYeJlt9ve4iWD33gUfB3WZmIxGNiQ51/rKtUT9qORu+cKaEEe0dRl3bWyIJ1PQ9KDz9g/cp kSl9PYcrnsIIwE9EgjYyua/XhbpuhjEmpxYKVWqs2rFIdCQZd1BbhXSosNeW0mICYYh15FA4xl WvzXyPWspGhOVKB0IehU8bzgSLhhRyayMrL5T1kLZ/LM9sZnv/Sg9VkbdMP/XcXWf54Q4thVIh lZxR9UiS2d4sFm1K3tUPYRVoZlh1mwMx393TH1diXNe89zXe6M9bglZC9GFNl4gagye4zqBHh8 87VGjrM2QT6+CzxaEKuFw6Dl IronPort-PHdr: =?us-ascii?q?A9a23=3AqdQXVhBgmEz/5xASWuykUyQVlhdPi93PFgcI9?= =?us-ascii?q?poqja5Pea2//pPkeVbS/uhpkEShdYTW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBT?= =?us-ascii?q?AQMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeH?= =?us-ascii?q?xzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+B7Qqo8Ym4J/LKY2x?= =?us-ascii?q?BbT5HdFKIxr?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AGTB67q0GEDG1paKTKXCKxgqjBJYkLtp033?= =?us-ascii?q?Aq2lEZdDV+eKWj+fyGtvIdyBPylXItSGgt8OrwWpWobHvA+fdOjLU5EqylWG?= =?us-ascii?q?Dd1FeACKFHwc/czyb7Gyv4n9QttptIV6RlEtX/ARxboK/BgTWQKNorzNmZ/K?= =?us-ascii?q?3Av463pB1QZDt3YKJt5RoRMGamO3BxLTMoOaYE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3DADiUIZg/z6wYZlaGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUAJgUkCgVFRB0yBBSRDC4Q4g0kBAYU5hkyBcDA4AZk?= =?us-ascii?q?JglMDVAsBAwEBAQEBCAExAQIEAQGBW4J1AjWBQwImSwIDAQEMAQEFAQEBAgE?= =?us-ascii?q?GBHEThVANQwEBAQMHBIVxAQUjDwEFCAEBFCMBDwkCGAICJgICMgceBgoDAQU?= =?us-ascii?q?CAQGCbYJWAy4CA409kG0CixmBMoEBggQBAQaCTIJNGFiBOwkJAYEGKgGCeIZ?= =?us-ascii?q?LhBM3gVVCgToPgVOBGT6BBIZVgmGFcE+7BywHgXSBHYEhBgubXQULIZQ6BpB?= =?us-ascii?q?QuHQCBAIEBQIOAQEGNYE3IoFZTSSDOFAXAg6OHxeDWYpfcQI2AgYBCQEBAwk?= =?us-ascii?q?BWAEBIYF5ZogkAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.82,251,1613430000"; d="scan'208";a="55237265" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO mobile.exch.fraunhofer.de) ([153.97.176.62]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2021 07:38:01 +0200 Received: from XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Mon, 26 Apr 2021 07:38:00 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5 via Frontend Transport; Mon, 26 Apr 2021 07:38:00 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MxF749TiNYFhxfM1HX9WMgSqsfdat46So8N9Bz+l3274LQ8FEFKm1ZN9lbuJ/GQQl1zERNIBVSYtHGb7k78WH11416DQn80gfua12aeOwbPfBAi21vbM01Xh5yp3Ph7sNbx6mhWy6sNvthXQwj1lxaNkuA/kV4WWkjsx/Yz7Y1A7ZNApe7J7/Sq2YaBgSDoNBT47o88m5PBJwNSAx6cLpl4tPqvfXew8Rg5qOqZb1Psi0xXYWiXRIOR4WSaflvPwJ3xIUF+OGh2C0KW7frjPVwFhzwe1VzFK8brWdwweSJixKi50YpKw5ZTJdePEKvKkqDw/If+lVw6HuiDM/Hk2gQ== 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=5L0i9ZpPsizOFc8tDB0cdlAkumuY8twBoZ+7DzqsjN4=; b=YDz6TNBeD+gZz7xNu7pMlATBuh8B3+PMVbPSV5USXlSVR6KHki9IQ2ZHvqRIUVpwcVVgd3LbRQaURMHxqmtNieOUSDcVbf+sJ/2rIjsMAIxp+OaOIUdZqxZTU07+pLpNrQvPDqVadCbTmiQPxljMTBTVYp7fbPUi/MKN1RyBr3Lzcc4ProCMEh0COkZu6uj2wK86RJNXqrbyj1gG0uo7X8zE4SmFUWq9FlWl5AgidV6WQBvITsK8t1MY6ziMgBPSlxUYR/TAF90l7bE0eBCB4MgqM6YAvclo8rhELJIAt77uQ9AwwtUWahLCKSjb+/YDn1rmHqG1Hd4akc8CKrHE5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5L0i9ZpPsizOFc8tDB0cdlAkumuY8twBoZ+7DzqsjN4=; b=gQVT8fCdEOIttxv5E3QRE2pbby2BPdriNnlPEBuKT9iIg+ybcmOXvj+9CIYlg5eDxIdgR3HCEyVFUGV34Cf85rnh8jWTFHOVNlUEEiK6FyDQ2AvpL8clLvlATKFFhzVkt0M4/FTPK5x51HFE0H0dTmWTu/PmGkZbTzRO4NpwRZs= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by DBBP194MB1131.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:1e3::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.24; Mon, 26 Apr 2021 05:37:59 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0%4]) with mapi id 15.20.4065.027; Mon, 26 Apr 2021 05:37:59 +0000 To: Michael Richardson CC: Carsten Bormann , "iotops-chairs@ietf.org" , IOTOPS Working Group References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> <2ff6d960-f652-dff8-bb85-f59bded4fb9e@sit.fraunhofer.de> <23872.1619397536@localhost> From: Henk Birkholz Message-ID: Date: Mon, 26 Apr 2021 07:37:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <23872.1619397536@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.119.37] X-ClientProxiedBy: PR3P195CA0001.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::6) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.234.119.37) by PR3P195CA0001.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20 via Frontend Transport; Mon, 26 Apr 2021 05:37:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2abd9604-fb1a-4260-95fa-08d908757386 X-MS-TrafficTypeDiagnostic: DBBP194MB1131: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: luEPDI+StZuLQ0mYQHekkbwOto8NrwBmrt42rd3d6q9wAXCXyiWutdT9dl1PRSQ3vaQC6WWBmjJ1O7Nvx6ySOj9PI5Kw3ngla5szgOz9vPLPTW8h4ZcI0r1L+V/RfX2MjBYmqNCAR1GFVsPmTwU1CtNojqsSNrPeDbja0DyKbJpWltE4Kz8YYc5KwCeG07jQm9lxTxm9E7gniYn76bBO23VE8o618MnBwrzSobVF+/QUs11fpDmrDzoy9F1NMR932SnChevUhijxw0vHOThGFqNqkBUTmez9yMrZRcJOIZis2ZvKCTCc9c1KAU3Z12Q5nFvQ6G1zr5IKt1X0QGf1ZjNCxgZImrFyXmbcCQ4fji79iiOCo1GLr5jUIZs4hhY3HY5itdgmoF/jaqJ2l5R0EIaO5TNERXEzZMi6iUo1h8aWHgGCa2a5o5jXlG56xoeeysFBaMNUlI5yRG4fosrXp+jb76thcPCMKA4dWbIpFR0c8AAdvuFWXdyuL7XIhdTrLd3r/99Ozz/exbXlJcF7NXj9rntWceqyOSeS7XEJPiPm5gQKn7QxKqqtGk1XOAEdz44CNuHimm9rSMlMA79jbhVkmKWC/XqXJFk/UBER2Q5FOFprXvRzuDcQ2SQIYzIX2kouq7oF7t+RFcdYVhivrrxSOO+mh7DyrJPlnvLFnaQfXdIwp9UnuQCqiOMfHcm/K/zVFwyJhVf3tuRpCxa0qg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(376002)(396003)(366004)(136003)(38100700002)(8936002)(38350700002)(5660300002)(52116002)(86362001)(4326008)(66946007)(31696002)(478600001)(31686004)(66476007)(66556008)(26005)(54906003)(16526019)(16576012)(316002)(186003)(2906002)(6486002)(4744005)(2616005)(53546011)(44832011)(956004)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?U1hDQkMzaTNPQ3FUUTFnRHp4eG9WQ2RJeHR3NHV1dVEyaVc1ak5BMjc4ZFF4?= =?utf-8?B?RkMrSGpNQjZzeWlEQjdESzZSMlFod05KK1pEZlIrSE0rT1N5OXZwU1F5dTZl?= =?utf-8?B?ekR5YjlPdVo5Wi81UEE2YjB4Y0thSXM3YzVJNmhMbnVCUFZtNzQ5YVlrdDl2?= =?utf-8?B?RlNlREJvVkh3ckFNUXUvSmk5MGllbU1oSkJabVljUTNsVU84d215OWNnUENa?= =?utf-8?B?QTdxUCtPWU0rUzVFR2lJRDY2YnVKcUc3amZqaDV4aXQ3Z2M2QSszeW92cmlC?= =?utf-8?B?RC9lNTluK3RoYkRzMHZhNFU5cXJhcVFLMit1M3BQTUtFWkxNb05LWmJhR29l?= =?utf-8?B?SGVvK0hyMlA1YUZEejRqdm5zNjRPUStOci9KQWVhZVdMWHVvNjRkaDBwSHNx?= =?utf-8?B?UjFuWDBaZ3VucC9HbmN6M2htRUcydmVBVGQrdWFheDd2UERuVVZ2UzhUVmJi?= =?utf-8?B?L2JObmpDVHhXVkM4ZTZvaktaSFU3eWM3bE9OeWliU1poRldRSG4yMlB1V2hp?= =?utf-8?B?QWxrRnB1RGl5UW9rUnRPOFFjTGxFeGlPNGNSVVhIaFJ1SStQWVQwY3lFaUI1?= =?utf-8?B?SjFhTXg0OFdPbEdmZ0FPODdJOVlYbnRweGt0NjZSZHp2NVcvUjR3ZFF5OEtB?= =?utf-8?B?TWx2MUhPU3BELzZBeUtNRU8reHIvbGJUWGhYUncrdE5FU1dZY2hCNzMxaFIy?= =?utf-8?B?bTVva3p2VGVsNjdlRlZoNTBrQTJxYjlNMU1qSUNvK2NKZGozejM4U0xDdi8x?= =?utf-8?B?QnU1dWtpMU1ZZmpncFVEdlZTZFhUQm9Eek9FTUJRQkd4UW1xVFRBUkJUYXJV?= =?utf-8?B?YnRCQWswUFQ3MWNDZzJDTkpUdUpRYzhFRGw4a1FSdWpITm90aUF6b09oeFUy?= =?utf-8?B?TUZUWW5rdUt1UWJyYUxCY2s0aDJCenNsdnlqZTRYWFFCSnUyaEx1Z1c1Q0JB?= =?utf-8?B?UUtDQTBoQy93LzlwWUhGSldIVXNuWGpjWnE5WmloV3VpNHBZZXZkY1hmSDVs?= =?utf-8?B?VzEwL3pEZ1Z5QkFTRm8zTkc3NHRLTXlUOFBQbDJNckZ4Nmt1UTdwbEtzb1JN?= =?utf-8?B?RlJtUFRndk0zekIyNGprc1FHNWhZRDhoSGFOSGJlSjhmREhVUUowUERmcGNh?= =?utf-8?B?RmlUVTRCUlRHTkRwdlFMYy9NWElJRUozUnFEQ1dyZWhxMjI3eUZZZEFURy93?= =?utf-8?B?bkpmenhobmFsMW5QQ2lSM0hHdEpSREhYUFg4REtvNnV4TkVCY0lmNnJQSmVs?= =?utf-8?B?MkR4QkRTRm1aeFc2dFFZR093R01EU3oreGRGODRFbnZOMG05bGZxZks0WlBr?= =?utf-8?B?U1o5UWFNVlJoMnkrQmhvOC9rNk54NjNGTUNUMVRUclg1RWlrdlpab1BOTnAy?= =?utf-8?B?SmpxbnVGQi8yaHFqKy84NXZYRUFnY1Nkb2IrUi9zd3hCSjBUSGF6SXpISy9k?= =?utf-8?B?WHYxa3F0MEJ4K0JpazgzV215Nk5YVm1mbEkxY1BjOFJ1bXpBNUt0Zlp3N0VQ?= =?utf-8?B?MC96MHFHcEFtTGlrL2wvMU8zcXgyR2VqTU5CeE0xMU9sQ2VRejEvTXA0QWpZ?= =?utf-8?B?Qi9WV2JWV2ZFZTZ5bjBGWEVMb2tlYmgzdXhpOHVyaTlzZkVyYTErSTZaV3cy?= =?utf-8?B?dW00QVNyZEp0QUg1cSt2ODRDeGN3Q0JPM3RILzRZTEE0WE5qaWtjZDlYYWJM?= =?utf-8?B?OHI2SWhqUGJRbVVYYndQclBibVFxN2Q5NDI4aEx4QnlyVmVVRTBHUDJBU1hM?= =?utf-8?Q?MXrEFkRhBuk0If1PNrQPIrWJ8YoH/Vh74Bbu4Ge?= X-MS-Exchange-CrossTenant-Network-Message-Id: 2abd9604-fb1a-4260-95fa-08d908757386 X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2021 05:37:59.3684 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: C0zL8eZF4ZjbR7o82TmH5c95Q/CoMZEJGdyFH1/VtIbO/Kesx/+FdzKU2DStjZsgccNCh0IHtSfISiOcJ2Kkt225QZHjkqVia4YBitXQWDU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP194MB1131 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 05:38:14 -0000 The recording is there. It just hasn't been transferred, yet. We'll just have to give that some time, I assume. On 26.04.21 02:38, Michael Richardson wrote: > > Henk Birkholz wrote: > > I can't fond anything either. I'll ask secretary and will come back to this! > > Henk, you should be able to find a URL on the webex site that can be shared. > > The secretariat takes ~week to get through them all. > It also could be that, given the mis-settings that record was not pressed? > I usually set the meetings up to auto-record. > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > From nobody Sun Apr 25 22:53:04 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3F3A09F5; Sun, 25 Apr 2021 22:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RfO9xeSKjlms; Sun, 25 Apr 2021 22:52:56 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798F53A09EC; Sun, 25 Apr 2021 22:52:56 -0700 (PDT) Received: from [192.168.217.112] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FTDZZ4bg5zyVP; Mon, 26 Apr 2021 07:52:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Carsten Bormann In-Reply-To: <23872.1619397536@localhost> Date: Mon, 26 Apr 2021 07:52:53 +0200 Cc: Henk Birkholz , "iotops-chairs@ietf.org" , IOTOPS Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> <2ff6d960-f652-dff8-bb85-f59bded4fb9e@sit.fraunhofer.de> <23872.1619397536@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 05:53:02 -0000 On 26. Apr 2021, at 02:38, Michael Richardson = wrote: >=20 > The secretariat takes ~week to get through them all. IOTOPS has been on the 20th. https://www.youtube.com/user/ietf/videos shows that other videos from = the 21st have been up for a couple of days already. > It also could be that, given the mis-settings that record was not = pressed? The recording does exist. But maybe the automatism that gets the secretariat notified didn=E2=80=99t= work. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 27 10:19:10 2021 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B7B3A17CD; Tue, 27 Apr 2021 10:19:08 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fraunhofer.onmicrosoft.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 rHxVee8ag8nX; Tue, 27 Apr 2021 10:19:03 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 8E5813A17CA; Tue, 27 Apr 2021 10:19:01 -0700 (PDT) IronPort-SDR: TKTYmuVv8kxTuros4cQCcOfYpbmkpoo/Mjl6N0DXXuyD3XtNLHvMDaMiLcBqAJMfWU9pg6DLN4 vM9a9FV8+39w== IronPort-PHdr: =?us-ascii?q?A9a23=3A9qNBdhKxk7wH51iDwdmcuZ8yDhhPgJ39IxIV5?= =?us-ascii?q?5w7irlHbqWk+dH4MVfC4el25HfIUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXX?= =?us-ascii?q?hAIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbA?= =?us-ascii?q?B6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUCtrBmXuNMfnI1iLag80?= =?us-ascii?q?F3FryggRg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HyAQA1Rohg/xoHYZlaGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBV4FTUX6BQQuEOINJAYU6iEQwmUOCUwMYPAsBAQE?= =?us-ascii?q?BAQEBAQEIASgKAgQBAQMDhEoCNYFIASU4EwIEAQEMAQEGAQEBAQEGBAICgQC?= =?us-ascii?q?FUA2Cc2KBCAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQU?= =?us-ascii?q?CNRo5GiMBAQEBAgESEQ8BBQgBATcBBAsJAg4KAgImAgIyJQYBDAEFAgEBHoJ?= =?us-ascii?q?PAYJVAw4gAgMLjXGQLAESLgKKH3qBMoEBggQBAQYEBIJNglIYWIE7AwYJAYE?= =?us-ascii?q?GKoJ5hksdg3YnEIFVQoE6DAOBU4EZPoEEgVwCAhiEXYJhhAWBa1ovulUsB4F?= =?us-ascii?q?0gR+BIQYLm2IFCyGUPAaQUJUpiyeYKwIEAgQFAg4BAQY1gTaBfU0kgzhQFwI?= =?us-ascii?q?Ojh8Xg1mKX3E4AgYBCQEBAwkBWiGLAwGBDwEB?= X-IPAS-Result: =?us-ascii?q?A2HyAQA1Rohg/xoHYZlaGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBV4FTUX6BQQuEOINJAYU6iEQwmUOCUwMYPAsBAQEBAQEBAQEIASgKA?= =?us-ascii?q?gQBAQMDhEoCNYFIASU4EwIEAQEMAQEGAQEBAQEGBAICgQCFUA2Cc2KBCAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCNRo5GiMBAQEBA?= =?us-ascii?q?gESEQ8BBQgBATcBBAsJAg4KAgImAgIyJQYBDAEFAgEBHoJPAYJVAw4gAgMLj?= =?us-ascii?q?XGQLAESLgKKH3qBMoEBggQBAQYEBIJNglIYWIE7AwYJAYEGKoJ5hksdg3YnE?= =?us-ascii?q?IFVQoE6DAOBU4EZPoEEgVwCAhiEXYJhhAWBa1ovulUsB4F0gR+BIQYLm2IFC?= =?us-ascii?q?yGUPAaQUJUpiyeYKwIEAgQFAg4BAQY1gTaBfU0kgzhQFwIOjh8Xg1mKX3E4A?= =?us-ascii?q?gYBCQEBAwkBWiGLAwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.82,255,1613430000"; d="scan'208";a="42254691" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 19:18:56 +0200 IronPort-SDR: HaZVZ2qpqr66GKijAYuCq8fGI/4BVPHfH5STKhpXQpWP64jNDZwow1kXJto6cJVar8E3acF1Q8 Ra1SjHvxB2LEusdsRMu+6hX2TKNxX2oGA= IronPort-PHdr: =?us-ascii?q?A9a23=3AF/cqXR9PYxnN1/9uWNvoyV9lXQAupqn0MwgJ6?= =?us-ascii?q?5Eul7NJdOG58o//OFDEjd1sgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBH?= =?us-ascii?q?xkClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHH?= =?us-ascii?q?BL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZpLQnwox/Yq88WhoVvMOA9x?= =?us-ascii?q?0ihnw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AuLUNP6PI9RNMjsBcT0jw55DYdL4zR+YMi2?= =?us-ascii?q?QD/3taDTRIb82VkN2vlvwH1RnyzA0cQm0khMroAsa9aFvm39pQ7ZMKNbmvGD?= =?us-ascii?q?PntmyhMZ144eLZrwHIMxbVstRQ3aIIScVDIfXtEFl3itv76gGkE9AmhOKK6r?= =?us-ascii?q?ysmP229RZQZCtBApsQiztRIACdD0FwWU1iDZ02CJKT6qN81kadUF4Qadm2AW?= =?us-ascii?q?RAYvPKoMfFmImjTRkNARMm7wfmt0LW1JfRFR+E0hACFw5e2LtKyxm5ryXVxI?= =?us-ascii?q?WG98u6xBjVynPJ4/1t9ufJ59NfCKW3+7AoAxr2jALAXvUGZ5Sju3QPrPir+B?= =?us-ascii?q?IWlrD30m0dFuBSz1+UQW2vuxvq3GDboUUTwlvv00WRj3emgeGRfkNCN+N7iY?= =?us-ascii?q?hUcgTU5iMb1bkWusI7vBPti7NtARzNhyj77dTTPisa8XacmnY+jfUVy0VWTI?= =?us-ascii?q?p2Us4gkaUk4EhXHJ0cdRiKirwPLe8GNrC42N9ra1+AK1jWsm5zqebcJUgbL1?= =?us-ascii?q?OtR0gPvdGtyD5GnHx15Ftw/r1vol4wsL06UJVK/OLCL+BBk6xPVNYfaeZHCP?= =?us-ascii?q?4GWtbfMB2AfTv8dEapZXj3HqAOPHzA77bx/bUO/emvPLgF1oE7lpjtWE5R3F?= =?us-ascii?q?RCNH7GOImr5tlm4xrNSGKyUXDG0cdF/aV0vbX6Wf7CLTCDYEpGqbrhn9wvRu?= =?us-ascii?q?ngH9qjMpNfBPHuaUH0H5xS4gH4U55ObVEDTcwuvMohUV7mmLOLFqTa8sjgNN?= =?us-ascii?q?rDLrvkFjgpHknlBGEYYTT1LMJcqm+xXHvVhwXQRmPNdkTz8YkYKtmZw8EjjK?= =?us-ascii?q?w2cqFcuAkcjlq0ouuRLydZj6AwdExiZJPr+5nL4FWezCLt1SFEKxBdBkFa7P?= =?us-ascii?q?HLSHVRvzIHNEvybPIms9WbcmZC4WufKnZEPofrOT8ag24y1bO8LpSWyyxnIc?= =?us-ascii?q?mgKHimg3wao2/PaJsAhKuZ54PAdokjBpgrHIx9fD+7WSBdqEJPkiNueQUETk?= =?us-ascii?q?jQGnfFkqO+lqEZA+nZap1bmwekIcldrFrFrkWCrcQTRn8WNgTeEvK/sEILfX?= =?us-ascii?q?55l1dx+6gQjP6rgjC0M1Yyh+w+LRlxcmiNOalHCw6EfY1QvbjudGhLPCC3rA?= =?us-ascii?q?3fryt2Vnvh9k0UiGCkCSGPY/nEDmBQvW1i3r/w/El5cXiceExMeml32LcNZ1?= =?us-ascii?q?juizJW66umd6Cz22yeZh85zuYRPCrsTBESLgltrurHnyK9qXKnLzEL158uNu?= =?us-ascii?q?vSAPAfaLnVwGqqM5DNv7oBBeVo8JFsM83OvucHXfmEQRKcKCr1BooSqkqoj0?= =?us-ascii?q?dgHBMxjnYqkfnlgkK4qEe52WMyGvrULhBNQaoBL9SV8mjjQLKp3fxC/KUIlN?= =?us-ascii?q?r1Fl+0TNiMjZzzRXpkDDj4pGatVeEmqZxOp8sJxfNONqiedQGN7W1N2RU1Ed?= =?us-ascii?q?z9m0wfSplq+bypAP4aQ+UiPwZiumcznNuBLEEXohX7L+83c1YqlWLaNbqyks?= =?us-ascii?q?z1gItqJk2Kvw3rP1aDtwVb4vfeRiOGvIRqQZ4YECBzaEIm7m5l8/7HX4rMCB?= =?us-ascii?q?+yf+UG2FahKHeyfPt8T6eCcI9g4ypS0pWtn+WNcTD/1x2VlTxnIrhW+2LieP?= =?us-ascii?q?iMOmu3aKd12u3/H0+NjKus6NOyizmyaQLTUTVnuaR1MWoKbspCjTE+ipYQyS?= =?us-ascii?q?bacN2vnn4Y?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGBwAaR4hg/z6wYZlaGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUAJgU4CgVFRB0wrWiRDC4Q4g0kBhTqGVIFwMDgBmQq?= =?us-ascii?q?CUwNUCwEDAQEBAQEIASgJAQIEAQGEUAI1gUUCJjgTAgQBAQwBAQUBAQECAQY?= =?us-ascii?q?EcROFUA1DAQwBhXMBAQEDARIRDwEFCAEBFCMBBAsJAg4KAgImAgIyBx4GAQw?= =?us-ascii?q?BBQIBAR6CTwGCVQMOIAIDC418kCwBEi4Cih96gTKBAYIEAQEGBASCTYJSGFi?= =?us-ascii?q?BOwMGCQGBBioBgniGSx2DdjeBVUKBOgwDgVOBGT6BBIFcAgIYhF2CYYQFgWt?= =?us-ascii?q?aL7pVLAeBdIEfgSEGC5tiBQshlDwGkFCVKaNSAgQCBAUCDgEBBjWBNiOBWU0?= =?us-ascii?q?kgzhQFwIOjh8Xg1mKX3E4AgYBCQEBAwkBWAEBIYJfiCQBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.82,255,1613430000"; d="scan'208";a="141677809" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO mobile.exch.fraunhofer.de) ([153.97.176.62]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 19:18:37 +0200 Received: from XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Tue, 27 Apr 2021 19:18:36 +0200 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5 via Frontend Transport; Tue, 27 Apr 2021 19:18:36 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K37vq4JacBN/aNHNvQd9POdmsq8qFom2SRjHiSyF1yD1YonAJ45ewXrTJ43ebfoeKzqAHhYDVtaqXkLy7aRBtlIExnqhlPbQVNTnRTWPV+gpfNsk1Rp8Mhw7aH41oANoKBOH3l9rWtctVxFEF1F3GV+7XRhbfhZomu0VOGZDWdXxzSCXbiFdHxlx8eS2qdgQpyuS3Ly/zi9D16iLtSIpikOxbL6Pw8l/xnXJsrSMioZPsrEpLu7xhdQjcCQ7iBMHzL2eTD7z4IqLh0Z04Z7v4s2DDyxoNZnKTcLWi3GmUEMNDHB0un77fBHturqcmpTgOuWI9Ndzjjp71t0I0AfFkA== 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=Axb3avnnUwOWFHdXNsU4ll0qR1IlIeaGEM8ANsecV4k=; b=YpJ9ynXBRozA2Q9dCvziT57YuC+vqO4T/n2hERutBE+W2oTCmsFlkmZJJ7bCEdGDzvxqb2Y67EkzVEDaeDfI7D25z7gjZrcWhwUHu6hRdswZHvVEjT5TeKpsX1NiolTC/zsZ5nqOglGkrPzni0ii1Hgo8tT0G7punPVRvlh0+icCIXT+AoDgyXkCUPCGh7bvKDPUwbh3jTi2MGpeAzqksN48H0j1wbxANFBbQYe+KdZCrhaza8ej530OsrM4MiKv7cucOaMeC/++LFwf9AjGiPhSEzi1veligogRTmdLwyq/KUohU4mE40L+tD77lJfK0GI5iiRtqLSQ1T2qHWBK3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Axb3avnnUwOWFHdXNsU4ll0qR1IlIeaGEM8ANsecV4k=; b=FRvvXas1qp8DSKGNSMdAFV+6S+NH9KBpTTsoEKiGuFP6Fv7FqD/5gFkali/eXMqaUAHqxYb/5nTrSGpmKTzBUVG5lbzDHX+IvHSsXTnnw3Ku9x0jEpu0q/crBnVfPP5pS5vV/12KmhgheT9tYXqQPpPypuaSHJtHtzN88scTTu8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by DB6P194MB0069.EURP194.PROD.OUTLOOK.COM (2603:10a6:4:c7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25; Tue, 27 Apr 2021 17:18:34 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::29fb:d2ca:1bdc:59c0%4]) with mapi id 15.20.4087.025; Tue, 27 Apr 2021 17:18:34 +0000 To: Carsten Bormann , Michael Richardson CC: "iotops-chairs@ietf.org" , IOTOPS Working Group References: <2ade053f-349d-887e-86c3-54674c82e7c9@sit.fraunhofer.de> <0261B244-D79B-43AA-AABB-12B4AEAE9CAA@tzi.org> <2ff6d960-f652-dff8-bb85-f59bded4fb9e@sit.fraunhofer.de> <23872.1619397536@localhost> From: Henk Birkholz Message-ID: <314766e3-3734-0cb6-add3-0a9ba31d4a8d@sit.fraunhofer.de> Date: Tue, 27 Apr 2021 19:18:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.119.37] X-ClientProxiedBy: PR1PR01CA0011.eurprd01.prod.exchangelabs.com (2603:10a6:102::24) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.234.119.37) by PR1PR01CA0011.eurprd01.prod.exchangelabs.com (2603:10a6:102::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25 via Frontend Transport; Tue, 27 Apr 2021 17:18:34 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9aa5444f-20ec-486c-28f6-08d909a07d04 X-MS-TrafficTypeDiagnostic: DB6P194MB0069: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5C7iaLylVK//7tsdEnnjXihMEWg1M4ECDbNvKooulSIC5q9w9u/poM/+YRzCHulm751CaVjGfvI2jqB3Jgd6O6Xchnv6b7SyKBwfBR9ZuooHdr1HKf778E8d6yYmJ9Jcxw52HeQBAgA1r/Ss6KlXcLfAPfFpk4WingxlHfl1swN6xHSA2CWhcdNkEzCBS82XNMbMf4h5SfrGZUJWWwfPsRKlaFHa2IHh8/rjjdbpajAPfdPDBff1Y0L/hMEylkrPUJWwkaF6SubQEDAkQeJ4BmdrudWufSYi2BIVUrlK8kxA4rqwPzu7fF8sE9V+G1p1EeblRE8V+bxH8SXgNu73mSks3GlCNPMqTzv0k40OLnkorVz5SiKZD3034X/HzRa4ym6KeKLqSAaI1dmfKYVEiJEqNRRkmQq18eKAj9vZy+gukjQ/veAFkTaQ5XCUfo6Z118EWzF1F7vl0r6I6ms2fvR6nqLH5NZuLRU4pKgKzzLBxG/624zv4X7tTXDxZuvTWH/zPi91fJv1wFaqCO3lW2vofYWcFcw9F2brUjH89bQYQMrGeT6ktHSwQyB9sWiiPBbV6zUuOT7We7LwE46xN475kPYxN7AzNrBNQPEARJmkQ8LKIYAc/OWyWnMrLgVBgjslZkEFw+Nzn00PAGDcnl5Vsm+3bz7C3vvAWTErffHgAqc+wFtmlXNUa+aC0i26Xy2Jm80wuR6NuqandU3vKkmBvT4LhV2qqpI7iiilSOC7Rzj9as1/x796AGWwH1c8 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(376002)(366004)(396003)(346002)(136003)(86362001)(16526019)(186003)(26005)(16576012)(31696002)(4744005)(52116002)(110136005)(8936002)(316002)(31686004)(38350700002)(2906002)(38100700002)(6486002)(478600001)(966005)(66946007)(54906003)(66476007)(66556008)(44832011)(4326008)(5660300002)(956004)(2616005)(53546011)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?WjRqbjk3UktWb05JR3FtZHJ2ZzJES1IyeHlDZlFic0x4ZEN2SnVNYjh3ZTJK?= =?utf-8?B?Ky9CVUVJV3piaERkWUV5bTZkNlJMaWZKSHdtem9pU0FlMlF6VTVPeEFrZlhz?= =?utf-8?B?cW9tNy9uNjV2TDFIcTZrQVpySkF5Z0t3SEZYNzVwcld2ekJOOXpOV2tYUmsr?= =?utf-8?B?MkhwWlU3VThnRnZlTGpBVUk1N1RWZ0tLcTFCajhLNXNGaktOOTZNUUpHWUo0?= =?utf-8?B?ZmM1aVZQRy93RDVEK20waEpQaGN5Skl2M096dEdtb2RpYk9EaHd1d25EV0ZN?= =?utf-8?B?T2ljV3ZlY0JsdlpDVURxZmtGOW9XdENrdmM5NUN5RGVmZGwvdCtzOTBDc0dj?= =?utf-8?B?WXh5THY0RmlNMzFFcmVrTXZ2MlZmMDB4dEd6ZmdOY1cyS0RGdkpUblFTWWwv?= =?utf-8?B?akNSRTVZVmZPSjFVVEdQaUE2VWZjcDU3cUQ1RldjNWkzOFVVUVpvZ04rZG00?= =?utf-8?B?UFkyNVlUUGczdkdVSmpybXBVQjRMekxKZ2RWOGYxZ2E3YnZMQW5mNkR4N2FO?= =?utf-8?B?ZzBRV0lwZUNuTVN5blBvdGhGZTNFV2hzMEZpRi9jV1FHeFZRTG4yUXZTU3FN?= =?utf-8?B?b2wvUHh4UjhFUHN5WnhGRzVQK1VELzZVU2VuanRpcDhXQ0dSbFlCTUVEUnlm?= =?utf-8?B?NGJDNDNaVklLS3M1d2xPam9HdTNwRUl4ckNsWm01d2JxR2ZTYk4rZlh2SmdR?= =?utf-8?B?eGQ3NkpNVmZDWjZ4SklaeG1CM2hjLzcwMUZFRnlTLzZaRzV3UnBZSG5lR3M0?= =?utf-8?B?bldyQjlBd0Jja0g5Ym13VWJYQ3kxRTBWckwrVno1ZmdXR3VnT3d1MGJzbGNX?= =?utf-8?B?K1dOZUUzNE4vNXFRb0duUWNnaGplZk9EYU82U29hbkFzV1NhL0hMcEZ2Vmxm?= =?utf-8?B?dDJNRkVzRnoycW1oL2ZZTllDMXdIWnMyY0ZjOVhSUTg5ZUZwREdvV05rd0Ev?= =?utf-8?B?TkJJaDQrVFR4VXUzM1ZSRXQ1SjM0UDVwVzFtOHE4OXgxODlkTkpBZ3k1Vzdj?= =?utf-8?B?OGxNU1VhczNOd21wdGhxR2Y0OVlJaW5oSllMUWRJUEt3ZDAzd2JsdDVPZDQ5?= =?utf-8?B?UDBjMnB6VFFXQ3Axb2YzN0JGOGRXaHp5ZEtacHpKRm1xNHRneFRqSm5rWUx2?= =?utf-8?B?OUdXQjNwY3pDUVBKb29tSXZOTmE1TllBTHZ1bDZjV0JpUjhBMkM0RXhxbVNH?= =?utf-8?B?QW9QLzAwa3VKcnVkc2c4M0RVSm5UY2gxVEczZ3NDT21EQ0ppN0hQZlhFM2hV?= =?utf-8?B?NitzTDVDb2dERXk5VmMrQm5aMGtRZHBTZFViZm9EenNmeTV0b09NWFpkUVVU?= =?utf-8?B?YjBhaFk1T3dneWxVWWlVNFZiWXJmWHAxelA2ZXpkdFFBekxaNjR0cXhmV1E3?= =?utf-8?B?cEtOREVJaWtSUk9wcUk5N21QZmoxa0lybS9xWTdQYTQ4ZzNWZ2tpUkJYaDB3?= =?utf-8?B?VmRVOG4xUytMVFJydUIyQUNMcUZVT0NlTGdlaGlXRUFKMWdPWnJmOGlrZjBV?= =?utf-8?B?ZWJXTXJwaHpWaUhST3N3NHhxOGZJZEwrZk11bWpqemZwYm85dnU5cWZWRzh6?= =?utf-8?B?NitoTmpYcTM5WDBKbFNicXgrcU4zNG52TDRtaWdqOFpIVC9Xb0VGSUdGQzdl?= =?utf-8?B?U2wxWHJ2Qy9DZVlvWGhRMEovdXQzM0VvZEVWOFYxamR2T3I0dmdaTDNWQmQ0?= =?utf-8?B?WUpINk9ZbDloVFhjUUs3NmJ4M2lCR3o0OFJyYi9ReTI0eDFkTkZPcy9pV3Y5?= =?utf-8?Q?6C60uRd9Bw92rOcRg5JaVdTlrUQcKdjr2NBkWll?= X-MS-Exchange-CrossTenant-Network-Message-Id: 9aa5444f-20ec-486c-28f6-08d909a07d04 X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2021 17:18:34.7881 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1JNNCXfSgwkzCE4Xaq1kQbkhIPWEiV34O5ZuQzON1455f8SUYMxObkZBVGUJHDs9Zfaooz8/0eeVqmJ/009KVZUt3Z2sQpapV7Uwrqvs3kA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P194MB0069 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: Re: [Iotops] =?utf-8?q?=F0=9F=94=94_IOTOPS_WG_Virtual_Interim_2021-0?= =?utf-8?q?4-20?= X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 17:19:09 -0000 Hi Carsten, hi all, the recording is now available via: > https://www.youtube.com/watch?v=P8mFPhBtaoE Viele Grüße, Henk On 26.04.21 07:52, Carsten Bormann wrote: > On 26. Apr 2021, at 02:38, Michael Richardson wrote: >> >> The secretariat takes ~week to get through them all. > > IOTOPS has been on the 20th. > https://www.youtube.com/user/ietf/videos shows that other videos from the 21st have been up for a couple of days already. > >> It also could be that, given the mis-settings that record was not pressed? > > The recording does exist. > But maybe the automatism that gets the secretariat notified didn’t work. > > Grüße, Carsten >