On Sat, Oct 11, 2014 at 12:13:29PM +0200, Mark Elkins wrote:
> > > I'm unsure of the middle digit...
> > > 0 = Full certificate
> > > 1 = SubjectPublicKeyInfo
> > > ... doesn't mean very much to me.
For the record the "middle" field is called the "selector". We're
discussing the difference between (acronyms per
<
http://tools.ietf.org/html/rfc7218>):
|-----------------------------------------------------------------|
| Certificate Usage | Selector | Matching Type | Association Data |
|-----------------------------------------------------------------|
| DANE-EE(3) | Cert(0) | SHA2-256(1) | {cert digest} |
|-----------------------------------------------------------------|
| DANE-EE(3) | SPKI(1) | SHA2-256(1) | {pkey digest} |
|-----------------------------------------------------------------|
The selector value Cert(0) indicates that the digest of the DER
ASN.1 certificate encoding appears in the association data field
which is hex-encoded in zone file presentation format, and is just
the corresponding raw binary data on the wire.
The selector value SPKI(1) indicates that the digest of the public
key (specifically the DER encoded SubjectPublicKeyInfo structure
that combines the algorithm, any parameters and the public key
bitstring) appears in the association data field.
> > $ openssl x509 -in cert.pem -noout -pubkey |
> > openssl pkey -pubin -outform DER |
> > openssl dgst -sha256 |
> > awk '{printf "IN TLSA 3 1 1 %s\n", $NF}'
>
> So the code "openssl x509 -noout -pubkey | openssl pkey -pubin" selects
> just the Public Key portion.
Correct.
> 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.
> At least I now understand the purpose/effect for the "Matching Type"
> middle digit.
The "middle digit" is the "Selector".
--
Viktor.
