Hi cose, I have a design question about a nested COSE construction and would value the group’s view, since it turns on COSE semantics rather than on the application above them.
The construction is sign-then-encrypt: a COSE_Sign1 (EdDSA) over a payload is itself the plaintext of a COSE_Encrypt0 (AES-256-GCM). The same external_aad value, a small deterministic-CBOR array binding a few cleartext envelope fields (a version integer and two 16-byte identifiers), is supplied to BOTH layers: to the Sign1 so the signature commits to those fields, and to the Encrypt0 so the AEAD tag does too. The intent is that rewriting any of those cleartext fields breaks both the signature and the AEAD tag. My question:: is supplying the identical external_aad to both the inner Sign1 and the outer Encrypt0 sound, or does reusing the same AAD bytes across two nested COSE layers with different purposes (authentication vs. AEAD) introduce any cross-layer interaction I should be aware of? I have not found guidance either way in RFC 9052/9053, and I would rather understand it now than later. A secondary question, if I may: the 8-byte author key identifier is the first 8 bytes of SHA-256 over the signer’s Ed25519 public key, and it participates in binding the claimed author to the verifying key (a payload field that must equal the truncated hash of the key that actually verified the signature). Is 64 bits of second-preimage resistance an adequate margin for an identity-binding identifier of this kind, or would you advise a longer one? For context, this arises in an individual draft on a client-side-encrypted memory format (draft-ferro-apertomemory), but the questions above are purely about the COSE usage. https://datatracker.ietf.org/doc/draft-ferro-apertomemory/ Best regards, Andrea Ferro
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
