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

[Dieter Bratko <[e-mail]>]

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 
<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. The approach is leant 
on the parameter/algorithm id specification used by Elliptic Curve 
Cryptography. EC uses separate ids for keys and (e.g. signature) 
algorithms, and the curve (and thus parameter set) is propageted as 
parameter of the key algorithm id. For the Dilithium example this could 
be done by keeping the three parameter (example) ids dilithium-4x4-r3 
(1.3.6.1.4.1.2.267.7.4.4), dilithium-6x5-r3 (1.3.6.1.4.1.2.267.7.6.5),  
dilithium-8x7-r3 (1.3.6.1.4.1.2.267.7.8.7)  and defining two additional 
ids, one for the key algorithm (e.g. 1.3.6.1.4.1.2.267.7.1) and one for 
the signature algorithm (e.g. 1.3.6.1.4.1.2.267.7.2) for Dilithium (or 
Shake256withDilithium -- to be open for alternative XOFs). The parameter 
field of the key algorithm id must contain the id of the corresponding 
parameter set:

AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm  OBJECT IDENTIFIER, -- OID: key algorithm
     parameters PQParameterSet
}

PQParameterSet ::= OBJECT IDENTIFIER

The encoding of the signature (or kem) algorithm id by default should 
omit the parameter field, except for if the specific signature (or kem) 
algorithm id may have to carry some additional information. For 
Dilithium, e.g., the parameter field could be used to tell the verifier 
whether the signer has used AES (instead of SHAKE) to expand the public 
matrix.

We think that this approach would be more convenient to implement and 
use. McEliece, for instance, defines ten parameter sets. Typically an 
user will have only one McEliece key(pair) which (in the EC-style 
approach) (s)he could use with the McEliece KEM (or. Shake256McEliece) 
algorithm id, regardless of which parameter-set is bound to the key. In 
the current (industry draft) approach the user would have to take care 
to select the right KEM algorithm ID among a set of ten KEM algorithm 
ids to ensure to use her/his, for instance, mceliece460896 key with the 
corresponding mceliece460896 KEM algorithm id.

Regards,
Dieter Bratko
--------
Dieter Bratko mailto:[e-mail] 
<mailto:[e-mail]>
SIC/IAIK – Graz University Of Technology,
Inffeldgasse 16A, 8010 Graz, Austria,
http://jce.iaik.tugraz.at <http://jce.iaik.tugraz.at>

On 08.06.2021 at 23:57 Mike Ounsworth wrote:
> As for defining algorithmID OIDs, parameters, etc for Sphincs+, Falcon, Dilithium, Kyber, etc, I haven't seen any drafts yet.