From 7b4460300ea49382ba9e02dd1c1b31e98b63445a Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Tue, 28 Nov 2023 07:36:04 +0100 Subject: [PATCH 01/10] Information Model Description This PR addresses issues #59 and #60. --- draft-ietf-lamps-csr-attestation.md | 71 +++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index a171c20..6cf0786 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -207,6 +207,77 @@ 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. + +~~~ + +--------------------+ + | PKCS#10 or CRMF | + | Attribute or | + | Extension | + +--------+-----------+ + |1 + | n +-------------------------+ + | +-------------+ CertificateAlternatives | + | | +-------------------------+ + | | | Certificate OR | + | | | TypedCert OR | + | | | TypedFlatCert | + | | +-------------------------+ + |n 1| + +--------+---------+-+ 1 n +-------------------+ + | EvidenceBundle +-----------+ EvidenceStatement | + +--------------------+ +-------------------+ + | Type | + | Statement | + +-------------------+ +~~~ + +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. + +- A single attester, which shares Evidence together with a certificate chain. +In this case, the CSR conveys a single EvidenceBundle with a single EvidenceStatement +and a single CertificateAlternatives structure. + +- In a Composite Device, which contains multiple Attesters, a collection of Evidence +is obtained. Imagine that each Attester returns its Evidence together with a +certificate chain. As a result, a multiple EvidenceBundle structures, each +carrying EvidenceStatement and CertificateAlternative structures. 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. + +- 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. We assume that the certificate chains at least differ with respect +to the end-entity certificates. Hence, it is 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 mdandate optimizing certificate chains +since there are trade-offs between Attester complexity and bandwidth consumption. + # ASN.1 Elements ## Object Identifiers From 7d339858aab844de33259c080f562ce31a91fc03 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Tue, 28 Nov 2023 08:43:41 +0100 Subject: [PATCH 02/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 34 ++++++++++++++++------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 6cf0786..535154e 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -241,23 +241,25 @@ CertificateAlternatives. | 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. +in a CSR that contains a single EvidenceStatement without the CertificateAlternatives +structure. - A single attester, which shares Evidence together with a certificate chain. -In this case, the CSR conveys a single EvidenceBundle with a single EvidenceStatement +The CSR conveys a single EvidenceBundle with a single EvidenceStatement and a single CertificateAlternatives structure. - In a Composite Device, which contains multiple Attesters, a collection of Evidence -is obtained. Imagine that each Attester returns its Evidence together with a -certificate chain. As a result, a multiple EvidenceBundle structures, each -carrying EvidenceStatement and CertificateAlternative structures. It may +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. @@ -265,15 +267,17 @@ by a lead Attester since the information is merely forwarded. - 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. We assume that the certificate chains at least differ with respect -to the end-entity certificates. Hence, it is 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. +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 mdandate optimizing certificate chains since there are trade-offs between Attester complexity and bandwidth consumption. From 250fc7f2e7e996da47bb0ef2da39add5b1e33127 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Tue, 28 Nov 2023 09:22:32 +0100 Subject: [PATCH 03/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 55 ++++++++++++++++++++++++++--- 1 file changed, 51 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 535154e..8a95807 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -245,17 +245,17 @@ CertificateAlternatives. The following use cases are supported: -- Single Attester, which only distributes Evidence without any certificate chains, +1 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. -- A single attester, which shares Evidence together with a certificate chain. +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. -- In a Composite Device, which contains multiple Attesters, a collection of Evidence +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 @@ -264,7 +264,7 @@ 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. -- In the last scenario, we also assume a Composite Device but in this case the +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. @@ -282,6 +282,53 @@ processing the first structure. Note that this specification does not mdandate optimizing certificate chains since there are trade-offs between Attester complexity and bandwidth consumption. +Graphically, the four use cases can be shown as follows: + +~~~ +Use Case 1: + +--------------------+ + | EvidenceBundle | + +--------------------+ + | EvidenceStatement | + +--------------------+ + +Use Case 2: + +-------------------------+ + | EvidenceBundle | + +-------------------------+ + | EvidenceStatement | + | CertificateAlternatives | + +-------------------------+ + +Use Case 3: + +-------------------------+ + | EvidenceBundle (1) |\ + +-------------------------+ \ Provided by + | EvidenceStatement | / Attester 1 + | CertificateAlternatives |/ + +-------------------------+ + | EvidenceBundle (2) |\ + +-------------------------+ \ Provided by + | EvidenceStatement | / Attester 2 + | CertificateAlternatives |/ + +-------------------------+ + +Use Case 4: + +-------------------------+ + | EvidenceBundle (1) |\ + Certificate +-------------------------+ \ Provided by + Chain + | EvidenceStatement | / Attester 1 + End-Entity -->| CertificateAlternatives |/ + Certificate +-------------------------+ + .... + +-------------------------+ + | EvidenceBundle (n) |\ + +-------------------------+ \ Provided by + End-Entity | EvidenceStatement | / Attester n + Certificate-->| CertificateAlternatives |/ + +-------------------------+ +~~~ + # ASN.1 Elements ## Object Identifiers From 1582ea5adc6a0e3804539d48b72caf354b855123 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Tue, 28 Nov 2023 09:23:59 +0100 Subject: [PATCH 04/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 8a95807..a4b8510 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -285,7 +285,7 @@ since there are trade-offs between Attester complexity and bandwidth consumption Graphically, the four use cases can be shown as follows: ~~~ -Use Case 1: +Use Case 1: +--------------------+ | EvidenceBundle | +--------------------+ From a24122be9091ce8d17def5153abfc5bf5f81f6d1 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Tue, 28 Nov 2023 09:25:23 +0100 Subject: [PATCH 05/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index a4b8510..e4bf553 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -233,7 +233,7 @@ CertificateAlternatives. | | | TypedCert OR | | | | TypedFlatCert | | | +-------------------------+ - |n 1| + |n 0| +--------+---------+-+ 1 n +-------------------+ | EvidenceBundle +-----------+ EvidenceStatement | +--------------------+ +-------------------+ From 1ea7513549806e507e4a7b1fccf35c2e51ee3823 Mon Sep 17 00:00:00 2001 From: Michael Richardson Date: Thu, 30 Nov 2023 14:34:34 +0100 Subject: [PATCH 06/10] make diagram pretty! --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index e4bf553..4c91b5a 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -219,7 +219,7 @@ EvidenceBundle structures. Each EvidenceBundle contains one or multiple EvidenceStatement structures as well as one or many CertificateAlternatives. -~~~ +~~~ aasvg +--------------------+ | PKCS#10 or CRMF | | Attribute or | From d8bef791381fd0c95e27a874bcd400d2b5cc3891 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sun, 3 Dec 2023 10:43:51 +0100 Subject: [PATCH 07/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 4c91b5a..a099400 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -279,7 +279,7 @@ 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 mdandate optimizing certificate chains +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: From b74cef6c57f06de9ad83151375ecd753b2748e00 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 18 Dec 2023 15:14:23 +0100 Subject: [PATCH 08/10] Update draft-ietf-lamps-csr-attestation.md Updated description based on Mike's feedback --- draft-ietf-lamps-csr-attestation.md | 115 ++++++++++++++++++---------- 1 file changed, 74 insertions(+), 41 deletions(-) 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 From 8df2120a0929800715f82e64ccf7977d3ceedc20 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 18 Dec 2023 15:16:28 +0100 Subject: [PATCH 09/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 29256a7..70d1732 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -356,8 +356,12 @@ 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. - +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. From a2be166fa1ff219f0715ab57376ed2749b088b61 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 18 Dec 2023 15:21:01 +0100 Subject: [PATCH 10/10] Update draft-ietf-lamps-csr-attestation.md --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 70d1732..86b34ea 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -361,7 +361,7 @@ 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.