[Remote CryptoKeys] Various questions and feedback

[twiss]

Hi! Here are some thoughts and suggestions on the “remote” CryptoKeys explainer.

First of all, as an aside, I wanted to mention that there is an old proposal for key discovery in Web Crypto. To my knowledge it was never implemented, and I assume it doesn't meet your needs, but it may serve as an inspiration for the spec, and I think there are some differences that would be good to copy here, more on which below.

First, some high-level questions:

• The high-level proposal seems to imply that the key is only queried when you actually try to use the CryptoKey object returned by getRemoteKey, but the description of getRemoteKey does describe querying for a key and throwing NotFoundError if none is found. Which is intended? (I think the latter seems more useful, so that the application knows as soon as possible whether it has a key it can use.)
• Is there any intention to allow generating a key via this API? The proposal doesn't explicitly mention it, but the UI could offer to generate a key, if the user doesn't have one?
• Is there any intention to allow querying or generating two keys at once, for example both a signing and encryption key? It would seem onerous to make the user go through the UI flow twice. Or perhaps the access control and user consent parts could be cached, at least?
• Taking a step back to the use case of email, for example, is the browser expected to manage S/MIME and/or OpenPGP certificates that it returns a handle to the key material for here, or is the application expected to construct a certificate using the key returned here?

Then, some more low-level nitpicks:

• I think it would make the most sense to define a interface RemoteKey : Key, and put the remote-key-specific fields on the key directly, rather than on the algorithm, and leave the algorithm field intact, since the format of the key material differs per algorithm, so a given key can't be used with any algorithm.
• Similarly, for requesting a remote key, I wouldn't let RemoteKeyParams extend Algorithm, and only include the params that can be used to query a key (i.e. remove expiresAt, presumably). Also, name: "remote" seems redundant, and it would seem useful to me to also (separately) pass the algorithm that the application wants a key for? Otherwise, the browser doesn't know what kind of key to query (or generate).
  • Alternatively, if you want to be able to query any type of key, it becomes even more important to have the remoteKey.algorithm.name indicate the algorithm that the key is intended to be used with (since the parameters required to use the key differ per algorithm). But, doing it that way also seems risky because the application would need to have support for all algorithms that the key's intended algorithm could possibly be. So it would seem better to me to allow passing the (list of?) algorithm(s) that the application supports.
• Finally, a naming nitpick: "remote keys" sounds a bit scary, as if they're stored on a server or so. Perhaps "user keys" would sound more friendly? That would also nicely align with UserKey having a userIdentifier property, for example.

[estark37]

Is there any intention to allow generating a key via this API? The proposal doesn't explicitly mention it, but the UI could offer to generate a key, if the user doesn't have one?

Somewhat related to this, the Security & Privacy Considerations section says that keys should be domain-scoped (though I imagine that should rather be origin-scoped), but it's not clear how this would be accomplished for pre-existing keys, and there's no specified way to generate keys. In other words, how do we determine the origin that a key belongs to, if it wasn't generated by the browser on behalf of a particular origin?

[jonchoukroun]

Thanks for the feedback @twiss and @estark37.

• The getRemoteKey method would be required to get the CryptoKey handle. This means the calling web app will know quickly whether it has a key or not.
• We should further discuss whether this API should support key and certificate generation, and other PKI functions. We omitted support to mitigate against a malicious web app using this API to create a tracking certificate/super cookie. However knowing that a number of email providers are web-only, we should further discuss supporting key/cert generation - while preserving user privacy - in a way that can be enforced by the spec as part of the incubation process.
• The intention is for all keys used by this API to be origin-scoped, however it’s still open for debate how we should enforce that in the spec. Is it enough for the spec to recommend implementers require that keys are origin-scoped and perform a validation?

[twiss]

The intention is for all keys used by this API to be origin-scoped, however it’s still open for debate how we should enforce that in the spec. Is it enough for the spec to recommend implementers require that keys are origin-scoped and perform a validation?

Do you mean that, if the user has an S/MIME certificate for alice@example.com, they can only access the key from https://example.com?

I worry that it wouldn't be super useful because you might have a mail app on mail.example.com serving email for @example.com, or even for entirely different domains (if the user uses their own custom domain, for example).

So I think it would be more useful if the app could request the key for any S/MIME certificate; if the user gives permission for that, of course. Perhaps the permission could be dependent on the app being selected as the user's email client / mailto: handler, or something like that? (Of course that would make it very email-specific, but some parts of the proposed API already seem somewhat email-specific to me, TBH, so maybe that's OK?)