RE: AES-GCM Algorithm is missing tag properties for input params and result value

Mike,

Can you explain why?
On May 9, 2013 10:09 PM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

>   JOSE decided to keep the tag separate and not use RFC 5116. I think we
> should too.
>
> -- Mike
>
>  ------------------------------
> From: Ryan Sleevi
> Sent: 5/9/2013 5:36 PM
> To: Israel Hilerio
> Cc: public-webcrypto@w3.org; Marcin Stankiewicz
> Subject: Re: AES-GCM Algorithm is missing tag properties for input params
> and  result value
>
>  On Thu, May 9, 2013 at 5:13 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Another piece of feedback we provided during the F2F was that the input
> parameters for AES-GCM need a tag property and the result value for AES-GCM
> needs to contain a tag parameter in addition to the ciphertext.
> >
> > This implies that we'll need to update the AesGcmParams dictionary the
> following way:
> >
> > dictionary AesGcmParams : Algorithm {
> >   // The initialization vector to use. May be up to 2^56 bytes long.
> >   ArrayBufferView? iv;
> >   // The additional authentication data to include.
> >   ArrayBufferView? additionalData;
> >   // The desired length of the authentication tag. May be 0 - 128.
> >   [EnforceRange] octet? tagLength;
> >
> >
> >   // The authentication tag value for decryption
> >   ArrayBufferView? tag;
> >
> >
> > };
>
> If we go this route, I would rather see two dictionaries, so that it
> can be unambiguous that tag is required for decrypt, but not for
> encrypt.
>
> >
> > This changes will impact section 20.12.3 of the spec.
> >
> > In addition, since we can't return dictionaries I was thinking we could
> add a new interface:
> >
> > interface AesGcmResult {
> >         readonly attribute ArrayBuffer? tag;
> >         readonly attribute ArrayBuffer ciphertext;
> > }
> >
> > This will impact the result values of section 20.12 AES-GCM registration
> table. We'll have to return this new interface for encrypt only.
> Alternatively, we could return it also for decrypt with the tag value being
> null or set from the input parameter.
>
> Agreed on this affecting encrypt only.
>
> >
> > Let us know what you think.
> >
> > Thanks,
> >
> > Israel
> >
> >
>
> I seem to recall some discussion/debate about whether or not it should
> follow the mode of RFC5116/PKCS#11 and treat the tag as a suffix of
> the ciphertext. I believe Richard was a proponent of this, and that
> certainly reflects the 'intent' of the current spec (although, as we
> both noted - presently woefully underspecified)
>
> The benefit of that is similar to those benefits expounded upon in
> RFC5116 - it treats AEAD encryption using a consistent interface as
> non-authenticated encryption, at least in terms of inputs/outputs.
>
> I'm curious for the arguments for splitting them up, since we did not
> have sufficient time during the F2F to discuss this point. Is there a
> technical advantage, or is this for syntactic purposes?
>
>