If the DANE-EE entry has a SubjectPublicKeyInfo hash, then the metadata within the certificate can be trusted only if the certificate signature is validated against a trust anchor: a self-signed certificate is sufficient (and probably ideal) here, since the client has already trusted the public key via DANE.
Absent signature verification, the client should probably throw away the rest of the certificate to avoid the temptation of trusting any of it: it's simply unclear to me what are the security implications to the universe of clients of having unauthenticated data present in the certificate or associated client context. What I mean is, what data from certificates other than the public key modify clients' behaviors? It may be "nothing" (i.e., that "the only item of interest in the certificate is the public key part"), but it's not clear to me that this is the case. Kyle On Tue, May 12, 2015 at 8:52 AM, Paul Wouters <[email protected]> wrote: > On Tue, 12 May 2015, Kyle Rose wrote: > > The draft statement that the record "need not change across certificate >> renewals with the same key" seems misleading. If >> anything in the certificate changes—and typically the expiration date >> will change if a certificate is regenerated using >> common tools, whether or not it is likely to be honored by a client—the >> certificate digest will change. Since presumably the >> TLSA record digest is of the entire certificate and not simply of the >> public key, as the authenticity of much of the >> metadata within the certificate is still of interest to clients, this >> means the digest in the TLSA record will change. >> >> It seems in fact that any renewal of the certificate producing anything >> other than a bit-identical output would necessitate >> a record change. >> >> Or what am I missing? >> > > https://tools.ietf.org/html/rfc6698#section-2.1.2 > > There are two main pubishers of TLSA records. Those who want an addotional > non-CA third party certificate validator, and those who want to replace > the CA. > > For those replacing the CA, the only item of interest in the > certificate is the public key part. These people likely will > need to allow for CA's for the next little while, so they > will do the regular "renewing" of the certificate, but they > won't care to put any of that under TLSA verification, as > it is just a CA/PKIX place holder. > > Paul >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
