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

On Fri, Jun 7, 2013 at 8:01 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> 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".

Can you clarify how you arrived at this interpretation? The spec
doesn't say one way or the other, so I'm curious the thinking.

>  Second, it has to compare type (2) and type (3) identifiers, e.g., ignoring operation parameters like "iv".

Can you clarify when or why?

>
> 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.
>

Richard,

Thanks for attempting to take the time to do this. However, it seems
that you didn't take into consideration the concerns I raised during
the face to face and the previous calls that explained the design
rationale behind this.

The current choice of specification was very intentional, based around
the limitations and designs of a number of APIs. Quite simply, a
number of underlying cryptographic libraries do not support what you
propose - most notably, PKCS#11 - and instead require much more
specification up front.

Now we can debate whether we're designing for the past or for the
future, but I would suspect that if the Web Crypto API requires new
platform cryptographic APIs to be developed, then the entire value of
this API is lost (namely, being able to use existing, validated,
approved-by-various-government APIs and implementations - and to keep
browsers OUT of the crypto game).

I'm all for reducing friction, but I want to make sure we recognize
the limitations in the design space.



>
> 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 18:54:06 UTC