On Sat, 30 May 2009 18:12:47 +0100, Dave CROCKER d...@dcrocker.net wrote:
This note is intended to anchor a discussion thread for discusses one of
those
features, namely:
DKIM-Signature Header tags
x: Signature expiration
Expiration is a fairly common feature in signing
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John R. Levine
Sent: Friday, May 29, 2009 5:22 PM
To: Barry Leiba
Cc: DKIM List
Subject: Re: [ietf-dkim] chained signatures, was l= summary
DKIM is too complicated as
On Jun 1, 2009, at 3:24 AM, Charles Lindsey wrote:
On Sat, 30 May 2009 18:12:47 +0100, Dave CROCKER d...@dcrocker.net
wrote:
This note is intended to anchor a discussion thread for discusses
one of
those
features, namely:
DKIM-Signature Header tags
x: Signature expiration
On Fri, May 29, 2009 at 5:22 PM, John R. Levine jo...@iecc.com wrote:
I don't understand what cruft you think I'm talking about.
Telling people that it is reasonable to add a chain of A-R headers to
messages with broken signatures, and expecting recipients to apply some ill
defined algorithm
The IESG has approved the following document:
- 'DomainKeys Identified Mail (DKIM) Service Overview '
draft-ietf-dkim-overview-12.txt as an Informational RFC
This document is the product of the Domain Keys Identified Mail Working
Group.
The IESG contact persons are Pasi Eronen and Tim
On Jun 1, 2009, at 8:23 AM, Barry Leiba wrote:
John says...
Related question: whether or not you sign with l=, does anyone have
any software that does anything with l= other than use it to decide
how much of the body to check? Anyone seen an MUA that uses it to
manage message display? A
DKIM-Signature Header tags
x: Signature expiration
Expiration is a fairly common feature in signing specifications. But
DK and DKIM are different in that the public key is not distributed to
others, it's always under the control of the signer. Does this add
anything that
TXT RR tags
k: Key type
Much the same as h=, with the added issue that there's only one
possible key type right now, and if there were a need for k= in the
future it could be added in the same RFC that adds support for
anything other than RSA.
Dropping this to remove
On Mon, Jun 1, 2009 at 12:04 PM, Dave CROCKER d...@dcrocker.net wrote:
Steve Atkins wrote:
We're not doing anything particularly clever with DKIM identities,
though, just using them as a key to a domain based whitelist to
enable some automated handling of inbound email (FBL handling,
On Jun 1, 2009, at 8:41 AM, Siegel, Ellen wrote:
TXT RR tags
k: Key type
Much the same as h=, with the added issue that there's only one
possible key type right now, and if there were a need for k= in the
future it could be added in the same RFC that adds support for
anything
On 6/1/2009 10:49, Barry Leiba wrote:
On Fri, May 29, 2009 at 5:22 PM, John R. Levine jo...@iecc.com wrote:
I would really like to remove l= from DKIM to make it clear that it is not a
good idea to even try to guess the history of a message based on signatures
that don't verify and cover the
Barry Leiba wrote:
I think this is an important question for us to answer as we decide
what to do with it in 4871bis work, and I'd like to see some answers
either way (including We don't sign with it.) I'd especially like
to hear what verifiers do if it's present and it doesn't cover the
Siegel, Ellen wrote:
TXT RR tags
k: Key type
Much the same as h=, with the added issue that there's only one
possible key type right now, and if there were a need for k= in the
future it could be added in the same RFC that adds support for
anything other than RSA.
On May 22, 2009, at 11:40 PM, John Levine wrote:
When the body of the message has an open-ended length, the number
of attempts to produce a collision might be within what now seems
like a small number of attempts.
If SHA256 is that weak, we have worse problems than spoofed DKIM
On 6/1/09 6:38 PM, Steve Atkins wrote:
I would assume that if it were added back it would look exactly like it
does now, but with some additional options other than rsa.
Adding k= back or extending it to support other options would
both require RFC level effort, so I'd expect anyone doing
Eliot Lear wrote:
On 6/1/09 6:38 PM, Steve Atkins wrote:
I would assume that if it were added back it would look exactly like it
does now, but with some additional options other than rsa.
Adding k= back or extending it to support other options would
both require RFC level effort, so I'd
Dave CROCKER:
Let's make sure everyone is in synch about what is being proposed:
The suggestion is to drop a tag from the *DNS record*, /not/
from the *DKIM-Signature* header field.
What is the benefit of having the DNS record list possible
algorithms?
A protocol like this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 30, 2009, at 10:15 AM, Dave CROCKER wrote:
k: Key type
Much the same as h=, with the added issue that there's only one
possible key type right now, and if there were a need for k= in the
future it could be added in the same RFC that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 30, 2009, at 10:15 AM, Dave CROCKER wrote:
Folks,
In:
http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html
Steve Atkins posted a list of suggested DKIM features to drop.
This note is intended to anchor a discussion thread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 30, 2009, at 10:17 AM, Dave CROCKER wrote:
Folks,
In:
http://mipassoc.org/pipermail/ietf-dkim/2009q2/011959.html
Steve Atkins posted a list of suggested DKIM features to drop.
This note is intended to anchor a discussion thread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 1, 2009, at 8:33 AM, Siegel, Ellen wrote:
DKIM-Signature Header tags
x: Signature expiration
Expiration is a fairly common feature in signing specifications. But
DK and DKIM are different in that the public key is not
On Tue, Jun 2, 2009 at 4:22 AM, Jon Callasj...@callas.org wrote:
It is far more important for us to put SHA3 into 4871bis, as that will
be finalized in 2012, and if you *can't* use it in DKIM, people would
be justifiably miffed for us.
It'd actually be a good idea to delink specific encryption
22 matches
Mail list logo
