search-doc.json

[{"title":"Hello","type":0,"sectionRef":"#","url":"blog/hello-world","content":"Welcome to this blog. This blog is created with Docusaurus 2 alpha.This is a test post.A whole bunch of other information."},{"title":"Hola","type":0,"sectionRef":"#","url":"blog/hola","content":"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet"},{"title":"Welcome","type":0,"sectionRef":"#","url":"blog/welcome","content":"Blog features are powered by the blog plugin. Simply add files to the blog directory. It supports tags as well!Delete the whole directory if you don't want the blog features. As simple as that!"},{"title":"Style GuideH1 - Create the best documentation#","type":0,"sectionRef":"#","url":"docs/","content":""},{"title":"Markdown Syntax","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#markdown-syntax","content":"To serve as an example page when styling markdown based Docusaurus sites. "},{"title":"Headers","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#headers","content":"H1 - Create the best documentation# "},{"title":"H2 - Create the best documentation","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#h2---create-the-best-documentation","content":""},{"title":"Emphasis","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#emphasis","content":"Emphasis, aka italics, with asterisks or underscores. Strong emphasis, aka bold, with asterisks or underscores. Combined emphasis with asterisks and underscores. Strikethrough uses two tildes. Scratch this.  "},{"title":"Lists","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#lists","content":"First ordered list itemAnother itemUnordered sub-list.Actual numbers don't matter, just that it's a numberOrdered sub-listAnd another item. Unordered list can use asterisks Or minuses Or pluses  "},{"title":"Links","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#links","content":"I'm an inline-style link I'm an inline-style link with title I'm a reference-style link I'm a relative reference to a repository file You can use numbers for reference-style link definitions Or leave it empty and use the link text itself. URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or http://www.example.com/ and sometimes example.com (but not on GitHub, for example). Some text to show that the reference links can follow later.  "},{"title":"Images","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#images","content":"Here's our logo (hover to see the title text): Inline-style:  Reference-style:  "},{"title":"Code","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#code","content":"Copyconst s = 'JavaScript syntax highlighting';alert(s); Copys = \"Python syntax highlighting\"print(s) CopyNo language indicated, so no syntax highlighting.But let's throw in a <b>tag</b>. Copyfunction highlightMe() { console.log('This line can be highlighted!');}  "},{"title":"Tables","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#tables","content":"Colons can be used to align columns.  Tables Are Cool col 3 is right-aligned \\$1600 col 2 is centered \\$12 zebra stripes are neat \\$1  There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.  Markdown Less Pretty Still renders nicely 1 2 3   "},{"title":"Blockquotes","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#blockquotes","content":"Blockquotes are very handy in email to emulate reply text. This line is part of the same quote. Quote break. This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.  "},{"title":"Inline HTML","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#inline-html","content":"Definition listIs something people use sometimes.Markdown in HTMLDoes *not* work **very** well. Use HTML tags.  "},{"title":"Line Breaks","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#line-breaks","content":"Here's a line for us to start with. This line is separated from the one above by two newlines, so it will be a separate paragraph. This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.  "},{"title":"Admonitions","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#admonitions","content":"noteThis is a note tipThis is a tip importantThis is important cautionThis is a caution warningThis is a warning "},{"title":"H3 - Create the best documentation","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#h3---create-the-best-documentation","content":"H4 - Create the best documentation# H5 - Create the best documentation# H6 - Create the best documentation#  "},{"title":"Mermaid Images","type":1,"pageTitle":"Style GuideH1 - Create the best documentation#","url":"docs/#mermaid-images","content":"You can use mermaid if you put remark-mermaid-dataurl under remarkPlugins in your docusaurus.config.js file:   "},{"title":"Gateway issued certificate","type":0,"sectionRef":"#","url":"docs/10-gateway-solution","content":"Name: defined by user (or other ?)Certificate issue: issued by local gatewayName resolution: could be implemented in gatewayCertificate validation : needs new method in browser ??In the Device DNS Name method, a method is defined forGiving each IOT device a unique resolvable name, which works with existing DNS methodsIssuing a unique certificate to each device, using the same common name issued in (1) and makes user of existing Certificate Authorities (CAs), recognised by the CA/Browser ForumIn Device DNS Name method globally resolvable DNS servers must be used, and globally accessible certificate authorities must be used, in order to preserve compatibility with the existing internet security infrastructure.An alternative approach, is to consider the use of a user owned, locally hosted gateway device to assist with either or both problems of name resolution and certificate issuer.These approaches would have the advantage of:being locally resolvable: will work with no access to global intranetreduce infrastructure requirement: this approach limits the amount of server resident infrastructure that needs to be created and supportedincrease end user control: the end users has more autonomy, both in terms of physical hosting of equipment, and reducing the dependency on manufacturer, or manufacture assisted resources for the ongoing operation of their deviceThe disadvantages are:local only resolution: the system can be easily made to work within the local environment, but more work would be required to ensure that the name resolution and security attestation can operate over a global internet linkhardware device security dependency: the gateway in this scenario has privileged access to the private signing keys, used in the certificate issuance. This changes the attack surface.it will require browser changesNA: describe a method like Device DNS Name but differences are:the gateway issues the cert not the bound domain (the bound domain is actually implicitly local)the gateway provides an \"alternative\" name lookup service (complementing DNS)"},{"title":"Application issued certificate","type":0,"sectionRef":"#","url":"docs/11-application-solution","content":"Name: defined by userCertificate issue: issued by application (or cloud service)Name resolution: needs new method in browser ??Certificate validation : needs new method in browserAn alternative to the gateway issued certificate, is to look at environments where a locally hosted application (e.g. a mobile application) will issue the certificates.Nick: more work to be done hereDescribe a method which uses a local application as CAthis is close to the matter solutionwould also require an additional name lookup service"},{"title":"Solution Overview","type":0,"sectionRef":"#","url":"docs/1b-solution-overview","content":"This document describes the building blocks for potential solutions. The purpose is to describe current practices and spark ideas on how they can be applied in a different context. Some solutions may prove impractical, while other solutions involve working with standardisation bodies to amend or extend existing standards. Unfortunately there is no easy fix.Compartmentalize the IOT network e.g. place them in dedicated VLAN's so they can only communicate through predefined paths.Ask browser vendors to treat certificates for local ip addresses differently and at least change the warning message. Solution #1aCreate a dedicated IOT browser or mobile app to manage IOT devices through a generic interface. Solution #5Ask the CA/B Forum to adapt the rules for signing certificates Solution #1bCurrently a local domain for IOT, similar to .local used in mDNS, but for which certificates are allowed to be signed (like .onion)Setup a dedicated IOT domain name for which different certificate rules can applyLet local gateways sign certificates and let browsers trust this as an alternative root of trust. Solution #4Create a dedicated special purpose ROOT CA for IOT devices (learning from ISRG Letsenrypt and cacert.org)Create a domain infrastructure to give local devices a globally unique domain name. Solution #2 and #3Create an infrastructure for onboarding devices using 802.11AR Device ID's and the brski bootstrapping.Use special purpose TLS certificates by introducing a new extended key-usage field for IOT.Apart from patching a browser to generate a softer warning message, all the other solutions require interworking with other standardisation organisations or creating an elaborate infrastructure."},{"title":"Addressing background","type":0,"sectionRef":"#","url":"docs/2-addressing-background","content":""},{"title":"Addressing primer","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#addressing-primer","content":"The concept of a device end point name and its physical internet address are intimately intertwined with negotiated security. Current HTTPS security semantics rely on the fact that a public key is bound to the devices referenceable name. The TLS negotaion provides the client the necessary guarnatees that the server is in posession of the private key, which corresponds to the public key tied to the name, in the presented certificate. Let us define the following terms to help understand the solution space  Browser: the browser is an application used by a use to browser web content. Target device: the target device is the IOT device with the user is attempting to connect to (or configure) using the browser Name: the name (or device name) from the browsers perspective is the string typed into the browser address bar, which corresponds to the target deviceName resolution: the name resolution process is the method used by the browser to turn the name into an addressAddress: is the physical (IP) based address that can be used for routing packets to the target device  Building on these basic concepts, the following higher level concepts are also important  "},{"title":"IP Addressing and Network","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#ip-addressing-and-network","content":"Concerning the device address: Local network addresses have identifiers that are distinguishable from public internet addresses. These IP addresses will be locally significant only. They can only be reached if traffic towards global addresses forward the traffic. These addresses are reserved as link local, private use or are shared and are not globally unique. They are listed as Special-Purpose IP Address Registries https://datatracker.ietf.org/doc/html/rfc6890  Purpose IP Range Private-use 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Link Local 169.254.0.0/16 Shared Address Space 100.64.0.0/10 Unique Local fc00::/7 Linked-Scoped Unicast fe80::/10  Browsers can distinguish between publicly routed internet addresses and private-use or link local addresses. When a browser negotiates a TLS session with a server, the browser can detect that the server is reachable through a special purpose IP address. The certificate warning displayed to the user can be different in this instance, because the context is local and not on the global internet. Firefox has a method hostnameIsLocalIPAddress to check if an IP address is local or not [nsIIOService.idl - mozsearch] https://searchfox.org/mozilla-central/source/netwerk/base/nsIIOService.idl#201 tipThe resolved IP address of the target device, is a critical part of current security decision making, in browsers  note, tip, important , caution , warning  "},{"title":"Network Segmentation","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#network-segmentation","content":"Network segregation is generally good security practice. At a crude level the distinction between private use address(192.168.0.0/16) and global IP addresses is a form of segmentation.  A dedicated IOT network using a private VLAN could create a separate communication channel for device management isolated from other network traffic. A browser and gateway would have a method to identify IoT devices and \"perform differently\". A private VLAN dedicated to IoT could for instance be set to 2107. https://datatracker.ietf.org/doc/html/rfc5517 However currently browsers are not considering the VLAN network they are operating in and it would require a significant standardisation effort to change the current networking practices to protect IoT network traffic. tipInternal network subnets, could be used to segment or separate out clusters of devices. These clusters of physical addresses could be used as part of the browsers security decision making process "},{"title":"(DNS) Domain name resolution","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#dns-domain-name-resolution","content":"In a local network there is often no registered and resolvable DNS domain name, especially for devices that are not supposed to be directly connected to the internet. The local device addressing method is important for two reasons. Firstly, traditional HTTPS certificates are essentially cryptographic bindings between a common name (and address) and a public key. Secondly, the discoverability and usability of the local address will directly impact the user experience. TLS certificates are valid for the identifier presented in the common name or subject alternative name. The most common identifier is a DNS name, but also public IP addresses are allowed. Root CAs are not allowed to sign certificates if these identifiers use internal names. The domain name must be registered and resolvable. https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf The naming mechanism is important also because the current browser standard is DNS resolution. The interaction of DNS resolution, proof of DNS ownership and certificate issuance are all intimately intertwined. Solutions therefore will fall into two broad categories: Methods restricted to current standard DNS address resolution semantics.Methods that introduce new addressing mechanisms. These solutions offer more room for innovation, but necessarily will require deeper changes to the browser. tipThe DNS name resolution process is an integral part of current TLS session negotiation. A new security model for browser/IOT interaction, either needs to fit into the current DNS model or replace the name resolution with another mechanism "},{"title":"Unique names and address binding","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#unique-names-and-address-binding","content":"Each device can be given an unique name. For example the hash of self generated public key of a device, can often be used to name a device with relatively strong guarantees of uniqueness. For this name to be useful, however it must be resolvable. For this name to be resolvable over the internet, the unique device name will have to be combined with the address of a parent domain, to create a compound name. Where DNS is being used as the name resolution process, we can construct the compound name in a device binding event.  There are a number of potential provides of parent (bound) domains  A private person could acquire a personal domainThe network provider could dedicate a subdomain to the users.A device vendor can create a subdomain for its devicesAn authority can setup a domain name dedicated for devices. Delete: A certificate binds a domain to a public key. The user has to store the private key in a safe place. A secure element like a smart card, TPM or HSM. The users requires a domain for certificates. A domain could be provided by one or more of the following entities: Private persons may not have the interest or technical capabilities to operate a domain. It could be made easier if domain and certificate management would be integrated in a home gateway, network storage devices On the other hand device manufactures may have a limited timespan in which they are interested in operating an infrastructure for their devices. An authority similar to how ISRG governs Letsencrypt could operate a device dedicated domain. Since it is in the public interest, this would deserve to be government funded by participating nations or unions. There are many options Clearly, the definition of this process has profound impact on the commercial ecosystem to be developed. It is therefore important that the solution proposed does not lock us into one operating economic model  Where a traditional certificate is being used, this process is essential as the derived compound name becomes the common name of the device to which the certificate must be issued. Hence, name construction must happen before certificate issuance.  tipBinding the device and provisioning it with a globally resolvable DNS name, is a real world (economic) event, which also impacts the construction of certificates (is that is the method being used) "},{"title":"Multicast DNS","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#multicast-dns","content":"On the internal network (private IP address space) a different name resolution mechanism can be used.  Common practice is to address devices by a private IP address, which some devices advertise through Multicast DNS. This makes the devices discoverable, but it does not make them uniquely identifiable. Multicast allows a device to advertise itself on the network and to be reached with a common name. mDNS uses the domain suffix .local (IETF RFC6762) and IPv6 has a link-local scope and unique local address range fe80::/64. These addresses are often on the same physical ethernet link. It is possible for a browser to identity the local context. For local connections a different error message can be displayed. https://datatracker.ietf.org/doc/html/rfc6762 CA/Browser Forum does not allow for the .local suffix to be signed. tipMulticast DNS can be used as an alternative local name resolution method. However some networks disable it so it cannot be assumed to always there "},{"title":"Link Address","type":1,"pageTitle":"Addressing background","url":"docs/2-addressing-background#link-address","content":"Most devices already have a unique identifier like a MAC address for ethernet, Wi-Fi or Bluetooth. The MAC address is a link level address in a network. Currently the MAC address is not typically used in the negotiation of security between client and server. However, there is a clear opportunity to introduce such concepts. The Organizational Unique Identifier which is part of the full address, conveys meaningful information about the original manufacturer. There are use cases where this information can be useful in establishing security credentials. MAC addresses however can be modified and spoofed in most circumstances. It's possible for the browser to identify that a resource is on the same physical link, however many devices are not on the same physical link and will be connected through routers, access points or switches. The link local address in IPv6 may be derived from the MAC address. X.509 certificates used in TLS require a verifiable public IP address or a public DNS name. Other X.509 based schemes exist that certify other layers in the network stack. tipThe link level address of the target device and/or security artefacts (e.g. certificates) attached to the link level address could be used as part of the security, decision making process "},{"title":"Browser background","type":0,"sectionRef":"#","url":"docs/3-browser-background","content":""},{"title":"Changing browser behaviour","type":1,"pageTitle":"Browser background","url":"docs/3-browser-background#changing-browser-behaviour","content":"An alternative and/or complementary solution could be the development of a dedicated IoT browser, which would be independent from the CAB Forum infrastructure. This would leave the internet certificates unaffected and would introduce similar certificate processing semantics for the IoT use case. Vendors often offer mobile apps because they implement their own certificate validation independent of the Root CAs. This approach requires an application for every device or service. A dedicated IoT application can bundle these services for a simplified user experience. It requires different user behaviour. The user will have to explicitly download and use a new class of browser in order to benefit from these new features.Needs to be designed from the ground up. "},{"title":"Lobbied browser changes","type":1,"pageTitle":"Browser background","url":"docs/3-browser-background#lobbied-browser-changes","content":"Move to solutions Lobbying for browser changes addresses some of the drawbacks above; the user can benefit from a differentiated UI, better local device addressing and resilient local behaviours. And these benefits are experienced across existing and future browsers. The drawbacks are however: Time: it will take time to lobby the CA/Browser forum and longer for any changes to propagate into available browser implementations.Indeterminacy: there is no guarantee any such lobbing will be successful. "},{"title":"No browser changes","type":1,"pageTitle":"Browser background","url":"docs/3-browser-background#no-browser-changes","content":"Move as intro to Solution 2/3 DNS Device Name Solutions which require no change to existing browser behaviour are desirable because these have minimal impact on the end user. Drawbacks to this class of solution include: The user cannot easily distinguish between local connections and internet connections (that would require UI changes to the browser). This is potentially significant to the security semantics of IoT end point devices.Because Multicast DNS does not always work reliably, additional infrastructure would be needed to locally address an endpoint device. This means any solution which has no change to the browser will have at least a partial dependency on DNS resolution, at least in the bootstrap binding phase. "},{"title":"Request Browsers to use softer warnings","type":1,"pageTitle":"Browser background","url":"docs/3-browser-background#request-browsers-to-use-softer-warnings","content":"Move to solutions A friendlier user experience would be to request browser vendors to distinguish between certificates served on local network versus self-signed, invalid or revoked certificates on the internet. Currently the message is: \"Attackers might be trying to steal your information (for example, passwords, messages, or credit cards)\" Instead browsers could display a message on how the validity can not be checked for local networks, for instance. \"This service is on the local network and the certificate can not be verified.\" With a single click option to abort or continue, it would give users the opportunity to identify the device they are connecting to. This does not introduce trust in private networks, but does make device management webservices more intuitive for common users. After the initial warning, the browser will connect to the end-point device over an encrypted TLS session. When browsing HTTPS sites on the public internet, most browsers adopt the convention of displaying a \"padlock\", next to the address. For this scenario where the user is browsing a local resource and where the certificate security semantics are subtly different, an alternative but consistent UI metaphor should be considered. "},{"title":"Propose CA/Browser Forum Amendment","type":1,"pageTitle":"Browser background","url":"docs/3-browser-background#propose-cabrowser-forum-amendment","content":"Move to solutions Currently CAs are not allowed to sign certificates for internal names https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf 7.1.4.2.1. Subject Alternative Name ExtensionCertificate Field: extensions:subjectAltName Required/Optional: Required Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully‐Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right‐most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines. CA/Browser Forum accepts or rejects change proposals with a ballot. It would be possible to propose a modification on 7.1.4.2.1 to allow signing of internal names in specific cases. Because CA/Browser Forum guards the trust in the certificate store, changes are not accepted lightly. Only changes that will not jeopardise trust are likely to be considered and accepted. It would require strict rules under which a local certificate could be signed by a Root CA. Similar to the \"softer warnings scenario\", where the user is browsing a local resource and the certificate security semantics are subtly different, an alternative but consistent UI metaphor should be considered. Possible options might be: Device icon: indicating to the user they are browsing a local device resource.Different colour: change the colour of either/both the icon and the address.Address differentiation: emphasise the differentiation of the address format, using syntax, prepends or colour.Chrome changes: make a wholesale change to the browser chrome (UI outside the HTML render) to indicate we are browsing a local resource. "},{"title":"Certificate background","type":0,"sectionRef":"#","url":"docs/4-certificate-background","content":""},{"title":"Non TLS based security","type":1,"pageTitle":"Certificate background","url":"docs/4-certificate-background#non-tls-based-security","content":"TLS enables encryption on the session layer, but it's possible to provide encryption for different protocols or in a different layer. If the device is in possession of a public private key pair, the device may sign one or more tokens, relating to the status of the devices. In addition the device may be in possession of tokens signed by externally recognised authorities, that containing the devices public key, which also express key information relating to the status of the device. The only real difference here relates to the expression of the claim. For example these claims could be rendered as JWT's, CBOR Object Signing and Encryption and Verified Credentials. ?? This method would require changes to the TLS stack, to accommodate these new credentials as part of the authorisation negotiation. ?? "},{"title":"Existing TLS certificate practices","type":1,"pageTitle":"Certificate background","url":"docs/4-certificate-background#existing-tls-certificate-practices","content":"Certificates are currently being used for deployed IOT devices. Many gateways and IoT devices host a both a HTTP and a HTTPS webserver for device onboarding and device management purposes. Users are most often directed to the HTTP administrative web server for the following reasons: The aggressive security warnings disconcert users, leading to support calls.Many browsers make it quite difficult to \"click through\" past the warning to the \"insecure\" destination web page. A solution that embraces the use of well-formed X.509 certificates will have to be combined with new browser behaviours (above section) if it is to be useful. "},{"title":"Alternative Root of Trust","type":1,"pageTitle":"Certificate background","url":"docs/4-certificate-background#alternative-root-of-trust","content":"Solution To solve the problem of establishing a trusted secure connection between a browser and a locally hosted web server, we could look outside of traditional TLS certificate semantics and use alternative methods to negotiate a secure TLS session and represent the results of this negotiation. There are multiple sources of such information from which security could be established. Some of these methods could work in isolation, others can be combined. Each of these methods could complement, or replace the existing root of trust negotiation method. The results of this security negotiation could be manifest in a classic X.509 certificate, in which case we may make use of Extended Key Usage (see below), it could be made manifest in a more complex key signing hierarchies (with multiple additional root of trust) , or it could be made manifest in non certificate based representation (see below). "},{"title":"IoT Certificate Key Usage","type":1,"pageTitle":"Certificate background","url":"docs/4-certificate-background#iot-certificate-key-usage","content":"Certificates have the parameter fields Key Usage and Extended Key Usage. These parameters describe the purpose of the certificate. For certificates used on the internet the extended key usage is set to server authentication (id-kp 1): https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3 The key usage parameters of a normal certificate are typically Digital Signature, Key Encipherment and Client and Server Authentication. Other extended key usages are for client authentication, code signing, email protection and timestamping. A new extended key usage dedicated to IoT could create a certificate class which would be allowed to be signed by a certification authority, vendor or any other authority. Browsers would be able to distinguish the certificate to be of local significance only. id-kp 10 could be assigned as Local Device. Since this is different than a normal Server Authentication certificate the browser can check that the connection is local and the certificate is signed by a device vendor or IoT authority (FIDO, Matter, CACERT) that acts as root for these certificates. "},{"title":"Certificate Semantics and Security Bootstrap","type":1,"pageTitle":"Certificate background","url":"docs/4-certificate-background#certificate-semantics-and-security-bootstrap","content":"When the browser connects to the gateway or end point device over HTTPS, the characteristics of the security established are determined by both the characteristics of the certificate being used, and the mechanism by which the certificate was provisioned on the device. (Viable methods of revocation are also relevant). In order to fully understand the qualities of the various solutions, it is worth outlining different options: 0. No certificate# In the simplest case there is no certificate and the website is hosted unencrypted This method is the defector standard. It should be strongly discouraged. It fails to implement zero trust principles. It leaves critical information, in particular passwords, in the clear. 1. Non device unique - self-signed certificate# In this scenario the exact same certificate is burned into \"all devices\" of this class. The certificate subject common name is the same as the issuer common name. The certificate is signed by itself. The common name can be arbitrary. This method will generate browser errors under CA/Browser forum current guidelines. This method is actively being used by some device manufacturers. This method should be discouraged. 2. Non device unique - untrusted root-signed certificate# In this scenario the exact same certificate is burned into \"all devices\" of this class. The certificate is signed by an untrusted root. By untrusted we mean the signing authority does not correspond to any authority recognised by convention in most web browsers 3. Device unique - self-signed certificate# In this scenario a public/private key pair is generated unique to this device. This key pair could be generated in the factory, or during device initialisation. The common name could be Arbitrary text: e.g. \"pre-set certificate\".MAC address: presumably unique to this device, but meaningless in current browser-based certificate check.Unique device address: e.g. GUID. This class of certificate is self-signed This method will fail the certificate verification under current CA/Browser Forum guidelines and would generate browser errors, unless an exception is accepted for the certificate. Both these methods 2 and 3 are in use today on real deployed devices. This method generates strong warnings on current browsers. These warnings could be made more usable with browser changes. These methods introduce a weakness, that that compromised private key credentials taken from the device mean that it is very easy to \"spoof\" a manufacture end point device. These methods should be discouraged. 4. Device unique - untrusted root-signed certificate# This scenario is like scenario 2, but instead of self-signing the certificate, it is signed by an untrusted root. It is the same as scenario 5, but the root certificate is not pre-approved in the browser. 5. Device unique - locally-signed certificate# In this method a certificate is signed by binding a unique device common name to a unique public key for this end point device. This certificate is signed by a local entity, for example a mobile application or a gateway hosted signing service. For this method to work: A CSR must be generated as part of a one-off binding event.The CSR must be issued to and processed by the local service.The end point address used in the CSR, must resolve locally. This method requires all the browsers on all the systems to add the gateway certificate that has signed all the local certificates. This requires the certificates to remain local. This may cause problems when internet servers start serving local certificates, but the common name would not match the certificate. These methods are all slight variants of one another. They improve on 1&2 in that the impact of private key compromise is limited. The private key per device could be implemented at different points in the lifecycle. Browser changes are required to unpack the certificate and establish a qualified measure of trust from the signatures, and any a priority trust base provisioned into the modified browser. These use facing impacts of this trust base will need to be presented to the user. Many of the solutions below, are examples of this solution 6. Device unique - CA root signed certificate# In this method a certificate is signed binding a unique device common name, to a unique public key on this end point device. This certificate is signed by one of the trusted roots that the browsers use. For this method to work: A CSR must be generated as part of a one-off binding event.The CSR must be issued to and signed by one of the Root CAs.The common name used in the CSR must be publicly DNS resolvable, at least for the duration of the signing. This method can be used without generating any browser security warnings. It is the method used by the flexible names Device DNS Name solution. Device DNS Name provides a description of how we may achieve this method. This is still under investigation. "},{"title":"Browser integrationMethod 1 - Change browser behaviour#","type":0,"sectionRef":"#","url":"docs/7-browser-solution","content":"Method 1 - Change browser behaviour#In this method we change the browser behaviour so that it does not issue the warningsThis method should clearly define exactly how teh browser should behave when it sees differeent certificate typesRefer to the certificate type list#0: No certificate should carry strong warning1,2: Non device unique certificats should also carry strong warning - but different from above6 is unique can can only be generated by the DNS methods.For all the other cert types [3..5] there should be a strong recommendation on the \"extended key usage type\"There should be a recommended decision tree to determingwhat warnings are given andWhen warnigns are givenEvery one of the other methods described in the list is essentially a different proposal for how the certificate gets provisioned on the device.Which has implications for how the name resolutin process must workEach of the methods should clearly outline the lifecyle and revocation proposals"},{"title":"DNS Based Device Name - Embedded physical address","type":0,"sectionRef":"#","url":"docs/8-dnsname-embedded-solution","content":""},{"title":"Name syntax","type":1,"pageTitle":"DNS Based Device Name - Embedded physical address","url":"docs/8-dnsname-embedded-solution#name-syntax","content":"The BNF syntax represetning such a name is as follows Copy<local-name> ::= <local-address> \".\" <dev-id> \".\" <bound-domain> // local address is IPV6 ULA or IP4 Private network address<local-address> ::= {fc00::/7} |{172.16.0.0/12} | {10.0.0.0/8} | {192.168.0.0/16} // dev-id is hash of device public key <dev-id> ::= {} // bound-domain is a publicly resolvable domain name, with which the device is provisioned<bound-domain> ::= {}  This produces example device names of the form https://c0a80001.f0ocrypto1d.devices.vendor.example Where in this instance c0a80001- is the physical address of the devicef0ocrypto1d- is the device ID - or more specifically the hash of the public key for the devicedevices.vendor.example - is the bound domain - a publicly resolvable IP address "},{"title":"Name provisioning","type":1,"pageTitle":"DNS Based Device Name - Embedded physical address","url":"docs/8-dnsname-embedded-solution#name-provisioning","content":"For the above method to work, there needs to be a provisioning event, where the the <dev-id> is bound to the <bound-domain> The pre-condition therefore is that a device is pre-provisioned with a bound domain. Nick :Question: could a device have multiple bound domainse.g.: original manufacturer, redundant resolver, distributor and or intermediary There are a number of scenarios to consider: Manufacturer provisioning: the device is provisioned in factory within the administrative domain of the original manufacturer.Service provider provisioning: the device is provisioned before point of sale within the administrative domain of the service provide (for example an ISPs address).Intermediate provider provisioning: the device is provisioned any point in the cycle with a manufacturer/service provider independent domain (for example a CA).User defined provisioning: the device is provisioned past point of sale within a home domain defined by the end user. In order to assure continued functioning of a device in the situtation where the manufacturer or server provider no longer operates the bound domain service, we should encourage models which allow for simple user provisioning or back-up provisioning flows. In the examples that follow we will use devices.vendor.example as a concrete instance of bound domain. Assuming the bound-domain has been pre-provisioned, in order to make use of the \"Device DNS Name\" solution, the IoT device must undergo a one-off onboarding provisioning flow.  Security considerationsIn this provisioning flow, steps 3 and 4 need to be protected. The DNS server being used to resolve the address and the CA processor which mediates the certificate request need to be protected against spoofed or non-permissioned provisioning requests "},{"title":"Name resolution","type":1,"pageTitle":"DNS Based Device Name - Embedded physical address","url":"docs/8-dnsname-embedded-solution#name-resolution","content":"The operational flow is trigged, every time the user initiates a browser session with the target IoT device. The user is expected to be in possession of the <local-name> (discovery) in order to initiate this process  "},{"title":"Name validation (security)","type":1,"pageTitle":"DNS Based Device Name - Embedded physical address","url":"docs/8-dnsname-embedded-solution#name-validation-security","content":"This method has the advantage that it can piggy back on top of existing HTTPS certificate semantics and certificate issuing methods. The issued certificates could make use of Key Usage and Extended Key Usage fields, so that local connections could be differentiated in the browser "},{"title":"Analysis","type":1,"pageTitle":"DNS Based Device Name - Embedded physical address","url":"docs/8-dnsname-embedded-solution#analysis","content":"DraftPLUS: uses existing certificate and DNS mechanimsPLUS: requires no change to browserNEGATIVE: rebind problem discovered in trial means it does not work on current routersNEGATIVE: requires manufacture to create new DNS services and CA servicesNEGATIVE: could bind device to manufacture Implementation notes#Link to SUIB-solution-cryptoname-detailsCurrent problems encountered in testingREBIND attack protection - means should not trust localDNSneed to sign DNS recordsrebinding protection limits the applicability of this approachDNS over HTTP avoids re-binding protection problemlimited IPV6 support Christian?: can you review and refresh the summary of current implementation issues "},{"title":"Implementation notes","type":1,"pageTitle":"DNS Based Device Name - Embedded physical address","url":"docs/8-dnsname-embedded-solution#implementation-notes","content":"Link to SUIB-solution-cryptoname-details Current problems encountered in testing REBIND attack protection - means should not trust localDNSneed to sign DNS recordsrebinding protection limits the applicability of this approachDNS over HTTP avoids re-binding protection problemlimited IPV6 support "},{"title":"DNS Based Device Name - Dynamic DNS resolution","type":0,"sectionRef":"#","url":"docs/9-dnsname-dynamic-solution","content":""},{"title":"Name syntax","type":1,"pageTitle":"DNS Based Device Name - Dynamic DNS resolution","url":"docs/9-dnsname-dynamic-solution#name-syntax","content":"The second flavour of locally resolvable name does not use an embedded physical address. This method must use some form of DynDNS for resolution: Copy<local-name> ::= <dev-id> \".\" <home-domain> // dev-id is hash of device public key <dev-id> ::= {} // bound-domain is a publicly resolvable domain name, with which the device is provisioned<bound-domain> ::= {} Alternatively, it can announce itself with the equivalent HTTP URI, and (once contacted by a browser that has Internet connectivity on its own, even though not necessarily simultaneously) utilizes the browser to obtain such a certificate. This needs no more cooperation from the browser than regular JavaScript execution and can result in a redirect to equivalent HTTPS URI and thus the green padlock moments later. This is likely achievable with current browsers. For an extended version that works even in fully offline situations, this can be adapted to a domain that promises to use the web service's policy. Some user stories, details and the first stubs of what can become a tech demo can be found at GitHub - chrysn/provisioning-demo. The provisioning flow for the DynDNS variant is almost identical. They only difference being is that the DNS registration and the Certificate request can be made using: [dev-id].devices.vendor.example instead of: *.[dev-id].devices.vendor.example In other words, it is not necessary to register the wildcard because we are not prepending the physical address to the device name. The provisioning can happen automatically when an unprovisioned device is connecting to the network. This would limit the used interaction for the first setup. "},{"title":"Name provisioning","type":1,"pageTitle":"DNS Based Device Name - Dynamic DNS resolution","url":"docs/9-dnsname-dynamic-solution#name-provisioning","content":"The operational flow is trigged, every time the user initiates a browser session with the target IoT device. The user is expected to be in possession of the in order to initiate this process.  whenever the physical address of the IOT device changes  "},{"title":"Name resolution","type":1,"pageTitle":"DNS Based Device Name - Dynamic DNS resolution","url":"docs/9-dnsname-dynamic-solution#name-resolution","content":"Device DNS Name : operational flow - DynDNS variant When using the DynDNS variant there are two parts to the operational flow: A flow initiated by the IoT device when the physical IP address changes (including the first time it is used).The flow initiated by the browser when connecting to the IOT device web server. DynDNS resolve# The DynDNS resolution method differs from the embedded local address; the DNS server uses the \"most recent\" physical address supplied by the DynDNS server instead of using the local address embedded within the device name.  "},{"title":"Name validation (security)","type":1,"pageTitle":"DNS Based Device Name - Dynamic DNS resolution","url":"docs/9-dnsname-dynamic-solution#name-validation-security","content":"This method has the advantage that it can piggy back on top of existing HTTPS certificate semantics and certificate issuing methods. The issued certificates could make use of Key Usage and Extended Key Usage fields, so that local connections could be differentiated in the browser "},{"title":"Analysis","type":1,"pageTitle":"DNS Based Device Name - Dynamic DNS resolution","url":"docs/9-dnsname-dynamic-solution#analysis","content":""},{"title":"SUIB-solutionsDevice Onboarding#Integration of external trust roots#7. Bringing it together#TODOs:#","type":0,"sectionRef":"#","url":"docs/SUIB-solutions","content":""},{"title":"Initial Device Identifier","type":1,"pageTitle":"SUIB-solutionsDevice Onboarding#Integration of external trust roots#7. Bringing it together#TODOs:#","url":"docs/SUIB-solutions#initial-device-identifier","content":"IEEE 802.1AR specifies a secure device identity. Manufacturers can embed an initial device identifier certificate to a device. The initial certificate (IDevID) typically has an infinite lifetime. It can validate the device is from the manufacturer. This can be used to enroll a certificate with a limited validity and with the domainname used within the network. https://1.ieee802.org/security/802-1ar/ BRSKI describes the bootstrapping process on how the IDevID certificate can be used for certificate enrollment (IETF EST). The manufacturer can operate a MASA to verify the certificate and the device is configured as part of the domain, so that it can sign a local context LDevID certificate. https://datatracker.ietf.org/doc/html/rfc8995/ For BRSKI to provision home devices with a valid certificate, they would need a globally unique address. Yet home devices normally do not have a domain. "},{"title":"FIDO Device Onboarding","type":1,"pageTitle":"SUIB-solutionsDevice Onboarding#Integration of external trust roots#7. Bringing it together#TODOs:#","url":"docs/SUIB-solutions#fido-device-onboarding","content":"https://fidoalliance.org/specs/FDO/fido-device-onboard-v1.0-ps-20210323/fido-device-onboard-v1.0-ps-20210323.html The FIDO alliance has defined a method of onboarding IoT devices. This onboarding process contains several pieces of information which could be used to negotiate a security session: Device Attestation Key: a unique key provisioned on the end point device. The device key is provisioned using the Device Key Provisioning with ECDSA process as an example Device credential: the Device Credential Persisted Type (non-normative) is a signed JSON/CBOR structure that contains key device metadata, in particular DCDeviceInfo which could be used in the bootstrapping of a secure session Question can we pull something form Ownership Voucher e.g. inital owner is manufacturer ?FDO mentions this on IETF Voucher Artifact differencesThe Ownership Voucher is distinct from the Voucher Artifact described in [RFC8366], although both are structured documents that convey trust. The Ownership Voucher here conveys trust through the supply chain from the manufacturer, being the original 'owner' of the Device, to the ultimate Owner who will use the Device in a production setting. The Voucher Artifact is a dynamically generated object which provides an endorsement of the Device from a trusted authority (the \"MASA\"). Question: FIDO device onboarding is managed with server-based rendezvous servers. But some of this info is still available even if FIDO oboarding as not completed as they are assumed pre-conditions To be of practical use the implementation of the device hosed web server would need access to the private attestation key, the device credential and any other information relevant eg ownership voucher.  The meaningful information could be encapsulated as X.509 certificate if using traditional HTTPS certificates. Or as signed tokens.  TODO: The exact format as use of fields for either X.509 or tokens need to be defined TODO: the preconditions within the browser and the semantics of establishing root of trust needs to be defined.  "},{"title":"MATTER Onboarding","type":1,"pageTitle":"SUIB-solutionsDevice Onboarding#Integration of external trust roots#7. Bringing it together#TODOs:#","url":"docs/SUIB-solutions#matter-onboarding","content":"The emerging MATTER standard being created under the Connectivity Standards Alliance is also creating device management and user provisioning protocols, where cryptographic primitives are persisted as a result of various manufacturer and device onboarding activities. The standard is not yet public, but we can expect similar components to those we see in the FIDO onboarding flows. Nick: flow is similar to above but uses matter keys and credentials   TODO: the root of trust semantics might be partly addressed by the MATTER approach to root of trust  "},{"title":"MUD Credentials","type":1,"pageTitle":"SUIB-solutionsDevice Onboarding#Integration of external trust roots#7. Bringing it together#TODOs:#","url":"docs/SUIB-solutions#mud-credentials","content":"The MUD specification does have security relevant information that could be used in the bootstrapping of a trusted TLS connection between browser and IOT device, specifically information on manufacture and device type. This information can be securely resolved form the MUD document.  However as it stands the MUD specification does not directly address the issue if device based client private keys, excepting the reference to IEEE 802.1AR 7. Bringing it together# The enable local encryption there are three aspects that need to be addressed. The local network needs a reliable way to identify that the device really came from the vendor, the network needs a reliable way to name a device and the browser needs to have a trust anchor that trusts these devices. In the current situation, the ingredients exist to create a solution that will satisfy the local trust, but there is no consistent coherent way which will work every time for everyone in every situation. It will require consensus building to achieve a reliable trust chain. Changes in the browser, certificate signing process or infrastructure to support domains can solve this issue, but it requires significant standardisation and organisation. "},{"title":"Nicks List","type":1,"pageTitle":"SUIB-solutionsDevice Onboarding#Integration of external trust roots#7. Bringing it together#TODOs:#","url":"docs/SUIB-solutions#nicks-list","content":"Naming of devices: outline the different methods/syntax we might have for naming devices : course grained#pubkey + bound domainFriendly name + bound domainWhere bound domain could beManufacturer allocated domain = devices.manufacturer.comEnd user allocated domain = nick.allott.com Other…Name resolution: list out the different name resolver methodsDNS basedEmbedded physical addressDynDNSmDNSOther…. Non DNS methodsCertificate usage – trust framework List out the current ways certificates are used – outlining pros and consOutline use of extended fields for X509Discuss the certificate storage (private key storage) requirementsPotential use of non X509 trust anchorsDevice validation methods (trusted manufactures) Bringing it all togetherLook at full Lifecyle- for different alternativesSpecific the flows (sequence diagrams for different flows) e.g.Device DNS Name – embedded device variation (manufacturer managed – or manufacture delegated) Device DNS – DynDNS version (manufacturer managed– or manufacture delegated)Gateway issued name and certificate (user managed)Application issued name and certificate (user managed)Other….For each considerBrowser implementation details: which methods impact browser behaviourChanges needed to deviceChanges needed to DNS server infrastructure Changes needed to server based CA infrastructure Changes needed to gateway – or local infrastructureUser experience Ecosystem impacts  TODOs:#  Ask [Hannes] to comment on FIDO issues Ask [CA] to check the current implementation issues [Nick] CA/existing methods: push forward the certificate tool and add some stats [Nick] made recommenations on use of certificates [other] review refine use of certificate [Nick] add detail on Matter implementation IEEE 802.1AR - add details on feasibility/desirability - what is the definitive reference for this [Jan] X.509 Certificate Key Usage for Home Devices: validate the intent or this section [Nick] flesh out gateway method - and repurpose Device gateway section [other] initial review of gateway approach [Nick] flesh out application method [Nick] Added draft on non certificate based trust [Nick] Added information on FIDO + Matter +MUD [Nick] seperated out the DynDNS and embbeded local address flow  "},{"title":"SUIB-solutions-background1. # 2.#3. Background#3.4 Device Onboarding#4. Solutions#5. Bringing it together#","type":0,"sectionRef":"#","url":"docs/SUIB-solutions-background","content":"1. # 2.#3. Background#Symmetrical encryption uses the same key to encrypt. To exchange the key an asymmetrical encryption can be used. A known shared public key of a recipient is used to encrypt the data and only the recipient with the private key can decrypt the traffic. The public key information can be published somewhere or exchanged in the protocol. ITU-T x.509 certificates can be used to exchange the information. This certificate can specify the subject to indicate what the certificate is valid for. It can also have an issuer who signs the certificate. TLS is a protocol that browsers use to communicate securely. TLS Certificates are not the only schemes that provide secure connections. TLS Certificates therefor have a component where the address matters, where the browser has an influence because it has a trust store, where the certificate values matter and the way they are provisioned during device onboarding.3.4 Device Onboarding#<< INSERT FDO, Matter, MUD Here >>4. Solutions#<< INSERT Solution Doc here>>5. Bringing it together#The enable local encryption there are three aspects that need to be addressed. The local network needs a reliable way to identify that the device really came from the vendor, the network needs a reliable way to name a device and the browser needs to have a trust anchor that trusts these devices.In the current situation, the ingredients exist to create a solution that will satisfy the local trust, but there is no consistent coherent way which will work every time for everyone in every situation. It will require consensus building to achieve a reliable trust chain.Changes in the browser, certificate signing process or infrastructure to support domains can solve this issue, but it requires significant standardisation and organisation."},{"title":"About","type":0,"sectionRef":"#","url":"docs/about","content":""},{"title":"Licensing","type":1,"pageTitle":"About","url":"docs/about#licensing","content":"The favicon is called \"Book SVG Vector\" was created by \"SVG Repo\" and used under the CC0 License. "},{"title":"Document Number 2","type":0,"sectionRef":"#","url":"docs/doc2","content":"This is a link to another document. This is a link to an external page."},{"title":"This is Document Number 3","type":0,"sectionRef":"#","url":"docs/doc3","content":"Lorem ipsum dolor sit amet, consectetur adipiscing elit. In ac euismod odio, eu consequat dui. Nullam molestie consectetur risus id imperdiet. Proin sodales ornare turpis, non mollis massa ultricies id. Nam at nibh scelerisque, feugiat ante non, dapibus tortor. Vivamus volutpat diam quis tellus elementum bibendum. Praesent semper gravida velit quis aliquam. Etiam in cursus neque. Nam lectus ligula, malesuada et mauris a, bibendum faucibus mi. Phasellus ut interdum felis. Phasellus in odio pulvinar, porttitor urna eget, fringilla lectus. Aliquam sollicitudin est eros. Mauris consectetur quam vitae mauris interdum hendrerit. Lorem ipsum dolor sit amet, consectetur adipiscing elit.Duis et egestas libero, imperdiet faucibus ipsum. Sed posuere eget urna vel feugiat. Vivamus a arcu sagittis, fermentum urna dapibus, congue lectus. Fusce vulputate porttitor nisl, ac cursus elit volutpat vitae. Nullam vitae ipsum egestas, convallis quam non, porta nibh. Morbi gravida erat nec neque bibendum, eu pellentesque velit posuere. Fusce aliquam erat eu massa eleifend tristique.Sed consequat sollicitudin ipsum eget tempus. Integer a aliquet velit. In justo nibh, pellentesque non suscipit eget, gravida vel lacus. Donec odio ante, malesuada in massa quis, pharetra tristique ligula. Donec eros est, tristique eget finibus quis, semper non nisl. Vivamus et elit nec enim ornare placerat. Sed posuere odio a elit cursus sagittis.Phasellus feugiat purus eu tortor ultrices finibus. Ut libero nibh, lobortis et libero nec, dapibus posuere eros. Sed sagittis euismod justo at consectetur. Nulla finibus libero placerat, cursus sapien at, eleifend ligula. Vivamus elit nisl, hendrerit ac nibh eu, ultrices tempus dui. Nam tellus neque, commodo non rhoncus eu, gravida in risus. Nullam id iaculis tortor.Nullam at odio in sem varius tempor sit amet vel lorem. Etiam eu hendrerit nisl. Fusce nibh mauris, vulputate sit amet ex vitae, congue rhoncus nisl. Sed eget tellus purus. Nullam tempus commodo erat ut tristique. Cras accumsan massa sit amet justo consequat eleifend. Integer scelerisque vitae tellus id consectetur."},{"title":"Powered by MDX","type":0,"sectionRef":"#","url":"docs/mdx","content":"You can write JSX and use React components within your Markdown thanks to MDX.Docusaurus green and Facebook blue are my favorite colors.I can write Markdown alongside my JSX!"},{"title":"SUIB problem Summmary","type":0,"sectionRef":"#","url":"docs/problem-overview","content":"Users who want to provision or manage an IoT device or router using a browser, will have to do this over untrusted or unencrypted connections. Within the domestic environment this meands passwords and activities are exposed, to competnet attacker on the internal network. It's good practice to communicate securely, but to establish an encrypted connection the browser expects a signed certificate. The certificate of a the device must have a unique address or hostname, before a certificate can be signed. A signed certificate requires devices to be dependably discovered, identified and addressed. Either the local network connection is not encrypted, or the devices serve a self-signed certificate which a user has to accept, which is a poor and for the user worrying experience. Consumers are trained to accept certificate exceptions without explaining the difference in context between certificates used on the internet and self-signed certificates within a home environment. Device manufacturers have to work around this problem. This prevents HTTPS from effectively being used in household and industrial environments.A browser can trust certificates when they are signed by a trusted authority. A certificate ties the public key to a unique DNS or IP address. Most devices do not have a globally unique address, instead they rely on private or link local IP addresses and generic Multicast DNS names. Without domain name infrastructure there is no unique address and certification authorities can not sign the certificate.IoTSF is principally concerned with IoT. The SUIB (Secure Usable Intranet Browser) initiative has been formed to address this problem as it will exponentially grow as devices are added to local networks.In order to meaningfully address this problem we need to consider the following dimensions:Addressing: How is a device connected to the network (e.g. ethernet), how is it addressable (e.g. IPv4) and how does it do name resolution (e.g. DNS or mDNS)? The physical and logical addressing are a means for a browser to identify the local scope. The IP and DNS names are relevant because they are used by the browser to locate the device and in TLS certificates these are used as identifiers for the device. CA/Browser Forum uses the term \"internal names\" for IP and DNS names used in a local scope.Browser: Current browsers following CA/Browser Forum requirements show a padlock icon for certificates that are signed by a Root CA and generic security warnings are displayed for certificates that are not verified. How can a secure connection be established to local web servers and does this require a change in the browser?Certificates: For public internet certificate the browser behaviour has clearly defined TLS certificate management principles. For the local web server scenario, what changes are needed to make the certificate chain work.Device Onboading: how do the IOT devices get onboarded on the network and how does the browser discover connectable IOT devicesIn the next few background sections, we outline critical techniccal knowledge which is needed to fully understand the outlined solutions. "}]