Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added mention of pure ML-DSA and text about CRLs. #31

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions draft-ietf-lamps-dilithium-certificates.xml
Original file line number Diff line number Diff line change
Expand Up @@ -119,6 +119,12 @@
<xref target="RFC3279" format="default"></xref> did for classic cryptography and
<xref target="RFC5480" format="default"></xref> did for elliptic curve cryptography.
The private key format is also specified.</t>
<t><xref target="FIPS204" format="default"></xref> defines two versions of ML-DSA, the pure and the
pre-digest version. Only the former is specified for use in this document.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose we remove "The size [...] ML-DSA performance.", and add

Pure ML-DSA (in contrast to SLH-DSA) allows for streaming the message that has to be signed. The only advantage of the pre-digest version, is that it allows a different hash to be used for hashing the message.

Copy link
Contributor Author

@csosto-pk csosto-pk Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pre-digest people do not argue that you cannot stream the message. Their point is that maybe I don't want to stream it to the HSM over its slow bus. I may want to just send the digest of the message and sign that especially if the message will be signed a lot of times. I don't fully buy it, but that is their main argument.

The size of the X.509 content signed in most certificates is small enough to not pose a
challenge with pure ML-DSA. For CRLs, CRL signing does not occur too frequently for ML-DSA
performance to be significant concern. Even then, CRL sharding is available to limit the
CRL lists to a size that does not affect ML-DSA performance. </t>
<section numbered="true" toc="default">
<name>ASN.1 Module and ML-DSA Identifiers</name>
<t>An ASN.1 module <xref target="X680"/> is included for reference purposes. Note that as per <xref target="RFC5280"/>,
Expand Down