Skip to main content

Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
RFC 7165

Document Type RFC - Informational (April 2014)
Author Richard Barnes
Last updated 2015-10-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Sean Turner
Send notices to (None)
RFC 7165
S3 Use cryptographic algorithms in a manner compatible with major
      validation processes.  For example, if typical validation
      standards allow algorithm A to be used for purpose X but not
      purpose Y, then JOSE should not recommend using algorithm A for
      purpose Y.

   S4 Support operation with or without pre-negotiation.  It must be
      possible to create or process secure objects without any
      configuration beyond key provisioning.  If it is possible for keys
      to be derived from application context, it must be possible for a
      recipient to recognize when it does not have the appropriate key.

6.3.  Desiderata

   D1 Maximize compatibility with the W3C Web Crypto specifications,
      e.g., by coordinating with the Web Crypto working group to
      encourage alignment of algorithms and algorithm identifiers.

   D2 Avoid JSON canonicalization to the extent possible.  That is, all
      other things being equal, techniques that rely on fixing a
      serialization of an object (e.g., by encoding it with base64url)
      are preferred over those that require converting an object to a
      canonical form.

   D3 Maximize the extent to which the inputs and outputs of JOSE
      cryptographic operations can be controlled by the applications, as
      opposed to involving processing specific to JOSE.  This allows
      JOSE the flexibility to address the needs of many cryptographic
      protocols.  For example, in some cases, it might allow JOSE
      objects to be translated to legacy formats such as CMS without the
      need for re-encryption or re-signing.

7.  Security Considerations

   The primary focus of this document is the requirements for a JSON-
   based secure object format.  At the level of general security
   considerations for object-based security technologies, the security
   considerations for this format are the same as for CMS [RFC5652].
   The primary difference between the JOSE format and CMS is that JOSE
   is based on JSON, which does not have a canonical representation.
   The lack of a canonical form means that it is difficult to determine
   whether two JSON objects represent the same information, which could
   lead to vulnerabilities in some usages of JOSE.

Barnes                        Informational                    [Page 20]
RFC 7165                     JOSE Use Cases                   April 2014

8.  References

8.1.  Normative References

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [RFC6708]  Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", RFC 6708, September 2012.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

   [W3C.REC-xml]
              Bray, T., Maler, E., Paoli, J., and C. Sperberg-McQueen,
              "Extensible Markup Language (XML) 1.0 (Fifth Edition)",
              W3C Recommendation, November 2008,
              <http://www.w3.org/TR/2008/REC-xml-20081126/>.

   [WebCrypto]
              Dahl, D. and R. Sleevi, "Web Cryptography API", W3C
              Working Draft, January 2013,
              <http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>.

8.2.  Informative References

   [ALERT-REQ]
              Schulzrinne, H., Norreys, S., Rosen, B., and H.
              Tschofenig, "Requirements, Terminology and Framework for
              Exigent Communications", Work in Progress, March 2012.

   [ALTO]     Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO
              Protocol", Work in Progress, March 2014.

   [CAP]      Botterell, A. and E. Jones, "Common Alerting Protocol,
              v1.1", OASIS Standard CAP-V1.1, October 2005,
              <http://www.oasis-open.org/committees/download.php/15135/
              emergency-CAPv1.1-Corrected_DOM.pdf>.

Barnes                        Informational                    [Page 21]
RFC 7165                     JOSE Use Cases                   April 2014

   [CONSTRAINED]
              Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained Node Networks", Work in Progress, March 2014.

   [CoAP]     Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", Work in Progress, June 2013.

   [ITU.X690.2002]
              International Telecommunications Union, "Information
              Technology - ASN.1 encoding rules: Specification of Basic
              Encoding Rules (BER), Canonical Encoding Rules (CER) and
              Distinguished Encoding Rules (DER)", ITU-T Recommendation
              X.690, July 2002.

   [JWA]      Jones, M., "JSON Web Algorithms (JWA)", Work in Progress,
              March 2014.

   [JWE]      Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              Work in Progress, March 2014.

   [JWK]      Jones, M., "JSON Web Key (JWK)", Work in Progress, March
              2014.

   [JWS]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", Work in Progress, March 2014.

   [JWT-BEARER]
              Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
              (JWT) Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", Work in Progress, March 2014.

   [JWT]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", Work in Progress, March 2014.

   [OASIS.saml-core-2.0-os]
              Cantor, S., Kemp, J., Maler, E., and R. Philpott,
              "Assertions and Protocols for the OASIS Security Assertion
              Markup Language (SAML) V2.0", Oasis Standard, March 2005,
              <http://docs.oasis-open.org/security/saml/v2.0/
              saml-core-2.0-os.pdf>.

   [OpenID.Core]
              Bradley, J., de Medeiros, B., Jones, M., Mortimore, C.,
              and N. Sakimura, "OpenID Connect Core 1.0", December 2013,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [Persona]  Mozilla Developer Network, "Mozilla Persona", April 2013,
              <https://developer.mozilla.org/en-US/docs/Persona>.

Barnes                        Informational                    [Page 22]
RFC 7165                     JOSE Use Cases                   April 2014

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3923]  Saint-Andre, P., "End-to-End Signing and Object Encryption
              for the Extensible Messaging and Presence Protocol
              (XMPP)", RFC 3923, October 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750, October 2012.

   [SAML2]    Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
              Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", Work in Progress, March 2014.

   [W3C.xmldsig-core]
              Eastlake, D., Reagle, J., and D. Solo, "XML-Signature
              Syntax and Processing", W3C Recommendation, June 2008,
              <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.

   [W3C.xmlenc-core]
              Eastlake, D. and J. Reagle, "XML Encryption Syntax and
              Processing", W3C Candidate Recommendation, December 2002,
              <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.

Barnes                        Informational                    [Page 23]
RFC 7165                     JOSE Use Cases                   April 2014

   [WS-Federation]
              Goodner, M., Kaler, C., McIntosh, M., and A. Nadalin, "Web
              Services Federation Language (WS-Federation) Version 1.2",
              Oasis Standard, May 2009, <http://docs.oasis-open.org/
              wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html>.

   [XMPP-E2E] Miller, M., "End-to-End Object Encryption and Signatures
              for the Extensible Messaging and Presence Protocol
              (XMPP)", Work in Progress, June 2013.

Barnes                        Informational                    [Page 24]
RFC 7165                     JOSE Use Cases                   April 2014

Appendix A.  Acknowledgements

   Thanks to Matt Miller for discussions related to the XMPP end-to-end
   security model and to Mike Jones for considerations related to
   security tokens and XML security.  Thanks to Mark Watson for raising
   the need for representing symmetric keys and binding attributes to
   them.  Thanks to Ludwig Seitz for contributing the constrained device
   use case.

Author's Address

   Richard Barnes
   Mozilla
   331 E. Evelyn Ave.
   Mountain View, CA  94041
   US

   EMail: rlb@ipv.sx

Barnes                        Informational                    [Page 25]