On Wed, 6 Mar 2013, Viktor Dukhovni wrote:
That creates a "certificate" with just the SubjectPublicKeyInfo blob.
I welcome postfix to be an early adopter of that draft :)
This is very unlikely to be implemented in Postfix. It is predicated
on an API change in OpenSSL to allow it to return bare public keys
for the peer certificate. Users will still need to generate and
configure X.509 certificates, and there is very little upside for
this proposal in existing applications that don't start life as
public-key only TLS applications.
Why are you suddenly switching the argument? If you want a protocol that
is not encumbered by obsolete X509 mappings, you're going to need
some API changes.
For the forseeable future, it is much more practical to just create
minimal certificates that essentially consist of just the public
key. With ECDSA and SHA256 the DER cert is just 275 bytes vs. 91
bytes for the associated public key. While an extra 184 (less
overhead for the new extension) bytes on the wire could be avoided
it sure is a lot of new code in libraries and applications to save
a small amount of extra packet payload.
Size was not the problem you were talking about. Problem was the
conflicting information between certificate content and DNS bindings
to name, ttl etc. This draft enables you a valid way out of your issue.
Neither one of us was talking about packet size or code size.
If you don't want conflicting X509 information in DNS, then the best way
out is to not have that information in the X509 certificate.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
