My summary of the proposal: is it correct?

[dimakuv]

Here is my summary of the current (as of 12. January 2023) proposal:

(I do not care about Endorsement Data Format currently; I'm only interested in the Evidence Data Format)

    /*
     * SGX-quote evidence has the following serialized-CBOR format:
     *
     * CBOR object (major type 6, new CBOR tag for "ECDSA SGX Quotes") ->
     *   CBOR array ->
     *      [
     *        0: CBOR bstr (SGX quote with user_report_data = hash(serialized-cbor-map of claims)),
     *        1: CBOR bstr (serialized-cbor-map of claims)
     *      ]
     *
     * where "serialized-cbor-map of claims" is as follows:
     *
     *   CBOR map ->
     *      {
     *        "pubkey-hash" (req) : CBOR bstr (serialized-cbor-array hash-entry),
     *        "nonce"       (opt) : CBOR bstr (arbitrary-sized nonce for per-session freshness)
     *      }
     *
     * where "serialized-cbor-array hash-entry" is as follows:
     *
     *   CBOR array ->
     *      [
     *        0: CBOR uint (hash-alg-id),
     *        1: CBOR bstr (hash-value -- hash of DER-formatted "SubjectPublicKeyInfo" field as CBOR bstr)
     *      ]
     *
     * For hash-alg-id values, see
     * https://www.iana.org/assignments/named-information/named-information.xhtml
     */

To put it differently, this is the process of creating an Evidence, step by step (basically, go backwards in the above diagram):

1. Prepare hash-value CBOR bstr:
   1. Get DER-formatted "SubjectPublicKeyInfo" field from the X.509 cert
   2. Encode this field as CBOR bstr
   3. Calculate hash (e.g. SHA256) over this CBOR bstr
   4. Encode the calculated hash as CBOR bstr
2. Prepare hash-entry CBOR array:
   1. Create hash-alg-id as CBOR unsigned integer (with value 1 which corresponds to the used hash SHA256)
   2. Put hash-alg-id as the first CBOR-array item
   3. Put hash-value (generated in previous step) as the second CBOR-array item
   4. Encode (serialize) the hash-entry CBOR array as CBOR bstr
3. Prepare map of claims CBOR map:
   1. Put encoded (serialized) hash-entry CBOR bstr as the "pubkey-hash" item in the CBOR map
   2. Put nonce (if any) encoded as CBOR bstr as the "nonce" item in the CBOR map
   3. Encode (serialize) the map of claims CBOR map as CBOR bstr
4. Prepare final CBOR array:
   1. Calculate SHA256 hash over map of claims CBOR bstr
   2. Generate the SGX quote with user_report_data field containing the calculated hash
   3. Encode (serialize) the SGX quote as CBOR bstr
   4. Put the encoded (serialized) SGX-quote CBOR bstr as the first CBOR-array item
   5. Put the encoded (serialized) map of claims CBOR bstr as the second CBOR-array item
5. Prepare the final CBOR object:
   1. Use Major type 6 and new CBOR tag <tag1>
   2. Put the final CBOR array as the tagged data item (so-called tag content)

P.S. I tried to use terminology from the following sources:

• https://github.com/CCC-Attestation/interoperable-ra-tls/blob/main/docs/Interoperable%20Attested%20TLS%5CInteroperable-RA-TLS-SGX-TDX-evidence-formats.md
• https://github.com/CCC-Attestation/interoperable-ra-tls/blob/main/docs/Interoperable-RA-TLS-cert-edvidence-formats.md
• https://www.rfc-editor.org/rfc/rfc8949.html

[dimakuv]

To be honest, I dislike the current "onion" design of the Evidence data format: a serialized CBOR array inside of a serialized CBOR map inside of a CBOR array...

I would prefer to remove one layer of indirection here. For example:

     ...
     * where "serialized-cbor-map of claims" is as follows:
     *
     *   CBOR map ->
     *      {
     *        "pubkey-hash-value" (req) : CBOR bstr (hash of DER-formatted "SubjectPublicKeyInfo" field as CBOR bstr),
     *        "pubkey-hash-alg-id" (opt) : CBOR uint (if skipped, then assume SHA256),
     *        "nonce"       (opt) : CBOR bstr (arbitrary-sized nonce for per-session freshness)
     *      }

But then this doesn't follow the standard CoSWID definition of "hash-entry array"...

[imlk0]

My understanding of the proposal is consistent with the above diagram and process.

[dimakuv]

Thanks @KB5201314 for confirmation!

[shnwc]

@dimakuv @KB5201314 Thank you for your summary! I've created PR #7 to edit the document for better clarity. Let me know if you have feedback to this PR.

[dimakuv]

PR #7 looks good to me. I'll keep this issue open for now, as I think my description may be helpful to others. (If you think otherwise, feel free to close the issue.)

[shnwc]

How about creating a new document (like design notes) to capture the description? Committing PR #7 will close this issue automatically.