Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

[Phillip Hallam-Baker <[e-mail]>]

Question: What exactly is a 'raw key' in any case?

Anything that the group does is going to require some commitment to a
specific serialization of the key information. A public key is an abstract
data structure and you can't put an abstract structure on the wire. There
has to be some mapping from the abstract structure to the bits.


Eric and myself are not trying to be difficult here. OK, I can't speak for
Eric, maybe he is. But we have both tried to do what is being presented as
the 'easy' case and it wasn't.

Raw key can simplify things if offered as an option. If it is the only
option it is going to make things harder, not easier in my view.



On Fri, Aug 5, 2011 at 10:07 AM, Eric Rescorla <[e-mail]> wrote:

> On Thu, Aug 4, 2011 at 9:34 PM, Joe Hildebrand <[e-mail]>
> wrote:
> > On 8/4/11 4:48 PM, "Hal Lockhart" <[e-mail]> 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.
>
> Cryptographer's warning: do not do this. Hard hat area ahead.
>
> -Ekr
> _______________________________________________
> woes mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/woes
>



-- 
Website: http://hallambaker.com/