doc: Add RFC documents

1 files changed, 355 insertions, 0 deletions

diff --git a/doc/rfc/rfc8809.txt b/doc/rfc/rfc8809.txt
new file mode 100644
index 0000000..e8f4e2a
--- /dev/null
+++ b/doc/rfc/rfc8809.txt
@@ -0,0 +1,355 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         J. Hodges
+Request for Comments: 8809                                        Google
+Category: Informational                                       G. Mandyam
+ISSN: 2070-1721                               Qualcomm Technologies Inc.
+                                                                M. Jones
+                                                               Microsoft
+                                                             August 2020
+
+
+              Registries for Web Authentication (WebAuthn)
+
+Abstract
+
+   This specification defines IANA registries for W3C Web Authentication
+   (WebAuthn) attestation statement format identifiers and extension
+   identifiers.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8809.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Notation and Conventions
+   2.  IANA Considerations
+     2.1.  WebAuthn Attestation Statement Format Identifiers Registry
+       2.1.1.  Registering Attestation Statement Format Identifiers
+       2.1.2.  Registration Request Processing
+       2.1.3.  Initial Values in the WebAuthn Attestation Statement
+               Format Identifiers Registry
+     2.2.  WebAuthn Extension Identifiers Registry
+       2.2.1.  Registering Extension Identifiers
+       2.2.2.  Registration Request Processing
+       2.2.3.  Initial Values in the WebAuthn Extension Identifiers
+               Registry
+   3.  Security Considerations
+   4.  Normative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This specification establishes IANA registries for W3C Web
+   Authentication [WebAuthn] attestation statement format identifiers
+   and extension identifiers.  The initial values for these registries
+   are in the IANA Considerations section of the [WebAuthn]
+   specification.
+
+1.1.  Requirements Notation and Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  IANA Considerations
+
+   This specification establishes two registries:
+
+   *  the "WebAuthn Attestation Statement Format Identifiers" registry
+      (see Section 2.1)
+
+   *  the "WebAuthn Extension Identifiers" registry (see Section 2.2)
+
+   Any additional processes established by the expert(s) after the
+   publication of this document will be recorded on the registry web
+   page at the discretion of the expert(s).
+
+2.1.  WebAuthn Attestation Statement Format Identifiers Registry
+
+   WebAuthn attestation statement format identifiers are strings whose
+   semantic, syntactic, and string-matching criteria are specified in
+   the "Attestation Statement Format Identifiers"
+   (https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-attstn-fmt-
+   ids) section of [WebAuthn], along with the concepts of attestation
+   and attestation statement formats.
+
+   Registered attestation statement format identifiers are those that
+   have been added to the registry by following the procedure in
+   Section 2.1.1.
+
+   Each attestation statement format identifier added to this registry
+   MUST be unique amongst the set of registered attestation statement
+   format identifiers.
+
+   Registered attestation statement format identifiers MUST be a maximum
+   of 32 octets in length and MUST consist only of printable ASCII
+   [RFC20] characters, excluding backslash and double quote, i.e., VCHAR
+   as defined in [RFC5234] but without %x22 and %x5c.  Attestation
+   statement format identifiers are case sensitive and may not match
+   other registered identifiers in a case-insensitive manner unless the
+   designated experts determine that there is a compelling reason to
+   allow an exception.
+
+2.1.1.  Registering Attestation Statement Format Identifiers
+
+   WebAuthn attestation statement format identifiers are registered
+   using the Specification Required policy (see Section 4.6 of
+   [RFC8126]).
+
+   The "WebAuthn Attestation Statement Format Identifiers" registry is
+   located at <https://www.iana.org/assignments/webauthn>.  Registration
+   requests can be made by following the instructions located there or
+   by sending an email to the webauthn-reg-review@ietf.org mailing list.
+
+   Registration requests consist of at least the following information:
+
+   WebAuthn Attestation Statement Format Identifier:
+      An identifier meeting the requirements given in Section 2.1.
+
+   Description:
+      A relatively short description of the attestation format.
+
+   Specification Document(s):
+      Reference to the document or documents that specify the
+      attestation statement format.
+
+   Change Controller:
+      For Standards Track RFCs, list "IETF".  For others, give the name
+      of the responsible party.  Other details (e.g., postal address,
+      email address, home page URI) may also be included.
+
+   Notes:
+      [optional]
+
+   Registrations MUST reference a freely available, stable
+   specification, e.g., as described in Section 4.6 of [RFC8126].  This
+   specification MUST include security and privacy considerations
+   relevant to the attestation statement format.
+
+   Note that WebAuthn attestation statement format identifiers can be
+   registered by third parties (including the expert(s) themselves), if
+   the expert(s) determines that an unregistered attestation statement
+   format is widely deployed and not likely to be registered in a timely
+   manner otherwise.  Such registrations still are subject to the
+   requirements defined, including the need to reference a
+   specification.
+
+2.1.2.  Registration Request Processing
+
+   As noted in Section 2.1.1, WebAuthn attestation statement format
+   identifiers are registered using the Specification Required policy.
+
+   The expert(s) will clearly identify any issues that cause a
+   registration to be refused, such as an incompletely specified
+   attestation format.
+
+   When a request is approved, the expert(s) will inform IANA, and the
+   registration will be processed.  The IESG is the arbiter of any
+   objection.
+
+2.1.3.  Initial Values in the WebAuthn Attestation Statement Format
+        Identifiers Registry
+
+   The initial values for the "WebAuthn Attestation Statement Format
+   Identifiers" registry have been populated with the values listed in
+   the "WebAuthn Attestation Statement Format Identifier Registrations"
+   (https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-att-fmt-
+   reg) section of [WebAuthn].  Also, the Change Controller entry for
+   each of those registrations is:
+
+   Change Controller:
+      W3C Web Authentication Working Group (public-webauthn@w3.org)
+
+2.2.  WebAuthn Extension Identifiers Registry
+
+   WebAuthn extension identifiers are strings whose semantic, syntactic,
+   and string-matching criteria are specified in the "Extension
+   Identifiers" (https://www.w3.org/TR/2019/REC-webauthn-1-
+   20190304/#sctn-extension-id) section of [WebAuthn].
+
+   Registered extension identifiers are those that have been added to
+   the registry by following the procedure in Section 2.2.1.
+
+   Each extension identifier added to this registry MUST be unique
+   amongst the set of registered extension identifiers.
+
+   Registered extension identifiers MUST be a maximum of 32 octets in
+   length and MUST consist only of printable ASCII characters, excluding
+   backslash and double quote, i.e., VCHAR as defined in [RFC5234] but
+   without %x22 and %x5c.  Extension identifiers are case sensitive and
+   may not match other registered identifiers in a case-insensitive
+   manner unless the designated experts determine that there is a
+   compelling reason to allow an exception.
+
+2.2.1.  Registering Extension Identifiers
+
+   WebAuthn extension identifiers are registered using the Specification
+   Required policy (see Section 4.6 of [RFC8126]).
+
+   The "WebAuthn Extension Identifiers" registry is located at
+   <https://www.iana.org/assignments/webauthn>.  Registration requests
+   can be made by following the instructions located there or by sending
+   an email to the webauthn-reg-review@ietf.org mailing list.
+
+   Registration requests consist of at least the following information:
+
+   WebAuthn Extension Identifier:
+      An identifier meeting the requirements given in Section 2.2.
+
+   Description:
+      A relatively short description of the extension.
+
+   Specification Document(s):
+      Reference to the document or documents that specify the extension.
+
+   Change Controller:
+      For Standards Track RFCs, list "IETF".  For others, give the name
+      of the responsible party.  Other details (e.g., postal address,
+      email address, home page URI) may also be included.
+
+   Notes:
+      [optional]
+
+   Registrations MUST reference a freely available, stable
+   specification, e.g., as described in Section 4.6 of [RFC8126].  This
+   specification MUST include security and privacy considerations
+   relevant to the extension.
+
+   Note that WebAuthn extensions can be registered by third parties
+   (including the expert(s) themselves), if the expert(s) determines
+   that an unregistered extension is widely deployed and not likely to
+   be registered in a timely manner otherwise.  Such registrations still
+   are subject to the requirements defined, including the need to
+   reference a specification.
+
+2.2.2.  Registration Request Processing
+
+   As noted in Section 2.2.1, WebAuthn extension identifiers are
+   registered using the Specification Required policy.
+
+   The expert(s) will clearly identify any issues that cause a
+   registration to be refused, such as an incompletely specified
+   extension.
+
+   When a request is approved, the expert(s) will inform IANA, and the
+   registration will be processed.  The IESG is the arbiter of any
+   objection.
+
+2.2.3.  Initial Values in the WebAuthn Extension Identifiers Registry
+
+   The initial values for the "WebAuthn Extension Identifiers" registry
+   have been populated with the values listed in the "WebAuthn Extension
+   Identifier Registrations" (https://www.w3.org/TR/2019/REC-webauthn-1-
+   20190304/#sctn-extensions-reg) section of [WebAuthn].  Also, the
+   Change Controller entry for each of those registrations is:
+
+   Change Controller:
+      W3C Web Authentication Working Group (public-webauthn@w3.org)
+
+3.  Security Considerations
+
+   See [WebAuthn] for relevant security considerations.
+
+4.  Normative References
+
+   [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
+              RFC 20, DOI 10.17487/RFC0020, October 1969,
+              <https://www.rfc-editor.org/info/rfc20>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [WebAuthn] Balfanz, D., Czeskis, A., Hodges, J., Jones, J.C., Jones,
+              M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg,
+              "Web Authentication: An API for accessing Public Key
+              Credentials", World Wide Web Consortium
+              (W3C) Recommendation, 4 March 2019,
+              <https://www.w3.org/TR/2019/REC-webauthn-1-20190304/>.
+
+Acknowledgements
+
+   Thanks to Mark Nottingham for valuable comments and suggestions.
+   Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area
+   Director sponsorship of this specification.  Thanks to Amanda Baber,
+   Sarah Banks, Alissa Cooper, Roman Danyliw, Murray Kucherawy, Paul
+   Kyzivat, Barry Leiba, Hilarie Orman, Magnus Westerlund, and Robert
+   Wilton for their reviews.
+
+Authors' Addresses
+
+   Jeff Hodges
+   Google
+   1600 Amphitheatre Parkway
+   Mountain View, CA 94043
+   United States of America
+
+   Email: jdhodges@google.com
+   URI:   https://kingsmountain.com/people/Jeff.Hodges/
+
+
+   Giridhar Mandyam
+   Qualcomm Technologies Inc.
+   5775 Morehouse Drive
+   San Diego, CA 92121
+   United States of America
+
+   Phone: +1 858 651 7200
+   Email: mandyam@qti.qualcomm.com
+
+
+   Michael B. Jones
+   Microsoft
+
+   Email: mbj@microsoft.com
+   URI:   https://self-issued.info/