PKIX Evidence for Remote Attestation

2.1. Remote audit of a Hardware Security Module (HSM)

There are situations where it is necessary to verify the current running state of a HSM as part of operational or auditing procedures. For example, there are devices that are certified to work in an environment only if certain versions of the firmware are loaded or only if application keys are protected in with a certain set of protection policies.¶

The Evidence format offered by this specification allows a platform to report its firmware level along with other collected claims necessary in critical deployments.¶

2.2. Key import and HSM clustering

Consider that an HSM is being added to a logical HSM cluster. Part of the onboarding process could involve the newly-added HSM providing proof of its running state, for example that it is a genuine device from the same manufacturer as the existing clustered HSMs, firmware patch level, FIPS mode, etc. It could also be required to provide attestation of any system-level keys required for secure establishment of cluster communication. In this scenario, the Verifier and Relying Party will be the other HSMs in the cluster deciding whether or not to admit the new HSM.¶

A related scenario is when performing a key export-import across HSMs. If the key is being imported with certain properties, for example an environment running in FIPS mode at FIPS Level 3, and the key is set to certain protection properties such as Non-Exportable and Dual-Control, then the HSM might wish to verify that the key was previously stored under the same properties. This specification even provides a way to do this across HSM vendors.¶

These scenarios motivate the design requirements to have an ASN.1 based Evidence format and a data model that more closely matches typical HSM architecture since in both scenarios an HSM is acting as Verifier and Relying Party.¶

2.3. Attesting subject of a certificate issuance

Prior to a Certification Authority (CA) issuing a certificate on behalf of a subject, a number of procedures are required to verify that the subject of the certificate is associated with the key that is certified. In some cases, such as issuing a code signing certificate [CNSA2.0], [codesigningbrsv3.8], a CA must ensure that the subject key is located in a Hardware Security Module (HSM).¶

The Evidence format offered by this specification is designed to carry the information necessary for a CA to assess the location of the subject key along a number of commonly-required attributes. More specifically, a CA could determine which HSM was used to generate the subject key, whether this device adheres to certain jurisdiction policies (such as FIPS mode) and the constraints applied to the key (such as whether is it extractable).¶

For relatively simple HSM devices such as TPM-like devices, storage properties such as Extractable may always be true for all keys since the devices is not capable of key export and so the attestation could be essentially a hard-coded template asserting these immutable attributes. However, more complex HSM devices require a more complex key attestation format that encompases the mutability of these attributes. Also, the client requesting the key attestation might wish to scope-down the content of the key attestation, for example maybe the HSM contains many keys and only a certain subset are relevant for attesting the given transaction, or maybe only certain claims are relevant. Lack of ability to scope-down the key attestation contents could, in some scenarios, constitute a grave privacy violation. This motivates the design choice for a key attestation request mechanism. The same objective could have been accomplished via a selective disclosure mechanism, however since an attestation request is necessary anyway to transmit an attestation nonce to the HSM, a standardized request format fits the usecase better and is generally simpler.¶

4.1. Attestation Key Certificate Chain

The data format in this specification represents attestation evidence and requires third-party endorsement in order to establish trust. Part of this endorsement is a trust anchor that chains to the HSM's attestation key (AK) which signs the evidence. In practice the trust anchor will usually be a manufacturing CA belonging to the device vendor which proves that the device is genuine and not counterfeit. The trust anchor can also belong to the device operator as would be the case when the AK certificate is replaced as part of onboarding the device into a new operational network.¶

The AK certificate that signs the evidence MUST have the Extended Key Usage id-kp-attest defined in [TODO-submit-2-pager-to-lamps].¶

Note that the data format specified in Section 6 allows for zero, one, or multiple 'SignatureBlock's, so a single evidence statement could be un-protected, or could be endorsed by multiple AK chains leading to different trust anchors. See Section 8 for a discussion of handling multiple SignatureBlocks.¶

5.1. Entity

An entity is composed of a type, the entity type, and a set of attributes. The entity type describes the class of the entity while its attributes defines its state.¶

An entity SHOULD be reported only once in a claim description. The claim description can have multiple entities of the same type (for example reporting multiple keys), but each entity MUST be relating to different elements. For example, if a given application public key appears in two different entities, these MUST be interpreted as two distinct and independent entities that happen to have the same public key, and MUST NOT be interpreted as adding attidional attributes to the already-described entity. This restriction is to ease the implementation of Verifiers for the provided Evidence.¶

The number of entities reported in a claim description, and their respective type, is left to the implementer. For a simple device where there is only one key, the list of reported entities could be fixed. For larger and more complex devices, the list of reported entities should be tailored to the demands of the requesting party.¶

In particular, note that the nonce attribute contained with the Transaction entity is optional, and therefore it is possible that an extremely simple device that holds one static key could have its key attestation object generated at manufacture time and injected statically into the device and acting as a kind of certificate instead of being generated on-demand. This model would essentially off-board the Attesting Environment to being part of the manufacturing infrastructure.¶

5.2. Entity Type

An entity is defined by its type. This specification defines three entity types:¶

• Platform : This entity holds attributes relating to the state of the platform, or device, where the Attester is located. Entities of this type holds attributes that are global in nature within the Target Environment.¶

• Key : The entities of this type represent a cryptographic key protected within the Target Environment and hold attributes relating to that key.¶

• Transaction : This is an entity logical in nature since it is associated with attributes that are not found in the Target Environment. The attributes found in this entity relate to the current request for Evidence such as a nonce to support freshness.¶

Although this document defines a short list of entity types, this list should be extensible to allow implementers to report on entities found in their implementation and not covered by this specification. By using an Object Identifier (OID) based system for identifying both entity types and the attribute types that they contain, this format is inherently extensible; implementers of Attesters MAY define new custom or proprietary entity types and place them along-side the standardized entities, or define new attribute types and place them inside standardized entities.¶

Verifiers SHOULD ignore and skip over unrecognized entity or attribute types and continue processing normally. In other words, if a given Evidence would have been acceptable without the unrecognized entity or attribute, then it SHOULD still be acceptable. In PKI terminology, all custom entities and attributes not defined in this document SHOULD be considered non-critical unless a further specification indicates differently.¶

5.3. Attribute and Attribute Type

Each attribute found in an entity is composed of a type, the attribute type, and a value. Each attribute describes a portion of the state of the associated entity. For example, a platform entity could have an attribute which indicates the firmware version currently running. Another example is a key entity with an attribute that reports whether the key is extractable or not.¶

A value provided by an attribute is to be interpreted within the context of its entity and in relation to the attribute type.¶

It is RECOMMENDED that an attribute type be defined for a specific entity type, to reduce confusion when it comes to interpretation of the value. MikeO: I don't understand this sentence. I think it needs better words.¶

The nature of the value (boolean, integer, string, bytes) is dependent on the attribute type.¶

This specification defines a limited number of attribute types. However, this list should be extensible to allow implementers to report attributes not covered by this specification.¶

If a Verifier encounters an attribute with an unrecognized attribute type, it may ignore it. In PKI terminology, all custom attributes not defined in this document SHOULD be considered non-critical unless a further specification indicates differently.¶

The number of attributes reported within an entity, and their respective type, is left to the implementer. For a simple device, the reported list of attributes for an entity might be fixed. However, larger and more complex devices, the list of reported attributes should be tailored to the demands of the requesting party.¶

Some attributes MAY be repeated within an entity while others MUST NOT. For example, for a platform entity, there can only be one "firmware version" attribute. Therefore, the associated attribute MUST NOT be repeated as it may lead to confusion. However, an attribute relating to a "loaded module" MAY be repeated, each attribute describing a different loaded module. Therefore, the definition of an attribute specifies whether or not multiple copies of that attribute are allowed.¶

If a Verifier encounters, within a single entity, multiple copies of an attribute specified as "Multiple Allowed: No", it MUST reject the evidence as mal-formed.¶

If a Verifier encounters, within the context of an entity, a repeated attribute for a type where multiple attributes are allowed, it MUST treat each one as an independent attribute and MUST NOT consider later ones to overwrite or extend the previous one.¶

6.1. Platform Entity

A platform entity is associated with the type identifier id-pkix-attest-entity-platform. It is composed of a set of attributes that are global to the Target Environment.¶

A platform entity, if provided, MUST be included only once within the reported entities. If a Verifier encounters multiple entities of type id-pkix-attest-entity-platform, it MUST reject the Evidence as mal-formed.¶

The following table lists the attributes for a platform entity (platform attributes) defined within this specification. In cases where the attribute is borrowed from another specification, the "Reference" column refers to the specification where the semantics for the attribute value can be found. Attributes defined in this specification have further details below.¶

TODO: find the actual reference for "FIPS Mode" -- FIPS 140-3 does not define it (at least not the 11 page useless version of 140-3 that I found).¶

Each attribute has an assigned OID, see Section 11.¶

6.2. Key Entity

A key entity is associated with the type id-pkix-attest-entity-key. Each instance of a key entity represents a different cryptographic key found in the Target Environment. There can be multiple key entities found in claim description, but each reported key entity MUST described a different cryptographic key.¶

A key entity is composed of a set of attributes relating to the related cryptographic key. At minimum, a key entity MUST have an attribute "identifier" to uniquely identify this cryptographic key from any others found in the same Target Environment.¶

A Verifier that encounters a claim description with multiple key entities referring to the same cryptographic key MUST reject the Evidence.¶

The following table lists the attributes for a key entity (key attributes) defined within this specification. The "Reference" column refers to the specification where the semantics for the attribute value can be found.¶

PKCS#11 private key attributes can be somewhat complex to parse, especially as their exact meanings can vary by the key type and the exact details of key export mechanisms supported by the HSM.¶

An attestation key might be visible to a client of the device and be reported along with other cryptographic keys. Therefore, it is acceptable to include a key entity providing claims about an attestation key like any other cryptographic key. An implemention MAY reject the generation of PKIX Evidence if it relates to an attestation key.¶

EDNOTE: JPF I wonder if we should convert the table column "Description" to "OID" and provide the name of the OID. It might be cleaner to provide the description in the associated sub-section.¶

EDNOTE: JPF the next paragraph probably belongs somewhere else¶

In most cases, the Verifier of a PKIX Attestation will want to know simply that the key is in hardware and cannot be extracted to be used with a software cryptographic module. A setting of extractable=false satisfies this requirement. Generally extractable=true && sensitive=true also satisfies this requirement as the key cannot be extracted in plaintext, but only under key wrap. This is common in HSM clustering scenarios, and is also common in scenarios where keys are exported under wrap so that they can be stored in an off-board database for re-import later, thus allowing the HSM to protect and manage a much larger set of keys than it has internal memory for. The never-extractable and local attributes give additional assurance that the key has always been in hardware and was not imported from software.¶

6.3. Transaction Entity

A transaction entity is associated with the type id-pkix-attest-entity-transaction. This is a logical entity and does not relate to an element found in the Target Environment. Instead, it groups together attributes that relate to the request of generating the Evidence.¶

For example, it is possible to include a "nonce" as part of the request to produce Evidence. This nonce is repeated as part of the Evidence, within the portion protected for integrity, to prove the freshness of the claims. This "nonce" is not related to any element in the Target Environment and the transaction entity is used to gather those values into attributes.¶

A transaction entity, if provided, should be included only once within the reported entities. If a Verifier encounters multiple entities of type id-pkix-attest-entity-transaction, it MUST reject the Evidence.¶

The following table lists the attributes for a transaction entity (transaction attributes) defined within this specification. The "Reference" column refers to the specification where the semantics for the attribute value can be found.¶

A default and vendor-agnostic set of transaction attributes is defined in this section.¶

These attribute types MAY be contained within a transaction entity; i.e. an entity identified by id-pkix-attest-entity-transaction.¶

6.4. Additional Entity and Attribute Types

It is expected that HSM vendors will register additional Entity and Attribute types by assigning OIDs from their own proprietary OID arcs to hold data describing additional proprietary key properties.¶

An Attester (HSM) which is requested to provide information about unrecognized Entity or Attribute types MUST fail the operation.¶

A Verifier which encounters an unrecognized Entity or Attribute type MAY ignore it.¶

6.5. Encoding

A PkixEvidence is to be DER encoded [X.690].¶

If a textual representation is required, then the DER encoding MAY be subsequently encoded into Base64.¶

EDNOTE: I think we have to be precise about which flavour of Base64 we are referrring to.¶

10.1. Key Import into an HSM

An HSM which is compliant with this draft SHOULD validate any PKIX Key Attestations that are provided along with the key being imported.¶

The SignatureBlocks MUST be validated and MUST chain to a trust anchor known to the HSM. In most cases this will be the same trust anchor that endorsed the HSMs own AK, but the HSM MAY be configured with set of third party trust anchors from which it will accept key attestations.¶

If the HSM is operating in FIPS Mode, then it MUST only import keys from HSMs also operating in FIPS Mode.¶

The claims key-purpose, key-extractable, key-never-extractable, key-local MUST be checked and honoured during key import, which typically means that after import, the key MUST NOT claim a stronger protection property than it had on the previous hardware. In other words, Key Attestation allows and requires that key protection properties be preserved over export / import operations between different HSMs, and this format provides a vendor-agnostic way to acheive this.¶

How to handle errors is outside the scope of this specification and is left to implementors; for example the key import MAY be aborted, or a prompt MAY be given to the user administrator, or any similar reasonable error handling logic.¶

10.2. CA/Browser Forum Code-Signing

TODO: ... intro text¶

The subscriber MUST:¶

• Provide the CA with a CSR containing the subscriber key.¶

• Provide an attestation token as per this specification describing the private key protection properties of the subscriber's private key. This token MAY be transported inside the CSR as per draft-ietf-lamps-csr-attest, or it MAY be transported adjacent to the CSR over any other certificate enrollment mechanism.¶

The CA / RA / RP / Verifier MUST:¶

• Ensure that the subscriber key which is the subject of the CSR is also described by a KAT by matching either the key fingerprint or full SubjectPublicKeyInfo.¶

• The hardware root-of-trust described by a PAT has a valid and active FIPS certificate according to the NIST CMVP database.¶

• The attestation signing key (AK) which has signed the attestation token chains to a root certificate that A) belongs to the hardware vendor described in the PAT token, and B) is trusted by the CA / RA / RP / Verifier to endorse hardware from this vendor, for example through a CA's partner program or through a network operator's device on-boarding process.¶

• The key is protected by a module running in FIPS mode. The parsing logic is to start at the leaf KAT token that matches the key in the CSR and parsing towards the root PAT ensuring that there is at least one fipsboot=true and no fipsboot=false on that path.¶

13.1. Simple to Implement

The nature of attestation requires the attestation service to be implemented in an extremely privileged position within the HSM so that it can collect measurements of both the hardware environment and the application keys being attested. For many HSM and TPM architectures, this will place the Attestation Service inside the "HSM kernel" and potentially subject to FIPS 140-3 or Common Criteria validation and change control. For both security and compliance reasons there is incentive for the emitting and parsing logic to be simple and easy to implement correctly. Additionally, when the data formats contained in this specification are parsed within an HSM boundary -- that would be parsing a request entity, or parsing an attestation produced by a different HSM -- implementers SHOULD opt for simple logic that rejects any data that does not match the expected format instead of attempting to be flexible.¶

In particular, Attesting Services SHOULD generate the attestation object from scratch and avoid copying any content from the request. Attesting Services MUST NOT allow unrecognized attributes or any attribute value other than the nonce to be echoed from the request into the attestation object.¶

13.2. Detached Signatures

TODO beef this up¶

No indication within the tbs content about what or how many signatures to expect.¶

A SignatureBlock can be trivially stripped off without leaving any evidence.¶

When multiple SignatureBlocks are used for providing third party counter-signatures, note that the counter signature only covers the tbs content and not existing SignatureBlocks.¶

13.3. Privacy

Often, a TPM will host cryptographic keys for both the kernel and userspace of a local operating system but a Presenter may only represents a single user or application. Similarly, a single enterprise-grade Hardware Security Module will often host cryptographic keys for an entire multi-tenant cloud service and the Presenter or Reciever or Recipient belongs only to a single tenant. For example the HSM backing a TLS-terminating loadbalancer fronting thousands of un-related web domains. In these cases, disclosing that two different keys reside on the same hardware, or in some cases even disclosing the existance of a given key, let alone its attributes, to an unauthorized party would constitute an egregious privacy violation.¶

Implementions SHOULD be careful to avoid over-disclosure of information, for example by authenticating the Presenter as described in Section 13.4 and only returning results for keys and envirnments for which it is authorized. In absence of an existing mechanism for authenticating and authorizing administrative connections to the HSM, the attestation request MAY be authenticated by embedding the ClaimDescriptionTbs of the request inside a PkixEvidence signed with a certificate belogning to the Presenter.¶

Furthermore, enterprise and cloud-services grade HSMs SHOULD support the full set of attestation request functionality described in Section 9 so that Presenters can fine-tune the content of a PKIX Attestation such that it is appropriate for the intended Recipient.¶

13.4. Authenticating and Authorizing the Presenter

The Presenter represents a priviledged role within the architecture of this specification as it gets to learn about the existence of application keys and their protection properties, as well as details of the platform. The Presenter is in the position of deciding how much information to disclose to the Recipient, and to request a suitably redacted attestation from the HSM.¶

For personal cryptographic tokens it might be appropriate for the attestation request interface to be un-authenticated. However, for enterprise and cloud-services grade HSMs the Presenter SHOULD be authenticated using the HSM's native authentication mechanism. The details will be HSM-specific and are thus left up to the implementer, however it is RECOMMENDED to implement an authorization framework similar to the following.¶

A Presenter SHOULD be allowed to request attestation for any application keys which it is allowed to use. For example, a TLS application that is correctly authenticated to the HSM in order to use its TLS keys SHOULD be able to request attestation of those same keys without needing to perform any additional authentication or requiring any additional roles or permissions. HSMs that wish to allow a Presenter to request attestation of keys which is not allowed to use, for example for the purposes of displaying HSM status information on an administrative console or UI, SHOULD have a "Attestation Requester" role or permission and SHOULD enforce the HSM's native access controls such that the Presenter can only retrieve attestations for keys for which it has read access.¶

13.5. Proof-of-Possession of Application Keys

With asymmetric keys within a Public Key Infrastructure (PKI) it is common to require a key holder to prove that they are in control of the private key by using it. This is called "proof-of-possession (PoP)". This specification intentionally does not provide a mechnaism for PoP of application keys and relies on the Presenter, Recipient, Verifier, and Relying Party trusting the Attester to correctly report the cryptographic keys that it is holding.¶

It would be easy to add a PoP Key Attribute that uses the attested application key to sign over, for example, the Transaction Entity, however this is a bad idea and MUST NOT be added as a custom attribute for several reasons.¶

First, an application key intended, for example, for TLS SHOULD only be used with the TLS protocol and introducing a signature oracle whereby the TLS application key is used to sign attestation content could lead to cross-protocol attacks whereby the attacker submits a nonce value which is in fact not random but is crafted in such a way as to appear as a valid message in some other protocol context or exploit some other weakness in the signature algorithm.¶

Second, the Presenter who has connected to the HSM to request an attestation may have permissions to view the requested application keys but not permission to use them, as in the case where the Presenter is an administrative UI displaying HSM status information to an systems administrator or auditor. Requiring the Attestation Service to use the attested application keys could, in some architectures, require the Attestation Service to resolve complex access control logic and handle complex error conditions for each requested key, which violates the "simple to implement" design principle outlined in Section 13.1. More discussion of authenticating the Presenter can be found in Section 13.4.¶

In cases where explicit PoP is required for a given attested application key, it MUST be done as part of the regular usage protocol for which that key is intended and performed through the HSM's regular application interface, not its attestation interface. For example, PoP could be performed by signing a Certificate Signing Request (CSR), through a PKI enrollment protocol such as Certificate Management Protocol (CMP) which includes a challenge-response PoP, by using the key within a TLS handshake, or some other protocol which is part of the key's intended usage.¶

14.1. Normative References

[FIPS.140-3]

NIST - Information Technology Laboratory, "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES", FIPS 140-3, n.d., <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf>.

[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>.

[PKCS11]

Cox, D. B. T., "PKCS #11 Specification Version 3.1", n.d., <https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/cs01/pkcs11-spec-v3.1-cs01.html>.

[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>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[X.680]

ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", n.d., <https://www.itu.int/rec/T-REC-X.680>.

[X.690]

ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2015, November 2015.

14.2. Informative References

[CNSA2.0]

"Commercial National Security Algorithm Suite 2.0", n.d., <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>.

[codesigningbrsv3.8]

"Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates Version 3.8.0", n.d., <https://cabforum.org/working-groups/code-signing/documents/>.

[I-D.fossati-tls-attestation]

Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-09, 30 April 2025, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-09>.

[I-D.ietf-lamps-csr-attestation]

Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-21, 5 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-21>.

[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-18, 29 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-18>.

[RFC2986]

Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/rfc/rfc2986>.

[RFC4211]

Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <https://www.rfc-editor.org/rfc/rfc4211>.

[RFC6024]

Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <https://www.rfc-editor.org/rfc/rfc6024>.

[RFC9019]

Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Firmware Update Architecture for Internet of Things", RFC 9019, DOI 10.17487/RFC9019, April 2021, <https://www.rfc-editor.org/rfc/rfc9019>.