Information Model Description

draft-ietf-lamps-csr-attestation.md

@@ -207,6 +207,165 @@ given attestation technology. The focus of this specification is on the
 transport of Evidence from the Attester to the Relying Party via existing
 CSR messages.
 
+# Information Model
+
+To support a number of different use cases for the transmission of
+Evidence in a CSR (together with certificate chains) the structure
+shown in {{fig-info-model}} is used.
+
+On a high-level, the structure can be explained as follows:
+A PKCS#10 attribute or a CRMF extension contains one or multiple
+EvidenceBundle structures. Each EvidenceBundle contains one or
+multiple EvidenceStatement structures as well as one or many
+CertificateAlternatives.
+
+~~~ aasvg
+ +--------------------+
+ |  PKCS#10 or CRMF   |
+ |  Attribute or      |
+ |  Extension         |
+ +--------+-----------+
+          |0
+          |                     n +-------------------------+
+          |         +-------------+ CertificateAlternatives |
+          |         |             +-------------------------+
+          |         |             | Certificate OR          |
+          |         |             | TypedCert   OR          |
+          |         |             | TypedFlatCert           |
+          |         |             +-------------------------+
+          |n       0|
+ +--------+---------+-+ 0       n +-------------------+
+ |  EvidenceBundle    +-----------+ EvidenceStatement |
+ +--------------------+           +-------------------+
+                                  | Type              |
+                                  | Statement         |
+                                  +-------------------+
+~~~
+{: #fig-info-model title="Information Model for CSR Evidence Conveyance."}
+
+The following use cases are supported:
+
+Single Attester, which only distributes Evidence without any certificate chains,
+i.e. the Verifier is assumed to be in possession of the certificate chain already
+or there is no certificate chain. As a result a single EvidenceBundle is included
+in a CSR that contains a single EvidenceStatement without the CertificateAlternatives
+structure. {{fig-single-attester}} shows this use case.
+
+~~~
+  +--------------------+
+  |  EvidenceBundle    |
+  +--------------------+
+  | EvidenceStatement  |
+  +--------------------+
+~~~
+{: #fig-single-attester title="Use Case 1: Single Attester without Certificate Chain."}
+
+
+A single Attester, which shares Evidence together with a certificate chain.
+The CSR conveys a single EvidenceBundle with a single EvidenceStatement
+and a single CertificateAlternatives structure. {{fig-single-attester-with-chain}} shows
+this use case.
+
+~~~
+ +-------------------------+
+ |  EvidenceBundle         |
+ +-------------------------+
+ | EvidenceStatement       |
+ | CertificateAlternatives |
+ +-------------------------+
+~~~
+{: #fig-single-attester-with-chain title="Use Case 2: Single Attester with Certificate Chain."}
+
+
+In a Composite Device, which contains multiple Attesters, a collection of Evidence
+statements is obtained. Imagine that each Attester returns its Evidence together with a
+certificate chain. As a result, multiple EvidenceBundle structures, each carrying
+an EvidenceStatement and the corresponding CertificateAlternative structure with the
+certificate chain as provided by each Attester, are included in the CSR. It may
+be possible that there is an overlap in the certificate chains transmitted by
+the different Attesters. This approach does not require any processing capabilities
+by a lead Attester since the information is merely forwarded. {{fig-multiple-attesters}}
+shows this use case.
+
+~~~
+  +-------------------------+
+  |  EvidenceBundle (1)     |\
+  +-------------------------+ \ Provided by
+  | EvidenceStatement       | / Attester 1
+  | CertificateAlternatives |/
+  +-------------------------+
+  |  EvidenceBundle (2)     |\
+  +-------------------------+ \ Provided by
+  | EvidenceStatement       | / Attester 2
+  | CertificateAlternatives |/
+  +-------------------------+
+~~~
+{: #fig-multiple-attesters title="Use Case 3: Multiple Attesters in Composite Device."}
+
+In the last scenario, we also assume a Composite Device with additional processing
+capabilities of the Leader Attester, which parses the certificate chains provided by
+all Attesters in the device and removes redundant certificate information. The
+benefit of this approach is the reduced transmission overhead. There are several
+implementation strategies and we show two in {{fig-multiple-attesters-optimized}}.
+
+~~~
+Implementation strategy (4a)
+
+                +-------------------------+
+                |  EvidenceBundle (1)     |\
+  Certificate   +-------------------------+ \ Provided by
+  Chain +       | EvidenceStatement       | / Attester 1
+  End-Entity -->| CertificateAlternatives |/
+  Certificate   +-------------------------+
+                         ....
+                +-------------------------+
+                |  EvidenceBundle (n)     |\
+                +-------------------------+ \ Provided by
+  End-Entity    | EvidenceStatement       | / Attester n
+  Certificate-->| CertificateAlternatives |/
+                +-------------------------+
+
+Implementation strategy (4b)
+
+ +------------------------------+
+ |  EvidenceBundle              |
+ +------------------------------+
+ | EvidenceStatement (1)        |
+ |        ...                   |
+ | EvidenceStatement (n)        |
+ | CertificateAlternatives {    |
+ |   End Entity Certificate (1) |
+ |        ...                   |
+ |   End Entity Certificate (n) |
+ |   <Remainder of the          |
+ |    Certificate Chain>        |
+ | }                            |
+ +------------------------------+
+~~~
+{: #fig-multiple-attesters-optimized title="Use Case 4: Multiple Attesters in Composite Device (with Optimization)."}
+
+In implementation strategy (4a) we assume that each Attester is provisioned with
+a unique end-entity certificate. Hence, the certificate chains will at least differ
+with respect to the end-entity certificates.
+The Lead Attester will therefore create multiple EvidenceBundle structures, each
+will carry an EvidenceStatement followed by a certificate chain in
+the CertificateAlternative structures containing most likely only the end-entity
+certificate. The shared certificate chain is carried in the first entry of the
+EvidenceBundle sequence to allow path validation to take place immediately after
+processing the first structure.
+
+Implementation strategy (4b), as an alternative, requires the Lead Attester
+to merge all certificate chains into a single EvidenceBundle containing a single
+de-duplicated sequence of CertificateAlternatives structures. This means that each
+EvidenceBundle is self-contained and any EvidenceStatement can be verified using
+only the sequence of CertificateAlternatives in its bundle, but Verifiers will have
+to do proper certification path building since the sequence of CertificateAlternatives
+is now a cert bag and not a cert chain.
+
+Note: This specification does not mandate optimizing certificate chains since
+there is a trade-off between the Attester implementation complexity and the
+transmission overhead.
+
 # ASN.1 Elements
 
 ##  Object Identifiers