Add merklemap to Certificate_and_Public_Key_Pinning.md (#989)

pages/controls/Certificate_and_Public_Key_Pinning.md

@@ -69,7 +69,7 @@ As shown above, the browser vendors have taken great steps to deal with these is
 ##### Certificate Transparency Logs
 This recommendation suggests publishing issued certificates into a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) so that the records are public and immutable. Thanks to Google’s market leverage, [Certificate Transparency Logging](https://certificate.transparency.dev/) has become a de facto standard. Google introduced CT Logging as optional in Chrome, for a time and then as CA’s came on board, they eventually began requiring every certificate that Chrome trusts to have been logged in CT. Given the success of this feature, CT logging is now reunited by Safari and Edge as well, covering [approximately 91%](https://www.browserstack.com/guide/understanding-browser-market-share) of the browser market as of 2023. Before a certificate is valid in any of these browsers, it must first be sent to 2 or 3 CT logs. The log servers themselves are readable to verify the certificate was logged, but they also provide signatures to be added to the final certificates, so that they can be verified in-band.
 
-While CT Logs are a Merkle tree that is not simply searchable, there are many sites, like [crt.sh](https://crt.sh/), that gather CT log data, as well as test other aspects of the certificates, and make data more searchable.
+While CT Logs are a Merkle tree that is not simply searchable, there are many sites, like [crt.sh](https://crt.sh/) and [merklemap](https://www.merklemap.com/), that gather CT log data, as well as test other aspects of the certificates, and make data more searchable.
 
 ##### CAA Records
 Another criticism of having larger trust stores with many CAs is that in most cases, a website will only use one or two CA vendors, despite most stores having more than 200 CAs present. This opens the possibility for an attacker to get a certificate for that site from any of the other numerous CAs (by trickery, bribery, etc.) and then use DNS cache poisoning or similar techniques to enable man-in-the-middle attacks against some specific web server. To combat this, the CA/BF requires CAs to respect [RFC 8659](https://datatracker.ietf.org/doc/html/rfc8659) DNS Certification Authority Authorization (CAA) Resource Record. A CAA record is a DNS record that is used to tell a CA, at the moment of certificate issuance, that only a certain CA or set of CAs is allowed to issue certificates for that domain or DNS name. CAA Resource Records are commonly used to support / bootstrap DNSSEC.