On Wed, Mar 06, 2013 at 02:47:01PM -0500, Paul Wouters wrote:
> >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.
I don't want to *depend* on complex certificate properties for
security. Their presence in the certificate does not bother me.
If I match a peer by the certificate or public key digest, ignoring
all extensions, names, ... I don't really care whether that key
was encapsulated inside an ASN.1 sequence of some additional useless
information.
Changing the Postfix code to depend as yet unreleased OpenSSL APIs
that users won't have for a long time, and TLS extensions that
may trigger interoperability problems just does not look that appealing.
> >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.
There is no conflicting information when the content of the
certificate (other than perhaps the public key) is simply ignored.
All I see is a pile of bits.
Sorry if this is disappointing, but for now the cost/benefit
ratio for oob-pubkey is too high.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
