Deploying to gh-pages from @ c463e84 🚀

docs/spec-files/routing.md

@@ -101,7 +101,7 @@ The recipient (`next` attribute of 'forward' message) may have pre-configured ad
 
 #### DID Document Keys
 
-Ideally, all keys declared in the `keyAgreement` section of a given recipient's DID document are used as target keys when encrypting a message. To encourage this, DIDComm encrypts the main message content only once, using an ephemeral content encryption key, and then encrypts the relatively tiny ephemeral key once per recipient key. This "multiplexed ecnryption" is efficient, and it allows a recipient to change devices over the course of a conversation without prior arrangement.
+Ideally, all keys declared in the `keyAgreement` section of a given recipient's DID document are used as target keys when encrypting a message. To encourage this, DIDComm encrypts the main message content only once, using an ephemeral content encryption key, and then encrypts the relatively tiny ephemeral key once per recipient key. This "multiplexed encryption" is efficient, and it allows a recipient to change devices over the course of a conversation without prior arrangement.
 
 However, practical considerations can frustrate this ideal. If a recipient's DID document declares keys of different types, a sender has to prepare more than one encryption envelope — and if not all of a recipient's key types are supported by the sender, the goal is simply unachievable.
 

docs/spec/index.html

@@ -1108,7 +1108,7 @@ <h4 id="mediator-process"><a class="toc-anchor" href="#mediator-process" >§</a>
 </ol>
 <p>The recipient (<code>next</code> attribute of ‘forward’ message) may have pre-configured additional routing keys with the mediator that were not present in the DID Document and therefore unknown to the original sender. If this is the case, the mediator should wrap the attached <code>payload</code> message into an additional Forward message once per routing key. This step is performed between (2) and (3).</p>
 <h4 id="did-document-keys"><a class="toc-anchor" href="#did-document-keys" >§</a> DID Document Keys</h4>
-<p>Ideally, all keys declared in the <code>keyAgreement</code> section of a given recipient’s DID document are used as target keys when encrypting a message. To encourage this, DIDComm encrypts the main message content only once, using an ephemeral content encryption key, and then encrypts the relatively tiny ephemeral key once per recipient key. This “multiplexed ecnryption” is efficient, and it allows a recipient to change devices over the course of a conversation without prior arrangement.</p>
+<p>Ideally, all keys declared in the <code>keyAgreement</code> section of a given recipient’s DID document are used as target keys when encrypting a message. To encourage this, DIDComm encrypts the main message content only once, using an ephemeral content encryption key, and then encrypts the relatively tiny ephemeral key once per recipient key. This “multiplexed encryption” is efficient, and it allows a recipient to change devices over the course of a conversation without prior arrangement.</p>
 <p>However, practical considerations can frustrate this ideal. If a recipient’s DID document declares keys of different types, a sender has to prepare more than one encryption envelope — and if not all of a recipient’s key types are supported by the sender, the goal is simply unachievable.</p>
 <p>In addition, if a sender is routing the same message to more than one recipient (not just more than one key of the same recipient), the sender has to wrap the message differently because it will flow through different mediators.</p>
 <p>This leads to a rule of thumb rather than a strong normative requirement: a sender SHOULD encrypt for as many of a recipient’s keys as is practical.</p>