< draft-birkholz-rats-epoch-markers-00.txt		draft-birkholz-rats-epoch-markers-01.txt >
	RATS Working Group H. Birkholz		RATS Working Group H. Birkholz
	Internet-Draft Fraunhofer SIT		Internet-Draft Fraunhofer SIT
	Intended status: Standards Track T. Fossati		Intended status: Standards Track T. Fossati
	Expires: 29 October 2022 Arm Limited		Expires: 5 November 2022 Arm Limited
	W. Pan		W. Pan
	Huawei Technologies		Huawei Technologies
	C. Bormann		C. Bormann
	Universität Bremen TZI		Universität Bremen TZI
	27 April 2022		4 May 2022
	Epoch Markers		Epoch Markers
	draft-birkholz-rats-epoch-markers-00		draft-birkholz-rats-epoch-markers-01
	Abstract		Abstract
	Abstract Text		Abstract Text
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Status information for this document may be found at		Status information for this document may be found at
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 29 October 2022.		This Internet-Draft will expire on 5 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
	2. Epoch IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Epoch IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Interaction Models . . . . . . . . . . . . . . . . . . . . . 4		3. Interaction Models . . . . . . . . . . . . . . . . . . . . . 4
	4. Epoch Marker CDDL . . . . . . . . . . . . . . . . . . . . . . 4		4. Epoch Marker CDDL . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. RFC 3161 TSTInfo . . . . . . . . . . . . . . . . . . . . 6
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Normative References . . . . . . . . . . . . . . . . . . 6		5.1. Normative References . . . . . . . . . . . . . . . . . . 6
	5.2. Informative References . . . . . . . . . . . . . . . . . 7		5.2. Informative References . . . . . . . . . . . . . . . . . 6
			Appendix A. RFC 3161 TSTInfo . . . . . . . . . . . . . . . . . . 7
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	Systems that are required to interact via secure interactions often		Systems that are required to interact via secure interactions often
	require a shared understanding of the freshness of conveyed		require a shared understanding of the freshness of conveyed
	information, especially in the domain of remote attestation		information, especially in the domain of remote attestation
	procedures. Establishing a notion of freshness between various		procedures. Establishing a notion of freshness between various
	involved entities taking on roles that rely on information that is		involved entities taking on roles that rely on information that is
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	"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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Epoch IDs		2. Epoch IDs
	The RATS architecture introduces the concept of Epoch IDs that mark		The RATS architecture introduces the concept of Epoch IDs that mark
	certain events during remote attestation procedures ranging from		certain events during remote attestation procedures ranging from
	simple handshakes to rather complex interactions including elaborate		simple handshakes to rather complex interactions including elaborate
	freshness proofs. Epoch Markers are a solution that includes the		freshness proofs. The Epoch Markers defined in this document are a
	lessons learned from TSAs and provides several means to identify a		solution that includes the lessons learned from TSAs, the concept of
	new freshness epoch as illustrated by the RATS architecture.		Epoch IDs and provides several means to identify a new freshness
			epoch. Some of these methods are introduced and discussed in
			Section 10.3 of [I-D.ietf-rats-architecture].
	3. Interaction Models		3. Interaction Models
	The interaction models illustrated in this section are derived from		The interaction models illustrated in this section are derived from
	the RATS Reference Interaction Models. In general there are three of		the RATS Reference Interaction Models. In general there are three of
	them:		them:
	* unsolicited distribution (e.g., via uni-directional methods, such		* ad-hoc requests (e.g., via challenge-response requests addressed
	as broad- or multicasting from Epoch Bells)		at Epoch Bells), corresponding to Section 7.1 in
			[I-D.ietf-rats-reference-interaction-models]
	* solicited distribution (e.g., via a subscription to Epoch Bells)		* unsolicited distribution (e.g., via uni-directional methods, such
			as broad- or multicasting from Epoch Bells), corresponding to
			Section 7.2 in [I-D.ietf-rats-reference-interaction-models]
	* ad-hoc requests (e.g., via challenge-response requests addressed		* solicited distribution (e.g., via a subscription to Epoch Bells),
	at Epoch Bells)		corresponding to Section 7.3 in
			[I-D.ietf-rats-reference-interaction-models]
	4. Epoch Marker CDDL		4. Epoch Marker CDDL
	epoch-marker = [		epoch-marker = [
	header,		header,
	$payload,		$payload,
	]		]
	header = {		header = {
	? challenge-response-nonce,		? challenge-response-nonce,
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 9 ¶
	remote-attestation-evidence = (2: "PLEASE DEFINE")		remote-attestation-evidence = (2: "PLEASE DEFINE")
	remote-attestation-results = (3: "PLEASE DEFINE")		remote-attestation-results = (3: "PLEASE DEFINE")
	;payload types independent on interaction model		;payload types independent on interaction model
	$payload /= native-rfc3161-TST-info		$payload /= native-rfc3161-TST-info
	$payload /= TST-info-based-on-CBOR-time-tag		$payload /= TST-info-based-on-CBOR-time-tag
	$payload /= CBOR-time-tag		$payload /= CBOR-time-tag
	$payload /= multi-nonce		$payload /= multi-nonce
	$payload /= multi-nonce-list		$payload /= multi-nonce-list
	$payload /= strictly-monotonically-increasing-counter		$payload /= strictly-monotonically-increasing-counter
	native-rfc3161-TST-info = bytes ; DER-encoded value of TSTInfo
	TST-info-based-on-CBOR-time-tag = "PLEASE DEFINE"		native-rfc3161-TST-info = bytes ; DER-encoded value of TSTInfo
	; ~~~		; ~~~
	; ~~~ verbatim translation of ASN.1 TSTInfo into CDDL		; ~~~ translation with a few poetic licenses of ASN.1 TSTInfo into CDDL
	; ~~~ (GeneralName is TODO atm, due to its terrible callousness)
	; ~~~		; ~~~
			TST-info-based-on-CBOR-time-tag = {
	TSTInfo = {		&(version : 0) => int .default 1 ; obsolete?
	&(version : 0) => int .default 1
	&(policy : 1) => oid		&(policy : 1) => oid
	&(messageImprint : 2) => MessageImprint		&(messageImprint : 2) => MessageImprint
	&(serialNumber : 3) => int		&(serialNumber : 3) => int
	&(genTime : 4) => GeneralizedTime		&(eTime : 4) => profiled-etime
	? &(accuracy : 5) => Accuracy		? &(accuracy : 5) => rfc3161-accuracy
	&(ordering : 6) => bool .default false		&(ordering : 6) => bool .default false
	? &(nonce : 7) => int		? &(nonce : 7) => int
	? &(tsa : 8) => GeneralName		? &(tsa : 8) => GeneralName
	* $$TSTInfoExtensions		* $$TSTInfoExtensions
	}		}
			; based on COSE_Hash_Find (draft-ietf-cose-hash-algs)
	MessageImprint = [		MessageImprint = [
	hashAlgorithm: AlgorithmIdentifier		hashAlg : int
	hashedMessage: bytes		hashValue : bstr
	]
	AlgorithmIdentifier = [
	algorithm: oid
	? parameters: any
	]		]
	Accuracy = non-empty<{		rfc3161-accuracy = non-empty<{
	? &(seconds : 0) => int		? &(seconds : 0) => int
	? &(millis: 1) => 1..999		? &(millis: 1) => 1..999
	? &(micros: 2) => 1..999		? &(micros: 2) => 1..999
	}>		}>
	; https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5.2		; timeMap profiles etime from https://datatracker.ietf.org/doc/html/draft-ietf-cbor-time-tag
	GeneralizedTime = tstr .regexp '[0-9]{14}(\.[0-9]+)?Z'		profiled-etime = #6.1001(timeMap)
			timeMap = {
			1 => #6.1(int / float) ; TIME_T
			* int => any
			}
	GeneralName = "todo"		; Section 11.8 of I-D.ietf-cose-cbor-encoded-cert
			GeneralName = [ GeneralNameType : int, GeneralNameValue : any ]
	; stuff		; stuff
	oid = #6.111(bstr)		oid = #6.111(bstr)
	non-empty<M> = (M) .and ({ + any => any })		non-empty<M> = (M) .and ({ + any => any })
	CBOR-time-tag = [		CBOR-time-tag = [
	time-tag,		time-tag,
	? nonce		? nonce
	]		]
	time-tag = "PLEASE DEFINE"		time-tag = "PLEASE DEFINE"
	nonce = "PLEASE DEFINE"		nonce = "PLEASE DEFINE"
	multi-nonce = tstr / bstr / int		multi-nonce = tstr / bstr / int
	multi-nonce-list = [+ multi-nonce]		multi-nonce-list = [+ multi-nonce]
	strictly-monotonically-increasing-counter = uint ; counter context? per issuer? per indicator?		strictly-monotonically-increasing-counter = uint ; counter context? per issuer? per indicator?
	4.1. RFC 3161 TSTInfo
	TSTInfo ::= SEQUENCE {
	version INTEGER { v1(1) },
	policy TSAPolicyId,
	messageImprint MessageImprint,
	-- MUST have the same value as the similar field in
	-- TimeStampReq
	serialNumber INTEGER,
	-- Time-Stamping users MUST be ready to accommodate integers
	-- up to 160 bits.
	genTime GeneralizedTime,
	accuracy Accuracy OPTIONAL,
	ordering BOOLEAN DEFAULT FALSE,
	nonce INTEGER OPTIONAL,
	-- MUST be present if the similar field was present
	-- in TimeStampReq. In that case it MUST have the same value.
	tsa [0] GeneralName OPTIONAL,
	extensions [1] IMPLICIT Extensions OPTIONAL }
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	[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>.
	[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,		[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
	skipping to change at page 7, line 18 ¶		skipping to change at page 6, line 48 ¶
	5.2. Informative References		5.2. Informative References
	[I-D.ietf-rats-architecture]		[I-D.ietf-rats-architecture]
	Birkholz, H., Thaler, D., Richardson, M., Smith, N., and		Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
	W. Pan, "Remote Attestation Procedures Architecture", Work		W. Pan, "Remote Attestation Procedures Architecture", Work
	in Progress, Internet-Draft, draft-ietf-rats-architecture-		in Progress, Internet-Draft, draft-ietf-rats-architecture-
	15, 8 February 2022, <https://www.ietf.org/archive/id/		15, 8 February 2022, <https://www.ietf.org/archive/id/
	draft-ietf-rats-architecture-15.txt>.		draft-ietf-rats-architecture-15.txt>.
			[I-D.ietf-rats-reference-interaction-models]
			Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
			Interaction Models for Remote Attestation Procedures",
			Work in Progress, Internet-Draft, draft-ietf-rats-
			reference-interaction-models-05, 26 January 2022,
			<https://www.ietf.org/archive/id/draft-ietf-rats-
			reference-interaction-models-05.txt>.
			Appendix A. RFC 3161 TSTInfo
			As a reference for the definition of TST-info-based-on-CBOR-time-tag
			the code block below depicts the original layout of the TSTInfo
			structure from [RFC3161].
			TSTInfo ::= SEQUENCE {
			version INTEGER { v1(1) },
			policy TSAPolicyId,
			messageImprint MessageImprint,
			-- MUST have the same value as the similar field in
			-- TimeStampReq
			serialNumber INTEGER,
			-- Time-Stamping users MUST be ready to accommodate integers
			-- up to 160 bits.
			genTime GeneralizedTime,
			accuracy Accuracy OPTIONAL,
			ordering BOOLEAN DEFAULT FALSE,
			nonce INTEGER OPTIONAL,
			-- MUST be present if the similar field was present
			-- in TimeStampReq. In that case it MUST have the same value.
			tsa [0] GeneralName OPTIONAL,
			extensions [1] IMPLICIT Extensions OPTIONAL }
	Acknowledgements		Acknowledgements
	TBD		TBD
	Authors' Addresses		Authors' Addresses
	Henk Birkholz		Henk Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	Rheinstrasse 75		Rheinstrasse 75
	64295 Darmstadt		64295 Darmstadt
End of changes. 22 change blocks.
	54 lines changed or deleted		70 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/