On Tue, 5 Mar 2013, Viktor Dukhovni wrote:
Not all applications understand wildcard certificates, or even
correctly parse certificate content.
When the Moxie Marlinspike embedded NUL attack on CA name bindings
was published, Postfix was one the few applications not impacted,
since I already anticipated this problem and Postfix already had
checks for embedded NULs in ASN.1 strings.
The moral of this anecdote is not that the Postfix developers go
the extra mile, but rather that X.509 is a very complex standard
with many pitfalls, and anything that makes the application's job
easier is a big win.
The easiest way to check that you have the right certificate is to
not parse it at all, or parse it just enough to extract the public
key (this is generally directly supported by the SSL toolkit), and
then just compare that or a digest of it to the value bound by DANE.
The simplicity of the DANE binding leaves PKIX with its horde of
trust anchors, local versions of intermediate certs, servers that
fail to present all intermediate certs, depth limits, expiration
date arithmetic, name constraints, multitudes of name types,
critical extensions, ... in the dust.
While I agree with most, the future to do this right is to use TLS with
raw public keys:
http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07
That creates a "certificate" with just the SubjectPublicKeyInfo blob.
I welcome postfix to be an early adopter of that draft :)
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
