The intention is to register the same algorithms.

Pre-hash algorithms should be treated the same way, but because COSE and
JOSE has algorithm as optional, unless there is domain separation in the
public keys, that would be application later alignment.

Pre-hash seems like a good idea, especially if folks are moving from ES256
with SHA-256.

Any application interfaces that JOSE or COSE have built around pre-hashing
are probably easier to preserve.

Imo, it would be good to have the domain separation in the keys as
signatures and not rely on application layer signaling.

OS

On Mon, Jul 29, 2024, 10:48 PM Michael Jones <[email protected]>
wrote:

> To what extent should our COSE post-quantum work be aligning with what’s
> happening in LAMPS?  And what would that entail?
>
>
>
>                                                                 With
> curiosity,
>
>                                                                 -- Mike
>
>
>
> *From:* 'Kampanakis, Panos' via pqc-forum <[email protected]>
> *Sent:* Monday, July 29, 2024 7:25 PM
> *To:* David A. Cooper <[email protected]>
> *Cc:* pqc-forum <[email protected]>
> *Subject:* RE: [pqc-forum] Pure and pre-hash object identifiers for
> ML-DSA and SLH-DSA
>
>
>
> Hi David,
>
>
>
> The ML-DSA and SLH-DSA X.509 drafts (and the SLH-DSA CMS draft) all had
> pure PQ signatures in the back of their minds like RFC8410 did for EdDSA.
> But the CRL use-case is an interesting one. Maybe prehash signing makes
> sense there if the signing frequency and message size justify it.
>
>
>
> I would advocate for distinct identifiers for the pure and prehash
> variants of both the Sig and PK for the same reasons David B. lays out in
> his
> https://mailarchive.ietf.org/arch/msg/spasm/Ssk0hTwLm2ao0Fkvxa7jyfdMREg/
> Maybe CRL signing does not have the same risk regarding collision
> resistance as you are suggesting and one PK identifier would make sense
> there, but these OIDs could be used in many places. We can’t predict they
> will go only in CRL signing.
>
>
>
> Rgs
>
>
>
>
>
>
>
> *From:* 'David A. Cooper' via pqc-forum <[email protected]>
> *Sent:* Monday, July 29, 2024 11:57 AM
> *To:* pqc-forum <[email protected]>
> *Subject:* [EXTERNAL] [pqc-forum] Pure and pre-hash object identifiers
> for ML-DSA and SLH-DSA
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> Hi all,
>
> As was previously announced on the pqc-forum
> <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/JKMh0D0pa30/m/vbflXolxAQAJ>,
> ML-DSA and SLH-DSA will specify separate "pure" and "pre-hash" versions,
> with domain separation to prevent pre-hash signatures verifying as pure
> signatures and vice versa.
>
> The IETF LAMPS working group is developing drafts that will specify
> semantics for OIDs associated with ML-DSA and SLH-DSA:
> https://www.ietf.org/archive/id/draft-ietf-lamps-dilithium-certificates-04.html
> and https://www.ietf.org/archive/id/draft-ietf-lamps-x509-slhdsa-01.html.
> In these drafts, for each parameter set, the same OID is used to identify
> both a public key and a signature. However, the IETF drafts do not account
> for the separate pure and pre-hash options.
>
> For the digital signature algorithms in FIPS 186-5 the public key and the
> signature algorithm identifiers are separate. For example, with ECDSA the
> public key is just identified as an elliptic curve key (ecPublicKey) and
> only the signature algorithm identifier indicates what hash function to use
> to verify the signature (e.g. ecdsaWithSHA256, ecdsaWithSHA512). Using
> SLH-DSA-SHA2-128s as an example, if NIST were to follow this approach with
> ML-DSA and SLH-DSA, then any public key using the SLH-DSA-SHA2-128s
> parameter set could be identified using the OID id-alg-slh-dsa-sha2-128s. A
> pure signature would also be identified using id-alg-slh-dsa-sha2-128s. A
> pre-hash signature would be identified with an OID that also indicated how
> pre-hashing was performed (e.g.,
> id-alg-slh-dsa-sha2-128s-with-sha256-prehash).
>
> A second option (as suggested in
> https://mailarchive.ietf.org/arch/msg/spasm/Ssk0hTwLm2ao0Fkvxa7jyfdMREg/)
> would be for the public key identifier to indicate how signatures are
> generated. In this case, if a public key were identified as
> id-alg-slh-dsa-sha2-128s, then it could only be used to verify pure
> signatures. A public key identified as
> id-alg-slh-dsa-sha2-128s-with-sha256-prehash could only be used to verify
> signatures created by pre-hashing with SHA-256.
>
> While we believe that it is generally best not to use the same key for
> both pure and pre-hash signatures, we are currently inclined to use a
> single identifier for the public key (e.g., id-alg-slh-dsa-sha2-128s)
> regardless of whether the key will be used to generate pure or pre-hash
> signatures. An example of where this flexibility could be helpful would be
> in a PKI. A CA might use pure signatures to sign certificates, but use
> pre-hash signatures to sign CRLs. While certificates may be small enough to
> sign in a pure mode, CRLs can become very large. Also, if there is a
> concern about needing to depend on the collision resistance of the hash
> function when using the pre-hash option, this is less of a concern with
> CRLs. An attacker may provide a certificate request message that will be
> used in the generation of the certificate, but it would be much more
> difficult for an attacker to have any impact on the contents of a CRL (in a
> way that could create a collision).
>
> We would appreciate any feedback you may have on this issue.
>
> Thank you,
>
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/0ec37c8d-a78e-4630-af5e-0ac1ad1177d4%40nist.gov
> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/0ec37c8d-a78e-4630-af5e-0ac1ad1177d4%40nist.gov?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/bc01337638364bf9a01ba1cabdd8a8aa%40amazon.com
> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/bc01337638364bf9a01ba1cabdd8a8aa%40amazon.com?utm_medium=email&utm_source=footer>
> .
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to