Skip to main content

Fully-Specified Algorithms for JOSE and COSE
draft-ietf-jose-fully-specified-algorithms-02

Document Type Active Internet-Draft (jose WG)
Authors Michael B. Jones , Orie Steele
Last updated 2024-02-28
Replaces draft-jones-jose-fully-specified-algorithms
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-jose-fully-specified-algorithms-02
JOSE Working Group                                            M.B. Jones
Internet-Draft                                    Self-Issued Consulting
Updates: 7518, 8037, 9053 (if approved)                        O. Steele
Intended status: Standards Track                               Transmute
Expires: 31 August 2024                                 28 February 2024

              Fully-Specified Algorithms for JOSE and COSE
             draft-ietf-jose-fully-specified-algorithms-02

Abstract

   This specification refers to cryptographic algorithm identifiers that
   fully specify the cryptographic operations to be performed, including
   any curve, key derivation function (KDF), hash functions, etc., as
   being "fully specified".  Whereas, it refers to cryptographic
   algorithm identifiers that require additional information beyond the
   algorithm identifier to determine the cryptographic operations to be
   performed as being "polymorphic".  This specification creates fully-
   specified algorithm identifiers for all registered JOSE and COSE
   polymorphic algorithm identifiers, enabling applications to use only
   fully-specified algorithm identifiers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 31 August 2024.

Copyright Notice

   Copyright (c) 2024 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.

Jones & Steele           Expires 31 August 2024                 [Page 1]
Internet-Draft         Fully-Specified Algorithms          February 2024

   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation and Conventions . . . . . . . . . .   4
   2.  Fully-specified Digital Signature Algorithm Identifiers . . .   4
     2.1.  Elliptic Curve Digital Signature Algorithm (ECDSA)  . . .   4
     2.2.  Edwards-Curve Digital Signature Algorithm (EdDSA) . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  JOSE Algorithms Registrations . . . . . . . . . . . . . .   5
       3.1.1.  Fully-Specified JOSE Algorithm Registrations  . . . .   5
       3.1.2.  Deprecated Polymorphic JOSE Algorithm
               Registrations . . . . . . . . . . . . . . . . . . . .   6
     3.2.  COSE Algorithms Registrations . . . . . . . . . . . . . .   6
       3.2.1.  Fully-Specified COSE Algorithm Registrations  . . . .   6
       3.2.2.  Deprecated Polymorphic COSE Algorithm
               Registrations . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Updated Review Instructions for Designated Experts  . . .   7
       3.3.1.  JSON Web Signature and Encryption Algorithms  . . . .   7
       3.3.2.  COSE Algorithms . . . . . . . . . . . . . . . . . . .   8
   4.  Key Representations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Fully-Specified Computations Using Multiple Algorithms  . . .   8
   6.  Notes on Algorithms Not Updated . . . . . . . . . . . . . . .   9
     6.1.  Algorithms for Signing with RSASSA-PKCS1-v1_5 . . . . . .   9
     6.2.  ECDH-ES and its Ephemeral Keys  . . . . . . . . . . . . .   9
     6.3.  KEMs and Encapsulated Keys  . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The IANA algorithm registries for JOSE [IANA.JOSE.Algorithms] and
   COSE [IANA.COSE.Algorithms] contain two kinds of algorithm
   identifiers:

Jones & Steele           Expires 31 August 2024                 [Page 2]
Internet-Draft         Fully-Specified Algorithms          February 2024

   Fully Specified
      Those that fully determine the cryptographic operations to be
      performed, including any curve, key derivation function (KDF),
      hash functions, etc.  Examples are RS256 and ES256K in both JOSE
      and COSE and ES256 in JOSE.

   Polymorphic
      Those requiring information beyond the algorithm identifier to
      determine the cryptographic operations to be performed.  Such
      additional information could include the actual key value and a
      curve that it uses.  Examples are EdDSA in both JOSE and COSE and
      ES256 in COSE.

   This matters because many protocols negotiate supported operations
   using only algorithm identifiers.  For instance, OAuth Authorization
   Server Metadata [RFC8414] uses negotiation parameters like these
   (from an example in the specification):

     "token_endpoint_auth_signing_alg_values_supported":
       ["RS256", "ES256"]

   OpenID Connect Discovery [OpenID.Discovery] likewise negotiates
   supported algorithms using alg and enc values.  W3C Web
   Authentication [WebAuthn] and FIDO Client to Authenticator Protocol
   (CTAP) [FIDO2] negotiate using COSE alg numbers.

   This does not work for polymorphic algorithms.  For instance, with
   EdDSA, you do not know which of the curves Ed25519 and/or Ed448 are
   supported!  This causes real problems in practice.

   WebAuthn contains this de-facto algorithm definition to work around
   this problem:

     -8 (EdDSA), where crv is 6 (Ed25519)

   This redefines the COSE EdDSA algorithm identifier for the purposes
   of WebAuthn to restrict it to using the Ed25519 curve - making it
   non-polymorphic so that algorithm negotiation can succeed, but also
   effectively eliminating the possibility of using Ed448.  Other
   similar workarounds for polymorphic algorithm identifiers are used in
   practice.

   This specification creates fully-specified algorithm identifiers for
   all registered polymorphic JOSE and COSE algorithms and their
   parameters, enabling applications to use only fully-specified
   algorithm identifiers.  It furthermore deprecates the practice of
   registering polymorphic algorithm identifiers.

Jones & Steele           Expires 31 August 2024                 [Page 3]
Internet-Draft         Fully-Specified Algorithms          February 2024

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.  Fully-specified Digital Signature Algorithm Identifiers

   This section creates fully-specified digital signature algorithm
   identifiers for all registered polymorphic JOSE and COSE algorithms
   and their parameters.

2.1.  Elliptic Curve Digital Signature Algorithm (ECDSA)

   [RFC9053] defines the current use of the Elliptic Curve Digital
   Signature Algorithm (ECDSA) by COSE.  The COSE algorithm
   registrations for ECDSA are polymorphic, since they do not specify
   the curve used.  For instance, ES256 is defined as "ECDSA w/ SHA-256"
   in Section 2.1 of [RFC9053].  (The corresponding JOSE registrations
   in [RFC7518] are full-specified.)

   The following fully-specified COSE algorithms are defined:

    +========+=================+===================+==================+
    | Name   | COSE Value      | Description       | COSE Recommended |
    +========+=================+===================+==================+
    | ESP256 | TBD (requested  | ECDSA using P-256 | Yes              |
    |        | assignment -9)  | curve and SHA-256 |                  |
    +--------+-----------------+-------------------+------------------+
    | ESP384 | TBD (requested  | ECDSA using P-384 | Yes              |
    |        | assignment -48) | curve and SHA-384 |                  |
    +--------+-----------------+-------------------+------------------+
    | ESP512 | TBD (requested  | ECDSA using P-521 | Yes              |
    |        | assignment -49) | curve and SHA-512 |                  |
    +--------+-----------------+-------------------+------------------+

                      Table 1: ECDSA Algorithm Values

2.2.  Edwards-Curve Digital Signature Algorithm (EdDSA)

   [RFC8037] defines the current use of the Edwards-Curve Digital
   Signature Algorithm (EdDSA) by JOSE and [RFC9053] defines its current
   use by COSE.  Both register polymorphic EdDSA algorithm identifiers.

   The following fully-specified JOSE and COSE algorithms are defined:

Jones & Steele           Expires 31 August 2024                 [Page 4]
Internet-Draft         Fully-Specified Algorithms          February 2024

    +=======+============+=============+================+=============+
    |Name   | COSE Value | Description | JOSE           | COSE        |
    |       |            |             | Implementation | Recommended |
    |       |            |             | Requirements   |             |
    +=======+============+=============+================+=============+
    |Ed25519| TBD        | EdDSA using | Optional       | No          |
    |       | (requested | Ed25519     |                |             |
    |       | assignment | curve       |                |             |
    |       | -50)       |             |                |             |
    +-------+------------+-------------+----------------+-------------+
    |Ed448  | TBD        | EdDSA using | Optional       | No          |
    |       | (requested | Ed448 curve |                |             |
    |       | assignment |             |                |             |
    |       | -51)       |             |                |             |
    +-------+------------+-------------+----------------+-------------+

                      Table 2: EdDSA Algorithm Values

3.  IANA Considerations

3.1.  JOSE Algorithms Registrations

   This section registers the following values in the IANA "JSON Web
   Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]
   established by [RFC7515].

3.1.1.  Fully-Specified JOSE Algorithm Registrations

   *  Algorithm Name: Ed25519
   *  Algorithm Description: EdDSA using Ed25519 curve
   *  Algorithm Usage Locations: alg
   *  JOSE Implementation Requirements: Optional
   *  Change Controller: IESG
   *  Reference: Section 2.2 of [[ this specification ]]
   *  Algorithm Analysis Document(s): [RFC8032]

   *  Algorithm Name: Ed448
   *  Algorithm Description: EdDSA using Ed448 curve
   *  Algorithm Usage Locations: alg
   *  JOSE Implementation Requirements: Optional
   *  Change Controller: IESG
   *  Reference: Section 2.2 of [[ this specification ]]
   *  Algorithm Analysis Document(s): [RFC8032]

Jones & Steele           Expires 31 August 2024                 [Page 5]
Internet-Draft         Fully-Specified Algorithms          February 2024

3.1.2.  Deprecated Polymorphic JOSE Algorithm Registrations

   The following registration is updated to change its status to
   Deprecated.

   *  Algorithm Name: EdDSA
   *  Algorithm Description: EdDSA signature algorithms
   *  Algorithm Usage Locations: alg
   *  JOSE Implementation Requirements: Deprecated
   *  Change Controller: IESG
   *  Reference: Section 3.1 of RFC8037
   *  Algorithm Analysis Document(s): [RFC8032]

3.2.  COSE Algorithms Registrations

   This section registers the following values in the IANA "COSE
   Algorithms" registry [IANA.COSE.Algorithms].

3.2.1.  Fully-Specified COSE Algorithm Registrations

   *  Name: ESP256
   *  Value: TBD (requested assignment -9)
   *  Description: ECDSA using P-256 curve and SHA-256
   *  Reference: Section 2.1 of this document
   *  Recommended: Yes

   *  Name: ESP384
   *  Value: TBD (requested assignment -48)
   *  Description: ECDSA using P-384 curve and SHA-384
   *  Reference: Section 2.1 of this document
   *  Recommended: Yes

   *  Name: ESP512
   *  Value: TBD (requested assignment -49)
   *  Description: ECDSA using P-521 curve and SHA-512
   *  Reference: Section 2.1 of this document
   *  Recommended: Yes

   *  Name: Ed25519
   *  Value: TBD (requested assignment -50)
   *  Description: EdDSA using Ed25519 curve
   *  Reference: Section 2.2 of this document
   *  Recommended: Yes

Jones & Steele           Expires 31 August 2024                 [Page 6]
Internet-Draft         Fully-Specified Algorithms          February 2024

   *  Name: Ed448
   *  Value: TBD (requested assignment -51)
   *  Description: EdDSA using Ed448 curve
   *  Reference: Section 2.2 of this document
   *  Recommended: Yes

3.2.2.  Deprecated Polymorphic COSE Algorithm Registrations

   The following registrations are updated to change their status to
   Deprecated.

   *  Name: ES256
   *  Value: -7
   *  Description: ECDSA w/ SHA-256
   *  Reference: RFC 9053
   *  Recommended: Deprecated

   *  Name: ES384
   *  Value: -35
   *  Description: ECDSA w/ SHA-384
   *  Reference: RFC 9053
   *  Recommended: Deprecated

   *  Name: ES512
   *  Value: -36
   *  Description: ECDSA w/ SHA-512
   *  Reference: RFC 9053
   *  Recommended: Deprecated

   *  Name: EdDSA
   *  Value: -8
   *  Description: EdDSA
   *  Reference: RFC 9053
   *  Recommended: Deprecated

3.3.  Updated Review Instructions for Designated Experts

3.3.1.  JSON Web Signature and Encryption Algorithms

   IANA is directed to preserve the current reference to RFC 7518, and
   to add a reference to this section of this document.

Jones & Steele           Expires 31 August 2024                 [Page 7]
Internet-Draft         Fully-Specified Algorithms          February 2024

   The review instructions for the designated experts for the IANA "JSON
   Web Signature and Encryption Algorithms" registry
   [IANA.JOSE.Algorithms] in Section 7.1 of [RFC7518] have been updated
   to include an additional review criterion:

   *  Only fully-specified algorithm identifiers may be registered.
      Polymorphic algorithm identifiers must not be registered.

3.3.2.  COSE Algorithms

   IANA is directed to preserve the current references to RFC 9053 and
   RFC 9054, and to add a reference to this section of this document.

   The review instructions for the designated experts for the IANA "COSE
   Algorithms" registry [IANA.COSE.Algorithms] in Section 10.4 of
   [RFC9053] have been updated to include an additional review
   criterion:

   *  Only fully-specified algorithm identifiers may be registered.
      Polymorphic algorithm identifiers must not be registered.

4.  Key Representations

   The key representations for the new fully-specified algorithms
   defined by this specification are the same as those for the
   polymorphic algorithms that they replace, other than the alg value,
   if included.  For instance, the representation for a key used with
   the Ed25519 algorithm is the same as that specified in [RFC8037],
   except that the alg value would be Ed25519 rather than EdDSA, if
   included.

5.  Fully-Specified Computations Using Multiple Algorithms

   Both JOSE and COSE have operations that take multiple algorithms as
   parameters.  Encrypted objects in JOSE [RFC7516] use two algorithm
   identifiers: the first in the alg (Algorithm) Header Parameter, which
   specifies how to determine the content encryption key, and the second
   in the enc (Encryption Algorithm) Header Parameter, which specifies
   the content encryption algorithm.  Likewise, encrypted COSE objects
   can use multiple algorithms for corresponding purposes.

   Each of these multiple algorithms must be independently fully
   specified.  The operations performed by each of them MUST NOT vary
   when used alongside other algorithms.  So for instance, for JOSE, alg
   values and enc values MUST each be fully specified, and their
   behaviors MUST NOT depend upon one another.

Jones & Steele           Expires 31 August 2024                 [Page 8]
Internet-Draft         Fully-Specified Algorithms          February 2024

6.  Notes on Algorithms Not Updated

   The working group has discussed some existing algorithms that are not
   updated by this specification.  This section discusses why they have
   not been updated.

6.1.  Algorithms for Signing with RSASSA-PKCS1-v1_5

   The working group has discussed whether the RS256, RS384, and RS512
   algorithms should be considered fully-specified or not, because they
   can operate on keys of different sizes.  For instance, they can use
   both 2048- and 4096-bit keys.  The same is true of the PS*
   algorithms.

   This is not a problem in practice, because RSA libraries accomodate
   keys of different sizes without having to use different code.
   Therefore, for example, there are not known cases in the wild where
   it would be useful to have different algorithm identifiers for
   RSASSA-PKCS1-v1_5 with SHA-256 and 2048-bit keys and RSASSA-
   PKCS1-v1_5 with SHA-256 and 4096-bit keys or 8192-bit keys.
   Therefore, the RSA signature algorithms are not replaced by this
   specification.

6.2.  ECDH-ES and its Ephemeral Keys

   The working group has discussed whether the ECDH-ES key agreement
   algorithm should be considered fully-specified or not, because it can
   use ephemeral keys of different key types and algorithms.  Indeed, an
   implementation might work when ECDH-ES is used with a ephemeral keys
   using the P-256 curve, and not work when used with ephemeral keys
   using the Ed25519 curve.

   One way that protocols can handle this situation is to use a
   discovery mechanism to declare what ephemeral key types are
   supported.  The alternative would be to introduce new fully-specified
   algorithm identifiers for choices such as "ECDH-ES with the P-256
   Curve", etc.  Feedback from deployers would be useful in determining
   what actions this specification should take in this case.

6.3.  KEMs and Encapsulated Keys

   All key encapsulation mechanisms (KEM) algorithms, as described in
   [NIST.PQC-API], provide three functions: KeyGen(), Encapsulate(), and
   Decapsulate().  In order to consider a KEM algorithm fully specified,
   there MUST be a single KDF used per KEM Algorithm.  For example, the
   HPKE KEM "0x0010 or DHKEM(P-256, HKDF-SHA256)", as defined in
   [RFC9180], is fully specified, because it uses a single elliptic
   curve (secp256r1) and a single KDF (HKDF with SHA256), as described

Jones & Steele           Expires 31 August 2024                 [Page 9]
Internet-Draft         Fully-Specified Algorithms          February 2024

   in [RFC5869].

7.  Security Considerations

   Using fully-specified algorithm identifiers reduces the attack
   surface relative to using polymorphic algorithm identifiers, since it
   reduces the opportunity for attackers to choose algorithms.

   The security considerations for ECDSA in [RFC7518], for EdDSA in
   [RFC8037], and for ECDSA and EdDSA in [RFC9053] apply.

8.  References

8.1.  Normative References

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

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
              and Signatures in JSON Object Signing and Encryption
              (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
              <https://www.rfc-editor.org/info/rfc8037>.

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

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/info/rfc9053>.

8.2.  Informative References

Jones & Steele           Expires 31 August 2024                [Page 10]
Internet-Draft         Fully-Specified Algorithms          February 2024

   [FIDO2]    Bradley, J., Hodges, J., Jones, M., Kumar, A., and J.
              Johan, "Client to Authenticator Protocol (CTAP)", FIDO
              Alliance Proposed Standard, 15 June 2021,
              <https://fidoalliance.org/specs/fido-v2.1-ps-20210615/
              fido-client-to-authenticator-protocol-v2.1-ps-
              20210615.html>.

   [IANA.COSE.Algorithms]
              IANA, "COSE Algorithms",
              <https://www.iana.org/assignments/cose/
              cose.xhtml#algorithms>.

   [IANA.JOSE.Algorithms]
              IANA, "JOSE Algorithms",
              <https://www.iana.org/assignments/jose/jose.xhtml#web-
              signature-encryption-algorithms>.

   [NIST.PQC-API]
              National Institute of Standards and Technology (NIST),
              "PQC-API", <https://csrc.nist.gov/CSRC/media/Projects/
              Post-Quantum-Cryptography/documents/example-files/api-
              notes.pdf>.

   [OpenID.Discovery]
              Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,
              "OpenID Connect Discovery 1.0", 8 November 2014,
              <https://openid.net/specs/openid-connect-discovery-
              1_0.html>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/info/rfc7518>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

Jones & Steele           Expires 31 August 2024                [Page 11]
Internet-Draft         Fully-Specified Algorithms          February 2024

   [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/info/rfc9180>.

   [WebAuthn] Hodges, J., Jones, J.C., Jones, M., Kumar, A., and E.
              Lundberg, "Web Authentication: An API for accessing Public
              Key Credentials - Level 2", World Wide Web Consortium
              (W3C) Recommendation, 8 April 2021,
              <https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>.

Appendix A.  Document History

   [[ to be removed by the RFC Editor before publication as an RFC ]]

   -02

   *  Expanded references for KEMs.

   *  Added example of a fully-specified KEM.

   -01

   *  Included additional instructions for IANA.

   *  Added text on KEMs and Encapsulated keys.

   *  Added the section Fully-Specified Computations Using Multiple
      Algorithms.

   -00

   *  Created initial working group version based on draft-jones-jose-
      fully-specified-algorithms-02.

Acknowledgements

   The authors thank John Bradley, Brian Campbell, Ilari Liusvarra,
   Tobias Looker, and Filip Skokan for their contributions to this
   specification.

Authors' Addresses

   Michael B. Jones
   Self-Issued Consulting
   Email: michael_b_jones@hotmail.com
   URI:   https://self-issued.info/

Jones & Steele           Expires 31 August 2024                [Page 12]
Internet-Draft         Fully-Specified Algorithms          February 2024

   Orie Steele
   Transmute
   Email: orie@transmute.industries

Jones & Steele           Expires 31 August 2024                [Page 13]