generated from martinthomson/internet-draft-template
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-smith-rats-evidence-trans.md~
216 lines (175 loc) · 9.06 KB
/
draft-smith-rats-evidence-trans.md~
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
---
v: 3
title: Evidence Transformations
docname: draft-smith-rats-evidience-trans-latest
category: std
consensus: true
submissiontype: IETF
ipr: trust200902
area: "Security"
workgroup: "Remote ATtestation ProcedureS"
keyword: Evidence, RATS, attestation, verifier, supply chain, RIM, appraisal
stand_alone: true
pi:
toc: yes
sortrefs: yes
symrefs: yes
tocdepth: 6
author:
- ins: A. Draper
name: Andrew Draper
org: Intel
email: [email protected]
- ins: N. Smith
name: Ned Smith
org: Intel
email: [email protected]
normative:
I-D.ietf-rats-corim: corim
DICE.CoRIM:
-: dice-corim
title: DICE Endorsement Architecture for Devices
author:
org: Trusted Computing Group (TCG)
seriesinfo: Version 1.0, Revision 0.38
date: November 2022
target: https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-V1-R38_pub.pdf
DICE.Attest:
-: dice-attest
title: DICE Attestation Architecture
author:
org: Trusted Computing Group (TCG)
seriesinfo: Version 1.1, Revision 18
date: January 2024
target: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Attestation-Architecture-Version-1.1-Revision-18_pub.pdf
RFC9334: rats-arch
X.690:
-: x690
title: >
Information technology — ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)
author:
org: International Telecommunications Union
date: 2015-08
seriesinfo:
ITU-T: Recommendation X.690
target: https://www.itu.int/rec/T-REC-X.690
SPDM:
-: spdm
title: Security Protocol and Data Model (SPDM)
author:
org: Distributed Management Task Force
seriesinfo: Version 1.3.0
date: May 2023
target: https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.3.0.pdf
TCG.CE:
-: ce
title: TCG DICE Concise Evidence Binding for SPDM
author:
org: Trusted Computing Group
seriesinfo: Version 1.00, Revision 0.54
date: January 2024
target: https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Concise-Evidence-Binding-for-SPDM-Version-1.0-Revision-54_pub.pdf
I-D.ietf-rats-endorsements: rats-endorsements
informative:
RFC4122: uuid
RFC7468: pkix-text
RFC8610: cddl
RFC9090: cbor-oids
STD96:
-: cose
=: RFC9052
STD94:
-: cbor
=: RFC8949
STD66:
-: uri
=: RFC3986
RFC9393: coswid
RFC7942:
I-D.fdb-rats-psa-endorsements: psa-endorsements
I-D.tschofenig-rats-psa-token: psa-token
DICE.Layer:
title: DICE Layering Architecture
author:
org: Trusted Computing Group
seriesinfo: Version 1.0, Revision 0.19
date: July 2020
target: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf
IANA.coswid: coswid-reg
I-D.ietf-rats-eat: eat
I-D.ietf-rats-concise-ta-stores: ta-store
entity:
SELF: "RFCthis"
--- abstract
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not.
Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence.
Therefore that burden is typically offloaded to a Verifier.
In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester.
Before a Verifier can appraise Evidence it may require transformation to an internal representation.
This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation.
--- middle
# Introduction {#sec-intro}
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it - or not.
Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence.
Therefore that burden is typically offloaded to a Verifier.
In order to conduct Evidence appraisal, a Verifier requires fresh Evidence from an Attester.
Before a Verifier can appraise Evidence it may require transformation to an internal representation.
This document specifies Evidence transformation methods for DICE and SPDM formats to the CoRIM internal representation.
## Terminology and Requirements Language
This document uses terms and concepts defined by the RATS architecture.
For a complete glossary see {{Section 4 of -rats-arch}}.
Addintional RATS architecture is found in {{-rats-endorsements}}.
RATS architecture terms and concepts are always referenced as proper nouns, i.e., with Capital Letters.
In this document, an Evidence structure describes an external representation.
There are many possible Evidence structures including {{-eat}}
The bytes composing the CoRIM data structure are the same either way.
The terminology from CoRIM {{-corim}}, CBOR {{-cbor}}, CDDL {{-cddl}} and COSE {{-cose}} applies.
{::boilerplate bcp14}
# Verifier Reconciliation {#sec-verifier-rec}
This specification assumes the reader is familiar with Verifier Reconsiliation as described in {{-corim}}.
It describes how a Verifier should process the CoRIM to enable CoRIM authors to convey their intended meaning and how a Verifier reconciles its various inputs.
Evidence is one of its inputs.
The Verifier is expected to create an internal representation from an external representation.
By using an internal representation, the Verifier processes Evidence inputs such that they can be appraised consistently.
This specification describes how Evidence in DICE {{-dice-attest}}, SPDM {{-spdm}}, and concise evidence {{-ce}} formats are transformed into the CoRIM {{-corim}} internal representation.
If other internal representations exist, a similar specification may be required that transforms Evidence to some other internal representation.
# Transforming SPDM Evidence {#sec-spdm-trans}
This section defines how Evidence from SPDM {{-spdm}} is transformed into a format where it can be added to an appraisal claims set.
A Verifier supporting SPDM format Evidence should implement this section.
The TCG DICE Concise Evidence Binding for SPDM specification {{-ce}} describes the process by which measurements in an SPDM Measurement Block are converted to Evidence suitable for matching using the rules below.
The SPDM measurements are converted to `concise-evidence` which has a format that is similar to CoRIM `triples-map` (their semantics follows the matching rules described above).
# Transforming DICE Evidence {#sec-dice-trans}
This section defines how Evidence from DICE {{-dice-attest}} is transformed into a format where it can be added to an appraisal claims set.
A Verifier supporting DICE format Evidence should implement this section.
DICE Evidence appears in certificates in the TcbInfo or MultiTcbInfo extension.
Each TcbInfo, and each entry in the MultiTcbInfo, is converted to an `endorsed-triple-record` using the rules in this section.
In a MultiTcbInfo each entry in the sequence is treated as independent and translated into a separate Evidence object.
The Verifier SHALL translate each field in the TcbInfo into a field in the created endorsed-triple-record
- The TcbInfo `type` field SHALL be copied to the field named `environment-map / class / class-id` and tagged with tag #6.111
- The TcbInfo `vendor` field SHALL be copied to the field named `environment-map / class / vendor`
- The TcbInfo `model` field SHALL be copied to the field named `environment-map / class / model`
- The TcbInfo `layer` field SHALL be copied to the field named `environment-map / class / layer`
- The TcbInfo `index` field SHALL be copied to the field named `environment-map / class / index`
- The TcbInfo `version` field SHALL be translated to the field named `measurement-map / mval / version / version`
- The TcbInfo `svn` field SHALL be copied to the field named `measurement-map / mval / svn`
- The TcbInfo `fwids` field SHALL be translated to the field named `measurement-map / mval / digests`
- Each digest within fwids is translated to a CoMID digest object, with an appropriate algorithm identifier
- The TcbInfo `flags` field SHALL be translated to the field named `measurement-map / mval / flags`
- Each flag is translated independently
- The TcbInfo `vendorInfo` SHALL shall be copied to the field named `measurement-map / mval / raw-value`
If there are multiple `endorsed-triple-record`s with the same `environment-map` then they MUST be merged into a single entry.
If the `measurement-values-map` fields in Evidence triples have conflicting values then the Verifier MUST fail validation.
# Transforming Concise Evidence {#sec-ce-trans}
# Security and Privacy Considerations {#sec-sec}
There are no security and privacy considerations.
# IANA Considerations {#sec-iana-cons}
There are no IANA considerations.
--- back
# Contributors
The authors would like to thank the following members for their valuable contributions to the specification.
Dionna Glaze
Email: [email protected]
# Acknowledgments
{:unnumbered}