I take John R Levine off, as he bounces my emails.
I add ietf-dkim.
Viktor Dukhovni wrote in
<zklm72pmjewpe...@chardros.imrryr.org>:
|On Mon, May 13, 2024 at 10:32:59PM +0200, Steffen Nurpmeso wrote:
|> "It is ok", but i want to say again (there were some private
|> emails and i have forgotten where i said what, i am talking too
|> much, anyway) that RFC 8463 uses *three* digests, whereas RFC 6376
|> wants *two*.
|
|The main disconnect here is that you're hyper-focused on implementation
|details, while the IETF deals with *specifications*.
(It should take more care for the former, .. if you look around.)
|The specification is clear and concise:
|
| The Ed25519-SHA256 signing algorithm computes a message hash as
| defined in Section 3 of [RFC6376] using SHA-256 [FIPS-180-4-2015] as
| the hash-alg. It signs the hash with the PureEdDSA variant Ed25519,
| as defined in RFC 8032, Section 5.1 [RFC8032]. Example keys and
| signatures in Appendix A are based on the test vectors in RFC 8032,
| Section 7.1 [RFC8032].
|
|Yes, this results in a different code path for RSA vs. EdDSA, due to API
|differences in, where RSA signing typically includes the digest
|operation, while pure EdDSA over a pre-computed message digest does not.
The API difference is that the latter do not allow "registering"
aka "passing through" a message digest that is part of the
"digest-sign" operation, because "they" have a built-in message
digest.
I want to point out one thing before you go into the wrong
direction, from my point of view, at least.
The non-"EC" (the four letter MTA maintainer wrote ECS, OpenSSL
umbrella them under OPENSSL_NO_ECX) algorithms like RSA allow for
life cycles like
Init .. Update .. Update .. Update .. Final
Whereas those like the one we talk about here only alow one-shot
operation. They mostly do not even allow to use the API used for
that purpose for decades, but only
DigestSignInit .. DigestSign
(where Init is not allowed to specify a user supplied message
digest.)
This is because they internally want (even several passes) over
all the data to be signed, including (several) message digest(s).
|This may be a modest inconvenience to an implementor, but so be it.
|
|If there is a issue of clarity it is actually in RFC6376, where the
Well, maybe yes, but not (from my point of view) because of what
you now explain (you are the expert there, i do not even start
thinking)..
|signature is described as a private-key (decrypt) operation over a
|pre-computed signature, but in fact for RSA what is used is an
|RSAwith<SomeHash> hash and sign operation.
|As explained upthread, the difference is the presence of the hash OID
|in the signed payload, which consists of:
|
| - PKCS#1 padding
| - Hash algorithm OID
| - NULL parameters
| - digest octet string
|
|Where a literal reading of RFC6376 might have expected:
|
| - PKCS#1 padding
| - digest octet string
|
|Because the algorithm signalling in the DNS TXT record, and, with the
|former, a naïve implementation might not check that the hash used in the
|signature is actually the one promised by the DKIM DNS record. One,
|might, e.g. accept an RSAwithSHA1 signature of the same headers and
|DKIM-Signature template (with "b=" empty).
|
|There really ought to have been more text in RFC6376 about what's
|actually expected, than just:
|
| NOTE: Many digital signature APIs provide both hashing and
| application of the RSA private key using a single "sign()"
| primitive. When using such an API, the last two steps in the
| algorithm would probably be combined into a single call that would
| perform both the "a-hash-alg" and the "sig-alg".
Maybe yes, there is need for clarification. To reiterate, RFC
6376 says
The Signer/Verifier MUST compute two hashes: one over the body of the
message and one over the selected header fields of the message.
And then it says
In hash step 2, the Signer/Verifier MUST pass the following to the
hash algorithm in the indicated order.
It also says
body-hash = hash-alg (canon-body, l-param)
data-hash = hash-alg (h-headers, D-SIG, body-hash)
signature = sig-alg (d-domain, selector, data-hash)
...
hash-alg: is the hashing algorithm specified in the "a" parameter.
...
signature: is the signature value produced by the signing algorithm.
sig-alg: is the signature algorithm specified by the "a"
parameter.
So if i now paste its
data-hash: is the output from using the hash-alg algorithm, to hash
the header including the DKIM-Signature header, and the
body hash.
then it is clearly against my point of view...
|Because that's not actually accurate, due to the inclusion of the digest
|OID in the signature payload in the "single" primitive.
...but the above says "two hashes". But despite that.
An Ed25519 sign operation alone creates three SHA-512 digests
which are incorporated into several further calculations. Whereas
for RSA it is, to the best of my knowledge, crucial to let it pass
over as few bytes as possible (for encryption as such i think
OpenSSL will refuse to do so after a certain limit), for EC with
its embedded digests it may be more expensive but even beneficial
to push more data rounds onto the embedded digests.
So maybe, and in hindsight to the RFC that i would try to publish
in fall if i am allowed to and if the email giants still have not
moved towards this RFC 8463, it might make sense to adjust the
data-hash in that it may come from hash-alg or be included via
sig-alg.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
