From e03ccadcc1f4b81611721014193446ef925a6b65 Mon Sep 17 00:00:00 2001 From: Yoshiro Yoneya Date: Thu, 2 Nov 2017 14:12:59 +0900 Subject: [PATCH 1/3] Add files via upload --- 20171102-httpslocal-IETF-02.txt | 435 ++++++++++++++++++++++++++++++++ 1 file changed, 435 insertions(+) create mode 100644 20171102-httpslocal-IETF-02.txt diff --git a/20171102-httpslocal-IETF-02.txt b/20171102-httpslocal-IETF-02.txt new file mode 100644 index 0000000..6d564e4 --- /dev/null +++ b/20171102-httpslocal-IETF-02.txt @@ -0,0 +1,435 @@ +====================================================================== + + Expect-CT Extension for HTTP + + https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/ + + ART/HTTPBIS + https://datatracker.ietf.org/wg/httpbis/about/ + + 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. +====================================================================== + + + + ART/UTA + https://datatracker.ietf.org/wg/uta/about/ + + +====================================================================== + + + + GEN/ + + +====================================================================== + + Device Pairing Using Short Authentication Strings + + https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing/ + + INT/DNSSD + https://datatracker.ietf.org/wg/dnssd/about/ + + 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. +====================================================================== + + Device Pairing Design Issues + + https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing-info/ + + INT/DNSSD + https://datatracker.ietf.org/wg/dnssd/about/ + + 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. +====================================================================== + + Special Use Domain 'home.arpa.' + + https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ + + INT/HOMENET + https://datatracker.ietf.org/wg/homenet/about/ + + 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'. +====================================================================== + + Simple Homenet Naming and Service Discovery Architecture + + https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/ + + INT/HOMENET + https://datatracker.ietf.org/wg/homenet/about/ + + 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. +====================================================================== + + + + INT/LWIG + https://datatracker.ietf.org/wg/lwig/about/ + + +====================================================================== + + Bootstrapping Remote Secure Key Infrastructures + + https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ + + OPS/ANIMA + https://datatracker.ietf.org/wg/anima/about/ + + 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. +====================================================================== + + Let 'localhost' be localhost. + + https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/ + + OPS/DNSOP + https://datatracker.ietf.org/wg/dnsop/about/ + + 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. +====================================================================== + + + + RTG/ + + +====================================================================== + + Use Cases for Authentication and Authorization in Constrained Environments + + https://datatracker.ietf.org/doc/rfc7744/ + + SEC/ACE + https://datatracker.ietf.org/wg/ace/about/ + + 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. +====================================================================== + + Automatic Certificate Management Environment + + https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + CAA Record Extensions for Account URI and ACME Method Binding + + https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites + + https://datatracker.ietf.org/doc/draft-ietf-acme-star/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates + + https://datatracker.ietf.org/doc/draft-sheffer-acme-star-request/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + + + SEC/OAUTH + https://datatracker.ietf.org/wg/oauth/documents/ + + +====================================================================== + + A DANE Record and DNSSEC Authentication Chain Extension for TLS + + https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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. +====================================================================== + + Exported Authenticators in TLS + + https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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. +====================================================================== + + Data Center use of Static Diffie-Hellman in TLS 1.3 + + https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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 + + https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/ + [expired] + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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. +====================================================================== + + + + TSV/QUIC + https://datatracker.ietf.org/wg/quic/about/ + + +====================================================================== + + J-PAKE: Password-Authenticated Key Exchange by Juggling + + https://datatracker.ietf.org/doc/rfc8236/ + + INDIVIDUAL/ + + 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. +====================================================================== + + Requirements for Password-Authenticated Key Agreement (PAKE) Schemes + + https://datatracker.ietf.org/doc/rfc8125/ + + IRTF/CFRG + https://datatracker.ietf.org/rg/cfrg/about/ + + 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). +====================================================================== + + Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures + + https://datatracker.ietf.org/doc/rfc7962/ + + IRTF/GAIA + https://datatracker.ietf.org/rg/gaia/about/ + + 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. +====================================================================== + + + + IRTF/T2TRG + https://datatracker.ietf.org/rg/t2trg/documents/ + + +====================================================================== From 1591ec69984d70c275821c305ca0d44900d602ec Mon Sep 17 00:00:00 2001 From: Yoshiro Yoneya Date: Thu, 2 Nov 2017 14:17:31 +0900 Subject: [PATCH 2/3] Delete 20171102-httpslocal-IETF-02.txt --- 20171102-httpslocal-IETF-02.txt | 435 -------------------------------- 1 file changed, 435 deletions(-) delete mode 100644 20171102-httpslocal-IETF-02.txt diff --git a/20171102-httpslocal-IETF-02.txt b/20171102-httpslocal-IETF-02.txt deleted file mode 100644 index 6d564e4..0000000 --- a/20171102-httpslocal-IETF-02.txt +++ /dev/null @@ -1,435 +0,0 @@ -====================================================================== - - Expect-CT Extension for HTTP - - https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/ - - ART/HTTPBIS - https://datatracker.ietf.org/wg/httpbis/about/ - - 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. -====================================================================== - - - - ART/UTA - https://datatracker.ietf.org/wg/uta/about/ - - -====================================================================== - - - - GEN/ - - -====================================================================== - - Device Pairing Using Short Authentication Strings - - https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing/ - - INT/DNSSD - https://datatracker.ietf.org/wg/dnssd/about/ - - 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. -====================================================================== - - Device Pairing Design Issues - - https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing-info/ - - INT/DNSSD - https://datatracker.ietf.org/wg/dnssd/about/ - - 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. -====================================================================== - - Special Use Domain 'home.arpa.' - - https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ - - INT/HOMENET - https://datatracker.ietf.org/wg/homenet/about/ - - 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'. -====================================================================== - - Simple Homenet Naming and Service Discovery Architecture - - https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/ - - INT/HOMENET - https://datatracker.ietf.org/wg/homenet/about/ - - 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. -====================================================================== - - - - INT/LWIG - https://datatracker.ietf.org/wg/lwig/about/ - - -====================================================================== - - Bootstrapping Remote Secure Key Infrastructures - - https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ - - OPS/ANIMA - https://datatracker.ietf.org/wg/anima/about/ - - 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. -====================================================================== - - Let 'localhost' be localhost. - - https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/ - - OPS/DNSOP - https://datatracker.ietf.org/wg/dnsop/about/ - - 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. -====================================================================== - - - - RTG/ - - -====================================================================== - - Use Cases for Authentication and Authorization in Constrained Environments - - https://datatracker.ietf.org/doc/rfc7744/ - - SEC/ACE - https://datatracker.ietf.org/wg/ace/about/ - - 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. -====================================================================== - - Automatic Certificate Management Environment - - https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ - - SEC/ACME - https://datatracker.ietf.org/wg/acme/about/ - - 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. -====================================================================== - - CAA Record Extensions for Account URI and ACME Method Binding - - https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ - - SEC/ACME - https://datatracker.ietf.org/wg/acme/about/ - - 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. -====================================================================== - - Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites - - https://datatracker.ietf.org/doc/draft-ietf-acme-star/ - - SEC/ACME - https://datatracker.ietf.org/wg/acme/about/ - - 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. -====================================================================== - - Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates - - https://datatracker.ietf.org/doc/draft-sheffer-acme-star-request/ - - SEC/ACME - https://datatracker.ietf.org/wg/acme/about/ - - 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. -====================================================================== - - - - SEC/OAUTH - https://datatracker.ietf.org/wg/oauth/documents/ - - -====================================================================== - - A DANE Record and DNSSEC Authentication Chain Extension for TLS - - https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ - - SEC/TLS - https://datatracker.ietf.org/wg/tls/about/ - - 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. -====================================================================== - - Exported Authenticators in TLS - - https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ - - SEC/TLS - https://datatracker.ietf.org/wg/tls/about/ - - 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. -====================================================================== - - Data Center use of Static Diffie-Hellman in TLS 1.3 - - https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ - - SEC/TLS - https://datatracker.ietf.org/wg/tls/about/ - - 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 - - https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/ - [expired] - - SEC/TLS - https://datatracker.ietf.org/wg/tls/about/ - - 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. -====================================================================== - - - - TSV/QUIC - https://datatracker.ietf.org/wg/quic/about/ - - -====================================================================== - - J-PAKE: Password-Authenticated Key Exchange by Juggling - - https://datatracker.ietf.org/doc/rfc8236/ - - INDIVIDUAL/ - - 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. -====================================================================== - - Requirements for Password-Authenticated Key Agreement (PAKE) Schemes - - https://datatracker.ietf.org/doc/rfc8125/ - - IRTF/CFRG - https://datatracker.ietf.org/rg/cfrg/about/ - - 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). -====================================================================== - - Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures - - https://datatracker.ietf.org/doc/rfc7962/ - - IRTF/GAIA - https://datatracker.ietf.org/rg/gaia/about/ - - 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. -====================================================================== - - - - IRTF/T2TRG - https://datatracker.ietf.org/rg/t2trg/documents/ - - -====================================================================== From bfe97733f4e2c82cca09180ea8bc1cad7185d0df Mon Sep 17 00:00:00 2001 From: Yoshiro Yoneya Date: Thu, 2 Nov 2017 14:20:47 +0900 Subject: [PATCH 3/3] Create RelevantIETFDocuments --- RelevantIETFDocuments | 436 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 436 insertions(+) create mode 100644 RelevantIETFDocuments diff --git a/RelevantIETFDocuments b/RelevantIETFDocuments new file mode 100644 index 0000000..81ed39b --- /dev/null +++ b/RelevantIETFDocuments @@ -0,0 +1,436 @@ +as of 2 Nov 2017 +====================================================================== + + Expect-CT Extension for HTTP + + https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/ + + ART/HTTPBIS + https://datatracker.ietf.org/wg/httpbis/about/ + + 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. +====================================================================== + + + + ART/UTA + https://datatracker.ietf.org/wg/uta/about/ + + +====================================================================== + + + + GEN/ + + +====================================================================== + + Device Pairing Using Short Authentication Strings + + https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing/ + + INT/DNSSD + https://datatracker.ietf.org/wg/dnssd/about/ + + 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. +====================================================================== + + Device Pairing Design Issues + + https://datatracker.ietf.org/doc/draft-ietf-dnssd-pairing-info/ + + INT/DNSSD + https://datatracker.ietf.org/wg/dnssd/about/ + + 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. +====================================================================== + + Special Use Domain 'home.arpa.' + + https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ + + INT/HOMENET + https://datatracker.ietf.org/wg/homenet/about/ + + 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'. +====================================================================== + + Simple Homenet Naming and Service Discovery Architecture + + https://datatracker.ietf.org/doc/draft-tldm-simple-homenet-naming/ + + INT/HOMENET + https://datatracker.ietf.org/wg/homenet/about/ + + 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. +====================================================================== + + + + INT/LWIG + https://datatracker.ietf.org/wg/lwig/about/ + + +====================================================================== + + Bootstrapping Remote Secure Key Infrastructures + + https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ + + OPS/ANIMA + https://datatracker.ietf.org/wg/anima/about/ + + 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. +====================================================================== + + Let 'localhost' be localhost. + + https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/ + + OPS/DNSOP + https://datatracker.ietf.org/wg/dnsop/about/ + + 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. +====================================================================== + + + + RTG/ + + +====================================================================== + + Use Cases for Authentication and Authorization in Constrained Environments + + https://datatracker.ietf.org/doc/rfc7744/ + + SEC/ACE + https://datatracker.ietf.org/wg/ace/about/ + + 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. +====================================================================== + + Automatic Certificate Management Environment + + https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + CAA Record Extensions for Account URI and ACME Method Binding + + https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites + + https://datatracker.ietf.org/doc/draft-ietf-acme-star/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates + + https://datatracker.ietf.org/doc/draft-sheffer-acme-star-request/ + + SEC/ACME + https://datatracker.ietf.org/wg/acme/about/ + + 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. +====================================================================== + + + + SEC/OAUTH + https://datatracker.ietf.org/wg/oauth/documents/ + + +====================================================================== + + A DANE Record and DNSSEC Authentication Chain Extension for TLS + + https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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. +====================================================================== + + Exported Authenticators in TLS + + https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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. +====================================================================== + + Data Center use of Static Diffie-Hellman in TLS 1.3 + + https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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 + + https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/ + [expired] + + SEC/TLS + https://datatracker.ietf.org/wg/tls/about/ + + 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. +====================================================================== + + + + TSV/QUIC + https://datatracker.ietf.org/wg/quic/about/ + + +====================================================================== + + J-PAKE: Password-Authenticated Key Exchange by Juggling + + https://datatracker.ietf.org/doc/rfc8236/ + + INDIVIDUAL/ + + 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. +====================================================================== + + Requirements for Password-Authenticated Key Agreement (PAKE) Schemes + + https://datatracker.ietf.org/doc/rfc8125/ + + IRTF/CFRG + https://datatracker.ietf.org/rg/cfrg/about/ + + 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). +====================================================================== + + Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures + + https://datatracker.ietf.org/doc/rfc7962/ + + IRTF/GAIA + https://datatracker.ietf.org/rg/gaia/about/ + + 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. +====================================================================== + + + + IRTF/T2TRG + https://datatracker.ietf.org/rg/t2trg/documents/ + + +======================================================================