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

From: Ludovic Perret <[email-masked]>
Date: Tue, 8 Jun 2021 17:59:57 +0000

Dear

One question about the milestones adopted in the new charter.

Is there is already a  draft circulating for PQC in  PKIX or CMS ?

Best Regards,

--
Ludovic Perret
CEO, co-founder, CryptoNext Security
CryptoNext Security - The next generation of public-key cryptography
https://cryptonext-security.com/

------ Message d'origine ------
De: "The IESG" <[email-masked]>
À: "IETF-Announce" <[email-masked]>
Cc : "[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "The IESG" <[email-masked]>
Envoyé : 25/05/2021 23:33:18
Objet : [lamps] WG Action: Rechartered Limited Additional Mechanisms for 
PKIX and SMIME (lamps)
>
>Milestones:
>
>   May 2021 - Adopt a draft for end-to-end email user agent guidance
>
>   Jul 2021 - Adopt a draft for short-lived certificate conventions
>
>   Oct 2021 - Adopt draft for PQC KEM public keys in PKIX certificates
>
>   Oct 2021 - Adopt draft for PQC KEM algorithms in CMS
>
>   Nov 2021 - Header protection conventions sent to IESG for standards track
>   publication
>
>   Dec 2021 - CMP updates sent to IESG for  standards track publication
>
>   Dec 2021 - Lightweight CMP profile sent to IESG for informational
>   publication
>
>   Dec 2021 - Adopt draft for PQC signatures in PKIX certificates
>
>   Dec 2021 - Adopt draft for PQC signatures in CMS
>
>   Dec 2021 - Adopt draft for public keys for hybrid key establishment in PKIX
>   certificates
>
>   Dec 2021 - Adopt draft for hybrid key establishment in CMS
>
>   Dec 2021 - Adopt draft for dual signatures in PKIX certificates
>
>   Dec 2021 - Adopt draft for dual signature in CMS
>
>   Dec 2021 - CMP algorithms sent to IESG for standards track publication
>
>   Mar 2022 - Short-lived certificate conventions sent to IESG for BCP
>   publication
>
>   Jul 2022 - End-to-end email user agent guidance sent to IESG for
>   informational publication
>
>
>
>_______________________________________________
>Spasm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/spasm

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 8 Jun 2021 21:57:55 +0000

Hi,

There is this one covering composite public keys and signatures, and we are working on a similar one that covers hybrid encryption and key exchange.

- https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/

As for defining algorithmID OIDs, parameters, etc for Sphincs+, Falcon, Dilithium, Kyber, etc, I haven't seen any drafts yet.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Ludovic Perret
Sent: June 8, 2021 1:00 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps)

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Dear

Best Regards,

--
Ludovic Perret
CEO, co-founder, CryptoNext Security
CryptoNext Security - The next generation of public-key cryptography https://urldefense.com/v3/__https://cryptonext-security.com/__;!!FJ-Y8qCqXTj2!MOFhe2IHrVZKBUfejddHmWleWjjFJNxK5gY45HjeCsyaIgKiyPl6IuKoQghuYJ2XuOSYr1Wgtw$ 

------ Message d'origine ------
De: "The IESG" <[email-masked]>
À: "IETF-Announce" <[email-masked]> Cc : "[email-masked]" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "The IESG" <[email-masked]> Envoyé : 25/05/2021 23:33:18 Objet : [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps)
>https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm
>__;!!FJ-Y8qCqXTj2!MOFhe2IHrVZKBUfejddHmWleWjjFJNxK5gY45HjeCsyaIgKiyPl6I
>uKoQghuYJ2XuORtKnhMQw$
_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!MOFhe2IHrVZKBUfejddHmWleWjjFJNxK5gY45HjeCsyaIgKiyPl6IuKoQghuYJ2XuORtKnhMQw$

---

From: Dieter Bratko <[email-masked]>
Date: Wed, 9 Jun 2021 11:51:55 +0200

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:[email-masked] 
<mailto:[email-masked]>
SIC/IAIK – Graz University Of Technology,
Inffeldgasse 16A, 8010 Graz, Austria,
http://jce.iaik.tugraz.at <http://jce.iaik.tugraz.at>

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 9 Jun 2021 12:04:17 -0400

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

> A while ago Scott Fluhrer has posted a hint to an industry draft (
> https://docs.google.com/document/d/19XfdzkVdHS69rqin-XV72Cn2FjrpEbiyERg7F1lKIVs/edit?usp=sharing)
> 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):
>
> 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/ )