remove requirement to sign the key, since it is no longer used to trust it

proposals/1946-secure_server-side_storage.md

@@ -38,9 +38,8 @@ Each key has an ID, and the description of the key is stored in the user's
 account_data using the event type `m.secret_storage.key.[key ID]`.  The contents
 of the account data for the key will include an `algorithm` property, which
 indicates the encryption algorithm used, as well as a `name` property, which is
-a human-readable name.  The contents will be signed as signed JSON using the
+a human-readable name.  Other properties depend on the encryption algorithm,
-user's master cross-signing key.  Other properties depend on the encryption
+and are described below.
-algorithm, and are described below.
 
 Example:
 
@@ -61,13 +60,6 @@ secrets that the user would expect to be available on all their clients.
 Unless the user specifies otherwise, clients will try to use the default key to
 decrypt secrets.
 
-Clients MUST ensure that the key is trusted before using it to encrypt secrets.
-One way to do that is to have the client that creates the key sign the key
-description (as signed JSON) using the user's master cross-signing key.
-Another way to do that is to prompt the user to enter the passphrase used to
-generate the encryption key and ensure that the generated private key
-corresponds to the public key.
-
 #### Secret storage
 
 Encrypted data is stored in the user's account_data using the event type

proposals/2472-symmetric-ssss.md

@@ -51,6 +51,10 @@ is able to store data.
   using a symmetric encryption algorithm, the client needs to know the key that
   is used to encrypt, so the purpose of the field cannot be fulfilled.
 
+* Signing the Secret Storage key with the user's master cross-signing key is no
+  longer required.  The key is trusted on the basis of the user entering the
+  key/passphrase.
+
 
 ## Potential issues