ISSUE-12 / ACTION-83: Operation vs. Algorithm parameters

Dear WebCrypto group,

Vijay and I took an action at the F2F to look into resolving the current ambiguity around algorithm identifiers and parameters.  
<http://www.w3.org/2012/webcrypto/track/actions/83>
<http://www.w3.org/2012/webcrypto/track/issues/12>
Some analysis and a proposal are below.  Comments welcome!

Thanks,
--Richard


PROBLEM STATEMENT
=================

Currently, the AlgorithmIdentifier structure appears in three places in the API, with slightly different flavors and semantics.
1. As an input to key creation (generate / import / derive)
2. As an output of key creation (as key.algorithm)
3. As an input to crypto operations

That means that the API implementation has two difficult jobs.  First, it has to translate type (1) identifiers to type (2) identifiers, e.g., by removing generation parameters like "modulusLength".  Second, it has to compare type (2) and type (3) identifiers, e.g., ignoring operation parameters like "iv".  

There aren't any algorithms defined for these transformations and comparisons, so the result is developer confusion.  (I've actually gotten more than one phone call.)


ANALYSIS
========

It seems like there are three types of parameters running around here:

* Algorithm Parameters  - Things you want to be fixed for the life of a key
* Operation Parameters  - Things that may vary over the lifetime of a key
* Generation parameters - Things that cannot be changed without making a new key

A first pass at a taxonomy of parameters is in a Google Spreadsheet here:
<https://docs.google.com/a/ipv.sx/spreadsheet/ccc?key=0AvGS_cx3xHzXdHhhZExqOEg2NktJai1Ccnc2RUhicEE&usp=sharing>

The algorithm parameters really identify the algorithm itself -- the thing that you want to check when you're doing an operation.  Conversely, the operation parameters are the things you want to ignore in that check.  Likewise, the generation parameters are the things that you don't need to keep in the algorithm identifier after key generation.

It's worth noting that these concepts are important mainly for encryption, signing, and MAC.  They don't matter much for digest or KDF algorithms, so we might handle those differently.


PROPOSAL
========

At a high level:
1. Split out operation and generation parameteres from algorithm parameters
2. Instead of specifying an algorithm in the CryptoOperation methods, specify key + operation parameters
3. In addition to specifying an algorithm at key generation time, specify algorithm + generation parameters

This resolves the two ambiguities noted above.  At key generation time, the algorithm is copied straight through to the key, while the generation parameters are discarded.  At operation time, the algorithm is drawn from the key, and the operation parameters specified in the method call.

As a bonus, this also adds some clarify the other methods for creating Key objects, deriveKey and importKey.  In those cases, you're not generating the key, so you just have to specify the algorithm.

We might also consider exposing the generation parameters on keys.  That would allow applications to query a Key object for its properties after it's been generated ("How long is this RSA key?").  Applications could keep track of this information on their own, but incorporating it in the Key object would be simple for the API code, and would save apps the bookkeeping.   If we do expose this information, it seems like it should be as a separate property from "algorithm".

Received on Friday, 7 June 2013 15:02:12 UTC