Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-0030: Clarity in the value of kid in signData? #680

Open
itsfarseen opened this issue Dec 21, 2023 · 1 comment
Open

CIP-0030: Clarity in the value of kid in signData? #680

itsfarseen opened this issue Dec 21, 2023 · 1 comment

Comments

@itsfarseen
Copy link

itsfarseen commented Dec 21, 2023

CIPs/CIP-0030/README.md

Lines 335 to 353 in 5d32dc4

#### `api.signData(addr: Address, payload: Bytes): Promise<DataSignature>`
Errors: `APIError`, `DataSignError`
This endpoint utilizes the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md) for standardization/safety reasons. It allows the dApp to request the user to sign a payload conforming to said spec. The user's consent should be requested and the message to sign shown to the user. The payment key from `addr` will be used for base, enterprise and pointer addresses to determine the EdDSA25519 key used. The staking key will be used for reward addresses. This key will be used to sign the `COSE_Sign1`'s `Sig_structure` with the following headers set:
* `alg` (1) - must be set to `EdDSA` (-8)
* `kid` (4) - Optional, if present must be set to the same value as in the `COSE_key` specified below. It is recommended to be set to the same value as in the `"address"` header.
* `"address"` - must be set to the raw binary bytes of the address as per the binary spec, without the CBOR binary wrapper tag
The payload is not hashed and no `external_aad` is used.
If the payment key for `addr` is not a P2Pk address then `DataSignError` will be returned with code `AddressNotPK`. `ProofGeneration` shall be returned if the wallet cannot generate a signature (i.e. the wallet does not own the requested payment private key), and `UserDeclined` will be returned if the user refuses the request. The return shall be a `DataSignature` with `signature` set to the hex-encoded CBOR bytes of the `COSE_Sign1` object specified above and `key` shall be the hex-encoded CBOR bytes of a `COSE_Key` structure with the following headers set:
* `kty` (1) - must be set to `OKP` (1)
* `kid` (2) - Optional, if present must be set to the same value as in the `COSE_Sign1` specified above.
* `alg` (3) - must be set to `EdDSA` (-8)
* `crv` (-1) - must be set to `Ed25519` (6)
* `x` (-2) - must be set to the public key bytes of the key used to sign the `Sig_structure`

  • kid (4) - Optional, if present must be set to the same value as in the COSE_key specified below. It is recommended to be set to the same value as in the "address" header.

Are we supposed to set it to the same value as the address field?


Nami used to set it to the publicKey corresponding to the address.
They have now removed it citing compatibility with CIP-0030.

https://github.com/input-output-hk/nami/blob/6ba65366406a21e47a5eec8eac997e2240ee9e16/src/api/extension/index.js#L881-L885

  // protectedHeaders.set_key_id(publicKey.as_bytes()); // Removed to adhere to CIP-30
  protectedHeaders.set_header(
    Loader.Message.Label.new_text('address'),
    Loader.Message.CBORValue.new_bytes(Buffer.from(address, 'hex'))
  );

The original PR (#148) used to say:

* `kid` (4) - must be set to the Ed25519 public key bytes used to sign the `Sig_structure`

It was later updated in the same PR to say:

* `kid` (4) - Optional, if present must be set to the same value as in the `COSE_key` specified below. It is recommended to be set to the same value as in the `"address"` header.

We should clarify what is the correct approach.
If it's anything counter-intuitive like duplicating the same value as in the address field, we should also provide the rationale.

@gitmachtl
Copy link
Contributor

this is general COSE standard, the key-id - if used - should match yes. so i would go with the later one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants