On Mon, 13 Jul 2015, Viktor Dukhovni wrote:
CT auditors log EE-certs. Checking the CT logs also provides a way to
signal rogue EE-certs to the original webserver via a gossip/client
protocol. So I would not say Usage 3 should never check the CT logs.
DANE-EE(3) certs are often self-signed, and there's no way to
control the "spam" problem on the CT logs with DANE-EE(3).
You don't know what audit logs will use for policies. Perhaps some
audit logs will be dedicated to only self-signed certs. I do not
think the dane document should dictate CT behaviour.
Furthermore such a certificate is only ever "rogue" if DNSSEC is
compromised to publish rogue TLSA RRs.
Not if they use a CT log for prepublishing somehow. Although that is
unlikely to happen with SCT's without a CA, I still think you should
not make those decisions on this document.
I don't think that whether or not public/private CA's are in used in
the TLSA record matters. A client that wants to confirm an EE-cert
via DNSSEC _and_ CT should be able to do so.
Perhaps if it were possible, but I'm afraid it is not. From the
CT FAQ:
Thus CT logs will not accept self-signed, domain-issued, ...
The CT FAQ is not an IETF document.
You're misreading the text. It is warning server operators that
"3 0 0" is less suitable for serving RPK clients (if that's what
We disagree on the concept of "RPK" clients.
I am confused. If DANE is only talking about how to verify a certain
certificate received over TLS, I do not think this document should
modify the TLS protocol with respect to SNI. It's out of scope.
You're confused. The server is free to ignore the client's SNI
extension when it has a single certificate that works for all hosted
domains, because clients authenticate the server via the certificate
or key digest, and don't care about what name is in the certificate.
We're not modifying TLS, we're explaining that the server is free
to ignore the client's SNI extension.
How is that not modifying TLS server behaviour?
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
