- WG: HTTPBIS
- Category: Certificate Transparency (CT)
This document defines a new HTTP header, named Expect-CT, that allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. When configured in enforcement mode, user agents (UAs) will remember that hosts expect SCTs and will refuse connections that do not conform to the UA's Certificate Transparency policy. When configured in report-only mode, UAs will report the lack of valid SCTs to a URI configured by the host, but will allow the connection. By turning on Expect-CT, web host operators can discover misconfigurations in their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs.
- WG: UTA
- Category:
- WG: DNSSD
- Category: service discovery, device authentication
This document proposes a device pairing mechanism that establishes a relation between two devices by agreeing on a secret and manually verifying the secret's authenticity using an SAS (short authentication string). Pairing has to be performed only once per pair of devices, as for a re-discovery at any later point in time, the exchanged secret can be used for mutual authentication.
The proposed pairing method is suited for each application area where human operated devices need to establish a relation that allows configurationless and privacy preserving re-discovery at any later point in time. Since privacy preserving applications are the main suitors, we especially care about privacy.
- WG: DNSSD
- Category: service discovery, device pairing
This document discusses issues and problems occuring in the design of device pairing mechanism. It presents experience with existing pairing systems and general user interaction requirements to make the case for "short authentication strings". It then reviews the design of cryptographic algorithms designed to maximise the robustness of the short authentication string mechanisms, as well as implementation considerations such as integration with TLS.
- WG: HOMENET
- Category: localnet top level domain name
This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.
- WG: HOMENET
- Category: service discovery, localnet name resolution
This document describes a simple name resolution and service discovery architecture for homenets. This architecture covers local publication of names, as well as name resolution for local and global names.
- WG: LWIG
- Category:
- WG: ANIMA
- Category: localnet pki bootstrap
This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well.
- WG: DNSOP
- Category: localnet top level domain name
This document updates RFC6761 with the goal of ensuring that "localhost" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return "NXDOMAIN" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates.
Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network.
- WG: ACE
- Category: device authentication, device authorization
Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.
This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.
Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.
- WG: ACME
- Category: certificate issuance mechanism
Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.
- WG: ACME
- Category: certificate issuance mechanism
The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required.
- WG: ACME
- Category: short-term certificate, localnet
This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed certificates. This allows a domain name owner to delegate the use of certificates to another party, while retaining the capability to cancel this delegation at any time with no need to rely on certificate revocation mechanisms.
- WG: ACME
- Category: short-term certificate, localnet
This memo proposes a protocol that allows a domain name owner to delegate to a third party (such as a CDN) control over a certificate that bears one or more names in that domain. Specifically the third party creates a Certificate Signing Request for the domain, which can then be used by the domain owner to request a short term and automatically renewed (STAR) certificate.
This is a component in a solution where a third-party such as a CDN can terminate TLS sessions on behalf of a domain name owner (e.g., a content provider), and the domain owner can cancel this delegation at any time without having to rely on certificate revocation mechanisms.
- WG: OAUTH
- Category:
- WG: TLS
- Category: certificate verification
This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names.
- WG: TLS
- Category: certificate verification
This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party.
- WG: TLS
- Category: tls1.3 specification
Unlike earlier versions of TLS, current drafts of TLS 1.3 have instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve Diffie-Hellman as the primary cryptographic key exchange mechanism used in TLS. This document describes an optional configuration for TLS servers that allows for the use of a static Diffie-Hellman private key for all TLS connections made to the server. Passive monitoring of TLS connections can be enabled by installing a corresponding copy of this key in each monitoring device.
Delegated Credentials for TLS [expired]
- WG: TLS
- Category: tls credential extension
The organizational separation between the operator of a TLS server and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms. This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking compatibility with clients that do not support this specification.
- WG: QUIC
- Category:
- RG: CFRG
- Category: password authenticated key exchange
Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).
- RG: GAIA
- Category: localnet, taxonomy
This document presents a taxonomy of a set of "Alternative Network Deployments" that emerged in the last decade with the aim of bringing Internet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives. They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.
The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.
The classification considers models such as Community Networks, Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.
- RG: T2TRG
- Category:
- Category: password authenticated key exchange
This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.