Merge branch 'main' into mikeo_iss61

lamps-wg · Jan 15, 2024 · 2794507 · 2794507
2 parents 6161777 + ca693e9
commit 2794507
Show file tree

Hide file tree

Showing 2 changed files with 73 additions and 3 deletions.
diff --git a/CSR-ATTESTATION-2023.asn b/CSR-ATTESTATION-2023.asn
@@ -23,6 +23,11 @@ id-aa
 FROM SecureMimeMessageV3dot1
     { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
+
+GeneralName
+  FROM PKIX1Implicit-2009
+      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
+      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
   ;
 
 
@@ -66,7 +71,8 @@ EvidenceStatements ::= SEQUENCE OF EvidenceStatement
 
 EvidenceStatement ::= SEQUENCE {
    type   EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
-   stmt   EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type})
+   stmt   EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}),
+   hint   GeneralName OPTIONAL
 }
 
 id-aa-evidenceStatement OBJECT IDENTIFIER ::= { id-aa TBDAA }

diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md
@@ -78,6 +78,13 @@ informative:
     title: DICE Attestation Architecture, v.1.1
     date: May4, 2023
     target: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Attestation-Architecture-Version-1.1-Revision-17_1August2023.pdf
+  PKCS11:
+    author:
+      org: OASIS
+    title: "PKCS #11 Cryptographic Token Interface Base Specification Version 2.40"
+    date: 14 April 2015
+    target: http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html
+
 
 --- abstract
 
@@ -209,6 +216,45 @@ CSR messages.
 
 # Information Model
 
+## Interaction with an HSM
+
+This specification is intended to be used both in cases where the CSR
+is constructed internally or externally to the attesting environment.
+
+Cases where the CSR is generated internally to the attesting environment
+are straightforward: the generates and embeds Evidence and the corresponding
+certificate chains when constructing the CSR.
+
+Externally-generated CSRs may require extra round-trips of communication
+between the CSR generator and the attesting environment, first to obtain
+the necessary evidence statements about the subject key, and then to use
+the subject key to sign the CSR. For example, consider a CSR generated by
+OpenSSL about a subject key stored on a PKCS#11 {{PKCS11}} device. The interaction would
+conceptually be:
+
+~~~ aasvg
+                   +---------+          +-----+
+                   | OpenSSL |          | HSM |
+                   +---------+          +-----+
+                        |                  |
+                        | getEvidence()    |
+                        |----------------->|
+                        |                  |
+                        |<-----------------|
++---------------------+ |                  |
+| CSR = assembleCSR() |-|                  |
++---------------------+ |                  |
+                        |                  |
+                        | sign(CSR)        |
+                        |----------------->|
+                        |                  |
+                        |<-----------------|
+                        |                  |
+~~~
+{: #fig-openssl-p11 title="Example interaction between CSR generator and HSM."}
+
+## Implementation Strategies
+
 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.
@@ -421,9 +467,27 @@ EvidenceStatements ::= SEQUENCE OF EvidenceStatement
 
 EvidenceStatement ::= SEQUENCE {
    type   EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
-   stmt   EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type})
+   stmt   EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}),
+   hint   GeneralName OPTIONAL
 }
+~~~
+
+The type is on OID indicating the format of the data contained in stmt.
+
+The hint is intended for an Attester to indicate to the Relying Party
+which Verifier should be invoked to parse this statement. In many cases,
+the type OID will already uniquely indicate which Verifier to invoke, but
+in some cases it may still be ambiguous, or the type may indicate
+another layer of conceptual message wrapping in which case it is helpful
+to the RP to bring this hint outside of the statement.
+It is assumed that the RP must be pre-configured with a list of trusted
+Verifiers and that the contents of this hint can be used to look up
+the correct Verifier. Under no circumstances must the RP be tricked into
+contacting an unknown and untrusted Verifier since the returned Attestation
+Result must not be relied on. The format and contents of the hint are out of
+scope of this document.
 
+~~~
 EvidenceBundles ::= SEQUENCE OF EvidenceBundle
 
 EvidenceBundle ::= SEQUENCE
@@ -447,7 +511,7 @@ ext-evidence EXTENSION ::= {
 }
 ~~~
 
-The Extension version is intended only for use within CRMF CSRs and MUST NOT be used within X.509 certificates due to the privacy implications of publishing Evidence about the end entity's hardware environment. See {{security-considerations}} for more discussion.
+The Extension variant is intended only for use within CRMF CSRs and MUST NOT be used within X.509 certificates due to the privacy implications of publishing Evidence about the end entity's hardware environment. See {{security-considerations}} for more discussion.
 
 The `certs` contains a set of certificates that
 may be needed to validate the contents of an Evidence statement