<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.3.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-richardson-rats-composite-attesters-05" category="info" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="composites">Taxonomy of Composite Attesters</title>
    <seriesInfo name="Internet-Draft" value="draft-richardson-rats-composite-attesters-05"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization>Fraunhofer SIT</organization>
      <address>
        <email>henk.birkholz@ietf.contact</email>
      </address>
    </author>
    <author initials="Y." surname="Deshpande" fullname="Yogesh Deshpande">
      <organization>Arm</organization>
      <address>
        <email>yogesh.deshpande@arm.com</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>Linaro</organization>
      <address>
        <email>thomas.fossati@linaro.org</email>
      </address>
    </author>
    <date year="2026" month="August" day="30"/>
    <area>Internet</area>
    <workgroup>RATS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 58?>

<t>This document was attempting to clarifys and extends the meaning of Composite Attester from RFC9334.
It has since been moved into the RATS wiki, and this I-D serves as a tombstone.</t>
      <t>A system of annotated diagram components is defined as a small language to explain the different ways that components can interact to form composites.</t>
      <t>These diagram components are then used to define a few popular classes of composites.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-richardson-rats-composite-attesters/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        rats Working Group mailing list (<eref target="mailto:rats@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/rats/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/rats/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/mcr/composite-attesters"/>.</t>
    </note>
  </front>
  <middle>
    <?line 67?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document was attempting to clarify and extend the meaning of Composite Attester from <xref section="3.3" sectionFormat="comma" target="RFC9334"/>.</t>
      <t>This work has been moved into the RATS wiki at: https://wiki.ietf.org/group/rats/atomic-composites</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>There are none.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Jun Zhang contributed the terms "Le Petit" and "Le Grand" to qualify Verifier, the original thought for Class 5 Composite Atteser and the description of the Nonce architecture.</t>
    </section>
    <section anchor="changelog">
      <name>Changelog</name>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9334" target="https://www.rfc-editor.org/info/rfc9334">
          <front>
            <title>Remote ATtestation procedureS (RATS) Architecture</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="N. Smith" initials="N." surname="Smith"/>
            <author fullname="W. Pan" initials="W." surname="Pan"/>
            <date month="January" year="2023"/>
            <abstract>
              <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9334"/>
          <seriesInfo name="DOI" value="10.17487/RFC9334"/>
        </reference>
        <reference anchor="I-D.ietf-rats-msg-wrap" target="https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-23" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rats-msg-wrap.xml">
          <front>
            <title>RATS Conceptual Messages Wrapper (CMW)</title>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization>Fraunhofer SIT</organization>
            </author>
            <author fullname="Ned Smith" initials="N." surname="Smith">
              <organization>Independent</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization>
            </author>
            <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
              <organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
            </author>
            <author fullname="Dionna Glaze" initials="D." surname="Glaze">
              <organization>Google LLC</organization>
            </author>
            <date day="11" month="December" year="2025"/>
            <abstract>
              <t>The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rats-msg-wrap-23"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="TCG-DICE" target="https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf">
          <front>
            <title>DICE Layering Architecture</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2020" month="July"/>
          </front>
          <seriesInfo name="Version 1.0, Revision 0.19" value=""/>
        </reference>
        <reference anchor="I-D.ffm-rats-cca-token" target="https://datatracker.ietf.org/doc/html/draft-ffm-rats-cca-token-03" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ffm-rats-cca-token.xml">
          <front>
            <title>Arm's Confidential Compute Architecture Reference Attestation Token</title>
            <author fullname="Simon Frost" initials="S." surname="Frost">
              <organization>Arm Limited</organization>
            </author>
            <author fullname="Thomas Fossati" initials="T." surname="Fossati">
              <organization>Linaro</organization>
            </author>
            <author fullname="Giridhar Mandyam" initials="G." surname="Mandyam">
              <organization>Mediatek Inc</organization>
            </author>
            <date day="2" month="March" year="2026"/>
            <abstract>
              <t>The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ffm-rats-cca-token-03"/>
        </reference>
      </references>
    </references>
    <?line 86?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA41VTW/bRhC9768Y2JcWNSn5I2jMkxW5dhw4QWALLdJLMCKH
4kLcXXZ3KVkJ8t87szRtuTCKCD5wZ2fn482b5yzLVNSxpQIW+OCsMztwNcyd
6VzQkWAWI4VIPihcLj1tCijHu6AqV1o0/LbyWMfM67JBXwVnM48xZE+eGY5R
sukbpQ4hRLTVV2yd5cfR96SU7nz6DPFkOj2fnij0hAXcWH5mKartqoC72eIe
/nJ+re0Krr3rO7XePvtkl1KGKjEWoG3tlCpdxa4F9LHO3qpOF8C/QyjRQh8I
0HvcwS+6Bmxb2FH4FZyHBkMDDXlSANGVhVzwZ3A+eqpDkUJUVGPfxsAe4/3O
DNdyVNjHxvlCqYxLYePHHO6e4GHvAbePYqL25ZXzXPE9A0St4ULvXR23DEZq
XBKRQd0WYEr/m6ZYX4TRNS9xTPc+h3farxvXfntK9p7set+a8lx57G3javJw
f7N4jt6wc758dL6QPHnpbMQyjim+5HBJoekk+1OOL27FthcXKc3Mm+fYu+SU
V6PTBXrD0c0YeZHDlQsBo36Ku2icwbBnTlFvtUXvngPH5JXXg9dFm65zdlXK
Om/YtqGC3d/NPx+fMZ2u5m+Pfz9jA3+dn56eyd1NdplLuwOFTVhlW48d095s
lZBqL8xifp1d3sz/kG+myrBGYoBb3JEXks582fAClLFPdAIYeQHpl7pYCOmp
SkvXx2dqi0PgMBQkbwF/8v5oZ+E4nx7BHW10Ok3z4/PkWmHk9B/6dgcn05Pp
UBP6FfE2NDF2oZhM4pCqHDOtJJEANNl2mcyXbJz0XeuwChPpJBs7yfY7yfzx
+deuX+ZdVT9CVtfmcelLzKJbky14vYwcldqQ7RNiKV8B4sinYWhyGAgmg2If
HZt+mfg9eUVBeKOyDHAZohcyqkWjA7AQ9YZrhy2TRFxNl4Dk5Sxb9LresdlW
QA/cYcVL2xAYQis+r8od1N6ZkRa5uomiCsCDKAmWRBaM2/DItOUMEiwp01av
9VHKE6UohkXmtyHOzX9cjOGqWfJypWYsF5zHSHa01kUUBlQaVx7NILGW+wkg
zVGtLd+mIMGIVLVoVz2uSBqkh65FbVMZla55kwcgdtImxv1gontaxJKRk6fC
5j09zwVNCvRaHSJAnCHpZiVvh6q4opq20LmuZ5wF7BC4X+7qRVgZmdFV1ZKo
P+u1d1VfRubvTw9wb34/O77v3x8HeAT3lLLBaX7640f+mHTLgprm+r8TBdxb
IDHkI1knic4TIfAEebq6zPb+OUqjs08zrs4GXTHmUkBIEHtKeNqBC4cwK9fW
bVuqViQgsNOH3sLfDU8ZZCu9XvbCD6mLuzMBDm4JPhNLzkHCRY7Xnr8OBLF/
emwFMRYMXWvyR+mh83rFgtiKSvarJsr0YS4Dgzf/hZARxEecWaVLr7uEHmMt
pk9O1gD3BCF1MZd6qXWstmngSyzXSv0LBDO+e2IIAAA=

-->

</rfc>
