On 2013-09-04 17:13, Ian Fette wrote:
Ondřej, I might be getting it wrong, but since our CA is cross-signed
by another CA, the chain that most clients will build will be rooted
in something else.
The usual problem is that the CA store in SMTP servers is empty by
default
and people usually (somebody should probably do some survey) use
self-signed
certs/CAs for their SMTP service.
You can see this if you go to
https://mail.google.com [7] - GeoTrust shows as the root, which signs
Google Internet Authority G2, which signs a cert for mail.google.com
[8]. If someone is using openssl and it follows AIA chaining or
otherwise constructs a trust chain up to GlobalSign and we had
specified "2" with the intermediate, would that break or still work?
It would still work if you send whole chain in the TLS up to the
certificate specified in TLSA record.
O.
(Sorry, this is probably the most confusing part of the spec)
On Wed, Sep 4, 2013 at 5:38 AM, Ondřej Surý <[email protected]>
wrote:
Ian,
On 4. 9. 2013, at 6:13, Ian Fette (イアンフェッティ)
<[email protected]> wrote:
I'm not sure that I agree with everything in that draft,
particularly the bit about not using certificate usage 0/1, as this
is precisely what we would do for Gmail most likely (we operate our
own CA, and for instance in Chrome and via
You need certificate usage 2 for your own CA and the mapping 0->2,
1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE
record with certificate usage 0 SHOULD be used even in case that you
use a well established CA.
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [1]
we typically pin google.com [2] to a set of CA certificates, not
leaf certificates, as the leaf certificates can rotate more
frequently based on operational needs but our CA cert changes much
more rarely.) It's not clear to me why requiring PKIX validation in
that case would be an unreasonable expectation.
I guess this comes from operational experiences, currently the SMTP
servers don't do any validation on the certificates and it would be
a great leap to take, so it's better to start with opportunistic TLS
than enforcing the users to do full PKIX.
This might change in the future in some future draft, but Viktor's
draft would be a huge leap for SMTP encryption.
Indeed, most of the certs I see from a random inspection of
servers offering STARTTLS (google, t-online, web.de [3] etc) include
a full certificate chain to a public CA. Other than that nit though,
I would love to see that draft advance.
O.
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:[email protected] http://nic.cz/ [4]
tel:+420.222745110 [5] fax:+420.222745112 [6]
-------------------------------------------
Links:
------
[1] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08
[2] http://google.com
[3] http://web.de
[4] http://nic.cz/
[5] tel:%2B420.222745110
[6] tel:%2B420.222745112
[7] https://mail.google.com
[8] http://mail.google.com
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
