On Sat, 2014-10-11 at 16:12 +0000, Viktor Dukhovni wrote:
> On Sat, Oct 11, 2014 at 12:13:29PM +0200, Mark Elkins wrote:
Thanks for the details. I appreciate the education.
> > I presume the motivation for using the Public-Key instead of the whole
> > Certificate is either simplicity or less prone to bad key management?
> Both. And this is more flexible, because it is compatible with
> RFC 7250 raw public keys. That's not yet implemented in SSL
> toolkits, but will be in the future.
> > Could your reasoning be that the Public-Key would remain constant (for
> > the same CSR) regardless of whether the Certificate is self-signed or
> > signed (or resigned) by a CA?
> Correct. Any certificate for the same public key (and correspoding
> private key known only to the server) matches.
> > ... or in other words - Certificate
> > rollover will not break a TLSA using just the Public-Key?
> Yes.
> > But wouldn't that then break the tie to one's preferred CA?
> With certificate usage DANE-EE(3) there is no tie to one's preferred
> CA. The certificate content apart from the public key is effectively
> ignored anyway.
I'm aware that DANE ignores Expiry dates and other data but the
Certificate may have embedded CA info (mine does) and if the HASH is for
the whole of the certificate - then using Selector=Cert(0) means that
there is an implied relationship with the embedded CA.... even if that
information is subsequently ignored.
The "Compatible with RFC 7250 raw public keys" could win me over
though...
--
Mark James ELKINS - Posix Systems - (South) Africa
mje@??? Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
