XX/WAKU-KEYSTORE: new RFC

[s1fr0]

Problem

The PR https://github.com/waku-org/nwaku/pull/1466 implements in nwaku the JSON keystore format proposed in https://github.com/waku-org/nwaku/issues/1238#issuecomment-1278114079. Encryption of credentials is done using an implementation derived from nimbus keystore and implemented in nwaku in https://github.com/waku-org/nwaku/pull/1285.

In order to properly address https://github.com/vacp2p/rfc/issues/543, the format and features implemented by the above PRs should be documented in a new RFC with suggested name XX/WAKU-KEYSTORE, to reflect the fact that in nwaku all related implementations are grouped under the protocol\waku_keystore module.

Credentials padding

In https://github.com/vacp2p/rfc/issues/543#issuecomment-1289798259 it is noted that the default keyfile implementation uses aes-ctr, which leaks the length of the ciphertext. Padding is not enforced in current nwaku implementation and it is up to the RFC to specify how this should be done (e.g. by using pkcs7 padding implemented in https://github.com/waku-org/nwaku/blob/6811af328cfae8b23755faaf3a30dae5df15880e/waku/v2/protocol/waku_noise/noise_utils.nim#L38-L60)

Acceptance criteria

• [ ] Publish a raw RFC to detail the format and features of the waku_keystore module
• [ ] Update the RFCs whose implementations currently use waku_keystore (e.g. 17/WAKU-RLN-RELAY) with a proper reference to and usage description of the XX/WAKU-KEYSTORE RFC.
• [ ] Address ciphertext padding in implementations.

[rymnc]

@kaiserd should we update the acceptance criteria here to just include the raw rfc for the current implementation? imo we shouldn't be including the padding in it yet since there is no reference impl I will create an issue in nwaku to address the padding of ciphertext

[jimstir]

Clsoing, RFC created here and spec located here