Subject: [lamps] draft-ietf-lamps-cms-shakes

From: Russ Housley <[email-masked]>
Date: Wed, 11 Sep 2019 15:06:28 -0400

I was just working on an implementation, and I discovered an omission in the ASN.1 for draft-ietf-lamps-cms-shakes.

The ASN.1 module for draft-ietf-lamps-pkix-shake includes:

    -- RSASSA-PSS with SHAKE128
    sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-RSASSA-PSS-SHAKE128
      PARAMS ARE absent
          -- The hashAlgorithm is mda-shake128
          -- The maskGenAlgorithm is id-shake128
          -- Mask Gen Algorithm is SHAKE128 with output length
          -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA
          -- modulus in bits.
          -- The saltLength is 32. The trailerField is 1
      HASHES { mda-shake128 }
      PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 }
      SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }
    }
    id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1)
            identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) algorithms(6)
            TBD1 }

    -- RSASSA-PSS with SHAKE256
    sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-RSASSA-PSS-SHAKE256
      PARAMS ARE absent
          -- The hashAlgorithm is mda-shake256
          -- The maskGenAlgorithm is id-shake256
          -- Mask Gen Algorithm is SHAKE256 with output length
          -- (8*ceil((n-1)/8) - 520)-bits, where n is the
          -- RSA modulus in bits.
          -- The saltLength is 64. The trailerField is 1.
     HASHES { mda-shake256 }
     PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 }
     SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }
    }
    id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1)
            identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) algorithms(6)
            TBD2 }

    -- ECDSA with SHAKE128
    sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-ecdsa-with-shake128
      VALUE ECDSA-Sig-Value
      PARAMS ARE absent
      HASHES { mda-shake128 }
      PUBLIC-KEYS { pk-ec }
      SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }
    }
    id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1)
            identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) algorithms(6)
            TBD3 }

    -- ECDSA with SHAKE256
    sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-ecdsa-with-shake256
      VALUE ECDSA-Sig-Value
      PARAMS ARE absent
      HASHES { mda-shake256 }
      PUBLIC-KEYS { pk-ec }
      SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }
    }
    id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1)
            identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) algorithms(6)
            TBD4 }

I think that the draft-ietf-lamps-cms-shakes ASN.1 module should repeat this information in exactly the same format or it should IMPORT these definitions.

Russ

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 12 Sep 2019 04:21:45 +0000

Hi Russ, 

Hmm, do we need it? 

CMS imports AlgorithmIdentifier from PKIX which we updated in the PKIX SHAKEs draft. And then CMS uses these algorithm identifiers in the SignedData SignerInfo signatureAlgorithm field. 

https://tools.ietf.org/html/rfc5753#appendix-A.2 does import sa-ecdsawithXXX as you are suggesting, but I am not sure it needed to. I mean we could import the new sa-ecdsawithshake and sa-rsassapssWithSHAKE and put them SignatureAlgs to make it easier, but it would be commented out like https://tools.ietf.org/html/rfc5753#appendix-A.2 does because it already exists in the PKIX SHAKEs ASN.1

Rgs,
Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, September 11, 2019 3:06 PM
To: LAMPS WG <[email-masked]>
Subject: [lamps] draft-ietf-lamps-cms-shakes

    -- ECDSA with SHAKE128

    -- ECDSA with SHAKE256

Russ
_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Jim Schaad <[email-masked]>
Date: Wed, 11 Sep 2019 21:54:27 -0700

Redefining is something that is not good.  You only want to have a single
definition if at all possible.

Importing something that is not referenced is a bit odd, but does not hurt
anything.  Pointing to where something is defined would be sufficient as far
as I am concerned

-- sa-rsassapssWithSHAKE  - this is defined in RFCXXXX

Jim

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Panos Kampanakis
(pkampana)
Sent: Wednesday, September 11, 2019 9:22 PM
To: Russ Housley <[email-masked]>; LAMPS WG <[email-masked]>
Subject: Re: [lamps] draft-ietf-lamps-cms-shakes

Hi Russ, 

Hmm, do we need it? 

CMS imports AlgorithmIdentifier from PKIX which we updated in the PKIX
SHAKEs draft. And then CMS uses these algorithm identifiers in the
SignedData SignerInfo signatureAlgorithm field. 

https://tools.ietf.org/html/rfc5753#appendix-A.2 does import sa-ecdsawithXXX
as you are suggesting, but I am not sure it needed to. I mean we could
import the new sa-ecdsawithshake and sa-rsassapssWithSHAKE and put them
SignatureAlgs to make it easier, but it would be commented out like
https://tools.ietf.org/html/rfc5753#appendix-A.2 does because it already
exists in the PKIX SHAKEs ASN.1

Rgs,
Panos

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, September 11, 2019 3:06 PM
To: LAMPS WG <[email-masked]>
Subject: [lamps] draft-ietf-lamps-cms-shakes

I was just working on an implementation, and I discovered an omission in the
ASN.1 for draft-ietf-lamps-cms-shakes.

    -- ECDSA with SHAKE128

    -- ECDSA with SHAKE256

I think that the draft-ietf-lamps-cms-shakes ASN.1 module should repeat this
information in exactly the same format or it should IMPORT these
definitions.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Sep 2019 07:24:45 -0400

Since pkix-shake is going through the process sirse, it would be easy to add an IMPORT for the four sa-* values.

Russ

> On Sep 12, 2019, at 12:54 AM, Jim Schaad <[email-masked]> wrote:
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 12 Sep 2019 14:39:58 +0000

ACK, thanks. 
I will spin up a new iteration early next week. 

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: Thursday, September 12, 2019 7:25 AM
To: Jim Schaad <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: Re: [lamps] draft-ietf-lamps-cms-shakes

Russ

> Redefining is something that is not good.  You only want to have a 
> single definition if at all possible.
> 
> Importing something that is not referenced is a bit odd, but does not 
> hurt anything.  Pointing to where something is defined would be 
> sufficient as far as I am concerned
> 
> https://tools.ietf.org/html/rfc5753#appendix-A.2 does import 
> sa-ecdsawithXXX as you are suggesting, but I am not sure it needed to. 
> I mean we could import the new sa-ecdsawithshake and 
> sa-rsassapssWithSHAKE and put them SignatureAlgs to make it easier, 
> but it would be commented out like
> https://tools.ietf.org/html/rfc5753#appendix-A.2 does because it 
> already exists in the PKIX SHAKEs ASN.1
> 
> Rgs,
> Panos
> 
> 
> I think that the draft-ietf-lamps-cms-shakes ASN.1 module should 
> repeat this information in exactly the same format or it should IMPORT 
> these definitions.
> 
> Russ