Subject: Re: [lamps] What do we want OIDs! Re: PKIX and related RFCs - definition of Key Packages

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 24 Jun 2021 02:40:22 +0000

Yes, but what would that OID specify exactly? 

IMHO, they would define the instance of an algorithm with a specific parameter set, like you suggested below. E.g., Kyber-1024-90s, or Kyber-1024.

Perhaps this LAMPS would like to do things like:

1. Specify how to use the PQC algorithms to create detached signatures (not message+signature combinations with a fixed hash and arbitrary formatting, as used in the NIST competition).

2. Specify how to use general hash functions such as SHA-2 with them (also not defined by NIST). The obvious, non-randomized way of doing this breaks their security, and must be avoided. ( Yes, I know that the internal XOFs are harder to change/specify, but this needs to be discussed in an RFC. )

Yes – these two make sense. 

IMHO, we should treat these algorithms as Black Boxes: OCTET STRING arguments as input, OCTET STRING output. And leave the internal XOF (and RNG where appropriate) to the algorithm itself. Unless I misunderstood you? Could you please make  clearer your concern with the “non-randomized way”?

So, after such definitions, the OID could refer to that formatting/padding method rather than the plain "algorithm"… After all we don't use OIDs that refer to plain "RSA" covering all of its use cases and PKCS padding methods either. At least the above two steps would be necessary to integrate PQC into X.509 PKI framework. Similarly, to use KEMs for some specific purpose, such as public-key encryption, requires specification for the formatting of the KEM-DEM/AEAD combination. LAMPS can assign an OID to that specific formatting + algorithm combination after it is defined.

In general, I like this. Except that KEM is a useful standalone construct. I don’t think it would be good to tie it to a specific single AEAD, or to create an OID for a given KEM and all the AEAD modes (and ciphers!) that are floating around.

I don't see the existence of OID numbers for plain algorithms without versioning as not as a prerequisite for standards definition work but as a plainly harmful as it leaves many things up for interpretation, even if the internal parameters are fixed (and PQC algorithms have a lot of security parameters). 

I agree that versioning should be reflected by these OIDs. As far as a KEM (or a Signature) algorithm is concerned – an assigned OID should leave nothing to interpretation (parameter set, etc. must be covered by this OID). 

By the way, this is not something that stops me from writing Internet-Drafts, which I'd see as an useful activity, unlike OIDs for ambiguous algorithm names. If someone wants an OID for, say, Falcon-1024-Round3.0, I could probably assign it within a day from our PEN (IANA has assigned the tree under 1.3.6.1.4.1.54575 to PQShield) .. it's just a matter of asking for a permission from the design team. Note that the OID would be for that specific version since I know that Falcon will be changed soon. Dilithium has already been updated during Round3 -- v3.1 had substantial functional changes in February (a couple of internal parameters and a few other things). Hence the current version ( https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf ) is not compatible with the one submitted to Round 3 last October. 

Since those OIDs aren’t going to expire – yes, I agree. The above is what we should do IMHO…

So, I'd suggest defining a temporary OID yourself or get an OID from the design teams if you want to use them in applications or Internet Drafts at this stage. But I see the concrete definition of how PQC algorithms are used in IETF protocols as a useful step.

Yes, I agree with both parts of the above. 

One goal here is to avoid proliferation of OIDs for the same algorithms. As Jeffrey said, we can live with two (IETF-agreed, and NIST-assigned), especially since it could only happen to the winner algorithms. For all the other candidates that we’d choose to “sanctify” by assigning OIDs, my hope is that they’ll have a single OID each.

Thanks!

Once the NIST picks “the one”, let them re-use the IETF OID or assign a brand new one from their MIB space.

However, we can do a lot of work prior to OID assignment, such as figuring out the information, if any, that needs to be included in parameters.

 Yes, let’s do that regardless of whether we decide to assign OIDs here or not.  

 Thanks!

On Jun 23, 2021, at 11:36 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:

Our charter says that we will use the NIST-assigned OIDs.  Please send the request for OIDs to NIST.

It was my understanding that the NIST usually follows IANA/IETF regarding OID assignment? If so, it should be easy enough to request and receive the charter correction.

In any case, the NIST is highly unlikely to assign OIDs to pre-selection (e.g., Round 3) candidates. Nor is it likely to assign OIDs to algorithms not selected at the end of Round 3. Other countries may (and probably will) choose different algorithms. 

In short, it appears that OIDs are needed now, the best entity to assign them is IETF/IANA, and this WG is as good a starting place as any.

I’m calling for consensus.

Thanks!

On Jun 23, 2021, at 10:44 AM, Phillip Hallam-Baker <[email-masked]> wrote:

When do we want them - NOW!

I second Jeffrey's request, we have to get OIDs and JOSE tags defined for PQC algorithms now or else we will have half a dozen different OIDs for the same algorithm by the time we need to use them.

Of the current finalists, only one, SIKE appears to be compatible with the Threshold techniques I am using in the Mesh so I will be implementing that one irregardless of the final NIST choice. I would prefer that either IETF or the group itself specify an OID etc.

This particular contest is not the same as previous NIST contests because it may be a decade before these algorithms are being widely used, the principles behind the algorithms are very new, there are major performance and functional differences, etc. etc. If I could use more than one of the proposals, I would probably implement two or more just to stress test the code.

That said, maybe we should ask the groups to specify their preferred identifiers as part of their submissions.

On Wed, Jun 23, 2021 at 10:16 AM Jeffrey Walton <[email-masked]> wrote:

OIDs are already showing up in the wild. Botan has some private
assignments at https://botan.randombit.net/handbook/dev_ref/oids.html.

It is reminiscent of Bernstein's x25519 gear. There are multiple OIDs
in the wild that a program must recognize to interoperate.

It would probably be useful to get OID assignments to avoid what
happened with x25519.

Jeff

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Thu, 24 Jun 2021 06:11:42 +0300

On Thu, Jun 24, 2021, 05:41 Blumenthal, Uri - 0553 - MITLL <[email-masked]>
wrote:

> IMHO, they would define the instance of an *algorithm with a specific
> parameter set*, like you suggested below. E.g., Kyber-1024-90s, or
> Kyber-1024.
>

Hi Uri,

I think it would be a bit more useful for us to define a way to use PQC
KEMs within the IETF protocols within the charter, eg PKI and Public Key
Encryption for S/MIME. And define an OID for the precise key wrap
mechanisms etc.

For signatures one needs to define the way they can be used in PKI in safe
and interoperable way. This is the nontrivial part.

As noted, the algorithms have changed even during the third round. If I
want define an OID for my PQ Sig algorithm I can put that in an informal
RFC together with test vectors etc (and there will be more of those even
after the competition "finishes" due to the fourth round and pq sig on-ramp
announced by NIST.) But: I'd like to have the help of this group to define
a way to use it for various purposes.

So, I would strongly advice against issuing OIDs for round 3 draft
parameter sets. Let the teams do it if they want. There would be a risk
that someone would just stick those OIDs into certificates, thinking that
signing a hash is fine .. or not understanding the failure mechanisms of
PQC CCA KEMs in encryption, for example.

I think it is best to put this into an internet draft at this stage,
explaining the properties and concepts and algorithm classes
(hash-and-sign, cca, cpa etc) and iterate on that.

Cheers,
-Markku

As noted algor

> 1. Specify how to use the PQC algorithms to create *detached signatures*
> (not message+signature combinations with a fixed hash and arbitrary
> formatting, as used in the NIST competition).
>
> 2. Specify how to use general hash functions such as SHA-2 with them (also
> not defined by NIST). The obvious, non-randomized way of doing this breaks
> their security, and must be avoided. ( Yes, I know that the internal XOFs
> are harder to change/specify, but this needs to be discussed in an RFC. )
>
>
>
> IMHO, we should treat these algorithms as Black Boxes: OCTET STRING
> arguments as input, OCTET STRING output. And leave the internal XOF (and
> RNG where appropriate) to the algorithm itself. Unless I misunderstood you?
> Could you please make  clearer your concern with the “non-randomized way”?
>
>
>
> So, after such definitions, the OID could refer to that formatting/padding
> method rather than the plain "algorithm"… After all we don't use OIDs that
> refer to plain "RSA" covering all of its use cases and PKCS padding methods
> either. At least the above two steps would be necessary to integrate PQC
> into X.509 PKI framework. Similarly, to use KEMs for some specific purpose,
> such as public-key encryption, requires specification for the formatting of
> the KEM-DEM/AEAD combination. LAMPS can assign an OID to that specific
> formatting + algorithm combination after it is defined.
>
>
>
> In general, I like this. Except that KEM is a useful standalone construct.
> I don’t think it would be good to tie it to a specific single AEAD, or to
> create an OID for a given KEM and all the AEAD modes (and ciphers!) that
> are floating around.
>
>
>
> I don't see the existence of OID numbers for plain algorithms without
> versioning as not as a prerequisite for standards definition work but as a
> plainly harmful as it leaves many things up for interpretation, even if the
> internal parameters are fixed (and PQC algorithms have a lot of security
> parameters).
>
>
>
> I agree that versioning should be reflected by these OIDs. As far as a KEM
> (or a Signature) algorithm is concerned – an assigned OID should leave
> *nothing* to interpretation (parameter set, etc. must be covered by this
> OID).
>
>
>
> By the way, this is not something that stops me from writing
> Internet-Drafts, which I'd see as an useful activity, unlike OIDs for
> ambiguous algorithm names. If someone wants an OID for, say,
> Falcon-1024-Round3.0, I could probably assign it within a day from our PEN
> (IANA has assigned the tree under 1.3.6.1.4.1.54575 to PQShield) .. it's
> just a matter of asking for a permission from the design team. Note that
> the OID would be for that specific version since I know that Falcon will be
> changed soon. Dilithium has already been updated during Round3 -- v3.1 had
> substantial functional changes in February (a couple of internal parameters
> and a few other things). Hence the current version (
> https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf
> ) is not compatible with the one submitted to Round 3 last October.
>
>
>
> So, I'd suggest defining a temporary OID yourself or get an OID from the
> design teams if you want to use them in applications or Internet Drafts at
> this stage. But I see the concrete definition of how PQC algorithms are
> used in IETF protocols as a useful step.
>
>
>
> One goal here is to avoid proliferation of OIDs for the same algorithms.
> As Jeffrey said, we can live with two (IETF-agreed, and NIST-assigned),
> especially since it could only happen to the winner algorithms. For all the
> other candidates that we’d choose to “sanctify” by assigning OIDs, my hope
> is that they’ll have a single OID each.
>
>
>
> Thanks!
>
>
>
> However, we can do a lot of work prior to OID assignment, such as figuring
> out the information, if any, that needs to be included in parameters.
>
> It was my understanding that the NIST usually follows IANA/IETF regarding
> OID assignment? If so, it should be easy enough to request and receive the
> charter correction.
>
> In any case, the NIST is highly unlikely to assign OIDs to pre-selection
> (e.g., Round 3) candidates. Nor is it likely to assign OIDs to algorithms
> *not* selected at the end of Round 3. Other countries may (and probably
> will) choose different algorithms.
>
> In short, it appears that OIDs are needed now, the best entity to assign
> them is IETF/IANA, and this WG is as good a starting place as any.
>
> I second Jeffrey's request, we have to get OIDs and JOSE tags defined for
> PQC algorithms now or else we will have half a dozen different OIDs for the
> same algorithm by the time we need to use them.
>
> Of the current finalists, only one, SIKE appears to be compatible with the
> Threshold techniques I am using in the Mesh so I will be implementing that
> one irregardless of the final NIST choice. I would prefer that either IETF
> or the group itself specify an OID etc.
>
> This particular contest is not the same as previous NIST contests because
> it may be a decade before these algorithms are being widely used, the
> principles behind the algorithms are very new, there are major performance
> and functional differences, etc. etc. If I could use more than one of the
> proposals, I would probably implement two or more just to stress test the
> code.
>
> That said, maybe we should ask the groups to specify their preferred
> identifiers as part of their submissions.
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 25 Jun 2021 21:01:08 +0000

On Thu, Jun 24, 2021, 05:41 Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:

I think it would be a bit more useful for us to define a way to use PQC KEMs within the IETF protocols within the charter, e.g., PKI and Public Key Encryption for S/MIME. And define an OID for the precise key wrap mechanisms etc. 

You made a good point – the actual Internet protocols don’t just need a “generic” algorithm (like AES256) – they need to know how to use it. 

For signatures one needs to define the way they can be used in PKI in safe and interoperable way. This is the nontrivial part.

I agree.

As noted, the algorithms have changed even during the third round. If I want define an OID for my PQ Sig algorithm I can put that in an informal RFC together with test vectors etc (and there will be more of those even after the competition "finishes" due to the fourth round and pq sig on-ramp announced by NIST.) But: I'd like to have the help of this group to define a way to use it for various purposes.

Yes. But it seems counterproductive to wait with experimenting and testing interoperability before the winners are announced. And it is pretty certain that some companies and countries are working with Round 3 candidates.

So, I would strongly advice against issuing OIDs for round 3 draft parameter sets. Let the teams do it if they want. There would be a risk that someone would just stick those OIDs into certificates, thinking that signing a hash is fine .. or not understanding the failure mechanisms of PQC CCA KEMs in encryption, for example.

I do not see how this follows from the initial argument. 

Yes, I agree that if we define OIDs, they must specify more than just an algorithm with a given parameter set – but include sufficient details for its use with, e.g., S/MIME, or X.509 PKI.

But I don’t see why that we cannot or shouldn’t do this work for Round 3 candidates with their parameters. Yes, some of them will change. So…?

I think it is best to put this into an internet draft at this stage, explaining the properties and concepts and algorithm classes (hash-and-sign, cca, cpa etc) and iterate on that.

Noted. Thank you!

 

Thanks!

 Thanks!

Thanks!

Jeff