Merge pull request #118 from riscv-non-isa/issue84

Biblio references cleanup

src/appendix_a.adoc

@@ -10,7 +10,7 @@ VMM-managed hart f/v registers* are expected to be saved/restored by the
 VMM before a TEECALL, and restored (similar to v/f register management 
 performed by the VMM for ordinary guest VMs). The TSM-driver saves OS/VMM 
 S/HS-mode CSRs and x registers on ECALLs into the HSSA on a TEECALL (per 
-the RISC-V SBI <<R5>> convention). The TSM-driver initializes TSM S/HS-mode 
+the RISC-V SBI <<SBI>> convention). The TSM-driver initializes TSM S/HS-mode
 CSRs from the TSSA on entry into the TSM (via TEECALL). Per-Hart TSM f/v 
 registers* state is managed (saved/restored) by the TSM in reserved memory 
 for the TSM (hence not shown below).

src/attestation.adoc

@@ -170,7 +170,7 @@ The TVM measurement extension interface is exposed through the optional COVG-ABI
 [NOTE]
 ====
 If an implementation uses UEFI firmware to initialize the CoVE TVM guest
-environment, then refer to UEFI specification <<R23>> chapter 38 on confidential
+environment, then refer to UEFI specification <<UEFI>> Ch.38 on confidential
 computing for UEFI ABI related to runtime measurement extension and
 event log creation.
 ====
@@ -187,7 +187,7 @@ In this section, we describe the high level model of remote attestation for CoVE
 
 ==== Model
 
-The CoVE attestation model follows the IETF RATS <<R1>> Remote Attestation
+The CoVE attestation model follows the IETF RATS <<RATS>> Remote Attestation
 architecture. CoVE implementations perform the RATS Attester role, and each CoVE
 TCB component participates to the generation of a layered Attestation Evidence
 composed of TCB specific Claims. Moreover, the generated CoVE Evidence freshness
@@ -197,7 +197,7 @@ Set. This is enforced by the `sbi_covg_get_evidence` intrinsic signature.
 In Remote Attestation, the Attester produces information about itself
 (Evidence) to enable a remote peer (the Relying Party) to decide whether to
 consider that Attester a trustworthy peer or not.
-The Verifier authenticates the Evidence with Endorser provided trust anchors
+The Verifier authenticates the Evidence with Endorser-provided trust anchors
 (Endorsements), compares it against Reference Values and appraises it via
 appraisal policies. It eventually creates Attestation Results to support
 Relying Parties in their decision process.
@@ -327,10 +327,10 @@ measurement to support the CoVE layered RTMs attestation of CoVE workloads.
 
 The CoVE Attestation Evidence uses the IETF Entity Attestation Token (<<EAT>>),
 formatted as an untagged, unprotected Concise Binary Object Representation
-(<<CBOR>>) Web Token (<<UCCS>>). A CoVE EAT profile is proposed to narrow the
+(<<CBOR>>) Web Token (<<CWT>>, <<UCCS>>). A CoVE EAT profile is proposed to narrow the
 EAT specification for the CoVE use case to enable interoperability.
 
-The UCCS (Unprotected CWT Claims Set) is composed of one EAT submodule Claims-Set 
+The UCCS (Unprotected CWT Claims Set) is composed of one EAT submodule Claims-Set
 map where the map values are attestation tokens for the TVM, TSM and Platform Claims.
 
 The TVM EAT is a CWT tagged CBOR formatted token, wrapped with a
@@ -786,6 +786,16 @@ signed with the TSM attestation key. The algorithm used to sign the certificate
 is described by the COSE_Sign1 envelope. It is recommended to use an EdDSA
 scheme with SHA-512, e.g. Ed25519.
 
+[NOTE]
+====
+The COSE_Sign structure might include signatures generated with both the
+Edwards-curve Digital Signature Algorithm (EdDSA) <<RFC8032>> and the Elliptic
+Curve Digital Signature Algorithm (ECDSA) <<DSS>>. This allows recipients to
+verify the signature associated with one algorithm or the other. More detailed
+information on multiple signature evaluations can be found in IETF RFC 5752
+<<RFC5752>>.
+====
+
 The CBOR certificate COSE_Sign1 payload is a CWT which claim set is composed of
 the CoVE evidence token and 2 additional claims:
 

src/bibliography.adoc

@@ -1,71 +1,82 @@
 [bibliography]
 == Bibliography
 
-* [[[R0,0]]] RISC-V Privileged specification
+* [[[PRIVISA,1]]] RISC-V Privileged specification
 https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf
 
-* [[[R1,1]]] IETF RFC 9334 Remote ATtestation procedureS (RATS) Architecture
+* [[[RATS,2]]] IETF RFC 9334 Remote ATtestation procedureS (RATS) Architecture
 https://datatracker.ietf.org/doc/rfc9334/
 
-* [[[DICE,2]]] TCG DICE Attestation Architecture, Version 1.00 Revision 0.23
+* [[[DICE,3]]] TCG DICE Attestation Architecture, Version 1.00 Revision 0.23
 https://trustedcomputinggroup.org/resource/dice-attestation-architecture/
 
-* [[[R3,3]]] DMTF DSP0274 Security Protocol and Data Model (SPDM) Specification, Version 1.2.1
-https://www.dmtf.org/dsp/DSP0274
+* [[[SPDM,4]]] DMTF DSP0274 Security Protocol and Data Model (SPDM) Specification, Version 1.2.3
+https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.2.3.pdf
 
-* [[[R4,4]]] TCG Reference Integrity Manifest (RIM) Information Model
-https://trustedcomputinggroup.org/resource/tcg-reference-integrity-manifest-rim-information-model/
-
-* [[[R5,5]]] RISC-V Supervisor Binary Interface
+* [[[SBI,5]]] RISC-V Supervisor Binary Interface
 https://github.com/riscv-non-isa/riscv-sbi-doc[riscv-non-isa/riscv-sbi-doc]
 
-* [[[R6,6]]] RISC-V Debug Specification Standard
+* [[[RVIDBG,6]]] RISC-V Debug Specification Standard
 https://github.com/riscv/riscv-debug-spec/blob/master/riscv-debug-stable.pdf
 
-* [[[R7,7]]] RISC-V Zero-Trust Platform Security Model
-https://docs.google.com/document/d/1TRHhsGiB5W4K8M7I4e-f40mOPErTb9sv/edit#heading=h.gjdgxs
+* [[[OT,7]]] OpenTitan
+https://opentitan.org/
 
-* [[[R8,8]]] Trusted Computing Group (TCG) Glossary, Version 1.1 Revision 1.0
+* [[[TCGG,8]]] Trusted Computing Group (TCG) Glossary, Version 1.1 Revision 1.0
 https://trustedcomputinggroup.org/resource/tcg-glossary/
 
-* [[[R9,9]]] The RISC-V Advanced Interrupt Architecture Document v0.2.1-draft
-https://github.com/riscv/riscv-aia/releases[https://github.com/riscv/riscv-aia/releases]
+* [[[RVIAIA,9]]] The RISC-V Advanced Interrupt Architecture Document v0.2.1-draft
+https://github.com/riscv/riscv-aia/releases[https://github.com/riscv/riscv-aia/releases
 
-* [[[R10,10]]] The RISC-V Nested Acceleration ("NACL") extension[https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v2.0-rc8/riscv-sbi.pdf]
+* [[[RVINACL,10]]] The RISC-V Nested Acceleration ("NACL") extension
+https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v2.0-rc8/riscv-sbi.pdf
 
 * [[[EAT,11]]] IETF Entity Attestation Token (EAT)
 https://github.com/ietf-rats-wg/eat[https://github.com/ietf-rats-wg/eat]
 
 * [[[CBOR,12]]] Concise Binary Object Representation
-https://datatracker.ietf.org/doc/rfc8949/[https://datatracker.ietf.org/doc/rfc8949/]
+https://datatracker.ietf.org/doc/rfc8949/[https://datatracker.ietf.org/doc/rfc8949/
 
 * [[[CWT,13]]] CBOR Web Token
-https://datatracker.ietf.org/doc/rfc8392/[https://datatracker.ietf.org/doc/rfc8392/]
+https://datatracker.ietf.org/doc/rfc8392/[https://datatracker.ietf.org/doc/rfc8392/
 
 * [[[UCCS,14]]] Unprotected CWT Claims Sets
-https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/[https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/]
+https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/[https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/
 
 * [[[COSE,15]]] CBOR Object Signing and Encryption
-https://datatracker.ietf.org/doc/rfc9052/[https://datatracker.ietf.org/doc/rfc9052/]
+https://datatracker.ietf.org/doc/rfc9052/[https://datatracker.ietf.org/doc/rfc9052/
 
 * [[[Hash_Algorithm_Names,16]]] IANA Hash Function Textual Names
-https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml[https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml]
+https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml[https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml
 
 * [[[TCG_Client,17]]] TCG PC Client Platform Profile
 https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/
 
 * [[[X509,18]]] X.509 Certificate Profile
-https://www.rfc-editor.org/rfc/rfc5280[https://www.rfc-editor.org/rfc/rfc5280]
+https://www.rfc-editor.org/rfc/rfc5280[https://www.rfc-editor.org/rfc/rfc5280
 
 * [[[X509_DSA,19]]] X.509 Algorithms for DSA and ECDSA
-https://datatracker.ietf.org/doc/rfc5758/[https://datatracker.ietf.org/doc/rfc5758/]
+https://datatracker.ietf.org/doc/rfc5758/[https://datatracker.ietf.org/doc/rfc5758/
+
+* [[[RVISD,20]]] RISC-V Supervisor Domain Access Protection
+https://github.com/riscv/riscv-smmtt/releases/download/v1.0.4/smmtt-spec.pdf
+
+* [[[RVISEC,21]]] RISC-V Security Model
+https://github.com/riscv-non-isa/riscv-security-model/releases/download/v1.0/riscv-platform-security-model.pdf
+
+* [[[RVICOVEIO,22]]] RISC-V CoVE-IO
+https://github.com/riscv-non-isa/riscv-ap-tee-io/releases/download/v0.1.0/riscv-cove-io.pdf
 
-* [[[R20,20]]] RISC-V Supervisor Domain Access Protection[https://github.com/riscv/riscv-smmtt/releases/download/v1.0.4/smmtt-spec.pdf]
+* [[[UEFI, 23]]] Unified Extensible Firmware Interface (UEFI) Specification v2.11
+https://uefi.org/specs/UEFI/2.11/index.html
 
-* [[[R21,21]]] RISC-V Platform Security Model[https://github.com/riscv-non-isa/riscv-security-model/releases/download/0.1/riscv-platform-security-model.pdf]
+* [[[RFC8032,24]]] IETF RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA)
+https://datatracker.ietf.org/doc/rfc8032/
 
-* [[[R22,22]]] RISC-V CoVE-IO[https://github.com/riscv-non-isa/riscv-ap-tee-io/releases/download/v0.1.0/riscv-cove-io.pdf]
+* [[[DSS,25]]] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-5, DOI 10.6028/NIST.FIPS.186-5, February 2023
+https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
 
-* [[[R23, 23]]] Unified Extensible Firmware Interface (UEFI) Specification v2.1[https://uefi.org/specs/UEFI/2.10/index.html]
+* [[[RFC5752,26]]] IETF RFC 5752 Multiple Signatures in Cryptographic Message Syntax (CMS)
+https://datatracker.ietf.org/doc/rfc5752/
 
 bibliography::[]

src/glossary.adoc

@@ -20,7 +20,7 @@ HW-rooted cryptographically-protected evidence.
 
 | CDI | Compound device identifier (CDI) is the value that represents the
 hardware, software and firmware combination measured by the TCB elements
-transitively. A CDI is the output of a DICE <<R2>> and is passed to the entity
+transitively. A CDI is the output of a DICE <<DICE>> and is passed to the entity
 which is measured by the previous TCB layer. The CDI is a secret that may be
 certified to use for attestation protocols.
 
@@ -30,7 +30,8 @@ performing computation in a hardware-based, attested TEE.
 | CoVE | Confidential VM extension (CoVE) is the set of non-ISA RISC-V ABI
 extensions defined in this specification that enables confidential computing on
 RISC-V platforms. In some deployment models, the CoVE ABI leverages the RISC-V
-ISA extensions specified in the RISC-V Supervisor Domains specification <<R20>>.
+ISA extensions specified in the RISC-V Supervisor Domains Access Protection
+specification <<RVISD>>.
 CoVE is a Trusted Execution Environment (TEE) ABI for Application Processors
 (APs). A supervisor domain that provides HW-isolation for workload data assets
 when in use (user/supervisor code/data) and provides HW-attestable
@@ -66,13 +67,13 @@ resources.
 | MTT | Memory Tracking Table (MTT).
 
 | Relying party | An entity that depends on the validity of information about
-another entity, typically for purposes of authorization <<R1>>.
+another entity, typically for purposes of authorization <<RATS>>.
 
-| RISC-V Supervisor Domains | RISC-V privileged architecture <<R0>> defines
+| RISC-V Supervisor Domains | RISC-V privileged architecture <<PRIVISA>> defines
 the S-mode for execution of supervisor software. S-mode software may optionally
 enable the Hypervisor extension to host virtual machines. Typically, there is a
 single supervisor domain of execution with access to all physical memory.
-*Supervisor Domains* <<R20>> is a RISC-V privileged architecture extension to
+*Supervisor Domains* <<RVISD>> is a RISC-V privileged architecture extension to
 support physical address space (memory and devices) isolation for more than one
 supervisor domain. Supervisor domains enable the reduction of the supervisor
 Trusted Computing Base (TCB), with differential access to memory and other
@@ -83,11 +84,11 @@ immutable ROM firmware and isolated compute and memory elements that form the
 Trusted Compute Base (TCB) of a TEE system. The RoT manages cryptographic keys
 and other security critical functions such as system lifecycle and debug
 authorization. The RoT provides trusted services to other software on the
-platform such as verified boot, key provisioning, and management, security
+platform such as verified boot, key provisioning and management, security
 lifecycle management, sealed storage, device management, crypto services,
-attestation etc. The RoT may be an integrated or discrete element <<R7>>,
+attestation etc. The RoT may be an integrated or discrete element e.g.<<OT>>,
 and may take on the role of a Device Identification Composition Engine
-(DICE) as defined in <<R2>>.
+(DICE) as defined in TCG DICE<<DICE>>.
 
 | SVN | Security version number (SVN) is the meta-data about the Trusted
 Compute Base (TCB) components that conveys the security posture of the TCB.

src/overview.adoc

@@ -32,7 +32,7 @@ specification. The underlying memory isolation mechanism for supervisor domains
 (Smmtt) is agnostic of the number of supervisor domains. On processors that do
 not support multiple supervisor domains where Smmtt is not mandated, a single
 confidential  supervisor domain and a single hosting supervisor domain can be
-supported using other hardware memory isolation techniques like PMP 
+supported using other hardware memory isolation techniques like PMP
 (for example <<dep3>>, other deployment models are also possible).
 
 [id=dep1]
@@ -92,7 +92,7 @@ hart. The TSM itself operates in HS-mode (priv=01; V=0) of the hart and enables
 the OS/VMM (also in HS-mode) to create TVMs, assign resources to TVMs, manage,
 execute and destroy a TVM - _this specification aims to describe the TEEI and
 TSM interfaces_. By using the Hypervisor extension of the RISC-V privileged
-specification <<R0>>, this specification minimizes ISA changes to introduce
+specification <<PRIVISA>>, this specification minimizes ISA changes to introduce
 a scalable architecture for hosting TEE workloads. More than one confidential
 supervisor domain may be hosted by the TSM-driver. Similarly, more than one
 TVM may be hosted by the host OS/VMM via confidential supervisor domains.
@@ -152,7 +152,7 @@ permitted as per the active permissions enforced by the memory management unit
 Smmtt for CoVE). This per-hart execution context is used by the processor to
 enforce access-control properties on memory accessed by TEE workloads managed by
 the TSM. The details of the supervisor domain access protection is specified in
-the Smmtt specification <<R20>>.
+the Smmpt specification <<RVISD>>.
 
 TSM functionality should be explicitly limited to support only the security
 primitives to ensure that the OS/VMM and non-confidential VMs do not violate

src/refarch.adoc

@@ -215,7 +215,7 @@ scrubbing memory when being assigned to a TVM.
 === TSM initialization
 
 The CoVE architecture requires a hardware root-of-trust (RoT) for supporting
-TCB measurement, reporting and storage <<R8>>. The root-of-trust for
+TCB measurement, reporting and storage <<TCGG>>. The root-of-trust for
 measurement (RTM) is defined as the TCB component that performs a
 measurement of an entity and cryptographically signs it as attestation
 evidence subsequently reported to a relying party. The
@@ -349,7 +349,7 @@ TSM-driver*
 
 * If trap is a synchronous trap due to TEECALL/ TEERESUME then activate
 confidential supervisor domain for the hart via M-mode `mmpt` CSR (See
-Supervisor Domains specification <<R20>> for CSR definition)
+Supervisor Domains specification <<RVISD>> for CSR definition)
 * Locate the per-hart THCS (located within TSM-driver memory data region)
 * Save operating VMM csr context into the THCS.hssa (Hart Supervisor State
 Area) fields: sstatus, stvec, scounteren, sscratch, satp (and other x
@@ -387,7 +387,7 @@ any v/f register state must be restored by the caller.
 * TSM-driver passes TSM/TVM-specified register contents to the OS/VMM to
 return status from TEERET (TSM sets a0, a1 registers always - other
 registers may be selected by the TVM)
-* Enable hosting supervisor domain on hart (via Superisor Domains <<R20>>
+* Enable hosting supervisor domain on hart (via Superisor Domains <<RVISD>>
 M-mode CSR `mmpt` to disable non-TCB accesses to confidential memory.)
 * MRET to resume execution in OS/VMM at mepc set to THCS.hssa.pc
 (THCS.hssa.pc adjusted to refer to opcode after the ECALL that triggered
@@ -551,7 +551,7 @@ In order to support probe-mode debugging of the TSM, the RoT must support
 an authorized debug of the platform. The authentication mechanism used for
 debug authorization is implementation-specific, but must support the
 security properties described in Section 3.12 of the RISC-V Debug
-Support specification version 1.0.0-STABLE <<R6>>. The RoT may support
+Support specification version 1.0.0-STABLE <<RVIDBG>>. The RoT may support
 multiple levels of debug authorization depending on access granted. For
 probe-based debugging of the hardware, the RoT performing debug
 authentication must ensure that separate attestation keys are used for TCB

src/sbi_cove.adoc

@@ -198,7 +198,7 @@ Host needs access to some of the TVM CSRs and GPRs to handle TVM exits. For
 example, the host needs `htval` to determine the fault address, `a0`-`a7` GPRs
 to handle forwarded ECALLs and so on. For this purpose, the host and
 TSM use the Nested Acceleration (NACL) extension based shared memory interface
-<<R10>>, from now on called NACL shared memory to avoid confusion with shared
+<<RVINACL>>, from now on called NACL shared memory to avoid confusion with shared
 memory pages between TVM and the host.
 
 The NACL shared memory interface is between TSM and the host and TSM is

src/swlifecycle.adoc

@@ -116,7 +116,7 @@ to cause IPIs to the virtual-harts managed by the TVM OS (and verified by
 the TVM OS to ensure the IPIs are received by the TVM OS to invalidate the
 TLB lazily).
 
-For implementations using AIA <<R9>>, this reference architecture requires
+For implementations using AIA <<RVIAIA>>, this reference architecture requires
 use of AIA IMSIC to ensure these IPIs are delivered through the IMSIC associated
 with the guest TVM. Each TVM is allocated a guest interrupt file during TVM
 initialization.