Re: [lamps] Default values for PKIX and CMS w/ SHAKE

Hi Jim,

Thanks for keeping us honest. 

I just noticed that in the text we say 
" When the id-KmacWithSHAKE128 or id-KmacWithSHAKE256 algorithm
   identifier is used as the KMAC algorithm identifier, the parameters
   field MUST be absent."
That is indeed inaccurate. We will fix it. 

I see your point about the params being required in ASN.1. I will change it to something like 

   -- KMAC with SHAKE256
   KMACwithSHAKE256 MAC-ALGORITHM ::= {
         IDENTIFIER id-KMACWithSHAKE256
         PARAMS TYPE KMACwithSHAKE256-params ARE optional
            -- If KMACwithSHAKE256-params parameters are absent 
            -- the SHAKE256 output length used in KMAC is 512 bits
            -- and the customization string is an empty string.
   }
   id-KMACWithSHAKE256 OBJECT IDENTIFIER ::=  { joint-iso-itu-t(2)
                               country(16) us(840) organization(1)
                               gov(101) csor(3) nistAlgorithm(4)
                               hashAlgs(2) 20 }
   KMACwithSHAKE256-params ::= SEQUENCE {
      KMACOutputLength     INTEGER DEFAULT 512, -- Output length in bits
      customizationString  OCTET STRING DEFAULT ''
   }

Makes sense?

Please keep us honest with both the PKIX and the CMS (not yet completed) ASN.1.

Panos

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Jim Schaad
Sent: Tuesday, November 06, 2018 12:05 AM
To: 'SPASM' <spasm@ietf.org>
Subject: [lamps] Default values for PKIX and CMS w/ SHAKE

In running through the ASN.1 module I came up with a question about default values.  There are two different ways that the defaults could be done for
id-KMACWithSHAKE256

1.  Use default values for the fields in the structure.  This ends up with the following

SEQUENCE {
    OID  id-KMACWithSHAKE256,
    SEQUENCE {
    }
}

2.  Use a default value for the parameters as a whole.  This ends up with the following

SEQUENCE {
   OID id-KMACWithSHAKE256
}

The document currently says that the parameters are required to be absent.
This is implies fixed values for some fields and does not map to either option above but would have the same encoding as option 2.

The first is what is currently in the document and seems to be an odd way to do things.

The second corresponds to what happens today with RSASSA-PSS as defined in
4055 where there are a set of default values, but one can change the values if one wishes to.

Jim

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm