Subject: [lamps] OID für KEM?

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 8 Oct 2021 16:48:36 +0000

There was a discussion here some time ago regarding NIST PQC KEM candidates, and assigning them OIDs for use in various protocols. 
The conclusion at  that time was that an OID should identify not just the bare-bones algorithm, but the suite the KEM in question is made a part of. 

I now need to define a certificate that would authenticate PQ public key for use in a variety of non-public (yet) protocols that utilize KEM. That means - I need to identify the algorithm this public key is for, and not bother with differentiating between different protocols that may use this KEM and therefore this public key. 
I understand that I can create an Algo Identifier myself, but my preference is something with broader acceptability and interoperability. 

What does the WG think? Any recommendations?

Regards,
Uri

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 12:54:34 -0400

Uri:

Researchers are going to assign OIDs to use in their projects.  A group of researchers might collaborate to use the same OIDs.  My worry is that these will not ever go away.

The LAMPS WG cannot assign these OIDs.  The charter says:

   5.a. The US National Institute of Standards and Technology (NIST)
   has a Post-Quantum Cryptography (PQC) effort to produce one or more
   quantum-resistant public-key cryptographic algorithm standards.
   The LAMPS WG will specify the use of these new PQC public key
   algorithms with the PKIX certificates and the Cryptographic Message
   Syntax (CMS). These specifications will use object identifiers
   for the new algorithms that are assigned by NIST.

Russ

> On Oct 8, 2021, at 12:48 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 8 Oct 2021 17:09:33 +0000

On 10/8/21, 12:55, "Russ Housley" <[email-masked]> wrote:

>    Researchers are going to assign OIDs to use in their projects.
>    A group of researchers might collaborate to use the same OIDs.

Understood, thanks!

>    My worry is that these will not ever go away.

I don't see a problem in this. 

E.g., Blake2 is not the final choice - but some apps use it, so what's wrong with having an interoperable way of identifying it?

>      .  .  .  .  .
>      algorithms with the PKIX certificates .  .  .  .  .
>      These specifications will use object identifiers

I see - this WG will define *how* those algorithms are used, but the OIDs themselves must come from NIST, like the selected algorithms themselves?

TNX

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 13:13:01 -0400

> E.g., Blake2 is not the final choice - but some apps use it, so what's wrong with having an interoperable way of identifying it?

That is not my point at all.  My worry is with the winning algorithms.  I worry that implementations will have to support the researcher-assigned OID and the NIST-assigned OID.

> I see - this WG will define *how* those algorithms are used, but the OIDs themselves must come from NIST, like the selected algorithms themselves?

Yes.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Oct 2021 10:17:10 -0700

> That is not my point at all.  My worry is with the winning algorithms.  I worry that implementations will have to support the researcher-assigned OID and the NIST-assigned OID.

Sounds like what happened at https://github.com/openssl/openssl/pull/16594
-- OpenSSL waited for the final SHA3 to implement, but then got asked to
also expose pre-standardization keccak.

-Ben

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 8 Oct 2021 18:57:20 +0000

On 10/8/21, 13:17, "Benjamin Kaduk" <[email-masked]> wrote:
 On Fri, Oct 08, 2021 at 01:13:01PM -0400, Russ Housley wrote:
>> .  .  .  .  .  My worry is with the winning algorithms. 
>> I worry that implementations will have to support the
>> researcher-assigned OID and the NIST-assigned OID.
>
> OpenSSL waited for the final SHA3 to implement, but then
> got asked to also expose pre-standardization Keccak.
               ^^^^

I acknowledge the concern that Russ expressed. But IMHO, it's inconvenient at worst. I see no reason to bend over backwards trying to avoid such a situation.

Another example: NIST standardized AES, removing certain capabilities of Rijndael. In our use case (that predates SHA3 by almost a decade ;), we needed a 256-bit block cipher for crypto hash. So, in our protocol we had to use *both* AES (aka, modified/constrained Rijndael) *and* Rijndael itself. 
Since it was for "internal consumption", we got by with assigning no specific per-algorithm identifiers (agility was provided by another way, details would only bore the audience ;).

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Oct 2021 14:10:37 -0400

> I acknowledge the concern that Russ expressed. But IMHO, it's
    > inconvenient at worst. I see no reason to bend over backwards trying to
    > avoid such a situation.

I also agree that it can be annoying, but I don't think that it's that huge a deal.
It would be nice if this didn't happen, but it seems to me that integers are
plentiful, and I think that we gain as a community from understanding how
things work or didn't work.

As I understand Ben's comment, the "pre-standization Keccak" (and the
unmodified Rijndael) are in fact different algorithms.

Ben didn't say what OpenSSL did.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Oct 2021 13:37:23 -0700

> unmodified Rijndael) are in fact different algorithms.

IIRC (not guaranteed), pre-standardization Keccak and SHA-3 differ in a few
constants, and the mapping between byte string and bit string, and are
definitely different algorithms.

> Ben didn't say what OpenSSL did.

The relevant policy body voted and approved an exception, so OpenSSL now
exposes pre-standardization Keccak as well as SHA-3.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 19:53:56 -0400

> exposes pre-standardization Keccak as well as SHA-3.

Did this require an OID?  (like, can I use it in CMS?)
Would the lack of an OID for pre-Keccak have made a difference to the
outcome?

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Oct 2021 23:30:24 -0700

> Would the lack of an OID for pre-Keccak have made a difference to the

With openssl 3.0.0, most operations use human-readable name when lookup is
needed, so there's no OID listed in
https://github.com/openssl/openssl/commit/524f12611040de64cda13dd148ad1b8ca559c730

-Ben

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 17 Oct 2021 12:00:25 +0200

> https://github.com/openssl/openssl/commit/524f12611040de64cda13dd148ad1b8ca559c730

Which means that for cases where an OID is needed, you can't use it.

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 17 Oct 2021 17:20:13 +0000

In other words, OpenSSL did not define or use from somewhere else an OID for Keccak.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 17 Oct 2021 23:47:35 +0000

>    >    With openssl 3.0.0, most operations use human-readable
>    >    name when lookup is needed, so there's no OID listed in
>

This comment "conforms to the letter of the answer (as indeed OpenSSL did not assign an OID to Keccak), but may violate its spirit (as the request was to expose Keccak, and OpenSSL agreed to do so)".

As "most OpenSSL-3.0.0 operations use human-readable name", so NO OID WAS NEEDED to lookup Keccak by name, so no OID was assigned to it. Apparently, being able to do a lookup on the algorithm name was sufficient for the requesters.

In my case, situation is a little worse - I need to not only access the algorithm, but encode it in a certificate. So, for my purposes, an OID would be necessary.