Re: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps)

[Ryan Sleevi <[e-mail]>]

On Wed, Jun 9, 2021 at 5:52 AM Dieter Bratko <[e-mail]>
wrote:

> Hello,
>
> > As for defining algorithmID OIDs, parameters, etc for Sphincs+, Falcon,
> > Dilithium, Kyber, etc, I haven't seen any drafts yet.
>
> A while ago Scott Fluhrer has posted a hint to an industry draft (
> https://docs.google.com/document/d/19XfdzkVdHS69rqin-XV72Cn2FjrpEbiyERg7F1lKIVs/edit?usp=sharing)
> on this list, and we wanted to suggest an alternative apporach:
>
> The industry draft specifies one algorithm id for each parameter set.
> These ids are used as key and signature/kem algorithm ids, too. Taking the
> Dilithium signature algorithm as example the draft specifies three ids
> (with the algorithm name as optional parameter):
>
> dilithium-4x4-r3 (1.3.6.1.4.1.2.267.7.4.4) for the security-level 2
> parameter set,
> dilithium-6x5-r3 (1.3.6.1.4.1.2.267.7.6.5) for the security-level 3
> parameter set, and
> dilithium-8x7-r3 (1.3.6.1.4.1.2.267.7.8.7) for the security-level 5
> parameter set,
>
> each of them used as key and signature algorihtm id, too.
>
> If there is no absolute requirement to bound the parameter set to the
> signature/kem algorithm, too, we would like to propose an alternative
> approach for defining the algorithm/parameter ids.
>

This is actually something that came up in past discussions as feedback
from multiple cryptographic library implementers.

In general, the use of parameters in AlgorithmIdentifiers creates a lot of
complexity throughout the system - from CAs issuing certificates (with the
correct parameters, and making sure the parameters make logical sense) to
RPs verifying certificates (which may only support a subset of parameters),
to applications using libraries trying to figure out "Is X supported"

The experience of running code is very much in favor of the explicit "use
the algorithm ID to express your parameters", which is more or less an
expression of the concepts captured at
https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance (now
abandoned?) or the lessons from other protocols (RFC 8701,
https://datatracker.ietf.org/doc/html/draft-nottingham-http-grease-01 ,
https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-grease-00 ...
you get the idea :D)

This is also roughly similar to the approach taken in TLS 1.3, which
collapsed the (independent) SignatureAndHashAlgorithm (
https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.4.1 ) into a
single logical unit (
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 ), to ensure no
untoward combinations/permutations.

I wanted to provide that context for why "OID with no params" is generally
prefered, in terms of security, complexity, and interoperability. Even
though ASN.1 technically affords the necessity, having well-scoped
definitions avoid ambiguities, or, worse, issues like
ChainOfFools/Curveball ( https://blog.lessonslearned.org/chain-of-fools/ )