Dave Crocker wrote in
<[email protected]>:
|On 10/30/2023 12:44 PM, Steffen Nurpmeso wrote:
|> Dave Crocker wrote in
|> <[email protected]>:
|>|On 10/29/2023 1:51 PM, Jan Dušátko wrote:
|>|> In my opinion, the verifiability of the place and time of origin needs
|>|> to be addressed, which is one of the reasons to use DKIM:
|>|
|>|While I think I understand the basis for thinking that DKIM is relevant
|>|to that determination, it isn't. It's semantics have nothing at all to
|>|do with authenticating origination, nor certifying content. Note, for
|>|example, that there can be (and often is) multiple DKIM signatures,
|>|affixed at different time.
|>
|> This is why it is so important that ARC makes headers directly
|> addressable in infrastructures that ignore the stack nature of
|> email.
|
|1. I don't understand what you mean by "headers directly addressable in
|infrastructures"
dkimpy of Scott Kitterman for example, in March this year:
commit 264230308cd5b47cb24f115f9f71d1ac334a6ca6
...
fix correct AMS header selection
When we are verifying the ARC seal we need to fetch the raw AMS header
from the header list. But it's not enough to return the first one we
find, since we may be interested in a different arc seal, we need
to search for the correct ARC index.
---
dkim/__init__.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dkim/__init__.py b/dkim/__init__.py
index 73d095f808..c2e77e9074 100644
--- a/dkim/__init__.py
+++ b/dkim/__init__.py
@@ -1293,7 +1293,9 @@ class ARC(DomainSigner):
# we can't use the AMS provided above, as it's already been
canonicalized relaxed
# for use in validating the AS. However the AMS is included in the AMS
itself,
# and this can use simple canonicalization
- raw_ams_header = [(x, y) for (x, y) in self.headers if x.lower() ==
b'arc-message-signature'][0]
+ raw_ams_header = [
+ (x, y) for (x, y) in self.headers if x.lower() ==
b'arc-message-signature' and b" i="+sig[b'i']+b";" in y.lower()
+ ][0]
|2. I am pretty sure ARC doesn't do that
See above.
|3. I don't understand how your response is relevant to what I wrote.
The thread is about addition of another algorithm.
I ...
|4. I don't understand how that is relevant to the current working group
|topic of a problem statement
(that is what the thread is about)
|>|DKIM says the signer attests to having 'some' responsibility in
|>|'handling' the message. That is fundamentally different than what your
|>|text means.
|>
|> Still the sheer size of "good enough" (tm) RSA is consumes space
...
|Is your response suppose to have something to do with my statement?
... disagreed with you. *That* 'some' and 'handling' is
a cryptographic signature operation. Even if the current non-ARC
email stack at times breaks inner envelopes and thus places them
and their producers in the twilight zone, to exaggerate that.
But this deficite is surely soon addressed by ARC.
The new algorithms also require significantly smaller certificates
(ie my US-ASCII armored S/MIME RSA public key is 2139 bytes, my
OpenSSH ED25519 one is 100 bytes, even though this compares apples
and oranges.)
And i reiterate what you did not quote, the Ed25519 algorithm with
all the benefits is already standardized by the IETF.
--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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
