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

["Panos Kampanakis (pkampana)" <[e-mail]>]

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


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

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 <[e-mail]> wrote:
> 
> 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 <[e-mail]> On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Wednesday, September 11, 2019 9:22 PM
> To: Russ Housley <[e-mail]>; LAMPS WG <[e-mail]>
> 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 <[e-mail]> On Behalf Of Russ Housley
> Sent: Wednesday, September 11, 2019 3:06 PM
> To: LAMPS WG <[e-mail]>
> 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.
> 
> 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
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm