diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index a099400..29256a7 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -225,7 +225,7 @@ CertificateAlternatives. | Attribute or | | Extension | +--------+-----------+ - |1 + |0 | n +-------------------------+ | +-------------+ CertificateAlternatives | | | +-------------------------+ @@ -234,7 +234,7 @@ CertificateAlternatives. | | | TypedFlatCert | | | +-------------------------+ |n 0| - +--------+---------+-+ 1 n +-------------------+ + +--------+---------+-+ 0 n +-------------------+ | EvidenceBundle +-----------+ EvidenceStatement | +--------------------+ +-------------------+ | Type | @@ -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 @@ -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 @@ -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) | + | | + | } | + +------------------------------+ ~~~ +{: #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