Internet DRAFT - draft-bormann-jose-cose
draft-bormann-jose-cose
JOSE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Informational October 27, 2014
Expires: April 30, 2015
Constrained Object Signing and Encryption (COSE)
draft-bormann-jose-cose-00
Abstract
COSE provides services similar to JSON Web Signature (JWS), JSON Web
Encryption (JWE), and JSON Web Key (JWK), making use of JSON Web
Algorithms (JWA), for data encoded in the Concise Binary Object
Representation (CBOR).
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 http://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 April 30, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://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.
Bormann Expires April 30, 2015 [Page 1]
Internet-Draft COSE October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Constrained nodes and networks of constrained nodes [RFC7228] pose
some specific requirements on data representation that may make it
difficult to apply existing object security standards to this space.
In constrained node networks, message payloads are often small (by
nature of the data exchanged), and both transmission systems (e.g.,
[RFC4944]) and application protocols (e.g., [RFC7252]) are optimized
for these small interchanges. As a result, fixed-size overheads
introduced by security protocols may be much more detrimental than in
a traditional Web environment. Transmission/reception of messages
requires power, turning a system that on average might consume
~100 [micro]W into a 50 mW consumer while communicating. This is a
strong incentive to keep message sizes reasonably small. It is not
often possible to rely on compression to achieve this, as compression
requires CPU power, RAM, and code space, which all are rather
constrained in these environments; compression also works better for
larger messages.
Handling messages requires RAM, the total available size of which on
a constrained node may be on the order of 10 KiB (note that apart
from security, most of this RAM is already needed for operating
system, network stack, sensor management, application processing,
etc.). Protocols that require copying data, or, worse, re-encoding
and escape processing, can double or triple those RAM requirements.
All the processing that is to be performed in a constrained node
requires code space in Flash, the total available size of which on a
constrained node may be on the order of 100 KiB (with the same note
applying as above). This leads to a strong requirement to minimize
Bormann Expires April 30, 2015 [Page 2]
Internet-Draft COSE October 2014
code complexity, and in particular to avoid having to implement
multiple different ways to do the same thing.
Still, security is not optional.
1.1. Objectives
The JOSE set of specifications provides an attractive set of
functions for the constrained space, even if its breadth of optional
functionality may go beyond what is required there. The present
specification aims to make use of the substantial amount of work that
went into making JOSE such a comprehensive specification.
JOSE makes use of JSON [RFC7159], a text based data representation
format. For applications in constrained nodes, the Concise Binary
Object Representation format (CBOR) provides a more compact
representation that is still largely based on the same principles.
By using CBOR, the present specification can:
o avoid the use of base64 coding of binary data. Base64 coding
causes message expansion, which is detrimental to energy
requirements. In an implementation, it also causes the
requirement for creating copies of some data, which increases RAM
requirements.
o avoid JSON-encoding of data. Again, this causes some message
expansion, requires creating copies for escape processing, but
also requires considerable code size, including for binary-to-
decimal conversion.
o potentially make use of CBOR's capability to minimize strings by
enumerating frequently occurring member names. This again helps
to reduce message sizes, but also can save some code space. (This
is a secondary, but useful objective.)
1.2. COSE
COSE provides services similar to JSON Web Signature (JWS)
[I-D.ietf-jose-json-web-signature], JSON Web Encryption (JWE)
[I-D.ietf-jose-json-web-encryption], and JSON Web Key (JWK)
[I-D.ietf-jose-json-web-key], making use of JSON Web Algorithms (JWA)
[I-D.ietf-jose-json-web-algorithms], in conjunction with data
encoding in the Concise Binary Object Representation (CBOR)
[RFC7049].
Bormann Expires April 30, 2015 [Page 3]
Internet-Draft COSE October 2014
1.3. Terminology
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 RFC
2119 [RFC2119].
The term "byte" is used in its now customary sense as a synonym for
"octet".
2. Specification
Presently, we believe the entire specification of COSE can be reduced
to the following:
COSE is exactly like JOSE, except that:
o each use of JSON is replaced by the equivalent use of CBOR;
o base64-encoding is never done:
* where the output of the base64url function was to be used as a
JSON string, instead the input to the base64url function is
represented as a byte string in CBOR
* where the output of the base64url function was to be used as an
input to a cryptographic algorithm, instead the input is used
directly
* where the output of the base64url function was to be joined by
ASCII dots (".") with other such outputs, CBOR encoding of an
array built from the inputs, each represented as a byte string,
is used.
o (probably:) certain member names ("alg"...) are replaced by a
number of predefined numeric replacements only in the key
positions of maps (JSON objects) defined by JOSE. Only the names
most likely to be frequently occurring in constrained node
networks are entered into a static table to be defined in this
specification. (There is no future extension planned for this
table.)
3. Examples
(TBD, to cover large parts of [I-D.ietf-jose-cookbook]).
Bormann Expires April 30, 2015 [Page 4]
Internet-Draft COSE October 2014
4. IANA considerations
(TBD)
5. Security considerations
(TBD)
6. Acknowledgments
This document obviously owes a lot to the work of the entire JOSE
working group, including the feedback during an initial presentation
at IETF 90 [1]. Richard Barnes' Python implementation of JOSE was
instrumental in confirming the feasibility of the COSE approach.
7. References
7.1. Normative References
[I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
json-web-algorithms-36 (work in progress), October 2014.
[I-D.ietf-jose-json-web-encryption]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption-36 (work in progress),
October 2014.
[I-D.ietf-jose-json-web-key]
Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key-36 (work in progress), October 2014.
[I-D.ietf-jose-json-web-signature]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature-36
(work in progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013.
7.2. Informative References
Bormann Expires April 30, 2015 [Page 5]
Internet-Draft COSE October 2014
[I-D.ietf-jose-cookbook]
Miller, M., "Examples of Protecting Content using
JavaScript Object Signing and Encryption (JOSE)", draft-
ietf-jose-cookbook-05 (work in progress), October 2014.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
7.3. URIs
[1] http://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires April 30, 2015 [Page 6]
