Alessandro Vesely wrote in
<[email protected]>:
|On Thu 17/Jul/2025 01:45:45 +0200 Bron Gondwana wrote:
|> On Wed, Jul 16, 2025, at 17:05, Barry Leiba wrote:
|>> What's wrong with something like this:
|>> The verifier MUST support at least one of the signature algorithms.
|>> The verifier SHOULD check all the algorithms it supports.
|>> The signature MUST be valid for all signatures that are checked.
|>> ...and we add an explanation for the SHOULD.
|>
|> Yeah, I think I agree with you. When adding a new algorithm support \
|> I would be likely to put it in a "check but don't use" state, where \
|> I'd log the result to see if it was well implemented at either my \
|> end or the sending end, and once it looked like it was generally \
|> solid I'd turn it on for real.
|
|We could also add another result type for aggregate reports and A-R \
|headers,
|e.g. "neglected" to mean that it is supported but not verified. This \
|might
|help understanding when to stop signing with algorithm Q.
Ach am i happy to go in a week.
I think this is (a) much fuss about nothing, because the saving
of storing multiple algorithms in one header field instead of
simply duplicating a header field for a small time span (if it is
key rotation you talk about) is very small, and causes headaches
of lots of minimally good paid engineers that already goes into
the thousands of US dollars (estimated), where (b) the original
DKIM has quite an approach and (c) there is a highly iterated
and grown approach of rotation defined in the DANE related RFC
series -- if i would design something completely new, the work
done there should better be valued.
Btw in my very humble opinion (d) the saving of using name
compression is much higher, i have not looked at the other
proposal for some time, but if i see the consciously still
misconfigured IETF mailing-list this possibly ends up at i see
Date:From:To:In-Reply-To:References:CC:Subject:List-Id:List-Archive:List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe
(131 bytes), and if one designs from scratch this could be
massively reduced to for example
D:F:T:IRT:R:C:S:L=IAHOPSU[:non:shortcut:header:fields]
(26 bytes), which is a saving of over hundred bytes at each hop,
or multiple thereof for multiple algorithms, at each hop.
(One could then use counts, too, as in ..DKIM-Signature/3 to mean
three (3) DKIM-Signature header fields. It would be DS/3, then.)
Of course ACDC is DKIMv1, and a hundred percent compatible to the
adult and rock solid foundation of this widely deployed decade
old approach, so it cannot be done there.
Btw such an abbreviation thing i use in the MUA i maintain
An empty search expression tests for existence of the given
header fields (compare digmsg†). Some header fields may be ab‐
breviated: ‘a’, ‘f’, ‘t’, ‘c’, ‘b’ and ‘s’ will match
‘Author:’, ‘From:’, ‘To:’, ‘Cc:’, ‘Bcc:’ and ‘Subject:’, re‐
spectively, and case-insensitively. But for the existence test
‘Author’ indeed means all of ‘Author:’, ‘From:’, and ‘Sender:’.
The special header fields ‘header’ or ‘<’ can be used to search
in (all of) the header(s), and ‘body’ or ‘>’ and ‘text’ or ‘=’
will perform full text searches
Greetings, and Ciao! from Germany,
--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)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
