From nobody Fri Mar 5 16:06:57 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 48BEA3A1441; Fri, 5 Mar 2021 16:06:52 -0800 (PST) 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, HTML_MESSAGE=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 tRqFLPmk0iJp; Fri, 5 Mar 2021 16:06:50 -0800 (PST) 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 B85453A16B1; Fri, 5 Mar 2021 16:06:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B674389E3; Fri, 5 Mar 2021 19:11:03 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2R4srx5NFTxF; Fri, 5 Mar 2021 19:11:02 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8096D389E2; Fri, 5 Mar 2021 19:11:02 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 005E1B2; Fri, 5 Mar 2021 19:06:16 -0500 (EST) From: Michael Richardson To: opsawg@ietf.org, iotops@ietf.org, dnsop@ietf.org 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: [Iotops] MUD in DNSOP (fwd) Ben Schwartz: MUD in DNSOP 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, 06 Mar 2021 00:06:52 -0000 --=-=-= Content-Type: text/plain Forwarding comments. <#secure method=pgpmime mode=sign> --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=214 Content-Description: forwarded message Replied: Fri, 05 Mar 2021 19:05:34 -0500 Replied: "Ben Schwartz " Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3:216:3eff:fe7c:d1f3] by localhost with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Fri, 05 Mar 2021 18:09:05 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus 2.5.10-Debian-2.5.10-3+deb9u2) with LMTPA; Fri, 05 Mar 2021 17:28:38 -0500 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B9558389E2 for ; Fri, 5 Mar 2021 17:28:38 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PUiVRBaxEgfs for ; Fri, 5 Mar 2021 17:28:36 -0500 (EST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 4C72A389E1 for ; Fri, 5 Mar 2021 17:28:36 -0500 (EST) Received: by mail-wr1-x42f.google.com with SMTP id f12so3712052wrx.8 for ; Fri, 05 Mar 2021 14:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=EaQvk0kyZLMp3m+3pEwDkv8u1FifwUIQ9/Ti/6C/stk=; b=p6M7kyZ8ytoTL+ijdxH55neIJM51ImCL2/hSxLdm7hG0e2RDuHJwQRPwOTLwOG6XOE +UoJKiWQcLgWZ+5O7isLhMC21CWIMcOrbi1oe9Ga+MJbmvJof9T2ftCglbEWpKfeTXQv Hu1+pVJXdhjTCFxy3qVWrWmXMk1mnF2dZ8tfrMX59gJ+7mljNUpackGZFTDpwNmyXxMp XBi1nZP4xDflNGSFHtczdit9Cwetv8u9r/TUiKaI7kScSMuo8Y+eMNh1VUJKw4wcAMGD pb+LfTrYt/R1oPAluarjLr+lqLq8BLRYNg/bEi43+FIaNTdLgf8cGP4UH2aU3q1shSfD AAcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EaQvk0kyZLMp3m+3pEwDkv8u1FifwUIQ9/Ti/6C/stk=; b=j6mDZSDY+tbOjBqu17yEsjVG8hTaDz3yOdjCEkgNaEmWaHu65t/u/x2a+pacj+MXpX xhyFIWzrncSvrbKEhBPWT+9ISkD5HfYSzK8fo86jxJaOtDjPXd//GEcitm/ndinoRNMe vmp2pm+xf+T90aY8pn2cUQJB9aRsBZzfE2VSiODmxT7GBEiJ4hwO3Drgm3WVdw7JxkIQ rvOTbLJ5d0Eyq8f8Jx4iJEW9ZfIWL2dQ2u+x7T8k8hIYz5Uaels0rth4o4AymPlfy5dq g9sDPi1j4OUp0dOIP8SmQ6jTT1Cuof4L2qrV0KOqJPBx3a4LxLbSS/3WjDtrh6nLArHe CQCg== X-Gm-Message-State: AOAM533Lgug5PhirAkhL7tRKLlTiOOKFhlhQuZFm9KLwB/hbqgCoI/AA lio1buGimhm7vue84t1akUjebjvzkshhGcEaIA3TS1cgMiRzyW8B X-Google-Smtp-Source: ABdhPJwAO3coolgaLuKDopeiRETouc57tyhQJZoShmgQkcl9yjOqdltieWoqIxCPG+cySjwcWZa0OTAcvE8XKr6+cPU= X-Received: by 2002:adf:f1c4:: with SMTP id z4mr11716985wro.404.1614983028231; Fri, 05 Mar 2021 14:23:48 -0800 (PST) MIME-Version: 1.0 From: Ben Schwartz Date: Fri, 5 Mar 2021 17:23:36 -0500 Message-ID: Subject: MUD in DNSOP To: dnsop Cc: Michael Richardson Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000bdec2b05bcd1891d" --000000000000bdec2b05bcd1891d Content-Type: multipart/alternative; boundary="000000000000b79c1005bcd18933" --000000000000b79c1005bcd18933 Content-Type: text/plain; charset="UTF-8" I noticed that draft-ietf-opsawg-mud-iot-dns-considerations is on the DNSOP agenda for this week. It considers the problem of using MUD, which applies IP-based filtering to locked-down IoT devices, with DNS-named servers. Some of the recommendations are clearly correct given the limitations of MUD, but I also have significant concerns with parts of the text. Section 4.1 says not to use IP addresses at all. Section 5 and Section 6.4 make recommendations about which resolvers to use for IoT generally. I think this is not necessary or productive. The recommendations should be limited to MUD-DNS devices. The draft recommends that devices use the network-provided DNS server, which is typically a general-purpose resolver that is capable of processing any name. Allowing the device to access this server defeats much of the security benefit of MUD, because malware can communicate bidirectionally through the DNS server, bypassing the MUD profile entirely. It would be more secure to disable the urn:ietf:params:mud:dns permission. Section 6.3 says When aliases point to a Content-Distribution Network (CDN), prefer to > use stable names that point to appropriately load balanced targets. > CDNs that employ very low time-to-live (TTL) values for DNS make it > harder for the MUD controller to get the same answer as the IoT > Device. A CDN that always returns the same set of A and AAAA > records, but permutes them to provide the best one first provides a > more reliable answer. I don't think this guidance is sufficient. MUD's DNS filters assume that the device and gateway have the same answer in their local caches. Even if the device got its answer _through_ the gateway, there's no guarantee that this is true, unless the name always resolves to the same addresses. Even if the name resolves to the same addresses for everyone (no geotargeting or load-balancing), any change to the zone can result in a device-gateway mismatch during the transition, resulting in an outage while the gateway blocks the device's network access. This mismatch can last for the duration of the DNS TTL. Ironically, the guidance here to use long TTLs could result in longer outages, plausibly hours to days. Even if the device always delegates DNS resolution to the MUD gateway, and the gateway attempts to provide deterministic caching (unlike a typical resolver or forwarder), consider the case where the gateway experiences a power glitch and resets. Normally, with MUD, this would likely result in an outage of less than a minute, but if the gateway re-queries the DNS name and gets a new answer, all corresponding devices on the network will be offline for the DNS TTL. I want MUD-DNS to work, but I think that's going to require some deeper changes. The cleanest solution, in my view, would be to avoid the device ever learning about the results of DNS resolution, by forwarding traffic to named destinations through a SOCKS5 proxy operated by the gateway. (SOCKS5 is trivial to implement, far simpler than DNS.) A similar effect could be achieved by IP encapsulation, IPv6 extension headers, and many other mechanisms. A hackier solution would be to add a DHCP option for the MUD gateway to specify its associated resolver, and require devices not to implement any DNS caching. These approaches are compatible with disabling the urn:ietf:params:mud:dns permission, which is typically necessary for real control over the device. --Ben [1] https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-01.txt --000000000000b79c1005bcd18933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I noticed that=C2=A0draft-ietf-opsawg-mud-iot-dns-consider= ations is on the DNSOP agenda for this week.=C2=A0 It considers the problem= of using MUD, which applies IP-based filtering to locked-down IoT devices,= with DNS-named servers.

Some of the recommendations are= clearly correct given the limitations of MUD, but I also have significant = concerns with parts of the text.

Section 4.1 = says not to use IP addresses at all.=C2=A0 Section 5 and Section 6.4 make r= ecommendations about which resolvers to use for IoT generally.=C2=A0 I thin= k this is not necessary or productive.=C2=A0 The recommendations should be = limited to MUD-DNS devices.

The draft recommends t= hat devices=C2=A0use the network-provided DNS server, which is=C2=A0typical= ly a general-purpose resolver that is capable of processing any name.=C2=A0= Allowing the device to access this server defeats much of the security ben= efit of MUD, because malware can communicate bidirectionally through the DN= S server, bypassing the MUD profile entirely.=C2=A0 It would be more secure= =C2=A0to disable the=C2=A0urn:ietf:params:mud:dns permission.

Section 6.3 says

=C2=A0 =C2=A0When aliases point to a Content-Distribution Net= work (CDN), prefer to
=C2=A0 =C2=A0use stable names that point to approp= riately load balanced targets.
=C2=A0 =C2=A0CDNs that employ very low ti= me-to-live (TTL) values for DNS make it
=C2=A0 =C2=A0harder for the MUD = controller to get the same answer as the IoT
=C2=A0 =C2=A0Device.=C2=A0 = A CDN that always returns the same set of A and AAAA
=C2=A0 =C2=A0record= s, but permutes them to provide the best one first provides a
=C2=A0 =C2= =A0more reliable answer.

I don't think = this guidance is sufficient.=C2=A0 MUD's DNS filters assume that the de= vice and gateway have the same answer in their local caches.=C2=A0 Even if = the device got its answer _through_ the gateway, there's no guarantee t= hat this is true, unless the name always resolves to the same addresses.

Even if the name resolves to the same addresses for = everyone (no geotargeting or load-balancing), any change to the zone can re= sult in a device-gateway mismatch during the transition, resulting in an ou= tage while the gateway blocks the device's network access.=C2=A0 This m= ismatch can last for the duration of the DNS TTL.=C2=A0 Ironically, the gui= dance here to use long TTLs could result in longer outages, plausibly hours= to days.

Even if the device always delegates DNS = resolution to the MUD gateway, and the gateway attempts to provide determin= istic caching (unlike a typical resolver or forwarder), consider the case w= here the gateway experiences a power glitch and resets.=C2=A0 Normally, wit= h MUD, this would likely result in an outage of less than a minute, but if = the gateway re-queries the DNS name and gets a new answer, all correspondin= g devices on the network will be offline for the DNS TTL.

I want MUD-DNS to work, but I think that's going to require som= e deeper changes.=C2=A0 The cleanest solution, in my view, would be to avoi= d the device ever learning about the results of DNS resolution, by forwardi= ng traffic to named destinations through a SOCKS5 proxy operated by the gat= eway.=C2=A0 (SOCKS5 is trivial to implement, far simpler than DNS.)=C2=A0 A= similar effect could be achieved by IP encapsulation, IPv6 extension heade= rs, and many other mechanisms.

A hackier solution = would be to add a DHCP option for the MUD gateway to specify its associated= resolver, and require devices not to implement any DNS caching.
=
These approaches are compatible with disabling the=C2=A0urn:ietf:params:mud:dns pe= rmission, which is typically necessary for real control over the device.

--Ben

--000000000000b79c1005bcd18933-- --000000000000bdec2b05bcd1891d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAGnjs1119HDOsp/SPG0 XFowDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMTAyMDUy MzQzNTNaFw0yMTA4MDQyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1N1uLicDVgtwM9oEggVS/tZ2KAmVdmTJ 5M/y8wlsQeOhdi3DS1kW1U4GywSj64bAhRF1Q8EWWv0eaZuU24dK638JYvl4X4ap99mFyGmsySPS bE+Q/fAsRkpLfRSXK+5ZjZ39ySwTgLsi62BLykDCnxKFv0h5ASmO/jQCfSxTshXQ+b5SRa8xy9/k noIBnT1k3g3Sx86NEzOqFcijEiojz/jhJ7qw2h/CQjlEpgvCKAFgY4DCop6exC8B6eoYS9Lj+/Sc hw2lAfqtueTuMqJErzrSeZcBwys262nOleJN9d1HTfkudv3NAeaPYmyaoYFZXQ1QeAklli0mqaqz odfLmQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUq0QyOyj+YgHX /rWYb/NHQJkioe4wTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAELHe2QqUz+Zoz832czTA7nh YMGb1UtuDhhJXGtQa30WhBzFxDw2KvYIT9bB176l/g5RXu9hjgPlNP39BJq+CN7aGp/nYsDUJv+c G/eTn+Lj4aRCXWbcNuetApMvbje/Blk4KfyrBJ6Bef/WGrV+9NLYZU06iOAe7ZIivEzvekianGAQ psQx9DfKqOsP6wGIxXEilIXPLDIObDnXRhYYJQcctmnSQbo3lD8kubWcV1PMRIo9B7T2T6Ao34Hi g2h43eaUHej4E1WVUW0LkqXKtQsAQhwc2QqE8D+MSC79Qn+ke6j3IG4Xef9+b0BGgDJCeftOvpCQ ZVJ3jM316xykETAxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAGn js1119HDOsp/SPG0XFowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIO4B3otkIvqa KOidkqHR7fpLdoPV7E8omvr2Mc6Af4fbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIxMDMwNTIyMjM0OFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQC0HQj8IITh86TyUyQGs/fNifQ/iFVS Dydc2IJjYjjiztkBzwV5olwQve35OHdHotzmtmhQBYzx80mBOuyLxdMdsjg/7LCKRNgPu8YgvIIA btxuHJdNsEAUdyu8jMIm5FlvZsBFc2pGS3FjYccX3J+QNTtVK8Fuk192SRgm6Kth3cuSSFNTh066 +gc0eOxte74TCzokgcKS2BBKzpAo5vWqIF5ngzk1fwF39YWHKBYqoCPk7rk5ONqGY8XsI/Un3jTk ZvJJJK3nVFl2RTVXSPsXrYJQFBLMb1pxsw8nj9F+GaBWzy+28EmBuhha2RpNwcOwjzbn2H3zz+HC 0HrPvjwY --000000000000bdec2b05bcd1891d-- --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-=-- From nobody Wed Mar 10 12:27:20 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 50AA83A1785; Wed, 10 Mar 2021 12:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.6 X-Spam-Level: X-Spam-Status: No, score=-14.6 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_HI=-5, SPF_PASS=-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 heJf5gZQ6EFf; Wed, 10 Mar 2021 12:27:17 -0800 (PST) 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 B94703A1757; Wed, 10 Mar 2021 12:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17889; q=dns/txt; s=iport; t=1615408037; x=1616617637; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=stvtBI/GVIA7Zn7OcEpn21DvPctihXz3osaHBlqV8LU=; b=NVS4M0Yiik4PgyuBAkvdTe7Obg3cEs6S1u7TLfDnEtsBL60cLPaVGBPi FTO4Qq+O25u0G68G6WOvtOEGmFlrMDLiR1UXKb91UZ4glT9s6Rltag4jE E7q6G8dOUoDiLNJU2yyYTECn0kjRd/AktQw2d5Bw/NqX4lp0w3YQWuXSn c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AgAAD+KUlglxbLJq1RCRoBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAYIPgSOBfg5IAScSMQKEP4kEiFkDh26MOogdBAcBAQEKAwEBH?= =?us-ascii?q?QEKDAQBAYRNAoFzJjgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGN?= =?us-ascii?q?g2GRAEBAQMBAQEhSwsFCwsRAwECASoCAicoCAYTgnABgmYhD60BdoEyhD8BA?= =?us-ascii?q?wGBFIRvCgaBOYFThSoBglOCQzV6QoILgREnHIIIUD6CXAEBAoExTIJ2NIIrB?= =?us-ascii?q?IFVAmkFAQGBGSEgOz4rDwETGykakEg2GYwcixCRT4MKgzCBPZdAAxYJgzyQK?= =?us-ascii?q?5AZhj+LWoRfiT+Rd0tBg3UCBAYFAhaBayGBWTMaCBsVOyoBgj4+EhkNjiYSi?= =?us-ascii?q?GqFRkADLwILKwIGAQkBAQMJjH8BAQ?= IronPort-HdrOrdr: A9a23:yYeVM6+O7wXRvs48DLRuk+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.81,238,1610409600"; d="asc'?scan'208,217";a="34021563" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Mar 2021 20:27:12 +0000 Received: from [10.61.144.22] ([10.61.144.22]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 12AKRBGR011445 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 20:27:11 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AFEF8D85-0447-4C98-87B1-F8A3799AE097"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 10 Mar 2021 21:27:10 +0100 In-Reply-To: Cc: Guy Fedorkow , Laurence Lundblade , "rats@ietf.org" , iotops@ietf.org To: "Smith, Ned" References: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.22, [10.61.144.22] 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: Wed, 10 Mar 2021 20:27:19 -0000 --Apple-Mail=_AFEF8D85-0447-4C98-87B1-F8A3799AE097 Content-Type: multipart/alternative; boundary="Apple-Mail=_692EB541-A479-4753-AF63-D9CC4EEB6CCC" --Apple-Mail=_692EB541-A479-4753-AF63-D9CC4EEB6CCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yeah, this is an issue that comes up from time to time. How = =E2=80=9Cimmutable=E2=80=9D should that iDevID be? 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? Can one recover with an update? What if there are attributes in the cert that I want to dink and share = with the deployment? I=E2=80=99d like to take that latter case off the table, but then we = need to seriously think about RATS or SUIT providing a standard = protected TLV 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. Eliot > On 10 Mar 2021, at 20:02, Smith, Ned wrote: >=20 > The 802.1AR spec doesn=E2=80=99t AFAIK require IDevIDs that can=E2=80=99= t change. But not curtain. Is says things like: > A > device=E2=80=99s DevID module stores each of its DevID secrets = securely and supports signing operations that prove > possession of the secret (and thus that the device is the subject of = the associated DevID certificate), while > ensuring that the secret remains confidential so the device cannot be = impersonated by others. > An Initial Device Identifier (IDevID) provided by a device=E2=80=99s = supplier can be supplemented by one or more > Local Device Identifiers (LDevIDs), each using an existing or a = freshly generated secret, facilitating > enrollment (provisioning of authentication and authorization = credentials to authenticated devices) by a local > network administrator. >=20 > A device with DevID capability incorporates a globally unique = manufacturer provided Initial Device > Identifier (IDevID), stored in a way that protects it from = modification. >=20 > LDevIDs can also be used as the sole identifier (by disabling the = IDevID) to > assure the privacy of the user of a DevID and the equipment in which = it is installed. >=20 > -Ned > From: RATS on behalf of Guy Fedorkow = > Date: Wednesday, March 10, 2021 at 7:59 AM > To: Laurence Lundblade > Cc: "rats@ietf.org" > Subject: [Rats] 802.1AR device identity >=20 > Hi Laurence, > We talked about device identity on the RATS call today. > For RIV, we=E2=80=99re relying on this IEEE spec: > https://1.ieee802.org/security/802-1ar/ = > That spec defines Initial and Local Device Identities. Initial = DevID is set by the manufacturer and can=E2=80=99t be changed or = replaced, while the Local DevID can be set and erased by the owner of = the gear. > The spec doesn=E2=80=99t address deciding which identity to use for = any specific application, but the intent clearly is to allow the owner = to use the manufacturer-supplied identity to install an owner-specific = identity in a device, and erase the owner-specific identity leaving the = manufacturer identity in place when the device is decommissioned. >=20 > Many different specs must have examined this problem, but of course = it never hurts to re-use some of these ideas where possible. > Thx > /guy >=20 >=20 > Juniper Business Use Only > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats --Apple-Mail=_692EB541-A479-4753-AF63-D9CC4EEB6CCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yeah,= this is an issue that comes up from time to time.  How = =E2=80=9Cimmutable=E2=80=9D should that iDevID be?  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? =  Can one recover with an update?
  • What if there = are attributes in the cert that I want to dink and share with the = deployment?

I=E2=80=99d like to take that latter case off the table, but = then we need to seriously think about RATS or SUIT providing a standard = protected TLV 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.

Eliot


On 10 Mar 2021, at 20:02, Smith, Ned <ned.smith@intel.com>= wrote:

The 802.1AR spec doesn=E2=80=99t AFAIK require = IDevIDs that can=E2=80=99t change. But not curtain. Is says things = like:
A
device=E2=80=99s DevID module stores = each of its DevID secrets securely and supports signing operations that = prove
possession of the secret (and = thus that the device is the subject of the associated DevID = certificate), while
ensuring that = the secret remains confidential so the device cannot be impersonated by = others.
An Initial Device Identifier = (IDevID) provided by a device=E2=80=99s supplier can be supplemented by = one or more
Local Device = Identifiers (LDevIDs), each using an existing or a freshly generated = secret, facilitating
enrollment = (provisioning of authentication and authorization credentials to = authenticated devices) by a local
network administrator.
 
A device with = DevID capability incorporates a globally unique manufacturer provided = Initial Device
Identifier = (IDevID), stored in a way that protects it from modification.
 
LDevIDs can also = be used as the sole identifier (by disabling the IDevID) to
assure the privacy of the user of a = DevID and the equipment in which it is installed.
 
-Ned
From: RATS <rats-bounces@ietf.org> on behalf of Guy Fedorkow = <gfedorkow=3D40juniper.net@dmarc.ietf.org>
Date: Wednesday, March 10, = 2021 at 7:59 AM
To: Laurence Lundblade = <lgl@island-resort.com>
Cc: "rats@ietf.org" <rats@ietf.org>
Subject: [Rats] 802.1AR device = identity
 
Hi = Laurence,
  We talked about device identity on the RATS call = today.
  For RIV, we=E2=80=99re relying on this IEEE spec:
https://1.ieee802.org/security/802-1ar/
  = That spec defines Initial and Local Device Identities.  Initial = DevID is set by the manufacturer and can=E2=80=99t be changed or = replaced, while the Local DevID can be set and erased by the owner of = the gear.
  The spec doesn=E2=80=99t address deciding which = identity to use for any specific application, but the intent clearly is = to allow the owner to use the manufacturer-supplied identity to install = an owner-specific identity in a device, and erase the owner-specific = identity leaving the manufacturer identity in place when the device is = decommissioned.
 
  Many different specs must have examined this problem, = but of course it never hurts to re-use some of these ideas where = possible.
  Thx
/guy
 
 

Juniper Business Use = Only

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

= --Apple-Mail=_692EB541-A479-4753-AF63-D9CC4EEB6CCC-- --Apple-Mail=_AFEF8D85-0447-4C98-87B1-F8A3799AE097 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBJK54ACgkQh7ZrRtnS ejNDxwf/bfF+OI7IwSu2fsuJm/gWT9b7eZEv0+GteydI0kYSwctpEkvdVIP/dEbF dQ0sCZ94R583SM7qM3005gU8TfMUu0LAzMoKzWqfs8LuBqNZlurcYjzL1z016uWN pf3KAkLgMor1u2ssQQrIMgwn4ryneZ1FLp+rzSqMEheMActDChyoXbAz2vqhxxi4 JdxvF02Y5bjX0ZM4geih9egAQLUtP5kok0BiINVo68kUoOahdtIc1M7xAExXo8aP P/XV+EcKgPHWAo6yd9gBRelv8vIczioqAM7WQV8vqfRMpJueXhv9iYuCFl28oVlz y8/YCMGQIGj0IpWkMGLafWMH2ZFpsQ== =3eEO -----END PGP SIGNATURE----- --Apple-Mail=_AFEF8D85-0447-4C98-87B1-F8A3799AE097-- From nobody Wed Mar 10 13:09: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 03AA93A182A; Wed, 10 Mar 2021 13:09:45 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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_PASS=-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 PveWPOW6Y9qC; Wed, 10 Mar 2021 13:09:42 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.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 CFEA43A1829; Wed, 10 Mar 2021 13:09:41 -0800 (PST) IronPort-SDR: nzYTyCFxqF+DpMtOUTHcD2mUcD8jyczU0ppVG2xjvaTUGqN/MtpSZYvjFgau05r6El5eiWyL+K KaNkP2oJIo6Q== X-IronPort-AV: E=McAfee;i="6000,8403,9919"; a="188663844" X-IronPort-AV: E=Sophos;i="5.81,238,1610438400"; d="scan'208,217";a="188663844" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 13:09:40 -0800 IronPort-SDR: 0f7HCGPmOHlqHQ/+uudqFaAUuQN2/tP7KlNVY029OY6O2Qn2lXVn0vMM/udlIIxNpO+SndsPpo 4+ROZc4G9oYg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,238,1610438400"; d="scan'208,217";a="386775268" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga002.jf.intel.com with ESMTP; 10 Mar 2021 13:09:40 -0800 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, 10 Mar 2021 13:09:39 -0800 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) 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 via Frontend Transport; Wed, 10 Mar 2021 13:09:39 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.175) 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; Wed, 10 Mar 2021 13:09:39 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TF+aHGuZ27gqrLf5NTDmNBadwCeyVvzX0Ct40id8blLJowwUoOp3UOCLAzUUdDKvMoQu7B0Svt0TFHiI1xv8lKUdl1zREWuEraPLFe+GWWAfkUllXsbBwA0TXXohjqtpiADHI34xGtDQAjjoxyPqwMiBGHU0XSbAeKmbeJflY038XxeCopfjz37YSYWw3hj7r45dMPPjhloV4SCgY7oDBB+i/KqRFem6vhDNeoX6IswefiSAKm/WUeTlBfXUmHggXzDnrw2xOehTQqTjRGJlThTlsFj3wQts/aPZ4nGOnaxVtUOGX4gPwmtWeKDeEcuVh8ez/jwbdC4vgnkT6gSsHw== 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=5aQeoOLY6X5zRZDGVMPr+K49QDgRsfP+S+70X3j4wnA=; b=BiwJtKeazxOhsZbzA4oDqCE3BfuqY4yr/j61h6xqJjeK5Q5ac+uB7GK3u3duaMrePI/3h2T/HLBH4CUPl+TQbmQScX1M5PVJ7q3omZHj5dMAJiqig8Y7v7SVJPcsypLOaZqqDZNVRm3IOVoR41oUx6q8578Nr0xQeGY4CQqgJ3hyZHQ9nJkkqzy8EvLT6v6baJnqZ9tzEE9XfOesX1Xnv7BvjO3FsY3FzCSz11Mxr+Ie3o/DtNUmU/0HYijWKNNCtausYrLV6VtROsYKA34Yajo164kd5NZkxlbnkDxlCI8699YzPRp6D6i4ptzJ7FvnGlHEamVt3PVmapL57HRSeQ== 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=5aQeoOLY6X5zRZDGVMPr+K49QDgRsfP+S+70X3j4wnA=; b=TvCFoVGI6/Pu+/4+x0/dIsjayEeVPzOYW5F7ZvPubc8F2deOfVJy0OUtvyY3ItKhO2yKaeGoSqWF6DnD1cBXr2/+UMwdkf4nVZODJq6KgYwOzu8pW9Y9YlL1ZeSRB9q8Zo/yUHriWW2+6A4xzW93O7xaaVu76VUDkRHgqXKGabM= Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by MWHPR1101MB2350.namprd11.prod.outlook.com (2603:10b6:300:75::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Wed, 10 Mar 2021 21:09:38 +0000 Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0%3]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 21:09:38 +0000 From: "Smith, Ned" To: Eliot Lear CC: Guy Fedorkow , Laurence Lundblade , "rats@ietf.org" , "iotops@ietf.org" Thread-Topic: [Rats] 802.1AR device identity Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoA= Date: Wed, 10 Mar 2021 21:09:38 +0000 Message-ID: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.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: 9d21b11f-4607-419e-fabe-08d8e408d0e2 x-ms-traffictypediagnostic: MWHPR1101MB2350: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cxaZ+9oJl7ZEbbFCdOZIiLmjvYUjcvGzRUmWb5+RaW4zbdgsTf4HeyZDCzDIKzTwtX3VPB3FtrCMo2WUEs/TYngsU6U2eII9/VwfweadZ5gB5mZxrHFLcj7KrGptnkJoo9+ABVPWmFkIRhisGbt0+rb4ZY4SF5H/+pPpedmC26WGfjK2ypK/CU6JLfuivW6elyD5Ovv4HBw/cL0M9lJibRLQFv4icfXcU9O5qZWlbbA5QHoNu/JJEKXL+C7BHuCAXnCYkBSgt+4NbzxdWrlm9Eu60cIdr6HqA/7tRN9EUyWX2dH73b4s0ZKRQucju3AS16eBTKtrvYT8UQ0lC+y+DYlhA56qRmv0UBWEiKrhm/BxCHZqCjdcOF00ccK/Ai7WvES1+Lwjd+uMEk+Sp2iVCmfxQPLmbR12hQzXFUEUykaSxlMf/BVEV+7KeiXbpBwd0AuF6Tuk7YVo/IB26H86u76dX+peme1W8QN5T7hKpdwulvcBblNkdsjI3zR+LwiGCYBhFuzpScjQlftGGcNgO9rrzR3z0gn0dFRHuMvg+PFaItUVCgloLBV3URihHKTncDJ+RdbqENAS7HLO9hg/NHSt/hmdqWNO0ftvLpkAaNsauO5rtKNrU4lU7+yqMxdLwCYX2sUcf4Xr3GQ87GM0vg== 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)(396003)(376002)(346002)(136003)(366004)(6916009)(66946007)(66556008)(66476007)(66446008)(186003)(76116006)(6512007)(8936002)(6486002)(71200400001)(478600001)(4326008)(64756008)(2906002)(36756003)(53546011)(6506007)(33656002)(316002)(8676002)(83380400001)(966005)(54906003)(2616005)(86362001)(26005)(166002)(5660300002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?R3o4RDZiSFhhYUFSaTdvLzZWczM0bW1HY1ByNGNkTWVEVGRYNHVHQ3BLSkxM?= =?utf-8?B?WmhaUmNpd1NQQXdHREZ2MTBkNFdjUC9UektXdmhqYnllRklrK3JJRlZNWVdU?= =?utf-8?B?ZVZFQUFRNUQ0TGlsQzdQUG1TUmU2V2FWdVl1NmxmZ2Z4eVpBK3l2clh0amlT?= =?utf-8?B?emJUempTWWU0K0xWQ3Q4Njl4aUd0bWJQNGRFR1hEOUtmSU1xQU90cVorMWdC?= =?utf-8?B?ZjB0OFZjNVVZcWpPTllyNjVwek1adEcxdlhOUGN3YVVmcEd6UGJIMzZ2T0lT?= =?utf-8?B?aEZvbGRRazhrRVhDYzdwQnc1WEVGRVNiWkJmY3hyNVNtYXd6RndrZWVscWI0?= =?utf-8?B?ajRNbDAvc3ZQUGx6YS9tTjduZlQxMWdmRklQY2J4U0gxVHlmSDJoMng3aXNs?= =?utf-8?B?cE44Wm5EeGw2TXZpK1ROYVJ1eFg4SDNkK0VTU0VFWEloTHZpaVRNWER5ek1W?= =?utf-8?B?N2lQSk5XSGsyTUNtYzdyWkxWeVE4b0dtT1diNGhHUHkzNXFiVTZaZDhreUM0?= =?utf-8?B?NnBYWlJYN3A5N1huTWVvZXVjalFnc2liZXVKWmpHdFdoVldiK01qQ0l5b3RR?= =?utf-8?B?TFpqZS9iTjV3RGdwQlJvaUxrekNaMzZQMytsRmdKb044dXc5cmxvTTg3UTBq?= =?utf-8?B?OGxvS0VNK1p0WHRzYWhEKzBXRFNUZDJkeTYvYk55dE5pVXcrU0tPbVZReTRv?= =?utf-8?B?TUM0ZWh6OEY3VUYrY2Vxd0VmTTI2eTBIeERFL01ndlVzMHVLSE1KTGo4OEM3?= =?utf-8?B?YUVQRllGeHRYZDRhUW1BUzZVZ3padjhtL3B2aEhXRHF3b3BKbGNFdW5UaU9r?= =?utf-8?B?YlZIQTZVOWl5VTZRenhncGRWTXBoSTFzbU4xZ0VkVklqWnVTS2lENE1LRFhC?= =?utf-8?B?cm42UGNmTUg3bnpSOVpBSTR1UktOdmx1a0NWTGd6VEdkZ0U4MTZheE13Q3VE?= =?utf-8?B?a3dNcWRCWXhDNUw2SUg5bjY5bVNPeUh0dlUwNTRjWS91RUI1K3BHWHk0YU5w?= =?utf-8?B?WDlkN0dFK3hwT3VsRWdlQlF2QzZ3RWF5cDcyRVI0cGRScEc4S3BCT2NjZFZr?= =?utf-8?B?NlQxY3lZdzRLK3FHK1p3eXRSUU5yM1NDRm0rNkMxTk01TDNaMmVUUU9aSUpE?= =?utf-8?B?TzVPWENpdUVQa2o1QjdDQWxJUXlielY3VUpYRVVacWdmeFkwZHhreC9IU0l3?= =?utf-8?B?QmJKV1pvZUhqN2dTcnpVZmdzZ0xNRWtnQzAxVUR2T09WTTM3ZS9RZVR4d0Jx?= =?utf-8?B?N1lPS1B2NGRTSmRGNnJDenVCeXJuc3ArL0duTmdGV04yK2Voc2Y5d2tiOTRq?= =?utf-8?B?Q2FIT1E5R0hHeWN1L09HMjkrMERWTEJXS3hoVTNFZ0FUeno0cXpJdmdkVjEx?= =?utf-8?B?UDlKSDZMSy9acW1QZnZHRVE0MXJrWk13SzF2QmpGTGFUdURzYVJJeUVtbHo3?= =?utf-8?B?Z1RZWkUraUQvY1ZoYzg0dkFYSmc1V25CVlU3VXpWYVpNZWVLYUVUdEtIMUY0?= =?utf-8?B?OG1EWHJyakovRXdJWmV5MUpvbENGNFQrM0lmeHF3M2xtZURSTkVRQzQyUHVN?= =?utf-8?B?MnZPTitEZTdDNmpLdEs3SDdxMElWUmwvdUVMa0d5NmxVR0EydjhLV01velRH?= =?utf-8?B?azVsOWd6TEhWajVpUjBJbEJSUXhmRmVrcXJlMXY0SDlNSm5wa3dtVDdQUXFz?= =?utf-8?B?MVUyMndDclhPVzNQdjQwNHFGcXRXSFB3QmRYMVMxODJHMWJTZlV1Tm1kdU5S?= =?utf-8?Q?T2l3k4C6rTF49vdhQcgsS5rhxZpd82qzn1pq6Fk?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0C1A8AE6E6C34AF99E4F5841FB450BE3intelcom_" 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: 9d21b11f-4607-419e-fabe-08d8e408d0e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 21:09:38.8053 (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: l4riY7WfBCwY9nNkWJxdO6aY19GHuKKgTGC21AainVwWXRn3/bazzf5pHUN0up2GA3dEWJBJ4x1KebiClarMrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2350 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, 10 Mar 2021 21:09:45 -0000 --_000_0C1A8AE6E6C34AF99E4F5841FB450BE3intelcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIOKAnGEgc3RhbmRhcmQgcHJvdGVjdGVkIFRMViBsaXN0ICB0aGF0IGRlcGxveW1l bnRzIGNvdWxkIHJlY2VpdmUgdGhyb3VnaCBhIHN0YW5kYXJkIGludGVyZmFjZS4gIFRoZXNlIGFy ZSBhdHRlc3RhdGlvbnMgb2YgYSBmb3Jt4oCdDQoNClRoZSBUTFYgbGlzdCBpcyBhIHN0YXRlbWVu dCBtYWRlIGJ5IGEgbWFudWZhY3R1cmVyIGFib3V0IHRoZSByZWNvdmVyYWJpbGl0eSBvZiBkZXZp Y2UgLyBkZXZpY2UgSUQuIFdlIG1pZ2h0IGNhbGwgdGhlbSBWZW5kb3IgQXNzZXJ0aW9ucyBmb3Ig bm93Lg0KDQpUaGUgUkFUUyBBcmNoIGRlc2NyaWJlcyBFbmRvcnNlbWVudHMgd2hpY2ggYXJlIOKA nHN0YXRlbWVudHMgYWJvdXQgdGhlIGludGVncml0eSBvZiB0aGUgc2lnbmluZyBjYXBhYmlsaXR5 4oCdLiBJdCBpc27igJl0IGNsZWFyIHRvIG1lIHRoYXQgbXV0YWJpbGl0eS9pbW11dGFiaWxpdHkg b2YgYW4gSWRldklEIGtleSBpcyBjb3ZlcmVkIHVuZGVyIHRoZSBkZWZpbml0aW9uIGZvciBFbmRv cnNlbWVudHMuIFRoZSBhcmNoaXRlY3R1cmUgZGlkbuKAmXQgZGVmaW5lIHRlcm1pbm9sb2d5IGZv ciBWZW5kb3IgQXNzZXJ0aW9ucyB0aGF0IGRvbuKAmXQgZml0IHRoZSBkZWZpbml0aW9uIGZvciBF bmRvcnNlbWVudHMgb3IgUmVmZXJlbmNlIFZhbHVlcy4NCg0KQnJpbmdpbmcgdGhpcyBiYWNrIHRv IHRoZSBvcmlnaW5hbCB0aHJlYWQuIFRoZSB2ZW5kb3IgaXMgbGlrZWx5IHRoZSBtb3N0IGF1dGhv cml0YXRpdmUgZW50aXR5IHRvIG1ha2UgYXNzZXJ0aW9ucyBhYm91dCB0aGUgbXV0YWJpbGl0eS9p bW11dGFiaWxpdHkgcHJvcGVydGllcyBvZiB0aGUgSURldklEIChrZXkpLiBJZiBhIHN0YW5kYXJk IHRyaWVzIHRvIGNvZGlmeSBpdCBpbiBhIHNwZWNpZmljYXRpb24gaXQgdGVuZHMgdG8gc3VmZmVy IGZyb20gYW1iaWd1aXR5IG9yIGl0IGRlZmluZXMgYW4gaW1wbGVtZW50YXRpb24uIChib3RoIGhh dmUgY29tcGxpYW5jZSBjaGFsbGVuZ2VzKQ0KDQpIZW5jZSwgYSByZWFzb25hYmxlIHdheSBmb3J3 YXJkIGlzIGZvciB2ZW5kb3JzIHRvIG1ha2UgY2xhaW1zIGFib3V0IElEZXZJRCBtdXRhYmlsaXR5 IHByb3BlcnRpZXMuIFByb3ZpZGluZyB0aGUgY29tbXVuaXR5IHdpdGggYSB2b2NhYnVsYXJ5IGZv ciBtYWtpbmcgc3VjaCBjbGFpbXMgaXMgcHJvYmFibHkgdGhlIGJlc3QgZmFjaWxpdGF0aW9uIGEg c3RhbmRhcmQgY291bGQgZG8uDQoNCkZyb206IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPg0K RGF0ZTogV2VkbmVzZGF5LCBNYXJjaCAxMCwgMjAyMSBhdCAxMjoyNyBQTQ0KVG86ICJTbWl0aCwg TmVkIiA8bmVkLnNtaXRoQGludGVsLmNvbT4NCkNjOiBHdXkgRmVkb3Jrb3cgPGdmZWRvcmtvdz00 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiwgTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNs YW5kLXJlc29ydC5jb20+LCAicmF0c0BpZXRmLm9yZyIgPHJhdHNAaWV0Zi5vcmc+LCA8aW90b3Bz QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtSYXRzXSA4MDIuMUFSIGRldmljZSBpZGVudGl0eQ0K DQpZZWFoLCB0aGlzIGlzIGFuIGlzc3VlIHRoYXQgY29tZXMgdXAgZnJvbSB0aW1lIHRvIHRpbWUu ICBIb3cg4oCcaW1tdXRhYmxl4oCdIHNob3VsZCB0aGF0IGlEZXZJRCBiZT8gIEnigJl2ZSBoYWQg dGhpcyB0aG91Z2h0IGluIHR3byBkaWZmZXJlbnQgY29udGV4dHM6DQrCtyAgICAgICAgIFdoYXQg aWYgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0sIENBLCBvciBwcml2YXRlIGtleSB1c2VkIHRvIHBy b3RlY3QgdGhlIGlEZXZJRCBoYXMgYmVlbiBjb21wcm9taXNlZD8gIENhbiBvbmUgcmVjb3ZlciB3 aXRoIGFuIHVwZGF0ZT8NCsK3ICAgICAgICAgV2hhdCBpZiB0aGVyZSBhcmUgYXR0cmlidXRlcyBp biB0aGUgY2VydCB0aGF0IEkgd2FudCB0byBkaW5rIGFuZCBzaGFyZSB3aXRoIHRoZSBkZXBsb3lt ZW50Pw0KDQpJ4oCZZCBsaWtlIHRvIHRha2UgdGhhdCBsYXR0ZXIgY2FzZSBvZmYgdGhlIHRhYmxl LCBidXQgdGhlbiB3ZSBuZWVkIHRvIHNlcmlvdXNseSB0aGluayBhYm91dCBSQVRTIG9yIFNVSVQg cHJvdmlkaW5nIGEgc3RhbmRhcmQgcHJvdGVjdGVkIFRMViBsaXN0ICB0aGF0IGRlcGxveW1lbnRz IGNvdWxkIHJlY2VpdmUgdGhyb3VnaCBhIHN0YW5kYXJkIGludGVyZmFjZS4gIFRoZXNlIGFyZSBh dHRlc3RhdGlvbnMgb2YgYSBmb3JtLCBidXQgdGhleeKAmXJlIG5vdCByZWFsbHkgbWVhc3VyZW1l bnRzLCBhcyBoYXMgYmVlbiBwcmV2aW91c2x5IGRpc2N1c3NlZCBoZXJlLg0KDQpFbGlvdA0KDQoN Cg0KT24gMTAgTWFyIDIwMjEsIGF0IDIwOjAyLCBTbWl0aCwgTmVkIDxuZWQuc21pdGhAaW50ZWwu Y29tPG1haWx0bzpuZWQuc21pdGhAaW50ZWwuY29tPj4gd3JvdGU6DQoNClRoZSA4MDIuMUFSIHNw ZWMgZG9lc27igJl0IEFGQUlLIHJlcXVpcmUgSURldklEcyB0aGF0IGNhbuKAmXQgY2hhbmdlLiBC dXQgbm90IGN1cnRhaW4uIElzIHNheXMgdGhpbmdzIGxpa2U6DQpBDQpkZXZpY2XigJlzIERldklE IG1vZHVsZSBzdG9yZXMgZWFjaCBvZiBpdHMgRGV2SUQgc2VjcmV0cyBzZWN1cmVseSBhbmQgc3Vw cG9ydHMgc2lnbmluZyBvcGVyYXRpb25zIHRoYXQgcHJvdmUNCnBvc3Nlc3Npb24gb2YgdGhlIHNl Y3JldCAoYW5kIHRodXMgdGhhdCB0aGUgZGV2aWNlIGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBhc3Nv Y2lhdGVkIERldklEIGNlcnRpZmljYXRlKSwgd2hpbGUNCmVuc3VyaW5nIHRoYXQgdGhlIHNlY3Jl dCByZW1haW5zIGNvbmZpZGVudGlhbCBzbyB0aGUgZGV2aWNlIGNhbm5vdCBiZSBpbXBlcnNvbmF0 ZWQgYnkgb3RoZXJzLg0KQW4gSW5pdGlhbCBEZXZpY2UgSWRlbnRpZmllciAoSURldklEKSBwcm92 aWRlZCBieSBhIGRldmljZeKAmXMgc3VwcGxpZXIgY2FuIGJlIHN1cHBsZW1lbnRlZCBieSBvbmUg b3IgbW9yZQ0KTG9jYWwgRGV2aWNlIElkZW50aWZpZXJzIChMRGV2SURzKSwgZWFjaCB1c2luZyBh biBleGlzdGluZyBvciBhIGZyZXNobHkgZ2VuZXJhdGVkIHNlY3JldCwgZmFjaWxpdGF0aW5nDQpl bnJvbGxtZW50IChwcm92aXNpb25pbmcgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRp b24gY3JlZGVudGlhbHMgdG8gYXV0aGVudGljYXRlZCBkZXZpY2VzKSBieSBhIGxvY2FsDQpuZXR3 b3JrIGFkbWluaXN0cmF0b3IuDQoNCkEgZGV2aWNlIHdpdGggRGV2SUQgY2FwYWJpbGl0eSBpbmNv cnBvcmF0ZXMgYSBnbG9iYWxseSB1bmlxdWUgbWFudWZhY3R1cmVyIHByb3ZpZGVkIEluaXRpYWwg RGV2aWNlDQpJZGVudGlmaWVyIChJRGV2SUQpLCBzdG9yZWQgaW4gYSB3YXkgdGhhdCBwcm90ZWN0 cyBpdCBmcm9tIG1vZGlmaWNhdGlvbi4NCg0KTERldklEcyBjYW4gYWxzbyBiZSB1c2VkIGFzIHRo ZSBzb2xlIGlkZW50aWZpZXIgKGJ5IGRpc2FibGluZyB0aGUgSURldklEKSB0bw0KYXNzdXJlIHRo ZSBwcml2YWN5IG9mIHRoZSB1c2VyIG9mIGEgRGV2SUQgYW5kIHRoZSBlcXVpcG1lbnQgaW4gd2hp Y2ggaXQgaXMgaW5zdGFsbGVkLg0KDQotTmVkDQpGcm9tOiBSQVRTIDxyYXRzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnJhdHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBHdXkgRmVk b3Jrb3cgPGdmZWRvcmtvdz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzpnZmVk b3Jrb3c9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBXZWRuZXNkYXksIE1h cmNoIDEwLCAyMDIxIGF0IDc6NTkgQU0NClRvOiBMYXVyZW5jZSBMdW5kYmxhZGUgPGxnbEBpc2xh bmQtcmVzb3J0LmNvbTxtYWlsdG86bGdsQGlzbGFuZC1yZXNvcnQuY29tPj4NCkNjOiAicmF0c0Bp ZXRmLm9yZzxtYWlsdG86cmF0c0BpZXRmLm9yZz4iIDxyYXRzQGlldGYub3JnPG1haWx0bzpyYXRz QGlldGYub3JnPj4NClN1YmplY3Q6IFtSYXRzXSA4MDIuMUFSIGRldmljZSBpZGVudGl0eQ0KDQpI aSBMYXVyZW5jZSwNCiAgV2UgdGFsa2VkIGFib3V0IGRldmljZSBpZGVudGl0eSBvbiB0aGUgUkFU UyBjYWxsIHRvZGF5Lg0KICBGb3IgUklWLCB3ZeKAmXJlIHJlbHlpbmcgb24gdGhpcyBJRUVFIHNw ZWM6DQpodHRwczovLzEuaWVlZTgwMi5vcmcvc2VjdXJpdHkvODAyLTFhci8NCiAgVGhhdCBzcGVj IGRlZmluZXMgSW5pdGlhbCBhbmQgTG9jYWwgRGV2aWNlIElkZW50aXRpZXMuICBJbml0aWFsIERl dklEIGlzIHNldCBieSB0aGUgbWFudWZhY3R1cmVyIGFuZCBjYW7igJl0IGJlIGNoYW5nZWQgb3Ig cmVwbGFjZWQsIHdoaWxlIHRoZSBMb2NhbCBEZXZJRCBjYW4gYmUgc2V0IGFuZCBlcmFzZWQgYnkg dGhlIG93bmVyIG9mIHRoZSBnZWFyLg0KICBUaGUgc3BlYyBkb2VzbuKAmXQgYWRkcmVzcyBkZWNp ZGluZyB3aGljaCBpZGVudGl0eSB0byB1c2UgZm9yIGFueSBzcGVjaWZpYyBhcHBsaWNhdGlvbiwg YnV0IHRoZSBpbnRlbnQgY2xlYXJseSBpcyB0byBhbGxvdyB0aGUgb3duZXIgdG8gdXNlIHRoZSBt YW51ZmFjdHVyZXItc3VwcGxpZWQgaWRlbnRpdHkgdG8gaW5zdGFsbCBhbiBvd25lci1zcGVjaWZp YyBpZGVudGl0eSBpbiBhIGRldmljZSwgYW5kIGVyYXNlIHRoZSBvd25lci1zcGVjaWZpYyBpZGVu dGl0eSBsZWF2aW5nIHRoZSBtYW51ZmFjdHVyZXIgaWRlbnRpdHkgaW4gcGxhY2Ugd2hlbiB0aGUg ZGV2aWNlIGlzIGRlY29tbWlzc2lvbmVkLg0KDQogIE1hbnkgZGlmZmVyZW50IHNwZWNzIG11c3Qg aGF2ZSBleGFtaW5lZCB0aGlzIHByb2JsZW0sIGJ1dCBvZiBjb3Vyc2UgaXQgbmV2ZXIgaHVydHMg dG8gcmUtdXNlIHNvbWUgb2YgdGhlc2UgaWRlYXMgd2hlcmUgcG9zc2libGUuDQogIFRoeA0KL2d1 eQ0KDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClJBVFMgbWFpbGluZyBsaXN0DQpSQVRTQGlldGYu b3JnPG1haWx0bzpSQVRTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yYXRzDQoNCg== --_000_0C1A8AE6E6C34AF99E4F5841FB450BE3intelcom_ Content-Type: text/html; charset="utf-8" Content-ID: <4425FB742427B642B5BFF6BB1E5685DC@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBDU1wpIjsNCglwYW5v c2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpwLm1zaXBm b290ZXIzMGIzZDUzOCwgbGkubXNpcGZvb3RlcjMwYjNkNTM4LCBkaXYubXNpcGZvb3RlcjMwYjNk NTM4DQoJe21zby1zdHlsZS1uYW1lOm1zaXBmb290ZXIzMGIzZDUzODsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzk4NTUzOTYzOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotNTI1MTUyNzEyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5SZWdhcmRpbmcg4oCcPC9zcGFuPmEgc3RhbmRhcmQgcHJvdGVjdGVkIFRM ViBsaXN0ICZuYnNwO3RoYXQgZGVwbG95bWVudHMgY291bGQgcmVjZWl2ZSB0aHJvdWdoIGEgc3Rh bmRhcmQgaW50ZXJmYWNlLiAmbmJzcDtUaGVzZSBhcmUgYXR0ZXN0YXRpb25zIG9mIGEgZm9ybeKA nQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIFRMViBsaXN0IGlzIGEgc3RhdGVtZW50IG1hZGUgYnkg YSBtYW51ZmFjdHVyZXIgYWJvdXQgdGhlIHJlY292ZXJhYmlsaXR5IG9mIGRldmljZSAvIGRldmlj ZSBJRC4gV2UgbWlnaHQgY2FsbCB0aGVtIFZlbmRvciBBc3NlcnRpb25zIGZvciBub3cuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIFJBVFMgQXJjaCBkZXNjcmliZXMgRW5kb3JzZW1lbnRz IHdoaWNoIGFyZSDigJxzdGF0ZW1lbnRzIGFib3V0IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIHNpZ25p bmcgY2FwYWJpbGl0eeKAnS4gSXQgaXNu4oCZdCBjbGVhciB0byBtZSB0aGF0IG11dGFiaWxpdHkv aW1tdXRhYmlsaXR5IG9mIGFuIElkZXZJRCBrZXkgaXMgY292ZXJlZCB1bmRlciB0aGUgZGVmaW5p dGlvbg0KIGZvciBFbmRvcnNlbWVudHMuIFRoZSBhcmNoaXRlY3R1cmUgZGlkbuKAmXQgZGVmaW5l IHRlcm1pbm9sb2d5IGZvciBWZW5kb3IgQXNzZXJ0aW9ucyB0aGF0IGRvbuKAmXQgZml0IHRoZSBk ZWZpbml0aW9uIGZvciBFbmRvcnNlbWVudHMgb3IgUmVmZXJlbmNlIFZhbHVlcy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5CcmluZ2luZyB0aGlzIGJhY2sgdG8gdGhlIG9yaWdpbmFsIHRocmVh ZC4gVGhlIHZlbmRvciBpcyBsaWtlbHkgdGhlIG1vc3QgYXV0aG9yaXRhdGl2ZSBlbnRpdHkgdG8g bWFrZSBhc3NlcnRpb25zIGFib3V0IHRoZSBtdXRhYmlsaXR5L2ltbXV0YWJpbGl0eSBwcm9wZXJ0 aWVzIG9mIHRoZSBJRGV2SUQgKGtleSkuIElmIGEgc3RhbmRhcmQgdHJpZXMNCiB0byBjb2RpZnkg aXQgaW4gYSBzcGVjaWZpY2F0aW9uIGl0IHRlbmRzIHRvIHN1ZmZlciBmcm9tIGFtYmlndWl0eSBv ciBpdCBkZWZpbmVzIGFuIGltcGxlbWVudGF0aW9uLiAoYm90aCBoYXZlIGNvbXBsaWFuY2UgY2hh bGxlbmdlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGVuY2UsIGEgcmVhc29uYWJsZSB3YXkg Zm9yd2FyZCBpcyBmb3IgdmVuZG9ycyB0byBtYWtlIGNsYWltcyBhYm91dCBJRGV2SUQgbXV0YWJp bGl0eSBwcm9wZXJ0aWVzLiBQcm92aWRpbmcgdGhlIGNvbW11bml0eSB3aXRoIGEgdm9jYWJ1bGFy eSBmb3IgbWFraW5nIHN1Y2ggY2xhaW1zIGlzIHByb2JhYmx5IHRoZSBiZXN0IGZhY2lsaXRhdGlv bg0KIGEgc3RhbmRhcmQgY291bGQgZG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5FbGlvdCBMZWFyICZs dDtsZWFyQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXJjaCAx MCwgMjAyMSBhdCAxMjoyNyBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7U21pdGgsIE5lZCZxdW90 OyAmbHQ7bmVkLnNtaXRoQGludGVsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkd1eSBGZWRvcmtv dyAmbHQ7Z2ZlZG9ya293PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7LCBMYXVyZW5j ZSBMdW5kYmxhZGUgJmx0O2xnbEBpc2xhbmQtcmVzb3J0LmNvbSZndDssICZxdW90O3JhdHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O3JhdHNAaWV0Zi5vcmcmZ3Q7LCAmbHQ7aW90b3BzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1JhdHNdIDgwMi4xQVIgZGV2aWNlIGlkZW50aXR5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WWVhaCwgdGhp cyBpcyBhbiBpc3N1ZSB0aGF0IGNvbWVzIHVwIGZyb20gdGltZSB0byB0aW1lLiAmbmJzcDtIb3cg 4oCcaW1tdXRhYmxl4oCdIHNob3VsZCB0aGF0IGlEZXZJRCBiZT8gJm5ic3A7SeKAmXZlIGhhZCB0 aGlzIHRob3VnaHQgaW4gdHdvIGRpZmZlcmVudCBjb250ZXh0czo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPldoYXQgaWYgdGhlIHNp Z25hdHVyZSBhbGdvcml0aG0sIENBLCBvciBwcml2YXRlIGtleSB1c2VkIHRvIHByb3RlY3QgdGhl IGlEZXZJRCBoYXMgYmVlbiBjb21wcm9taXNlZD8gJm5ic3A7Q2FuIG9uZSByZWNvdmVyIHdpdGgg YW4gdXBkYXRlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5XaGF0IGlmIHRoZXJlIGFyZSBhdHRyaWJ1dGVzIGluIHRoZSBjZXJ0IHRoYXQgSSB3 YW50IHRvIGRpbmsgYW5kIHNoYXJlIHdpdGggdGhlIGRlcGxveW1lbnQ/PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPknigJlkIGxpa2UgdG8gdGFrZSB0aGF0IGxhdHRlciBj YXNlIG9mZiB0aGUgdGFibGUsIGJ1dCB0aGVuIHdlIG5lZWQgdG8gc2VyaW91c2x5IHRoaW5rIGFi b3V0IFJBVFMgb3IgU1VJVCBwcm92aWRpbmcgYSBzdGFuZGFyZCBwcm90ZWN0ZWQgVExWIGxpc3Qg Jm5ic3A7dGhhdCBkZXBsb3ltZW50cyBjb3VsZCByZWNlaXZlIHRocm91Z2ggYSBzdGFuZGFyZCBp bnRlcmZhY2UuICZuYnNwO1RoZXNlDQogYXJlIGF0dGVzdGF0aW9ucyBvZiBhIGZvcm0sIGJ1dCB0 aGV54oCZcmUgbm90IHJlYWxseSBtZWFzdXJlbWVudHMsIGFzIGhhcyBiZWVuIHByZXZpb3VzbHkg ZGlzY3Vzc2VkIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gMTAgTWFyIDIwMjEsIGF0IDIw OjAyLCBTbWl0aCwgTmVkICZsdDs8YSBocmVmPSJtYWlsdG86bmVkLnNtaXRoQGludGVsLmNvbSI+ bmVkLnNtaXRoQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlRoZSA4MDIuMUFSIHNwZWMgZG9lc27igJl0IEFGQUlLIHJlcXVpcmUgSURldklE cyB0aGF0IGNhbuKAmXQgY2hhbmdlLiBCdXQgbm90IGN1cnRhaW4uIElzIHNheXMgdGhpbmdzIGxp a2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5kZXZpY2Xi gJlzIERldklEIG1vZHVsZSBzdG9yZXMgZWFjaCBvZiBpdHMgRGV2SUQgc2VjcmV0cyBzZWN1cmVs eSBhbmQgc3VwcG9ydHMgc2lnbmluZyBvcGVyYXRpb25zIHRoYXQgcHJvdmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpI ZWx2ZXRpY2EiPnBvc3Nlc3Npb24gb2YgdGhlIHNlY3JldCAoYW5kIHRodXMgdGhhdCB0aGUgZGV2 aWNlIGlzIHRoZSBzdWJqZWN0IG9mIHRoZSBhc3NvY2lhdGVkIERldklEIGNlcnRpZmljYXRlKSwg d2hpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPmVuc3VyaW5nIHRoYXQgdGhlIHNlY3JldCByZW1h aW5zIGNvbmZpZGVudGlhbCBzbyB0aGUgZGV2aWNlIGNhbm5vdCBiZSBpbXBlcnNvbmF0ZWQgYnkg b3RoZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+QW4gSW5pdGlhbCBEZXZpY2UgSWRlbnRpZmll ciAoSURldklEKSBwcm92aWRlZCBieSBhIGRldmljZeKAmXMgc3VwcGxpZXIgY2FuIGJlIHN1cHBs ZW1lbnRlZCBieSBvbmUgb3IgbW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+TG9jYWwgRGV2aWNl IElkZW50aWZpZXJzIChMRGV2SURzKSwgZWFjaCB1c2luZyBhbiBleGlzdGluZyBvciBhIGZyZXNo bHkgZ2VuZXJhdGVkIHNlY3JldCwgZmFjaWxpdGF0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5l bnJvbGxtZW50IChwcm92aXNpb25pbmcgb2YgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRp b24gY3JlZGVudGlhbHMgdG8gYXV0aGVudGljYXRlZCBkZXZpY2VzKSBieSBhIGxvY2FsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhIj5uZXR3b3JrIGFkbWluaXN0cmF0b3IuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkEgZGV2aWNlIHdpdGggRGV2SUQgY2Fw YWJpbGl0eSBpbmNvcnBvcmF0ZXMgYSBnbG9iYWxseSB1bmlxdWUgbWFudWZhY3R1cmVyIHByb3Zp ZGVkIEluaXRpYWwgRGV2aWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5JZGVudGlmaWVyIChJRGV2 SUQpLCBzdG9yZWQgaW4gYSB3YXkgdGhhdCBwcm90ZWN0cyBpdCBmcm9tIG1vZGlmaWNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkxEZXZJRHMg Y2FuIGFsc28gYmUgdXNlZCBhcyB0aGUgc29sZSBpZGVudGlmaWVyIChieSBkaXNhYmxpbmcgdGhl IElEZXZJRCkgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPmFzc3VyZSB0aGUgcHJpdmFjeSBvZiB0 aGUgdXNlciBvZiBhIERldklEIGFuZCB0aGUgZXF1aXBtZW50IGluIHdoaWNoIGl0IGlzIGluc3Rh bGxlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tTmVk PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UkFUUyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJhdHMtYm91bmNlc0BpZXRmLm9yZyI+cmF0cy1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIEd1eQ0KIEZlZG9ya293ICZsdDs8YSBocmVmPSJtYWlsdG86Z2ZlZG9y a293PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmciPmdmZWRvcmtvdz00MGp1bmlwZXIubmV0 QGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5LCBNYXJjaCAxMCwgMjAy MSBhdCA3OjU5IEFNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvYj5MYXVyZW5jZSBMdW5kYmxhZGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpsZ2xAaXNsYW5kLXJlc29ydC5jb20iPmxnbEBpc2xhbmQtcmVzb3J0LmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cmF0c0BpZXRmLm9yZyI+cmF0c0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyYXRzQGlldGYub3JnIj5yYXRzQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+W1JhdHNdIDgwMi4xQVIgZGV2aWNlIGlkZW50aXR5PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5IaSBMYXVyZW5jZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7IFdlIHRhbGtlZCBhYm91dCBkZXZpY2UgaWRlbnRpdHkgb24gdGhlIFJB VFMgY2FsbCB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7IEZvciBSSVYsIHdl4oCZcmUgcmVseWluZyBvbiB0aGlzIElFRUUgc3BlYzo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGEgaHJlZj0iaHR0cHM6 Ly8xLmllZWU4MDIub3JnL3NlY3VyaXR5LzgwMi0xYXIvIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1 NjNDMSI+aHR0cHM6Ly8xLmllZWU4MDIub3JnL3NlY3VyaXR5LzgwMi0xYXIvPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7IFRoYXQg c3BlYyBkZWZpbmVzIEluaXRpYWwgYW5kIExvY2FsIERldmljZSBJZGVudGl0aWVzLiZuYnNwOyBJ bml0aWFsIERldklEIGlzIHNldCBieSB0aGUgbWFudWZhY3R1cmVyIGFuZCBjYW7igJl0IGJlIGNo YW5nZWQgb3IgcmVwbGFjZWQsIHdoaWxlIHRoZSBMb2NhbCBEZXZJRCBjYW4gYmUgc2V0IGFuZCBl cmFzZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBnZWFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgVGhlIHNwZWMgZG9lc27igJl0IGFkZHJlc3MgZGVj aWRpbmcgd2hpY2ggaWRlbnRpdHkgdG8gdXNlIGZvciBhbnkgc3BlY2lmaWMgYXBwbGljYXRpb24s IGJ1dCB0aGUgaW50ZW50IGNsZWFybHkgaXMgdG8gYWxsb3cgdGhlIG93bmVyIHRvIHVzZSB0aGUg bWFudWZhY3R1cmVyLXN1cHBsaWVkIGlkZW50aXR5IHRvIGluc3RhbGwgYW4gb3duZXItc3BlY2lm aWMgaWRlbnRpdHkNCiBpbiBhIGRldmljZSwgYW5kIGVyYXNlIHRoZSBvd25lci1zcGVjaWZpYyBp ZGVudGl0eSBsZWF2aW5nIHRoZSBtYW51ZmFjdHVyZXIgaWRlbnRpdHkgaW4gcGxhY2Ugd2hlbiB0 aGUgZGV2aWNlIGlzIGRlY29tbWlzc2lvbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7IE1hbnkgZGlmZmVyZW50IHNwZWNzIG11c3QgaGF2ZSBleGFtaW5l ZCB0aGlzIHByb2JsZW0sIGJ1dCBvZiBjb3Vyc2UgaXQgbmV2ZXIgaHVydHMgdG8gcmUtdXNlIHNv bWUgb2YgdGhlc2UgaWRlYXMgd2hlcmUgcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyBUaHg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+L2d1eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJtc2lwZm9v dGVyMzBiM2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjBpbjt0 ZXh0LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij5KdW5pcGVy IEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpSQVRTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpSQVRTQGlldGYub3JnIj5SQVRTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmF0cyI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yYXRzPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0C1A8AE6E6C34AF99E4F5841FB450BE3intelcom_-- From nobody Wed Mar 10 13:19: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 864EE3A186D for ; Wed, 10 Mar 2021 13:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=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 7gwjBS-2sW2Z for ; Wed, 10 Mar 2021 13:19:12 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 3E3663A186C for ; Wed, 10 Mar 2021 13:19:12 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id 130so18453933qkh.11 for ; Wed, 10 Mar 2021 13:19:12 -0800 (PST) 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=P9gY9r699eEaOhc483rCiJ7wIWWzvBZz7VHWvF9MuU4=; b=Q5sqtV02CdgV4T7nwubDyjuH2E/7dZ1VMndKOdjfEW3fn5rfxygXKl3hk/sk3+BTfP TmUeH2TJyNyuMchIz3BFwgIw0khrP0wLHHH6uqMoCh8jgI5bVDJuPgoYGKGyPQYOUX4w B5ab++58/GN9oAc848AezVPCcsLwQDpjQaA/MHS69JP3OquehZ0AH2hueG4SeA20qq7s /zK3e/o/9nXxLNYKZK7IKFueZDAYPQbKB71Re06LLK4zzujFcDKQvJxsir8C2EbWycL2 G6zIFqvEs1hCAY15l2ebT89z2TSUYVJy9B0ngmgGHqQWkrT88z5knw62kx+Xuh56QeK3 WZOQ== 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=P9gY9r699eEaOhc483rCiJ7wIWWzvBZz7VHWvF9MuU4=; b=OZIiraPDBK7Vuv9bF0LF0GQiAFv85g5OkViKEW9J4aOz7LSTW0vumrbWZqjFQZQlVw 4pYRQnUrDlWMiCZOsS/h9UZjXd48zPdpsHT4jypLI11ZrTq6StPpahjpFaQcoxXzX476 wd23Kek/OzO8QMXLltIORl2OIDzrARBzRsBFWXN+PcSUpdgR6k65J1HgTmRDjy0aY/Hs yZBapJk2CJ095I1OW1rhuC6JTK390MoSl+lm6PiJFf3sjIyFukLDgbY9ljhZ0pAQYMsO jci8iGcQSMIY168qVSQ/mjYEymWwW3mAL+F+G3O9IggrvHpEwoF9zpGGQYf8vbMt4jX0 mDpw== X-Gm-Message-State: AOAM533KXJINvOFGkBLUGUgozJQLntUi6/+7/Ru/lshEhZFI8CHINYov 5ozJaIEHioweCDU1bsPjijEYVIE9HJcgF5qNcnQLFW4dIzg0T+l9 X-Google-Smtp-Source: ABdhPJxdNEuB/BNfFHAcAr89obKUIhs6EC1thkB/GjChzWYT/4B59ymZK17nXZEgAZZbvFqkfWeblFyR4shcl12DeBo= X-Received: by 2002:a37:ba45:: with SMTP id k66mr4679576qkf.423.1615411149206; Wed, 10 Mar 2021 13:19:09 -0800 (PST) MIME-Version: 1.0 References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com> <2FE1E13B-E313-43F9-932E-6682DF72E18D@cisco.com> <20201117074330.GP39343@faui48f.informatik.uni-erlangen.de> <692795.1606948121@dooku> <2085.1607021035@localhost> In-Reply-To: From: Ash Wilson Date: Wed, 10 Mar 2021 13:18:58 -0800 Message-ID: To: Michael Richardson , iotops@ietf.org Cc: "iot-onboarding@ietf.org" , Shumon Huque Content-Type: multipart/alternative; boundary="000000000000b706f705bd353776" Archived-At: Subject: Re: [Iotops] [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome 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, 10 Mar 2021 21:19:15 -0000 --000000000000b706f705bd353776 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, Reviving this thread (and cross-posting to iotops) to tie in the BoF on Friday, on this topic. The DANISH BoF is scheduled on Friday at 13:00 GMT+1 ( https://datatracker.ietf.org/wg/danish/meetings/) In a general sense, this BoF proposes the use of DANE for TLS client identity, as well as certificate discovery for object security (signing/encryption) use cases. We will be discussing three drafts, together with a conversation on the problem space and the use cases that may benefit from this approach. The first two were published ahead of scheduling the BoF, and the third was published early this week: https://tools.ietf.org/html/draft-huque-dane-client-cert-05 https://tools.ietf.org/html/draft-huque-tls-dane-clientid-04 https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd Hope to see you there! -Ash On Fri, Dec 4, 2020 at 11:28 AM Ash Wilson wrote: > > > On Thu, Dec 3, 2020 at 1:44 PM Michael Richardson > wrote: > >> >> Hi, I don't want to religate the email again. >> I accept pretty much all your claims, except that: >> >> > I can run my own CA if I need to... But the need to do so diminishes i= f >> > DANE allows me to avoid name collisions and to perform mutual auth >> without >> > having to distribute CA certificates. >> >> This seems to imply that running a private CA is at least an order of >> magnitude harder than managing a DNS zone containing TLSA records, >> and which is probably DNSSEC signed. >> >> It is unclear to that your application needs either: it seems like it ju= st >> needs a database of public keys which are authorized, and you already >> seem to >> assume the existence of a radius server with a database backend. >> I think that radius servers can be as complex as signed DNS zones, or >> simple private CAs. >> >> I'm sorry to be obtuse here: others will ask the question. >> > > I really appreciate your feedback. The more questions we answer now, the > fewer we will need to answer later on. > I agree- RADIUS can be quite complicated. The hope is that if the CA and > DNS are operated by the manufacturer/supplier, the amount of configuratio= n > complexity required for RADIUS or other EAP-TLS authentication server (if > operated by the application owner or network manager) might be reduced. > > We can't eliminate all complexity, but there may be an opportunity to > simplify and shift some complexity up the supply chain and away from the > application owner. By allowing the supplier to take on some of the > responsibility for identity (via PKI and DNS), the application owner may > more easily (or less expensively) use strong device identity. I'm making > the assumptions that the application owner (1) has influence on security > aspects of the application design, (2) wants to build a secure > application, and (3) wants to minimize complexity in implementation. The > hope is that reducing the application owner's complexity (authentication > infrastructure) and expense (human labor) for PKI-based authentication wi= ll > encourage broader adoption. > > >> It sounds like your application is primarily a mp2p data flow >> (device->cloud). >> I'm finding it difficult to see why a DNS zone full of TLSA records is >> even >> required. > > > The simplification gains are definitely greater as the application > becomes more complex/decoupled/m2m. > If the communication pattern is directly device-to-cloud, then it may mak= e > more sense to just work with traditional PKI, private CA, etc... This is > certainly not a silver bullet for all IoT authentication needs :-) > > There's a point of complexity where it makes more sense to take the DANE > approach, and I suspect that it will be driven by a few aspects: > * How many device suppliers will my application have? > * Can my suppliers ship devices with identities already in DNS? > * Does my application make use of messaging middleware, like MQTT brokers > and message queues? > * How much do I trust the middleware to resist unauthorized > access/behavior? (level of comfort with implied trust) > * What is the potential impact of message sender impersonation in my > application? > * Should I be signing messages to help prevent sending device > impersonation? > > >> > If we get into e2e (m2m) data flows, then the ability for one device to >> validate another device without directly communicating with a third part= y >> is >> a win. For that, a private CA or a DNS zone of TLSA keys, particularly, >> as >> you say, that DNSSEC record cache proposal, makes perfect sense to me. >> >> My proposal going forward: >> section 2 of draft-huque-dane-client-cert >> >> needs to expand to a couple of pages. >> >> The SMTP use case should probably get it's own section; perhaps its own >> document actually. >> >> I think that: >> TLS Extension for DANE Client Identity >> draft-huque-tls-dane-clientid-03 >> >> is clear and simple, and once we figure out where huque-dane-client-cert >> goes, then I think that this document should just be referred to the TLS >> WG. >> The previous document should then provide adequate explanation of the >> context. >> >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consu= lting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> > > -- > > *Ash Wilson* | Technical Director > *e:* ash.wilson@valimail.com > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibit= ed > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > --=20 *Ash Wilson* | Technical Director *e:* ash.wilson@valimail.com ` This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000b706f705bd353776 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,
Reviving this thread (and cross-posting to i= otops) to tie in the BoF on Friday, on this topic.

The DANISH BoF is scheduled on Friday at 13:00 GMT+1 (https://datatracker.ietf.org/wg/da= nish/meetings/)=C2=A0

In a general sense, this= BoF proposes the use of DANE for TLS client identity, as well as certifica= te discovery for object security (signing/encryption) use cases.
=
We will be discussing three drafts,=C2=A0together with a con= versation on the problem space and the use cases that may benefit from this= approach.=C2=A0

The first two were published ahea= d of scheduling the BoF, and the third was published early this week:
=

Hope to see you there!

-Ash

<= div class=3D"gmail_quote">
On Fri, Dec= 4, 2020 at 11:28 AM Ash Wilson <ash.wilson@valimail.com> wrote:


=
On Thu, De= c 3, 2020 at 1:44 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Hi, I don't want to religate the email again.
I accept pretty much all your claims, except that:

> I can run my own CA if I need to... But the need to do so diminishes i= f
> DANE allows me to avoid name collisions and to perform mutual auth wit= hout
> having to distribute CA certificates.

This seems to imply that running a private CA is at least an order of
magnitude harder than managing a DNS zone containing TLSA records,
and which is probably DNSSEC signed.

It is unclear to that your application needs either: it seems like it just<= br> needs a database of public keys which are authorized, and you already seem = to
assume the existence of a radius server with a database backend.
I think that radius servers can be as complex as signed DNS zones, or simpl= e private CAs.

I'm sorry to be obtuse here: others will ask the question.
=C2=A0
I really appreciate your feedback. The more quest= ions we answer now, the fewer we will need to answer later on.
I = agree- RADIUS can be quite complicated. The hope is that if the CA and DNS = are operated by the manufacturer/supplier, the amount of configuration comp= lexity required for RADIUS or other EAP-TLS authentication server (if opera= ted by the application owner or network manager) might be reduced.=C2=A0

We can't eliminate all complexity,=C2=A0but ther= e may be an opportunity to simplify and shift some complexity up the supply= chain and away from the application owner. By allowing the supplier to tak= e on some of the responsibility for identity (via PKI and DNS), the applica= tion owner may more easily (or less expensively) use strong device identity= . I'm making the assumptions that the application owner (1) has influen= ce on security aspects of the application design, (2) wants to build a secu= re application,=C2=A0and (3) wants to minimize complexity in implementation= . The hope is that reducing the=C2=A0application owner's complexity (au= thentication infrastructure) and expense (human labor) for PKI-based authen= tication will encourage broader adoption.


It sounds like your application is primarily a mp2p data flow (device->c= loud).
I'm finding it difficult to see why a DNS zone full of TLSA records is = even
required.
=C2=A0
The simplification gains are de= finitely greater as the application becomes=C2=A0more complex/decoupled/m2m= .
If the communication pattern is directly device-to-cloud, then = it may make more sense to just work with traditional PKI,=C2=A0private CA, = etc... This is certainly not a silver bullet for all IoT authentication nee= ds :-)

There's a point of complexity where it = makes more sense to take the DANE approach, and I suspect that it will be d= riven by a few aspects:
* How many device suppliers will my appli= cation have?
* Can my suppliers ship devices with identities alre= ady in DNS?
* Does my application make use of messaging middlewar= e, like MQTT brokers and message queues?
=C2=A0 * How much do I t= rust the middleware to resist unauthorized access/behavior?=C2=A0(level of = comfort with implied trust)
=C2=A0 * What is the potential impact= of message sender impersonation in my application?
=C2=A0 * Shou= ld I be signing messages to help prevent sending device impersonation?

=C2=A0
If we get into e2e=C2=A0 (m2m) data flows, then the ability for one device = to
validate another device without directly communicating with a third party i= s
a win.=C2=A0 For that, a private CA or a DNS zone of TLSA keys, particularl= y, as
you say, that DNSSEC record cache proposal, makes perfect sense to me.

My proposal going forward:
=C2=A0 =C2=A0section 2 of draft-huque-dane-client-cert

needs to expand to a couple of pages.

The SMTP use case should probably get it's own section; perhaps its own=
document actually.

I think that:
=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS Extension for DANE Client Identity
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-huque-tls-dane-clientid-03
is clear and simple, and once we figure out where huque-dane-client-cert goes, then I think that this document should just be referred to the TLS WG= .
The previous document should then provide adequate explanation of the
context.

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



--


--

Ash Wilson | Technical Dire= ctor

=

`

This email= and all data transmitted with it contains confidential and/or proprietary = information intended solely for the use of individual(s) authorized to rece= ive it. If you are not an intended and authorized recipient you are hereby = notified of any use, disclosure, copying or distribution of the information= included in this transmission is prohibited and may be unlawful. Please im= mediately notify the sender by replying to this email and then delete it fr= om your system.

--000000000000b706f705bd353776-- From nobody Thu Mar 11 01:54:02 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 236E03A1779; Thu, 11 Mar 2021 01:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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_PASS=-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 d0m_haZip5nU; Thu, 11 Mar 2021 01:53:58 -0800 (PST) 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 4527F3A1776; Thu, 11 Mar 2021 01:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29519; q=dns/txt; s=iport; t=1615456437; x=1616666037; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=sJ3fNxfV4FagEqfeOLbgFFly6pxuHX3VHA2tPSZwuJs=; b=UfgxzrVpF2jtW/Rqu6GqpQLLsAqF95dRSbLhlhajNh6w4woFYolZE78a j6q0afbcR7vZ5rNVQCcUFiiI8FAhQkdsSKK9ZJ0VTpyL8yWJx2jTrZ72e aNV2xMADWj4uZEDY1LBA1Q9yyyVlE6ROXIez9eArv15uKvnUsgmrdZKkT k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BXAAAu6ElglxbLJq1RCRsBAQEBAQEBAQUBAQESAQEBA?= =?us-ascii?q?wMBAQGCD4EjgX4OSAEnEjEChD+JBIgbJQOHbpRXBAcBAQEKAwEBHQEKDAQBA?= =?us-ascii?q?YRNAoF0JjgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNg2GRAEBA?= =?us-ascii?q?QMBAQEhBEcLBQsLEQECAQIBIAcDAgInHwMGCAYKCRSCXAGCZiEPrAV2fzOEP?= =?us-ascii?q?wEDAYEUhHQKBoE5gVOFKgGCU4JDNXpCgguBEScMEIFaLlA+glwBAQKBMUwWg?= =?us-ascii?q?mA0gisEgVUCaQUBAYEZISA7BTgBKw8BExspGpBINhkDjBmLEJFPgwqDMIE9d?= =?us-ascii?q?ZZLAx+DPJArkBmGP4taA4RciT+Rd0tBg3UCBAYFAhaBayGBWTMaCBsVOyoBg?= =?us-ascii?q?j4+EhkNjiYSiGqFRkADLwILKwIGAQkBAQMJjH8BAQ?= IronPort-HdrOrdr: A9a23:Mj9f3650wwua/3u/VAPXwErXdLJzesId70hD6mlaQ3VuA6+lvu qpm+kW0gKxtSYJVBgb9eyoFaGcTRrnlKJdzpIWOd6ZNjXOmGztF4166Jun/juIIU3D38pQz7 1pfaQ7KNCYNzVHpOL75AX9LNo62tmA98mT6tv29HtmQQF0Z6wI1W4QYTqzKUF4SBJLApA0Dv Onl696jgC9cncaZNnTPBc4dtXEzue79q7OUFojDx4j5BLmt0LN1JfKVz6FwxwZTzRDhZAl/G StqX2e2oyT99em1xTby2jfq65zpeKk4N5CCMuQ4/JlTQnRtg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,240,1610409600"; d="asc'?scan'208,217";a="34101684" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2021 09:53:52 +0000 Received: from [10.61.144.22] ([10.61.144.22]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 12B9rp78011181 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Mar 2021 09:53:52 GMT From: Eliot Lear Message-Id: <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_79471D38-9C62-4BF9-9EF9-593971C924D1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 11 Mar 2021 10:53:50 +0100 In-Reply-To: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> Cc: Guy Fedorkow , Laurence Lundblade , "rats@ietf.org" , "iotops@ietf.org" To: "Smith, Ned" References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.22, [10.61.144.22] X-Outbound-Node: aer-core-1.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: Thu, 11 Mar 2021 09:54:00 -0000 --Apple-Mail=_79471D38-9C62-4BF9-9EF9-593971C924D1 Content-Type: multipart/alternative; boundary="Apple-Mail=_5D78AC3F-799D-4A37-B7FA-27D029125BCB" --Apple-Mail=_5D78AC3F-799D-4A37-B7FA-27D029125BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Ned. My point really was to talk about the impetus for making = an iDevID change. There=E2=80=99s one more obvious one that I didn=E2=80=99= t mention. If you want to make use of tools like ANIMA BRSKI / RFC 8366 = to transition from iDevID -> lDevID and you have a supply chain to = manage, monkeying with what is called the iDevID in those transactions = might help. A better approach might be to integrate FDO (ledger based = transfers). Eliot > On 10 Mar 2021, at 22:09, Smith, Ned wrote: >=20 > Regarding =E2=80=9Ca standard protected TLV list that deployments = could receive through a standard interface. These are attestations of a = form=E2=80=9D >=20 > The TLV list is a statement made by a manufacturer about the = recoverability of device / device ID. We might call them Vendor = Assertions for now. >=20 > The RATS Arch describes Endorsements which are =E2=80=9Cstatements = about the integrity of the signing capability=E2=80=9D. It isn=E2=80=99t = clear to me that mutability/immutability of an IdevID key is covered = under the definition for Endorsements. The architecture didn=E2=80=99t = define terminology for Vendor Assertions that don=E2=80=99t fit the = definition for Endorsements or Reference Values. >=20 > Bringing this back to the original thread. The vendor is likely the = most authoritative entity to make assertions about the = mutability/immutability properties of the IDevID (key). If a standard = tries to codify it in a specification it tends to suffer from ambiguity = or it defines an implementation. (both have compliance challenges) >=20 > Hence, a reasonable way forward is for vendors to make claims about = IDevID mutability properties. Providing the community with a vocabulary = for making such claims is probably the best facilitation a standard = could do. >=20 > From: Eliot Lear > Date: Wednesday, March 10, 2021 at 12:27 PM > To: "Smith, Ned" > Cc: Guy Fedorkow , Laurence = Lundblade , "rats@ietf.org" , = > Subject: Re: [Rats] 802.1AR device identity >=20 > Yeah, this is an issue that comes up from time to time. How = =E2=80=9Cimmutable=E2=80=9D should that iDevID be? I=E2=80=99ve had = this thought in two different contexts: > =C2=B7 What if the signature algorithm, CA, or private key = used to protect the iDevID has been compromised? Can one recover with = an update? > =C2=B7 What if there are attributes in the cert that I want to = dink and share with the deployment? >=20 > I=E2=80=99d like to take that latter case off the table, but then we = need to seriously think about RATS or SUIT providing a standard = protected TLV 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. >=20 > Eliot >=20 >=20 >=20 >> On 10 Mar 2021, at 20:02, Smith, Ned > wrote: >>=20 >> The 802.1AR spec doesn=E2=80=99t AFAIK require IDevIDs that can=E2=80=99= t change. But not curtain. Is says things like: >> A >> device=E2=80=99s DevID module stores each of its DevID secrets = securely and supports signing operations that prove >> possession of the secret (and thus that the device is the subject of = the associated DevID certificate), while >> ensuring that the secret remains confidential so the device cannot be = impersonated by others. >> An Initial Device Identifier (IDevID) provided by a device=E2=80=99s = supplier can be supplemented by one or more >> Local Device Identifiers (LDevIDs), each using an existing or a = freshly generated secret, facilitating >> enrollment (provisioning of authentication and authorization = credentials to authenticated devices) by a local >> network administrator. >>=20 >> A device with DevID capability incorporates a globally unique = manufacturer provided Initial Device >> Identifier (IDevID), stored in a way that protects it from = modification. >>=20 >> LDevIDs can also be used as the sole identifier (by disabling the = IDevID) to >> assure the privacy of the user of a DevID and the equipment in which = it is installed. >>=20 >> -Ned >> From: RATS > on = behalf of Guy Fedorkow > >> Date: Wednesday, March 10, 2021 at 7:59 AM >> To: Laurence Lundblade > >> Cc: "rats@ietf.org " > >> Subject: [Rats] 802.1AR device identity >>=20 >> Hi Laurence, >> We talked about device identity on the RATS call today. >> For RIV, we=E2=80=99re relying on this IEEE spec: >> https://1.ieee802.org/security/802-1ar/ = >> That spec defines Initial and Local Device Identities. Initial = DevID is set by the manufacturer and can=E2=80=99t be changed or = replaced, while the Local DevID can be set and erased by the owner of = the gear. >> The spec doesn=E2=80=99t address deciding which identity to use for = any specific application, but the intent clearly is to allow the owner = to use the manufacturer-supplied identity to install an owner-specific = identity in a device, and erase the owner-specific identity leaving the = manufacturer identity in place when the device is decommissioned. >>=20 >> Many different specs must have examined this problem, but of course = it never hurts to re-use some of these ideas where possible. >> Thx >> /guy >>=20 >>=20 >> Juniper Business Use Only >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats = --Apple-Mail=_5D78AC3F-799D-4A37-B7FA-27D029125BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Ned.  My point really was to talk about the = impetus for making an iDevID change.  There=E2=80=99s one more = obvious one that I didn=E2=80=99t mention.  If you want to make use = of tools like ANIMA BRSKI / RFC 8366 to transition from iDevID -> = lDevID and you have a supply chain to manage, monkeying with what is = called the iDevID in those transactions might help.  A better = approach might be to integrate FDO (ledger based transfers).

Eliot


On 10 = Mar 2021, at 22:09, Smith, Ned <ned.smith@intel.com> wrote:

Regarding =E2=80=9Ca standard protected = TLV list  that deployments could receive through a standard = interface.  These are attestations of a form=E2=80=9D
 
The TLV list = is a statement made by a manufacturer about the recoverability of device = / device ID. We might call them Vendor Assertions for now.
 
The RATS Arch = describes Endorsements which are =E2=80=9Cstatements about the integrity = of the signing capability=E2=80=9D. It isn=E2=80=99t clear to me that = mutability/immutability of an IdevID key is covered under the definition = for Endorsements. The architecture didn=E2=80=99t define terminology for = Vendor Assertions that don=E2=80=99t fit the definition for Endorsements = or Reference Values.
 
Bringing this back to the original thread. The = vendor is likely the most authoritative entity to make assertions about = the mutability/immutability properties of the IDevID (key). If a = standard tries to codify it in a specification it tends to suffer from = ambiguity or it defines an implementation. (both have compliance = challenges)
 
Hence, a = reasonable way forward is for vendors to make claims about IDevID = mutability properties. Providing the community with a vocabulary for = making such claims is probably the best facilitation a standard could = do.
 
From: Eliot Lear <lear@cisco.com>
Date: Wednesday, March 10, = 2021 at 12:27 PM
To: "Smith, Ned" <ned.smith@intel.com>
Cc: Guy = Fedorkow <gfedorkow=3D40juniper.net@dmarc.ietf.org>, Laurence = Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>, <iotops@ietf.org>
Subject: Re: [Rats] 802.1AR = device identity
 
Yeah, this is an issue that comes up from time to time. =  How =E2=80=9Cimmutable=E2=80=9D should that iDevID be? =  I=E2=80=99ve had this thought in two different contexts:
=C2=B7         What = if the signature algorithm, CA, or private key used to protect the = iDevID has been compromised?  Can one recover with an update?
=C2=B7         What = if there are attributes in the cert that I want to dink and share with = the deployment?
 
I=E2=80=99d like to take that latter case off the table, but = then we need to seriously think about RATS or SUIT providing a standard = protected TLV 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.
 
Eliot
 


On 10 Mar 2021, at 20:02, Smith, Ned = <ned.smith@intel.com> = wrote:
 
The 802.1AR spec doesn=E2=80=99t = AFAIK require IDevIDs that can=E2=80=99t change. But not curtain. Is = says things like:
A
device=E2=80=99s DevID module stores each of its DevID = secrets securely and supports signing operations that prove
possession of the secret (and thus that the device is the = subject of the associated DevID certificate), while
ensuring that the secret remains confidential so the device = cannot be impersonated by others.
An Initial Device Identifier (IDevID) provided by a = device=E2=80=99s supplier can be supplemented by one or more
Local Device Identifiers (LDevIDs), each using an existing or = a freshly generated secret, facilitating
enrollment (provisioning of authentication and authorization = credentials to authenticated devices) by a local
network administrator.
 
A device with DevID = capability incorporates a globally unique manufacturer provided Initial = Device
Identifier (IDevID), stored in a way = that protects it from modification.
 
LDevIDs can also be used as = the sole identifier (by disabling the IDevID) to
assure the privacy of the user of a DevID and the equipment = in which it is installed.
 
-Ned
From: RATS <rats-bounces@ietf.org> on = behalf of Guy Fedorkow <gfedorkow=3D40juniper.net@dmarc.ietf.org>
Date: Wednesday, March 10, = 2021 at 7:59 AM
To: Laurence Lundblade = <lgl@island-resort.com>
Cc: "rats@ietf.org" <rats@ietf.org>
Subject: [Rats] 802.1AR device = identity
 
Hi Laurence,
  We talked about = device identity on the RATS call today.
  For RIV, we=E2=80=99r= e relying on this IEEE spec:
  That spec defines = Initial and Local Device Identities.  Initial DevID is set by the = manufacturer and can=E2=80=99t be changed or replaced, while the Local = DevID can be set and erased by the owner of the gear.
  The spec doesn=E2=80=99= t address deciding which identity to use for any specific application, = but the intent clearly is to allow the owner to use the = manufacturer-supplied identity to install an owner-specific identity in = a device, and erase the owner-specific identity leaving the manufacturer = identity in place when the device is decommissioned.
 
  Many different = specs must have examined this problem, but of course it never hurts to = re-use some of these ideas where possible.
  Thx
/guy
 
 

Juniper = Business Use Only

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

= --Apple-Mail=_5D78AC3F-799D-4A37-B7FA-27D029125BCB-- --Apple-Mail=_79471D38-9C62-4BF9-9EF9-593971C924D1 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBJ6K4ACgkQh7ZrRtnS ejOHIQf+K0yr35snmsOV9ZSy4RvfaQuDIOe3+ufqXBwFYb8J8HRNkh2lIZPu2suH f6vwb61NPU5nn0emc6IshstjcEVatVBod/2WW2kF6LHdCvKQFsefmg0zGRMQA2Y2 wcgzTPNnGYJLoyhwxZtyqjPOzv+DUb3zjCS2vPN61U0gCo/ybw7N+qQLJt2ZQbv2 mwGsAj1BcXYuSi20MujCd6lTJKVSkAE1BlCsMUs6aiFi58fEgm78BqW/l7+P2Wvi P5eI9Crx7tCCh4tZEqXwg/IwzII1v2viK/jj+f6/9oDDY3AO+Uv4ZbtaP/o4G8mV 8feoTXGJNAFKqBbohWmAMrinJlAEvw== =Y+c0 -----END PGP SIGNATURE----- --Apple-Mail=_79471D38-9C62-4BF9-9EF9-593971C924D1-- From nobody Thu Mar 11 08:17:07 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 865403A12A7; Thu, 11 Mar 2021 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.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_HI=-5, 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 (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 A9Pwj5mAbLWI; Thu, 11 Mar 2021 08:16:58 -0800 (PST) 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 109013A12A9; Thu, 11 Mar 2021 08:16:57 -0800 (PST) IronPort-SDR: Ev8U1DOu9XucZAc87/nw/MMnrJT1eu5lJCPEYS2/Aq+r8vr79oYQarp8CWgzi7+E7ANB4rye2C lfQbjBd8HH4w== X-IronPort-AV: E=McAfee;i="6000,8403,9920"; a="188057335" X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208,217";a="188057335" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2021 08:16:50 -0800 IronPort-SDR: Y7G4QxfBPQ6hKmRZ+BDaj1WMPUCvZD38xictg4kcqZb6+d/a/KcUAQTSE5g8Z6uvHQH236Wn2b a8D5tzBKNGzw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208,217";a="372370467" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga006.jf.intel.com with ESMTP; 11 Mar 2021 08:16:50 -0800 Received: from orsmsx606.amr.corp.intel.com (10.22.229.19) 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; Thu, 11 Mar 2021 08:16:49 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Thu, 11 Mar 2021 08:16:49 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.106) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Thu, 11 Mar 2021 08:16:49 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RnxQlG09v2+hMWqm7yz0r4VvAagP26/+CwT5vGgRe8mqRCTMa9gASTQDTXYVpvYtDctvzXHCTn47K1auZOS3ZqGLl5ryKvUZaXiHDLQEjAl3Ro6ikSovNigANpAsuiRjIg7OJ7Mpe4LwHvKs1dGoHr3dpYewA9DmWxivwYYXAiQrLvkQ4Yr5ySG9he0DSxp5NNY24VYqiqgFDVW2v4wZpnjDbNjao1kVv/rL+WeMzCmV1Sn4qJCepcAlEGzdt/U+tjiNIWqaxMDCuH2kNMT/IUlXr5UwoaCdg9QFiefNDeQAeLISNKyAiidxvHeJSIn/7eTWTLClyD37lVQpep/bSw== 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=s5Zi4mBIKSw2XMg2RdtGDuxFEBVpR77GluC3kwgKxh8=; b=cOUZ9/vZxZcMGO8GOem+i0pLgMQEhmP8FG2Jan4AHbYIUpDcNY1hH7oXKpF2Oe9TrBDgZXntI/1ZuAvYVZxqeTCVHf93/eFaLVjUy6O12PyB1IQTWgZ6Nxe9XauPVU5Un3pBzEqWxqWeaHmhx7t860QhICXqjfzRTdHGdP30KvbJt2KGzvXJQxDOIe5AOGTbxIfzmi36lrUYItVyF3FXGKj0HW3Qnrrortq4FANjHlDEUd62wJBVJ8JNU0gCfw3woP3/GPmdNR65r3JsSgqlMnFCdT85H7ARlh+5zGtzsBoEpeEh+pVA6c5ojYsQYgNHa/djh/5xG0aqtyrRmBIjGw== 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=s5Zi4mBIKSw2XMg2RdtGDuxFEBVpR77GluC3kwgKxh8=; b=MZxQbehkYzEEozJOXi6X8El/lw2+obmIgnxvSqiJMKJdfYxMYAtInKlsgQBvxdDJPFegMwfeh+SOmYHjoSGRoKIV68grLeJ+/hto9a8ZXZUCrAPZFs020xaPeP/Dt8tp9aKimSW2Qd+/dlYU9G5RwdxbtUGhi60fVhdBt55pI9s= Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by MWHPR11MB1902.namprd11.prod.outlook.com (2603:10b6:300:10f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Thu, 11 Mar 2021 16:16:47 +0000 Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0%3]) with mapi id 15.20.3933.031; Thu, 11 Mar 2021 16:16:47 +0000 From: "Smith, Ned" To: Eliot Lear CC: Guy Fedorkow , Laurence Lundblade , "rats@ietf.org" , "iotops@ietf.org" Thread-Topic: [Rats] 802.1AR device identity Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOA Date: Thu, 11 Mar 2021 16:16:47 +0000 Message-ID: <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> References: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> In-Reply-To: <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.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: 3a3fa6d9-5e86-4794-ebd3-08d8e4a91219 x-ms-traffictypediagnostic: MWHPR11MB1902: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wNUF2osP7ZDdS+yVL72J7ChLYlWuO48ozBN39VZx2bTtW3CO+SHfm2ALgA7YqDk+0zJPMwUsaycOMFpSaac1DMRnySQVN+j7Url7/Wbk/BaOSKGhguOr7+UQJmdDEfCUJBLgZkAbBlwlzrvajQG5Df5z1sTb2b9f44FOpWnr+2BnBIJKjGjuZzjmwr8bbgYBaw1xeckiAQDZPBmFpWzrb82Go0pRlX5wwSZNBB/mpl8TVYOdf+dA5ceH723PIF99W44libWz/xetNZt3C0qM98l58Vo++IfBNRuDcDJG9mSneU0ykoN3O8YcAnbtm3OQji3vmsDCO0Us5O8hHyEpa1rKZgFVwIr8JmZRfnXIGoZILx8kNV5eOLEq5jEXxAstXOwP91zMWWY3RUkhMvnWgBUHoi5FC6Vh5teYX6PAaHA4Iyr/A3N8zYo7vL+dZiTEyyE3lXBdWWKFyF/uENz8EKR+fAy1QVXa/ZO4lH5bIGvOvMzpKdY3f9DOrF9tD6LqTNg9S6rAdTWZPg+Aivbt6r/g7nJnDUUWG5wcR8g+NAbGVq3AsGWqNfCuE1ybrTvqf1VyVZgR9ewb4jZNcSH878eOZ810+frQ0Hy01rmoODlQ8LcDi86HrFICptIGIC14T7CXpSD1yS5d3jNtnwX1a7zw+TSZMsSrDdJLJxp1Bz2WtyNPDLTIEi372yQAbXfP 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)(39860400002)(396003)(366004)(346002)(136003)(6916009)(6486002)(71200400001)(36756003)(26005)(8936002)(2906002)(6512007)(86362001)(166002)(186003)(33656002)(83380400001)(6506007)(76116006)(966005)(64756008)(66556008)(53546011)(66446008)(66476007)(91956017)(66946007)(8676002)(5660300002)(4326008)(478600001)(2616005)(54906003)(316002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?S2F0LzNtWXFIYjMzQTZ3TitmTENQRGhFZndienNLSDZtdENqdG9IYU1ReUJZ?= =?utf-8?B?V2JVRXh4TWFJbTh1eUU1YU9pbFRIQzEzOEt1bjJrcXNPYVlrang3UXNyWXh2?= =?utf-8?B?N0NvSlpHa3Z3QWNBQTlWQzZSUWhaQnJXQTdveTBnUDNVTXF1OHQ2L0xoenRH?= =?utf-8?B?MG82ZlFzajlRWk1FQlBpbHdUM3JwK1ZlWmxKeXo1TnEvZVpLMnVsaVBRODU5?= =?utf-8?B?L1BEQmIwQ3lvSVJlQll0L3I3ZDRXYWZPY01kY08rTDRLc1k1b0szV3Q2TkJJ?= =?utf-8?B?Q2VMdktHajhtRlRxT1JETEVIcHltTUk2SHJHVEd2WEVmeGNDbmx4VTRqRlJm?= =?utf-8?B?SnROTUNyMG8rK1JYQTRaRERxRG5BWXRJelp4QUZKOUtqeWN3eXVOZkw3SDRh?= =?utf-8?B?VUNMZ0I2UU91bUt5Tnl4TmhFUWQ4UnpFR2hub3RkRFFmMllQbjBxcFJwM1pJ?= =?utf-8?B?VjlQVXV6MHRiallpYldtVFV0NFFIRDIrVHJuOG9mT3IwS1B2MG0yWWY0SWRP?= =?utf-8?B?OXBLSEtiR0NGa0kyank5dk90VUZDL0NRYjlrYmkzTlJMdFM5dlJvRG5LamVp?= =?utf-8?B?cmg0YjJNNUhiNlVLNmZMVjlPZTZoUmJVWnB5TncvbHd4UTMzclhIS0xReHQ1?= =?utf-8?B?WXlJd2hkaVRUdDhXemNpMjV5dkF6ZmhrUDMxanFLKzNadU0rcGhHRmhuUVdp?= =?utf-8?B?SXdyOCtwNno1eFc4VG4wV0JkbngvM2hpMDhYQk9jTW1OQXpOVk9oM2h1Q2V3?= =?utf-8?B?QjdDUlAyYTJQVGtLSFJEUjhxbXZZbnA5MHpsT081ZE9XMGgybGtYdVd6Sm9Q?= =?utf-8?B?Mk9MTS93MlZwUUdNdGxtTlIrN0RCenJJcSs1SkRObnJZeWswZXFlaVNYTnda?= =?utf-8?B?dXF1emNucVFsQzFnTE5qV0VDa0tQWkRpRllUTkx6cnJZRmJFTnJVTXdRZXR6?= =?utf-8?B?M0ZHbWt0dXNhcDIyT0hoN2JaRVRMcWZWV2pNK3Z3MzRDZEpkZWQ3U0NoZWdh?= =?utf-8?B?YzZDTTh2SjRTaWJZaWJVWTZBWVcvWlhuSGVjM3FFSGpqSFNMU0hqZitQdTFw?= =?utf-8?B?ZEZiZGJkS0VXenhYMXdQZ3J4M0NvS0UyTCtXak5FZS81ZFdhRDNpbk9UM2Jz?= =?utf-8?B?MW91c0l0QUV1YTFjNk94eGZTbGsyRmtMd0VKeGt1dG94aHo5QmVodGdGaDl3?= =?utf-8?B?VU5rY3ErL0hwWW9HWWZDbHIvSjI4RGd6enprWWd0QzZ3RDZzTyt0b0hVT1Bn?= =?utf-8?B?NjNyd2tsUFVrQUlISTZCVzRqdGpTNzFoMEh4UzVMOUdxM0ozMnB5SE1nUjBw?= =?utf-8?B?VGx6VDVnSnFVbDU5U1h4YThBUi9WQzk1V3owa1ZhOUwzSUNnUDJBc2xiSUpP?= =?utf-8?B?Y0pOZGc1dkFhZW1iRzJucWpma2s3S1hvemdNcENNeFRjbHQ1aCtabEZYb0Rn?= =?utf-8?B?WVI4cElYelgvaXQwUElUaCtPU1VOUzVUVFB4bmxrcHI3UnYzWG05a3gxUyth?= =?utf-8?B?bVVhb0tGaDZ0YzJRTjNxTkQ0NnJkTWd3OFdBeFpoblJLZmVRRGtsbUhnamxw?= =?utf-8?B?QmthSm9OQ2E4Zm5OdVJLSDJpTXJLK3F3Q1VMN2gya1I4anV2T1lmckNsaW9K?= =?utf-8?B?UTFvTVdpSExpNXpGZ3pKYlpvV2ZxUjhpSXpTWTVUOFJEOG1wL0FBTUZmaFow?= =?utf-8?B?RnJPVm12WUl5Ty9FNTNHYW4vanBpYjNCcWdoWTFlNE95T0NIZ1R1akxLVUI2?= =?utf-8?Q?G/CoqiTqy6D/NlQE40scgi27OkQCPZ30zI7EY8S?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_62FFA122047E468CA2DD5A0E4E8EAF74intelcom_" 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: 3a3fa6d9-5e86-4794-ebd3-08d8e4a91219 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 16:16:47.5766 (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: +bU2pcCgsb3v2UyKr9cxLRNTMNM9AMI/+ujeaIRj/dycproJKNw31dtd7txxDgYdShOGlVSotyXs71L68d0PdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1902 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: Thu, 11 Mar 2021 16:17:01 -0000 --_000_62FFA122047E468CA2DD5A0E4E8EAF74intelcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIGlubGluZSBubXM+Lg0KRnJvbTogRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20+DQpEYXRl OiBUaHVyc2RheSwgTWFyY2ggMTEsIDIwMjEgYXQgMTo1NCBBTQ0KVG86ICJTbWl0aCwgTmVkIiA8 bmVkLnNtaXRoQGludGVsLmNvbT4NCkNjOiBHdXkgRmVkb3Jrb3cgPGdmZWRvcmtvdz00MGp1bmlw ZXIubmV0QGRtYXJjLmlldGYub3JnPiwgTGF1cmVuY2UgTHVuZGJsYWRlIDxsZ2xAaXNsYW5kLXJl c29ydC5jb20+LCAicmF0c0BpZXRmLm9yZyIgPHJhdHNAaWV0Zi5vcmc+LCAiaW90b3BzQGlldGYu b3JnIiA8aW90b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtSYXRzXSA4MDIuMUFSIGRldmlj ZSBpZGVudGl0eQ0KDQpUaGFua3MsIE5lZC4gIE15IHBvaW50IHJlYWxseSB3YXMgdG8gdGFsayBh Ym91dCB0aGUgaW1wZXR1cyBmb3IgbWFraW5nIGFuIGlEZXZJRCBjaGFuZ2UuICBUaGVyZeKAmXMg b25lIG1vcmUgb2J2aW91cyBvbmUgdGhhdCBJIGRpZG7igJl0IG1lbnRpb24uICBJZiB5b3Ugd2Fu dCB0byBtYWtlIHVzZSBvZiB0b29scyBsaWtlIEFOSU1BIEJSU0tJIC8gUkZDIDgzNjYgdG8gdHJh bnNpdGlvbiBmcm9tIGlEZXZJRCAtPiBsRGV2SUQgYW5kIHlvdSBoYXZlIGEgc3VwcGx5IGNoYWlu IHRvIG1hbmFnZSwgbW9ua2V5aW5nIHdpdGggd2hhdCBpcyBjYWxsZWQgdGhlIGlEZXZJRCBpbiB0 aG9zZSB0cmFuc2FjdGlvbnMgbWlnaHQgaGVscC4gIEEgYmV0dGVyIGFwcHJvYWNoIG1pZ2h0IGJl IHRvIGludGVncmF0ZSBGRE8gKGxlZGdlciBiYXNlZCB0cmFuc2ZlcnMpLg0KTm1zPiBJ4oCZbSBu b3QgZmFtaWxpYXIgd2l0aCB0aGUgRkRPIGFjcm9ueW0gKEZpcnN0IERldmljZSBPbmJvYXJkPykg b3IgaG93IHRoZSA4MDIuMUFSIHVzZSBjYXNlIGNvbnRleHQgZm9yIGlEZXZJRC9MRGV2SUQgcmVs YXRlcyB0byBsZWRnZXIgYmFzZWQgdHJhbnNmZXJzLiBUaGlzIGZlZWxzIGxpa2UgYSBkZWVwIHRv cGljIHRoYXQgbWF5YmUgc2hvdWxkIGJlIGEgdGFsayBvciBzbGlkZXMgdGhhdCB0aGUgUkFUUyBX RyB1bmRlcnN0YW5kcyBiZXR0ZXI/DQoNCkVsaW90DQoNCg0KDQpPbiAxMCBNYXIgMjAyMSwgYXQg MjI6MDksIFNtaXRoLCBOZWQgPG5lZC5zbWl0aEBpbnRlbC5jb208bWFpbHRvOm5lZC5zbWl0aEBp bnRlbC5jb20+PiB3cm90ZToNCg0KUmVnYXJkaW5nIOKAnGEgc3RhbmRhcmQgcHJvdGVjdGVkIFRM ViBsaXN0ICB0aGF0IGRlcGxveW1lbnRzIGNvdWxkIHJlY2VpdmUgdGhyb3VnaCBhIHN0YW5kYXJk IGludGVyZmFjZS4gIFRoZXNlIGFyZSBhdHRlc3RhdGlvbnMgb2YgYSBmb3Jt4oCdDQoNClRoZSBU TFYgbGlzdCBpcyBhIHN0YXRlbWVudCBtYWRlIGJ5IGEgbWFudWZhY3R1cmVyIGFib3V0IHRoZSBy ZWNvdmVyYWJpbGl0eSBvZiBkZXZpY2UgLyBkZXZpY2UgSUQuIFdlIG1pZ2h0IGNhbGwgdGhlbSBW ZW5kb3IgQXNzZXJ0aW9ucyBmb3Igbm93Lg0KDQpUaGUgUkFUUyBBcmNoIGRlc2NyaWJlcyBFbmRv cnNlbWVudHMgd2hpY2ggYXJlIOKAnHN0YXRlbWVudHMgYWJvdXQgdGhlIGludGVncml0eSBvZiB0 aGUgc2lnbmluZyBjYXBhYmlsaXR54oCdLiBJdCBpc27igJl0IGNsZWFyIHRvIG1lIHRoYXQgbXV0 YWJpbGl0eS9pbW11dGFiaWxpdHkgb2YgYW4gSWRldklEIGtleSBpcyBjb3ZlcmVkIHVuZGVyIHRo ZSBkZWZpbml0aW9uIGZvciBFbmRvcnNlbWVudHMuIFRoZSBhcmNoaXRlY3R1cmUgZGlkbuKAmXQg ZGVmaW5lIHRlcm1pbm9sb2d5IGZvciBWZW5kb3IgQXNzZXJ0aW9ucyB0aGF0IGRvbuKAmXQgZml0 IHRoZSBkZWZpbml0aW9uIGZvciBFbmRvcnNlbWVudHMgb3IgUmVmZXJlbmNlIFZhbHVlcy4NCg0K QnJpbmdpbmcgdGhpcyBiYWNrIHRvIHRoZSBvcmlnaW5hbCB0aHJlYWQuIFRoZSB2ZW5kb3IgaXMg bGlrZWx5IHRoZSBtb3N0IGF1dGhvcml0YXRpdmUgZW50aXR5IHRvIG1ha2UgYXNzZXJ0aW9ucyBh Ym91dCB0aGUgbXV0YWJpbGl0eS9pbW11dGFiaWxpdHkgcHJvcGVydGllcyBvZiB0aGUgSURldklE IChrZXkpLiBJZiBhIHN0YW5kYXJkIHRyaWVzIHRvIGNvZGlmeSBpdCBpbiBhIHNwZWNpZmljYXRp b24gaXQgdGVuZHMgdG8gc3VmZmVyIGZyb20gYW1iaWd1aXR5IG9yIGl0IGRlZmluZXMgYW4gaW1w bGVtZW50YXRpb24uIChib3RoIGhhdmUgY29tcGxpYW5jZSBjaGFsbGVuZ2VzKQ0KDQpIZW5jZSwg YSByZWFzb25hYmxlIHdheSBmb3J3YXJkIGlzIGZvciB2ZW5kb3JzIHRvIG1ha2UgY2xhaW1zIGFi b3V0IElEZXZJRCBtdXRhYmlsaXR5IHByb3BlcnRpZXMuIFByb3ZpZGluZyB0aGUgY29tbXVuaXR5 IHdpdGggYSB2b2NhYnVsYXJ5IGZvciBtYWtpbmcgc3VjaCBjbGFpbXMgaXMgcHJvYmFibHkgdGhl IGJlc3QgZmFjaWxpdGF0aW9uIGEgc3RhbmRhcmQgY291bGQgZG8uDQoNCkZyb206IEVsaW90IExl YXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+DQpEYXRlOiBXZWRuZXNk YXksIE1hcmNoIDEwLCAyMDIxIGF0IDEyOjI3IFBNDQpUbzogIlNtaXRoLCBOZWQiIDxuZWQuc21p dGhAaW50ZWwuY29tPG1haWx0bzpuZWQuc21pdGhAaW50ZWwuY29tPj4NCkNjOiBHdXkgRmVkb3Jr b3cgPGdmZWRvcmtvdz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzpnZmVkb3Jr b3c9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+LCBMYXVyZW5jZSBMdW5kYmxhZGUgPGxn bEBpc2xhbmQtcmVzb3J0LmNvbTxtYWlsdG86bGdsQGlzbGFuZC1yZXNvcnQuY29tPj4sICJyYXRz QGlldGYub3JnPG1haWx0bzpyYXRzQGlldGYub3JnPiIgPHJhdHNAaWV0Zi5vcmc8bWFpbHRvOnJh dHNAaWV0Zi5vcmc+PiwgPGlvdG9wc0BpZXRmLm9yZzxtYWlsdG86aW90b3BzQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBbUmF0c10gODAyLjFBUiBkZXZpY2UgaWRlbnRpdHkNCg0KWWVhaCwgdGhp cyBpcyBhbiBpc3N1ZSB0aGF0IGNvbWVzIHVwIGZyb20gdGltZSB0byB0aW1lLiAgSG93IOKAnGlt bXV0YWJsZeKAnSBzaG91bGQgdGhhdCBpRGV2SUQgYmU/ICBJ4oCZdmUgaGFkIHRoaXMgdGhvdWdo dCBpbiB0d28gZGlmZmVyZW50IGNvbnRleHRzOg0K4oCiICAgICAgICAgV2hhdCBpZiB0aGUgc2ln bmF0dXJlIGFsZ29yaXRobSwgQ0EsIG9yIHByaXZhdGUga2V5IHVzZWQgdG8gcHJvdGVjdCB0aGUg aURldklEIGhhcyBiZWVuIGNvbXByb21pc2VkPyAgQ2FuIG9uZSByZWNvdmVyIHdpdGggYW4gdXBk YXRlPw0K4oCiICAgICAgICAgV2hhdCBpZiB0aGVyZSBhcmUgYXR0cmlidXRlcyBpbiB0aGUgY2Vy dCB0aGF0IEkgd2FudCB0byBkaW5rIGFuZCBzaGFyZSB3aXRoIHRoZSBkZXBsb3ltZW50Pw0KDQpJ 4oCZZCBsaWtlIHRvIHRha2UgdGhhdCBsYXR0ZXIgY2FzZSBvZmYgdGhlIHRhYmxlLCBidXQgdGhl biB3ZSBuZWVkIHRvIHNlcmlvdXNseSB0aGluayBhYm91dCBSQVRTIG9yIFNVSVQgcHJvdmlkaW5n IGEgc3RhbmRhcmQgcHJvdGVjdGVkIFRMViBsaXN0ICB0aGF0IGRlcGxveW1lbnRzIGNvdWxkIHJl Y2VpdmUgdGhyb3VnaCBhIHN0YW5kYXJkIGludGVyZmFjZS4gIFRoZXNlIGFyZSBhdHRlc3RhdGlv bnMgb2YgYSBmb3JtLCBidXQgdGhleeKAmXJlIG5vdCByZWFsbHkgbWVhc3VyZW1lbnRzLCBhcyBo YXMgYmVlbiBwcmV2aW91c2x5IGRpc2N1c3NlZCBoZXJlLg0KDQpFbGlvdA0KDQoNCg0KDQpPbiAx MCBNYXIgMjAyMSwgYXQgMjA6MDIsIFNtaXRoLCBOZWQgPG5lZC5zbWl0aEBpbnRlbC5jb208bWFp bHRvOm5lZC5zbWl0aEBpbnRlbC5jb20+PiB3cm90ZToNCg0KVGhlIDgwMi4xQVIgc3BlYyBkb2Vz buKAmXQgQUZBSUsgcmVxdWlyZSBJRGV2SURzIHRoYXQgY2Fu4oCZdCBjaGFuZ2UuIEJ1dCBub3Qg Y3VydGFpbi4gSXMgc2F5cyB0aGluZ3MgbGlrZToNCkENCmRldmljZeKAmXMgRGV2SUQgbW9kdWxl IHN0b3JlcyBlYWNoIG9mIGl0cyBEZXZJRCBzZWNyZXRzIHNlY3VyZWx5IGFuZCBzdXBwb3J0cyBz aWduaW5nIG9wZXJhdGlvbnMgdGhhdCBwcm92ZQ0KcG9zc2Vzc2lvbiBvZiB0aGUgc2VjcmV0IChh bmQgdGh1cyB0aGF0IHRoZSBkZXZpY2UgaXMgdGhlIHN1YmplY3Qgb2YgdGhlIGFzc29jaWF0ZWQg RGV2SUQgY2VydGlmaWNhdGUpLCB3aGlsZQ0KZW5zdXJpbmcgdGhhdCB0aGUgc2VjcmV0IHJlbWFp bnMgY29uZmlkZW50aWFsIHNvIHRoZSBkZXZpY2UgY2Fubm90IGJlIGltcGVyc29uYXRlZCBieSBv dGhlcnMuDQpBbiBJbml0aWFsIERldmljZSBJZGVudGlmaWVyIChJRGV2SUQpIHByb3ZpZGVkIGJ5 IGEgZGV2aWNl4oCZcyBzdXBwbGllciBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IG9uZSBvciBtb3Jl DQpMb2NhbCBEZXZpY2UgSWRlbnRpZmllcnMgKExEZXZJRHMpLCBlYWNoIHVzaW5nIGFuIGV4aXN0 aW5nIG9yIGEgZnJlc2hseSBnZW5lcmF0ZWQgc2VjcmV0LCBmYWNpbGl0YXRpbmcNCmVucm9sbG1l bnQgKHByb3Zpc2lvbmluZyBvZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBjcmVk ZW50aWFscyB0byBhdXRoZW50aWNhdGVkIGRldmljZXMpIGJ5IGEgbG9jYWwNCm5ldHdvcmsgYWRt aW5pc3RyYXRvci4NCg0KQSBkZXZpY2Ugd2l0aCBEZXZJRCBjYXBhYmlsaXR5IGluY29ycG9yYXRl cyBhIGdsb2JhbGx5IHVuaXF1ZSBtYW51ZmFjdHVyZXIgcHJvdmlkZWQgSW5pdGlhbCBEZXZpY2UN CklkZW50aWZpZXIgKElEZXZJRCksIHN0b3JlZCBpbiBhIHdheSB0aGF0IHByb3RlY3RzIGl0IGZy b20gbW9kaWZpY2F0aW9uLg0KDQpMRGV2SURzIGNhbiBhbHNvIGJlIHVzZWQgYXMgdGhlIHNvbGUg aWRlbnRpZmllciAoYnkgZGlzYWJsaW5nIHRoZSBJRGV2SUQpIHRvDQphc3N1cmUgdGhlIHByaXZh Y3kgb2YgdGhlIHVzZXIgb2YgYSBEZXZJRCBhbmQgdGhlIGVxdWlwbWVudCBpbiB3aGljaCBpdCBp cyBpbnN0YWxsZWQuDQoNCi1OZWQNCkZyb206IFJBVFMgPHJhdHMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cmF0cy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEd1eSBGZWRvcmtvdyA8 Z2ZlZG9ya293PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmdmZWRvcmtvdz00 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IFdlZG5lc2RheSwgTWFyY2ggMTAs IDIwMjEgYXQgNzo1OSBBTQ0KVG86IExhdXJlbmNlIEx1bmRibGFkZSA8bGdsQGlzbGFuZC1yZXNv cnQuY29tPG1haWx0bzpsZ2xAaXNsYW5kLXJlc29ydC5jb20+Pg0KQ2M6ICJyYXRzQGlldGYub3Jn PG1haWx0bzpyYXRzQGlldGYub3JnPiIgPHJhdHNAaWV0Zi5vcmc8bWFpbHRvOnJhdHNAaWV0Zi5v cmc+Pg0KU3ViamVjdDogW1JhdHNdIDgwMi4xQVIgZGV2aWNlIGlkZW50aXR5DQoNCkhpIExhdXJl bmNlLA0KICBXZSB0YWxrZWQgYWJvdXQgZGV2aWNlIGlkZW50aXR5IG9uIHRoZSBSQVRTIGNhbGwg dG9kYXkuDQogIEZvciBSSVYsIHdl4oCZcmUgcmVseWluZyBvbiB0aGlzIElFRUUgc3BlYzoNCmh0 dHBzOi8vMS5pZWVlODAyLm9yZy9zZWN1cml0eS84MDItMWFyLw0KICBUaGF0IHNwZWMgZGVmaW5l cyBJbml0aWFsIGFuZCBMb2NhbCBEZXZpY2UgSWRlbnRpdGllcy4gIEluaXRpYWwgRGV2SUQgaXMg c2V0IGJ5IHRoZSBtYW51ZmFjdHVyZXIgYW5kIGNhbuKAmXQgYmUgY2hhbmdlZCBvciByZXBsYWNl ZCwgd2hpbGUgdGhlIExvY2FsIERldklEIGNhbiBiZSBzZXQgYW5kIGVyYXNlZCBieSB0aGUgb3du ZXIgb2YgdGhlIGdlYXIuDQogIFRoZSBzcGVjIGRvZXNu4oCZdCBhZGRyZXNzIGRlY2lkaW5nIHdo aWNoIGlkZW50aXR5IHRvIHVzZSBmb3IgYW55IHNwZWNpZmljIGFwcGxpY2F0aW9uLCBidXQgdGhl IGludGVudCBjbGVhcmx5IGlzIHRvIGFsbG93IHRoZSBvd25lciB0byB1c2UgdGhlIG1hbnVmYWN0 dXJlci1zdXBwbGllZCBpZGVudGl0eSB0byBpbnN0YWxsIGFuIG93bmVyLXNwZWNpZmljIGlkZW50 aXR5IGluIGEgZGV2aWNlLCBhbmQgZXJhc2UgdGhlIG93bmVyLXNwZWNpZmljIGlkZW50aXR5IGxl YXZpbmcgdGhlIG1hbnVmYWN0dXJlciBpZGVudGl0eSBpbiBwbGFjZSB3aGVuIHRoZSBkZXZpY2Ug aXMgZGVjb21taXNzaW9uZWQuDQoNCiAgTWFueSBkaWZmZXJlbnQgc3BlY3MgbXVzdCBoYXZlIGV4 YW1pbmVkIHRoaXMgcHJvYmxlbSwgYnV0IG9mIGNvdXJzZSBpdCBuZXZlciBodXJ0cyB0byByZS11 c2Ugc29tZSBvZiB0aGVzZSBpZGVhcyB3aGVyZSBwb3NzaWJsZS4NCiAgVGh4DQovZ3V5DQoNCg0K DQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUkFUUyBtYWlsaW5nIGxpc3QNClJBVFNAaWV0Zi5vcmc8bWFp bHRvOlJBVFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JhdHMNCg0K --_000_62FFA122047E468CA2DD5A0E4E8EAF74intelcom_ Content-Type: text/html; charset="utf-8" Content-ID: <29548CA869B062439C7FD8028A7375AA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KcC5tc2lwZm9vdGVyMzBiM2Q1Mzgs IGxpLm1zaXBmb290ZXIzMGIzZDUzOCwgZGl2Lm1zaXBmb290ZXIzMGIzZDUzOA0KCXttc28tc3R5 bGUtbmFtZTptc2lwZm9vdGVyMzBiM2Q1Mzg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlv bjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ U2VlIGlubGluZSBubXMmZ3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkVsaW90 IExlYXIgJmx0O2xlYXJAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwg TWFyY2ggMTEsIDIwMjEgYXQgMTo1NCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7U21pdGgsIE5l ZCZxdW90OyAmbHQ7bmVkLnNtaXRoQGludGVsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkd1eSBG ZWRvcmtvdyAmbHQ7Z2ZlZG9ya293PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7LCBM YXVyZW5jZSBMdW5kYmxhZGUgJmx0O2xnbEBpc2xhbmQtcmVzb3J0LmNvbSZndDssICZxdW90O3Jh dHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3JhdHNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtpb3RvcHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O2lvdG9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtSYXRzXSA4MDIuMUFSIGRldmljZSBpZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYW5rcywgTmVkLiAmbmJzcDtNeSBwb2ludCByZWFs bHkgd2FzIHRvIHRhbGsgYWJvdXQgdGhlIGltcGV0dXMgZm9yIG1ha2luZyBhbiBpRGV2SUQgY2hh bmdlLiAmbmJzcDtUaGVyZeKAmXMgb25lIG1vcmUgb2J2aW91cyBvbmUgdGhhdCBJIGRpZG7igJl0 IG1lbnRpb24uICZuYnNwO0lmIHlvdSB3YW50IHRvIG1ha2UgdXNlIG9mIHRvb2xzIGxpa2UgQU5J TUEgQlJTS0kgLyBSRkMgODM2NiB0byB0cmFuc2l0aW9uDQogZnJvbSBpRGV2SUQgLSZndDsgbERl dklEIGFuZCB5b3UgaGF2ZSBhIHN1cHBseSBjaGFpbiB0byBtYW5hZ2UsIG1vbmtleWluZyB3aXRo IHdoYXQgaXMgY2FsbGVkIHRoZSBpRGV2SUQgaW4gdGhvc2UgdHJhbnNhY3Rpb25zIG1pZ2h0IGhl bHAuICZuYnNwO0EgYmV0dGVyIGFwcHJvYWNoIG1pZ2h0IGJlIHRvIGludGVncmF0ZSBGRE8gKGxl ZGdlciBiYXNlZCB0cmFuc2ZlcnMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ObXMm Z3Q7IEnigJltIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBGRE8gYWNyb255bSAoRmlyc3QgRGV2aWNl IE9uYm9hcmQ/KSBvciBob3cgdGhlIDgwMi4xQVIgdXNlIGNhc2UgY29udGV4dCBmb3IgaURldklE L0xEZXZJRCByZWxhdGVzIHRvIGxlZGdlciBiYXNlZCB0cmFuc2ZlcnMuIFRoaXMgZmVlbHMgbGlr ZSBhIGRlZXAgdG9waWMgdGhhdCBtYXliZQ0KIHNob3VsZCBiZSBhIHRhbGsgb3Igc2xpZGVzIHRo YXQgdGhlIFJBVFMgV0cgdW5kZXJzdGFuZHMgYmV0dGVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPk9uIDEwIE1hciAyMDIxLCBhdCAyMjowOSwgU21pdGgsIE5lZCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm5lZC5zbWl0aEBpbnRlbC5jb20iPm5lZC5zbWl0aEBpbnRlbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZWdhcmRpbmcg4oCcPC9zcGFuPmEg c3RhbmRhcmQgcHJvdGVjdGVkIFRMViBsaXN0ICZuYnNwO3RoYXQgZGVwbG95bWVudHMgY291bGQg cmVjZWl2ZSB0aHJvdWdoIGEgc3RhbmRhcmQgaW50ZXJmYWNlLiAmbmJzcDtUaGVzZSBhcmUgYXR0 ZXN0YXRpb25zIG9mIGEgZm9ybeKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+VGhlIFRMViBsaXN0IGlzIGEgc3RhdGVtZW50IG1hZGUgYnkgYSBtYW51ZmFjdHVyZXIg YWJvdXQgdGhlIHJlY292ZXJhYmlsaXR5IG9mIGRldmljZSAvIGRldmljZSBJRC4gV2UgbWlnaHQg Y2FsbCB0aGVtIFZlbmRvciBBc3NlcnRpb25zIGZvciBub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIFJBVFMgQXJjaCBkZXNjcmliZXMgRW5kb3Jz ZW1lbnRzIHdoaWNoIGFyZSDigJxzdGF0ZW1lbnRzIGFib3V0IHRoZSBpbnRlZ3JpdHkgb2YgdGhl IHNpZ25pbmcgY2FwYWJpbGl0eeKAnS4gSXQgaXNu4oCZdCBjbGVhciB0byBtZSB0aGF0IG11dGFi aWxpdHkvaW1tdXRhYmlsaXR5IG9mIGFuIElkZXZJRCBrZXkNCiBpcyBjb3ZlcmVkIHVuZGVyIHRo ZSBkZWZpbml0aW9uIGZvciBFbmRvcnNlbWVudHMuIFRoZSBhcmNoaXRlY3R1cmUgZGlkbuKAmXQg ZGVmaW5lIHRlcm1pbm9sb2d5IGZvciBWZW5kb3IgQXNzZXJ0aW9ucyB0aGF0IGRvbuKAmXQgZml0 IHRoZSBkZWZpbml0aW9uIGZvciBFbmRvcnNlbWVudHMgb3IgUmVmZXJlbmNlIFZhbHVlcy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5CcmluZ2luZyB0aGlz IGJhY2sgdG8gdGhlIG9yaWdpbmFsIHRocmVhZC4gVGhlIHZlbmRvciBpcyBsaWtlbHkgdGhlIG1v c3QgYXV0aG9yaXRhdGl2ZSBlbnRpdHkgdG8gbWFrZSBhc3NlcnRpb25zIGFib3V0IHRoZSBtdXRh YmlsaXR5L2ltbXV0YWJpbGl0eSBwcm9wZXJ0aWVzIG9mIHRoZSBJRGV2SUQNCiAoa2V5KS4gSWYg YSBzdGFuZGFyZCB0cmllcyB0byBjb2RpZnkgaXQgaW4gYSBzcGVjaWZpY2F0aW9uIGl0IHRlbmRz IHRvIHN1ZmZlciBmcm9tIGFtYmlndWl0eSBvciBpdCBkZWZpbmVzIGFuIGltcGxlbWVudGF0aW9u LiAoYm90aCBoYXZlIGNvbXBsaWFuY2UgY2hhbGxlbmdlcyk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5IZW5jZSwgYSByZWFzb25hYmxlIHdheSBmb3J3YXJk IGlzIGZvciB2ZW5kb3JzIHRvIG1ha2UgY2xhaW1zIGFib3V0IElEZXZJRCBtdXRhYmlsaXR5IHBy b3BlcnRpZXMuIFByb3ZpZGluZyB0aGUgY29tbXVuaXR5IHdpdGggYSB2b2NhYnVsYXJ5IGZvciBt YWtpbmcgc3VjaCBjbGFpbXMgaXMgcHJvYmFibHkNCiB0aGUgYmVzdCBmYWNpbGl0YXRpb24gYSBz dGFuZGFyZCBjb3VsZCBkby48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5FbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86 bGVhckBjaXNjby5jb20iPmxlYXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2VkbmVzZGF5 LCBNYXJjaCAxMCwgMjAyMSBhdCAxMjoyNyBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7U21pdGgsIE5lZCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5lZC5zbWl0aEBpbnRlbC5jb20iPm5lZC5zbWl0aEBpbnRl bC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+R3V5IEZlZG9ya293ICZsdDs8YSBocmVmPSJtYWlsdG86Z2Zl ZG9ya293PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmciPmdmZWRvcmtvdz00MGp1bmlwZXIu bmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDssIExhdXJlbmNlIEx1bmRibGFkZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmxnbEBpc2xhbmQtcmVzb3J0LmNvbSI+bGdsQGlzbGFuZC1yZXNvcnQuY29tPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpyYXRzQGlldGYub3JnIj5yYXRzQGlldGYub3Jn PC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86cmF0c0BpZXRmLm9yZyI+cmF0c0BpZXRm Lm9yZzwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlvdG9wc0BpZXRmLm9yZyI+aW90b3Bz QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtSYXRzXSA4MDIuMUFSIGRldmljZSBp ZGVudGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WWVhaCwgdGhpcyBpcyBhbiBpc3N1ZSB0aGF0IGNvbWVzIHVw IGZyb20gdGltZSB0byB0aW1lLiAmbmJzcDtIb3cg4oCcaW1tdXRhYmxl4oCdIHNob3VsZCB0aGF0 IGlEZXZJRCBiZT8gJm5ic3A7SeKAmXZlIGhhZCB0aGlzIHRob3VnaHQgaW4gdHdvIGRpZmZlcmVu dCBjb250ZXh0czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5XaGF0IGlmIHRoZQ0KIHNpZ25h dHVyZSBhbGdvcml0aG0sIENBLCBvciBwcml2YXRlIGtleSB1c2VkIHRvIHByb3RlY3QgdGhlIGlE ZXZJRCBoYXMgYmVlbiBjb21wcm9taXNlZD8gJm5ic3A7Q2FuIG9uZSByZWNvdmVyIHdpdGggYW4g dXBkYXRlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox LjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0 LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+V2hhdCBpZiB0aGVyZQ0KIGFyZSBhdHRyaWJ1dGVz IGluIHRoZSBjZXJ0IHRoYXQgSSB3YW50IHRvIGRpbmsgYW5kIHNoYXJlIHdpdGggdGhlIGRlcGxv eW1lbnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SeKAmWQgbGlrZSB0byB0YWtlIHRoYXQgbGF0dGVyIGNhc2Ugb2ZmIHRoZSB0 YWJsZSwgYnV0IHRoZW4gd2UgbmVlZCB0byBzZXJpb3VzbHkgdGhpbmsgYWJvdXQgUkFUUyBvciBT VUlUIHByb3ZpZGluZyBhIHN0YW5kYXJkIHByb3RlY3RlZCBUTFYgbGlzdCAmbmJzcDt0aGF0IGRl cGxveW1lbnRzIGNvdWxkIHJlY2VpdmUgdGhyb3VnaCBhIHN0YW5kYXJkIGludGVyZmFjZS4gJm5i c3A7VGhlc2UNCiBhcmUgYXR0ZXN0YXRpb25zIG9mIGEgZm9ybSwgYnV0IHRoZXnigJlyZSBub3Qg cmVhbGx5IG1lYXN1cmVtZW50cywgYXMgaGFzIGJlZW4gcHJldmlvdXNseSBkaXNjdXNzZWQgaGVy ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkVsaW90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pk9uIDEwIE1hciAyMDIxLCBhdCAyMDowMiwgU21pdGgsIE5lZCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5lZC5zbWl0aEBpbnRlbC5jb20iPm5lZC5zbWl0aEBpbnRlbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRo ZSA4MDIuMUFSIHNwZWMgZG9lc27igJl0IEFGQUlLIHJlcXVpcmUgSURldklEcyB0aGF0IGNhbuKA mXQgY2hhbmdlLiBCdXQgbm90IGN1cnRhaW4uIElzIHNheXMgdGhpbmdzIGxpa2U6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+QTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPmRldmljZeKAmXMgRGV2SUQgbW9kdWxlIHN0b3JlcyBlYWNoIG9mIGl0cyBEZXZJRCBzZWNy ZXRzIHNlY3VyZWx5IGFuZCBzdXBwb3J0cyBzaWduaW5nIG9wZXJhdGlvbnMgdGhhdCBwcm92ZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPnBvc3Nlc3Npb24gb2YgdGhlIHNlY3JldCAoYW5kIHRodXMgdGhhdCB0aGUgZGV2aWNlIGlz IHRoZSBzdWJqZWN0IG9mIHRoZSBhc3NvY2lhdGVkIERldklEIGNlcnRpZmljYXRlKSwgd2hpbGU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj5lbnN1cmluZyB0aGF0IHRoZSBzZWNyZXQgcmVtYWlucyBjb25maWRlbnRpYWwgc28gdGhl IGRldmljZSBjYW5ub3QgYmUgaW1wZXJzb25hdGVkIGJ5IG90aGVycy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BbiBJbml0aWFs IERldmljZSBJZGVudGlmaWVyIChJRGV2SUQpIHByb3ZpZGVkIGJ5IGEgZGV2aWNl4oCZcyBzdXBw bGllciBjYW4gYmUgc3VwcGxlbWVudGVkIGJ5IG9uZSBvciBtb3JlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+TG9jYWwgRGV2aWNl IElkZW50aWZpZXJzIChMRGV2SURzKSwgZWFjaCB1c2luZyBhbiBleGlzdGluZyBvciBhIGZyZXNo bHkgZ2VuZXJhdGVkIHNlY3JldCwgZmFjaWxpdGF0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+ZW5yb2xsbWVudCAocHJvdmlz aW9uaW5nIG9mIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGNyZWRlbnRpYWxzIHRv IGF1dGhlbnRpY2F0ZWQgZGV2aWNlcykgYnkgYSBsb2NhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPm5ldHdvcmsgYWRtaW5pc3Ry YXRvci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BIGRldmljZSB3aXRoIERldklEIGNhcGFiaWxpdHkgaW5j b3Jwb3JhdGVzIGEgZ2xvYmFsbHkgdW5pcXVlIG1hbnVmYWN0dXJlciBwcm92aWRlZCBJbml0aWFs IERldmljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPklkZW50aWZpZXIgKElEZXZJRCksIHN0b3JlZCBpbiBhIHdheSB0aGF0IHBy b3RlY3RzIGl0IGZyb20gbW9kaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5MRGV2SURzIGNhbiBh bHNvIGJlIHVzZWQgYXMgdGhlIHNvbGUgaWRlbnRpZmllciAoYnkgZGlzYWJsaW5nIHRoZSBJRGV2 SUQpIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+YXNzdXJlIHRoZSBwcml2YWN5IG9mIHRoZSB1c2VyIG9mIGEgRGV2SUQgYW5k IHRoZSBlcXVpcG1lbnQgaW4gd2hpY2ggaXQgaXMgaW5zdGFsbGVkLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LU5l ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5SQVRTICZsdDs8YSBocmVmPSJtYWlsdG86cmF0cy1ib3Vu Y2VzQGlldGYub3JnIj5yYXRzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg R3V5DQogRmVkb3Jrb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpnZmVkb3Jrb3c9NDBqdW5pcGVyLm5l dEBkbWFyYy5pZXRmLm9yZyI+Z2ZlZG9ya293PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIE1hcmNoIDEwLCAyMDIxIGF0IDc6NTkgQU08YnI+ DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPkxhdXJlbmNlIEx1bmRibGFkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxnbEBpc2xhbmQtcmVz b3J0LmNvbSI+bGdsQGlzbGFuZC1yZXNvcnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpyYXRzQGlldGYub3JnIj5yYXRzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJhdHNAaWV0Zi5vcmciPnJhdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjwvYj5bUmF0c10gODAyLjFBUiBkZXZpY2UgaWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+SGkgTGF1cmVuY2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsgV2UgdGFsa2VkIGFib3V0IGRldmljZSBpZGVudGl0eSBvbiB0aGUgUkFUUyBjYWxsIHRv ZGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7IEZvciBSSVYsIHdl4oCZcmUg cmVseWluZyBvbiB0aGlzIElFRUUgc3BlYzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxh IGhyZWY9Imh0dHBzOi8vMS5pZWVlODAyLm9yZy9zZWN1cml0eS84MDItMWFyLyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vMS5pZWVlODAyLm9yZy9zZWN1cml0eS84MDItMWFy Lzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsgVGhhdCBzcGVj IGRlZmluZXMgSW5pdGlhbCBhbmQgTG9jYWwgRGV2aWNlIElkZW50aXRpZXMuJm5ic3A7IEluaXRp YWwgRGV2SUQgaXMgc2V0IGJ5IHRoZSBtYW51ZmFjdHVyZXIgYW5kIGNhbuKAmXQgYmUgY2hhbmdl ZCBvciByZXBsYWNlZCwgd2hpbGUgdGhlIExvY2FsIERldklEIGNhbiBiZSBzZXQgYW5kIGVyYXNl ZCBieSB0aGUgb3duZXIgb2YgdGhlIGdlYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsgVGhlIHNwZWMgZG9lc27igJl0IGFkZHJlc3MgZGVjaWRpbmcgd2hpY2ggaWRlbnRpdHkg dG8gdXNlIGZvciBhbnkgc3BlY2lmaWMgYXBwbGljYXRpb24sIGJ1dCB0aGUgaW50ZW50IGNsZWFy bHkgaXMgdG8gYWxsb3cgdGhlIG93bmVyIHRvIHVzZSB0aGUgbWFudWZhY3R1cmVyLXN1cHBsaWVk IGlkZW50aXR5IHRvIGluc3RhbGwgYW4gb3duZXItc3BlY2lmaWMgaWRlbnRpdHkNCiBpbiBhIGRl dmljZSwgYW5kIGVyYXNlIHRoZSBvd25lci1zcGVjaWZpYyBpZGVudGl0eSBsZWF2aW5nIHRoZSBt YW51ZmFjdHVyZXIgaWRlbnRpdHkgaW4gcGxhY2Ugd2hlbiB0aGUgZGV2aWNlIGlzIGRlY29tbWlz c2lvbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsgTWFueSBkaWZmZXJlbnQgc3BlY3MgbXVzdCBoYXZlIGV4YW1p bmVkIHRoaXMgcHJvYmxlbSwgYnV0IG9mIGNvdXJzZSBpdCBuZXZlciBodXJ0cyB0byByZS11c2Ug c29tZSBvZiB0aGVzZSBpZGVhcyB3aGVyZSBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyBUaHg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPi9ndXk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Im1zaXBmb290 ZXIzMGIzZDUzOCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuNWluO3Rl eHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPkp1bmlwZXIg QnVzaW5lc3MgVXNlIE9ubHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUkFU UyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UkFUU0BpZXRmLm9yZyI+UkFUU0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JhdHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmF0czwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_62FFA122047E468CA2DD5A0E4E8EAF74intelcom_-- From nobody Thu Mar 11 11:00:20 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 88B2F3A0D97 for ; Thu, 11 Mar 2021 11:00:18 -0800 (PST) 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_MSPIKE_H4=-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 5uTCWlwPpYZo for ; Thu, 11 Mar 2021 11:00:17 -0800 (PST) Received: from p3plsmtpa12-08.prod.phx3.secureserver.net (p3plsmtpa12-08.prod.phx3.secureserver.net [68.178.252.237]) (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 EA0EB3A0D95 for ; Thu, 11 Mar 2021 11:00:16 -0800 (PST) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id KQXelJLlTGlIUKQXflzXAe; Thu, 11 Mar 2021 12:00:15 -0700 X-CMAE-Analysis: v=2.4 cv=cd0XElPM c=1 sm=1 tr=0 ts=604a68bf a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=d89gtNoHE_lvAHdhvrEA:9 a=QEXdDO2ut3YA:10 a=LrXWqHzY8c5mkKdJaqgA:9 a=eN45PPH_a0raEnLw:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_33FB6DE4-01D3-456F-9153-95ABA1781D2C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 11 Mar 2021 11:00:14 -0800 In-Reply-To: <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> Cc: Eliot Lear , "rats@ietf.org" , Guy Fedorkow , "iotops@ietf.org" 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> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfBQUNUAJtGCqXhXlyUCCwpKZcbAGmBaTXxN9x+qg8bjMVQTB9s15dtOGZ9WjR94s0HKtk/w8qLqThww1qn7WA/vv9+MFKMiJ/ayESoXZCa3AD1K+/dTG aSQnqVNGb+GfX3GZuCulot8wzqDIgfWzl2ZIRLdcTlDbc4vN37jZlEU3C/+piRT3XmssR1XHoQUBHAOCw3rQ6Qii2WAMtmvkbzMpP0V2xpRilZWvss01x8J6 AAJH18UCmACA0bAHfdIiDr3fVfrhMw3ruFEQ4lPIXMS0G/hFfrI81Uzc0RQhOM8akdhhrK7bwHiIPMjynxU/2A== 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: Thu, 11 Mar 2021 19:00:19 -0000 --Apple-Mail=_33FB6DE4-01D3-456F-9153-95ABA1781D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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).=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. 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=99= t enough to get access. --Apple-Mail=_33FB6DE4-01D3-456F-9153-95ABA1781D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.



= --Apple-Mail=_33FB6DE4-01D3-456F-9153-95ABA1781D2C-- From nobody Thu Mar 11 11:13: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 630E73A0E1E; Thu, 11 Mar 2021 11:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.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 V0wvC-OYwXMx; Thu, 11 Mar 2021 11:13:38 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 277393A0E1A; Thu, 11 Mar 2021 11:13:38 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id p8so723604vki.7; Thu, 11 Mar 2021 11:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=adG6uzpbviDnP1EzUSUu63ppaq/APxuHaE8PTZk2J7Q=; b=ntLRAk/NT2zTR8hBaUMUzjOHtPNLDw0eqD3xQtWoIFvpv5HIxSTLLRBwMusNAOtbWs MOXwqYalbtdz+5tdC8GG2UKAFaEJx1E2Y0KNSIZhV507DUKkH/DSGIDiIshwfFp1CM+O c4q53UipVV72npWcM+J+HsFGYSHSSF1b7B5PNLN3lJb0NaTvDuYN1F3leZiLXbMKflil 1ad/wK8ymRSedqeSIyPkMRjT7l3MW1TEwqbzZPshzUsTbe0o8/VxBhu/6tI0W/VS8sNi Y0SMOH5MY5n4ydCIQtdb6IBjEXxtYB1E53YJEWgJnBOS7En3Bg8sW/BUgizYBrPScp51 1RQw== 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=adG6uzpbviDnP1EzUSUu63ppaq/APxuHaE8PTZk2J7Q=; b=onRDBCa/JH2b0MGCS0k96NBFnoZS7ccWk2vUGKn2skzw3YVQFmeZaTLcJHQN6YdNmJ DFYVddvSfVl9sm3KE28kXGuRzgbX7GydV6OIssS6SGw/xq/4QR+ZJBbHLaYR3kk9rjg3 2UyTnfa/fcEdqtAAE5IzotWQMYDIzLxhfVYSheAQaVxJPWZqkmibGwfUTzqxLGhjrAYi UXWXVT2DUp5V51V68qN+aZKxLgCKLDMXBTQfLK1Fq4SoadJ+OPMags/QhDIKjRMpL8mJ PdMcwW/KPTry9t8YPPHsBPzgNFXcjEf1AZfhFmxcqTFl2riOIBqKa57rkKzDX25oTLqQ sIoQ== X-Gm-Message-State: AOAM531nW0OHyn1H4xUMqQk9rnAKrX7anICWB7R5ULnPZZU7yulVcKR2 IZF9AFpzVamF6dmszAKj5KXdUtLmHZW6zYAR5XI= X-Google-Smtp-Source: ABdhPJy4CPs4CmMCobjFfPHtEt4QAgZ0UPAj4wkZlPWscf+aNGKq+3SlLAb7iq/R10JOfZFERWa7HhrdpERXBXjsKVw= X-Received: by 2002:a1f:50c5:: with SMTP id e188mr5880706vkb.19.1615490015295; Thu, 11 Mar 2021 11:13:35 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> From: Ira McDonald Date: Thu, 11 Mar 2021 14:13:24 -0500 Message-ID: To: Laurence Lundblade Cc: "Smith, Ned" , "rats@ietf.org" , Guy Fedorkow , Eliot Lear , "iotops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007ffbe305bd4794a7" 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: Thu, 11 Mar 2021 19:13:40 -0000 --0000000000007ffbe305bd4794a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =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 comprom= ised or > the device being owned or such is a separate topic. Discussion of it seem= s > 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 i= s the > simplest case to describe. It is not at all privacy preserving for some u= se > 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 M= AC. > > 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 a= n > implementation of this one. > > > A related solution is to have a privacy proxy between the Attester and th= e > 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=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 lifecyc= le > issues that come up in real deployments for chip makers and complex suppl= y > 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 ca= se > 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 > mentio= ns > 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 w= ant 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 no= t 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 > --0000000000007ffbe305bd4794a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Laurence,

Thanks to the w= onderful *free* IEEE Get 802 program, you can go to this link (from Guy ear= lier)
and create your own durable free Get 802 account and then d= ownload IEEE 802.1AR-2018 (and
anything else from the whole IEEE = 802 series that you need).


Cheers,
- Ira


On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <lgl@island-resort.com> wrote:
<= /div>
I want to unpack and unfold a few things here.
Permanence / Lifecycle / Privacy=C2=A0=E2=80=94=C2=A0I = think the main topic here is about when an ID changes relative to the lifec= ycle of the device and how this relates to privacy.

Compromise=C2=A0=E2=80=94=C2=A0I think compromise due to algorithm= s being compromised or the device being owned or such is a separate topic. = Discussion of it seems orthogonal, should go into security considerations a= nd 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 som= e use cases (e.g., mobile phone), but is OK for others (e.g., dumb sensor).= =C2=A0

I was thinking other folks might define oth= er IDs for other use cases. Maybe the time has come to invent one or two of= those and put them in EAT.

Some Solutions<= /div>
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 fa= ctory reset. I think this lines up with the way some MAC addresses are mana= ged 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 authenti= cate the Verifier and/or Relying Party and generate a distinct UEID or SUEI= D 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 A= ttester and the Verifier that makes RP-specific UEIDs or SUEIDs.
=

Separation of ID from Attestation Key<= /div>
An ID that is not signed is nearly useless because anyone can for= ge 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 separati= on. The reason EAT separates them is to have a lot of flexibility to deal w= ith the privacy and lifecycle issues that come up in real deployments for c= hip makers and complex supply chains.

For example,= FIDO uses group attestation keys to deal with the privacy issue. One key i= s put into 100,000 plus devices which makes it statistically not very usefu= l for tracking users. Maybe the device manufacture uses this tactic for bil= lions of devices. Then maybe a use case involving only millions of these de= vices needs a truly global ID and have the means to program it. This can wo= rk if the keys and IDs are separate.

Or maybe the = manufacturer changes signing schemes moving from a primitive MAC to EC-base= d pub key and onto some sort of DAA while maintaining the same scheme for d= evice IDs.


Possible harmonizatio= n with other Device IDs?
I = noticed that=C2=A0birkholz-rats-suit-claims= =C2=A0mentions a device ID based on UUIDs. We should probably take a look a= t how this relates UEID. There=E2=80=99s probably others to check out. We p= robably want to re use a lot of the claims from Evidence in Attestation Res= ults 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 IEE= E once, but that wasn=E2=80=99t enough to get access.

<= div>

________________________________________= _______
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats
--0000000000007ffbe305bd4794a7-- From nobody Sat Mar 13 17:34:48 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 8660B3A1557; Sat, 13 Mar 2021 17:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znlp6wpISspH; Sat, 13 Mar 2021 17:34:44 -0800 (PST) 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 1376F3A1558; Sat, 13 Mar 2021 17:34:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9ED8238A02; Sat, 13 Mar 2021 20:39:59 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dj4I918SAU71; Sat, 13 Mar 2021 20:39:59 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EE97738A01; Sat, 13 Mar 2021 20:39:58 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0543E8F5; Sat, 13 Mar 2021 20:34:42 -0500 (EST) From: Michael Richardson To: Eliot Lear , "rats\@ietf.org" , iotops@ietf.org In-Reply-To: References: 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: Sun, 14 Mar 2021 01:34:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 n= ot 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 IDevID is open to intepretation) > I=E2=80=99ve had this thought in two > different contexts: What if the signature algorithm, CA, or private k= ey > 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 we = need to > seriously think about RATS or SUIT providing a standard protected TLV > list that deployments could receive through a standard interface. > These are attestations of a form, but they=E2=80=99re not really meas= urements, > 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. =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+93Q3WUFAmBNaDEACgkQgItw+93Q 3WVsqAf+KPTASuR3ffbdzRk5XUX8l+1jmCWoEsrDartzXk7i7umhdW6vJSsQhchf jFxYd+IxK8p9IJbqQGUv6UGL0dDsHPdzYXsSbbAtEHRYWGmrdX2IarJM5Wymbfoe yXsduHD0wU9ncHHRCg/dkEsl0OBSaNlnPr9vNThQajdF+9Vy/VrY6sjubacY+ULX hqqE+T25UM5S39qUsO8Cbuuyqr1xg54sajRfMWayx8d7jDiE16DrUBv4cmGhIN4x BBKAn8rFVpJQ+ZlWdxTqodVNTTFcp8I9J+9rHUUwll+iXOrahPVx3dCXWh+nS5/r K5iQAlErbE86LFzPo4acSAuztnunNQ== =qbFq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 14 00:22:54 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 CAE2A3A1F4B; Sun, 14 Mar 2021 00:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.9 X-Spam-Level: X-Spam-Status: No, score=-11.9 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_PASS=-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 tSrUAOp5_l0r; Sun, 14 Mar 2021 00:22:51 -0800 (PST) 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 84A3F3A1F4A; Sun, 14 Mar 2021 00:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7631; q=dns/txt; s=iport; t=1615710170; x=1616919770; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=HkNaz6c17umO9kQeh7rk3bNxfEvLob84xpyuBidgSXg=; b=YDvZTRgcVBxhvHHCRsEa8JOp4g4l0wmeFEmm9hIRzF7HwsIlNigRnFFz liIGOiwxM4HiuqM7wWZK+2xwCrpMUcenTK5mG3FelN0GG4uI78kkYJnXB wNoxNxRRz0ByVFedQBQvax7etlpzBrLHYuWolBhAuk08cuuRDCvXXdzdY o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AMAACNxk1gjBbLJq1RCRkBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QESAQEBAQEBAQEBAQEBgX0CAQEBAQELAYN2AScShHKJBIhAA5Q2hiMUgWgEB?= =?us-ascii?q?wEBAQoDAQE0BAEBgViCdQKBdSY2Bw4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBA?= =?us-ascii?q?QEBhkeGRQECAgEjVhALQgICVwaDAwGCZiGrZHeBMoVYhHoQgTkBgVKFKgGFF?= =?us-ascii?q?oEvQoIMgREnHIFsbD6EFRKDMDWCKwSBZVsGCGIwgTIHOwEFBAoVCJE2Eow6n?= =?us-ascii?q?GiDDIMzgT+XTAMfgz6KXIVXkCSGQ5A+nE4Bg3gCBAYFAhaBWwIvgVkzGggbF?= =?us-ascii?q?TsqAYI/PRIZDY44jjBAA2cCBgEJAQEDCY5pAQE?= IronPort-HdrOrdr: A9a23:fay7EKEtH5CN+3ZvpLqEaseALOonbusQ8zAX/mp6ICY0TuWzkc eykPMHkSLlkTp5YhsdsP2JJaXoexLh3LFv5415B9ifdSng/FClNYRzqbblqgePJwTb+vRG3a ltN4hyYeeAbmRSqcb/7E2GH807wN+BmZrEuc7kw31gTR5nZshbhm8TNi+hHkJ7XwVAD5Yifa DshPZvnSaqengcc62AakUtYu6rnayvqLvWJToPBxsq82C1/FeVwY+/NQSE1REDVD4K5rEu/Q H+4mrEz5Tmle2nwRnB0GKW1bBqoZ/Kz9tOA9HksLlzFgnR X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,245,1610409600"; d="asc'?scan'208,217";a="34169395" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2021 08:22:45 +0000 Received: from [10.61.144.24] ([10.61.144.24]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 12E8Mj9K011797 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Mar 2021 08:22:45 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_0DE1A019-940F-4EBB-BF81-AFC0ED2D4535"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Eliot Lear In-Reply-To: <22167.1615685681@localhost> Date: Sun, 14 Mar 2021 09:22:44 +0100 Cc: iotops@ietf.org Message-Id: <75F17573-ED6C-4A08-88A2-574BF06BD91B@cisco.com> References: <22167.1615685681@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.24, [10.61.144.24] 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, 14 Mar 2021 08:22:53 -0000 --Apple-Mail=_0DE1A019-940F-4EBB-BF81-AFC0ED2D4535 Content-Type: multipart/alternative; boundary="Apple-Mail=_D7EA7E36-B65B-479F-A3F3-A92892D2FC86" --Apple-Mail=_D7EA7E36-B65B-479F-A3F3-A92892D2FC86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [moving rats to bcc=E2=80=A6 continuing discussion on iotops] Hi Michael, >=20 >=20 > (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 = IDevID is > open to intepretation) Yes. >=20 >> 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? >=20 > 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? The device is vulnerable. The question is whether a repair can be = effected. >=20 >> Can one recover with an update? >> What if there are attributes in the cert that I want to >> dink and share with the deployment? >=20 > Please define "dink" for me. I know of only one definition from the = school yard. > Does this mean remove? replace? Yes. >=20 >> I=E2=80=99d like to take that latter case off the table, but then we = need to >> seriously think about RATS or SUIT providing a standard protected TLV >> 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. >=20 > Can you give me an example of one of these attributes? Soooo=E2=80=A6. Here=E2=80=99s an example: Suppose I am a system integrator who needs to assemble a device out of = constituent components that includes a particular software load. I wish = to claim to be the manufacturer of the device, as I am the one producing = the final product. I want to therefore provide the onboarding service. = That requires a change of URL for the MASA in BRSKI terms. I may also = wish to change the MUD-URL based on the software load. The core question I am asking is this: we have attributes about the = device I these certificates that really could be elsewhere. But where? Eliot --Apple-Mail=_D7EA7E36-B65B-479F-A3F3-A92892D2FC86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[moving rats to bcc=E2=80=A6 continuing = discussion on iotops]

Hi = Michael,



(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 IDevID is
open to = intepretation)

Yes.


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?

The device is vulnerable.  The = question is whether a repair can be effected.


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?

Yes.


I=E2=80=99d like to take that latter case off = the table, but then we need to
seriously think about RATS = or SUIT providing a standard protected TLV
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?

Soooo=E2=80=A6. Here=E2=80=99s an example:

Suppose I am a system = integrator who needs to assemble a device out of constituent components = that includes a particular software load.  I wish to claim to be = the manufacturer of the device, as I am the one producing the final = product.  I want to therefore provide the onboarding service. =  That requires a change of URL for the MASA in BRSKI terms.  I = may also wish to change the MUD-URL based on the software = load.

The core = question I am asking is this: we have attributes about the device I = these certificates that really could be elsewhere.  But = where?

Eliot
= --Apple-Mail=_D7EA7E36-B65B-479F-A3F3-A92892D2FC86-- --Apple-Mail=_0DE1A019-940F-4EBB-BF81-AFC0ED2D4535 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBNx9QACgkQh7ZrRtnS ejMdnwgAh7WBozHUt6hQsxHQw7RJmUEWDaUZsaWqz2H99e/1hKVoMZq7eDHpc+nn echgX8UN2Pxdnyi4y05H9AV7LbTQ94S1VWmsAeGNHUE0teTWS2eKcsfi6uk3WIE0 IAaMzqmYKNykx1Hc50PP+c/g6M0OOSfqXmuk49N3pKXCV1kmhspIeive6CJ/6Zdi pe/irOzzt6OeWo6KdgRKku+CfgBAO8utyuTENOTflWBlplyRxelAZ1KF2snLaVsp 0p8BtND5TNPKlMetYcWxcmx0NFNO5CjiA5+tWXCMWLkvKicIVIN8EP/zY5438izn S1EokndFA2s8ZJAc7DfC52YAZ7s0eg== =0j4a -----END PGP SIGNATURE----- --Apple-Mail=_0DE1A019-940F-4EBB-BF81-AFC0ED2D4535-- From nobody Sun Mar 14 11:14: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 27C723A0CE7 for ; Sun, 14 Mar 2021 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GdbWSsnoniHh for ; Sun, 14 Mar 2021 11:14:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103833A0CE3 for ; Sun, 14 Mar 2021 11:14:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C0EF1389C4; Sun, 14 Mar 2021 14:19:31 -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 wMX05GZUURpF; Sun, 14 Mar 2021 14:19:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B1E13389C0; Sun, 14 Mar 2021 14:19:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 268B21C0; Sun, 14 Mar 2021 14:14:10 -0400 (EDT) From: Michael Richardson To: Eliot Lear , iotops@ietf.org In-Reply-To: <75F17573-ED6C-4A08-88A2-574BF06BD91B@cisco.com> References: <22167.1615685681@localhost> <75F17573-ED6C-4A08-88A2-574BF06BD91B@cisco.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: [Iotops] assemblies and onboarding and 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, 14 Mar 2021 18:14:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >>> 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? > Soooo=E2=80=A6. Here=E2=80=99s an example: > Suppose I am a system integrator who needs to assemble a device out of > constituent components that includes a particular software load. I > wish to claim to be the manufacturer of the device, as I am the one > producing the final product. I want to therefore provide the > onboarding service. That requires a change of URL for the MASA in > BRSKI terms. I may also wish to change the MUD-URL based on the > software load. > The core question I am asking is this: we have attributes about the > device I these certificates that really could be elsewhere. But wher= e? It seems clear that the assembler needs to create a new IDevID, and they ne= ed to store it somewhere, and it needs to express itself rather than the individual components. It seems to me that if one can effect to load a particular software, then o= ne ought to have control via that software load of the onboarding and which IDevID is expressed. Remembering that we invented multitasking because CPUs were very expensive, leading eventually to virtualization and containers, but that most of our security issues are the result of sharing of resources, I suggest that maybe the answer here is to stop sharing when doing an assembly. The "control plane" CPU for the assembly doesn't have to actually do any of the work other than coordination and onboarding. That having a $3 ATMEGA MCU hold all of the desired upward (for onboarding = of the assembly) and downward (for keeping track of the onboard components) might make the most sense. I don't think that's a big cost for an assembler if the assembly is worth thousands to fractions of millons. (I come back to the bogie assembly for a railcar, which has got to be worth= a fair bit. Also: airplanes and cars. However, we should think about smaller assemblies as well, including things like a desktop computer's CPUs, GPUs and MCUs in keyboards and hard disks. Component stereo/AV systems in homes and in theatres.) I'm not suggesting this MCU is an active Registrar, but rather, it's the like it's the TPM/CA for a Registrar component that the assembler brings in= to the do work stuff out. A tool if you like. So, it would store the credentials. It's a superset of the KDC. (insert storey about KDC that was drywalled in, but kept operating for year= s) I would propose we think about the commonalities among onboarding solutions (upward and downward), and probably we need to write a YANG module to expla= in it all. We should consider that one might use DPP to onboard the componen= ts of an assembly, which then uses BRSKI to join a superior assembly, and that superior assembly then uses FIDO-DO to be deployed. We need to take into account Kerberos, OAUTH2/GNAP and ACE operational keys. =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+93Q3WUFAmBOUnEACgkQgItw+93Q 3WXF6wf8CDD8+hbdcoqT+J9H0tp9+0NtQ0sd3msUiTI0x0pbYihlcEEAf1cdOfGL +Cez48uDoJCQ+exD0K9QaTat8PKbJfcbOcX+d6DWDH/HyIu1JYcDBBOpYZr1Iyxh n8H4Je1K1yoLoN2nQF4wz0FGeFeuuZL5L+dvN9R/NFxb32C79NEYHxlPBRM95UD0 Wd1fsl3enzl9XFACMSnxpIaWumqt5y4OWRuec2Kg1veusUGxXjfLZy47HorKbu/o aIF8cW32RiQkivv6pkGYoWvs79+U3h11NLFE9t7rQ349HRij3OyWuejcRVHHgLY5 ZXEdxxjMeFfN8TD2JxlnMo+JbZ+XPg== =G+Co -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 15 06:30:44 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 1A7463A1195; Mon, 15 Mar 2021 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=bcI57Mq4; dkim=pass (1024-bit key) header.d=juniper.net header.b=Am4JL01V 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 naexMtsya8KN; Mon, 15 Mar 2021 06:30:41 -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 646743A1188; Mon, 15 Mar 2021 06:30:41 -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 12FDPV9D010097; Mon, 15 Mar 2021 06:30:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=faUQlFR9CYkjlB5NNv+scH0GT/Rd4Zdk/chQdZV8BFc=; b=bcI57Mq4/H5BzEI6DGK9s9X68ayCY0fnMIJzh2HMyJyumhyK4yxhMommQnikvPfKMdjJ 12gBt0CYATG3LS1pYsHVIdwsGF0KxB4JECVTfMcnlHe9TQslHzPu+Y4BanBR7WpCNzd6 xcqxd9yZLWLczoQMph7tnGVTPUwjm3vCJ4RUE4MZAauPYho/8ociY/cGSVImuGQX9WXz ojduBTbMoRFbt73CoE+09lUA2rNIhgSLo9XbSB2vXYY7YOQHGx1Um4dKXsrqFP/NiRiD TcOYNAq6nPyzLVvpovYJV5SP9InNpvcPFpgpWiJscpAOgfXuVK+La9kw3LIoKilStGHE lg== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2174.outbound.protection.outlook.com [104.47.55.174]) by mx0b-00273201.pphosted.com with ESMTP id 378vheb2qv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Mar 2021 06:30:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KglPb4SJGxojLEkLJPYMts1MTXb17xzmad7OibLIcS5kiOOEBIRfD3GhA37msjNnXmln2ZFNhMGXqnNPZLruYh4336KJsUkVxgyKkWWfW6gPsi0yADPLEHMHtktfNAb1vyPJJVrHIADPXX2SZeCZ6mqvwrSZ288KP1NFJ8eqvruV4Zs6IaCAKw9Z+EMEio6jw2SbtUJI2Gnn6rKchChty1KDB6bthMngJn6i/Gf6kmpWQ0+wrG3cggRKaF3dOtGe0cEMDbirBTjL4ef0Fu/7Mfwor2M54Hes3XlRU3h1TlnZrINAq9Zi8EAp8rAK/v7vBvYCCVJMzVMsbHTl+7sQ1w== 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=faUQlFR9CYkjlB5NNv+scH0GT/Rd4Zdk/chQdZV8BFc=; b=PyeK0pcqILdaH6GIjCGGoJOc2fBE/7pwB1kol3DyoAaStCb7Xl83JyYpKeW0V3tnEtVEt8AQ16BglFxNVydot6cloIRFTz43P79wYOf9ihQIuzgT+T0rbjLHJCg1CoSZCoFB/6Hk3XJ4euzfE1hDrZ2Ag/dWG5FSvIyD3Ng7pVW0kcHtrAP7aA6TDf9GIV24E+dOZ3axGQ1b1Si3ArB+nvQowaedRakLMYOSWUYiWuDeWmPwEfBCSgOLJ84IPOxvhZITT1BThJD28OxT3lNu+LIDaemles9qVsHtQW7yCAjGG9vbFwk3j0L8lqwDGGBOm0Szsv+zT/szMHAT9qB1ug== 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=faUQlFR9CYkjlB5NNv+scH0GT/Rd4Zdk/chQdZV8BFc=; b=Am4JL01VXBGFpOL7egEMLXvlci1ochLClGvEXlBCV71rXNXv5lb4SXv/9JO4LrEheJFSzZDvLxtZxjGp61WLemf+3aAY8lL0qa3I/vPRZPr/mwfKPePOG9zSrypPSJ7YyYr9P7NBJDKH8MOXIZCgLERD3EupW+XbaZC4BEx3Ww0= Received: from BLAPR05MB7378.namprd05.prod.outlook.com (2603:10b6:208:298::10) by BL0PR05MB5169.namprd05.prod.outlook.com (2603:10b6:208:8b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.13; Mon, 15 Mar 2021 13:30:36 +0000 Received: from BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::6c50:5962:d313:b6c3]) by BLAPR05MB7378.namprd05.prod.outlook.com ([fe80::6c50:5962:d313:b6c3%8]) with mapi id 15.20.3955.011; Mon, 15 Mar 2021 13:30:34 +0000 From: Guy Fedorkow To: Michael Richardson , Eliot Lear , "rats@ietf.org" , "iotops@ietf.org" Thread-Topic: [Rats] [Iotops] 802.1AR device identity Thread-Index: AQHXGHI+lWZ/qcXa8kmN7GVHqvFoYKqFDEQw Date: Mon, 15 Mar 2021 13:30:34 +0000 Message-ID: References: <22167.1615685681@localhost> In-Reply-To: <22167.1615685681@localhost> 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-03-15T13:30:32Z; 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=0ab3000d-4c5f-4b47-b99d-ec173ef24062; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=juniper.net; x-originating-ip: [24.62.29.247] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4bf9642e-d105-4a37-b1c7-08d8e7b68368 x-ms-traffictypediagnostic: BL0PR05MB5169: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wp3GyeU4v4/wwuAFa16jiu0U/kaWBMLbfPWzHAdyCtrqYrqkvzQuwdLfJsm0+qbjmQ+pd74FNDCdWVXArxkjvKTOJUyz5RTHI85KfxA9xPog/zCCJeS0JLlbPR9K36mlDfRqZGi9yATXQY49yQicAQ39JWLZncJK44Gnk3G9QlrLJLl4+/Olvr9/aC6RS1AuJnP1uRkwFqhy7ekiRj8mDmfkZISyeDKm5VPCRsMg+OdBNllcY9riJYRhA/FADIDWJBFV5hTb/WNYyLVskXMVL8jqAfxOPZqT60smbxxsOtLvCOl8zfqtgEGtcBSnPsKXcQjzm7sTL9R/UVE512rqx06A3iT1uqo/gLA/s6SWQztcQtnw1yWDXaX7uNGPsemsDJTG/EaHCyq12kBxJZt+bzUMaRoR5rmARTxuVn7QFhTBup/HxhxTCZy97QUyFgbMdGEGMEkEB5WEJx6Tzo3DhmJXb/oaXc8LL4G58Ee/1hlmlAj11ObH9Bj4e/Qv8UjxUiVr7x5OpNM6Lp51nmEzlmbRvhF59aBHRzt6Y2INep9W68Ref5X4l+iSCPu77SBh 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)(346002)(396003)(376002)(366004)(136003)(39860400002)(2906002)(76116006)(55016002)(66476007)(86362001)(52536014)(83380400001)(33656002)(9686003)(66574015)(478600001)(316002)(186003)(7696005)(6506007)(8676002)(110136005)(53546011)(8936002)(66946007)(71200400001)(66446008)(64756008)(66556008)(26005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?dm5hS2wrQklmQitUcG5JcTFOTlZhMXNyWWVsZVhoTklDMmQxMmtodzROQ2FR?= =?utf-8?B?TWMyWEFFZnJqbFNKZVkyWlNkRm1WNHRHU1pYcnBmS0Rxd3g4dGdCdlhTclRZ?= =?utf-8?B?NzNRYU9oUHFTK0lGQjNMSVNxZmVNUmU5QVc3RncwMjZLNVpBKzBEd29WaTk0?= =?utf-8?B?ZkE0NCtpOWNVd2FDZElMNjFNYStWQXhjc3JDKzVsdWVCOW0zK3hxRjlQRXVw?= =?utf-8?B?cjlYWjNvNm91bEJsZWg1dEtDZ05VTktBd09VdUlFVWN2NU5CZWhHT3F5RDVv?= =?utf-8?B?amNVMlZ5UGhXTmtaNEIvdDI3dFBVRWlJUFZhcWl2UHdFcWdveHdYb08raVE1?= =?utf-8?B?clFPaERqWkY5T0pVMlUvV0NjSlR2ZW9NK1dBZkdSdjRtZFVRcGUwM1l6ZFlX?= =?utf-8?B?a0JuR2NHdFFHOTU1djFOTUxBOWx5bDB1LzRKM0dIWGZsRlpuK0xHbUxzVVVt?= =?utf-8?B?NWdnaHR4TzRZaDJRNDU1NGN2a0J2c2lXK2pJOW1lZjFTdUtUZ1J3UklVMCty?= =?utf-8?B?QUxGK1FKMzN4azVtdDdGNEQxTDR1ZlcxS285WDFsNVAvQUJwbjJOSTQvN0w4?= =?utf-8?B?WW8zZ3pZTzgyRDNjYmppWE4vVWwyZ29iZFl1YXNCMnovUm5oai91OFFHNjlk?= =?utf-8?B?NFFUbVBrRnFhL2M3bzQ0ZzZSZ2w3T09IMHU2QUtsazliaEZuRk8xaUUrb1BO?= =?utf-8?B?VHV5TktkMEcwZWo4N2Rycm5JT1c4NkVqQlFxTkM3U0hkQTdyUlh0Y2l3SEp2?= =?utf-8?B?OHl2dlhRMFZIZkY2aGZMZHNzWGt1b3k2YkIwWnQydWREVlhLdnVzV29pREFO?= =?utf-8?B?RW53YXhyUEUrNVF1WkhmdUdmV2daOU9SV2Z4dVpiZTJlbHFLVUpSR2FlT3JM?= =?utf-8?B?ZWdubllpZEFqVVQvSFUxQlhRYUg3aVRDMTVWWFBMV2NzTzZmUjRZTjBFS0VS?= =?utf-8?B?RHV4MGJCdWNmenFOZStFYm0zRmtNT0JJdUprT2J0YkwzYjE0OUNRQVY5Wktz?= =?utf-8?B?TzljZ2x3SUZPRUQ4OFlyZUpMYzFlaTBNNWJ3enUzakl6b0swYUQ2R0JHZUdI?= =?utf-8?B?S0ZVZkphUDNBZE9IWVU0cWFTenlmTGhCZ2piWDZsQklkbWFUQXMycVBpT1lS?= =?utf-8?B?LzE1OVBDdktMMEZ4VlJqeUJXMHdyL2MrYVBqOUlQNktHcXhqNlorUjlwM2dz?= =?utf-8?B?aUhXRklza1dWSHBPVUpUNUxaN0lpdjVaQVZENC9NWEkwSE12WmdLSGtsa3JY?= =?utf-8?B?aVNPK3BxQXU4Vk50TU16L1EvdFdIWTdoVG9pck9nMTZLU0ZENDNNbDVSUGJI?= =?utf-8?B?eGQrRUtOUzFlbmVQUGY1cXNWM2pyelNMUmVpQVV1UDBjTElCUkNPeGVRMXlw?= =?utf-8?B?RlhyWW1DTjY5dzV5YTZHbHFPb1NuY3V2U3R2akx2VE1BQUZ2NTk1RXFBU3BW?= =?utf-8?B?cCtoTVRFM25Tazl3eTk0TDRzUWZ5MGNlNDBUdlNzYVB4S0tiOTN5bGkxNUpi?= =?utf-8?B?K2twM205TUFDcjkwRHJ3LzlWWWVHRHVRNWVQZ0NSdzhma3NoSFJaR0hSYzdL?= =?utf-8?B?eVhFY2JGWHhOQjJHYWpoK3FTVnBXZXRVWWs1UFJGWDdBT2VKYlVwOXBMK3Br?= =?utf-8?B?QS9UelQzd0tvTSsweDZadDlEaFlNN1ByUTBVbFdreVMwbkJWQ2tEZkRISzNU?= =?utf-8?B?Mm00aFRibU96TGk3UUhqdVJ6d2wxbTFJUWo1VTZ2Qkg0eXdFT3p5WWNZN1pt?= =?utf-8?Q?rsCZn97Hvig5t/agy8=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 4bf9642e-d105-4a37-b1c7-08d8e7b68368 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2021 13:30:34.5575 (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: va0AyF+G86unJ6dn9nPwAdLEMHwFQlW5zDEota+X3vyD1Olsm3IMoy/aVv+GMTwhufYRzY9EGXI0A7aBaPH+7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-15_05:2021-03-15, 2021-03-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 phishscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103150095 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, 15 Mar 2021 13:30:43 -0000 SSBhZ3JlZSB3aXRoIE1pY2hhZWwuICBUaGUgSURldklEIGluIG15IHBvaW50IG9mIHZpZXcgaXMg YXMgcGVybWFuZW50IGFzIHRoZSBzZXJpYWwgbnVtYmVyIG9uIHRoZSBib3ggb3IgdGhlIFZJTiBv biB5b3VyIGNhci4gIA0KSSB0aGluayBEZXZJRCBjb3VsZCBoYXZlIHByaXZhY3kgaW1wbGljYXRp b25zIGluIHNvbWUgYXBwbGljYXRpb25zLCBzbyB3aXRoaW4gVENHIHRoZXJlIGhhdmUgYmVlbiBw cm9wb3NhbHMgdG8gZG93bmxvYWQgdGhlIElEZXZJRCBhdCB0aGUgY3VzdG9tZXIncyBkaXNjcmV0 aW9uLCBidXQgaW4gdGhhdCBjYXNlLCBpdCB3b3VsZCBoYXZlIHRvIGJlIGxpbmtlZCB0byBUUE0n cyBFSyAoYW5vdGhlciBpbW11dGFibGUga2V5KSwgc28gdGhlcmUncyBzdGlsbCBvbmx5IG9uZSBw b3NzaWJsZSBJRGV2SUQgZXZlciBmb3IgYSBib3guDQogIEFzIG5vdGVkLCBMRGV2SURzIGNhbiBi ZSBtYWRlIGFuZCBkZXN0cm95ZWQgYXQgd2lsbC4NCi9ndXkNCg0KDQoNCkp1bmlwZXIgQnVzaW5l c3MgVXNlIE9ubHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJBVFMgPHJh dHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KU2Vu dDogU2F0dXJkYXksIE1hcmNoIDEzLCAyMDIxIDg6MzUgUE0NClRvOiBFbGlvdCBMZWFyIDxsZWFy PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPjsgcmF0c0BpZXRmLm9yZzsgaW90b3BzQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW1JhdHNdIFtJb3RvcHNdIDgwMi4xQVIgZGV2aWNlIGlkZW50aXR5 DQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQpFbGlvdCBM ZWFyIDxsZWFyPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCiAgICA+IFllYWgs IHRoaXMgaXMgYW4gaXNzdWUgdGhhdCBjb21lcyB1cCBmcm9tIHRpbWUgdG8gdGltZS4gIEhvdw0K ICAgID4g4oCcaW1tdXRhYmxl4oCdIHNob3VsZCB0aGF0IGlEZXZJRCBiZT8NCg0KSSB0YWtlIHRo ZSBhcHByb2FjaCB0aGF0IHRoZSBJRGV2SUQgdGhhdCB3YXMgc2hpcHBlZCBmcm9tIHRoZSBmYWN0 b3J5IGNhbiBub3QgYmUgcmVwbGFjZWQgd2l0aG91dCBhIGRldmljZSByZWNhbGwuDQoNCihJdCBj b3VsZCBiZSB0aGF0IHRoZXJlIGFyZSBtb2RlcyB3aGVyZSBhbm90aGVyIElEZXZJRCBjYW4gYmUg aW5zdGFsbGVkLCBidXQgdGhlIG9yaWdpbmFsIHdvdWxkIG5vdCBiZSByZW1vdmVkLiAgV2hldGhl ciB0aGlzIGlzIGFuIExEZXZJRCBvciBJRGV2SUQgaXMgb3BlbiB0byBpbnRlcHJldGF0aW9uKQ0K DQogICAgPiBJ4oCZdmUgaGFkIHRoaXMgdGhvdWdodCBpbiB0d28NCiAgICA+IGRpZmZlcmVudCBj b250ZXh0czogV2hhdCBpZiB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobSwgQ0EsIG9yIHByaXZhdGUg a2V5DQogICAgPiB1c2VkIHRvIHByb3RlY3QgdGhlIGlEZXZJRCBoYXMgYmVlbiBjb21wcm9taXNl ZD8NCg0KVGhlbiwgdGhlIGRldmljZSBpcyBicm9rZW4uDQpJIHRoaW5rIHlvdSB3b3VsZCBjZXJ0 YWlubHkgYWdyZWUgdGhhdCB0aGlzIGNhbiBiZSB0aGUgb25seSBhbnN3ZXIgaWYgdGhlIHNvZnR3 YXJlIHNpZ25pbmcga2V5IGlzIGNvbXByb21pc2VkLCByaWdodD8NCg0KICAgID4gQ2FuIG9uZSBy ZWNvdmVyIHdpdGggYW4gdXBkYXRlPw0KICAgID4gV2hhdCBpZiB0aGVyZSBhcmUgYXR0cmlidXRl cyBpbiB0aGUgY2VydCB0aGF0IEkgd2FudCB0bw0KICAgID4gZGluayBhbmQgc2hhcmUgd2l0aCB0 aGUgZGVwbG95bWVudD8NCg0KUGxlYXNlIGRlZmluZSAiZGluayIgZm9yIG1lLiAgSSBrbm93IG9m IG9ubHkgb25lIGRlZmluaXRpb24gZnJvbSB0aGUgc2Nob29sIHlhcmQuDQpEb2VzIHRoaXMgbWVh biByZW1vdmU/IHJlcGxhY2U/DQoNCiAgICA+IEnigJlkIGxpa2UgdG8gdGFrZSB0aGF0IGxhdHRl ciBjYXNlIG9mZiB0aGUgdGFibGUsIGJ1dCB0aGVuIHdlIG5lZWQgdG8NCiAgICA+IHNlcmlvdXNs eSB0aGluayBhYm91dCBSQVRTIG9yIFNVSVQgcHJvdmlkaW5nIGEgc3RhbmRhcmQgcHJvdGVjdGVk IFRMVg0KICAgID4gbGlzdCB0aGF0IGRlcGxveW1lbnRzIGNvdWxkIHJlY2VpdmUgdGhyb3VnaCBh IHN0YW5kYXJkIGludGVyZmFjZS4NCiAgICA+IFRoZXNlIGFyZSBhdHRlc3RhdGlvbnMgb2YgYSBm b3JtLCBidXQgdGhleeKAmXJlIG5vdCByZWFsbHkgbWVhc3VyZW1lbnRzLA0KICAgID4gYXMgaGFz IGJlZW4gcHJldmlvdXNseSBkaXNjdXNzZWQgaGVyZS4NCg0KQ2FuIHlvdSBnaXZlIG1lIGFuIGV4 YW1wbGUgb2Ygb25lIG9mIHRoZXNlIGF0dHJpYnV0ZXM/DQpUaGlzIHNvdW5kcyBsaWtlIHRoZSBG SURPIHNpdHVhdGlvbiwgZnJvbSBzZWN0aW9uIDYuMyBvZiAobXkpIHRoZSB1c2VjYXNlDQpkb2N1 bWVudDoNCg0KICAgQWNjb3JkaW5nIHRvIFtmaWRvdGVjaG5vdGVdIEZJRE8gdXNlcyBhdHRlc3Rh dGlvbiB0byBtYWtlIGNsYWltcw0KICAgYWJvdXQgdGhlIGtpbmQgb2YgZGV2aWNlIHdoaWNoIGlz IGJlIHVzZWQgdG8gZW5yb2xsLiAgS2V5cGFpcnMgYXJlDQogICBnZW5lcmF0ZWQgb24gYSBwZXIt ZGV2aWNlIF9tb2RlbF8gYmFzaXMsIHdpdGggYSBjZXJ0aWZpY2F0ZSBoYXZpbmcgYQ0KICAgdHJ1 c3QgY2hhaW4gdGhhdCBsZWFkcyBiYWNrIHRvIGEgd2VsbC1rbm93biByb290IGNlcnRpZmljYXRl LiAgSXQgaXMNCiAgIGV4cGVjdGVkIHRoYXQgYXMgbWFueSBhcyAxMDAsMDAwIGRldmljZXMgaW4g YSBwcm9kdWN0aW9uIHJ1biB3b3VsZA0KICAgaGF2ZSB0aGUgc2FtZSBwdWJsaWMgYW5kIHByaXZh dGUga2V5IHBhaXIuICBPbmUgYXNzdW1lcyB0aGF0IHRoaXMgaXMNCiAgIHN0b3JlZCBpbiBhIHRh bXBlci1wcm9vZiBUUE0gc28gaXQgaXMgcmVsYXRpdmVseSBkaWZmaWN1bHQgdG8gZ2V0DQogICB0 aGlzIGtleSBvdXQuICBUaGUgdXNlIG9mIHRoaXMga2V5IGF0dGVzdHMgdG8gdGhlIHRoZSBkZXZp Y2UgdHlwZSwNCiAgIGFuZCB0aGUga2luZCBvZiBwcm90ZWN0aW9ucyBmb3Iga2V5cyB0aGF0IHRo ZSByZWx5aW5nIHBhcnR5IG1heQ0KICAgYXNzdW1lLCBub3QgdG8gdGhlIGlkZW50aXR5IG9mIHRo ZSBlbmQgdXNlci4NCg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxt YW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQogICAgICAgICAgIFNhbmRl bG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQoNCg0KDQo= From nobody Mon Mar 15 08:01:39 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 2E2C03A1368; Mon, 15 Mar 2021 08:01:34 -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 8Uv3d4AzjbVZ; Mon, 15 Mar 2021 08:01:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5063D3A1365; Mon, 15 Mar 2021 08:01:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 38435389A5; Mon, 15 Mar 2021 11:06:52 -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 9rejm-ijLn8y; Mon, 15 Mar 2021 11:06:51 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A5393389A1; Mon, 15 Mar 2021 11:06:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CACD38F8; Mon, 15 Mar 2021 11:01:28 -0400 (EDT) From: Michael Richardson To: Guy Fedorkow , Eliot Lear , "rats\@ietf.org" , "iotops\@ietf.org" In-Reply-To: References: <22167.1615685681@localhost> 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: Mon, 15 Mar 2021 15:01:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 IDevID ev= er > for a box. As noted, LDevIDs can be made and destroyed at will. Perhaps you said it more precisely than I. The private key must be immutable and heavily protected (TPM or secure enclave, etc.). In draft-selander-ace-ake-authz-02 we describe a mechanism where the conten= ts of the IDevID are in fact downloaded by correspondants (Registrar) from the manufacturer, rather than being transmitted over a challenged network. I guess this would allow the manufacturer to resign in some ways, and maybe even present different certificates depending upon who is asking. But, the serial-number identity that the device has and the connection to the private key is immutable. BTW: in the above document we encrypt (with ECIES) the identity to the manufacturer. Eliot's concern about which network should a pledge try firs= t, given many choices, remains. =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+93Q3WUFAmBPdsgACgkQgItw+93Q 3WVvEQf+Pwlm8KqaQrWyRqI79j51epWrdmnZorEbfiB6ig3vvIS//G9lDgPQ/SDB AzgBnE+sr4ujtxgfdf2cHe2WN2HhVdq0/h2d3ECdpTAYPz9V4WHY15dwtt0/H1Fb KZp6K0CVoL5qIPIATUW3baGGhEHqWqHzNZUduJGGiIhP4xBaeVkcvJ8BcZcJoEmz Axq+oDAJf66Q3K0aZ7+rxG9eeRTtH3yprYP6eiREa5ZIYtNoOSWzwXtpp7gWrBS1 zf0oXAzrKYXCmjsJU4U4CWKOE2xwzDW7jztgHTRUuLu3esCBaUfOahhN7ADDvuf2 2San96VORP8LhA7ycUWQ9Z4TywEcGQ== =4r/G -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 20 13:52: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 588B43A2A54; Sat, 20 Mar 2021 13:52: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, 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 036FFC2HNAFe; Sat, 20 Mar 2021 13:52:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CE83A2A4F; Sat, 20 Mar 2021 13:52:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A89138997; Sat, 20 Mar 2021 16:58:09 -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 cx9CDc0jCZDt; Sat, 20 Mar 2021 16:58:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7CEB83897B; Sat, 20 Mar 2021 16:58:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D99EE335; Sat, 20 Mar 2021 16:52:25 -0400 (EDT) From: Michael Richardson To: Tianran Zhou , "rfc-ise\@rfc-editor.org" , "opsawg-chairs\@ietf.org" , "opsawg\@ietf.org" , iotops@ietf.org In-Reply-To: References: <240866a424caca4cf10e5df833533ffe.squirrel@www.rfc-editor.org> <2a12c6bcb4bbbde5e4f046a9763272be.squirrel@www.rfc-editor.org> <366a510ca7b4412892eac3c9dba81337@huawei.com> <20640.1615925798@localhost> 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] [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode] 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, 20 Mar 2021 20:52:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tianran Zhou wrote: > Now we have IOTOPS for more bandwidth to discussion on MUD. > I think it would be a good idea to collect more interest in IOTOPS, a= nd bring to OPSAWG. I'm rather mystified by the meaning of this statement. As WG chairs you are empowered to use your judgement, and you can run any process you like to decide whether to adopt work, including, I like to remind, doing it by fiat. The "two week adoption call" is just a common pr= ocess. So, clearly you are suggesting some other process. Perhaps you could explain to me what process you have envisioned here so th= at I can follow it? =2D-- To those in the WGs, perhaps you could read: https://datatracker.ietf.org/doc/draft-richardson-mud-qrcode/ Editorial changes most welcome at https://github.com/CIRALabs/securehomegat= eway-mud/tree/ietf I should note that there is almost no content in this document which the IE= TF will have change control on. (I say almost, because I could say none, but I might be wrong) This is an application of a Reverse Logistics Association profile of the MH10.8.2 Committee QR code control protocol to include an RFC8520 entry. =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+93Q3WUFAmBWYIkACgkQgItw+93Q 3WU/qAgAsbOFs9Bk03FzoTJDnIixnYDz7j2XoZ2QJItZ8E8VQbygvjtN48MBTb0E zbaG5jSGD7qgRug6J8BvVmj2DyDD6oYyeNsjO9LPFFifny0CYMLWrpQDyA5erShd QzQv8aiviOaLUB8adxPOgIhSncOLss32QF6zjxaK4zbje4n5CfmeuygJSy5tegx0 LZGcijuHTO2H7BefUoRENjXyKx2SOVcSHyWEDhJt7rrEvxWT6kxGZuQOIwR/yCIa mwAnKk3zsaPGC/Tsw/2cF9Sr72PBZOiNumeDMNIUHaFPRVv/LKItZB1CaqyuoYfu p3+4l1AC4BD4JxkuhKlMvwYb1DyT7w== =2Iyq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 21 17:56: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 ACF723A0E1F; Sun, 21 Mar 2021 17:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 uULCuE4eROK6; Sun, 21 Mar 2021 17:56:25 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4F13A0E27; Sun, 21 Mar 2021 17:56:24 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F3bW94KSTz67nG6; Mon, 22 Mar 2021 08:49:57 +0800 (CST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 22 Mar 2021 01:56:20 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 22 Mar 2021 08:56:18 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.2106.013; Mon, 22 Mar 2021 08:56:18 +0800 From: Tianran Zhou To: Michael Richardson , "rfc-ise@rfc-editor.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.org" , "iotops@ietf.org" Thread-Topic: [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode] Thread-Index: AQHXGYS//PV4bVoSJEmt7+jfnmRrpqqGLv7wgABaZgCAANpc4IAFePaAgAJZvsA= Date: Mon, 22 Mar 2021 00:56:18 +0000 Message-ID: References: <240866a424caca4cf10e5df833533ffe.squirrel@www.rfc-editor.org> <2a12c6bcb4bbbde5e4f046a9763272be.squirrel@www.rfc-editor.org> <366a510ca7b4412892eac3c9dba81337@huawei.com> <20640.1615925798@localhost> <13989.1616273545@localhost> In-Reply-To: <13989.1616273545@localhost> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Iotops] [OPSAWG] [Fwd: Your thoughts on draft-richardson-mud-qrcode] 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, 22 Mar 2021 00:56:30 -0000 SGkgTWljaGFlbCwNCg0KU29ycnkgZm9yIG5vdCBiZWluZyBjbGVhci4NCk15IHN0YXRlbWVudCBp cyBvbiB0aGUgZm9sbG93aW5nIGNvbnRleHQgZnJvbSB5b3VyIHByZXZpb3VzIG1haWwuDQoiSSBn b3QgdmVyeSBsaXR0bGUgaW50ZXJlc3QgYXQgYWxsLiINCkFuZA0KIkkgdGhpbmsgdGhhdCB0aGUg T1BTQVdHIGhhcyB2ZXJ5IGxpdHRsZSBhdmFpbGFibGUgYmFuZHdpZHRoIGZvciBNVUQgcmVsYXRl ZCB0aGluZ3MsIGFuZCB0aGUgbXVkLXFyY29kZSBkb2N1bWVudCBpcyBub3Qgd2hlcmUgSSB3b3Vs ZCB3YW50IHRvIHNwZW5kIHRoZSBsaW1pdGVkIGJhbmR3aWR0aCBvZiBPUFNBV0csIHNpbmNlIEkg dGhpbmsgdGhhdCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSBmb3IgdGhlIFdHIg0KDQpTbyBteSBwcmVs aW1pbmFyeSBzdWdnZXN0aW9uIGlzDQoiSSB0aGluayBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0 byBjb2xsZWN0IG1vcmUgaW50ZXJlc3QgaW4gSU9UT1BTLCBhbmQgYnJpbmcgdG8gT1BTQVdHLiIN Cg0KVGhlIGNoYWlycyB3aWxsIGRpc2N1c3MgbW9yZSBhYm91dCB0aGUgbmV4dC4NCg0KQ2hlZXJz LA0KVGlhbnJhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBS aWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhXSANClNlbnQ6IFN1bmRheSwg TWFyY2ggMjEsIDIwMjEgNDo1MiBBTQ0KVG86IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVh d2VpLmNvbT47IHJmYy1pc2VAcmZjLWVkaXRvci5vcmc7IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7 IG9wc2F3Z0BpZXRmLm9yZzsgaW90b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0FXR10g W0Z3ZDogWW91ciB0aG91Z2h0cyBvbiBkcmFmdC1yaWNoYXJkc29uLW11ZC1xcmNvZGVdDQoNCg0K VGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPiB3cm90ZToNCiAgICA+IE5vdyB3 ZSBoYXZlIElPVE9QUyBmb3IgbW9yZSBiYW5kd2lkdGggdG8gZGlzY3Vzc2lvbiBvbiBNVUQuDQog ICAgPiBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRvIGNvbGxlY3QgbW9yZSBpbnRl cmVzdCBpbiBJT1RPUFMsIGFuZCBicmluZyB0byBPUFNBV0cuDQoNCkknbSByYXRoZXIgbXlzdGlm aWVkIGJ5IHRoZSBtZWFuaW5nIG9mIHRoaXMgc3RhdGVtZW50Lg0KQXMgV0cgY2hhaXJzIHlvdSBh cmUgZW1wb3dlcmVkIHRvIHVzZSB5b3VyIGp1ZGdlbWVudCwgYW5kIHlvdSBjYW4gcnVuIGFueSBw cm9jZXNzIHlvdSBsaWtlIHRvIGRlY2lkZSB3aGV0aGVyIHRvIGFkb3B0IHdvcmssIGluY2x1ZGlu ZywgSSBsaWtlIHRvIHJlbWluZCwgZG9pbmcgaXQgYnkgZmlhdC4gIFRoZSAidHdvIHdlZWsgYWRv cHRpb24gY2FsbCIgaXMganVzdCBhIGNvbW1vbiBwcm9jZXNzLg0KDQpTbywgY2xlYXJseSB5b3Ug YXJlIHN1Z2dlc3Rpbmcgc29tZSBvdGhlciBwcm9jZXNzLg0KUGVyaGFwcyB5b3UgY291bGQgZXhw bGFpbiB0byBtZSB3aGF0IHByb2Nlc3MgeW91IGhhdmUgZW52aXNpb25lZCBoZXJlIHNvIHRoYXQg SSBjYW4gZm9sbG93IGl0Pw0KDQotLS0NCg0KVG8gdGhvc2UgaW4gdGhlIFdHcywgcGVyaGFwcyB5 b3UgY291bGQgcmVhZDoNCiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cmljaGFyZHNvbi1tdWQtcXJjb2RlLw0KDQpFZGl0b3JpYWwgY2hhbmdlcyBtb3N0IHdlbGNvbWUg YXQgaHR0cHM6Ly9naXRodWIuY29tL0NJUkFMYWJzL3NlY3VyZWhvbWVnYXRld2F5LW11ZC90cmVl L2lldGYNCg0KSSBzaG91bGQgbm90ZSB0aGF0IHRoZXJlIGlzIGFsbW9zdCBubyBjb250ZW50IGlu IHRoaXMgZG9jdW1lbnQgd2hpY2ggdGhlIElFVEYgd2lsbCBoYXZlIGNoYW5nZSBjb250cm9sIG9u LiAoSSBzYXkgYWxtb3N0LCBiZWNhdXNlIEkgY291bGQgc2F5IG5vbmUsIGJ1dCBJIG1pZ2h0IGJl IHdyb25nKQ0KDQpUaGlzIGlzIGFuIGFwcGxpY2F0aW9uIG9mIGEgUmV2ZXJzZSBMb2dpc3RpY3Mg QXNzb2NpYXRpb24gcHJvZmlsZSBvZiB0aGUNCk1IMTAuOC4yIENvbW1pdHRlZSBRUiBjb2RlIGNv bnRyb2wgcHJvdG9jb2wgdG8gaW5jbHVkZSBhbiBSRkM4NTIwIGVudHJ5Lg0KDQoNCi0tDQpNaWNo YWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4gICAuIG8gTyAoIElQdjYgScO4 VCBjb25zdWx0aW5nICkNCiAgICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywg T3R0YXdhIGFuZCBXb3JsZHdpZGUNCg0KDQoNCg0K From nobody Mon Mar 22 09:37:10 2021 Return-Path: X-Original-To: iotops@ietf.org Delivered-To: iotops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D13F83A0E61; Mon, 22 Mar 2021 09:36:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: iotops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161643101881.22832.2965645535514665337@ietfa.amsl.com> Date: Mon, 22 Mar 2021 09:36:58 -0700 Archived-At: Subject: [Iotops] IOT Operations (iotops) WG Virtual Meeting: 2021-04-20 X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 16:37:03 -0000 The IOT Operations (iotops) WG will hold a virtual interim meeting on 2021-04-20 from 15:00 to 17:00 UTC. Agenda: Will be updated/posted soon(tm). Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e From nobody Fri Mar 26 11:23:18 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 039DF3A24FF for ; Fri, 26 Mar 2021 11:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 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.001, RCVD_IN_MSPIKE_WL=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 LGAZMFfEemQX for ; Fri, 26 Mar 2021 11:23:12 -0700 (PDT) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (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 60B0B3A24FE for ; Fri, 26 Mar 2021 11:23:12 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Pr4qlubOY5NJSPr4rlgx9z; Fri, 26 Mar 2021 11:20:57 -0700 X-CMAE-Analysis: v=2.4 cv=bPLTnNyZ c=1 sm=1 tr=0 ts=605e2609 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=pGLkceISAAAA:8 a=dHJOhkScAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=Nb4w7BjiCnl53hLM2RMA:9 a=QEXdDO2ut3YA:10 a=cPy95GN0dDjb3_8kiSwA:9 a=p4qslzA6h5rM7i-0:21 a=_W_S_7VecoQA:10 a=0Jc9p3VZYLcdQ-t9l-12:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 a=RBBcRewTFc8P4JkPnay6:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_825BADA2-C9B0-4F32-AE1D-232D30789F4A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 26 Mar 2021 11:20:56 -0700 In-Reply-To: Cc: "rats@ietf.org" , "Smith, Ned" , Eliot Lear , Guy Fedorkow , "iotops@ietf.org" To: Ira McDonald 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> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfGUNqbI5T85vbrpgPyMYGGtrYBZZ0GQmnbJGtI9Lg3ECBx1oeUv/lznG78aN9KSCjI0EcPTOPOne/vVRRIklwgaBhAGYSfvytUWj/uHF5iHt4cgeJPm4 1BfgocDnRaAdQlAF9Mc1C/uUuKIHzhcsOPhS5RLpHh8hDfWYjxCDtfLdzC77DmJ6wEkmEf2oZ3TsG5sRY58WANIj6Z64400BuIeJcUtqN8tjSbc90aepsHVv fxHkEDMG7pPpRfdYcirOPSie3D8w1JWmOO3CUJjtTgvrgYTM74BVUVN9T7YABn4virfiiCaxFWzWpNu2ixBlRSMVI3RncfbUbNN/CTXUGRK/V4FiphPROLgB TBgqAjK6 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, 26 Mar 2021 18:23:17 -0000 --Apple-Mail=_825BADA2-C9B0-4F32-AE1D-232D30789F4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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,=20 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: >=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 > 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=_825BADA2-C9B0-4F32-AE1D-232D30789F4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=_825BADA2-C9B0-4F32-AE1D-232D30789F4A-- From nobody Tue Mar 30 04:14: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 6AACC3A0B5F; Tue, 30 Mar 2021 04:14:00 -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=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 yMHRD-bJNzLH; Tue, 30 Mar 2021 04:13:54 -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 85DA83A0B07; Tue, 30 Mar 2021 04:13:54 -0700 (PDT) Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (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 4F8mzM5Y8DzyVM; Tue, 30 Mar 2021 13:13:51 +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: <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> Date: Tue, 30 Mar 2021 13:13:51 +0200 Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , "iotops@ietf.org" , "draft-sarikaya-t2trg-sbootstrapping@ietf.org" X-Mao-Original-Outgoing-Id: 638795630.9399281-71df6642f8241bf184f6b943a9442cb7 Content-Transfer-Encoding: quoted-printable Message-Id: <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> References: <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Tue, 30 Mar 2021 11:14:04 -0000 On 2021-02-19, at 16:38, Eliot Lear wrote: >=20 > 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 plan = to adopt it as an RG document on April 6th. Gr=C3=BC=C3=9Fe, Carsten >=20 > Eliot >=20 >> On 19 Feb 2021, at 16:24, Ari Ker=C3=A4nen = wrote: >>=20 >> Hi IoTOPS folks, >>=20 >> At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been = updated: >> https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/ >>=20 >> The draft has been discussed and developed quite some time in the = T2TRG and we chairs think it's now getting close to ready for adoption. = We would like to hear views on this from the IoT operational community. = In particular we'd like to hear if the technologies considered important = for security setup and bootstrapping by this group are covered in the = document. >>=20 >>=20 >> Thanks, >> Ari & Carsten >>=20 >> -- >> Iotops mailing list >> Iotops@ietf.org >> https://www.ietf.org/mailman/listinfo/iotops From nobody Tue Mar 30 04:29:23 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 9511A3A0C9D; Tue, 30 Mar 2021 04:29:21 -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, 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=cascoda.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 ePevhJ-Em44q; Tue, 30 Mar 2021 04:29:16 -0700 (PDT) Received: from cs43706557.123-cloud-server.co.uk (cs43706557.123-cloud-server.co.uk [91.109.11.113]) (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 499583A0C9C; Tue, 30 Mar 2021 04:29:15 -0700 (PDT) Received: from [192.168.178.85] (unknown [93.92.10.229]) by cs43706557.123-cloud-server.co.uk (Postfix) with ESMTPSA id 5B9CE7C28A; Tue, 30 Mar 2021 12:29:10 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cascoda.com; s=default; t=1617103751; bh=rAFLSf/cLwrwwt//zjsC9SSPKVyWPa60f3baGZR+xzk=; h=Subject:To:From; b=HJK7Vkp0wtalv21giTWvtfxv7Vas4FJ11g8moTcseYRdViXD5/RujpcaMutOOzWSx Mnft+tJyG1Qfs4n3hIXPWUder4J2uj397JYQqURi++xc3/vIEcZQ0/mJut5MONsswM teabFjmKE/MNDNbDypvtwwfJ0LNyj8tFgkLzRdbQ= Authentication-Results: cs43706557; spf=pass (sender IP is 93.92.10.229) smtp.mailfrom=w.vanderbeek@cascoda.com smtp.helo=[192.168.178.85] Received-SPF: pass (cs43706557: connection is authenticated) To: Carsten Bormann , Eliot Lear Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "draft-sarikaya-t2trg-sbootstrapping@ietf.org" , "iotops@ietf.org" References: <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> From: Wouter van der Beek Message-ID: <7a8814c0-f6c0-8206-42af-8f23ec18c995@cascoda.com> Date: Tue, 30 Mar 2021 12:29:10 +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 In-Reply-To: <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> Content-Type: multipart/alternative; boundary="------------A5F4F0B1C4ED6E3A00FBAD1D" Content-Language: en-US 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: Tue, 30 Mar 2021 11:29:22 -0000 This is a multi-part message in MIME format. --------------A5F4F0B1C4ED6E3A00FBAD1D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi All, who wrote the OCF section? Kind Regards, Wouter On 30/03/2021 12:13, Carsten Bormann wrote: > On 2021-02-19, at 16:38, Eliot Lear wrote: >> Very well timed. I look forward to discussing this. > Thanks! > > Now would be a good time to get some initial feedback — we plan to adopt it as an RG document on April 6th. > > Grüße, Carsten > >> Eliot >> >>> On 19 Feb 2021, at 16:24, Ari Keränen wrote: >>> >>> Hi IoTOPS folks, >>> >>> At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been updated: >>> https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/ >>> >>> The draft has been discussed and developed quite some time in the T2TRG and we chairs think it's now getting close to ready for adoption. We would like to hear views on this from the IoT operational community. In particular we'd like to hear if the technologies considered important for security setup and bootstrapping by this group are covered in the document. >>> >>> >>> Thanks, >>> Ari & Carsten >>> >>> -- >>> Iotops mailing list >>> Iotops@ietf.org >>> https://www.ietf.org/mailman/listinfo/iotops -- Wouter van der Beek Principal Engineer Cascoda Ltd *Southampton Office:* *Taipei Office:*  Threefield House  Threefield Lane  Southampton  SO14 3LP  UK  Rm.918, 9F, No.96, Chia Hsin Bldg.  Sec.2, Zhongshan N.Rd.  Zhongshan Dist.  Taipei  Taiwan  Tel: +353 852448780 _ *Registered Office:* 12-14 Carlton Place, Southampton SO15 2EA, UK *Registered in England and Wales:* 6174299 *Confidentiality:* This e-mail transmission is strictly confidential and intended solely for the addressee. It may contain privileged and confidential information and if you are not the intended recipient, you must not copy or distribute it. If you have received this e-mail in error, please notify the sender and delete the e-mail transmission immediately. *Viruses:* Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. *Security Warning:* Please note that this e-mail has been created in the knowledge that internet e-mail is not a 100% secure communications medium. We advise that you understand this lack of security and take any necessary measures when e-mailing us. --------------A5F4F0B1C4ED6E3A00FBAD1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi All,

who wrote the OCF section?

Kind Regards,

Wouter

On 30/03/2021 12:13, Carsten Bormann wrote:
On 2021-02-19, at 16:38, Eliot Lear <lear@cisco.com> wrote:

Very well timed.  I look forward to discussing this.

Thanks!

Now would be a good time to get some initial feedback — we plan to adopt it as an RG document on April 6th.

Grüße, Carsten


Eliot


On 19 Feb 2021, at 16:24, Ari Keränen <ari.keranen=40ericsson.com@dmarc.ietf.org> wrote:

Hi IoTOPS folks,

At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been updated:
https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/

The draft has been discussed and developed quite some time in the T2TRG and we chairs think it's now getting close to ready for adoption. We would like to hear views on this from the IoT operational community. In particular we'd like to hear if the technologies considered important for security setup and bootstrapping by this group are covered in the document.


Thanks,
Ari & Carsten

--
Iotops mailing list
Iotops@ietf.org
https://www.ietf.org/mailman/listinfo/iotops


    

    
-- 

      

      Wouter van der Beek

      

      Principal Engineer

      Cascoda Ltd

      

      

        
          

            Southampton Office:
            Taipei Office:
          

          

              Threefield House

               Threefield Lane

               Southampton

               SO14 3LP

               UK

            		
              Rm.918, 9F, No.96, Chia Hsin Bldg.

               Sec.2, Zhongshan N.Rd.

               Zhongshan Dist.

               Taipei

               Taiwan

            		
          

          

             Tel: +353 852448780
             
          

        
      

      
 
          

        

      

        Registered Office: 12-14 Carlton Place, Southampton SO15
        2EA, UK 

        Registered in England and Wales: 6174299

        

        Confidentiality: This e-mail transmission is strictly
        confidential and intended solely for the addressee. It may
        contain privileged and confidential information and if you are
        not the intended recipient, you must not copy or distribute it.
        If you have received this e-mail in error, please notify the
        sender and delete the e-mail transmission immediately.

        Viruses: Although we have taken steps to ensure that this
        e-mail and attachments are free from any virus, we advise that
        in keeping with good computing practice the recipient should
        ensure they are actually virus free.

        Security Warning: Please note that this e-mail has been
        created in the knowledge that internet e-mail is not a 100%
        secure communications medium. We advise that you understand this
        lack of security and take any necessary measures when e-mailing
        us.

      

    

  


--------------A5F4F0B1C4ED6E3A00FBAD1D--


From nobody Tue Mar 30 04:39: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 2F87D3A0D03; Tue, 30 Mar 2021 04:39:11 -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=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 DMCIYzCL4Qhc; Tue, 30 Mar 2021 04:39:05 -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 4194A3A0CF4; Tue, 30 Mar 2021 04:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7611; q=dns/txt; s=iport; t=1617104345; x=1618313945; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=vsBs7FfNeii2tF2A4y7oKbU0IiOTcG14gESrrLy1xhE=; b=TfRDEY7yc7HneAeH6bYZqp2DHKcTMrL7cVFeN08BywQAeCjED4xE9lC5 e2rcigcTM8wWIqO6yPpHTC7aK/sT7IYIPWIui+qT1JyOcDg54kEk+QzhR G2z3z5MyxbV1zc6FQjXTEzJlS9dOgPBsLzilbM4TvNE3mBABYjM790LK9 w=;
X-Files: signature.asc : 488
X-IPAS-Result: =?us-ascii?q?A0AiAAA5DWNglxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBghCDIVYBJxIxhEGJBIhLA5RAiB8EBwEBAQoDAQEdAQwKBAEBh?= =?us-ascii?q?AxEAoF6JjgTAgMBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBhjYNhkQBA?= =?us-ascii?q?QEBAgEBARYLSwsFCwkCDgoqAgInMAYKCRQHglUBgmYhD48imwt3gTKEU0FEh?= =?us-ascii?q?F8KBoE5gVOFKgGGTEKCC4ESJxyCWT6CYAEBAgGEcTWCKwSDKgRDEFs/SUMFS?= =?us-ascii?q?Z0vix2RXYMRgzqBRIRdjFkIhioDH5QZkDigZ5IdLGMBg34CBAYFAhaBayGBW?= =?us-ascii?q?zMaCBsVOyoBgj4+EhkNjjiFVYMVhUc/Ay8CATUCBgEJAQEDCYkfAQE?=
IronPort-HdrOrdr: A9a23:jygBDK9WiB1LquNzHgBuk+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.81,290,1610409600";  d="asc'?scan'208,217";a="34614623"
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; 30 Mar 2021 11:39:03 +0000
Received: from [10.61.144.98] ([10.61.144.98]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 12UBd1CF028760 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Mar 2021 11:39:02 GMT
From: Eliot Lear 
Message-Id: <7DA8C071-8BE1-4CF5-A712-508DA7EA445B@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6F91C181-B9E7-476F-8228-70CA5B1C0320"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 30 Mar 2021 13:39:01 +0200
In-Reply-To: <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org>
Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= ,  "iotops@ietf.org" , "draft-sarikaya-t2trg-sbootstrapping@ietf.org" ,  Susan F Symington 
To: Carsten Bormann 
References:  <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Outbound-SMTP-Client: 10.61.144.98, [10.61.144.98]
X-Outbound-Node: aer-core-2.cisco.com
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: Tue, 30 Mar 2021 11:39:11 -0000

--Apple-Mail=_6F91C181-B9E7-476F-8228-70CA5B1C0320
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7DA5FA48-ECB4-49DE-8939-7AA4B5ABA7E3"


--Apple-Mail=_7DA5FA48-ECB4-49DE-8939-7AA4B5ABA7E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Carsten,

It would be good if the draft incorporated the comparison chart that we =
developed in our side meetings.  For one thing, there are several key =
distinctions for comparison:

Network versus Application onboarding
Many of the mechanisms assume network access prior to onboarding.  =
That=E2=80=99s not good over any wireless method.
Zero-touch versus one-touch deployment
Ownership transfer versus proof of knowledge
First use versus subsequent uses

There are other aspects.

Also, NIST has done a lot of work in this space as of late.  Have a look =
at this:

=
https://www.nccoe.nist.gov/projects/building-blocks/iot-network-layer-onbo=
arding =


Susan Symington (CC=E2=80=99d) is the primary author and has done great =
work in this space.  It may make sense to use that taxonomy and apply it =
to the various solutions.

Eliot

> On 30 Mar 2021, at 13:13, Carsten Bormann  wrote:
>=20
> On 2021-02-19, at 16:38, Eliot Lear  wrote:
>>=20
>> Very well timed.  I look forward to discussing this.
>=20
> Thanks!
>=20
> 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.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>>=20
>> Eliot
>>=20
>>> On 19 Feb 2021, at 16:24, Ari Ker=C3=A4nen =
 wrote:
>>>=20
>>> Hi IoTOPS folks,
>>>=20
>>> At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been =
updated:
>>> =
https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/
>>>=20
>>> The draft has been discussed and developed quite some time in the =
T2TRG and we chairs think it's now getting close to ready for adoption. =
We would like to hear views on this from the IoT operational community. =
In particular we'd like to hear if the technologies considered important =
for security setup and bootstrapping by this group are covered in the =
document.
>>>=20
>>>=20
>>> Thanks,
>>> Ari & Carsten
>>>=20
>>> --
>>> Iotops mailing list
>>> Iotops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/iotops
>=20


--Apple-Mail=_7DA5FA48-ECB4-49DE-8939-7AA4B5ABA7E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Carsten,

It=
 would be good if the draft incorporated the comparison chart that we =
developed in our side meetings.  For one thing, there are several =
key distinctions for comparison:

  • Network versus Application onboarding
    • Many of the mechanisms assume network access prior to =
onboarding.  That=E2=80=99s not good over any wireless =
method.
  • Zero-touch versus one-touch =
deployment
  • Ownership transfer versus proof of =
knowledge
  • First use versus subsequent =
uses

There =
are other aspects.

Also, NIST has done a lot of work in this space as of late. =
 Have a look at this:

https://www.nccoe.nist.gov/projects/building-blocks/iot-network=
-layer-onboarding

Susan Symington (CC=E2=80=99d) is the primary author and has =
done great work in this space.  It may make sense to use that =
taxonomy and apply it to the various solutions.

Eliot

On 30 =
Mar 2021, at 13:13, Carsten Bormann <cabo@tzi.org> wrote:

On =
2021-02-19, at 16:38, Eliot Lear <lear@cisco.com> 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 plan to adopt it as an RG =
document on April 6th.

Gr=C3=BC=C3=9Fe, =
Carsten


Eliot

On 19 Feb 2021, at 16:24, Ari Ker=C3=A4nen =
<ari.keranen=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi IoTOPS folks,

At=
 T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been =
updated:
https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstra=
pping/

The draft has been discussed and =
developed quite some time in the T2TRG and we chairs think it's now =
getting close to ready for adoption. We would like to hear views on this =
from the IoT operational community. In particular we'd like to hear if =
the technologies considered important for security setup and =
bootstrapping by this group are covered in the document.

Thanks,
Ari & Carsten

--
Iotops mailing list
Iotops@ietf.org
https://www.ietf.org/mailman/listinfo/iotops


=

--Apple-Mail=_7DA5FA48-ECB4-49DE-8939-7AA4B5ABA7E3--

--Apple-Mail=_6F91C181-B9E7-476F-8228-70CA5B1C0320
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-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBjDdUACgkQh7ZrRtnS
ejN3+QgArD2IMUKIXbBzcamzuFkGbWAwrp5RdgNJUYFSz0wKH5KZjQoVJQRG6CN5
4fEVAC47aiqzd9dr36/6qOFKMD44eHFKPoHdDY2gtiHUpN9VjkCtipkypBLBQHTH
JDgafdnTMxWU6+krUT51QVuwud8wAoVzsC6T2NV+2maigFu/UsIRhK+0JILzLc65
a7jIRcpwsPepw8LHzG8wF4RLpkvDo+IXckt3ccYdPJwenXh1QUJ6q5cCOBjqH+Ih
FfXlpiqfzJ917z9Vq4354Hl0b0dF+H9wYTaIVWR4Bis5xuiG/E79LgQSIZ4dTzZY
LT6YBWrlqm/CrrDOkPW0xjJrIIqJ6w==
=z1lo
-----END PGP SIGNATURE-----

--Apple-Mail=_6F91C181-B9E7-476F-8228-70CA5B1C0320--


From nobody Tue Mar 30 08:12:43 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 076B63A180B; Tue, 30 Mar 2021 08:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=gmail.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 PTtlY4TV8Lqn; Tue, 30 Mar 2021 08:12:30 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 2566E3A1835; Tue, 30 Mar 2021 08:12:26 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id o66so17759130ybg.10; Tue, 30 Mar 2021 08:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=L78CGIkkyZ8m1y7eKc1MdCM7e20LivbzaHeS/H9zrhA=; b=n2kiW9R9cO/i4il4DZaF3iAOBg1OMXmz65SBxVWlySVhKhl8lD1yuTKuTmIykrZ6ND MD0sw93qiJw/PiQTlpV8m1NFIMPDjbCxH3ob0+GH0iLjcuPiaJJmtarJmuCzoBclzxTo oke0bsWX9wWI3VCMRciuBGTkjj2mpHlF0jFs2WgNlqEL/oSItPu0E+DGmeWFhrsGVsir QizSVNn4iKkE/IMBwHPpThtjTLevyRb8Gqo8aruFpGkYZTztUaCemFsFb65HK31l/4OX q+VzHAGuXgZNRLzmIVSb7rd8pqAN3cRttIXceVDcQcfqHoq+Zs5ekM7Rx9pSNgiSbJ5H Y8JQ==
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:reply-to :from:date:message-id:subject:to:cc; bh=L78CGIkkyZ8m1y7eKc1MdCM7e20LivbzaHeS/H9zrhA=; b=O7ZyYgpIX8B+tTa3uuD9Hpk406m6k5NiTFIDhclqpZKzkHVb0ZlOmmulBT/Y80dSKU 47pi1UgBdYwSFH0xI4j2p1BOH5mP6SZxDSCRTUrIswYi6pfBtjs1xlGgZpZdK61P5xpx D2YS6HVtL5b+Azse5ZzRNi/SGlr/QVxA4eaoy2d0bIUKUA0TRZecNJD5QSsbYm63KSwx w/xSbl9918+1tDNsWo9Vv6dJ87TiuqF2fhhvjAF9um1V7d1sDb4bkM5uq2A0ZG+jZu0a sxgF13mQpBxGP+HEtqm5Ad14lG8ToD/2QSolJ56dmYrdSborqVhnhmyEEyS4WG/cLjqW L1vw==
X-Gm-Message-State: AOAM532h6+EMfM7RwbdBCGn6r6Ew7H6RzUzICf9cLbmFwzSl9Yd5Vfs9 96JTw5IJyYBDF34GrUsQPSDCubdv0rSbKHnwZNs=
X-Google-Smtp-Source: ABdhPJys7jSxU9hVSTXK84WwIdGngdmRCP84eAKdVuxV44Hfze1kgsfwl75RuQJvn/h7BvJRQLZlacx+QeI05Yg/O+U=
X-Received: by 2002:a5b:787:: with SMTP id b7mr46376921ybq.243.1617117145088;  Tue, 30 Mar 2021 08:12:25 -0700 (PDT)
MIME-Version: 1.0
References:  <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> <7a8814c0-f6c0-8206-42af-8f23ec18c995@cascoda.com>
In-Reply-To: <7a8814c0-f6c0-8206-42af-8f23ec18c995@cascoda.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya 
Date: Tue, 30 Mar 2021 10:12:14 -0500
Message-ID: 
To: Wouter van der Beek 
Cc: Carsten Bormann , Eliot Lear ,  =?UTF-8?B?QXJpIEtlcsOkbmVu?= ,  "draft-sarikaya-t2trg-sbootstrapping@ietf.org" ,  "iotops@ietf.org" , "t2trg@irtf.org" 
Content-Type: multipart/alternative; boundary="000000000000fe480005bec26c89"
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: Tue, 30 Mar 2021 15:12:41 -0000

--000000000000fe480005bec26c89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 30, 2021 at 6:29 AM Wouter van der Beek <
w.vanderbeek@cascoda.com> wrote:

> Hi All,
>
> who wrote the OCF section?
>

It was introduced in Rev. 08.
I think Mohit wrote it.
Why did you ask?

Behcet

> Kind Regards,
>
> Wouter
> On 30/03/2021 12:13, Carsten Bormann wrote:
>
> On 2021-02-19, at 16:38, Eliot Lear   wro=
te:
>
> 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 plan t=
o adopt it as an RG document on April 6th.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
> Eliot
>
>
> On 19 Feb 2021, at 16:24, Ari Ker=C3=A4nen   wrote:
>
> Hi IoTOPS folks,
>
> At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been updated:=
https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/
>
> The draft has been discussed and developed quite some time in the T2TRG a=
nd we chairs think it's now getting close to ready for adoption. We would l=
ike to hear views on this from the IoT operational community. In particular=
 we'd like to hear if the technologies considered important for security se=
tup and bootstrapping by this group are covered in the document.
>
>
> Thanks,
> Ari & Carsten
>
> --
> Iotops mailing listIotops@ietf.orghttps://www.ietf.org/mailman/listinfo/i=
otops
>
> --
>
> Wouter van der Beek
>
> Principal Engineer
> Cascoda Ltd
>
> *Southampton Office:* *Taipei Office:*
>  Threefield House
>  Threefield Lane
>  Southampton
>  SO14 3LP
>  UK
>  Rm.918, 9F, No.96, Chia Hsin Bldg.
>  Sec.2, Zhongshan N.Rd.
>  Zhongshan Dist.
>  Taipei
>  Taiwan
>  Tel: +353 852448780
>
>  
> 
> 
>
> *Registered Office:* 12-14 Carlton Place, Southampton SO15 2EA, UK
> *Registered in England and Wales:* 6174299
>
> *Confidentiality:* This e-mail transmission is strictly confidential and
> intended solely for the addressee. It may contain privileged and
> confidential information and if you are not the intended recipient, you
> must not copy or distribute it. If you have received this e-mail in error=
,
> please notify the sender and delete the e-mail transmission immediately.
> *Viruses:* Although we have taken steps to ensure that this e-mail and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus fr=
ee.
> *Security Warning:* Please note that this e-mail has been created in the
> knowledge that internet e-mail is not a 100% secure communications medium=
.
> We advise that you understand this lack of security and take any necessar=
y
> measures when e-mailing us.
>

--000000000000fe480005bec26c89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Mar 30, 2021 at 6:29 AM Woute=
r van der Beek <w.vanderbeek=
@cascoda.com> wrote:

 =20
   =20
 =20
  

    
Hi All,

    
who wrote the OCF section? 

It was introduced in Rev. 08.
I think Mohit wrote it.
=

Why did you ask?

Behcet=C2=A0

    

    
Kind Regards,

    
Wouter

    

    
On 30/03/2021 12:13, Carsten Bormann
      wrote:

    

    

      
On 2021-02-19, at 16:38, Eliot Lear <lear@cisco.com> 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 plan to =
adopt it as an RG document on April 6th.

Gr=C3=BC=C3=9Fe, Carsten



      

        
Eliot



        

          
On 19 Feb 2021, at 16:24, Ari Ker=C3=A4nen <ari.ker=
anen=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi IoTOPS folks,

At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been =
updated:
https://datatracker.ietf.org/doc/draft-sarikaya-t2=
trg-sbootstrapping/

The draft has been discussed and developed quite some time in the T2TRG and=
 we chairs think it's now getting close to ready for adoption. We would=
 like to hear views on this from the IoT operational community. In particul=
ar we'd like to hear if the technologies considered important for secur=
ity setup and bootstrapping by this group are covered in the document.


Thanks,
Ari & Carsten

--
Iotops mailing list
Iotops@ietf.org
=
https://www.ietf.org/mailman/listinfo/iotops


        

      

      

    

    
-- 

      

      Wouter van der Beek

      

      Principal Engineer

      Cascoda Ltd

      

      

        
          

            Southampton Office:
            Taipei Office:
          

          

             =C2=A0Threefield House

              =C2=A0Threefield Lane

              =C2=A0Southampton

              =C2=A0SO14 3LP

              =C2=A0UK

            		
             =C2=A0Rm.918, 9F, No.96, Chia Hsin Bldg.

              =C2=A0Sec.2, Zhongshan N.Rd.

              =C2=A0Zhongshan Dist.

              =C2=A0Taipei

              =C2=A0Taiwan

            		
          

          

            =C2=A0Tel: +353 852448780
            =C2=A0
          

        
      

      
 
          

        

      

        Registered Office: 12-14 Carlton Place, Southampton SO15
        2EA, UK 

        Registered in England and Wales: 6174299

        

        Confidentiality: This e-mail transmission is strictly
        confidential and intended solely for the addressee. It may
        contain privileged and confidential information and if you are
        not the intended recipient, you must not copy or distribute it.
        If you have received this e-mail in error, please notify the
        sender and delete the e-mail transmission immediately.

        Viruses: Although we have taken steps to ensure that this
        e-mail and attachments are free from any virus, we advise that
        in keeping with good computing practice the recipient should
        ensure they are actually virus free.

        Security Warning: Please note that this e-mail has been
        created in the knowledge that internet e-mail is not a 100%
        secure communications medium. We advise that you understand this
        lack of security and take any necessary measures when e-mailing
        us.

      

    

  





--000000000000fe480005bec26c89--


From nobody Tue Mar 30 08:21:52 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 CA16A3A1841; Tue, 30 Mar 2021 08:21:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=cascoda.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 xVo6ugwbJ1h9; Tue, 30 Mar 2021 08:21:44 -0700 (PDT)
Received: from cs43706557.123-cloud-server.co.uk (cs43706557.123-cloud-server.co.uk [91.109.11.113]) (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 4F1253A1840; Tue, 30 Mar 2021 08:21:43 -0700 (PDT)
Received: from [192.168.178.85] (unknown [93.92.10.229]) by cs43706557.123-cloud-server.co.uk (Postfix) with ESMTPSA id 324307C28A; Tue, 30 Mar 2021 16:21:38 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cascoda.com; s=default; t=1617117699; bh=UXn3kqG1rJxeL7zXyHukPFQIgcxQIbnpkUmeK+ftPQ8=; h=Subject:To:From; b=XHg3z+A988qIsLXGqH+UQYGIIB1DYzvrYxR6ilObc1iuI6Ps93BUij6V5NJ7IngKF rtI4DTPAbdXNMDidWWoATAVSFqf4wX4Gg2+k7C/PY2FPdvCApmtifsVJmRgN7DxU7d KFQ9b4aDTcPGj2mNe2n/gYUi9B1I8b0VqzJV1YwE=
Authentication-Results: cs43706557; spf=pass (sender IP is 93.92.10.229) smtp.mailfrom=w.vanderbeek@cascoda.com smtp.helo=[192.168.178.85]
Received-SPF: pass (cs43706557: connection is authenticated)
To: sarikaya@ieee.org
Cc: Carsten Bormann , Eliot Lear , =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "draft-sarikaya-t2trg-sbootstrapping@ietf.org" , "iotops@ietf.org" , "t2trg@irtf.org" 
References:  <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> <7a8814c0-f6c0-8206-42af-8f23ec18c995@cascoda.com> 
From: Wouter van der Beek 
Message-ID: 
Date: Tue, 30 Mar 2021 16:21:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B34D2DBED1F030F962B4A107"
Content-Language: en-US
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: Tue, 30 Mar 2021 15:21:50 -0000

This is a multi-part message in MIME format.
--------------B34D2DBED1F030F962B4A107
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Frankly, as author I would have reached out to OCF.

I never saw a request in OCF for a review of this text.

for starters current version of specs of OCF is v2.2.2 version 1.0 is a 
long long time ago.

one can also reference the ISO/IEC version 
(https://www.iso.org/standard/74239.html ) that is also way better than 
the v1.0.0 version referenced.


Also the Fairhair spec is not listed in this draft RFC. This document is 
regarded in the building industry as a guiding document.

https://openconnectivity.org/wp-content/uploads/2019/11/fairhair-specification-version-10_approved_april-2019.pdf

Kind Regard,

Wouter


On 30/03/2021 16:12, Behcet Sarikaya wrote:
>
>
> On Tue, Mar 30, 2021 at 6:29 AM Wouter van der Beek 
> > wrote:
>
>     Hi All,
>
>     who wrote the OCF section?
>
>
> It was introduced in Rev. 08.
> I think Mohit wrote it.
> Why did you ask?
>
> Behcet
>
>     Kind Regards,
>
>     Wouter
>
>     On 30/03/2021 12:13, Carsten Bormann wrote:
>>     On 2021-02-19, at 16:38, Eliot Lear    wrote:
>>>     Very well timed.  I look forward to discussing this.
>>     Thanks!
>>
>>     Now would be a good time to get some initial feedback — we plan to adopt it as an RG document on April 6th.
>>
>>     Grüße, Carsten
>>
>>>     Eliot
>>>
>>>>     On 19 Feb 2021, at 16:24, Ari Keränen    wrote:
>>>>
>>>>     Hi IoTOPS folks,
>>>>
>>>>     At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been updated:
>>>>     https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/  
>>>>
>>>>     The draft has been discussed and developed quite some time in the T2TRG and we chairs think it's now getting close to ready for adoption. We would like to hear views on this from the IoT operational community. In particular we'd like to hear if the technologies considered important for security setup and bootstrapping by this group are covered in the document.
>>>>
>>>>
>>>>     Thanks,
>>>>     Ari & Carsten
>>>>
>>>>     --
>>>>     Iotops mailing list
>>>>     Iotops@ietf.org  
>>>>     https://www.ietf.org/mailman/listinfo/iotops  
>     -- 
>
>     Wouter van der Beek
>
>     Principal Engineer
>     Cascoda Ltd
>
>     *Southampton Office:* 	*Taipei Office:*
>      Threefield House
>      Threefield Lane
>      Southampton
>      SO14 3LP
>      UK
>     	 Rm.918, 9F, No.96, Chia Hsin Bldg.
>      Sec.2, Zhongshan N.Rd.
>      Zhongshan Dist.
>      Taipei
>      Taiwan
>      Tel: +353 852448780 	
>
>     _
>
>     *Registered Office:* 12-14 Carlton Place, Southampton SO15 2EA, UK
>     *Registered in England and Wales:* 6174299
>
>     *Confidentiality:* This e-mail transmission is strictly
>     confidential and intended solely for the addressee. It may contain
>     privileged and confidential information and if you are not the
>     intended recipient, you must not copy or distribute it. If you
>     have received this e-mail in error, please notify the sender and
>     delete the e-mail transmission immediately.
>     *Viruses:* Although we have taken steps to ensure that this e-mail
>     and attachments are free from any virus, we advise that in keeping
>     with good computing practice the recipient should ensure they are
>     actually virus free.
>     *Security Warning:* Please note that this e-mail has been created
>     in the knowledge that internet e-mail is not a 100% secure
>     communications medium. We advise that you understand this lack of
>     security and take any necessary measures when e-mailing us.
>
-- 

Wouter van der Beek

Principal Engineer
Cascoda Ltd

*Southampton Office:* 	*Taipei Office:*
  Threefield House
  Threefield Lane
  Southampton
  SO14 3LP
  UK
	 Rm.918, 9F, No.96, Chia Hsin Bldg.
  Sec.2, Zhongshan N.Rd.
  Zhongshan Dist.
  Taipei
  Taiwan
  Tel: +353 852448780 	

_

*Registered Office:* 12-14 Carlton Place, Southampton SO15 2EA, UK
*Registered in England and Wales:* 6174299

*Confidentiality:* This e-mail transmission is strictly confidential and 
intended solely for the addressee. It may contain privileged and 
confidential information and if you are not the intended recipient, you 
must not copy or distribute it. If you have received this e-mail in 
error, please notify the sender and delete the e-mail transmission 
immediately.
*Viruses:* Although we have taken steps to ensure that this e-mail and 
attachments are free from any virus, we advise that in keeping with good 
computing practice the recipient should ensure they are actually virus free.
*Security Warning:* Please note that this e-mail has been created in the 
knowledge that internet e-mail is not a 100% secure communications 
medium. We advise that you understand this lack of security and take any 
necessary measures when e-mailing us.


--------------B34D2DBED1F030F962B4A107
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Frankly, as author I would have reached out to OCF.

    
I never saw a request in OCF for a review of this text.

    

    
for starters current version of specs of OCF is v2.2.2 version
      1.0 is a long long time ago.

    
one can also reference the ISO/IEC version
      (https://www.iso.org/standard/74239.html ) that is also way better
      than the v1.0.0 version referenced.

    


    

    
Also the Fairhair spec is not listed in this draft RFC. This
      document is regarded in the building industry as a guiding
      document.

    

    
https://openconnectivity.org/wp-content/uploads/2019/11/fairhair-specification-version-10_approved_april-2019.pdf

    

    
Kind Regard,

    
Wouter

    

    


    

    
On 30/03/2021 16:12, Behcet Sarikaya
      wrote:

    

    

      
      

        


        

        

        

          
On Tue, Mar 30, 2021 at 6:29
            AM Wouter van der Beek <w.vanderbeek@cascoda.com>
            wrote:

          

          

            

              
Hi All,

              
who wrote the OCF section? 

              

            

          

          


          

          
It was introduced in Rev. 08.

          
I think Mohit wrote it.

          
Why did you ask?

          


          

          
Behcet 

          

            

              
 

              
Kind Regards,

              
Wouter

              

              
On 30/03/2021 12:13, Carsten Bormann wrote:

              

              

                
On 2021-02-19, at 16:38, Eliot Lear <lear@cisco.com> wrote:


                

                  
Very well timed.  I look forward to discussing this.


                

                
Thanks!

Now would be a good time to get some initial feedback — we plan to adopt it as an RG document on April 6th.

Grüße, Carsten



                

                  
Eliot



                  

                    
On 19 Feb 2021, at 16:24, Ari Keränen <ari.keranen=40ericsson.com@dmarc.ietf.org> wrote:

Hi IoTOPS folks,

At T2TRG the "Secure IoT Bootstrapping: A Survey" draft has been updated:
https://datatracker.ietf.org/doc/draft-sarikaya-t2trg-sbootstrapping/

The draft has been discussed and developed quite some time in the T2TRG and we chairs think it's now getting close to ready for adoption. We would like to hear views on this from the IoT operational community. In particular we'd like to hear if the technologies considered important for security setup and bootstrapping by this group are covered in the document.


Thanks,
Ari & Carsten

--
Iotops mailing list
Iotops@ietf.org
https://www.ietf.org/mailman/listinfo/iotops


                  

                

              

              
-- 

                

                Wouter van der Beek

                

                Principal Engineer

                Cascoda Ltd

                

                

                  
                    

                      Southampton Office:
                      Taipei Office:
                    

                    

                        Threefield House

                         Threefield Lane

                         Southampton

                         SO14 3LP

                         UK

                      		
                        Rm.918, 9F, No.96, Chia Hsin
                        Bldg.

                         Sec.2, Zhongshan N.Rd.

                         Zhongshan Dist.

                         Taipei

                         Taiwan

                      		
                    

                    

                       Tel: +353 852448780
                       
                    

                  
                

                
  

                  

                
 Registered Office:
                  12-14 Carlton Place, Southampton SO15 2EA, UK 

                  Registered in England and Wales: 6174299

                  

                  Confidentiality: This e-mail transmission is
                  strictly confidential and intended solely for the
                  addressee. It may contain privileged and confidential
                  information and if you are not the intended recipient,
                  you must not copy or distribute it. If you have
                  received this e-mail in error, please notify the
                  sender and delete the e-mail transmission immediately.

                  Viruses: Although we have taken steps to ensure
                  that this e-mail and attachments are free from any
                  virus, we advise that in keeping with good computing
                  practice the recipient should ensure they are actually
                  virus free.

                  Security Warning: Please note that this e-mail
                  has been created in the knowledge that internet e-mail
                  is not a 100% secure communications medium. We advise
                  that you understand this lack of security and take any
                  necessary measures when e-mailing us.

                

              

            

          

        

      

    

    
-- 

      

      Wouter van der Beek

      

      Principal Engineer

      Cascoda Ltd

      

      

        
          

            Southampton Office:
            Taipei Office:
          

          

              Threefield House

               Threefield Lane

               Southampton

               SO14 3LP

               UK

            		
              Rm.918, 9F, No.96, Chia Hsin Bldg.

               Sec.2, Zhongshan N.Rd.

               Zhongshan Dist.

               Taipei

               Taiwan

            		
          

          

             Tel: +353 852448780
             
          

        
      

      
 
          

        

      

        Registered Office: 12-14 Carlton Place, Southampton SO15
        2EA, UK 

        Registered in England and Wales: 6174299

        

        Confidentiality: This e-mail transmission is strictly
        confidential and intended solely for the addressee. It may
        contain privileged and confidential information and if you are
        not the intended recipient, you must not copy or distribute it.
        If you have received this e-mail in error, please notify the
        sender and delete the e-mail transmission immediately.

        Viruses: Although we have taken steps to ensure that this
        e-mail and attachments are free from any virus, we advise that
        in keeping with good computing practice the recipient should
        ensure they are actually virus free.

        Security Warning: Please note that this e-mail has been
        created in the knowledge that internet e-mail is not a 100%
        secure communications medium. We advise that you understand this
        lack of security and take any necessary measures when e-mailing
        us.

      

    

  


--------------B34D2DBED1F030F962B4A107--


From nobody Tue Mar 30 11:39:41 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 CCBC93A1DF9; Tue, 30 Mar 2021 11:39:39 -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 UJ4sqfeoGwSi; Tue, 30 Mar 2021 11:39:35 -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 473583A1DF1; Tue, 30 Mar 2021 11:39:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CCBB238E52; Tue, 30 Mar 2021 14:45:31 -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 rMlUCSAxBxm3; Tue, 30 Mar 2021 14:45:31 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29E9538E51; Tue, 30 Mar 2021 14:45:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 345A0150; Tue, 30 Mar 2021 14:39:11 -0400 (EDT)
From: Michael Richardson 
To: Carsten Bormann , Eliot Lear , =?us-ascii?Q?=3D=3Futf-8=3FQ=3FAri=5FKer=3DC3=3DA4nen=3F=3D?= ,  "draft-sarikaya-t2trg-sbootstrapping\@ietf.org" ,  "iotops\@ietf.org" 
In-Reply-To: <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org>
References:  <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org>
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] 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: Tue, 30 Mar 2021 18:39:40 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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.

=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+93Q3WUFAmBjcE4ACgkQgItw+93Q
3WUqDwgAg6CmsUa7P3z13bMC3vLyW+i3b1LJVD9OIWGGkjq6cniCzP9ghuJdbNnn
Wp3MLt65h4nUAoKoitF8ZEEubp21L3VU2l+UZgi1fdOCGTnAn1WuVEzKNU1z46C3
51ThhghtFfro9NMgAJmG89jSr4e4iyJZ4HOMbJ+Veks9vOcNLYmHbtyokAI/TjlL
VKMUxs0atdP+v4THrZzrgVNKofXG979nVwEv6DwgSXgIsaBOLQ2kCSOkyY2QdCKk
ZiaVgvfRhNVUDDgIL5jAurvARsEDZUuczJpVhIekNae2avZlQSug/8kIz+PNIYql
ebNoukTpcdvEwkEK0wUey2Q0bq8+xQ==
=TeRj
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Mar 30 12:51: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 74D853A200B for ; Tue, 30 Mar 2021 12:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTPTeF-OTTkD for ; Tue, 30 Mar 2021 12:51:43 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00067.outbound.protection.outlook.com [40.107.0.67]) (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 95A9B3A2004 for ; Tue, 30 Mar 2021 12:51:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EtkACK63B+Gz8gL/HgDIxUWqoEpjsYDSaAEvRw0RzV10F+rCvea/6HpWamLdPK6s85GPNufeRoIOivwhNEmQ7FtCaivd6DPwMTUmYOkKNxBwRos4nPgCPsjafpSEZ7lhf/xXG6O5hKixXtW98BxufM5almMtlisC50WIdiGktofKF83vvjpvYT5i4582NOqjALgcaaaVomUdyZas5zz3L2ukmqvQBSpOYFSSoVs9QKCTsGeijkd1IJHDt6aIJfdr1MQVcCBKKAZ/oQ4R7yg+0Ly0DM4ho0OtOuQ/+AM1mTRtX36UzXLj2EUrK2pZft6V8dnt0auXQ4PDVnFW+c801w==
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=2zbkn8Oq3RLW3xO/3EvctSMarYocO2riEQ0ICV2e6Cg=; b=XjEShGBCkZwg7/gGXSVcKYkYo95X9/Mnk4XTPvJij8QLYmtbrFawZdsNVlcTBuyFqZhL72kmpE57vebC5lsy78RqevGYkDs+l2OEdEIy5SceThBS81k1ZoM4jqDfjHtpYKNVTSRD1RWEdOS65PivHLXkeOjy8RsMbkSHm1mpAt/WaZJQw4NW8a3wnP8phi1WVZVU5DvhuNEs1ADnQ3As7kc9yzCkawCCpz5/r9JqazKgu/uAS+BeNfcYcKPgOX2AjAGEY9PHx6SVpxq7YF8AQ9NES3FBUbxg6cEOyhn4U1yHQUYnn6thRN9el+FPxfbmwmOz0yjWioaqjdzgIGaC8A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2zbkn8Oq3RLW3xO/3EvctSMarYocO2riEQ0ICV2e6Cg=; b=ssUiO6PWydN+AeUalsA12MOXK6mVfmxkObWlI3OQMZb8Xb1Qy9Tl/Iw+IhBEYwhBfFplXrNU0XwKImOqXaX+m5hxnda9hiU7HWKLUsHBo1za7fUkpxA3zuPDeNAn8eKjgaB0gHetxQ7lIGpCZKci25/qCUC+sTwTRU0y0wEYCOU=
Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR07MB4281.eurprd07.prod.outlook.com (2603:10a6:7:95::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.19; Tue, 30 Mar 2021 19:51:39 +0000
Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::9028:916a:402e:aa6a]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::9028:916a:402e:aa6a%6]) with mapi id 15.20.3999.025; Tue, 30 Mar 2021 19:51:39 +0000
From: Mohit Sethi M 
To: Wouter van der Beek , "sarikaya@ieee.org" 
CC: "iotops@ietf.org" , "t2trg@irtf.org" , =?utf-8?B?QXJpIEtlcsOkbmVu?= , Carsten Bormann 
Thread-Topic: [T2TRG] [Iotops] Secure IoT Bootstrapping: A Survey
Thread-Index: AQHXJZ4Yr2qv4wbihU+oNqT/I6eSBg==
Date: Tue, 30 Mar 2021 19:51:39 +0000
Message-ID: <99f6b2c1-15be-687e-f168-a515633092b7@ericsson.com>
References:  <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> <7a8814c0-f6c0-8206-42af-8f23ec18c995@cascoda.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: cascoda.com; dkim=none (message not signed) header.d=none;cascoda.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:14bb:170:164:b6af:f443:f174:3f46]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 666d77e4-09fa-410b-062f-08d8f3b53be6
x-ms-traffictypediagnostic: HE1PR07MB4281:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YWgCFhkNP7dp5iKs16M8jYGsm8XDmU1bbEYgp/xrhTu+c7tU/0HWefupYPHvTe50nKDAUkfun/INEPuRAMTCDqPhAFcrvV0QGtk5ZCnZNjHKUpdY/yNv9WAlqYv6xEWfF5ETqA9VqyQu2mwokmFabwXUMVUk9+yR+KnW6qIMXvjnBydSuEjC0xFhhxFATucNC1eVPdksJjlfp8pmKUBVm2NkEtQsdlUP/yKS1yYh74NTDJ5/ZHoN42eTNb6eNJ8MySOSt2HovbinfURq82b/zUYyNsyCnIBuAKLVA5+gRvCFRTWSlfxwMVQKqEoIOyjdy85qzB90I/nZZmigp0iWEreCqbHlL8wd1J81KVsiImSnkhWv4bEhTDbr0EBcBNrfbqrEoYI4mkMWuc7Xa90SHENmpKtZvB2VOTyqPlrFPnkItpo1cxTBzx8QYkUPZHGDuFJKEf1VdkU4sEVPsTmZ1RCJ8JEe9UNgWyy/ktlfoxQIVSy3N0LUyWsZYNVwMMFycb3pVaHvP7QFijB3qOUjNSZ8AdRZFESWQ+c0tJ3CT6Rb/ghzOyf+A3/3jAiSu87FABucBbzotIDVpEbTqvdleWobdRLp+YcCBD1B+QZmca2kLIDlvGZmtrCYW/QzSg/lgnJOaopt6oUxkZjT5iOcpD5H4dF3gG5giJ3h6RzKcudnMhjvsamCunDA0ETNA32JDJsceeeFkQlRWUlQaKNS6yz+hEYvvzfxkKGjYJ+EDQOVKfaG0NkKq7IcUs7avsZE3kzCbj9G/HKYfzKyGTizhDRjqbK/MXr4J+bfjjq423lpA03kpRRTAiRJzkjgjZOOH4NnZIrPZMMLB7wvkIEsTw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(66574015)(66446008)(83380400001)(31696002)(316002)(64756008)(31686004)(6486002)(76116006)(166002)(66476007)(8936002)(21615005)(6512007)(478600001)(36756003)(5660300002)(2616005)(2906002)(53546011)(6506007)(86362001)(8676002)(966005)(110136005)(4326008)(66946007)(71200400001)(54906003)(186003)(66556008)(38100700001)(15398625002)(43740500002)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?SkZRclorc0RNWkJEYm9mbHIwQVREclozbzhCZy9xR2htWGpjckhSZzN3ZllE?= =?utf-8?B?dUo4UG5QWDVLdE9QVWY4dWhNVHN6VEVoOFlPcE9yZmJBMEhxcHdIUENva3NR?= =?utf-8?B?aEg3NllHYlB1OUdSZ29CSGptRTJqakJGUXNxbkh3OFZmZGdZaisvSUxwdUpU?= =?utf-8?B?dGI5ME9XMzFqZmNqdHZINWNiVjUxNENLdjdqNmRQYzZJbE51RTVkY0J0cEFj?= =?utf-8?B?TWwzRzc5eFd6TEUrSzFSZlI5WGg0eno1ZlpiQitlL0lIWXVvZ2RwWVBOMXhL?= =?utf-8?B?Q3RmcEhsZmViZnJSOGgxNWs0KytMTFBmN3pqNDFwRW1TWmF1L0YrNytNSmFk?= =?utf-8?B?azRnZnpkWkF5aU9jWHFGRWFxZ01mVWcvN1pvNWtrZm9ncFJyNWx1R0Nlelpm?= =?utf-8?B?bWxUbnlvaHZpZWRXRkE0RXN5enRORDlScGJnczhjZ0ZXWnBMTnpTSFF1NFRm?= =?utf-8?B?VnF6QWQ4NEwzRlpnMUJpaGJmQzAzMFVwKzMxUnpZMENjSDQ3RFBjeTNCTzdz?= =?utf-8?B?NThGalBPYmRnd0hiU3JuTmV1eDNMRS9GN0N4ZDFXVWUxR1pFVUhZRTBqT2FP?= =?utf-8?B?SmhlVVI5WGlJeHNLMjM0YXVsaUdhb3dUckhxMnl4eDRPUE9wRXNmY2lBcVo4?= =?utf-8?B?eldFVnIxbitTMFhEcFVnRWdWSDhFRGFGWDZKLzlINWRnb3ExQ3dkYWZjR01J?= =?utf-8?B?cUZXYUhlMG44M2tyblR1YUFSbUE0MnJ2WngrMTlEL3FpZEVNYk9kd1FWUUxj?= =?utf-8?B?Rk9YTjAyUUtpMXpVeTE1d0VERldlMTFyQ3VmZWVaVlBweFphL05tWjF3b200?= =?utf-8?B?UDREcEF2RjZodXRRc1drMUFiT3dHcGUvc2x5VFNrL0hab09rS1YrNjJGU3JG?= =?utf-8?B?MHAvcmRmeGRMaTF0QmNpQWlrZDVyMHBkSUlmNVl3cDRKdmQ4azZrTHoyT1kw?= =?utf-8?B?ZWFMYkU1TmR6RHZ0VWk0QnZQczlFY2pZSS9GSjNlSlNtM09LNytTNjJrMkpm?= =?utf-8?B?NEZ3VjAwbGRUbWErL3kzMktJaVZkZllSUUhVdWVnRmNPd3FPcSs2NHFHcnN2?= =?utf-8?B?enc0R05jV3k1Q1Bzc2ZRVnRoR1RpeTZFK2VrUnE1RVB5cE9tRTBCa3o0aW10?= =?utf-8?B?djBzTWRwaFhSL0RZRDdYWW5vWU5XOHZWdjFQaTRBdWthWlhsM1dXaVMvWVA5?= =?utf-8?B?dG5kVXRIaGl1TTF5U0tyVDF2MVNxR2s1VnBvTVcvYitkZDlsMDhXMEJ2S2tw?= =?utf-8?B?ME5pdUdLTllLQmM4RXVhblpPckI0Uk9la3VCL2hmU3F1clUyRlhmV2t1TTlM?= =?utf-8?B?RGpUVVI0WlV1MVVhNVBLcWFIdk5wYitlMWFiRmxSZFV6dERYNFVPMlUvQ1JF?= =?utf-8?B?OXNtcTNCN3k5cVlPZHpCRTBPWUJKSU55emg3M0VqN0xxa05QY0N2Q2FIRE5W?= =?utf-8?B?RDJDREdXUFVWdVUrdHJ4dEw4Vk9kbFp0T1FVWkYwZnUvS3c1YlBrVHNvcDFB?= =?utf-8?B?aTArRzVJSlFMTGNLbDRQNC9WQld1Tkk3WFBNOHNTVWtWWitKemU1WlY3eFZ5?= =?utf-8?B?c2Ryci93a1lTMHhiNmw4QzJuSVMxWDQxeTRDTy8xYUdoTjVGN0YzQ28xQnhj?= =?utf-8?B?VDU1VDNvS2VNdXdWc1BVTHp5Vy9sZjM3VkZIT3BxUkFyUFdtR2ZwK1l3MEVh?= =?utf-8?B?NDd0RTg0WmF6dnV4aFJhMjh6bkFOcVJwZ2JLR2g2MkEya3VzSTluSUhqV2Yx?= =?utf-8?B?Q2xKTGJQRWkrMG1YZTQ5aHJwT3ZkbVUrK29ya1o5T3plL0FVNW4xK1hKV25q?= =?utf-8?Q?HRNYHJwpIPpYD4utDHvuwTt0cKjIEvjLnO/PM=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_99f6b2c115be687ef168a515633092b7ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 666d77e4-09fa-410b-062f-08d8f3b53be6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 19:51:39.1106 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: F5sR8yeVVE6Ec63suPHUBn5J70xIt0A3dBNS61dycwXSmfSv6W6NGGLBBbQw1hHm0KkVDQ5Mf/zLO2am3zLzz7pVw1qplI67bN2TQzVf5N8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4281
Archived-At: 
Subject: Re: [Iotops] [T2TRG]  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: Tue, 30 Mar 2021 19:51:49 -0000

--_000_99f6b2c115be687ef168a515633092b7ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgV291dGVyLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmZWVkYmFjay4gV2Ugd2lsbCB1cGRhdGUg
dGhlIHJlZmVyZW5jZSBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgdGV4dCBmb3IgT0NGIGluIHRoZSBu
ZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpUaGVyZSBhcmUgbWFueSBzcGVjaWZpY2F0aW9u
cyBvdXQgdGhlcmUgYW5kIGl0IG1heSBub3QgYmUgcG9zc2libGUgdG8gY292ZXIgYWxsIG9mIHRo
ZW0gaW4gYSBzaW5nbGUgZG9jdW1lbnQuIEhvd2V2ZXIsIEkgdGhpbmsgeW91ciBwb2ludGVyIHRv
IHRoZSBGYWlyaGFpciBzcGVjaWZpY2F0aW9uIGlzIHZlcnkgcmVsZXZhbnQgYmVjYXVzZSBvZiBp
dHMgdXNlIG9mIEFOSU1BIGFuZCB3ZSB3aWxsIGFkZCBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9m
IHRoZSBkcmFmdC4NCg0KQmFzZWQgb24geW91ciBmZWVkYmFjaywgSSBoYXZlIG9wZW5lZCAyIGlz
c3VlcyBvbiB0aGUgZ2l0aHViIHJlcG9zaXRvcnkgZm9yIHRoaXMgZHJhZnQ6IGh0dHBzOi8vZ2l0
aHViLmNvbS90MnRyZy9zYm9vdHN0cmFwcGluZy9pc3N1ZXMuDQoNClBlcmhhcHMgeW91IGFscmVh
ZHkga25vdyB0aGlzIGJ1dCBJIHdvdWxkIGxpa2UgdG8gaGlnaGxpZ2h0IHRoYXQgdGhlIHJlc2Vh
cmNoIGdyb3VwIGlzIGN1cnJlbnRseSBjb25zaWRlcmluZyBpZiB0aGlzIGRyYWZ0IHNob3VsZCBi
ZSBhZG9wdGVkLiBBZG9wdGlvbiBkb2VzIG5vdCBtZWFuIHB1YmxpY2F0aW9uLiBEcmFmdHMgbm9y
bWFsbHkgdW5kZXJnbyBtYW55IHJldmlzaW9ucyBhbmQgcmV2aWV3cyBiZWZvcmUgY29uc2lkZXJp
bmcgcHVibGljYXRpb24gYXMgYW4gUkZDLg0KDQotLU1vaGl0DQoNCk9uIDMvMzAvMjEgNjoyMSBQ
TSwgV291dGVyIHZhbiBkZXIgQmVlayB3cm90ZToNCg0KRnJhbmtseSwgYXMgYXV0aG9yIEkgd291
bGQgaGF2ZSByZWFjaGVkIG91dCB0byBPQ0YuDQoNCkkgbmV2ZXIgc2F3IGEgcmVxdWVzdCBpbiBP
Q0YgZm9yIGEgcmV2aWV3IG9mIHRoaXMgdGV4dC4NCg0KZm9yIHN0YXJ0ZXJzIGN1cnJlbnQgdmVy
c2lvbiBvZiBzcGVjcyBvZiBPQ0YgaXMgdjIuMi4yIHZlcnNpb24gMS4wIGlzIGEgbG9uZyBsb25n
IHRpbWUgYWdvLg0KDQpvbmUgY2FuIGFsc28gcmVmZXJlbmNlIHRoZSBJU08vSUVDIHZlcnNpb24g
KGh0dHBzOi8vd3d3Lmlzby5vcmcvc3RhbmRhcmQvNzQyMzkuaHRtbCApIHRoYXQgaXMgYWxzbyB3
YXkgYmV0dGVyIHRoYW4gdGhlIHYxLjAuMCB2ZXJzaW9uIHJlZmVyZW5jZWQuDQoNCg0KQWxzbyB0
aGUgRmFpcmhhaXIgc3BlYyBpcyBub3QgbGlzdGVkIGluIHRoaXMgZHJhZnQgUkZDLiBUaGlzIGRv
Y3VtZW50IGlzIHJlZ2FyZGVkIGluIHRoZSBidWlsZGluZyBpbmR1c3RyeSBhcyBhIGd1aWRpbmcg
ZG9jdW1lbnQuDQoNCmh0dHBzOi8vb3BlbmNvbm5lY3Rpdml0eS5vcmcvd3AtY29udGVudC91cGxv
YWRzLzIwMTkvMTEvZmFpcmhhaXItc3BlY2lmaWNhdGlvbi12ZXJzaW9uLTEwX2FwcHJvdmVkX2Fw
cmlsLTIwMTkucGRmDQoNCktpbmQgUmVnYXJkLA0KDQpXb3V0ZXINCg0KDQpPbiAzMC8wMy8yMDIx
IDE2OjEyLCBCZWhjZXQgU2FyaWtheWEgd3JvdGU6DQoNCg0KT24gVHVlLCBNYXIgMzAsIDIwMjEg
YXQgNjoyOSBBTSBXb3V0ZXIgdmFuIGRlciBCZWVrIDx3LnZhbmRlcmJlZWtAY2FzY29kYS5jb208
bWFpbHRvOncudmFuZGVyYmVla0BjYXNjb2RhLmNvbT4+IHdyb3RlOg0KDQpIaSBBbGwsDQoNCndo
byB3cm90ZSB0aGUgT0NGIHNlY3Rpb24/DQoNCkl0IHdhcyBpbnRyb2R1Y2VkIGluIFJldi4gMDgu
DQpJIHRoaW5rIE1vaGl0IHdyb3RlIGl0Lg0KV2h5IGRpZCB5b3UgYXNrPw0KDQpCZWhjZXQNCg0K
S2luZCBSZWdhcmRzLA0KDQpXb3V0ZXINCg0KT24gMzAvMDMvMjAyMSAxMjoxMywgQ2Fyc3RlbiBC
b3JtYW5uIHdyb3RlOg0KDQpPbiAyMDIxLTAyLTE5LCBhdCAxNjozOCwgRWxpb3QgTGVhciA8bGVh
ckBjaXNjby5jb20+PG1haWx0bzpsZWFyQGNpc2NvLmNvbT4gd3JvdGU6DQoNCg0KVmVyeSB3ZWxs
IHRpbWVkLiAgSSBsb29rIGZvcndhcmQgdG8gZGlzY3Vzc2luZyB0aGlzLg0KDQoNClRoYW5rcyEN
Cg0KTm93IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIGdldCBzb21lIGluaXRpYWwgZmVlZGJhY2sg
4oCUIHdlIHBsYW4gdG8gYWRvcHQgaXQgYXMgYW4gUkcgZG9jdW1lbnQgb24gQXByaWwgNnRoLg0K
DQpHcsO8w59lLCBDYXJzdGVuDQoNCg0KDQpFbGlvdA0KDQoNCg0KT24gMTkgRmViIDIwMjEsIGF0
IDE2OjI0LCBBcmkgS2Vyw6RuZW4gPGFyaS5rZXJhbmVuPTQwZXJpY3Nzb24uY29tQGRtYXJjLmll
dGYub3JnPjxtYWlsdG86YXJpLmtlcmFuZW49NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+
IHdyb3RlOg0KDQpIaSBJb1RPUFMgZm9sa3MsDQoNCkF0IFQyVFJHIHRoZSAiU2VjdXJlIElvVCBC
b290c3RyYXBwaW5nOiBBIFN1cnZleSIgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZDoNCmh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhcmlrYXlhLXQydHJnLXNib290c3RyYXBw
aW5nLw0KDQpUaGUgZHJhZnQgaGFzIGJlZW4gZGlzY3Vzc2VkIGFuZCBkZXZlbG9wZWQgcXVpdGUg
c29tZSB0aW1lIGluIHRoZSBUMlRSRyBhbmQgd2UgY2hhaXJzIHRoaW5rIGl0J3Mgbm93IGdldHRp
bmcgY2xvc2UgdG8gcmVhZHkgZm9yIGFkb3B0aW9uLiBXZSB3b3VsZCBsaWtlIHRvIGhlYXIgdmll
d3Mgb24gdGhpcyBmcm9tIHRoZSBJb1Qgb3BlcmF0aW9uYWwgY29tbXVuaXR5LiBJbiBwYXJ0aWN1
bGFyIHdlJ2QgbGlrZSB0byBoZWFyIGlmIHRoZSB0ZWNobm9sb2dpZXMgY29uc2lkZXJlZCBpbXBv
cnRhbnQgZm9yIHNlY3VyaXR5IHNldHVwIGFuZCBib290c3RyYXBwaW5nIGJ5IHRoaXMgZ3JvdXAg
YXJlIGNvdmVyZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQoNClRoYW5rcywNCkFyaSAmIENhcnN0ZW4N
Cg0KLS0NCklvdG9wcyBtYWlsaW5nIGxpc3QNCklvdG9wc0BpZXRmLm9yZzxtYWlsdG86SW90b3Bz
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3RvcHMN
Cg0KDQotLQ0KDQpXb3V0ZXIgdmFuIGRlciBCZWVrDQoNClByaW5jaXBhbCBFbmdpbmVlcg0KQ2Fz
Y29kYSBMdGQNCg0KU291dGhhbXB0b24gT2ZmaWNlOiAgICAgVGFpcGVpIE9mZmljZToNCiBUaHJl
ZWZpZWxkIEhvdXNlDQogVGhyZWVmaWVsZCBMYW5lDQogU291dGhhbXB0b24NCiBTTzE0IDNMUA0K
IFVLDQogUm0uOTE4LCA5RiwgTm8uOTYsIENoaWEgSHNpbiBCbGRnLg0KIFNlYy4yLCBaaG9uZ3No
YW4gTi5SZC4NCiBaaG9uZ3NoYW4gRGlzdC4NCiBUYWlwZWkNCiBUYWl3YW4NCiBUZWw6ICszNTMg
ODUyNDQ4NzgwDQoNCltodHRwczovL3d3dy5jYXNjb2RhLmNvbS93cC1jb250ZW50L3VwbG9hZHMv
MjAxOS8wMy93b3JkcHJlc3NfMzJ4MzIucG5nXTxodHRwczovL3d3dy5jYXNjb2RhLmNvbT5baHR0
cHM6Ly93d3cuY2FzY29kYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMDMvdHdpdHRlcl8z
MngzMi5wbmddPGh0dHBzOi8vdHdpdHRlci5jb20vY2FzY29kYT5baHR0cHM6Ly93d3cuY2FzY29k
YS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMDMvbGlua2VkaW5fMzJ4MzIucG5nXTxodHRw
czovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9jYXNjb2RhLWx0ZC8+W2h0dHBzOi8vd3d3LmNh
c2NvZGEuY29tL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDE5LzAzL3lvdXR1YmVfMzJ4MzIucG5nXTxo
dHRwczovL3d3dy55b3V0dWJlLmNvbS9jaGFubmVsL1VDaTl6YnBTQkxuV0o0WGY3OU5uRVM0UT4N
Cg0KUmVnaXN0ZXJlZCBPZmZpY2U6IDEyLTE0IENhcmx0b24gUGxhY2UsIFNvdXRoYW1wdG9uIFNP
MTUgMkVBLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlczogNjE3NDI5OQ0KDQpD
b25maWRlbnRpYWxpdHk6IFRoaXMgZS1tYWlsIHRyYW5zbWlzc2lvbiBpcyBzdHJpY3RseSBjb25m
aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4gSXQgbWF5IGNv
bnRhaW4gcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBpZiB5b3Ug
YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgbXVzdCBub3QgY29weSBvciBkaXN0
cmlidXRlIGl0LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIGUtbWFpbCB0cmFuc21pc3Npb24g
aW1tZWRpYXRlbHkuDQpWaXJ1c2VzOiBBbHRob3VnaCB3ZSBoYXZlIHRha2VuIHN0ZXBzIHRvIGVu
c3VyZSB0aGF0IHRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2
aXJ1cywgd2UgYWR2aXNlIHRoYXQgaW4ga2VlcGluZyB3aXRoIGdvb2QgY29tcHV0aW5nIHByYWN0
aWNlIHRoZSByZWNpcGllbnQgc2hvdWxkIGVuc3VyZSB0aGV5IGFyZSBhY3R1YWxseSB2aXJ1cyBm
cmVlLg0KU2VjdXJpdHkgV2FybmluZzogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGUtbWFpbCBoYXMg
YmVlbiBjcmVhdGVkIGluIHRoZSBrbm93bGVkZ2UgdGhhdCBpbnRlcm5ldCBlLW1haWwgaXMgbm90
IGEgMTAwJSBzZWN1cmUgY29tbXVuaWNhdGlvbnMgbWVkaXVtLiBXZSBhZHZpc2UgdGhhdCB5b3Ug
dW5kZXJzdGFuZCB0aGlzIGxhY2sgb2Ygc2VjdXJpdHkgYW5kIHRha2UgYW55IG5lY2Vzc2FyeSBt
ZWFzdXJlcyB3aGVuIGUtbWFpbGluZyB1cy4NCg0KLS0NCg0KV291dGVyIHZhbiBkZXIgQmVlaw0K
DQpQcmluY2lwYWwgRW5naW5lZXINCkNhc2NvZGEgTHRkDQoNClNvdXRoYW1wdG9uIE9mZmljZTog
ICAgIFRhaXBlaSBPZmZpY2U6DQogVGhyZWVmaWVsZCBIb3VzZQ0KIFRocmVlZmllbGQgTGFuZQ0K
IFNvdXRoYW1wdG9uDQogU08xNCAzTFANCiBVSw0KIFJtLjkxOCwgOUYsIE5vLjk2LCBDaGlhIEhz
aW4gQmxkZy4NCiBTZWMuMiwgWmhvbmdzaGFuIE4uUmQuDQogWmhvbmdzaGFuIERpc3QuDQogVGFp
cGVpDQogVGFpd2FuDQogVGVsOiArMzUzIDg1MjQ0ODc4MA0KDQpbaHR0cHM6Ly93d3cuY2FzY29k
YS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMDMvd29yZHByZXNzXzMyeDMyLnBuZ108aHR0
cHM6Ly93d3cuY2FzY29kYS5jb20+W2h0dHBzOi8vd3d3LmNhc2NvZGEuY29tL3dwLWNvbnRlbnQv
dXBsb2Fkcy8yMDE5LzAzL3R3aXR0ZXJfMzJ4MzIucG5nXTxodHRwczovL3R3aXR0ZXIuY29tL2Nh
c2NvZGE+W2h0dHBzOi8vd3d3LmNhc2NvZGEuY29tL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDE5LzAz
L2xpbmtlZGluXzMyeDMyLnBuZ108aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvY2Fz
Y29kYS1sdGQvPltodHRwczovL3d3dy5jYXNjb2RhLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAx
OS8wMy95b3V0dWJlXzMyeDMyLnBuZ108aHR0cHM6Ly93d3cueW91dHViZS5jb20vY2hhbm5lbC9V
Q2k5emJwU0JMbldKNFhmNzlObkVTNFE+DQoNClJlZ2lzdGVyZWQgT2ZmaWNlOiAxMi0xNCBDYXJs
dG9uIFBsYWNlLCBTb3V0aGFtcHRvbiBTTzE1IDJFQSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFu
ZCBhbmQgV2FsZXM6IDYxNzQyOTkNCg0KQ29uZmlkZW50aWFsaXR5OiBUaGlzIGUtbWFpbCB0cmFu
c21pc3Npb24gaXMgc3RyaWN0bHkgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9y
IHRoZSBhZGRyZXNzZWUuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlh
bCBpbmZvcm1hdGlvbiBhbmQgaWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
eW91IG11c3Qgbm90IGNvcHkgb3IgZGlzdHJpYnV0ZSBpdC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg
dGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl
IHRoZSBlLW1haWwgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0KVmlydXNlczogQWx0aG91Z2gg
d2UgaGF2ZSB0YWtlbiBzdGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGUtbWFpbCBhbmQgYXR0YWNo
bWVudHMgYXJlIGZyZWUgZnJvbSBhbnkgdmlydXMsIHdlIGFkdmlzZSB0aGF0IGluIGtlZXBpbmcg
d2l0aCBnb29kIGNvbXB1dGluZyBwcmFjdGljZSB0aGUgcmVjaXBpZW50IHNob3VsZCBlbnN1cmUg
dGhleSBhcmUgYWN0dWFsbHkgdmlydXMgZnJlZS4NClNlY3VyaXR5IFdhcm5pbmc6IFBsZWFzZSBu
b3RlIHRoYXQgdGhpcyBlLW1haWwgaGFzIGJlZW4gY3JlYXRlZCBpbiB0aGUga25vd2xlZGdlIHRo
YXQgaW50ZXJuZXQgZS1tYWlsIGlzIG5vdCBhIDEwMCUgc2VjdXJlIGNvbW11bmljYXRpb25zIG1l
ZGl1bS4gV2UgYWR2aXNlIHRoYXQgeW91IHVuZGVyc3RhbmQgdGhpcyBsYWNrIG9mIHNlY3VyaXR5
IGFuZCB0YWtlIGFueSBuZWNlc3NhcnkgbWVhc3VyZXMgd2hlbiBlLW1haWxpbmcgdXMuDQoNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVDJUUkcg
bWFpbGluZyBsaXN0DQpUMlRSR0BpcnRmLm9yZzxtYWlsdG86VDJUUkdAaXJ0Zi5vcmc+DQpodHRw
czovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3QydHJnDQoNCg==

--_000_99f6b2c115be687ef168a515633092b7ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <99A054C267E6984CAF351E10CC382D52@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgV291dGVy
LDwvcD4NCjxwPlRoYW5rIHlvdSBmb3IgdGhlIGZlZWRiYWNrLiBXZSB3aWxsIHVwZGF0ZSB0aGUg
cmVmZXJlbmNlIGFuZCB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IGZvciBPQ0YgaW4gdGhlIG5leHQg
dmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo8YnI+DQo8L3A+DQo8cD5UaGVyZSBhcmUgbWFueSBzcGVj
aWZpY2F0aW9ucyBvdXQgdGhlcmUgYW5kIGl0IG1heSBub3QgYmUgcG9zc2libGUgdG8gY292ZXIg
YWxsIG9mIHRoZW0gaW4gYSBzaW5nbGUgZG9jdW1lbnQuIEhvd2V2ZXIsIEkgdGhpbmsgeW91ciBw
b2ludGVyIHRvIHRoZSBGYWlyaGFpciBzcGVjaWZpY2F0aW9uIGlzIHZlcnkgcmVsZXZhbnQgYmVj
YXVzZSBvZiBpdHMgdXNlIG9mIEFOSU1BIGFuZCB3ZSB3aWxsIGFkZCBpdCBpbiB0aGUgbmV4dCB2
ZXJzaW9uDQogb2YgdGhlIGRyYWZ0LiZuYnNwOzwvcD4NCjxwPkJhc2VkIG9uIHlvdXIgZmVlZGJh
Y2ssIEkgaGF2ZSBvcGVuZWQgMiBpc3N1ZXMgb24gdGhlIGdpdGh1YiByZXBvc2l0b3J5IGZvciB0
aGlzIGRyYWZ0Og0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6
Ly9naXRodWIuY29tL3QydHJnL3Nib290c3RyYXBwaW5nL2lzc3VlcyI+DQpodHRwczovL2dpdGh1
Yi5jb20vdDJ0cmcvc2Jvb3RzdHJhcHBpbmcvaXNzdWVzPC9hPi4gPGJyPg0KPC9wPg0KPHA+UGVy
aGFwcyB5b3UgYWxyZWFkeSBrbm93IHRoaXMgYnV0IEkgd291bGQgbGlrZSB0byBoaWdobGlnaHQg
dGhhdCB0aGUgcmVzZWFyY2ggZ3JvdXAgaXMgY3VycmVudGx5IGNvbnNpZGVyaW5nIGlmIHRoaXMg
ZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQuIEFkb3B0aW9uIGRvZXMgbm90IG1lYW4gcHVibGljYXRp
b24uIERyYWZ0cyBub3JtYWxseSB1bmRlcmdvIG1hbnkgcmV2aXNpb25zIGFuZCByZXZpZXdzIGJl
Zm9yZSBjb25zaWRlcmluZyBwdWJsaWNhdGlvbg0KIGFzIGFuIFJGQy4gPGJyPg0KPC9wPg0KPHA+
LS1Nb2hpdDxicj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMy8zMC8y
MSA2OjIxIFBNLCBXb3V0ZXIgdmFuIGRlciBCZWVrIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOmEwNmU3MWU5LWJjNGQtYWUzYS0yMzRiLTA0M2Zj
NDQ5YTMyNEBjYXNjb2RhLmNvbSI+DQo8cD5GcmFua2x5LCBhcyBhdXRob3IgSSB3b3VsZCBoYXZl
IHJlYWNoZWQgb3V0IHRvIE9DRi48L3A+DQo8cD5JIG5ldmVyIHNhdyBhIHJlcXVlc3QgaW4gT0NG
IGZvciBhIHJldmlldyBvZiB0aGlzIHRleHQuPGJyPg0KPC9wPg0KPHA+Zm9yIHN0YXJ0ZXJzIGN1
cnJlbnQgdmVyc2lvbiBvZiBzcGVjcyBvZiBPQ0YgaXMgdjIuMi4yIHZlcnNpb24gMS4wIGlzIGEg
bG9uZyBsb25nIHRpbWUgYWdvLjwvcD4NCjxwPm9uZSBjYW4gYWxzbyByZWZlcmVuY2UgdGhlIElT
Ty9JRUMgdmVyc2lvbiAoPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0
cHM6Ly93d3cuaXNvLm9yZy9zdGFuZGFyZC83NDIzOS5odG1sIiBtb3otZG8tbm90LXNlbmQ9InRy
dWUiPmh0dHBzOi8vd3d3Lmlzby5vcmcvc3RhbmRhcmQvNzQyMzkuaHRtbDwvYT4gKSB0aGF0IGlz
IGFsc28gd2F5IGJldHRlciB0aGFuIHRoZSB2MS4wLjAgdmVyc2lvbiByZWZlcmVuY2VkLjwvcD4N
CjxwPjxicj4NCjwvcD4NCjxwPkFsc28gdGhlIEZhaXJoYWlyIHNwZWMgaXMgbm90IGxpc3RlZCBp
biB0aGlzIGRyYWZ0IFJGQy4gVGhpcyBkb2N1bWVudCBpcyByZWdhcmRlZCBpbiB0aGUgYnVpbGRp
bmcgaW5kdXN0cnkgYXMgYSBndWlkaW5nIGRvY3VtZW50Ljxicj4NCjwvcD4NCjxwPjxhIGNsYXNz
PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vb3BlbmNvbm5lY3Rpdml0eS5v
cmcvd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTEvZmFpcmhhaXItc3BlY2lmaWNhdGlvbi12ZXJz
aW9uLTEwX2FwcHJvdmVkX2FwcmlsLTIwMTkucGRmIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0
dHBzOi8vb3BlbmNvbm5lY3Rpdml0eS5vcmcvd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTEvZmFp
cmhhaXItc3BlY2lmaWNhdGlvbi12ZXJzaW9uLTEwX2FwcHJvdmVkX2FwcmlsLTIwMTkucGRmPC9h
Pjxicj4NCjwvcD4NCjxwPktpbmQgUmVnYXJkLDwvcD4NCjxwPldvdXRlcjxicj4NCjwvcD4NCjxw
Pjxicj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMzAvMDMvMjAyMSAx
NjoxMiwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSIgY2l0ZT0ibWlkOkNBQzhRQWNkZDlxbS1aaGNMckhrUDNWSmpFejhSX2E1aEFQOU1R
VGVvYXJraXpIdEFzQUBtYWlsLmdtYWlsLmNvbSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGly
PSJsdHIiPjxicj4NCjwvZGl2Pg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRp
diBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFR1ZSwgTWFyIDMwLCAyMDIxIGF0IDY6
MjkgQU0gV291dGVyIHZhbiBkZXIgQmVlayAmbHQ7PGEgaHJlZj0ibWFpbHRvOncudmFuZGVyYmVl
a0BjYXNjb2RhLmNvbSIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj53LnZhbmRlcmJlZWtAY2FzY29k
YS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp
bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweA0KMC44ZXg7Ym9yZGVyLWxlZnQtd2lk
dGg6MXB4O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQs
MjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0KPHA+SGkgQWxsLDwvcD4NCjxwPndo
byB3cm90ZSB0aGUgT0NGIHNlY3Rpb24/IDxicj4NCjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SXQgd2FzIGludHJvZHVjZWQgaW4gUmV2LiAwOC48
L2Rpdj4NCjxkaXY+SSB0aGluayBNb2hpdCB3cm90ZSBpdC48L2Rpdj4NCjxkaXY+V2h5IGRpZCB5
b3UgYXNrPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVoY2V0Jm5ic3A7PC9kaXY+
DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw
cHgNCjAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDti
b3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRp
dj4NCjxwPjwvcD4NCjxwPktpbmQgUmVnYXJkcyw8L3A+DQo8cD5Xb3V0ZXI8YnI+DQo8L3A+DQo8
ZGl2Pk9uIDMwLzAzLzIwMjEgMTI6MTMsIENhcnN0ZW4gQm9ybWFubiB3cm90ZTo8YnI+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZT5PbiAyMDIxLTAyLTE5LCBhdCAxNjoz
OCwgRWxpb3QgTGVhciA8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20iIHRhcmdldD0iX2Js
YW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPiZsdDtsZWFyQGNpc2NvLmNvbSZndDs8L2E+IHdy
b3RlOg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmU+VmVyeSB3ZWxsIHRp
bWVkLiAgSSBsb29rIGZvcndhcmQgdG8gZGlzY3Vzc2luZyB0aGlzLg0KPC9wcmU+DQo8L2Jsb2Nr
cXVvdGU+DQo8cHJlPlRoYW5rcyENCg0KTm93IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIGdldCBz
b21lIGluaXRpYWwgZmVlZGJhY2sg4oCUIHdlIHBsYW4gdG8gYWRvcHQgaXQgYXMgYW4gUkcgZG9j
dW1lbnQgb24gQXByaWwgNnRoLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCjwvcHJlPg0KPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlPkVsaW90DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iY2l0ZSI+DQo8cHJlPk9uIDE5IEZlYiAyMDIxLCBhdCAxNjoyNCwgQXJpIEtlcsOkbmVuIDxh
IGhyZWY9Im1haWx0bzphcmkua2VyYW5lbj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0O2FyaS5rZXJhbmVuPTQw
ZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0OzwvYT4gd3JvdGU6DQoNCkhpIElvVE9QUyBm
b2xrcywNCg0KQXQgVDJUUkcgdGhlICZxdW90O1NlY3VyZSBJb1QgQm9vdHN0cmFwcGluZzogQSBT
dXJ2ZXkmcXVvdDsgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZDoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhcmlrYXlhLXQydHJnLXNib290c3RyYXBwaW5n
LyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2FyaWtheWEtdDJ0cmctc2Jvb3RzdHJhcHBpbmcvPC9h
Pg0KDQpUaGUgZHJhZnQgaGFzIGJlZW4gZGlzY3Vzc2VkIGFuZCBkZXZlbG9wZWQgcXVpdGUgc29t
ZSB0aW1lIGluIHRoZSBUMlRSRyBhbmQgd2UgY2hhaXJzIHRoaW5rIGl0J3Mgbm93IGdldHRpbmcg
Y2xvc2UgdG8gcmVhZHkgZm9yIGFkb3B0aW9uLiBXZSB3b3VsZCBsaWtlIHRvIGhlYXIgdmlld3Mg
b24gdGhpcyBmcm9tIHRoZSBJb1Qgb3BlcmF0aW9uYWwgY29tbXVuaXR5LiBJbiBwYXJ0aWN1bGFy
IHdlJ2QgbGlrZSB0byBoZWFyIGlmIHRoZSB0ZWNobm9sb2dpZXMgY29uc2lkZXJlZCBpbXBvcnRh
bnQgZm9yIHNlY3VyaXR5IHNldHVwIGFuZCBib290c3RyYXBwaW5nIGJ5IHRoaXMgZ3JvdXAgYXJl
IGNvdmVyZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQoNClRoYW5rcywNCkFyaSAmYW1wOyBDYXJzdGVu
DQoNCi0tDQpJb3RvcHMgbWFpbGluZyBsaXN0DQo8YSBocmVmPSJtYWlsdG86SW90b3BzQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5Jb3RvcHNAaWV0Zi5v
cmc8L2E+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lv
dG9wcyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3RvcHM8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+LS0gPGJyPg0KPGJyPg0KV291
dGVyIHZhbiBkZXIgQmVlazxicj4NCjxicj4NClByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkNhc2Nv
ZGEgTHRkPGJyPg0KPGJyPg0KPHRhYmxlIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2Ui
IGlkPSJnbWFpbC1tXzE0ODIyMDc5NzM1NTQ5NjZBdXRvTnVtYmVyMSIgd2lkdGg9IjUwJSIgY2Vs
bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBib3JkZXI9IjEiPg0KPHRib2R5Pg0KPHRyPg0K
PHRkIHdpZHRoPSI1MCUiPjxiPlNvdXRoYW1wdG9uIE9mZmljZTo8L2I+PC90ZD4NCjx0ZCB3aWR0
aD0iNTAlIj48Yj5UYWlwZWkgT2ZmaWNlOjwvYj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0
aD0iNTAlIj4mbmJzcDtUaHJlZWZpZWxkIEhvdXNlPGJyPg0KJm5ic3A7VGhyZWVmaWVsZCBMYW5l
PGJyPg0KJm5ic3A7U291dGhhbXB0b248YnI+DQombmJzcDtTTzE0IDNMUDxicj4NCiZuYnNwO1VL
PGJyPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNTAlIj4mbmJzcDtSbS45MTgsIDlGLCBOby45NiwgQ2hp
YSBIc2luIEJsZGcuPGJyPg0KJm5ic3A7U2VjLjIsIFpob25nc2hhbiBOLlJkLjxicj4NCiZuYnNw
O1pob25nc2hhbiBEaXN0Ljxicj4NCiZuYnNwO1RhaXBlaTxicj4NCiZuYnNwO1RhaXdhbjxicj4N
CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHdpZHRoPSI1MCUiPiZuYnNwO1RlbDogKzM1MyA4NTI0
NDg3ODA8L3RkPg0KPHRkIHdpZHRoPSI1MCUiPiZuYnNwOzwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N
CjwvdGFibGU+DQo8cD48c3ViPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmNhc2NvZGEuY29tIiB0YXJn
ZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48aW1nIHNyYz0iaHR0cHM6Ly93d3cu
Y2FzY29kYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMDMvd29yZHByZXNzXzMyeDMyLnBu
ZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48L2E+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNv
bS9jYXNjb2RhIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48aW1nIHNy
Yz0iaHR0cHM6Ly93d3cuY2FzY29kYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMDMvdHdp
dHRlcl8zMngzMi5wbmciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PC9hPjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmxpbmtlZGluLmNvbS9jb21wYW55L2Nhc2NvZGEtbHRkLyIgdGFyZ2V0PSJfYmxhbmsi
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGltZyBzcmM9Imh0dHBzOi8vd3d3LmNhc2NvZGEuY29t
L3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDE5LzAzL2xpbmtlZGluXzMyeDMyLnBuZyIgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cueW91dHViZS5jb20vY2hhbm5l
bC9VQ2k5emJwU0JMbldKNFhmNzlObkVTNFEiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNl
bmQ9InRydWUiPjxpbWcgc3JjPSJodHRwczovL3d3dy5jYXNjb2RhLmNvbS93cC1jb250ZW50L3Vw
bG9hZHMvMjAxOS8wMy95b3V0dWJlXzMyeDMyLnBuZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48
L2E+PGJyPg0KPC9zdWI+PC9wPg0KPHAgc3R5bGU9ImZvbnQtc2l6ZToxMnB4Ij48Yj5SZWdpc3Rl
cmVkIE9mZmljZTo8L2I+IDEyLTE0IENhcmx0b24gUGxhY2UsIFNvdXRoYW1wdG9uIFNPMTUgMkVB
LCBVSw0KPGJyPg0KPGI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlczo8L2I+IDYxNzQy
OTk8YnI+DQo8YnI+DQo8Yj5Db25maWRlbnRpYWxpdHk6PC9iPiBUaGlzIGUtbWFpbCB0cmFuc21p
c3Npb24gaXMgc3RyaWN0bHkgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo
ZSBhZGRyZXNzZWUuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBp
bmZvcm1hdGlvbiBhbmQgaWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91
IG11c3Qgbm90IGNvcHkgb3IgZGlzdHJpYnV0ZSBpdC4gSWYgeW91IGhhdmUNCiByZWNlaXZlZCB0
aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg
dGhlIGUtbWFpbCB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuPGJyPg0KPGI+VmlydXNlczo8L2I+
IEFsdGhvdWdoIHdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlLW1haWwg
YW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCB3ZSBhZHZpc2UgdGhhdCBp
biBrZWVwaW5nIHdpdGggZ29vZCBjb21wdXRpbmcgcHJhY3RpY2UgdGhlIHJlY2lwaWVudCBzaG91
bGQgZW5zdXJlIHRoZXkgYXJlIGFjdHVhbGx5IHZpcnVzIGZyZWUuPGJyPg0KPGI+U2VjdXJpdHkg
V2FybmluZzo8L2I+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBlLW1haWwgaGFzIGJlZW4gY3JlYXRl
ZCBpbiB0aGUga25vd2xlZGdlIHRoYXQgaW50ZXJuZXQgZS1tYWlsIGlzIG5vdCBhIDEwMCUgc2Vj
dXJlIGNvbW11bmljYXRpb25zIG1lZGl1bS4gV2UgYWR2aXNlIHRoYXQgeW91IHVuZGVyc3RhbmQg
dGhpcyBsYWNrIG9mIHNlY3VyaXR5IGFuZCB0YWtlIGFueSBuZWNlc3NhcnkgbWVhc3VyZXMgd2hl
biBlLW1haWxpbmcgdXMuPGJyPg0KPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSJtb3otc2lnbmF0dXJl
Ij4tLSA8YnI+DQo8YnI+DQpXb3V0ZXIgdmFuIGRlciBCZWVrPGJyPg0KPGJyPg0KUHJpbmNpcGFs
IEVuZ2luZWVyPGJyPg0KQ2FzY29kYSBMdGQ8YnI+DQo8YnI+DQo8dGFibGUgc3R5bGU9ImJvcmRl
ci1jb2xsYXBzZTogY29sbGFwc2UiIGlkPSJBdXRvTnVtYmVyMSIgd2lkdGg9IjUwJSIgY2VsbHNw
YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBib3JkZXJjb2xvcj0iI0ZGRkZGRiIgYm9yZGVyPSIx
Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iNTAlIj48Yj5Tb3V0aGFtcHRvbiBPZmZpY2U6
PC9iPjwvdGQ+DQo8dGQgd2lkdGg9IjUwJSI+PGI+VGFpcGVpIE9mZmljZTo8L2I+PC90ZD4NCjwv
dHI+DQo8dHI+DQo8dGQgd2lkdGg9IjUwJSI+Jm5ic3A7VGhyZWVmaWVsZCBIb3VzZTxicj4NCiZu
YnNwO1RocmVlZmllbGQgTGFuZTxicj4NCiZuYnNwO1NvdXRoYW1wdG9uPGJyPg0KJm5ic3A7U08x
NCAzTFA8YnI+DQombmJzcDtVSzxicj4NCjwvdGQ+DQo8dGQgd2lkdGg9IjUwJSI+Jm5ic3A7Um0u
OTE4LCA5RiwgTm8uOTYsIENoaWEgSHNpbiBCbGRnLjxicj4NCiZuYnNwO1NlYy4yLCBaaG9uZ3No
YW4gTi5SZC48YnI+DQombmJzcDtaaG9uZ3NoYW4gRGlzdC48YnI+DQombmJzcDtUYWlwZWk8YnI+
DQombmJzcDtUYWl3YW48YnI+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCB3aWR0aD0iNTAlIj4m
bmJzcDtUZWw6ICszNTMgODUyNDQ4NzgwPC90ZD4NCjx0ZCB3aWR0aD0iNTAlIj4mbmJzcDs8L3Rk
Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHA+PHN1Yj48YSBocmVmPSJodHRwczovL3d3
dy5jYXNjb2RhLmNvbSIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48aW1nIHNyYz0iaHR0cHM6Ly93
d3cuY2FzY29kYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMDMvd29yZHByZXNzXzMyeDMy
LnBuZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48L2E+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVy
LmNvbS9jYXNjb2RhIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxpbWcgc3JjPSJodHRwczovL3d3
dy5jYXNjb2RhLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxOS8wMy90d2l0dGVyXzMyeDMyLnBu
ZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cubGlua2Vk
aW4uY29tL2NvbXBhbnkvY2FzY29kYS1sdGQvIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxpbWcg
c3JjPSJodHRwczovL3d3dy5jYXNjb2RhLmNvbS93cC1jb250ZW50L3VwbG9hZHMvMjAxOS8wMy9s
aW5rZWRpbl8zMngzMi5wbmciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PC9hPjxhIGhyZWY9Imh0
dHBzOi8vd3d3LnlvdXR1YmUuY29tL2NoYW5uZWwvVUNpOXpicFNCTG5XSjRYZjc5Tm5FUzRRIiBt
b3otZG8tbm90LXNlbmQ9InRydWUiPjxpbWcgc3JjPSJodHRwczovL3d3dy5jYXNjb2RhLmNvbS93
cC1jb250ZW50L3VwbG9hZHMvMjAxOS8wMy95b3V0dWJlXzMyeDMyLnBuZyIgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj48L2E+PGJyPg0KPC9zdWI+PC9wPg0KPHAgc3R5bGU9ImZvbnQtc2l6ZToxMnB4
Ij48Yj5SZWdpc3RlcmVkIE9mZmljZTo8L2I+IDEyLTE0IENhcmx0b24gUGxhY2UsIFNvdXRoYW1w
dG9uIFNPMTUgMkVBLCBVSw0KPGJyPg0KPGI+UmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxl
czo8L2I+IDYxNzQyOTk8YnI+DQo8YnI+DQo8Yj5Db25maWRlbnRpYWxpdHk6PC9iPiBUaGlzIGUt
bWFpbCB0cmFuc21pc3Npb24gaXMgc3RyaWN0bHkgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz
b2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgYW5kIGNv
bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgaWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl
Y2lwaWVudCwgeW91IG11c3Qgbm90IGNvcHkgb3IgZGlzdHJpYnV0ZSBpdC4gSWYgeW91IGhhdmUN
CiByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGFuZCBkZWxldGUgdGhlIGUtbWFpbCB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuPGJyPg0KPGI+
VmlydXNlczo8L2I+IEFsdGhvdWdoIHdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQg
dGhpcyBlLW1haWwgYW5kIGF0dGFjaG1lbnRzIGFyZSBmcmVlIGZyb20gYW55IHZpcnVzLCB3ZSBh
ZHZpc2UgdGhhdCBpbiBrZWVwaW5nIHdpdGggZ29vZCBjb21wdXRpbmcgcHJhY3RpY2UgdGhlIHJl
Y2lwaWVudCBzaG91bGQgZW5zdXJlIHRoZXkgYXJlIGFjdHVhbGx5IHZpcnVzIGZyZWUuPGJyPg0K
PGI+U2VjdXJpdHkgV2FybmluZzo8L2I+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBlLW1haWwgaGFz
IGJlZW4gY3JlYXRlZCBpbiB0aGUga25vd2xlZGdlIHRoYXQgaW50ZXJuZXQgZS1tYWlsIGlzIG5v
dCBhIDEwMCUgc2VjdXJlIGNvbW11bmljYXRpb25zIG1lZGl1bS4gV2UgYWR2aXNlIHRoYXQgeW91
IHVuZGVyc3RhbmQgdGhpcyBsYWNrIG9mIHNlY3VyaXR5IGFuZCB0YWtlIGFueSBuZWNlc3Nhcnkg
bWVhc3VyZXMgd2hlbiBlLW1haWxpbmcgdXMuPGJyPg0KPC9wPg0KPC9kaXY+DQo8YnI+DQo8Zmll
bGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0Pg0KPHByZSBjbGFz
cz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KVDJUUkcgbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86VDJUUkdAaXJ0Zi5vcmciPlQyVFJHQGlydGYu
b3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93
d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90MnRyZyI+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90MnRyZzwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_99f6b2c115be687ef168a515633092b7ericssoncom_--


From nobody Tue Mar 30 13:12: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 1D2E63A0AB9; Tue, 30 Mar 2021 13:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 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, 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 ChP7f8hD2JHu; Tue, 30 Mar 2021 13:11: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 BC38F3A07D4; Tue, 30 Mar 2021 13:11:49 -0700 (PDT)
Received: from [192.168.217.152] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (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 4F90w322JpzyX5; Tue, 30 Mar 2021 22:11:47 +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: <21967.1617129551@localhost>
Date: Tue, 30 Mar 2021 22:11:46 +0200
Cc: Eliot Lear , =?us-ascii?B?PT91dGYtOD9RP0FyaV9LZXI9QzM9QTRuZW4/PQ==?= ,  "draft-sarikaya-t2trg-sbootstrapping@ietf.org" ,  "iotops@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <53C7C8C0-1995-4FEB-98D5-3F3EF26F3527@tzi.org>
References:  <55009522-4B31-4248-B07F-5905B8BFB8CF@cisco.com> <58405701-32CD-42E1-8E84-6BC6A875537E@tzi.org> <21967.1617129551@localhost>
To: Michael Richardson 
X-Mailer: Apple Mail (2.3654.60.0.2.21)
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: Tue, 30 Mar 2021 20:12:07 -0000

On 30. Mar 2021, at 20:39, Michael Richardson  =
wrote:
>=20
>=20
> Carsten Bormann  wrote:
>>> Very well timed.  I look forward to discussing this.
>=20
>> Thanks!
>=20
>> 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.
>=20
> 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, even =
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.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Tue Mar 30 13:54: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 9EF543A0CB0 for ; Tue, 30 Mar 2021 13:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulhGo3rxGGNc for ; Tue, 30 Mar 2021 13:54:05 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.49]) (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 D97363A0CB2 for ; Tue, 30 Mar 2021 13:54:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GSKjnsGwU0I0ch9OxRxKDgNPW29s2aDCq+LdfslzeNzsinTRoroFCH+m/yYNCRHB0a34cFhWdwn4li2hDgR59deFWeto/Wk7q+3G81RR8oUvdGQRmvPD/24uE+BVszTetbSHTn6RG6x4ICA8XraVNf+FshI6104YnfoP9cX//dvh5TDywEW/rvaAhG6AXPtC4VHWtVL4PEJeRC0apelCl14XN/0uT8msCCRJMjbgps+Xh5RuUvBqwfL98KccdnWr6lfsTqazlAC8m/aA1NO9zrvAx28GPjAJFDT/52OomMn4EcZ3/48fTeOnYIAxzUyuVurMoaqg+KgxokbWPL7qJg==
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=6vrWAGN98MS1zqhm+8coeNjzIXayw8spSBes+mfmTaY=; b=kN8ka8Qmpi2vsVJnFnDrrDGAkjxKlsbCu7zsfsz0Y2vSw8oxywzZ166ciCUzJwjCXGiICwmoxyFYdQfZMpHcem+ucuo0o/YhCjtLhYofsSn6dQK/OwEixiRN9UNJt7bL/lCn0VJLyi8pgfYcDWfL3NqCjzQF4NqI+gIHVGa81b6Knt5GzEcH8cMIYeC+PkrIOxVYv1CgI5c/PcXKSYFKHeRdX6gUYgoU4jhQZTEH0WqB04x8pXNPdkPTH0eQG+N6cUaSoJ+cNFqhFHx/dMSZ9OD84RVrd1w5VLZx8A5xsz7HSLXbq7V4eJ9Ag0S48GcmHg+EYNIyfjQrRZstOnsWDA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6vrWAGN98MS1zqhm+8coeNjzIXayw8spSBes+mfmTaY=; b=kOdYa2bo5XDDgNcm7Aivqsq85eWw1WTWaQRwCwbIxbmHwfSmcQWkCFZZF8YYliceJnUKC8IVKQrisHbbDQXMg1sQ8hBhGpAF/Qs/quR1JnHALt9yPpQNmzU4cRM1QXHZVmhtt7FL7/k2InewHgPqdkxe5T9swxw6OV/P3KWlR5A=
Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR0701MB2089.eurprd07.prod.outlook.com (2603:10a6:3:2a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.16; Tue, 30 Mar 2021 20:54:01 +0000
Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::9028:916a:402e:aa6a]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::9028:916a:402e:aa6a%6]) with mapi id 15.20.3999.025; Tue, 30 Mar 2021 20:54:01 +0000
From: Mohit Sethi M 
To: Carsten Bormann , Michael Richardson 
CC: "iotops@ietf.org" , "t2trg@irtf.org" 
Thread-Topic: [Iotops] Secure IoT Bootstrapping: A Survey
Thread-Index: AQHXJabP98VJZE+IvkWJY+N8d8DjyQ==
Date: Tue, 30 Mar 2021 20:54:01 +0000
Message-ID: <08b7f4d5-03a6-3cd1-e36b-9e57932517d2@ericsson.com>
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>
In-Reply-To: <53C7C8C0-1995-4FEB-98D5-3F3EF26F3527@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:14bb:170:164:b6af:f443:f174:3f46]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c5664bfa-fd8e-4d1f-a55d-08d8f3bdf28e
x-ms-traffictypediagnostic: HE1PR0701MB2089:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3ImgUYP/xienuVZrvdOSUDf8qT79vYFfsq5IUxHSDiZKbLflgZzdiFe2Ng18PhV3T8mNeWDqYW6NJj53GkFpkzragl4Jd8PyYOPjU62eNeOJJnHSyJwzheCDjk3RXT0Nf42JROGqeuyA8XJzUMHWopeSQChvUJGtVzJGEaRCSrpX3Gxv323dD6/NZbrDw5WwyAUVe0VDClMZ2KC6NXVU4HtT5X81LUN2E84KC1Gf0S3MXOsHCWEpN002HHWNDQDzL5FaFqOwznFSZ7aHoMreX1Rl2ZlFGgBa8cgwPv105zgEP420xYng5AkxzXJVFkpQseAGT2J1pGAROEUtGybn2fqbtoClbihTsj8eSHFwXznbeNsa3Vs96TbIV05J4TDaWHwWRP3GOFpFhZVBQjkt8t05cAyX83kfVHIF4MMpMNbjeVssBw5Vcs1cOPhTkgyC6IIx07IR7XgK9QoN6sAugPPOTfxhyod7ECCZ/O5DefjdSebhNTpKov074vVf9juBl9DyB7Zj1e4Zrsl38cklyTNV1W2xEW/7ryJ6BfpOeZpPjrQcxsfXSA3E9P2dnvFmAdd12yFVrTDepkjSRFDjDHY7fdM8mvmVXDKvxjygfq36wQhLG+MdRUSgVAUk0wRLVLB1yyvc6jDzqnCH492m0tP/HulEU9PWzJHFN3JgfVi1Ydaw4139NmPZF+SPx5qVG3i5IoYvku+UQIuoIApuLCe9EzNh/tJ0LaBCEdvIrKnASIBRqRssukXiae1UbXEhjBzU/2p4cgLbvFGYnJxgsgj3oPvaR1p8QDWelDvTEP0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(6506007)(64756008)(6512007)(31686004)(66574015)(2616005)(8676002)(8936002)(38100700001)(86362001)(71200400001)(4326008)(83380400001)(66476007)(186003)(31696002)(5660300002)(54906003)(66946007)(36756003)(76116006)(110136005)(66556008)(2906002)(66446008)(316002)(6486002)(53546011)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?eEI0bllPalljOEN5VGNMNW85di96STdLUGxrVHhZZlFPcVFsc0Fmdk5mbml2?= =?utf-8?B?cGIzTE5QMFhjSllKb0VjWkVmT1ppMjFYSGV4OWltSTRrQUdzVmhLY3ZkVmpK?= =?utf-8?B?Z0hkUkE1cGdKQzdhRUNlb3pIZmVEZ3FJRHI2NU00TEdiUk03eDQ2UG9KYk10?= =?utf-8?B?dC9qb1o3NHBqYUVtSUErSWdLM1BVeVdVNzBlWURyQkl1M3l6L2NXU2prK3V3?= =?utf-8?B?cEszUUgxbXZrck0zQi9jR0Jydm5DaXp1SDJOWHFYZTdYdnYwMGZ4RXBtT2Z0?= =?utf-8?B?THVubThWc2ZVSXUyVFBiSnluUG53ZDJ1N2tTVWFpWXUyTjdlOWU0eHYrUG5H?= =?utf-8?B?NU05Y1Y4R3MwSXNlcTdXdzl5YnFUeXN6Z0xuOUtkUTN4TDBodlFhM3h3OWFy?= =?utf-8?B?aHo1YjdHU1VFcVdMN3RwNVVZLy8xQ2FoQzVYNTNhV3QrQ1pnN0ljcElqdzI5?= =?utf-8?B?U1MzU2Y5TDN2SWJ0ZmZaMWl6eEFmaHdKM3dHTTJORzNRT0ovNUNaam8zcXpx?= =?utf-8?B?M2hGWmNyK1ZYM2hmSDUyUzh2S3pXMVRkV0hpVXBMWDhkeGNiRk1DbTdYS1dP?= =?utf-8?B?U1lOR3ZMdUZhYWY4clJOMFBNVERFcWdmWlJSRGw3cFpTSXFjZ0VxVGx5Wk1o?= =?utf-8?B?MDJ4MFp2d3grUHgxZjNGN011bGtaRnlIN3dkNnlMSWxYNXVvNGdZOGFoeXlW?= =?utf-8?B?bjk0QlhZSENXdkNObFFWekJMSGhCK2hCZWJRSnlyU3ZZQW1KTmVZdWdhNGN0?= =?utf-8?B?WlN3K3J0YjY5Zjh3WlhrbXZPbUF4bkdZOWVub2s5bTZUbDhuZ2l3VWw5bVpN?= =?utf-8?B?WnlaMk12SC9tbmFsUHdjbXl3NldoYXlncXp6d054N1FCSEJRWEJieVZWUVpi?= =?utf-8?B?bVlTV2U1MkNla0h5K1hxeW5SMkc0QTBPOC9MWTV1bXFpOXNFNERJcTc4V0Rr?= =?utf-8?B?QTNvanU3VnFnRXdVcERYc09zSXRpbDV6dEFNdGNjdmFOUVJZWlc2eGRobXpC?= =?utf-8?B?RW53dC9uMnQ0TmtaVm5qOGhOVlJ1YnJib3UwaVY5WWN0R0R4cDRHRU5XUGRv?= =?utf-8?B?aE5iL3pQRGtEYUVQQzJwakRlZGV3MzQwUXU1RmNIem5najNKcTFhTVRIUnl0?= =?utf-8?B?a1FBVjlNUTJJS2t3UFY3R0ZKc2RqSlVGcTNydlU1Nkh6R3BKMm5rLy9LYzVS?= =?utf-8?B?MUFjbDhnMXlRdGZacEFQK1k4VXdGenRqSWpFbDJlSStKTThKWHVTTWpSSS8y?= =?utf-8?B?RGRNSXJxVUVxZllhYWI5b0o1cGxiOEVNUk94Wm5mZTRPL0hIbE1pNFV5aU9m?= =?utf-8?B?MkRzS3hSUzF6UWlTRjBGalg4UVgzOUlQYW9aaHBLTzVVNGgyWGh2cFVxTi96?= =?utf-8?B?S3hiUXpRQjZqRFdCZmxuVlRTZmNTVDY1ZkxsbXNEZWFzVGpSYkRiQkowaFVS?= =?utf-8?B?ZGMrcXBMVUVab3FzdWNjY0owRTk3Qkl1alJpdEkwQXBIeWVQNlRneGo0TjUy?= =?utf-8?B?VEFQdURnMnd1OUxta3RpSVhOeW4xSWJwMUZzV1ZZcjUwSmZqZlI3ajJvSEVv?= =?utf-8?B?ckVObngzMHNIbmFReFdBVGdjd0JwNXcyajNhTUp6cXlDVmtROFc4Nkk5M1Jo?= =?utf-8?B?Q0FhaENxanhjd1BYcmJlazk1cFdiOVVVS1ZxS0FoSlNObGZZa1FEbnkwOEJ1?= =?utf-8?B?ekJkbzZYRERaZVdTUHljWXBlby9wdlNzNkduQnBkK2M5RHlRNWo3UGNUVjRL?= =?utf-8?B?MC9OM3duWnhsSjVXWWFrY1kySXl6bGZrUTgwV1h5ODU5RDFVcEN5UHVNR2ZE?= =?utf-8?Q?FqTw+m4YxE5Zt8oS9dkbYf4JU4ia/X2El+YSM=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <1B72DCD9A698D746B7C0A653096E2A97@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c5664bfa-fd8e-4d1f-a55d-08d8f3bdf28e
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 20:54:01.5978 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +hO5l3tHPLgKP8EAo7R1wWByn7Xs3qwkUNpZ/UZVsQffGAQwJeU7umeAJWjq2Q7QuwXQ5IdA65eUWqhPJLCnaaU3onOpxB3G32XUOsrm0Jk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2089
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: Tue, 30 Mar 2021 20:54:11 -0000

RGVhciBDYXJzdGVuLCBNaWNoYWVsLA0KDQpPbiAzLzMwLzIxIDExOjExIFBNLCBDYXJzdGVuIEJv
cm1hbm4gd3JvdGU6DQo+IE9uIDMwLiBNYXIgMjAyMSwgYXQgMjA6MzksIE1pY2hhZWwgUmljaGFy
ZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+DQo+PiBDYXJzdGVuIEJvcm1h
bm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+Pj4+IFZlcnkgd2VsbCB0aW1lZC4gIEkgbG9vayBm
b3J3YXJkIHRvIGRpc2N1c3NpbmcgdGhpcy4NCj4+PiBUaGFua3MhDQo+Pj4gTm93IHdvdWxkIGJl
IGEgZ29vZCB0aW1lIHRvIGdldCBzb21lIGluaXRpYWwgZmVlZGJhY2sg4oCUIHdlIHBsYW4gdG8N
Cj4+PiBhZG9wdCBpdCBhcyBhbiBSRyBkb2N1bWVudCBvbiBBcHJpbCA2dGguDQo+PiBJIHdvbmRl
ciBpZiBoYXZpbmcgaXQgYWRvcHRlZCBpbiBJT1RPUFMgbWlnaHQgbWFrZSBtb3JlIHNlbnNlLg0K
PiBDZXJ0YWlubHkg4oCUIGFkZHJlc3NpbmcgdGhhdCBtaWdodCBiZSBwYXJ0IG9mIHRoYXQgZmVl
ZGJhY2suDQo+IEl0IGFwcGVhcnMgdG8gbWUgdGhhdCB0aGUgZG9jdW1lbnQgd291bGQgYmUgY292
ZXJlZCBieSBpdHMgY2hhcnRlciwgZXZlbiBpZiAiVGFraW5nIGlucHV0IGFuZCBkaXNjdXNzaW5n
IGlzc3Vlc+KAnSBpcyBub3QgdGhhdCB3ZWxsLWRlZmluZWQgYW4gYWN0aXZpdHkuDQo+IEl0IGlz
IG5vdCBjbGVhciB0byBtZSB3aGV0aGVyIHdvcmtpbmcgb24gdGhpcyBpbiB0aGUgV0cgd291bGQg
Z2l2ZSB0aGUgZG9jdW1lbnQgYSBuZXcgc3BpbiwgYmV5b25kIGl0cyBjdXJyZW50IGFwcHJvYWNo
IGFzIGEgc3VydmV5LCBhbmQgd2hldGhlciB0aGF0IHdvdWxkIGFjdHVhbGx5IGJlIGEgd2VsY29t
ZSBjaGFuZ2UgdG8gdGhlIGF1dGhvcnMgYW5kIGNvbnN1bWVycyBvZiB0aGF0IGRvY3VtZW50Lg0K
PiBJbnB1dCBmcm9tIFdHIG1lbWJlcnMgYW5kIGxlYWRlcnNoaXAgY291bGQgaGVscCB1bmRlcnN0
YW5kIHRoaXMuDQoNClNwZWFraW5nIGZvciBteXNlbGY6IEkgZmVlbCB0aGF0IHN1Y2ggYSBzdXJ2
ZXkgZG9jdW1lbnQgaXMgYmV0dGVyLXN1aXRlZCANCmZvciBhIHJlc2VhcmNoIGdyb3VwIChSRykg
cmF0aGVyIHRoYW4gYSB3b3JraW5nIGdyb3VwIChXRykuIEl0IHdvdWxkIGJlIA0KaW4gbGluZSB3
aXRoIHRoZSBwcmV2aW91cyBzZWN1cml0eSBkb2N1bWVudCBmcm9tIFQyVFJHOiAiSW50ZXJuZXQg
b2YgDQpUaGluZ3MgKElvVCkgU2VjdXJpdHk6IFN0YXRlIG9mIHRoZSBBcnQgYW5kIENoYWxsZW5n
ZXMiIA0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NTc2KS4gSSBhbSBub3QgZnVu
ZGFtZW50YWxseSBvcHBvc2VkIHRvIA0KcHVyc3VpbmcgdGhpcyBpbiBJb1RvcHMgYnV0IEkgZmVl
bCB0aGF0IHBlcmhhcHMgYW4gZXZvbHV0aW9uIG9mIHRoaXMgDQpkb2N1bWVudCAoQ2Fyc3RlbiB3
cml0ZXMgYWJvdXQgYSBuZXcgc3BpbikgaW4gdGhlIG5lYXIgZnV0dXJlIHdvdWxkIGJlIA0KbW9y
ZSBzdWl0YWJsZSBmb3IgSW9Ub3BzLiBJIGFtIG9mIGNvdXJzZSBpbnRlcmVzdGVkIGluIGNvbnRy
aWJ1dGluZyB0byANCnRoYXQgcG90ZW50aWFsIGZ1dHVyZSBkb2N1bWVudCBhcyB3ZWxsLg0KDQot
LU1vaGl0DQoNCj4NCj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPg0K