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 tha
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 algor
> 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'
>> 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"
-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
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
-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
> >> 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 vi
> 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
withou
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.
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
> 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 con
On Jun 4, 2009, at 5:20 AM, Charles Lindsey wrote:
> On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
> 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 bel
-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 fac
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.
> > 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
> -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
>
>
Charles Lindsey wrote:
> On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
> 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 omi
On Wed, 03 Jun 2009 17:13:02 +0100, Murray S. Kucherawy
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 step?
>
>
On Wed, 03 Jun 2009 14:58:06 +0100, John Levine 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 within the s
20 matches
Mail list logo
