On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:
Question: What exactly is a 'raw key' in any case?

I believe the people that want this are trying to avoid X.509. I'd bet a $1 it won't end up just being the 'raw key' there's going to be parameters, etc. If you look at what Mike's proposing in http://datatracker.ietf.org/doc/draft-jones-json-web-key/ which I believe is one draft on offer as input, it already includes more than just the key - as it should.

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.

I have never assumed that the charter item for a 'raw key' implied that it was *the* way to convey the public key in the resulting JSON-structures for signatures/encryption. I have always assumed there would be some faction that would want an option to refer to|point to|include a certificate.

We can fight about what the required mechanism is when we actually write the spec. I've gotten the impression that regardless of the choice that wins a 'bare key' JSON format is needed - hence the charter item.

spt

On Fri, Aug 5, 2011 at 10:07 AM, Eric Rescorla <e...@rtfm.com
<mailto:e...@rtfm.com>> wrote:

    On Thu, Aug 4, 2011 at 9:34 PM, Joe Hildebrand
    <joe.hildebr...@webex.com <mailto:joe.hildebr...@webex.com>> wrote:
     > On 8/4/11 4:48 PM, "Hal Lockhart" <hal.lockh...@oracle.com
    <mailto:hal.lockh...@oracle.com>> 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
    woes@ietf.org <mailto:woes@ietf.org>
    https://www.ietf.org/mailman/listinfo/woes




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



_______________________________________________
woes mailing list
woes@ietf.org
https://www.ietf.org/mailman/listinfo/woes
_______________________________________________
woes mailing list
woes@ietf.org
https://www.ietf.org/mailman/listinfo/woes

Reply via email to