< draft-tschofenig-tls-cwt-00.txt		draft-tschofenig-tls-cwt-01.txt >
	TLS H. Tschofenig		TLS H. Tschofenig
	Internet-Draft M. Brossard		Internet-Draft M. Brossard
	Intended status: Standards Track Arm Limited		Intended status: Standards Track Arm Limited
	Expires: September 12, 2019 March 11, 2019		Expires: May 7, 2020 November 04, 2019
	Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and		Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and
	Datagram Transport Layer Security (DTLS)		Datagram Transport Layer Security (DTLS)
	draft-tschofenig-tls-cwt-00		draft-tschofenig-tls-cwt-01
	Abstract		Abstract
	The TLS protocol supports different credentials, including pre-shared		The TLS protocol supports different credentials, including pre-shared
	keys, raw public keys, and X.509 certificates. For use with public		keys, raw public keys, and X.509 certificates. For use with public
	key cryptography developers have to decide between raw public keys,		key cryptography developers have to decide between raw public keys,
	which require out-of-band agreement and full-fletched X.509		which require out-of-band agreement and full-fletched X.509
	certificates. For devices where the reduction of code size is		certificates. For devices where the reduction of code size is
	important it is desirable to minimize the use of X.509-related		important it is desirable to minimize the use of X.509-related
	libraries. With the CBOR Web Token (CWT) a structure has been		libraries. With the CBOR Web Token (CWT) a structure has been
	defined that allows CBOR-encoded claims to be protected with CBOR		defined that allows CBOR-encoded claims to be protected with CBOR
	Object Signing and Encryption (COSE).		Object Signing and Encryption (COSE).
	This document registers a new value to the "TLS Certificate Types"		This document registers a new value to the "TLS Certificate Types"
	subregistry to allow TLS and DTLS to use CWTs. Conceptually, CWTs		sub-registry to allow TLS and DTLS to use CWTs. Conceptually, CWTs
	can be seen as a certificate format (when with public key		can be seen as a certificate format (when with public key
	cryptography) or a Kerberos ticket (when used with symmetric key		cryptography) or a Kerberos ticket (when used with symmetric key
	cryptography).		cryptography).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 12, 2019.		This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 52 ¶		skipping to change at page 2, line 52 ¶
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 8
	Appendix B. Working Group Information . . . . . . . . . . . . . 8		Appendix B. Working Group Information . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	The CBOR Web Token (CWT) [RFC8392] was defined as the CBOR-based		The CBOR Web Token (CWT) [RFC8392] was defined as the CBOR-based
	version of the JSON Web Token (JWT) [RFC7519]. JWT is used		version of the JSON Web Token (JWT) [RFC7519]. JWT is used
	extensibly on Web application and for use with Internet of Things		extensively on Web application and for use with Internet of Things
	environments the believe is that a more lightweight encoding, namely		environments the believe is that a more lightweight encoding, namely
	CBOR, is needed. CWTs, like JWTs, contain claims and those claims		CBOR, is needed. CWTs, like JWTs, contain claims and those claims
	are protected against modifications using COSE [RFC8152]. CWTs are		are protected against modifications using COSE [RFC8152]. CWTs are
	flexible with regard to the use of cryptography and hence CWTs may be		flexible with regard to the use of cryptography and hence CWTs may be
	protected using a keyed message digest, or a digital signature. One		protected using a keyed message digest, or a digital signature. One
	of the claims allows keys to be included, as described in		of the claims allows keys to be included, as described in
	[I-D.ietf-ace-cwt-proof-of-possession]. This specification makes use		[I-D.ietf-ace-cwt-proof-of-possession]. This specification makes use
	of these proof-of-possession claims in CWTs.		of these proof-of-possession claims in CWTs. This document mandates
			a minimum number of claims to be present in a CWT. There may,
			however, be a number of additional claims present in a CWT. An
			example of a token with a larger number of claims is the Entity
			Attestation Token (EAT), which may also be encoded as a CWT.
	Fundamentially, there are two types of keys that can be used with		Fundamentally, there are two types of keys that can be used with
	CWTs:		CWTs:
	- Asymmetric keys: In this case a CWT contains a COSE_Key [RFC8152]		- Asymmetric keys: In this case a CWT contains a COSE_Key [RFC8152]
	representing an asymmetric public key. To protect the CWT against		representing an asymmetric public key. To protect the CWT against
	modifications the CWT also needs to be digitally signed.		modifications the CWT also needs to be digitally signed.
	- Symmetric keys: In this case a CWT contains a Encrypted_COSE_Key		- Symmetric keys: In this case a CWT contains the Encrypted_COSE_Key
	[RFC8152] representing a symmetric key encrypted to a key known to		[RFC8152] structure representing a symmetric key encrypted to a
	the recipient using COSE_Encrypt or COSE_Encrypt0. Again, to		key known to the recipient using COSE_Encrypt or COSE_Encrypt0.
	protect the CWT against modifications a keyed message digest is		Again, to protect the CWT against modifications a keyed message
	used.		digest is used.
	The CWT also allows mixing symmetric and asymmetric crypto although		The CWT also allows mixing symmetric and asymmetric crypto although
	this is less likely to be used in practice.		this is less likely to be used in practice.
	Exchanging CWTs in the TLS / DTLS handshake offers an alternative to		Exchanging CWTs in the TLS / DTLS handshake offers an alternative to
	the use of raw public keys and X.509 certificates. Compared to raw		the use of raw public keys and X.509 certificates. Compared to raw
	public keys, CWTs allow more information to be included via the use		public keys, CWTs allow more information to be included via the use
	of claims. Compared to X.509 certificates CBOR offers an alternative		of claims. Compared to X.509 certificates CBOR offers an alternative
	encoding format, which may also be used by the application layer		encoding format, which may also be used by the application layer
	thereby potentially reducing the overall code size requirements.		thereby potentially reducing the overall code size requirements.
	2. Conventions and Terminology		2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	3. The CWT Certificate Type		3. The CWT Certificate Type
	This document defines a new value to the "TLS Certificate Types"		This document defines a new value to the "TLS Certificate Types" sub-
	subregistry and the value is defined as follows.		registry and the value is defined as follows.
	/* Managed by IANA */		/* Managed by IANA */
	enum {		enum {
	X509(0),		X509(0),
	RawPublicKey(2),		RawPublicKey(2),
	CWT(TBD),		CWT(TBD),
	(255)		(255)
	} CertificateType;		} CertificateType;
	struct {		struct {
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	CWTs without proof-of-possession keys MUST NOT be used.		CWTs without proof-of-possession keys MUST NOT be used.
	When CWTs are used with TLS 1.3 [RFC8446] and DTLS 1.3		When CWTs are used with TLS 1.3 [RFC8446] and DTLS 1.3
	[I-D.ietf-tls-dtls13] additional privacy properties are provided		[I-D.ietf-tls-dtls13] additional privacy properties are provided
	since most handshake messages are encrypted.		since most handshake messages are encrypted.
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to add a new value to the "TLS Certificate Types"		IANA is requested to add a new value to the "TLS Certificate Types"
	subregistry for CWTs.		sub-registry for CWTs.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-ace-cwt-proof-of-possession]		[I-D.ietf-ace-cwt-proof-of-possession]
	Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-		Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
	possession-06 (work in progress), February 2019.		possession-11 (work in progress), October 2019.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-30 (work in progress),		1.3", draft-ietf-tls-dtls13-33 (work in progress), October
	November 2018.		2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
	Weiler, S., and T. Kivinen, "Using Raw Public Keys in		Weiler, S., and T. Kivinen, "Using Raw Public Keys in
	Transport Layer Security (TLS) and Datagram Transport		Transport Layer Security (TLS) and Datagram Transport
	Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,		Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	[1] mailto:tls@ietf.org		[1] mailto:tls@ietf.org
	[2] https://www1.ietf.org/mailman/listinfo/tls		[2] https://www1.ietf.org/mailman/listinfo/tls
	[3] https://www.ietf.org/mail-archive/web/tls/current/index.html		[3] https://www.ietf.org/mail-archive/web/tls/current/index.html
	Appendix A. History		Appendix A. History
	RFC EDITOR: PLEASE REMOVE THE THIS SECTION		RFC EDITOR: PLEASE REMOVE THE THIS SECTION
	- Initial version		- -01: Minor editorial bugfixes and reference updates; refreshing
			draft
			- -00: Initial version
	Appendix B. Working Group Information		Appendix B. Working Group Information
	The discussion list for the IETF TLS working group is located at the		The discussion list for the IETF TLS working group is located at the
	e-mail address tls@ietf.org [1]. Information on the group and		e-mail address tls@ietf.org [1]. Information on the group and
	information on how to subscribe to the list is at		information on how to subscribe to the list is at
	https://www1.ietf.org/mailman/listinfo/tls [2]		https://www1.ietf.org/mailman/listinfo/tls [2]
	Archives of the list can be found at: https://www.ietf.org/mail-		Archives of the list can be found at: https://www.ietf.org/mail-
	archive/web/tls/current/index.html [3]		archive/web/tls/current/index.html [3]
End of changes. 13 change blocks.
	19 lines changed or deleted		26 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/