- From: Richard Barnes <rbarnes@bbn.com>
- Date: Wed, 3 Jul 2013 18:57:52 -0400
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Yoshi Huang <allstars.chh@mozilla.com>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On Jul 3, 2013, at 6:38 PM, Ryan Sleevi <sleevi@google.com> wrote: > On Wed, Jul 3, 2013 at 3:25 PM, Richard Barnes <rbarnes@bbn.com> wrote: >> Ryan, >> >> I'm not sure I disagree with you, but I have to call you out for trying to inflict PKCS#12-in-JS on poor web developers when it's already in the browser :) > > It is entirely consistent with trying to avoid introducing > application-layer protocols - especially those as poorly spec'd and as > widely divergent in conformance as PKCS#12. > > There's little hope for spec-based interop on a standard like that. > >> >> Trying to avoid having the browser support PKCS#12 seems like a funny thing to do, since the major browsers already have PKCS#12 libraries. > > No, they don't. IE and Firefox do, at least. I don't know about others off the top of my head. >> And I can say from experience that PKCS#12 is really horrendous to do in JS, much less in an interoperable way. I've been unable so far to get the Forge P12 library to work with anything by IE [1]. Not to mention that the library is >1000 lines of JS, not including the DER parser [2]. > > That's because PKCS#12 itself is really horrendous to do. > > Let's be clear here, the fundamental question is PKCS#8 > EncryptedPrivateKeyInfo - even if EPKI was supported, I would still > object to including "PKCS#12" - for the same reasons I object to high > level certificate abstractions. > >> >> I'm a little split on this issue. It seems like good security practice in general not to have private keys exposed outside the browser envelope, and having the browser do PKCS#12 / EncryptedPrivateKeyInfo seems consistent with current practice w.r.t. client certificates. > > I have no idea what you mean "w.r.t client certificates" All I meant was that, e.g., Firefox and IE both support import/export of PKCS#12, so that the stuff they hand the user is safe. --Richard > Naturally, I see the security boundary as being the "browser and web > application", just like existing cryptographic APIs rely on the > calling application to use them correctly (c.f. PKCS#11 and > CryptoAPI/CNG) > >> But it also seems like it would be difficult to specify an interoperable function based on those containers, without specifying a profile to constrain down some of the options. > > A vast undertaking in and of itself that is functionally akin to > tilting at windmills in the grand scheme of things. > >> >> --Richard >> >> >> [1] <http://demo.polycrypt.net/x509/> >> [2] <https://github.com/digitalbazaar/forge/blob/master/js/pkcs12.js> >> >> >> >> >> On Jul 3, 2013, at 12:41 AM, Ryan Sleevi <sleevi@google.com> wrote: >> >>> SPKI is Subject*Public*KeyInfo, so no. >>> >>> PKCS#12 just holds PKCS#8 key blobs. So you would write your own PKCS#12 parser to read the different bags, then import the decrypted PKCS#8 key. >>> >>> The goal is to avoid requiring the UA to support PKCS#12 natively, much in the same way it tries to avoid requiring JWE support or any other key transport specific protocols. Do that in content, not the UA, same as you do today with existing APIs. >>> >>> On Jul 2, 2013 9:30 PM, "Yoshi Huang" <allstars.chh@mozilla.com> wrote: >>> Hi Ryan, >>> >>> Sorry for not asking question clearly. >>> >>> The keys could be encrypted pkcs8 or pkcs12 >>> Also does the 'spki' in KeyFormat includes pkcs12 ? >>> >>> And thanks for your detail explanation. >>> >>> >>> On 07/03/2013 01:55 AM, Ryan Sleevi wrote: >>> Could you explain which keys you're thinking of? >>> >>> The spec indicates that "pkcs8" is a PrivateKeyInfo, not an >>> EncryptedPrivateKeyInfo, from RFC 5208. >>> >>> If you had a passphrase protected EncryptedPrivateKeyInfo, you would >>> do the same thing you do in other APIs - you would prompt the user for >>> the passphrase, apply it through PBKDF to derive the key, then decrypt >>> the PrivateKeyInfo to be able to import it. >>> >>> This is the same workflow for the JWE-protected JWK, which is that the >>> API tries to avoid baking in knowledge of specific protocols or >>> higher-level key formats (whether CMS or JOSE), and instead focus on >>> primitives and the security boundary therein. This has been quite >>> suitable for a variety of well-used, long successful APIs. >>> >>> >>> -- >>> Yoshi Huang, Mozilla Taiwan >>> allstars.chh@mozilla.com >>> >>
Received on Wednesday, 3 July 2013 22:58:21 UTC