Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg

I was unaware of the ISO/IEC 9797-3 OID, which seems to allow any block cipher, and thus is not able to constrain the tag length based on the specifics of that block cipher.

Russ

> On Nov 13, 2020, at 1:42 PM, Jonathan Hammell <jfhamme.cccs@gmail.com> wrote:
> 
> I support adoption of this draft.
> 
> For reference, the ASN.1 module including GMAC in ISO/IEC 9797-3 specifies:
> is9797-3 OID ::= {iso standard message-authentication-codes(9797) part3(3)}
> id-gmac OID ::= {is9797-3 gmac(4)}
> GmacParameters ::= SEQUENCE {
>    bcAlgo BlockAlgorithms,
>    taglength INTEGER,
>    noncelength INTEGER
> }
> 
> where bcAlgo would specify AES-128, AES-192 or AES-256.  Matching
> other algorithms in 9797-3, the nonce is assumed to be transmitted
> separately.
> 
> However, I think the definition of GMACParameters in your I-D makes more sense.
> 
> Best regards,
> Jonathan
> 
> On Fri, Nov 13, 2020 at 9:12 AM Russ Housley <housley@vigilsec.com> wrote:
>> 
>> 
>> 
>>> On Nov 12, 2020, at 5:10 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>> 
>>> Signed PGP part
>>> 
>>> Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org> wrote:
>>>> https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt
>>> 
>>> 
>>> 
>>>> Please indicate by November 25th whether you support adoption of
>>>> draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.
>>> 
>>> Seems short and to the point.
>>> 
>>> An example message in an appendix would be nice.
>> 
>> Sure.  That is something I can do in the next version.
>> 
>> Russ
>> 
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm