Rename of Issuance Keys (#44)

This performs a rename of the Issuance keys as follows:

- `imk : Issuance master key` is renamed to `isk: Issuance authorizing
key`

zip-0226.rst

@@ -72,7 +72,7 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5,
 Asset Identifiers
 -----------------
 
-For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance key of the issuer, the specific Asset Identifier, :math:`\mathsf{AssetId}`, the Asset Digest, and the Asset Base (:math:`\mathsf{AssetBase}`) are derived as defined in ZIP 227 [#zip-0227]_.
+For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{asset\_desc}`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance validating key of the issuer, the specific Asset Identifier, :math:`\mathsf{AssetId}`, the Asset Digest, and the Asset Base (:math:`\mathsf{AssetBase}`) are derived as defined in ZIP 227 [#zip-0227]_.
 
 This Asset Base will be the base point of the value commitment for the specific Custom Asset. Note that the Asset Base of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^\mathsf{Orchard}`.
 

zip-0227-key-components-zsa.svg

@@ -31,10 +31,10 @@
      inkscape:document-units="px"
      inkscape:current-layer="layer1"
      showgrid="false"
-     inkscape:window-width="1158"
+     inkscape:window-width="1068"
      inkscape:window-height="916"
-     inkscape:window-x="381"
-     inkscape:window-y="81"
+     inkscape:window-x="222"
+     inkscape:window-y="102"
      inkscape:window-maximized="0"
      inkscape:showpageshadow="2"
      inkscape:pagecheckerboard="0"
@@ -203,7 +203,7 @@
          x="99.664932"
          id="tspan3757-7"
          sodipodi:role="line"
-         style="stroke-width:1.06667">imk</tspan></text><text
+         style="stroke-width:1.06667">isk</tspan></text><text
        id="text3755-6-6"
        y="911.11285"
        x="106.69933"
@@ -223,7 +223,7 @@
          y="1019.9116"
          x="184.15979"
          id="tspan3852-9-93"
-         sodipodi:role="line">Issuance master key</tspan></text><path
+         sodipodi:role="line">Issuance authorizing key</tspan></text><path
        sodipodi:nodetypes="cc"
        inkscape:connector-curvature="0"
        id="path3980-1"

zip-0227.rst

@@ -83,7 +83,7 @@ Specification: Issuance Keys and Issuance Authorization Signature Scheme
 
 The Orchard-ZSA Protocol adds the following keys to the key components [#protocol-addressesandkeys]_:
 
-1. The issuance master key, denoted as :math:`\mathsf{imk}`, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer.
+1. The issuance authorizing key, denoted as :math:`\mathsf{isk}`, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer.
 
 2. The issuance validating key, denoted as :math:`\mathsf{ik}`, is the key that is used to validate issuance transactions. This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer.
 
@@ -120,47 +120,47 @@ The issuance authorizing key generation algorithm and the issuance validating ke
 Issuance Key Derivation
 -----------------------
 
-Issuance master key generation for hierarchical deterministic wallets
-`````````````````````````````````````````````````````````````````````
+Issuance authorizing key generation for hierarchical deterministic wallets
+``````````````````````````````````````````````````````````````````````````
 
-The issuance master key is generated using the Orchard master key derivation procedure defined in ZIP 32 [#zip-0032-orchard-master]_. We reuse the functions defined there in what follows in this section.
+The issuance authorizing key is generated using the Orchard master key derivation procedure defined in ZIP 32 [#zip-0032-orchard-master]_. We reuse the functions defined there in what follows in this section.
 
 Let :math:`S` be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes.
 We define the master extended issuance key :math:`m_{\mathsf{Issuance}} := \mathsf{MasterKeyGen}(\texttt{"ZIP32ZSAIssue_V1"}, S)`.
 
-As in ZIP 32 for Orchard [#zip-0032-orchard-child-key-derivation]_, we only use hardened child key derivation for the issuance master key. 
+As in ZIP 32 for Orchard [#zip-0032-orchard-child-key-derivation]_, we only use hardened child key derivation for the issuance authorizing key. 
 We reuse the :math:`\mathsf{CDKsk}` function for Orchard child key derivation from ZIP 32.
 
-We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD paths, and define the issuance master key path as :math:`m_\mathsf{Issuance} / purpose' / coin\_type' / account'`. We fix the path levels as follows:
+We use the notation of ZIP 32 [#zip-0032-orchard-key-path]_ for shielded HD paths, and define the issuance authorizing key path as :math:`m_\mathsf{Issuance} / purpose' / coin\_type' / account'`. We fix the path levels as follows:
 
 - :math:`purpose`: a constant set to :math:`227` (i.e. :math:`\texttt{0xe3}`). :math:`purpose'` is thus :math:`227'` (or :math:`\texttt{0x800000e3}`) following the BIP 43 recommendation.
 - :math:`coin\_type`: Defined as in ZIP 32 [#zip-0032-key-path-levels]_.
 - :math:`account`: fixed to index :math:`0`.
 
-From the generated :math:`(\mathsf{sk}, \mathsf{c})`, we set the issuance master key to be :math:`\mathsf{imk} := \mathsf{sk}`.
+From the generated :math:`(\mathsf{sk}, \mathsf{c})`, we set the issuance authorizing key to be :math:`\mathsf{isk} := \mathsf{sk}`.
 
 Derivation of issuance validating key
 `````````````````````````````````````
 
-Define :math:`\mathsf{IssueAuthSig.DerivePublic}\: : \: (\mathsf{imk}\: : \: \mathsf{IssueAuthSig.Private}) \to \mathsf{IssueAuthSig.Public}` as:
+Define :math:`\mathsf{IssueAuthSig.DerivePublic}\: : \: (\mathsf{isk}\: : \: \mathsf{IssueAuthSig.Private}) \to \mathsf{IssueAuthSig.Public}` as:
 
-* :math:`\mathsf{ik} := \textit{PubKey}(\mathsf{imk})`
+* :math:`\mathsf{ik} := \textit{PubKey}(\mathsf{isk})`
 * Return :math:`\bot` if the :math:`\textit{PubKey}` algorithm invocation fails, otherwise return :math:`\mathsf{ik}`.
 
 where the :math:`\textit{PubKey}` algorithm is defined in BIP 340 [#bip-0340]_. 
 
 It is possible for the :math:`\textit{PubKey}` algorithm to fail with very low probability, which means that :math:`\mathsf{IssueAuthSig.DerivePublic}` could return :math:`\bot` with very low probability. 
-If this happens, discard the keys and repeat with a different :math:`\mathsf{imk}`.
+If this happens, discard the keys and repeat with a different :math:`\mathsf{isk}`.
 
 This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.
 
 Issuance Authorization Signing and Validation
 ---------------------------------------------
 
-Define :math:`\mathsf{IssueAuthSig.Sign}\: : \: (\mathsf{imk}\: : \: \mathsf{IssueAuthSig.Private}) \times (M\: : \: \mathsf{IssueAuthSig.Message}) \to \mathsf{IssueAuthSig.Signature}` as:
+Define :math:`\mathsf{IssueAuthSig.Sign}\: : \: (\mathsf{isk}\: : \: \mathsf{IssueAuthSig.Private}) \times (M\: : \: \mathsf{IssueAuthSig.Message}) \to \mathsf{IssueAuthSig.Signature}` as:
 
 * Let the auxiliary data :math:`a = \mathtt{[0x00]}^{32}`.
-* Let :math:`\sigma = \mathsf{Sign}(\mathsf{imk},M)`.
+* Let :math:`\sigma = \mathsf{Sign}(\mathsf{isk},M)`.
 * Return :math:`\bot` if the :math:`\mathsf{Sign}` algorithm fails in the previous step, otherwise return :math:`\sigma`.
 
 where the :math:`\mathsf{Sign}` algorithm is defined in BIP 340 and :math:`a` denotes the auxiliary data used in BIP 340 [#bip-0340]_.
@@ -269,7 +269,7 @@ It contains the following fields:
 
 - :math:`\mathsf{ik}`: the issuance validating key, that allows the validators to verify that the :math:`\mathsf{AssetId}` is properly associated with the issuer.
 - ``vIssueActions``: an array of issuance actions, of type ``IssueAction``.
-- :math:`\mathsf{issueAuthSig}`: the signature of the transaction SIGHASH, signed by the issuance master key, :math:`\mathsf{imk}`, that validates the issuance .
+- :math:`\mathsf{issueAuthSig}`: the signature of the transaction SIGHASH, signed by the issuance authorizing key, :math:`\mathsf{isk}`, that validates the issuance .
 
 The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format [#protocol-transactionstructure]_.
 
@@ -307,7 +307,7 @@ For the ``IssueBundle``:
 
 - encode the ``vIssueActions`` vector.
 - encode the :math:`\mathsf{ik}` as 32 byte-string.
-- sign the SIGHASH transaction hash with the issuance master key, :math:`\mathsf{imk}`, using the :math:`\mathsf{IssueAuthSig}` signature scheme. The signature is then added to the issuance bundle.
+- sign the SIGHASH transaction hash with the issuance authorizing key, :math:`\mathsf{isk}`, using the :math:`\mathsf{IssueAuthSig}` signature scheme. The signature is then added to the issuance bundle.
 
 
 **Note:** that the commitment is not included in the ``IssuanceAction`` itself. As explained below, it is computed later by the validators and added to the note commitment tree.
@@ -553,7 +553,7 @@ Issuance Key Compromise
 
 The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended:
 
-- If an issuance validating key is compromised, the :math:`\mathsf{finalize}` boolean for all the Assets issued with that key should be set to :math:`1` and the issuer should change to a new issuance master key, and issue new Assets, each with a new :math:`\mathsf{AssetId}`.
+- If an issuance validating key is compromised, the :math:`\mathsf{finalize}` boolean for all the Assets issued with that key should be set to :math:`1` and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new :math:`\mathsf{AssetId}`.
 
 Bridging Assets
 ---------------