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

Sent from my iPhone

On Jun 7, 2013, at 7:54 PM, Ryan Sleevi <sleevi@google.com> wrote:

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

I don't understand this objection, because the proposal doesn't change
what information is available at what times to the WebCrypto
implementation.

Ryan, can you give an example of how PKCS#11 doesn't support what
Richard proposes ?

>
> 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 Saturday, 8 June 2013 08:41:06 UTC