Skip to content

Commit

Permalink
Update draft-ietf-lamps-csr-attestation.md
Browse files Browse the repository at this point in the history 
Updated description based on Mike's feedback
  • Loading branch information
@hannestschofenig
hannestschofenig authored Dec 18, 2023
1 parent d8bef79 commit b74cef6
Showing 1 changed file with 74 additions and 41 deletions.
115 changes: 74 additions & 41 deletions draft-ietf-lamps-csr-attestation.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -225,7 +225,7 @@ CertificateAlternatives.
| Attribute or |
| Extension |
+--------+-----------+
|1
|0
| n +-------------------------+
| +-------------+ CertificateAlternatives |
| | +-------------------------+
Expand All @@ -234,7 +234,7 @@ CertificateAlternatives.
| | | TypedFlatCert |
| | +-------------------------+
|n 0|
+--------+---------+-+ 1 n +-------------------+
+--------+---------+-+ 0 n +-------------------+
| EvidenceBundle +-----------+ EvidenceStatement |
+--------------------+ +-------------------+
| Type |
Expand All @@ -245,62 +245,49 @@ CertificateAlternatives.

The following use cases are supported:

1 Single Attester, which only distributes Evidence without any certificate chains,
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.

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

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

4 In the last scenario, we also assume a Composite Device but in this case the
lead Attester has additional processing capabilities to parse 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.
Assuming that each Attester is provisioned with a unique end-entity certificate,
the certificate chains will at least differ with respect to the end-entity
certificates. It is therefore necessary to convey certificate information that
is unique to each EvidenceStatement structure while also conveying a certificate
chain that is common accross all Attesters. As a result, multiple EvidenceBundle
structures each 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.

Note that this specification does not mandate optimizing certificate chains
since there are trade-offs between Attester complexity and bandwidth consumption.

Graphically, the four use cases can be shown as follows:
structure. {{fig-single-attester}} shows this use case.

~~~
Use Case 1:
+--------------------+
| EvidenceBundle |
+--------------------+
| EvidenceStatement |
+--------------------+
~~~
{: #fig-single-attester title="Use Case 1: Single Attester without Certificate Chain."}


Use Case 2:
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."}

Use Case 3:

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
Expand All @@ -312,8 +299,18 @@ Use Case 3:
| 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)

Use Case 4:
+-------------------------+
| EvidenceBundle (1) |\
Certificate +-------------------------+ \ Provided by
Expand All @@ -327,7 +324,43 @@ Use Case 4:
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.

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

Expand Down

0 comments on commit b74cef6

Please sign in to comment.