security.html

<h2>Security Considerations</h2>
<section>
    <h3>Secure communication</h3>
    <p>All the messages in this protocol (except for a connection invitation that requires no security, by design)
        must be sent encrypted, using the encryption format specified in <a target="aries"
                href="https://github.com/hyperledger/aries-rfcs/blob/master/features/0019-encryption-envelope/README.md">
            DIDComm's encryption envelope</a>. This gives strong guarantees about the confidentiality and integrity of
        exchanged data, regardless of the transport mechanism used to transmit the messages.</p>
</section>
<section>
    <h3>Proof of Control</h3>
    <p>Because peer DIDs are generated from an algorithm that includes the values of their initial public key(s)
        as input, they cannot be created without the creator controlling them. As mentioned earlier, this prevents
        man-in-the-middle attacks at the time of creation.
    </p>
</section>
<section>
    <h3>Entropy</h3>
    <p>
        Since keys must be created from keys generated by a secure random number generator, they are guaranteed
        to be unpredictable and globally unique at creation time.</p>
</section>
<section>
    <h3>Key Management</h3>
    <p>Keys used to control peer DIDs, or keys authorized to communicate and update the DID docs
        for peer DIDs, should be managed according to best practices for DKMS, as described in
        <a target="aries" href="https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0051-dkms/dkms-v4.md">
            the DKMS spec</a>.
    </p>
    <p><a target="sgl" href="https://evernym.github.io/sgl/docs/reference.html#rules">SGL rules</a> are powerful and
        flexible, and should be used to implement best practices.</p>
</section>