(source)

Table of Contents

• RFC-XXXX: Adding customized mandatory context to proof of possession statement
  • Summary
  • Motivation
  • Explanation
  • Drawbacks
  • Testing, Security, and Privacy
  • Performance, Ergonomics, and Compatibility
    • Performance
    • Ergonomics
    • Compatibility
  • Prior Art and References
  • Unresolved Questions
  • Future Directions and Related Material

RFC-XXXX: Adding customized mandatory context to proof of possession statement

Summary

This RFC is an amendment to RFC-0048. It proposes changing the OpaqueKeysInner:create_ownership_proof and OpaqueKeys:: ownership_proof_is_valid to invoke generation and validation procedures specific to each crypto type. This enables different crypto schemes to implement proof of possession that fits their security needs. In short, this RFC delegates the procedure of generating and validating proof of possession to the crypto schemes rather than dictating a uniform generation and verification.

Motivation

Following RFC-0048, all submitted keys accompany a signature of the account_id by the same key, proving that the submitter knows the private key corresponding to the submitted key. However, a scheme should mandate a context-specific approach for generating proof of possession and a different context for signing anything else to prevent rogue key attacks [3]. While this is critical for schemes with aggregatable public keys, the other (non-aggregatable) crypto schemes opt for backward compatibility and accept signatures not prepended with mandatory context.

However, the current RFC does not allow using different API calls and procedures to generate proof of possession for different crypto schemes.

After this RFC, the procedure for generating and verifying proof of possession would be at the discretion of the crypto scheme itself, not deterministically tied to the way they sign other messages. Stakeholders

• Polkadot runtime implementors
• Polkadot node implementors
• Validator operators

Explanation

The RFC does not change the structure introduced by RFC-0048. The proof is a sequence of signatures:

#![allow(unused)]
fn main() {
type Proof = (Signature, Signature, ..);
}

However, each signature is generated by the crypto scheme instead of each private session key signing the account_id. By default, the following statement is signed by the crypto scheme:

rust
"POP_"|account_id

The prefix could alert signers if they are misled into signing false proof of possession statements. More importantly, a new crypto scheme could specify a different structure for its proof of possession.

Because RFC-0048 has not been deployed, the version of the SessionKeys could still be set to 1 as requested by RFC-0048.

Drawbacks

Crypto scheme needs to implement an explicit generate_proof_of_possession and verify_proof_of_possession runtime API in addition to old capabilities (sigen, verify, etc).

Testing, Security, and Privacy

The proof of possession for current crypto schemes is virtually identical to the one defined in RFC-0048. On the other hand, the changes proposed by this RFC allow the generation of secure proof of possession for BLS keys.

Performance, Ergonomics, and Compatibility

Performance

The performance is the same as the one discussed in RFC-0048.

Ergonomics

Separating the generation of proof of possession from signing allows a crypto scheme more freedom to implement proof of possession that is fitted to its needs.

Compatibility

The significant difference is that proof of possession suggested by RFC-0048 is signed:

rust
account_id

vs the current proposal suggests changing the statement to:

rust
"POP_"|account_id

for the current crypto scheme. However, future crypto schemes such as BLS, which are not bound to backward compatibility, could produce more sophisticated proof of possession.

Prior Art and References

This is a minor amendment to RFC-0048.

Unresolved Questions

None.

Future Directions and Related Material

- [1] Substrate implementation of the generation of proof of possession for all crypto schemes (current and experimental ones) is implemented in Pull 6010.

- [2] Substrate implementation of RFC-0048, in which the implementation of OpaqueKeysInner:create_ownership_proof and OpaqueKeys:: ownership_proof_is_valid should be modified to call generate_proof_of_possion and verify_proof_of_possession runtime APIs instead of directly calling the sign.

- [3] Ristenpart, T., & Yilek, S. (2007). The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks. In , Annual {{International Conference}} on the {{Theory}} and {{Applications}} of {{Cryptographic Techniques} (pp. 228–245). : Springer).