On 2022-03-03 18:02, Mike Jones wrote:
We are **definitely** not attempting to change anything about COSE message processing, including how encryption is done. We are defining an additional header parameter that can be used – that’s it.
Dear Mike, what I showed is effectively an /alternative to COSE/. It is a spin-off from an attempt to marry FIDO and CBOR for payment authorizations. Since FIDO signatures are pretty unique, it is not entirely obvious what to do: https://www.w3.org/TR/webauthn-2/images/fido-signature-formats-figure2.svg By leaving "Legacy CBOR" [*] behind, you can create FIDO based authorization signatures like this: { / Key 1-9 hold application data / 1: "1.0", 2: { 1: "Space Shop", 2: "7040566321", 3: "435.00", 4: "EUR" }, 3: "spaceshop.com", 4: "FR7630002111110020050014382", 5: "0057162932", 6: "https://bankdirect.com";, 7: "additional stuff...", 8: { 1: { 3: "Android", 4: "10.0" }, 2: { 3: "Chrome", 4: "103" } }, 9: "2022-02-02T10:14:07+01:00", / Enveloped authorization signature object / 10: { / COSE signatureAlgorithm = ES256 / 1: -7, / COSE publicKey / 2: { / COSE kty = EC / 1: 2, / COSE crv = P-256 / -1: 1, / COSE x / -2: h'e812b1a6dcbc708f9ec43cc2921fa0a14e9d5eadcc6dc63471dd4b680c6236b5', / COSE y / -3: h'9826dcbd4ce6e388f72edd9be413f2425a10f75b5fd83d95fa0cde53159a51d8' }, / FIDO authenticatorData / 3: h'412e175a0f0bdc06dabf0b1db79b97541c08dbacee7e31c97a553588ee922ea70500000017', / FIDO ASN.1 encoded signature / 5: h'304402205c29e1971c0ceb78a977b7fac2aa955ccc8e7d1b6de79e2b9fd1b230313392b70220392d17dacff64bf69a7586cc1aa11e93611a0514ae0c431eef67d47718de763a' } } The signature validation algorithm then becomes quite simple: - Collect key and algorithm data from the authorization signature object. - Save and Remove FIDO "authenticatorData" and FIDO "signature" from the CBOR container. - Set "authorizationData" = re-serialized CBOR container. - Verify signature using ("authenticatorData" || sha256(authorizationData) as signed data. The same model (but without the FIDO specific "authenticatorData" and double hashing) can be applied to most other systems requiring signed CBOR data. As shown in the previous posting, the core concept fits encryption as well. I'm considering submitting some of this to the EU ID-Wallet program: https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/opportunities/topic-details/digital-2022-deploy-02-electronic-id Cheers, Anders *] The rationale for keeping legacy CBOR seems pretty hollow: https://github.com/cyberphone/D-CBOR/blob/main/d-cbor-4-constrained-devices.md
-- Mike *From:*Hannes Tschofenig <[email protected]> *Sent:* Thursday, March 3, 2022 1:45 AM *To:* Anders Rundgren <[email protected]>; Laurence Lundblade <[email protected]>; Mike Jones <[email protected]> *Cc:* Tobias Looker <[email protected]>; [email protected] *Subject:* RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers Hi Anders, Thanks for jumping in. The example you provide below is actually quite interesting and related to a question I posted to the list a few days ago (see https://mailarchive.ietf.org/arch/msg/cose/9nowDz5kbfUvrGR-o6U1Tm31XAA/). I am not sure whether the intention of Tobias & Mike are actually to re-define the way how encryption is accomplished. They should confirm. Ciao Hannes *From:*Anders Rundgren <[email protected]> *Sent:* Thursday, March 3, 2022 8:39 AM *To:* Laurence Lundblade <[email protected]>; Mike Jones <[email protected]> *Cc:* Hannes Tschofenig <[email protected]>; Tobias Looker <[email protected]>; [email protected] *Subject:* Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers On 2022-03-02 19:33, Laurence Lundblade wrote: Makes sense to me. Helps out for the EAT claim named “profile” which gives information about the type of the token you might want before fully verifying it. Addresses an issue Anders brought up about the profile claim. Not so fast :) I brought up a bunch of things which can be illustrated by this (just implemented...) example of an encryption object: 211(["https://example.com/myobject"; <https://example.com/myobject>, { / COSE content encryption algorithm = A256GCM / 1: 3, / Key encryption container / 2: { / COSE Key encryption algorithm = ECDH-ES+A256KW / 1: -31, / Key identifier / 3: "mykey", / Ephemeral key / 5: { / COSE Key type = OKP / 1: 1, / COSE Curve = X25519 / -1: 4, / COSE X coordinate / -2: h'33a04b83d4428824b6d5477522d4a88fac4441122bc46136c0203faa308c3929' }, / Encrypted key / 10: h'e08977c25aeccaecd63b3367de2e2b8f700c82e098ad1e5099d9db510920ccff14debf820427e4ba' }, / Tag / 8: h'59a84826983e3247fbec4295f75cc138', / IV / 9: h'fd8556c122cff2bc128d5119', / Encrypted data / 10: h'e16b16c29da5163eb0131dd1f10f080f8850f55df2ae9d89a3b839ad50952858445f290dfb60' }]) The core of this builds on /Deterministic CBOR/ which unleashes the /true power/ of CBOR in a way legacy solutions do not. The enhancements include: * Eliminating wrapping of header and (unencrypted) application data. * Using the entire container (modulo the algorithm output variables which are added lastly) as input to a signature process and to the authentication part of an encryption process. In the example that includes the top-level CBOR tag as well. cryptoOperation(cborObject.encode()) is all that it takes on the encoder's side. This is pretty much what the X.509 folks have been doing from the very start so there is close to zero innovation here 😁 In the example I have also used a URL as profile/object type indicator since IANA CBOR custom tag 1537244 or whatever you end-up with, simply isn't pretty enough :) To be more serious: URLs are /decentralized/ and would in this context probably be /browseable/ as well. Cheers, Anders IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
