< draft-birkholz-rats-reference-interaction-model-00.txt   draft-birkholz-rats-reference-interaction-model-01.txt >
TBD H. Birkholz RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft M. Eckel
Intended status: Informational M. Eckel Intended status: Informational Fraunhofer SIT
Expires: September 13, 2019 Huawei Expires: January 9, 2020 July 08, 2019
March 12, 2019
Reference Interaction Model for Challenge-Response-based Remote Reference Interaction Model for Challenge-Response-based Remote
Attestation Attestation
draft-birkholz-rats-reference-interaction-model-00 draft-birkholz-rats-reference-interaction-model-01
Abstract Abstract
This document defines an interaction model for a basic remote This document defines an interaction model for a basic remote
attestation procedure. Additionally, the required information attestation procedure. Additionally, the required information
elements are illustrated. elements are illustrated.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 33
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 September 13, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2
2. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 2 2. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Component Roles . . . . . . . . . . . . . . . . . . . . . . . 3 4. Component Roles . . . . . . . . . . . . . . . . . . . . . . . 3
5. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Remote Attestation Interaction Model . . . . . . . . . . . . 4 6. Remote Attestation Interaction Model . . . . . . . . . . . . 4
6.1. Information Elements . . . . . . . . . . . . . . . . . . 4 6.1. Information Elements . . . . . . . . . . . . . . . . . . 4
7. Interaction Model . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Interaction Model . . . . . . . . . . . . . . . . . . . . 6
8. Further Context . . . . . . . . . . . . . . . . . . . . . . . 6 7. Further Context . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 6 7.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7
8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 6 7.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 7
8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 7 7.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security and Privacy Considerations . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. CDDL Specification for a simple CoAP
Challenge/Response Interaction . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Remote attestation procedures (RATS) are a combination of activities, Remote attestation procedures (RATS) are a combination of activities,
in which a Verifier creates assertions about claims of integrity and in which a Verifier creates assertions about assertions of integrity
about the characteristics of other system entities by the appraisal and about characteristics of other system entities by the appraisal
of corresponding signed claims (evidence). In this document, a of corresponding signed assertions (evidence). In this document, a
reference interaction model for a generic challenge-response-based reference interaction model for a generic challenge-response-based
remote attestation procedure is provided. The minimum set of remote attestation procedure is provided. The minimum set of
components, roles and information elements that have to be conveyed components, roles and information elements that have to be conveyed
between Verifier and Attester are defined as a standard reference to between Verifier and Attester are defined as a standard reference to
derive more complex RATS from. derive more complex RATS from.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 RFC "OPTIONAL" in this document are to be interpreted as described in
2119, BCP 14 [RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Disambiguation 2. Disambiguation
The term "Remote Attestation" is a common expression and often The term "Remote Attestation" is a common expression and often
associated with certain properties. The term "Remote" in this associated with certain properties. The term "Remote" in this
context does not necessarily refer to a remote system entity in the context does not necessarily refer to a remote system entity in the
scope of network topologies or the Internet. It rather refers to a scope of network topologies or the Internet. It rather refers to a
decoupled system or different computing context, which also could be decoupled system or different computing context, which also could be
present locally as components of a composite device. Examples present locally as components of a composite device. Examples
include: a Trusted Execution Environment (TEE), Baseboard Management include: a Trusted Execution Environment (TEE), Baseboard Management
skipping to change at page 3, line 40 skipping to change at page 3, line 47
Attester: The role that designates the subject of the remote Attester: The role that designates the subject of the remote
attestation. A system entity that is the provider of evidence attestation. A system entity that is the provider of evidence
takes on the role of an Attester. takes on the role of an Attester.
Verifier: The role that designates the system entity and that is the Verifier: The role that designates the system entity and that is the
appraiser of evidence provided by the Attester. A system entity appraiser of evidence provided by the Attester. A system entity
that is the consumer of evidence takes on the role of a Verifier. that is the consumer of evidence takes on the role of a Verifier.
5. Prerequisites 5. Prerequisites
Identity: An Attester must have a unique Identity in such a way that Attester Identity:
a Verifier can uniquely identify an Attester. This Identity MUST
be part of the signed claims (attestation evidence) that the
Attester conveys to the Verifier.
Secret: A Secret that is present on the Attester and that a Verifier Attestation Authenticity: An Attestation MUST be authentic.
can identify by its Secret ID, e.g. a public key. This Secret
MUST be established before a remote attestation procedure can take An attestation, in order to be authentic, MAY This Identity MUST
place. How this Secret is established is out of scope for this be part of the signed assertions (attestation evidence) that the
reference model. Attester conveys to the Verifier. An Identity MAY be a unique
identity or it MAY be included in a zero-knowledge proof (ZKP) or
be part of a group signature.
Authentication Secret: An Authentication Secret MUST be present on
the Attester. The Attester MUST sign assertions with that
Authentication Secret, proving the authenticity of the assertions.
The Authentication Secret MUST be established before a remote
attestation procedure can take place. How it is established is
out of scope for this reference model.
6. Remote Attestation Interaction Model 6. Remote Attestation Interaction Model
This section defines the information elements that have to be This section defines the information elements that have to be
conveyed via a protocol, enabling the conveyance of Evidence between conveyed via a protocol, enabling the conveyance of Evidence between
Verifier and Attester, as well as the interaction model for a generic Verifier and Attester, as well as the interaction model for a generic
challenge-response scheme. challenge-response remote attestation scheme.
6.1. Information Elements 6.1. Information Elements
Nonce: mandatory Attester Identity ('attesterIdentity'): _mandatory_
The Nonce (number used once) is a number intended to be unique and A statement about a distinguishable Attester made by an entity
intended to be effectively infeasible to guess. In this reference without accompanying evidence of its validity, used as proof of
interaction model it MUST be provided by the Verifier and MUST be identity.
used as a proof of freshness, with respect to conveyed evidence
ensuring that the result of an attestation activity was created
recently (i. e. triggered by the challenge emitted by the
Verifier). As such, the Nonce MUST be part of the signed evidence
sent by the Attester to the Verifier.
Secret ID: mandatory Authentication Secret ID ('authSecID'): _mandatory_
An identifier that MUST be associated with the Secret which is An identifier that MUST be associated with the Authentication
used to sign the evidence. Secret which is used to sign evidence.
Evidence: mandatory Nonce ('nonce'): _mandatory_
The signed claims that are required to enable integrity proving of The Nonce (number used once) is intended to be unique and
the corresponding characteristics of the Attester. Examples of practically infeasible to guess. In this reference interaction
claims included in attestation evidence are claims about sensor model the Nonce MUST be provided by the Verifier and MUST be used
data, policies that are active on the system entity, versions of as proof of freshness. With respect to conveyed evidence, it
composite firmware of a platform, running software, routing ensures the result of an attestation activity to be created
tables, or information about a local time source. Attestation recently, e. g. sent or derived by the challenge from the
evidence must be cryptographically bound to the Verifier-provided Verifier. As such, the Nonce MUST be part of the signed
Nonce, the Identity of the Attester, as well as to the Secret Attestation Evidence that is sent from the Attester to the
identified by the Secret ID. Verifier.
Claim Selection: optional Assertions ('assertions'): _mandatory_
An Attester MAY provide a selection of claims that are relevant to Assertions represent characteristics of an Attester. They are
the appraisal conducted by the Verifier in order to prove required for proving the integrity of an Attester. Examples are
correctness of the (integrity) claims created by the Attester. assertions about sensor data, policies that are active on the
Usually, all available claims that are available to the Attester system entity, versions of composite firmware of a platform,
SHOULD be conveyed. This claim selection can be composed as running software, routing tables, or information about a local
complementary signed claims or can be encapsulated claims in the time source.
signed evidence that composes the evidence about integrity. This
information element is optional in order to enable a Verifier to Reference Assertions ('refAssertions') _mandatory_
narrow down or increase the amount of received evidence. An
Attester MAY decide whether or not to provide the requested claims Reference Assertions are used to verify the assertions received
or not. In either case, the claim selection MUST be from an Attester in an attestation verification process. For
cryptographically bound to the signed claim set. An example for a example, Reference Assertions MAY be Reference Integrity
claim selection is that a Verifier can request from an Attester Measurements (RIMs) or assertions that are implicitly trusted
(signed) Reference Integrity Measurements (RIMs), which represent because they are signed by a trusted authority. RIMs represent
a claim about the intended platform operational state of the (trusted) assertions about the intended platform operational state
of the Attester.
Assertion Selection ('assertionSelection'): _optional_
An Attester MAY provide a selection of assertions in order to
reduce or increase retrieved assertions to those that are relevant
to the conducted appraisal. Usually, all available assertions
that are available to the Attester SHOULD be conveyed. The
Assertion Selection MAY be composed as complementary signed
assertions or MAY be encapsulated assertions in the signed
Attestation Evidence. An Attester MAY decide whether or not to
provide all requested assertions or not. An example for an
Assertion Selection is a Verifier requesting (signed) RIMs from an
Attester. Attester.
Identity: mandatory (Signed) Attestation Evidence ('signedAttestationEvidence'): _mandat
ory_
A statement about a distinguishable Attester made by an entity Attestation Evidence consists of the Authentication Secret ID that
without accompanying evidence of its validity, used as proof of identifies an Authentication Secret, the Attester Identity, the
identity. Assertions, and the Verifier-provided Nonce. Attestation Evidence
MUST cryptographically bind all of those elements. The
Attestation Evidence MUST be signed by the Authentication Secret.
The Authentication Secret MUST be trusted by the Verifier as
authoritative.
7. Interaction Model Attestation Result ('attestationResult'): _mandatory_
An Attestation Result is produced by the Verifier as a result of a
Verification of Attestation Evidence. The Attestation Result
represents assertions about integrity and other characteristics of
the corresponding Attester.
6.2. Interaction Model
The following sequence diagram illustrates the reference remote The following sequence diagram illustrates the reference remote
attestation procedure defined by this document. attestation procedure defined by this document.
[Attester] [Verifier] [Attester] [Verifier]
| | | |
| <--- requestAttestation(nonce, secretID, claimSelection) | | <--- requestAttestation(nonce, authSecID, assertionSelection) |
| | | |
collectClaims(claimSelection) | collectAssertions(assertionSelection) |
| ===> claims | | => assertions |
| | | |
signEvidence(claims, secretID, nonce, identity) | signAttestationEvidence(authSecID, assertions, nonce) |
| ===> evidence, signature | | => signedAttestationEvidence |
| | | |
| evidence, signature, identity -------------------------> | | signedAttestationEvidence ----------------------------------> |
| | | |
| appraise(evidence, signature, identity, nonce) | verifyAttestationEvidence(signedAttestationEvidence, refAssertions)
| appraisalResult <=== | | attestationResult <= |
| | | |
The remote attestation procedure is initiated by the Verifier, The remote attestation procedure is initiated by the Verifier,
sending an attestation request to the Attester. The attestation sending an attestation request to the Attester. The attestation
request consists of a Nonce, a Secret ID, and a Claim Selection. The request consists of a Nonce, a Authentication Secret ID, and an
Nonce guarantees attestation freshness. The Secret ID selects the Assertion Selection. The Nonce guarantees attestation freshness.
secret the Attester is requested to sign the Evidence with. The The Authentication Secret ID selects the secret with which the
Claim Selection narrows down or increases the amount of received Attester is requested to sign the Attestation Evidence. The
Evidence, if required. If the Claim Selection is empty, then by Assertions Selection narrows down or increases the amount of received
default all claims that are available on the system of the Attester Assertions, if required. If the Assertions Selection is empty, then
SHOULD be signed and returned as Evidence. For example, the Verifier by default all assertions that are available on the system of the
is only interested in particular information about the Attester, such Attester SHOULD be signed and returned as Attestation Evidence. For
as whether the device booted up in a known state, and not include example, a Verifier may only be interested in particular information
information about all currently running software. about the Attester, such as proof of with which BIOS and firmware it
booted up, and not include information about all currently running
software.
The Attester, after receiving the attestation request, collects the The Attester, after receiving the attestation request, collects the
corresponding claims to compose the evidence the Verifier requested-- corresponding Assertions to compose the Attestation Evidence that the
or, in case the Verifier did not provide a claim selection, the Verifier requested--or, in case the Verifier did not provide an
Attester collects all information that can be used as complementary Assertions Selection, the Attester collects all information that can
claims in the scope of the semantics of the remote attestation be used as complementary Assertions in the scope of the semantics of
procedure. After that, the Attester signs the evidence with the the remote attestation procedure. After that, the Attester produces
secret identified by the secret ID, including the nonce and the Attestation Evidence by signing the Attester Identity, the
identity information. Then the Attester sends the output back to the Assertions, and the Nonce with the Authentication Secret identified
Verifier. Important at this point is that the nonce as well as the by the Authentication Secret ID. Then the Attester sends the signed
identity information must be cryptographically bound to the Attestation Evidence back to the Verifier.
signature, i. e. it is not required for them to be present in plain
text. For instance, those information can be part of the signature
after a one-way function (e. g. a hash function) was applied to them.
There is also a possibility to scramble the nonce or identity with
other information that is known to both the Verifier and Attester. A
prominent example is the IP address of the Attester that usually is
known by the Attester as well as the Verifier. This extra
information can be used to scramble the Nonce in order to counter
certain types of relay attacks. As soon as the Verifier receives the
evidence, it appraises it, including the verification of the
signature, the identity, the nonce, and the claims included in the
evidence. This process is application-specific and can be done by e.
g. comparing the claims to known (good), expected reference claims,
such as Reference Integrity Measurements (RIMs), or evaluating it in
other ways. The final output, the appraisal result (also referred to
as attestation result), is a new claim about properties of the
Attester, i. e. whether or not it is compliant to policies, or even
can be "trusted".
8. Further Context Important at this point is that Assertions, the Nonce as well as the
Attester Identity information MUST be cryptographically bound to the
signature of the Attestation Evidence. It is not required for them
to be present in plain text, though. Cryptographic blinding MAY be
used at this point. For further reference see Security and Privacy
Considerations (Section 8)
Depending on the use cases to cover there may be additional As soon as the Verifier receives the signed Attestation Evidence, it
requirements. verifies the signature, the Attester Identity, the Nonce, and the
Assertions. This process is application-specific and can be carried
out by, e. g., comparing the Assertions to known (good), expected
Reference Assertions, such as Reference Integrity Measurements
(RIMs), or evaluating it in other ways. The final output of the
Verifier is the Attestation Result. It constitutes an new assertion
about properties and characteristics of the Attester, i. e. whether
or not it is compliant to policies, or even can be "trusted".
8.1. Confidentiality 7. Further Context
Use confidential communication to exchange attestation information. Depending on the use cases to cover, there may be additional
This requirement usually is present when communication happens over requirements. Some of them are mentioned in this section.
insecure channels, such as the public Internet. Speaking of a
suitable communication protocol, TLS is a good candidate. In private
networks, such as carrier management networks, it must be evaluated
whether or not the transport medium is considered confidential.
8.2. Mutual Authentication 7.1. Confidentiality
Confidentiality of exchanged attestation information may be
desirable. This requirement usually is present when communication
takes place over insecure channels, such as the public Internet. In
such cases, TLS may be uses as a suitable communication protocol that
preserves confidentiality. In private networks, such as carrier
management networks, it must be evaluated whether or not the
transport medium is considered confidential.
7.2. Mutual Authentication
In particular use cases mutual authentication may be desirable in In particular use cases mutual authentication may be desirable in
such a way that a Verifier also needs to prove its identity to the such a way that a Verifier also needs to prove its identity to the
Attester instead of only the Attester proving its identity to the Attester, instead of only the Attester proving its identity to the
Verifier. Verifier.
8.3. Hardware-Enforcement/Support 7.3. Hardware-Enforcement/Support
In particular use cases hardware support can be desirable. Depending Depending on the requirements, hardware support for secure storage of
on the requirements those can be secure storage of cryptographic cryptographic keys, crypto accelerators, or protected or isolated
keys, crypto accelerators, or protected or isolated execution execution environments may be useful. Well-known technologies are
environments. Well-known technologies are Hardware Security Modules Hardware Security Modules (HSM), Physically Unclonable Functions
(HSM), Physical Unclonable Functions (PUFs), Shielded Secrets, (PUFs), Shielded Secrets, and Trusted Executions Environments (TEEs).
Trusted Executions Environments (TEEs), etc.
9. Security Considerations 8. Security and Privacy Considerations
There are always some. In a remote attestation process the Verifier or the Attester MAY want
to cryptographically blind several attributes. For instance,
information can be part of the signature after applying a one-way
function (e. g. a hash function).
10. Acknowledgements There is also a possibility to scramble the Nonce or Attester
Identity with other information that is known to both the Verifier
and Attester. A prominent example is the IP address of the Attester
that usually is known by the Attester itself as well as the Verifier.
This extra information can be used to scramble the Nonce in order to
counter certain types of relay attacks.
9. Acknowledgments
Very likely. Very likely.
11. Change Log 10. Change Log
Initial draft -00 o Initial draft -00
Changes from version 00 to version 01: o Changes from version 00 to version 01:
Added details to the flow diagram * Added details to the flow diagram
12. References o Changes from version 01 to version 02:
12.1. Normative References * Integrated comments from Ned Smith (Intel)
* Reorganized sections and
* Updated interaction model
o Changes from version 02 to version 03:
* Replaced "claims" with "assertions"
* Added proof-of-concept CDDL for CBOR via CoAP based on a TPM
2.0 quote operation
11. References
11.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>.
12.2. Informative References [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/info/rfc8174>.
11.2. Informative References
[I-D.birkholz-rats-architecture] [I-D.birkholz-rats-architecture]
Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith,
"Architecture and Reference Terminology for Remote "Architecture and Reference Terminology for Remote
Attestation Procedures", draft-birkholz-rats- Attestation Procedures", draft-birkholz-rats-
architecture-00 (work in progress), October 2018. architecture-01 (work in progress), March 2019.
Appendix A. CDDL Specification for a simple CoAP Challenge/Response
Interaction
The following CDDL specification is an examplary proof-of-concept to
illustrate a potential implementation of the Reference Interaction
Model. The transfer protocol used is CoAP using the FETCH operation.
The actual resource operated on can be empty. Both the Challenge
Message and the Response Message are exchanged via the FETCH Request
and FETCH Response body.
In this example, the root-of-trust for reporting primitive operation
"quote" is provided by a TPM 2.0.
RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body
CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed
nonce: bytes,
pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID
[ + pcr: uint .size 1 ],
]
],
]
CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote,
tpm-native-signature: bytes,
? ak-cert: bytes, ; attestation key certificate
]
TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME
TPMS_CLOCK_INFO,
firmwareVersion: uint .size 8
quote-responses: [ * [ pcr: uint .size 1,
+ [ pcr-value: bytes,
? hash-alg-id: uint .size 2,
],
],
? pcr-digest: bytes,
],
]
TPMS_CLOCK_INFO = [ clock: uint .size 8,
resetCounter: uint .size 4,
restartCounter: uint .size 4,
save: bool,
]
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@sit.fraunhofer.de
skipping to change at page 8, line 14 skipping to change at page 11, line 4
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@sit.fraunhofer.de
Michael Eckel Michael Eckel
Huawei Technologies Fraunhofer SIT
Feldbergstrasse 78 Rheinstrasse 75
Darmstadt 64293 Darmstadt 64295
Germany Germany
Email: michael.eckel@huawei.com Email: michael.eckel@sit.fraunhofer.de
 End of changes. 46 change blocks. 
164 lines changed or deleted 267 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/