Re: [lamps] Dilithium OIDs per security level?

[David Benjamin <[e-mail]>]

On Sun, Nov 20, 2022 at 12:39 PM Carl Wallace <[e-mail]>
wrote:

> Inline…
>
>
>
> *From: *Spasm <[e-mail]> on behalf of David Benjamin <
> [e-mail]>
> *Date: *Sunday, November 20, 2022 at 12:21 PM
> *To: *Mike Ounsworth <Mike.Ounsworth=[e-mail]>
> *Cc: *LAMPS <[e-mail]>
> *Subject: *Re: [lamps] Dilithium OIDs per security level?
>
>
>
> Not one of the draft authors, but they need to be distinct OIDs. The
> two-level construction with id-ecPublicKey was a mistake, as was RSA
> defining one OID to cover a whole family of related algorithms.
> Dilithium2, Dilithium3, and Dilithium5 should be thought of as entirely
> distinct algorithms. We have plenty of implementation experience with the
> compounding costs of getting this wrong. Some additional points that should
> be resolved:
>
>
>
> 1. Please drop the unnecessary OCTET STRING wrapper inside the BIT STRING.
> There is no requirement that the BIT STRING carry an ASN.1 type, indeed
> none of the EC types (id-ecPublicKey or the new curves) do this and
> instead, correctly, just place the byte representation directly in the BIT
> STRING.
>
>
>
> [CW] This was discussed during LAMPS. The OCTET STRING definition is
> negated by text shortly below it (the tag and length of the OCTET STRING
> are not actually encoded into the BIT STRING). I’d like to see the
> definition dropped in favor of prose that describes encoding the key
> directly into the BIT STRING. During the hackathon at IETF 115, we
> initially saw varied handling of the OCTET STRING in both in
> SubjectPublicKeyInfo (including inclusion of the spurious tag in my
> implementation) and OneAsymmetricKey. The EC spec appears to have
> established the practice of defining a structure then negating it by
> mapping the value onto a BIT STRING (see 2.2 of RFC5480). I see no reason
> to continue that here.
>

Oh, whoops! I was looking at draft-massimo-lamps-pq-sig-certificates-00
instead of draft-ietf-lamps-dilithium-certificates-00. Thanks! That is
indeed kinda oddly phrased but would have the desired effect.


> 2. There should not be an OPTIONAL copy of the public key
> in DilithiumPrivateKey. Either it's part of the structure, or it isn't,
> with no optionality. We've already learned this lesson with ECPrivateKey;
> the various optional fields have had a compounding negative effect up the
> stack. This is also the wrong layer to define this... whatever
> specification we have for Dilithium, be it NIST's actual document or a
> fixup document in CFRG, should come with a byte string representation that
> we just drop into PKCS#8 unmodified and unadorned.
>
>
>
> I still need to fully evaluate this draft for whether it would be an
> acceptable starting point for the TLS and X.509 implementations that I'm
> involved with, but getting any of these wrong would be considered
> disqualifying in my eyes.
>
>
>
> On Sat, Nov 19, 2022 at 6:27 PM Mike Ounsworth <Mike.Ounsworth=
> [e-mail]> wrote:
>
> Hi Jake, Panos, Sean, Bas,
>
>
>
> I could use some clarification on which OIDs you’re planning to register
> cause I’m trying to cross-reference them when defining all the composite
> pairs.
>
>
>
> The current version of draft-ietf-lamps-dilithium-certificates-00 has
>
>
>
> id-dilithiumTBD which you seem to be using for the signature algorithm.
>
>
>
>
>
>    id-dilithiumTBD OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
>
>             country(16) us(840) organization(1) gov(101) csor(3)
>
>             nistAlgorithm(4) sigAlgs(3) TBD }
>
>
>
>
>
> And also pk-dilithiumTBD which you seem to be using for the public key.
>
>
>
>   PublicKeys PUBLIC-KEY ::= {
>
>     -- This expands PublicKeys from RFC 5912
>
>     pk-dilithiumTBD |
>
>     pk-TBD-TBD,
>
>     ...
>
>   }
>
>
>
>
>
> Next question: are you going to register those per level; ie
> id-dilithium2, id-dilithium3, id-dilithium5?
>
>
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
>
> *Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.*
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________ Spasm mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/spasm
>