< draft-nottingham-rfc5785bis-06.txt   draft-nottingham-rfc5785bis-07.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft May 24, 2018 Internet-Draft August 1, 2018
Obsoletes: 5785 (if approved) Obsoletes: 5785, 8307 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: November 25, 2018 Expires: February 2, 2019
Well-Known Uniform Resource Identifiers (URIs) Well-Known Uniform Resource Identifiers (URIs)
draft-nottingham-rfc5785bis-06 draft-nottingham-rfc5785bis-07
Abstract Abstract
This memo defines a path prefix for "well-known locations", "/.well- This memo defines a path prefix for "well-known locations", "/.well-
known/", in selected Uniform Resource Identifier (URI) schemes. known/", in selected Uniform Resource Identifier (URI) schemes.
Note to Readers Note to Readers
_RFC EDITOR: please remove this section before publication_ _RFC EDITOR: please remove this section before publication_
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2018. This Internet-Draft will expire on February 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4 3.1. Registering Well-Known URIs . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4.1. Interaction with Web Browsing . . . . . . . . . . . . . . 5 4.1. Interaction with Web Browsing . . . . . . . . . . . . . . 5
4.2. Scoping Applications . . . . . . . . . . . . . . . . . . 6 4.2. Scoping Applications . . . . . . . . . . . . . . . . . . 7
4.3. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 7 4.3. Hidden Capabilities . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 7 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 10 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 10
Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 10 Appendix B. Changes from RFC5785 . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 41 skipping to change at page 3, line 41
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Well-Known URIs 3. Well-Known URIs
A well-known URI is a URI [RFC3986] whose path component begins with A well-known URI is a URI [RFC3986] whose path component begins with
the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", the characters "/.well-known/", and whose scheme is "http", "https",
or another scheme that has explicitly been specified to use well- "ws", "wss", or another scheme that has explicitly been specified to
known URIs. use well-known URIs.
Applications that wish to mint new well-known URIs MUST register Applications that wish to mint new well-known URIs MUST register
them, following the procedures in Section 5.1. them, following the procedures in Section 5.1.
For example, if an application registers the name 'example', the For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'. 'http://www.example.com/.well-known/example'.
Registered names MUST conform to the segment-nz production in Registered names MUST conform to the segment-nz production in
[RFC3986]. This means they cannot contain the "/" character. [RFC3986]. This means they cannot contain the "/" character.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
Registered names for a specific application SHOULD be correspondingly Registered names for a specific application SHOULD be correspondingly
precise; "squatting" on generic terms is not encouraged. For precise; "squatting" on generic terms is not encouraged. For
example, if the Example application wants a well-known location for example, if the Example application wants a well-known location for
metadata, an appropriate registered name might be "example-metadata" metadata, an appropriate registered name might be "example-metadata"
or even "example.com-metadata", not "metadata". or even "example.com-metadata", not "metadata".
At a minimum, a registration will reference a specification that At a minimum, a registration will reference a specification that
defines the format and associated media type(s) to be obtained by defines the format and associated media type(s) to be obtained by
dereferencing the well-known URI, along with the URI scheme(s) that dereferencing the well-known URI, along with the URI scheme(s) that
the well-known URI can be used with. If no URI schemes are the well-known URI can be used with. If no URI schemes are
explicitly specified, "HTTP" and "HTTPS" are assumed. explicitly specified, "http" and "https" are assumed.
Typically, applications will use the default port for the given
scheme; if an alternative port is used, it MUST be explicitly
specified by the application in question.
It MAY also contain additional information, such as the syntax of It MAY also contain additional information, such as the syntax of
additional path components, query strings and/or fragment identifiers additional path components, query strings and/or fragment identifiers
to be appended to the well-known URI, or protocol-specific details to be appended to the well-known URI, or protocol-specific details
(e.g., HTTP [RFC7231] method handling). (e.g., HTTP [RFC7231] method handling).
Note that this specification defines neither how to determine the Note that this specification defines neither how to determine the
hostname to use to find the well-known URI for a particular hostname to use to find the well-known URI for a particular
application, nor the scope of the metadata discovered by application, nor the scope of the metadata discovered by
dereferencing the well-known URI; both should be defined by the dereferencing the well-known URI; both should be defined by the
application itself. application itself.
Also, this specification does not define a format or media-type for Also, this specification does not define a format or media-type for
the resource located at "/.well-known/" and clients should not expect the resource located at "/.well-known/" and clients should not expect
a resource to exist at that location. a resource to exist at that location.
Well-known URIs are only valid when rooted in the top of the path's Well-known URIs are rooted in the top of the path's hierarchy; they
hierarchy; they MUST NOT be used in other parts of the path. For are not well-known by definition in other parts of the path. For
example, "/.well-known/example" is a valid use, but "/foo/.well- example, "/.well-known/example" is a well-known URI, whereas
known/example" is not. "/foo/.well-known/example" is not.
See also Section 4 for Security Considerations regarding well-known See also Section 4 for Security Considerations regarding well-known
locations. locations.
3.1. Registering Well-Known URIs 3.1. Registering Well-Known URIs
The "Well-Known URIs" registry is located at The "Well-Known URIs" registry is located at
"https://www.iana.org/assignments/well-known-uris/". Registration "https://www.iana.org/assignments/well-known-uris/". Registration
requests can be made by following the instructions located there or requests can be made by following the instructions located there or
by sending an email to the "wellknown-uri-review@ietf.org" mailing by sending an email to the "wellknown-uri-review@ietf.org" mailing
skipping to change at page 5, line 43 skipping to change at page 5, line 47
Applications minting new well-known URIs, as well as administrators Applications minting new well-known URIs, as well as administrators
deploying them, will need to consider several security-related deploying them, will need to consider several security-related
issues, including (but not limited to) exposure of sensitive data, issues, including (but not limited to) exposure of sensitive data,
denial-of-service attacks (in addition to normal load issues), server denial-of-service attacks (in addition to normal load issues), server
and client authentication, vulnerability to DNS rebinding attacks, and client authentication, vulnerability to DNS rebinding attacks,
and attacks where limited access to a server grants the ability to and attacks where limited access to a server grants the ability to
affect how well-known URIs are served. affect how well-known URIs are served.
4.1. Interaction with Web Browsing 4.1. Interaction with Web Browsing
Applications using well-known URIs for HTTP or HTTPS URLs need to be Applications using well-known URIs for "http" or "https" URLs need to
aware that well-known resources will be accessible to Web browsers, be aware that well-known resources will be accessible to Web
and therefore are able to be manipulated by content obtained from browsers, and therefore are able to be manipulated by content
other parts of that origin. If an attacker is able to inject content obtained from other parts of that origin. If an attacker is able to
(e.g., through a Cross-Site Scripting vulnerability), they will be inject content (e.g., through a Cross-Site Scripting vulnerability),
able to make potentially arbitrary requests to the well-known they will be able to make potentially arbitrary requests to the well-
resource. known resource.
HTTP and HTTPS also use origins as a security boundary for many other HTTP and HTTPS also use origins as a security boundary for many other
mechanisms, including (but not limited to) Cookies [RFC6265], Web mechanisms, including (but not limited to) Cookies [RFC6265], Web
Storage [WEBSTORAGE] and many capabilities. Storage [WEBSTORAGE] and many capabilities.
Applications defining well-known locations should not assume that Applications defining well-known locations should not assume that
they have sole access to these mechanisms, or that they are the only they have sole access to these mechanisms, or that they are the only
application using the origin. Depending on the nature of the application using the origin. Depending on the nature of the
application, mitigations can include: application, mitigations can include:
skipping to change at page 10, line 36 skipping to change at page 10, line 42
Appendix B. Changes from RFC5785 Appendix B. Changes from RFC5785
o Allow non-Web well-known locations o Allow non-Web well-known locations
o Adjust IANA instructions o Adjust IANA instructions
o Update references o Update references
o Various other clarifications o Various other clarifications
o Add "ws" and "wss" schemes
Author's Address Author's Address
Mark Nottingham Mark Nottingham
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
 End of changes. 10 change blocks. 
21 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/