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

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Friday, July 19, 2013 12:00 PM
> To: Jim Schaad
> Cc: Richard Barnes; public-webcrypto@w3.org
> Subject: 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.)

But does this not imply that you are going to compare more than just the
algorithm name for equality?

Received on Saturday, 20 July 2013 14:04:52 UTC