Re: [mailop] Certificate chain when encrypting SMTP

2018-09-22 Thread Phil Pennock
On 2018-09-13 at 16:30 +0300, Vladimir Dubrovin via mailop wrote:
> For opportunistic TLS, there is no difference between certificate signed
> by CA and self-signed certificate (or even unsigned), because
> cerificatate is usually not validated. Certificate validation is useless
> here, because opportunistic TLS falls back to cleartext anyway.
> 
> For DANE, again there is no difference, because certificate is pinned
> via DNS.

There are two modes with DANE in SMTP.

Usage 3, the certificate is pinned.  (DANE-EE, End-Entity)
Usage 2, the CA certificate is pinned, and so you need to provide the
trust chain back to the anchored CA.  (DANE-TA, Trust-Anchor)

Whether to use DANE-EE or DANE-TA is a local decision; there are various
opinions online (aren't there always) but really it boils down to how
integrated DNS editing is to your mail-server workflow and whether or
not you want to setup pre-staging of certificates before actually
serving them, then only put them live later.

I like to keep life simple, and to use the certificates as soon as
they're issued; I publish DANE-TA records, using Lets Encrypt anchors.
If there's a LE CA certificate roll which changes the public keys, then
I need to pay attention to the warnings online and update the DNS
records, but otherwise DNS is unchanged when the certificates are
issued.

DANE-TA/SPKI means that if there's another cert reissuance using the
same private/public keypair (as done for Let's Encrypt X1/X2 -> X3/X4)
then I don't need to care.

(RFC 7218 for the terminology)
-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Certificate chain when encrypting SMTP

2018-09-13 Thread Vladimir Dubrovin via mailop

P.S.
for client access (SMTP submission) validation is also important, whole
chain must be provided for better compatibility.

13.09.2018 16:30, Vladimir Dubrovin пишет:
>
> For opportunistic TLS, there is no difference between certificate
> signed by CA and self-signed certificate (or even unsigned), because
> cerificatate is usually not validated. Certificate validation is
> useless here, because opportunistic TLS falls back to cleartext anyway.
>
> For DANE, again there is no difference, because certificate is pinned
> via DNS.
>
> For SMTP STS validation is important and you better provide whole
> certificate chain (except self-signed root CA) for compatibility.
>
> 13.09.2018 15:56, Christian пишет:
>> Hey,
>>
>> I was wondering what the best practice is regarding certificate
>> chains provided through SMTP.
>>
>> Should you present the entire certificate chain including the CA or
>> just the certificate and all intermediate certificates?
>>
>> As I understand it the CA has to be in the trust store of the other
>> party anyways since it makes no sense to trust all other certificates
>> if there is no trusted CA, even if the server provides it. If the
>> provided (or not provided) CA is not in the trust store it is as good
>> as a self-signed/unsigned certificate (chain), isn't it?
>> Even if this might be true, is it still best practice to provide the CA?
>>
>> Of course, the matter is different with DANE since you can argue a
>> "pinned" certificate is better than one signed by a CA.
>>
>> Can someone shed some light on how off I am on this topic?
>>
>> Thanks,
>> Christian
>>
>> PS: Do best practices differ from the those for HTTPS?
>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> -- 
> Vladimir Dubrovin
> @Mail.Ru


-- 
Vladimir Dubrovin
@Mail.Ru

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Certificate chain when encrypting SMTP

2018-09-13 Thread Vladimir Dubrovin via mailop

For opportunistic TLS, there is no difference between certificate signed
by CA and self-signed certificate (or even unsigned), because
cerificatate is usually not validated. Certificate validation is useless
here, because opportunistic TLS falls back to cleartext anyway.

For DANE, again there is no difference, because certificate is pinned
via DNS.

For SMTP STS validation is important and you better provide whole
certificate chain (except self-signed root CA) for compatibility.

13.09.2018 15:56, Christian пишет:
> Hey,
>
> I was wondering what the best practice is regarding certificate chains
> provided through SMTP.
>
> Should you present the entire certificate chain including the CA or
> just the certificate and all intermediate certificates?
>
> As I understand it the CA has to be in the trust store of the other
> party anyways since it makes no sense to trust all other certificates
> if there is no trusted CA, even if the server provides it. If the
> provided (or not provided) CA is not in the trust store it is as good
> as a self-signed/unsigned certificate (chain), isn't it?
> Even if this might be true, is it still best practice to provide the CA?
>
> Of course, the matter is different with DANE since you can argue a
> "pinned" certificate is better than one signed by a CA.
>
> Can someone shed some light on how off I am on this topic?
>
> Thanks,
> Christian
>
> PS: Do best practices differ from the those for HTTPS?
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


[mailop] Certificate chain when encrypting SMTP

2018-09-13 Thread Christian
Hey,

I was wondering what the best practice is regarding certificate chains
provided through SMTP.

Should you present the entire certificate chain including the CA or
just the certificate and all intermediate certificates?

As I understand it the CA has to be in the trust store of the other party
anyways since it makes no sense to trust all other certificates if there is
no trusted CA, even if the server provides it. If the provided (or not
provided) CA is not in the trust store it is as good as a
self-signed/unsigned certificate (chain), isn't it?
Even if this might be true, is it still best practice to provide the CA?

Of course, the matter is different with DANE since you can argue a "pinned"
certificate is better than one signed by a CA.

Can someone shed some light on how off I am on this topic?

Thanks,
Christian

PS: Do best practices differ from the those for HTTPS?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop