fix!: follow DIP-11 key rules when disabling keys and reading contact requests

docs/dashpay/INTEROP_DESK_CHECK.md

@@ -471,17 +471,18 @@ The alignment recommendation above is superseded on the receive side by
 contacts established through the legacy Android/dashj client had 27 inbound
 requests that reference the recipient's AUTHENTICATION or TRANSFER key, and the
 documents are immutable, so rejecting them left those contacts unpayable. The
-rules now are (rs-sdk `platform/dashpay/contact_request.rs`):
+rules now are:
 
-- **Send (documents we create):** unchanged. The sender key must be ENCRYPTION
-  (`sender_key_purpose_is_valid`) and the recipient key DECRYPTION or ENCRYPTION
+- **Send (documents we create; rs-sdk `platform/dashpay/contact_request.rs`):**
+  unchanged. The sender key must be ENCRYPTION (`sender_key_purpose_is_valid`)
+  and the recipient key DECRYPTION or ENCRYPTION
   (`recipient_key_purpose_is_valid`).
-- **Receive (documents already on chain):** the recipient key may be DECRYPTION,
-  ENCRYPTION, AUTHENTICATION or TRANSFER
-  (`recipient_key_purpose_is_acceptable_on_receive`), and the sender key
-  ENCRYPTION or AUTHENTICATION (`sender_key_purpose_is_acceptable_on_receive`).
-  Any other purpose is a mismatch that is skipped and retried, never a
-  permanently broken channel.
+- **Receive (documents already on chain; rs-platform-wallet
+  `wallet/identity/crypto/validation.rs`, `validate_contact_request`):** key
+  purpose is not checked. Only the key type is: the sender key must be
+  ECDSA_SECP256K1, and the recipient key ECDSA_SECP256K1 or ECDSA_HASH160. A
+  key of another type is a permanent error; a key id absent from the identity
+  is retryable, since identities gain keys; a disabled key is only a warning.
 
 ## Re-checking against the reference clients
 

packages/rs-dpp/src/errors/protocol_error.rs

@@ -15,6 +15,7 @@ use crate::document::errors::*;
 ))]
 use crate::state_transition::errors::InvalidIdentityPublicKeyTypeError;
 
+use crate::identity::key_disable_rule::LastAuthenticationKeyError;
 #[cfg(all(feature = "state-transitions", feature = "validation"))]
 use crate::state_transition::errors::StateTransitionError;
 
@@ -324,6 +325,12 @@ pub enum ProtocolError {
         using: u16,
         msg: &'static str,
     },
+
+    /// An identity update would disable the last valid authentication key of a security
+    /// level (DIP-11). Refused by the signing builder before anything is signed; this is
+    /// client-side policy, not a consensus rule, so it is never a `ConsensusError`.
+    #[error(transparent)]
+    LastAuthenticationKey(#[from] LastAuthenticationKeyError),
 }
 
 impl From<&str> for ProtocolError {

packages/rs-dpp/src/identity/identity_public_key/key_type.rs

@@ -99,6 +99,21 @@ impl KeyType {
         }
     }
 
+    /// Can a key of this type sign an identity-signed state transition?
+    ///
+    /// Mirrors the `SUPPORTED_KEY_TYPES` set drive-abci checks in
+    /// `validate_state_transition_identity_signed` (ECDSA_SECP256K1, BLS12_381 and
+    /// ECDSA_HASH160); `StateTransition::sign` refuses the other types. Keep the two in step.
+    pub fn can_sign_state_transitions(&self) -> bool {
+        match self {
+            KeyType::ECDSA_SECP256K1 => true,
+            KeyType::BLS12_381 => true,
+            KeyType::ECDSA_HASH160 => true,
+            KeyType::BIP13_SCRIPT_HASH => false,
+            KeyType::EDDSA_25519_HASH160 => false,
+        }
+    }
+
     /// Can this key type be understood as an address on the Core chain?
     pub fn is_core_address_key_type(&self) -> bool {
         match self {