ipip-378: switch signature to dag-cbor

Rationale: #378 (comment)

src/routing/http-routing-v1.md

@@ -136,7 +136,7 @@ server SHOULD be no more than 100 `Providers` per `application/json` response.
  }
  ```
 
-- `ProvideResults` is a list of results in the same order as the `Providers` in the request, and the schema of each object is determined by the `Protocol` of the corresponding write object
+- `ProvideResults` is a list of results in the same order as the `Providers` in the request, and the schema of each object is determined by the `Schema` of the corresponding write object
  - Returned list MAY contain entry-specific information such as server-specific TTL, per-entry error message, etc. Fields which are not relevant, can be omitted.
  - In error scenarios, a client can check for presence of non-empty `Error` field (top level, or per `ProvideResults` entry) to learn about the reason why POST failed.
 - The work for processing each provider record should be idempotent so that it can be retried without excessive cost in the case of full or partial failure of the request
@@ -209,13 +209,13 @@ Server SHOULD accept writes represented with [Announcement Schema](#announcement
 
  ```json
  {
- "ProvideResults": [
+ "PeersResults": [
  { ... }
  ]
  }
  ```
 
-- `ProvideResults` is a list of results in the same order as the `Providers` in the request, and the schema of each object is determined by the `Protocol` of the corresponding write object
+- `PeersResults` is a list of results in the same order as the `Peers` in the request, and the schema of each object is determined by the `Schema` of the corresponding write object
  - Returned list MAY contain entry-specific information such as server-specific TTL, per-entry error message, etc. Fields which are not relevant, can be omitted.
  - In error scenarios, a client can check for presence of non-empty `Error` field (top level, or per `ProvideResults` entry) to learn about the reason why POST failed.
 - The work for processing each provider record should be idempotent so that it can be retried without excessive cost in the case of full or partial failure of the request
@@ -392,36 +392,57 @@ The `announcement` schema can be used in `POST` operations to announce content p
  }
 ```
 
-- `Schema`: tells the server to interpret the JSON object as announce provider
+#### Announcement Payload
+
 - `Payload`: is a map object with a subset of the below fields.
  - `CID` is a string with multibase-encoded CID being provided (`/routing/v1/providers` only).
  - This field is not present when used for `POST /routing/v1/peers`
  - `Scope` (optional) is a string hint that provides semantic meaning about CID (`/routing/v1/providers` only):
  - `block` announces only the individual block (this is the implicit default if `Scope` field is not present).
  - `entity` announces CIDs required for enumerating entity behind the CID (e.g.: all blocks for UnixFS file or a minimum set of blocks to enumerate contents of HAMT-sharded UnixFS directory, only top level of directory tree, etc).
  - `recursive` announces entire DAGs behind the CIDs (e.g.: entire DAG-CBOR DAG, or everything in UnixFS directory, including all files in all subdirectories).
+
  - `Timestamp` is the current time, formatted as an ASCII string that follows notation from [rfc3339](https://specs.ipfs.tech/ipns/ipns-record/#ref-rfc3339).
+
  - `TTL` is caching and expiration hint informing the server how long to keep the record available, specified as integer in milliseconds.
  - If this value is unknown, the caller may skip this field or set it to 0. The server's default will be used.
+
  - `ID` is a multibase-encoded Peer ID of the node that provides the content and also indicates the `libp2p-key` that SHOULD be used for verifying `Signature` field.
+ - ED25519 and other small public keys MUST be inlined inside of the `ID` field
+ with the identity multihash type.
+ - Key types that exceed 42 bytes (e.g. RSA) SHOULD NOT be inlined, the `ID`
+ field should only include the multihash of the key. The key itself SHOULD be
+ obtained out-of-band (e.g. by fetching the block via IPFS) and cached to
+ reduce the size of the signed `Payload`.
+
+ If support for big keys is needed in
+ the future, this spec can be updated to allow the client to provide the key
+ and key type out-of-band by adding optional `PublicKey` fields, and if the
+ Peer ID is a CID, then the server can verify the public key's authenticity
+ against the CID, and then proceed with the rest of the verification scheme.
+
  - `Addrs` (optional) is an a list of string-encoded multiaddrs without `/p2p/peerID` suffix.
+
  - `Protocols` (optional) is a list of strings with protocols supported by `ID` and/or `Addrs`, if known upfront.
+
  - `Metadata` (optional) is a string with multibase-encoded binary metadata that should be passed as-is
+
+#### Announcement Signature
+
 - `Signature` is a string with multibase-encoded binary signature that provides integrity and authenticity of the `Payload` field.
+
  - Signature is created by following below steps:
- 1. Convert `Payload` to deterministic, ordered [DAG-JSON](https://ipld.io/specs/codecs/dag-json/spec/) map notation
- 2. Prefix the DAG-JSON bytes with ASCII string `POST /routing/v1 announcement:`
+ 1. Convert `Payload` JSON to deterministic, ordered [DAG-CBOR](https://ipld.io/specs/codecs/dag-cbor/spec/) map notation
+ - Specification intention here is to use similar signature normalization as with DAG-CBOR `Data` field in IPNS Records, allowing for partial code and dependency reuse.
+ 2. Prefix the DAG-CBOR bytes with ASCII string `routing-record:`
  3. Sign the bytes with the private key of the Peer ID specified in the `Payload.ID`.
  - Signing details for specific key types should follow [libp2p/peerid specs](https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#key-types), unless stated otherwise.
+
  - Client SHOULD sign every announcement.
  - Servers SHOULD verify signature before accepting a record, unless running in a trusted environment.
- - ED25519 and other small public keys MUST be inlined inside of the `ID` field with the identity multihash type.
- - Key types that exceed 42 bytes (e.g. RSA) SHOULD NOT be inlined, the `ID` field should only include the multihash of the key. The key itself SHOULD be obtained out-of-band (e.g. by fetching the block via IPFS) and cached.
- If support for big keys is needed in the future, this spec can be updated to allow the client to provide the key and key type out-of-band by adding optional `PublicKey` fields, and if the Peer ID is a CID, then the server can verify the public key's authenticity against the CID, and then proceed with the rest of the verification scheme.
-
-A [400 Bad Request](https://httpwg.org/specs/rfc9110.html#status.400) response code SHOULD be returned if either
-- `Signature` is not valid
-- `Payload` serialized to DAG-CBOR is bigger than 2MiB
+ - A [400 Bad Request](https://httpwg.org/specs/rfc9110.html#status.400) response code SHOULD be returned if (in order):
+ - `Payload` serialized to DAG-CBOR is bigger than 2MiB
+ - `Signature` is not valid
 
 #### Use in POST responses