This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The methods of the subtleCrypto interface (encrypt, decrypt, importKey, exportKey etc.) are distinct from the operations defined for each algorithm. Also there is not a 1-1 mapping between methods and operations (e.g. wrapKey method makes use of the export key and wrap key operations). However, the names used in the registration tables for each algorithm align more closely with the method names than with the operation names used in the method descriptions and the operations section of each algorithm. We should explicitly list the possible operations and align the names in the registration tables. The operations are: - encrypt - decrypt - sign - verify - derive key - derive bits - wrap key - unwrap key - import key - export key
I wonder if we should go further and rename some of the operation to emphasize this difference: derive bits -> derive secret wrap key -> wrap unwrap key -> unwrap import key -> import export key -> export
This is a continuing source of confusion. For example, there is no longer a derive key operation. The deriveKey *method* procedures say "call the derive bits operation for the derivation algorithm then feed the result into import key for the target key algorithm". In fact it only makes sense for the derivation algorithm to go as far as deriving the raw bits. The process of importing raw bits into a key object for *another algorithm* is a function of that other algorithm. But when looking at the supported operation tables, the fact that derive Key is missing for things like DH generates confusion because this distinction between methods and operations is not properly described. Any opinions on this ? Should I make a more concrete proposal to resolve this ?
(In reply to Mark Watson from comment #4) > This is a continuing source of confusion. > > For example, there is no longer a derive key operation. The deriveKey > *method* procedures say "call the derive bits operation for the derivation > algorithm then feed the result into import key for the target key algorithm". > > In fact it only makes sense for the derivation algorithm to go as far as > deriving the raw bits. The process of importing raw bits into a key object > for *another algorithm* is a function of that other algorithm. I'm sorry, but I find this paragraph vastly more confusing than the one you have issue with. > > But when looking at the supported operation tables, the fact that derive Key > is missing for things like DH generates confusion because this distinction > between methods and operations is not properly described. > > Any opinions on this ? > > Should I make a more concrete proposal to resolve this ? I'm already working on resolving this as part of the TAG feedback, with respect to how algorithms are defined, their extensibility points, and the conceptual framework for interacting with them. I hope to have a concrete proposal up soon. However, because much of the feedback results in changes through multiple layers, I haven't pushed a change because it's not clear when viewed in piece-meal, and because I'm trying to ensure the spec is holistically updated, rather than in the bits and pieces that have led to the linguistic, stylistic, and functional inconsistency of the present spec.
That's great news. Would it be possible to send a summary of your general approach to the working group, so we can comment on that before invest too much in the details ?
I propose we address this together with 25625.
*** This bug has been marked as a duplicate of bug 25625 ***