as of 2 Nov 2017

======================================================================

<Document Title>

Expect-CT Extension for HTTP

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/

<AREA/WG>

ART/HTTPBIS

https://datatracker.ietf.org/wg/httpbis/about/

<Category>

Certificate Transparency (CT)

<Abstract>

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.

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

ART/UTA

https://datatracker.ietf.org/wg/uta/about/

<Category>

<Abstract>

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

GEN/

<Category>

<Abstract>

======================================================================

<Document Title>

Device Pairing Using Short Authentication Strings

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing/

<AREA/WG>

INT/DNSSD

https://datatracker.ietf.org/wg/dnssd/about/

<Category>

service discovery, device authentication

<Abstract>

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.

======================================================================

<Document Title>

Device Pairing Design Issues

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing-info/

<AREA/WG>

INT/DNSSD

https://datatracker.ietf.org/wg/dnssd/about/

<Category>

service discovery, device pairing

<Abstract>

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.

======================================================================

<Document Title>

Special Use Domain 'home.arpa.'

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/

<AREA/WG>

INT/HOMENET

https://datatracker.ietf.org/wg/homenet/about/

<Category>

localnet top level domain name

<Abstract>

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'.

======================================================================

<Document Title>

Simple Homenet Naming and Service Discovery Architecture

<Document URL>

https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/

<AREA/WG>

INT/HOMENET

https://datatracker.ietf.org/wg/homenet/about/

<Category>

service discovery, localnet name resolution

<Abstract>

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.

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

INT/LWIG

https://datatracker.ietf.org/wg/lwig/about/

<Category>

<Abstract>

======================================================================

<Document Title>

Bootstrapping Remote Secure Key Infrastructures

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

<AREA/WG>

OPS/ANIMA

https://datatracker.ietf.org/wg/anima/about/

<Category>

localnet pki bootstrap

<Abstract>

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.

======================================================================

<Document Title>

Let 'localhost' be localhost.

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/

<AREA/WG>

OPS/DNSOP

https://datatracker.ietf.org/wg/dnsop/about/

<Category>

localnet top level domain name

<Abstract>

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.

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

RTG/

<Category>

<Abstract>

======================================================================

<Document Title>

Use Cases for Authentication and Authorization in Constrained Environments

<Document URL>

https://datatracker.ietf.org/doc/rfc7744/

<AREA/WG>

SEC/ACE

https://datatracker.ietf.org/wg/ace/about/

<Category>

device authentication, device authorization

<Abstract>

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.

======================================================================

<Document Title>

Automatic Certificate Management Environment

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

<AREA/WG>

SEC/ACME

https://datatracker.ietf.org/wg/acme/about/

<Category>

certificate issuance mechanism

<Abstract>

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.

======================================================================

<Document Title>

CAA Record Extensions for Account URI and ACME Method Binding

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-acme-caa/

<AREA/WG>

SEC/ACME

https://datatracker.ietf.org/wg/acme/about/

<Category>

certificate issuance mechanism

<Abstract>

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.

======================================================================

<Document Title>

Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-acme-star/

<AREA/WG>

SEC/ACME

https://datatracker.ietf.org/wg/acme/about/

<Category>

short-term certificate, localnet

<Abstract>

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.

======================================================================

<Document Title>

Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates

<Document URL>

https://datatracker.ietf.org/doc/draft-sheffer-acme-star-request/

<AREA/WG>

SEC/ACME

https://datatracker.ietf.org/wg/acme/about/

<Category>

short-term certificate, localnet

<Abstract>

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.

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

SEC/OAUTH

https://datatracker.ietf.org/wg/oauth/documents/

<Category>

<Abstract>

======================================================================

<Document Title>

A DANE Record and DNSSEC Authentication Chain Extension for TLS

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

<AREA/WG>

SEC/TLS

https://datatracker.ietf.org/wg/tls/about/

<Category>

certificate verification

<Abstract>

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.

======================================================================

<Document Title>

Exported Authenticators in TLS

<Document URL>

https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/

<AREA/WG>

SEC/TLS

https://datatracker.ietf.org/wg/tls/about/

<Category>

certificate verification

<Abstract>

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.

======================================================================

<Document Title>

Data Center use of Static Diffie-Hellman in TLS 1.3

<Document URL>

https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/

<AREA/WG>

SEC/TLS

https://datatracker.ietf.org/wg/tls/about/

<Category>

tls1.3 specification

<Abstract>

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.

======================================================================

<Document Title>

Delegated Credentials for TLS

<Document URL>

https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/

[expired]

<AREA/WG>

SEC/TLS

https://datatracker.ietf.org/wg/tls/about/

<Category>

tls credential extension

<Abstract>

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.

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

TSV/QUIC

https://datatracker.ietf.org/wg/quic/about/

<Category>

<Abstract>

======================================================================

<Document Title>

J-PAKE: Password-Authenticated Key Exchange by Juggling

<Document URL>

https://datatracker.ietf.org/doc/rfc8236/

<AREA/WG>

INDIVIDUAL/

<Category>

password authenticated key exchange

<Abstract>

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.

======================================================================

<Document Title>

Requirements for Password-Authenticated Key Agreement (PAKE) Schemes

<Document URL>

https://datatracker.ietf.org/doc/rfc8125/

<AREA/WG>

IRTF/CFRG

https://datatracker.ietf.org/rg/cfrg/about/

<Category>

password authenticated key exchange

<Abstract>

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).

======================================================================

<Document Title>

Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures

<Document URL>

https://datatracker.ietf.org/doc/rfc7962/

<AREA/WG>

IRTF/GAIA

https://datatracker.ietf.org/rg/gaia/about/

<Category>

localnet, taxonomy

<Abstract>

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.

======================================================================

<Document Title>

<Document URL>

<AREA/WG>

IRTF/T2TRG

https://datatracker.ietf.org/rg/t2trg/documents/

<Category>

<Abstract>

======================================================================