Add COSE/JOSE Algorithms Support - Address issue #64

Signed-off-by: Fabrizio Damato <[email protected]>

Author: fdamato

specifications/ietf-eat-profile/bibliography.yaml

@@ -55,3 +55,17 @@ references:
       year: 2020
       month: 12
     url: "https://datatracker.ietf.org/doc/html/rfc8949"
+  - id: "ietf-cose-dilithium"
+    title: "ML-DSA for JOSE and COSE"
+    publisher: "IETF"
+    issued:
+      year: 2025
+      month: 9
+    url: "https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/"
+  - id: "nist-fips-204"
+    title: "Module-Lattice-Based Digital Signature Standard"
+    publisher: "NIST"
+    issued:
+      year: 2024
+      month: 8
+    url: "https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf"

specifications/ietf-eat-profile/spec.ocp

@@ -185,7 +185,7 @@ and provide the minimum necessary information for verifier appraisal policies:
     * This claim is used by the attester to identify the profile. It **MUST** be present and **SHALL** contain the OID assigned to the OCP Profile. **TODO: OCP to assign OID Value**
 
 6. **Measurements** (claim key: 273, encoded as 0x190111)
-    * This claim is used by the attester to present the target environment claims that verifier will consume for the appraisal policy. It **MUST** be present and **SHALL** encapsulate a "concise-evidence" as a serialized CBOR byte string using the appropriate IANA media type. The serialized concise-evidence **SHALL NOT** exceed 128kB in size.
+    * This claim is used by the attester to present the target environment claims that verifier will consume for the appraisal policy. It **MUST** be present and **SHALL** encapsulate a "concise-evidence" as a serialized CBOR byte string using the appropriate IANA media type.
 
 **Optional Claims (7-14)**: These claims are **OPTIONAL** and provide additional
 platform information that may be useful for audit purposes but are not strictly
@@ -267,7 +267,102 @@ Additionally, an Attester has the option to include a complete certificate path
 within the x5-chain, extending from a recognized Trusted Anchor (such as a
 Vendor Root CA) or up to the Initial Device Identity (IDEVID).
 
-The signed-cwt CDDL is defined in the following manner:
+## COSE Algorithm Requirements
+
+This profile defines specific cryptographic algorithms that **MUST** be
+supported for CWT signing to ensure interoperability and appropriate security
+levels for data center environments.
+
+### Supported Algorithms
+
+Implementations of this profile **SHALL** support **one** of the
+following COSE algorithms for the COSE_Sign1 signature:
+
+1. **ECDSA with P-384 and SHA-384** (COSE Algorithm ID: -35)
+    * **Algorithm**: ES384 as defined in [@{ietf-rfc9052}]
+    * **Curve**: NIST P-384
+    * **Hash**: SHA-384
+    * **Key Size**: 384 bits
+    * **Security Level**: 192-bit classical security
+    * **Signature Size**: ~96 bytes
+    * **Public Key Size**: 97 bytes (uncompressed point)
+    * **Private Key Size**: 48 bytes
+    * **Profile OID**: **TODO: OCP to assign OID for ECDSA-P384 profile**
+
+2. **ML-DSA-87** (COSE Algorithm ID: -50)
+    * **Algorithm**: ML-DSA-87 (FIPS 204) as defined in
+      [@{ietf-cose-dilithium}]
+    * **Security Level**: Category 5 (256-bit classical, 128-bit quantum) as defined in [@{nist-fips-204}]
+    * **Signature Size**: ~4,627 bytes
+    * **Public Key Size**: 2,592 bytes
+    * **Private Key Size**: 4,896 bytes
+    * **Hash**: SHAKE256
+    * **Profile OID**: **TODO: OCP to assign OID for ML-DSA-87 profile**
+
+### Profile OID Usage
+
+The **EAT Profile** claim (claim key: 265) **MUST** contain the OID
+corresponding to the algorithm used for signing the CWT:
+
+* When signed with ECDSA-P384, use the ECDSA-P384 profile OID
+* When signed with ML-DSA-87, use the ML-DSA-87 profile OID
+
+This allows verifiers to immediately identify both the profile version and
+the expected signature algorithm without parsing the COSE headers.
+
+### Algorithm Selection Guidelines
+
+The choice of algorithm **SHALL** be determined by:
+
+1. Attester capabilities
+2. Deployment security requirements (classical vs. post-quantum)
+3. Size constraints and bandwidth considerations
+4. Certificate chain algorithm consistency
+
+**Certificate Chain Consistency**: The algorithm used for CWT signing
+**SHOULD** be consistent with the algorithm used in the Attestation Key
+certificate chain, though this is not strictly required.
+
+### Size Implications
+
+Implementations **MUST** account for the following signature size
+implications when calculating total CWT size against the 64kB limit:
+
+* **ECDSA-P384**: ~96 bytes signature size
+* **ML-DSA-87**: ~4,627 bytes signature size
+
+**Note**: When using ML-DSA-87, implementors should carefully consider the
+available space for claims and certificate chains within the 64kB total
+size limit. The large signature size may necessitate more compact
+certificate chains or reduced optional claims.
+
+### COSE Header Requirements
+
+The COSE_Sign1 protected header **MUST** include:
+
+* **alg** (label 1): The COSE algorithm identifier (-35 for ES384 or -50
+  for ML-DSA-87)
+* Additional algorithm-specific parameters as required by the chosen
+  algorithm
+
+The COSE_Sign1 unprotected header **MUST** include:
+
+* **x5chain** (label 33): Certificate chain as specified in the main
+  specification
+
+### Implementation Notes
+
+**Migration Path**: The dual algorithm support provides a clear migration
+path from classical to post-quantum cryptography while maintaining current
+security levels during the transition period.
+
+### Future Algorithm Support
+
+This profile may be updated to include additional COSE algorithms as they
+become standardized and relevant for data center attestation use cases.
+When new algorithms are added, a new profile OID will be assigned to
+support each additional algorithm, maintaining clear identification and
+backward compatibility with existing implementations.
 
 ## Concise Evidence