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 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.
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).
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.
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)
So, about the content of the API itself :
- why does the CryptoKeyPair dictionnary associate a salt and an iv with
the key pair ?
- Actually I don't see CryptoKeyPair and CryptoConfiguration be actually
used anywhere
- why doesn't the getPublicKey function have any argument ? Is the
callback called once for every public key that is available ?
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.
- 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. 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 ?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
