- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 20 Sep 2021 20:00:27 +0900
- To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at: https://www.w3.org/2021/07/26-wot-sec-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] https://www.w3.org/ WoT Security 26 July 2021 [2]Agenda. [3]IRC log. [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#26_July_2021 [3] https://www.w3.org/2021/07/26-wot-sec-irc Attendees Present Kaz_Ashimura, Michael_McCool, Oliver_Pfaff, Philipp_Blum, Tomoaki_Mizushima Regrets Elena_Reshetova Chair McCool Scribe kaz Contents 1. [4]Minutes 2. [5]Meeting schedule in August 3. [6]Best Practices 1. [7]Issue 13 Meeting minutes Minutes [8]July-19 [8] https://www.w3.org/2021/07/19-wot-sec-minutes.html McCool: any objections? (none; approved) Meeting schedule in August McCool: vacation in August … starting with the next week … and cancel all the Security call in August (Aug 2-23 Security meetings will be cancelled) Best Practices Issue 13 [9]PR 20 - Cleanup [9] https://github.com/w3c/wot-security-best-practices/pull/20 [10]PR 19 - Add Ed Note to Object Security [10] https://github.com/w3c/wot-security-best-practices/pull/19 [11]PR 21 - Add local TLS/DTLS security via Raw Public Keys [11] https://github.com/w3c/wot-security-best-practices/pull/21 McCool: some clean up PRs as above [12]Issue 13 - Update Secure Local Transport [12] https://github.com/w3c/wot-security-best-practices/issues/13 McCool: how to generate a PR for that? Oliver: a bit different form of secure transport McCool: would like to mention some proxy as well … (adds comments to Issue 13) … expectations around mutual authentication, etc. … would be useful to distinguish "key distribution" from "secure transport" … but we have to decide where certain parts go, e.g., mutual authentication … also question of managing permissions Oliver: would look into the NETCONF RFCs … 6241 [13]RFC6241 [13] https://datatracker.ietf.org/doc/html/rfc6241 [14]more specifically, section 2.2 [14] https://datatracker.ietf.org/doc/html/rfc6241#section-2.2 Oliver: talks about authentication … meant for network configuration, not specifically for Web … there is also RESTCONF [15]RFC8040 [15] https://datatracker.ietf.org/doc/html/rfc8040 McCool: anonymous service for IoT Oliver: you'd like to learn NETCONF for encryption, etc. … similar constraints like the ones we have McCool: original intent of Philipp was to support a secure PKS key distribution … typically we see the key during the onboarding process … would assume something like OAuth for tokens … some kind of mechanism for people to access multiple devices … but how do you know who to generate the token, and how to get it? Philipp: also what kind of clients are available … core issue here is how to distribute the keys McCool: yeah … want to be able to target the problem of a larg number of users and devices … also being able to manage different/dynamic permissions for different users … want to avoid configuration for each device every time … we should look into standards on key distribution … or at least de-facto mechanism … are there an existing best practices? … CA is one such system but requries that servers have a public URL … LDAP is another possibility but that is just a distributed directory; CAN hod keys Oliver: LDAP is basically a directory and doesn't handle security itself … but you can run LDAP over TLS McCool: what we want to do is not recommending something new but unusual <citrullin> [16]https://datatracker.ietf.org/doc/html/ rfc7250#section-1 [16] https://datatracker.ietf.org/doc/html/rfc7250#section-1 McCool: we'd like to see the existing best practices … what do people actually use? … (found a research paper about key management) [17]Towards Formally Verified Key Management for Industrial Control Systems [17] https://dl.acm.org/doi/10.1145/3372020.3391555 McCool: probably should define some terms … and then some suitable options for different "modules" … e.g., for secure transport and for key distribution … problem with TLS 1.2 is can't use raw public keys... Oliver: raw public key was available before. will check the specification again McCool: use cases for browsers … accessing public URLs … relate to how we deal with proxies, tunnels, etc. … also reverse/forward proxies <citrullin> [18]https://success.qualys.com/discussions/s/ question/0D52L00004TnvRc/ using-raw-public-keys-in-transport-layer-security-tls-and-datag ram-transport-layer-security-dtls [18] https://success.qualys.com/discussions/s/question/0D52L00004TnvRc/using-raw-public-keys-in-transport-layer-security-tls-and-datagram-transport-layer-security-dtls <citrullin> [19]https://bugzilla.mozilla.org/ show_bug.cgi?id=1050175 [19] https://bugzilla.mozilla.org/show_bug.cgi?id=1050175 McCool: perhaps we simply say "if you want to access a system though a browser, nee to access system via a public URL secured by a certificate." … then we simply have to discuss the privacy implications [20]McCool's comments [20] https://github.com/w3c/wot-security-best-practices/issues/13#issuecomment-886673831 Philipp: gave some resources above … the first link above is about Using Raw Public Keys in TLS and DTLS (which mentions Firefox nightly supports client side TLS 1.3 McCool: (adds another comment to Issue 13) … some browsers may support import of raw public keys and/or integration with PS systems … if one exists, then we can give this as an option in environments where putting public URLs for access devices is not desirable. [adjourned] Minutes manually created (not a transcript), formatted by [21]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC). [21] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 20 September 2021 11:00:37 UTC