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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
