RATS Message Types
draft-fossati-rats-message-types-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Thomas Fossati , Laurence Lundblade | ||
| Last updated | 2024-11-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fossati-rats-message-types-00
RATS T. Fossati
Internet-Draft Linaro
Intended status: Standards Track L. Lundblade
Expires: 23 May 2025 Security Theory LLC
19 November 2024
RATS Message Types
draft-fossati-rats-message-types-00
Abstract
This establishes that RATs messages types should be identified by
either CoAP Content-Format or Media Type (MIME type) or both. CBOR
tags and other type mechanisms should not be used.
This updates EAT, in a backwards-compatible way, so that the type of
EAT nested tokens can be identified by CoAP Content-Format and Media
Type.
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 23 May 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fossati & Lundblade Expires 23 May 2025 [Page 1]
Internet-Draft RATS Message Types November 2024
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.
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
2. Type Identifiers and Receptacles . . . . . . . . . . . . . . 3
2.1. Type Identifiers . . . . . . . . . . . . . . . . . . . . 3
2.2. Receptacle Definition . . . . . . . . . . . . . . . . . . 3
2.3. Receptacle Commentary . . . . . . . . . . . . . . . . . . 4
3. EAT Updates . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Normative References . . . . . . . . . . . . . . . . . . 5
4.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
When EAT [I-D.ietf-rats-eat] and CMW [I-D.ietf-rats-msg-wrap] were
designed, some of the nesting requirements were not fully understood.
What is understood now is that composite and layered attestation has
to accommodate an open-ended range of formats for attestation
evidence messages (a.k. a., attestation tokens).
When composing attestation for a complex device like a car or
airplane, there are likely to be hundreds of components from hundreds
of suppliers. Individual suppliers are likely to have picked an
attestation token format convenient for their environment. For
example, traditional security-oriented components like HSMs are
likely to choose ASN.1 based formats while higher level components
may use JSON-based formats. In many cases, the components and the
attestation implementation will be subject to expensive certification
requirements. It is not possible for the manufacturer of the complex
device to dictate that all suppliers use the same format.
Encoding-specific message type indicators like CBOR tags (See
[STD94]) are not recommended, because they work only in the
particular protocol environments.
Fossati & Lundblade Expires 23 May 2025 [Page 2]
Internet-Draft RATS Message Types November 2024
Proprietary type indicators are also not recommended as there are
perfectly usable standard type indicators. Standard type indicators
have the benefit of working with established protocols like HTTP and
CoAP [RFC7252].
It is expected that attestation, and thus attestation messages, will
be integrated into other protocols like TLS. Some uniform means of
identifying RATS messages is desirable. This is akin to identify
image format types in a general way that works for email, web pages
and so on.
A concern with multiple formats for RATS messages is incurring
n-squared complexity where n is the number of formats for something
like evidence. Orienting around a standard content types will mostly
reduce from n-squared to simple order of n.
It is advantageous to identify one point in RATS protocols where
message-formats can change, say from CBOR to JSON or DER (ASN.1) to
CBOR. Since RATS messages can be many formats, the logical place to
do that is at the message level. This is how EAT does it. The only
place a message format boundary is crossed is for nested tokens.
(EAT also allows a message format boundary crossing for manifests and
measurements, but technically they are not attestation messages.
Never the less, in EAT this boundary makes use of CoAP Content-
Format).
2. Type Identifiers and Receptacles
A type system needs identifiers for each message that plugs-in and a
receptacle structure for the place the message plugs-in.
2.1. Type Identifiers
A CoAP Content-Format and Media Type SHOULD be registered for each
RATS protocol message definition.
A CBOR tag SHOULD NOT be registered for RATS protocol messages. If a
CBOR tag is needed, one can be derived by the TN() mechanism
described in [RFC7252].
2.2. Receptacle Definition
A receptacle is a place in a protocol where a RATS message can occur.
For example, a nested-token in EAT or a cbor-record in CMW. In a
sense, HTTP is largely a receptacle.
Fossati & Lundblade Expires 23 May 2025 [Page 3]
Internet-Draft RATS Message Types November 2024
A receptacle is a content type and a body. cbor-record and json-
record in CMW are receptacles. The content type header and message
body in HTTP are a receptacle.
All RATS protocols SHOULD use a receptacle that is based on CoAP
Content-Format or Media Type or both.
CBOR-based protocols SHOULD use the cbor-record defined in CMW as a
receptacle. JSON-based protocols should use the json-record defined
in CMW as a receptacle.
This does not deprecate previously registered CBOR tags or CBOR tag-
using receptacles.
2.3. Receptacle Commentary
The actual definition and encoding for a receptacle should match the
format and encoding of the surround protocol. For example, in a
CBOR-format CMW token, a cbor-record is used for the receptacle. In
an ASN.1-based protocol the receptacle will be defined in ASN.1. It
is perhaps an INTEGER and an OCTET-STREAM or an OID that maps to a
CoAP Content-Format and an OCTET-STREAM.
A receptacle is a place where encoding formats can change. A JSON-
format message can be put into a CBOR-format message. It is
recommended that in RATS protocols a receptacle be the only place
where the encoding format can change. Stated conversely, any place
in a RATS protocol were the encoding format can change, a receptacle
should be used.
A typical receptacle implementation will decode the message type, and
then switch or dispatch to a handler for that type. This may be by a
look up table or such. The important part is the implementation of
the receptacle doesn’t have to be changed for each new type. Only a
configuration has to be adjusted.
Some protocols, like TLS, don’t have receptacles and need one to
transport RATS messages.
Note that in EAT, both the manifests and measurements claims are
defined are receptacles as described here.
3. EAT Updates
The definition of a nested-token in EAT [I-D.ietf-rats-eat] doesn’t
meet the above criterion, so it needs to be adjusted. This doesn’t
deprecate anything in EAT, just refines some definitions.
Fossati & Lundblade Expires 23 May 2025 [Page 4]
Internet-Draft RATS Message Types November 2024
In CBOR-format EAT tokens, the type of a nested token is identified
by a CBOR tag. This document updates EAT to say the CBOR tag SHOULD
use CoAP Content-Formats [RFC7252] and tn() described in [RFC9277] to
turn them into CBOR tags.
In JSON-format EAT tokens, the JSON-Selector structure is used to
identify the type of a nested token. The string identifier in JSON-
Selector may be one of a small number of strings defined by the EAT
standard and may be update only by a standards document.
This document updates the JSON-Selector as follows. When the string
in the JSON-selector is one of the top-level media types (e.g.,
“application”) the JSON-selector is a media type identifier.
4. References
4.1. Normative References
[I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[I-D.ietf-rats-msg-wrap]
Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-11,
15 November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-11>.
[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/rfc/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
Fossati & Lundblade Expires 23 May 2025 [Page 5]
Internet-Draft RATS Message Types November 2024
[RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for
Items in Concise Binary Object Representation (CBOR)",
RFC 9277, DOI 10.17487/RFC9277, August 2022,
<https://www.rfc-editor.org/rfc/rfc9277>.
4.2. Informative References
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
Authors' Addresses
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Fossati & Lundblade Expires 23 May 2025 [Page 6]