Re: [jose] JOSE WG request from W3C WebCrypto API

Mon, 20 Aug 2012 07:15:42 -0700
The rationale for having the encrypted keys were because I thought that the main use case were to transfer keys from one system to another, while it stays within a system, hopefully we can use platform supplied storage mechanism and key store.
That makes sense. In that case, I think it would make more sense to just use an existing encryption container like JWE with the public and private key structure as the payload. Or just use TLS. 




Now, your use case is different. You want to use the JWK private key 
stored in the local file system to sign or encrypt messages. For that, 
I agree it is turtles all the way. System implementers needs to be 
careful on how the process authentication is done when allowing the 
access to the key file is done though.



Yes, absolutely. But in our use case (service configuration) it's 
already being stored and protected in a place that houses other 
sensitive secrets, and it needs to be treated as sensitive just like the 
rest of them.


 -- Justin




On Aug 17, 2012, at 11:15 PM, Justin Richer <[email protected] 
<mailto:[email protected]>> wrote:




Nat, how would you store the private key that you encrypted the 
private key with? And what key would you use to encrypt your 
private-key-encrypter key? It's turtles all the way down, and not in 
a good way.



I personally really like having a parallel format to JWK for private 
keys, and I even asked (off list) for this feature about six months 
back. My use case was simple, and still valid: I have a server that 
takes in a configuration file with all kinds of already-sensitive 
information, like database passwords and admin user lists. I would 
love to be able to put my public and private keys in there without 
dropping to an ASN.1 structure. I realized that with JWK, I could 
store my public keys, but didn't have any place to put the private 
keys. At the time, we punted and went with a container-native 
certificate store with self-signed certificates, but this setup 
remains overkill and a bad fit for what we actually care about, the 
keys. But in order to get the keys, we had to generate a self-signed 
cert with a fake certificate authority and junk metadata just to fit 
the format. A JWK/JPK structure (to coin an acronym for the soup) 
would be able to handle this quite nicely, and it parallels what the 
WebCrypto WG is after, from what I gather. It would be fairly easy to 
add support for shared HMAC secrets in the same format as well.



However, I do agree with one point that was brought up: I don't 
necessarily like putting the two in the same structure. I think it's 
quite *functional* this way, but it seems like it could cause a 
problem like the private bits getting leaked. On the other hand, this 
feeling could be a case of premature intuition-based optimization 
[1], so I'm not sure how much credence to give it.


 -- Justin

[1] http://thesmithfam.org/blog/2011/02/06/how-to-optimize-your-code/


On 08/16/2012 10:26 PM, Nat Sakimura wrote:

Thanks Mike.


Would it not be a good idea to mandate that private key file must be 
encrypted? As far as I remember, one of the reason for not producing 
private key format was from the fear that developers leave the 
exported keys in a insecure manner.


Thoughts?

Nat


On Thu, Aug 16, 2012 at 8:19 AM, Mike Jones 
<[email protected] <mailto:[email protected]>> 
wrote:


    Thanks for writing, Harry and WebCrypto WG.

    1)  About private keys, given the WebCrypto use case, I
    personally think it would be valuable for JOSE to define a JSON
    private key representation.  To make this concrete, I would
    propose the private key representations specified in
    http://tools.ietf.org/html/draft-jones-jose-json-private-key.
     You'll see that doing this is very simple; it just defines two
    additional members for the JWK structure for representing the
    private parts of Elliptic Curve and RSA keys.  This could either
    remain a separate spec from JWK/JWA or be merged in, at the
    working group's preference.

    I had previously agreed with the position that it was not
    necessary for JOSE to define private key representations because
    we didn't have a use case for it.  However, as I see it, the W3C
    WebCrypto API use case changes things.  Better for JOSE to be
    responsive to WebCrypto and add this simple extension, either as
    a new spec or in the existing specs, than to leave this undone,
    and have it potentially be an area where otherwise
    standards-compliant implementations diverge, and where JSON-only
    solutions are not possible.

    Finally, I'll note that the JOSE charter
    http://datatracker.ietf.org/wg/jose/charter/ does not preclude
    defining private key formats.  (It simply requires the
    definition of public key formats and is silent on the topic of
    private keys.)

    2)  I agree on the likely need for WebCrypto support ASN.1 for
    backwards compatibility in some cases (just as the JOSE specs
    allow the use of X.509 certificates).  However, I believe it
    would be a shame to preclude JSON-only solutions by not
    supporting key import/export in JWK format, where such solutions
    make sense.

    3)  It appears to me the JWK format is stable.  I believe the
    JWS format is stable as well.  The JWE format has known changes
    that will be applied shortly, based upon working group
    discussions at IETF 84 in Vancouver two weeks ago.  Some JWA
    changes will occur that are part of the JWE changes.  I don't
    anticipate significant changes after that.  (Making these
    changes is my highest priority as JOSE editor.  I'm hoping to
    have drafts out containing them by the end of August, which
    hopefully fits well with the WebCrypto schedule.)  I write all
    of the above with the caveat that the working group is, of
    course, free to change things as they see fit.

    I look forward to a productive discussion of this coordination
    request in both working groups.

                                    Best wishes,
                                    -- Mike

    P.S.  If you prefer, a HTML-formatted version of the private key
    spec is available at
    http://self-issued.info/docs/draft-jones-jose-json-private-key.html.
     I also blogged about this draft specification at
    http://self-issued.info/?p=816.

    -----Original Message-----
    From: Harry Halpin [mailto:[email protected] <mailto:[email protected]>]
    Sent: Sunday, August 12, 2012 8:03 AM
    To: Jim Schaad; Karen O'Donoghue; [email protected]
    <mailto:[email protected]>; Mike Jones
    Subject: JOSE WG request from W3C WebCrypto API

    [cc'ing Mike Jones and Richard Barnes, who participate inboth WGs]

    JOSE Chairs,

    The Web Cryptography Working group has noted that the API
    requires some access to raw key material, and the issue of
    whether or not to use JWK or ASN.1 as the default format came
    up. Two issues have come out that we'd like to know the answer to:

    1) JWK does not define a private key format. Does the JOSE WG
    plan to support a JOSE-format for private keys? If so, when? Or
    'maybe'?

      2) While we'd like encourage the use of JOSE over ASN.1, it
    seems like for backwards compatibility having some level of
    ASN.1 support would be useful and we *need* a format that allows
    key material (both private and
    public) to be exported. Folks seem to leaning towards ASN.1 as a
    default format in the low-level API, and having JWK as a format
    that can be built on top of that in a possible high-level API.
    Would that be OK?

      3) How stable do you believe the JOSE formats are right now?
    Do you think they are stable enough now we can reference them in
    our API draft at end of August? If not, when?  The W3C would
    like to and plan to use these formats where possible.

    Feel free to forward this by JOSE WG for discussion. We'd like
    an answer before we send our document to FPWD at end of August.

      cheers,
          harry




    _______________________________________________
    jose mailing list
    [email protected] <mailto:[email protected]>
    https://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose





_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose























					Reply via email to