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.

Sign up for GitHub

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

Suggestions by Mike on PR #50 #55

Merged
merged 3 commits into from
Dec 11, 2024
Merged

Suggestions by Mike on PR #50 #55

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e74f1c5
Suggestions by Mike on PR #50
bwesterb Dec 4, 2024
3d88333
Update draft-ietf-lamps-dilithium-certificates.md
bwesterb Dec 4, 2024
6c99cca
Update draft-ietf-lamps-dilithium-certificates.md
bwesterb Dec 4, 2024
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
17 changes: 10 additions & 7 deletions draft-ietf-lamps-dilithium-certificates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -400,19 +400,22 @@ process can be separated into a pre-hash step and a core signature
step in order to ease operational requirements around large or
inconsistently-sized payloads. This can be performed at the
protocol layer, but not all protocols support it.
An example in [RFC5280] is the certificate revocation list
Examples in [RFC5280] are certificate and certificate revocation list
(CRL) data structures, that do not include message digesting before signing.
This makes signing large volumes of large CRLs challenging.
This can make signing large CRLs or a high volume of certificates
with large public keys challenging.

As mentioned in the introduction, pure ML-DSA signing itself
supports a prehashing flow by splitting the operation over two
modules. In this section we make this "ExternalMu-ML-DSA"
more explicit.

There are two steps. First an `ExternalMu-ML-DSA.Prehash()`
followed by `ExternalMu-ML-DSA.Sign()`. Together these operate
as `ML-DSA.Sign()` from [FIPS204] and thus create exactly the same
signatures as regular pure ML-DSA.
followed by `ExternalMu-ML-DSA.Sign()`. Together these are functionally
equivalent to `ML-DSA.Sign()` from [FIPS204] in that they create
exactly the same signatures as regular pure ML-DSA, which can be
verified by the unmodified `ML-DSA.Verify()`.

An ML-DSA key and certificate MAY be used with either ML-DSA
or ExternalMu-ML-DSA interchangeably.
Note that ExternalMu-ML-DSA describes a different signature API from ML-DSA
Expand All @@ -421,8 +424,8 @@ software cryptographic modules.

Note that the signing mode defined here is different from HashML-DSA
defined in [FIPS204] section 5.4. This specification uses exclusively
ExternalMu-ML-DSA for pre-hashed use cases, and thus HashML-DSA as
defined in [FIPS204] and identified by `id-hash-ml-dsa-44-with-sha512`,
ExternalMu-ML-DSA for pre-hashed use cases, and thus public
keys identified by `id-hash-ml-dsa-44-with-sha512`,
`id-hash-ml-dsa-65-with-sha512`, and `id-hash-ml-dsa-87-with-sha512`
MUST NOT be used in X.509 and related PKIX protocols.

Expand Down
Loading