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

On Sat, Jun 8, 2013 at 1:40 AM, Mark Watson <watsonm@netflix.com> wrote:
> 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 ?
>

Sure.

In PKCS#11, AES-GCM, tagLength is not a property of the key, but of
the operation.
In PKCS#11, RSA-OAEP, hash is not a property of the key, but of the operation.
  - We've talked about making it a property of the key, it in the
context of key tainting, but there was continued objection to
mandatory tainting, which this introduces.
In PKCS#11, RSASSA-PKCS1-v1_5, hash is not a property of the key, but
of the operation.
In PKCS#11, RSA-PSS, hash/saltLength are not properties of the key,
but of the operation.
In PKCS#11, ECDSA, hash is not a property of the key, but of the operation.

The only place that IS a property of the key seems to be the hash for
HMAC - which is a point of discussion for PKCS#11 v2.4++, but not yet
resolved.

So when we talk about exposing pre-existing keys - which has been a
key point of concern for members of the smart card community -
adopting the distinctions that Richard proposes would effectively
prohibit them, because such parameters could not be inferred from the
existing key objects that exist.

In all of these cases, explicitly specifying them during the operation
avoids any ambiguities of how to synthesize them, regardless of the
underlying implementation or key storage.

Really, the only thing that can be inferred is the .name property, and
I'm not sure the savings is really there. As mentioned in my reply to
Richard, it adds extra overhead for implementations, by virtue of
needing to inspect into the key earlier in processing (during the
normalization phase - which is synchronous, ergo bad). For the end
user, it seems to hinder readability by creating confusion about what
operation will be performed.

Received on Friday, 19 July 2013 01:35:20 UTC