You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following OIDs are defined for key derivation attributes:
@@ -332,6 +327,42 @@ These OIDs indicate which inputs contribute to the derivation of the identity ke
332
327
333
328
Subsequent versions of this specification may be expanded with additional key derivation attribute OIDs.
334
329
330
+
#### Envelope-Signed CSR EAT Profile
331
+
332
+
This specification defines a partial EAT profile for use in the GET_ENVELOPE_SIGNED_CSR response. This is not a complete EAT profile as defined in RFC 9711 because:
333
+
334
+
1. It does not prescribe specific cryptographic algorithms
335
+
2. It is only used as a response to the GET_ENVELOPE_SIGNED_CSR command
336
+
3. It does not define all aspects required for a full profile
337
+
338
+
Therefore, no EAT Profile OID is assigned for this usage.
339
+
340
+
**Required EAT Claims:**
341
+
342
+
The EAT contained in EnvelopeSignedCSRdata SHALL include the following claims:
343
+
344
+
1. **Nonce claim (nonce: 10)** - A binary string between 8 and 64 bytes that MUST match the Nonce value provided in the GET_ENVELOPE_SIGNED_CSR request. This provides freshness and prevents replay attacks.
345
+
346
+
2. **CSR claim (csr: -70001)** - A binary string containing the DER-encoded Certificate Signing Request. This may be either:
347
+
- A self-signed CSR where the signature is generated by the subject key
348
+
- A non-self-signed CSR where the signature field contains all zeroes
349
+
350
+
3. **Key derivation attributes claim (attrib: -70002)** - An array of OIDs indicating which inputs contributed to the derivation of the identity key for which the CSR is being requested. Each OID is encoded according to CBOR OID encoding rules.
351
+
352
+
**Signature Requirements:**
353
+
354
+
The EAT SHALL be encoded as a signed CWT using COSE_Sign1. The signature provides authenticity and integrity for the CSR and its associated metadata.
355
+
356
+
**Key Identification:**
357
+
358
+
The COSE_Sign1 protected header SHALL include:
359
+
- **Algorithm identifier (alg: 1)** - Integer identifying the signature algorithm used
360
+
- **Content type (content-type: 3)** - Text string or integer indicating the content type (for EAT, this is typically "application/eat+cwt")
361
+
- **Key ID (issuer-key-id: 4)** - Binary string that MUST match the subject name of the certificate containing the public key that can verify the EAT signature
362
+
363
+
For example, if the EAT is signed by the RT_Alias key, the kid should match the subject field of the RT_Alias certificate.
364
+
365
+
335
366
## Issuing and provisioning an identity certificate {#sec:issuing-and-provisioning-identity-cert}
336
367
337
368
After establishing trust in a device's identity keypair through the envelope-signed CSR mechanism, a PKI owner can issue and provision an identity certificate to the device. This specification defines OCP-specific commands for certificate provisioning.
@@ -358,9 +389,6 @@ This approach ensures that only identity certificates can be provisioned, as tho
358
389
- Optionally, any intermediate CA certificates
359
390
- Optionally, the root CA certificate
360
391
361
-
362
-
**Important**: While devices may expose CSRs for various keys in their hierarchy, endorsement chains provisioned via `OCP_SET_ENDORSEMENT` SHALL NOT include LEAF certificates. This ensures that endorsements work across different use cases (e.g., attestation, secure sessions) since each use case may have different LEAF certificates while sharing the same endorsement chain.
363
-
364
392
**Certificate chain composition**: When provisioning via `OCP_SET_ENDORSEMENT`, the certificate chain SHALL include:
365
393
- The PKI-issued identity certificate for the device key (e.g., the LDevID certificate issued by the owner's PKI)
0 commit comments