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

Hi Ryan,

Apologies in advance for making a comment without fully catching up on the
thread.

I don't have a strong opinion about which information needed to perform
some operation should be a property of the Key and which should be
specified with the operation. You have a point that if something is not
considered a property of the key in some existing crypto API that might be
used as the back end for WebCrypto *and* that might discover keys of its
own, then its problematic if that is considered a property of the Key in
WebCrypto (we would have to provide a way within the discovery API to
attach those necessary properties to make it into a well-formed WebCrypto
Key).

But still, the existing API is extremely confusing in not at least making a
distinction between things that are immutable properties of the Key and
things that are specified when performing an operation. This was a
considerable source of confusion for several devs on our side working with
the API and I fail to see any sensible reason for not trying to address
that confusion.

Either something is an immutable property of the key and MUST be specified
explicitly or implicitly at key generation/derivation time, or it is not.
I'd suggest that those things that are not immutable properties of a Key
SHALL NOT be specified at key generation/derivation time and there should
be some clear specification of what falls into which category.

I could understand a desire *as a convenience* to allow the programmer to
attach a set of operation parameter values to a key so that they do not
need to be repeated on every operation call. I could believe that for some
parameters there may even be implementation optimizations which could be
done because it is known that the same value will be used many times. But
this should be a clearly separate mechanism from that used to define the
immutable properties at key generation/derivation time. Such convenience
properties would be mutable anyway. And having to repeat any of the
immutable properties at operation time is totally redundant. Repeating the
algorithm name makes no more sense than repeating the key length and I
don't buy that there is some significant internal optimization that comes
from processing the arguments of the operation (other than the Key) before
processing the Key object itself.

None of the above is arguing for particular parameters to be in one
category or another. The request is only that we be clear and treat
different things differently in order to make the API easier to understand.

...Mark


On Thu, Jul 18, 2013 at 6:34 PM, Ryan Sleevi <sleevi@google.com> wrote:

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