From 2f8aa3b703f56f69cd30bc986bea9397af05f753 Mon Sep 17 00:00:00 2001 From: Dennis Baaten Date: Thu, 20 Feb 2020 12:19:06 +0100 Subject: [PATCH] typo --- DANE-for-SMTP-how-to.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DANE-for-SMTP-how-to.md b/DANE-for-SMTP-how-to.md index 1804b9f..e37ec44 100644 --- a/DANE-for-SMTP-how-to.md +++ b/DANE-for-SMTP-how-to.md @@ -194,7 +194,7 @@ This section describes several pionts for attention when implementing DANE for S * It is possible to use self-signed certificates. * [Section 3.2 of RFC 7672](https://tools.ietf.org/html/rfc7672#section-3.2) states that SMTP clients **must not** perform certificate name checks when using an end-entity certificate (usage type 3). However, it also states that SMTP clients **must** perform certificate name checks when using an intermediate or root certificate (usage type 2). The latter is necessary to prevent attackers from abusing a random intermediate or root certificate to falsely validate their evil mail servers. * [Section 3.1 of RFC 7672](https://tools.ietf.org/html/rfc7672#section-3.1) states that the expiration date of the end-entity certificate MUST be ignored. -* It is highly recommended to use a certificates public key for generating a TLSA signature (selector type "1") instead of the full certificate (selector type "0"), because this enables the reuse of key materials. Alghough it is wise te refresh your key material once in a while, note that the use of Forward Secrecy decreases the need to use a new key-pair on every occasion. +* It is highly recommended to use a certificates public key for generating a TLSA signature (selector type "1") instead of the full certificate (selector type "0"), because this enables the reuse of key materials. Alghough it is wise to refresh your key material once in a while, note that the use of Forward Secrecy decreases the need to use a new key-pair on every occasion. * See also this [example of Let's Encrypt](https://mail.sys4.de/pipermail/dane-users/2019-December/000545.html). In this case the issuer certificate was changed, but the public key was not. As a result a "2 1 1" roll-over record would still validate, but a "2 0 1" roll-over record would not and requires an update. * An issuer certificate (usage type "2") validates only when the full certificate chain is offered by the receiving mail server. * Mail servers by default don't validate certificates and therefore don't have their own certificate store. That's why DANE for SMTP only supports usage type "2" (DANE-TA) and usage type "3" (DANE-EE). Usage type "0" (PKIX-TA) and usage type "1" (PKIX-EE) are not supported.