From dd70795474822b9c68e2de2c1f3fd29e3b9a9b8a Mon Sep 17 00:00:00 2001 From: Hendrik Brockhaus <35796373+HBrock@users.noreply.github.com> Date: Thu, 17 Oct 2024 09:34:52 +0200 Subject: [PATCH 1/7] Changes to Abstract, Sections 1, 2, and 4 --- draft-ietf-lamps-csr-attestation.md | 58 ++++++++++++++--------------- 1 file changed, 27 insertions(+), 31 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 784a259..2b12c4a 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -138,7 +138,7 @@ The certificates typically contain one or more certification paths rooted in a device manufacturer trust anchor and the end-entity certificate being on the device in question. The end-entity certificate is associated with key material that takes on the role of an Attestation Key and is used as Evidence originating from the Attester. -This document specifies a CSR Attribute (or Extension for Certificate Request Message Format (CRMF) CSRs) for carrying Evidence. Evidence can be placed into an EvidenceStatement along with an OID to identify its type and optionally a hint to the Relying Party about which Verifier (software package) will be capable of parsing it. A set of EvidenceStatements may be grouped together along with the set of CertificateChoices needed to validate them to form a EvidenceBundle. One or more EvidenceBundles may be placed into the id-aa-evidence CSR Attribute (or CRMF Extension). +This document specifies a CSR Attribute (or Extension for Certificate Request Message Format (CRMF) CSRs) for carrying Evidence. Evidence can be placed into an EvidenceStatement along with an OID to identify its type and optionally a hint to the Relying Party about which Verifier (software package) will be capable of parsing it. A set of EvidenceStatement structures may be grouped together along with the set of CertificateChoice structures needed to validate them to form a EvidenceBundle. The id-aa-evidence CSR Attribute (or CRMF Extension) contains one EvidenceBundle. A CSR may contain one or more Evidence payloads, for example Evidence asserting the storage properties of a private key, Evidence @@ -147,7 +147,7 @@ of the device, or Evidence signed using different cryptographic algorithms. With these attributes, additional -information information is available to an RA or CA, which may be used +information is available to an RA or CA, which may be used to decide whether to issue a certificate and what certificate profile to apply. The scope of this document is, however, limited to the conveyance of Evidence within CSR. The exact format of the @@ -167,7 +167,7 @@ Lead Attester, Attestation Key, and Relying Party (RP). The term "Certification Request" message is defined in {{RFC2986}}. Specifications, such as {{RFC7030}}, later introduced the term "Certificate Signing Request (CSR)" to refer to the Certification -Request message. While the term "Certification Signing Request" +Request message. While the term "Certification Request" would have been correct, the mistake was unnoticed. In the meanwhile CSR is an abbreviation used beyond PKCS#10. Hence, it is equally applicable to other protocols that use a different syntax and @@ -297,12 +297,16 @@ Evidence and certificate chains in a CSR the structure shown in {{fig-info-model}} is used. On a high-level, the structure is composed as follows: -A PKCS#10 attribute or a CRMF extension contains one or more -EvidenceBundle structures. Each EvidenceBundle contains one or more +A PKCS#10 attribute or a CRMF extension contains one +EvidenceBundle structure. The EvidenceBundle contains one or more EvidenceStatement structures as well as one or more CertificateChoices which enable to carry various format of certificates. +Note: As an extension must only be included once in a certificate, +see {{Section 4.2 of RFC5280}}, it is RECOMMENDED to include the +PKCS#10 attribute or the CRMF extension only once in a CSR. + ~~~ aasvg +-------------------+ | PKCS#10 Attribute | @@ -328,19 +332,17 @@ certificates. {: #fig-info-model title="Information Model for CSR Evidence Conveyance."} A conformant implementation of an entity processing the CSR structures MUST be prepared -to use certificates found in the parent EvidenceBundle structure to build a certification -path to validate any EvidenceStatement found in an EvidenceBundle. That is, certificates -needed for validating EvidenceStatements are found in the same EvidenceBundle. - +to use certificates found in the EvidenceBundle structure to build a certification +path to validate any EvidenceStatement. The following use cases are supported, as described in the sub-sections below. -### Case 1 - Single Evidence Bundle +### Case 1 - Evidence Bundle without Certificate Chain A single Attester, which only distributes Evidence without an attached certificate chain. In the use case, the Verifier is assumed to be in possession of the certificate chain already or the Verifier directly trusts the Attestation Key and therefore no certificate chain needs to be conveyed in the CSR. -As a result, a single EvidenceBundle is included in a CSR that contains a single EvidenceStatement +As a result, an EvidenceBundle is included in a CSR that contains a single EvidenceStatement without the CertificateChoices structure. {{fig-single-attester}} shows this use case. ~~~ aasvg @@ -350,13 +352,13 @@ without the CertificateChoices structure. {{fig-single-attester}} shows this use | EvidenceStatement | +--------------------+ ~~~ -{: #fig-single-attester title="Case 1: Single Evidence Bundle."} +{: #fig-single-attester title="Case 1: Evidence Bundle without Certificate Chain."} -### Case 2 - Single Evidence Bundle with Certificate Chain +### Case 2 - Evidence Bundle with 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 CertificateChoices structure. {{fig-single-attester-with-path}} +The CSR conveys an EvidenceBundle with a single EvidenceStatement +and a CertificateChoices structure. {{fig-single-attester-with-path}} shows this use case. ~~~ aasvg @@ -369,32 +371,26 @@ shows this use case. ~~~ {: #fig-single-attester-with-path title="Case 2: Single Evidence Bundle with Certificate Chain."} -### Case 3 - Multiple Evidence Bundles each with Complete Certificate Chains +### Case 3 - Evidence Bundles with Multiple Evidence Statements and Complete Certificate Chains In a Composite Device, which contains multiple Attesters, a collection of Evidence statements is obtained. In this use case, each Attester returns its Evidence together with a -certificate chain. As a result, multiple EvidenceBundle structures, each carrying -an EvidenceStatement and the corresponding CertificateChoices structure with the -certification chain as provided by each Attester, are included in the CSR. -This may result in certificates being duplicated across multiple EvidenceBundles. +certificate chain. As a result, multiple EvidenceStatement structures and the corresponding CertificateChoices structure with the +certification chains as provided by the Attester, are included in the CSR. 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. ~~~ aasvg +-------------------------+ - | EvidenceBundle (1) |\ - +.........................+ \ Provided by - | EvidenceStatement | / Attester 1 - | CertificateChoices |/ + | EvidenceBundle | + +.........................+ + | EvidenceStatement (1) | Provided by Attester 1 + | EvidenceStatement (2) | Provided by Attester 2 + | CertificateChoices | Certificates provicded by Attester 1 and 2 +-------------------------+ - | EvidenceBundle (2) |\ - +.........................+ \ Provided by - | EvidenceStatement | / Attester 2 - | CertificateChoices |/ - +-------------------------+ -~~~ -{: #fig-multiple-attesters title="Case 3: Multiple Evidence Bundles each with Complete Certificate Chains."} + ~~~ +{: #fig-multiple-attesters title="Case 3: Multiple Evidence Structures each with Complete Certificate Chains."} # ASN.1 Elements From 98ca7eae480fe8bfbdf5e21726c9970500d30690 Mon Sep 17 00:00:00 2001 From: Hendrik Brockhaus <35796373+HBrock@users.noreply.github.com> Date: Thu, 17 Oct 2024 10:38:43 +0200 Subject: [PATCH 2/7] Updated Sections 5 and 6 --- draft-ietf-lamps-csr-attestation.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 2b12c4a..fb82eb6 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -410,12 +410,12 @@ id-ata OBJECT IDENTIFIER ::= { id-pkix (TBD1) } By definition, attributes within a PKCS#10 CSR are typed as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION. -This attribute definition contains one or more -Evidence bundles of type `EvidenceBundle` where each contain +This attribute definition contains one +Evidence bundle of type `EvidenceBundle` containing one or more Evidence statements of a type `EvidenceStatement` along with -an optional certification path. -This structure allows for grouping Evidence statements that share a -certification path. +optional certificates for certification path building. +This structure allows for different Evidence statements that share a +certification path not dublicationg them in the attribute. ~~~ EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER @@ -427,7 +427,7 @@ EvidenceStatementSet EVIDENCE-STATEMENT ::= { {: #code-EvidenceStatementSet title="Definition of EvidenceStatementSet"} The expression illustrated in {{code-EvidenceStatementSet}} maps ASN.1 Types for Evidence Statements to the OIDs -that identify them. These mappings are are used to construct +that identify them. These mappings are used to construct or parse EvidenceStatements. Evidence Statements are typically defined in other IETF standards, other standards bodies, or vendor proprietary formats along with corresponding OIDs that identify them. @@ -519,16 +519,14 @@ The Extension variant illustrated in {{code-extensions}} is intended only for us The `certs` field contains a set of certificates that is intended to validate the contents of an Evidence statement -contained in `evidence`, if required. The set of certificates should contain +contained in `evidences`, if required. For each Evidnece statement the set of certificates should contain the certificate that contains the public key needed to directly validate the -`evidence`. Additional certificates may be provided, for example, to chain the -Evidence signer key back to an agreed upon trust anchor. No order is implied, it is -up to the Attester and its Verifier to agree on both the order and format -of certificates contained in `certs`. +Evidence statement. Additional certificates may be provided, for example, to chain the +Evidence signer key back to an agreed upon trust anchor. No specific order of the certificates in `certs` SHOULD be expected because the certificates needed for different Evidence statements may be contained in `certs`. This specification places no restriction on mixing certificate types within the `certs` field. For example a non-X.509 Evidence signer certificate MAY chain to a trust anchor via a chain of X.509 certificates. It is up to the Attester and its Verifier to agree on supported certificate formats. -By the nature of the PKIX ASN.1 classes {{RFC5912}}, there are multiple ways to convey multiple Evidence statements: by including multiple copies of `attr-evidence` or `ext-evidence`, multiple values within the attribute or extension, and finally, by including multiple `EvidenceStatement`s within an `EvidenceBundle`. The latter is the preferred way to carry multiple Evidence statements. Implementations MUST NOT place multiple copies of `attr-evidence` into a PKCS#10 CSR due to the `COUNTS MAX 1` declaration, and SHOULD NOT place multiple copies of `EvidenceBundle` into an `AttributeSet`. In a CRMF CSR, implementers SHOULD NOT place multiple copies of `ext-evidence` and SHOULD NOT place multiple copies of `EvidenceBundle` into an `ExtensionSet`. +By the nature of the PKIX ASN.1 classes {{RFC5912}}, there are multiple ways to convey multiple Evidence statements: by including multiple copies of `attr-evidence` or `ext-evidence`, multiple values within the attribute or extension, and finally, by including multiple `EvidenceStatement` structures within an `EvidenceBundle`. The latter is the preferred way to carry multiple Evidence statements. Implementations MUST NOT place multiple copies of `attr-evidence` into a PKCS#10 CSR due to the `COUNTS MAX 1` declaration. In a CRMF CSR, implementers SHOULD NOT place multiple copies of `ext-evidence`. # IANA Considerations From 80dd48b0a66068322db4355288c1444168002a49 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sat, 19 Oct 2024 15:59:07 +0200 Subject: [PATCH 3/7] 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 fb82eb6..ce59dcb 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -414,7 +414,7 @@ This attribute definition contains one Evidence bundle of type `EvidenceBundle` containing one or more Evidence statements of a type `EvidenceStatement` along with optional certificates for certification path building. -This structure allows for different Evidence statements that share a +This structure enables different Evidence statements to share a certification path not dublicationg them in the attribute. ~~~ From d26d74d2d0dd4c83fa01b4d4d39dcef800aa6a41 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sat, 19 Oct 2024 15:59:21 +0200 Subject: [PATCH 4/7] 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 ce59dcb..dd8f235 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -415,7 +415,7 @@ Evidence bundle of type `EvidenceBundle` containing one or more Evidence statements of a type `EvidenceStatement` along with optional certificates for certification path building. This structure enables different Evidence statements to share a -certification path not dublicationg them in the attribute. +certification path without duplicating it in the attribute. ~~~ EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER From 7c25b7f965e8e739f9aae01dde4e440980d42b02 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sat, 19 Oct 2024 16:02:37 +0200 Subject: [PATCH 5/7] 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 dd8f235..87c2993 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -305,7 +305,7 @@ certificates. Note: As an extension must only be included once in a certificate, see {{Section 4.2 of RFC5280}}, it is RECOMMENDED to include the -PKCS#10 attribute or the CRMF extension only once in a CSR. + or the CRMF extension only once in a CSR. ~~~ aasvg +-------------------+ From efca6eba28caf10761cf4f227ba3b12bdd73fc2d Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sat, 19 Oct 2024 16:02:43 +0200 Subject: [PATCH 6/7] 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 87c2993..1260b56 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -304,7 +304,7 @@ CertificateChoices which enable to carry various format of certificates. Note: As an extension must only be included once in a certificate, -see {{Section 4.2 of RFC5280}}, it is RECOMMENDED to include the +see {{Section 4.2 of RFC5280}}, it is RECOMMENDED to include the PKCS#10 attribute or the CRMF extension only once in a CSR. ~~~ aasvg From 2fa3f4abd1a6dfd9b9e8c67010aa286c36967dcf Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Sat, 19 Oct 2024 16:02:49 +0200 Subject: [PATCH 7/7] 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 1260b56..94b036c 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -303,7 +303,7 @@ EvidenceStatement structures as well as one or more CertificateChoices which enable to carry various format of certificates. -Note: As an extension must only be included once in a certificate, +Note: Since an extension must only be included once in a certificate see {{Section 4.2 of RFC5280}}, it is RECOMMENDED to include the PKCS#10 attribute or the CRMF extension only once in a CSR.