----- Original Message ----- > From: "Jean-Marc Desperrier" <jmd...@gmail.com> > To: mozilla-dev-tech-cry...@lists.mozilla.org > Sent: Friday, June 17, 2011 8:31:03 AM > Subject: Re: DOMCrypt API developments > David Dahl wrote: > >> I find this API effort very interesting, however I'm left with the > >> > feeling you wish to leave out the use of PKI elements. > >> > A really neutral API would work both with and without PKI. > > Public Key crypto is actually the main use case of this API. > > I meant more certificate/X509 based PKI, and I've reached the > conclusion > that's very certainly *not* the main use case of this API. > The webcrypto-api proposal is oriented around > certificate/X509/smartcard > PKI, I end up with the feeling the two proposal lives in different > realms. > I am not sure what the webcrypto-api is. I am not working on any way to interface with smart cards - merely a browser API for public Key and symmetric crypto, etc. This is meant to be very general purpose, and high-level.
> I think the most important part to understand the context of your > proposal is the phrase in the notes that says : > "Each origin will only have access to the asymmetric private key > generated for it." > So this is a low level API that allows a web application to do > anything > either useful or stupid with the keys it generates, based on the fact > it > will only access it's own keys, and if it does something stupid, it > will > not affect any other application. > > You should modify the proposal to say this first, so that people get > the > context easily. Ah, yes. I will do that. The private keys are not actually available to the API in the sense that they can be handled by the web developer in any way. They are used behind the scenes by the chrome-priv code only - in the prototype. Any production code in browser will use the proper NSS handling of the keypair. > > One question is left of what should be the security level of the > private > key. Is it allowed to create them in a HTTP origin ? > For HTTPS origin, what happens if the user clicks yes to connect to an > invalid server, does it have access to data already created for the > origin it claims to have that isn't validated ? Whilst we're at it, > what > happens when the server certificate change ? > One solution can be to keep it simple and have exactly the same level > of > security as for local storage, so in effect storing the private keys > inside local storage (explicitly or implicitly). I think the private keys will live inside the NSS database, well secured and not handled as strings at all. As far as access control with http vs. https - a policy will have to be established. > > This context also means that application need to implement a lot of > things above that low level API to do something significant. For > exemple > in the API the keys for example have no identifier, no context of use > (signature, encryption), no time limit, etc. A smart default time limit and ID should be set when the keys are created. I figured the host or domain name might be a good identifier for the keypair. these details still need to be hashed out. > > Given all that, I wonder if an API that gives directly to a low level, > optimised big num API (with random) wouldn't be a simple, bare metal > but > effective, alternative ? (knowing that the approach *can't* be applied > to smartcards where you *need* the people who are allowed to access > the > smartcard to not do something stupid) I think a high-level easy to use API is the best starting point for this work. > > So, about the content of the API itself : > - why does the CryptoKeyPair dictionnary associate a salt and an iv > with > the key pair ? that is from the original implementation, and will be removed. > - why doesn't the getPublicKey function have any argument ? Is the > callback called once for every public key that is available ? It should have only one argument, a callback function that hands off the public key: void getPublicKey(GetPublicKeyCallback callback); > If that's how it works, then the caller needs to associate each > DOMString pubKey to an identify, and store that somewhere separately. > As > each pubKey is unique, it should work, but it sounds a bit painful to > have nothing to help in the API. Key management will have to be up to the application developer for now. Again, starting small here and not trying to solve all PKI issues - if we did we would never ship anything. > - I think it'd be better if createHash had a streamable interface. > And probably also encrypt, decrypt. > - In effect PKCryptoMessage should be opaque (Even if it's useful to > see > that the process works given what PKCryptoMessage actually contains). > - HMAC use symetric keys, in the usual definition, so I'd expect a > symetric key argument to createHMAC. Then I'd expect some key argument > to verifyHMAC, or a return value of createHMAC that's more complex > than > a simple DOMString in order to store what's needed for verification. Ah, ok, I need to update this. The symkey argument can then be a base64 encoded, wrapped symmetric key. > The > interface looks simply broken in it's current state. > - How do users of the API know if a algorithm is accepted, which ones > are available ? I need to add the exceptions this API throws, that will cover major errors like wrong algorithm, etc. I will also add a list of accepted algorithms to the API. > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
