On Fri, Aug 21, 2015 at 10:41:49PM -0700, Alice Wonder wrote:
> I received a rather weird e-mail, it seems to have been generated by an MTA
> because it was sent to the e-mail listed as the contact in my certificate,
> the e-mail listed in whois for my domain, and the postmaster e-mail.
Sorry my DANE monitoring notices look "weird", at least some people
find them informative.
> It claims:
s/claims/states/
> Only certificate usages DANE-TA(2) and DANE-EE(3) are supported
> with SMTP. See:
>
> https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.3
Correct.
> ---
>
> The certificate is a 1 0 1 and not a 3 0 1
>
> It seems to suggest that I change the TLSA record to 3 0 1
Or even better a "3 1 1".
>
> I get that other SMTP servers shouldn't be expected to do CA validation, but
> should one really mis-identify a CA signed cert as self-signed just because
> the other MTAs are not going to be able to validate it?
It is not a "mis-identification" or a "mis-representation" to
publish a DANE end-entity (usage 3) binding for a CA-issued
certificate.
> It seems more logical to me that if an MTA is using DANE validation and
> encounters a certificate with a 0 or 1 that it treat the certificate as if
> it was a 2 or 3 rather than asking the other MTA to mis-identify the
> certificate.
There is no "mis-identification". You'd be publishing a TLSA
certificate binding that is self-contained and independent of the
public CA Web PKI. Just because a certificate is issued by a
public CA, does not mean that the DANE record for opportunistic
TLS needs to be a "CA constraint". See also:
https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-4.1
> A certificate has to be used for TLS communication, whether it is
> self-signed or not doesn't matter - the TLSA fingerprint can still be
> validated whether it is a 1 0 1 or 3 0 1 TLSA entry.
>
> So why would an IETF draft suggest that they shouldn't be used?
The drafts contain explanations that need not be repeated here.
Note that usage 0 cannot be safely mapped to usage 2, because the
usage 0 publisher might not be including self-signed root certs in
his wire chain (e.g. Microsoft Exchange TLS can't send root certs
in the chain). And if all SMTP clients map PKIX-EE(1) to DANE-EE(3),
the right thing to do is to *publish* 3, and not rely on there being
an ad-hoc mapping that violates the standard semantics of the record.
> Expecting administrators with signed certificates to break the RFC for DANE
> just because some (all?) MTAs will not check with a CA seems bad.
No, breaking the RFC would be not adhering to the published usage
semantics. Publishing usage 3 for a CA issued cert is entirely
valid.
--
Viktor.
