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

On Fri, Jul 19, 2013 at 11:40 AM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Thursday, July 18, 2013 6:28 PM
>> To: Richard Barnes
>> Cc: public-webcrypto@w3.org Group
>> Subject: Re: ISSUE-12 / ACTION-83: Operation vs. Algorithm parameters
>>
>> Note, to circle back on this:
>>
>>
>> On Fri, Jun 7, 2013 at 1:13 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> > [Moving over to public-webcrypto, since I think that's where this
>> > should be.]
>> >
>> > On Jun 7, 2013, at 2:53 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.
>> >
>> > When you sit down to write generateKey/importKey, you need to figure out
>> how to populate the fields in the Key interface based on the arguments
> listed
>> in the spec.  That raises the question of what value to assign to
>> "key.algorithm".  The only plausible choice is from the "algorithm"
> parameter,
>> but that's got things like modulusLength that you don't necessarily want
> to
>> keep around, because they don't really match the semantic of
> "key.algorithm"
>> (namely "What can this key do?").
>>
>> There's no other way to inquire about the keys modulusLength EXCEPT
>> through key.algorithm. And it's entirely reasonable to want to know that
> at a
>> later point - eg: is this a 1024-bit key or a 2048-bit key.
>> Especially when you factor in named key discovery or key agility, you may
>> wish to say "Well, I have a 1024-bit key, but I want to replace it with a
> 2048-bit
>> key" or "This key is too small for this security guarantee - let's create
> a new
>> one"
>>
>> So yes, I think (as you noted originally) we'd have to key generation
>> parameters attached to the Key, in addition to what you term as the
> algorithm
>> parameters. So I don't really buy the 'savings' argument here.
>>
>>
>> >
>> > (I tried to find the right citation in the spec, but
>> > generateKey/importKey are underspecified right now.)
>> >
>> >
>> >>> Second, it has to compare type (2) and type (3) identifiers, e.g.,
> ignoring
>> operation parameters like "iv".
>> >>
>> >> Can you clarify when or why?
>> >
>> > The only point to having key scoping with key.algorithm is if it's
> enforced by
>> the API.  So when an algorithm is invoked, the implementation of, say,
>> encrypt() needs to compare key.algorithm with the algorithm parameter
>> provided in the method call.
>>
>> I'm not 100% in agreement with you here.
>>
>> First, on the implementation side, yes, there will always be an implicit
>> comparison, because library keys of Alg X can only be used with Alg X in
>> practice.
>>
>> Second, I agree, that the algorithm-specific operation descriptions
>> (eg: the flow for decrypt) are not fully clear on making a *standard*
>> comparison, so I agree, it needs to be added.
>>
>> That said, both objects are dictionaries - There's no requirement for a
> strict
>> equality check here, this is just good ol 'duck typing'. Even when we fix
>> key.algorithm to be an Interface, rather than a Dictionary, it still
> matches the
>> Dictionary requirements.
>>
>> Practically speaking, I anticipate the only comparisons being
>> Norm(operation.algorithm).name == Norm(key.algorithm).name.
>>
>
>
> Just to be clear - An HMAC key would be independent of the included hash
> algorithm.    And tainting would never be included in comparisons then.   I
> don't know that this is wrong, but I am not sure it is right either.
>

That's not now PKCS#11 works, which is why, when describing the HMAC
algorithm, I described it the way I did (where hash is part of the key
generation

Each HMAC+Hash algorithm is a distinct mechanism and may or may not be
supported by the underlying implementation (eg: an implementation may
support HMAC-SHA1 and SHA-256, but not HMAC-SHA256.)

Received on Friday, 19 July 2013 19:00:08 UTC