Eliot Lear wrote:
It's not a list. Dave got it wrong. Please look at RFC 4871:
I did, indeed.
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm okay
+1
with that. But let's at least have the debate
On Wed, 03 Jun 2009 14:58:06 +0100, John Levine jo...@iecc.com wrote:
The most common use of A-R will likely involve a secure channel
between the place where it's applied and the place where it's
interpreted, e.g., it's applied at a border MTA and it's interpreted
in a downstream MTA or MUA
On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
WTF is the point of inserting an A-R header if you are not willing to
take responsibility for what you have done by signing it?
And why should anyone else believe your A-R if you have omitted that
elementary
Charles Lindsey wrote:
On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
WTF is the point of inserting an A-R header if you are not willing to
take responsibility for what you have done by signing it?
And why should anyone else believe your A-R if you have
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Dave CROCKER
Sent: Wednesday, June 03, 2009 11:13 PM
To: ietf-dkim@mipassoc.org DKIM IETF WG
Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Eliot
Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm okay
+1
+1
with that. But let's at least have the debate based on facts.
yup.
+1
+1
Ellen
Siegel, Ellen:
Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm okay
+1
+1
with that. But let's at least have the debate based on facts.
yup.
+1
+1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm okay
with that. But let's at least have the debate based on
On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:
On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
WTF is the point of inserting an A-R header if you are not willing
to take responsibility for what you have done by signing it?
And why should anyone else
A competent mailing list admin would reject all messages from
dubious sources. But it would be foolish to assume that all such
admins are as competent as we would wish. So the mere fact that they
(re)sign messages does not prove their origin, except insofar as you
are prepared to have
On Jun 4, 2009, at 11:34 AM, Jon Callas wrote:
On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm
okay with that. But let's at least have the debate based on
Wietse Venema wrote:
Siegel, Ellen:
Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm okay
+1
+1
with that. But let's at least have the debate based on facts.
yup.
+1
+1
Enlightened
The issue of A-R headers being trusted only when signed by DKIM runs
counter to their intended use.
That's not necessarily true.
You're making hard assertions about a fuzzy situation. DKIM signing might work
just fine in certain installations. That's why RFC5451 suggests doing this
without
TXT RR tags
h: Acceptable hash algorithms
The spec needs to define the supported set of hash algorithms. There
may be some value in a signer being able to state that they're using
an algorithm that isn't supported, perhaps.
But unless there is a viable attack such that an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote:
TXT RR tags
h: Acceptable hash algorithms
The spec needs to define the supported set of hash algorithms.
There
may be some value in a signer being able to state that they're
On Jun 4, 2009, at 2:55 PM, Murray S. Kucherawy wrote:
TXT RR tags
h: Acceptable hash algorithms
If a site wanted to revoke instantly any signature previously
generated with rsa-craphash, couldn't it just revoke its old keys
and generate new keys, and begin signing with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote:
On Jun 4, 2009, at 11:34 AM, Jon Callas wrote:
On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the
key algorithm in the header? I
If a site wanted to revoke instantly any signature previously
generated with rsa-craphash, couldn't it just revoke its old keys
and generate new keys, and begin signing with rsa-goodhash?
Yes, it is a design feature of DKIM that an operational crypto error
can be instantly revoked by merely
Disagree. This feature is about better informing recipients as to the
status of the signature.
For the sake of enumerating implementations, the current libdkim implementation
does make a distinction between a signature that failed to verify and one that
couldn't be verified because the key's
On Jun 4, 2009, at 3:46 PM, Jon Callas wrote:
On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote:
On Jun 4, 2009, at 11:34 AM, Jon Callas wrote:
On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the
key algorithm in the header? I
On Jun 4, 2009, at 4:32 PM, Murray S. Kucherawy wrote:
Disagree. This feature is about better informing recipients as to
the
status of the signature.
For the sake of enumerating implementations, the current libdkim
implementation does make a distinction between a signature that
21 matches
Mail list logo
