Amaury, Thanks for that info. It seems like an analogous situation to the diagram in Section 1 of RFC 6032 could be made layering:
1. COSE_Encrypt0 to the intended key recipient with content type of cose_sign1 (18) and payload plaintext of: 2. COSE_Sign1 from the source, containing CCS header parameter describing the key material, with content type of cose-key-set (102) and payload of: 3. COSE_KeySet with the actual key materials This ensures confidentiality of the key data and metadata (originator and claims), and ensures origination verification for the key payload. It seems like there are a few existing media types with suffix "+cose" and enveloping this way will not cause any headaches. This can leave authorization and transport security to the transport mechanism. The good thing is that this seems to not require any new mechanism, just composing existing ones with requirements on contents. Maybe a simplified variation for pure confidential transport with just layer 3 and 1 and omitting claims. Brian S. From: Amaury Chamayou <[email protected]> Sent: Friday, November 14, 2025 4:36 AM To: Sipos, Brian J. <[email protected]>; cose <[email protected]> Subject: [EXT] Re: COSE equivalent to CMS Key Packages APL external email warning: Verify sender [email protected] <mailto:[email protected]> before clicking links or attachments There is a way to embed CWT Claims in a header (preferably protected): https://datatracker.ietf.org/doc/rfc9597/, which you could use in the layer-0, and where you could set nbf and exp, but that would not be confidential of course. I am also interested in an interoperable way to encode COSE_Key validity information, in the context of SCITT Statement Sequences. Amaury _____ From: Sipos, Brian J. <[email protected] <mailto:[email protected]> > Sent: 14 November 2025 02:59 To: cose <[email protected] <mailto:[email protected]> > Subject: [EXTERNAL] [COSE] COSE equivalent to CMS Key Packages All, I would like to be able to securely and confidentially transport key material in a way similar to the CMS Encrypted Key Package [1] for symmetric and asymmetric key material and attributes, but without needing the ASN.1 infrastructure. There are many possible ways to do this, and I'm interested in getting feedback for what may already exist or have already been experimented with. The first thing that came to mind is simply enveloping a COSE_Key within a COSE_Encrypt and using the layer-0 header "content type" (3) with value "application/cose-key" (101). This would serve the minimal purpose but would rely on the COSE_Key to have all needed attributes, and right now there are no key common parameters to reflect things like starting and ending validity time. The next I looked at was using an encrypted CWT, which can contain a COSE_Key as a cnf (8) claim along with other attributes like validity time, which is structurally similar to what I'm interested in but the semantics are backwards. Rather than conveying private key material, the cnf claim is meant to prove pre-existing possession of private key material. So it seems like maybe the thing I'm looking for does not yet exist in an interoperable way. Any suggestions for what may already exist for this kind of thing? Brian S. [1] <https://www.rfc-editor.org/rfc/rfc6032.html> https://www.rfc-editor.org/rfc/rfc6032.html
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
