Support for naked keys is useful. Lack of support for certificates where needed would be unacceptable and render the format unsuited for many of the applications we need it for.
Certificates are pretty simple to deal with. The problems that they are used to address are not simple. Whatever you thought of the 'Trust Router' proposal made at last IETF, it is certainly no simpler than the PKI based approach and that is before they have put it in operation and found the operational requirements. For my application I need certificates and will use them. The question then is not whether the spec will use them, it is whether the way in which they are used is standardized or not. On Fri, Aug 5, 2011 at 12:34 AM, Joe Hildebrand <[email protected]>wrote: > On 8/4/11 4:48 PM, "Hal Lockhart" <[email protected]> wrote: > > >> 3) A Standards Track document specifying how to encode public > >> keys as JSON-structured objects. > >> > > > > I would like to push back on the idea of only supporting naked public > keys. It > > is my understanding that common cryto libraries, e.g. OpenSSL, expect > public > > keys to be in certificates and the coding to get them to accept a naked > key as > > input is ugly. I don't think they care if the cert is self signed or even > > signed at all, its just a format issue. > > Just doing the math yourself, from scratch, is pretty easy if you have the > bare key. It's nigh-on trivial if you have a bigint library. Solution: > don't use OpenSSL. I propose we don't get bogged down in the certificate > problem for the moment. > > -- > Joe Hildebrand > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes > -- Website: http://hallambaker.com/
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
