draft-ietf-teep-architecture-06.txt   draft-ietf-teep-architecture-07.txt 
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: August 11, 2020 Arm Limited Expires: September 8, 2020 Arm Limited
D. Thaler D. Thaler
Microsoft Microsoft
D. Wheeler D. Wheeler
Intel Intel
February 08, 2020 March 07, 2020
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-06 draft-ietf-teep-architecture-07
Abstract Abstract
A Trusted Execution Environment (TEE) is an environment that enforces A Trusted Execution Environment (TEE) is an environment that enforces
that only authorized code can execute within that environment, and that only authorized code can execute within that environment, and
that any data used by such code cannot be read or tampered with by that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document any code outside that environment. This architecture document
motivates the design and standardization of a protocol for managing motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE. the lifecycle of trusted applications running inside such a TEE.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 11, 2020. This Internet-Draft will expire on September 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 36 skipping to change at page 2, line 36
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7
3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7
3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 10 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 10
4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12
4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14
4.4.1. Examples of Application Delivery Mechanisms in 4.4.1. Examples of Application Delivery Mechanisms in
Existing TEEs . . . . . . . . . . . . . . . . . . . . 14 Existing TEEs . . . . . . . . . . . . . . . . . . . . 15
4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16
5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17
5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 18 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19
5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 19 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 19
5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 19 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 19
5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20
6.2. TEEP Broker Implementation Consideration . . . . . . . . 21 6.2. TEEP Broker Implementation Consideration . . . . . . . . 21
6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 21 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 21
6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22
7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 15 skipping to change at page 3, line 15
8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25
9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 25 9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 25
9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 25 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 25
9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26 9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26
9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26
9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 26 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 26
9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 27 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 27
9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 27 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. Informative References . . . . . . . . . . . . . . . . . . . 28 13. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Applications executing in a device are exposed to many different Applications executing in a device are exposed to many different
attacks intended to compromise the execution of the application or attacks intended to compromise the execution of the application or
reveal the data upon which those applications are operating. These reveal the data upon which those applications are operating. These
attacks increase with the number of other applications on the device, attacks increase with the number of other applications on the device,
with such other applications coming from potentially untrustworthy with such other applications coming from potentially untrustworthy
sources. The potential for attacks further increases with the sources. The potential for attacks further increases with the
complexity of features and applications on devices, and the complexity of features and applications on devices, and the
skipping to change at page 6, line 19 skipping to change at page 6, line 19
with other human beings as secondary device users (e.g., parent with other human beings as secondary device users (e.g., parent
allowing children to use their tablet or laptop). Other devices allowing children to use their tablet or laptop). Other devices
are not used by a human being and hence have no device user. are not used by a human being and hence have no device user.
Relates to Device Owner and Device Administrator. Relates to Device Owner and Device Administrator.
- Rich Execution Environment (REE): An environment that is provided - Rich Execution Environment (REE): An environment that is provided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS), and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of any TEE. This environment and and hypervisors; it is outside of any TEE. This environment and
applications running on it are considered untrusted (or more applications running on it are considered untrusted (or more
precisely, less trusted than the TEE). precisely, less trusted than a TEE).
- Trust Anchor: As defined in [RFC6024] and - Trust Anchor: As defined in [RFC6024] and
[I-D.ietf-suit-manifest], "A trust anchor represents an [I-D.ietf-suit-manifest], "A trust anchor represents an
authoritative entity via a public key and associated data. The authoritative entity via a public key and associated data. The
public key is used to verify digital signatures, and the public key is used to verify digital signatures, and the
associated data is used to constrain the types of information for associated data is used to constrain the types of information for
which the trust anchor is authoritative." The Trust Anchor may be which the trust anchor is authoritative." The Trust Anchor may be
a certificate or it may be a raw public key along with additional a certificate or it may be a raw public key along with additional
data if necessary such as its public key algorithm and parameters. data if necessary such as its public key algorithm and parameters.
skipping to change at page 10, line 12 skipping to change at page 10, line 12
keys in their device's Trust Anchor list. Alternatively, a TAM keys in their device's Trust Anchor list. Alternatively, a TAM
may publish its certificate and allow Device Administrators to may publish its certificate and allow Device Administrators to
install the TAM's certificate in their devices as an after-market- install the TAM's certificate in their devices as an after-market-
action. action.
- TEEP Broker: A TEEP Broker is an application component running in - TEEP Broker: A TEEP Broker is an application component running in
a Rich Execution Environment (REE) that enables the message a Rich Execution Environment (REE) that enables the message
protocol exchange between a TAM and a TEE in a device. A TEEP protocol exchange between a TAM and a TEE in a device. A TEEP
Broker does not process messages on behalf of a TEE, but merely is Broker does not process messages on behalf of a TEE, but merely is
responsible for relaying messages from the TAM to the TEE, and for responsible for relaying messages from the TAM to the TEE, and for
returning the TEE's responses to the TAM. In devices with no REE, returning the TEE's responses to the TAM. In devices with no REE
the TEEP Broker would be absent and instead the TEEP protocol (e.g., a microcontroller where all code runs in an environment
transport would be implemented inside the TEE itself. that meets the definition of a Trusted Execution Environment in
Section 2), the TEEP Broker would be absent and instead the TEEP
protocol transport would be implemented inside the TEE itself.
- TEEP Agent: The TEEP Agent is a processing module running inside a - TEEP Agent: The TEEP Agent is a processing module running inside a
TEE that receives TAM requests (typically relayed via a TEEP TEE that receives TAM requests (typically relayed via a TEEP
Broker that runs in an REE). A TEEP Agent in the TEE may parse Broker that runs in an REE). A TEEP Agent in the TEE may parse
requests or forward requests to other processing modules in a TEE, requests or forward requests to other processing modules in a TEE,
which is up to a TEE provider's implementation. A response which is up to a TEE provider's implementation. A response
message corresponding to a TAM request is sent back to the TAM, message corresponding to a TAM request is sent back to the TAM,
again typically relayed via a TEEP Broker. again typically relayed via a TEEP Broker.
- Certification Authority (CA): Certificate-based credentials used - Certification Authority (CA): Certificate-based credentials used
skipping to change at page 12, line 15 skipping to change at page 12, line 17
resource usage. resource usage.
4.3. Multiple TAMs and Relationship to TAs 4.3. Multiple TAMs and Relationship to TAs
As shown in Figure 2, a TEEP Broker provides communication between As shown in Figure 2, a TEEP Broker provides communication between
one or more TEEP Agents and one or more TAMs. The selection of which one or more TEEP Agents and one or more TAMs. The selection of which
TAM to communicate with might be made with or without input from an TAM to communicate with might be made with or without input from an
Untrusted Application, but is ultimately the decision of a TEEP Untrusted Application, but is ultimately the decision of a TEEP
Agent. Agent.
A TEEP Agent is assumed to be able to determine, for any given TA,
whether that TA is installed (or minimally, is running) in a TEE with
which the TEEP Agent is associated.
Each TA is digitally signed, protecting its integrity, and linking Each TA is digitally signed, protecting its integrity, and linking
the TA back to the signer. The signer is usually the TA software the TA back to the signer. The signer is usually the TA software
author, but in some cases might be another party that the TA software author, but in some cases might be another party that the TA software
author trusts, or a party to whom the code has been licensed (in author trusts, or a party to whom the code has been licensed (in
which case the same code might be signed by multiple licensees and which case the same code might be signed by multiple licensees and
distributed as if it were different TAs). distributed as if it were different TAs).
A TA author or signer selects one or more TAMs through which to offer A TA author or signer selects one or more TAMs through which to offer
their TA(s), and communicates the TA(s) to the TAM. In this their TA(s), and communicates the TA(s) to the TAM. In this
document, we use the term "TA developer" to refer to the entity that document, we use the term "TA developer" to refer to the entity that
skipping to change at page 18, line 22 skipping to change at page 18, line 22
Code Signing 1 per TA TA binary TEE Code Signing 1 per TA TA binary TEE
developer developer
Figure 4: Keys Figure 4: Keys
Note that personalization data is not included in the table above. Note that personalization data is not included in the table above.
The use of personalization data is dependent on how TAs are used and The use of personalization data is dependent on how TAs are used and
what their security requirements are. what their security requirements are.
The TEE key pair and certificate are used for authenticating the TEE TEEP requests from a TAM to a TEEP Agent can be encrypted with the
to a remote TAM. Often, the key pair is burned into the TEE by the TEE public key (to provide confidentiality), and are then signed with
TEE manufacturer and the key pair and its certificate are valid for the TAM private key (for authentication and integrity protection).
the expected lifetime of the TEE. A TAM provider is responsible for Conversely, TEEP responses from a TEEP Agent to a TAM can be
configuring the TAM's Trust Anchor Store with the manufacturer encrypted with the TAM public key, and are then signed with the TEE
certificates or CAs that are used to sign TEE keys. This is private key.
discussed further in Section 5.3 below.
The TEE key pair and certificate are thus used for authenticating the
TEE to a remote TAM, and for sending private data to the TEE. Often,
the key pair is burned into the TEE by the TEE manufacturer and the
key pair and its certificate are valid for the expected lifetime of
the TEE. A TAM provider is responsible for configuring the TAM's
Trust Anchor Store with the manufacturer certificates or CAs that are
used to sign TEE keys. This is discussed further in Section 5.3
below.
The TAM key pair and certificate are used for authenticating a TAM to The TAM key pair and certificate are used for authenticating a TAM to
a remote TEE. A TAM provider is responsible for acquiring a a remote TEE, and for sending private data to the TAM. A TAM
certificate from a CA that is trusted by the TEEs it manages. This provider is responsible for acquiring a certificate from a CA that is
is discussed further in Section 5.1 below. trusted by the TEEs it manages. This is discussed further in
Section 5.1 below.
The TA developer key pair and certificate are used to sign TAs that The TA developer key pair and certificate are used to sign TAs that
the TEE will consider authorized to execute. TEEs must be configured the TEE will consider authorized to execute. TEEs must be configured
with the certificates or keys that it considers authorized to sign with the certificates or keys that it considers authorized to sign
TAs that it will execute. This is discussed further in Section 5.2 TAs that it will execute. This is discussed further in Section 5.2
below. below.
5.1. Trust Anchors in a TEEP Agent 5.1. Trust Anchors in a TEEP Agent
A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors,
skipping to change at page 25, line 17 skipping to change at page 25, line 21
9. Security Considerations 9. Security Considerations
9.1. Broker Trust Model 9.1. Broker Trust Model
The architecture enables the TAM to communicate, via a TEEP Broker, The architecture enables the TAM to communicate, via a TEEP Broker,
with the device's TEE to manage TAs. Since the TEEP Broker runs in a with the device's TEE to manage TAs. Since the TEEP Broker runs in a
potentially vulnerable REE, the TEEP Broker could, however, be (or be potentially vulnerable REE, the TEEP Broker could, however, be (or be
infected by) malware. As such, all TAM messages are signed and infected by) malware. As such, all TAM messages are signed and
sensitive data is encrypted such that the TEEP Broker cannot modify sensitive data is encrypted such that the TEEP Broker cannot modify
or capture sensitive data. or capture sensitive data, but the TEEP Broker can still conduct DoS
attacks as discussed in Section 9.3.
A TEEP Agent in a TEE is responsible for protecting against potential A TEEP Agent in a TEE is responsible for protecting against potential
attacks from a compromised TEEP Broker or rogue malware in the REE. attacks from a compromised TEEP Broker or rogue malware in the REE.
A rogue TEEP Broker might send corrupted data to the TEEP Agent, or A rogue TEEP Broker might send corrupted data to the TEEP Agent, or
launch a DoS attack by sending a flood of TEEP protocol requests. launch a DoS attack by sending a flood of TEEP protocol requests.
The TEEP Agent validates the signature of each TEEP protocol request The TEEP Agent validates the signature of each TEEP protocol request
and checks the signing certificate against its Trust Anchors. To and checks the signing certificate against its Trust Anchors. To
mitigate DoS attacks, it might also add some protection scheme such mitigate DoS attacks, it might also add some protection scheme such
as a threshold on repeated requests or number of TAs that can be as a threshold on repeated requests or number of TAs that can be
installed. installed.
skipping to change at page 25, line 39 skipping to change at page 25, line 44
9.2. Data Protection at TAM and TEE 9.2. Data Protection at TAM and TEE
The TEE implementation provides protection of data on the device. It The TEE implementation provides protection of data on the device. It
is the responsibility of the TAM to protect data on its servers. is the responsibility of the TAM to protect data on its servers.
9.3. Compromised REE 9.3. Compromised REE
It is possible that the REE of a device is compromised. If the REE It is possible that the REE of a device is compromised. If the REE
is compromised, several DoS attacks may be launched. The compromised is compromised, several DoS attacks may be launched. The compromised
REE may terminate the TEEP Broker such that TEEP transactions cannot REE may terminate the TEEP Broker such that TEEP transactions cannot
reach the TEE. However, while a DoS attack cannot be prevented, the reach the TEE, or might drop or delay messages between a TAM and a
REE cannot access anything in the TEE if it is implemented correctly. TEEP Agent. However, while a DoS attack cannot be prevented, the REE
cannot access anything in the TEE if it is implemented correctly.
Some TEEs may have some watchdog scheme to observe REE state and Some TEEs may have some watchdog scheme to observe REE state and
mitigate DoS attacks against it but most TEEs don't have have such mitigate DoS attacks against it but most TEEs don't have have such
capability. capability.
In some other scenarios, the compromised REE may ask a TEEP Broker to In some other scenarios, the compromised REE may ask a TEEP Broker to
make repeated requests to a TEEP Agent in a TEE to install or make repeated requests to a TEEP Agent in a TEE to install or
uninstall a TA. A TA installation or uninstallation request uninstall a TA. A TA installation or uninstallation request
constructed by the TEEP Broker or REE will be rejected by the TEEP constructed by the TEEP Broker or REE will be rejected by the TEEP
Agent because the request won't have the correct signature from a TAM Agent because the request won't have the correct signature from a TAM
to pass the request signature validation. to pass the request signature validation.
skipping to change at page 27, line 7 skipping to change at page 27, line 9
It may happen that a TA was previously considered trustworthy but is It may happen that a TA was previously considered trustworthy but is
later found to be buggy or compromised. In this case, the TAM can later found to be buggy or compromised. In this case, the TAM can
initiate the removal of the TA by notifying devices to remove the TA initiate the removal of the TA by notifying devices to remove the TA
(and potentially the REE or device owner to remove any Untrusted (and potentially the REE or device owner to remove any Untrusted
Application that depend on the TA). If the TAM does not currently Application that depend on the TA). If the TAM does not currently
have a connection to the TEEP Agent on a device, such a notification have a connection to the TEEP Agent on a device, such a notification
would occur the next time connectivity does exist. would occur the next time connectivity does exist.
Furthermore the policy in the Verifier in an attestation process can Furthermore the policy in the Verifier in an attestation process can
be updated so that any evidence that includes the malicious TA would be updated so that any evidence that includes the malicious TA would
result in an attestation failure. result in an attestation failure. There is, however, a time window
during which a malicious TA might be able to operate successfully,
which is the validity time of the previous attestation result. For
example, if the Verifier in Figure 5 is updated to treat a previously
valid TA as no longer trustworthy, any attestation result it
previously generated saying that the TA is valid will continue to be
used until the attestation result expires. As such, the TAM's
Verifier should take into account the acceptable time window when
generating attestation results. See [I-D.ietf-rats-architecture] for
further discussion.
9.7. Certificate Renewal 9.7. Certificate Renewal
TEE device certificates are expected to be long lived, longer than TEE device certificates are expected to be long lived, longer than
the lifetime of a device. A TAM certificate usually has a moderate the lifetime of a device. A TAM certificate usually has a moderate
lifetime of 2 to 5 years. A TAM should get renewed or rekeyed lifetime of 2 to 5 years. A TAM should get renewed or rekeyed
certificates. The root CA certificates for a TAM, which are embedded certificates. The root CA certificates for a TAM, which are embedded
into the Trust Anchor store in a device, should have long lifetimes into the Trust Anchor store in a device, should have long lifetimes
that don't require device Trust Anchor update. On the other hand, it that don't require device Trust Anchor update. On the other hand, it
is imperative that OEMs or device providers plan for support of Trust is imperative that OEMs or device providers plan for support of Trust
skipping to change at page 28, line 27 skipping to change at page 28, line 44
[I-D.ietf-suit-manifest] [I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., and H. Birkholz, "A Concise Moran, B., Tschofenig, H., and H. Birkholz, "A Concise
Binary Object Representation (CBOR)-based Serialization Binary Object Representation (CBOR)-based Serialization
Format for the Software Updates for Internet of Things Format for the Software Updates for Internet of Things
(SUIT) Manifest", draft-ietf-suit-manifest-03 (work in (SUIT) Manifest", draft-ietf-suit-manifest-03 (work in
progress), February 2020. progress), February 2020.
[I-D.ietf-teep-otrp-over-http] [I-D.ietf-teep-otrp-over-http]
Thaler, D., "HTTP Transport for Trusted Execution Thaler, D., "HTTP Transport for Trusted Execution
Environment Provisioning: Agent-to- TAM Communication", Environment Provisioning: Agent-to- TAM Communication",
draft-ietf-teep-otrp-over-http-03 (work in progress), draft-ietf-teep-otrp-over-http-04 (work in progress),
November 2019. February 2020.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
 End of changes. 18 change blocks. 
31 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/