On Oct 24, 2006, at 11:49 AM, Jim Fenton wrote:
Hallam-Baker, Phillip wrote:
6.3
11. The Protocol MUST NOT be required to be invoked if a valid
first party signature is found.
Should be:
The Protocol MUST NOT be required to be invoked if a valid first
party signature that satisfies the
> From: Stephen Farrell [mailto:[EMAIL PROTECTED]
> Hallam-Baker, Phillip wrote:
> > If you treat messages signed with an algorithm you do not
> understand as policy violations you are going to reject
> legitimate messages.
>
> Since I don't agree that the premise applies, the rest is moot
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of
the IETF.
Title : DomainKeys Identified Mail (DKIM) Service Overview
Author(s) : T. Hansen, et al.
> From: Jim Fenton [mailto:[EMAIL PROTECTED]
> > If I look at the email and find a satisfactory signature I
> am done. If I don't find any signature at all *or I find only
> a weak signature* I need to look at the policy.
> >
> I don't see why we need to introduce shades of grey (i.e.,
> va
Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:[EMAIL PROTECTED]
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a
signature of type B"
Now consider a recipient that only supports verificat
Hallam-Baker, Phillip wrote:
> 6.3
> 11. The Protocol MUST NOT be required to be invoked if a valid first party
> signature is found.
>
> Should be:
>
> The Protocol MUST NOT be required to be invoked if a valid first party
> signature that satisfies the cryptographic criteria of the recipient is
> From: Stephen Farrell [mailto:[EMAIL PROTECTED]
> > Consider the following two policies:
> >
> > X: "Every email has at least one signature"
> > Y: "Every email has a signature of type A and a
> signature of type B"
> >
> > Now consider a recipient that only supports verification of
On Oct 24, 2006, at 9:54 AM, Stephen Farrell wrote:
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a signature of type B"
Now consider a recipient that only supports verification of
signature type
Thanks for persevering Phill,
Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:[EMAIL PROTECTED]
Hallam-Baker, Phillip wrote:
Your restatement of my point misses the point entirely:
IF there is a signature that the recipient can use
I think you mean "IF there was ever a ..."
THEN
> From: Stephen Farrell [mailto:[EMAIL PROTECTED]
> Hallam-Baker, Phillip wrote:
> > Your restatement of my point misses the point entirely:
> >
> > IF there is a signature that the recipient can use
> I think you mean "IF there was ever a ..."
> > THEN the recpient should know that there is suc
Yeah!
(Let the games begin...)
d/
The IESG wrote:
The IESG has received a request from the Domain Keys Identified Mail WG
to consider the following document:
- 'DomainKeys Identified Mail (DKIM) Signatures '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
Hallam-Baker, Phillip wrote:
Your restatement of my point misses the point entirely:
IF there is a signature that the recipient can use
I think you mean "IF there was ever a ..."
THEN the recpient should know that there is such a signature
and s/is such a/was ever such a/
But why? The cons
Your restatement of my point misses the point entirely:
IF there is a signature that the recipient can use
THEN the recpient should know that there is such a signature
If this condition is not met an attacker can perform upgrade and downgrade
attacks in which the attacker attaches a bogus signa
The IESG has received a request from the Domain Keys Identified Mail WG
to consider the following document:
- 'DomainKeys Identified Mail (DKIM) Signatures '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please se
Phillip,
"since we will not be specifying compromised algorithms initially the only code
path that requires implementation is what to do when you have a signature
present that you do not support. We absolutely do need to have a mechanism that
allows the verifier to know that it should expect the
My Technical opinion.
This 6.3 provision #11 makes no sense to me.
>From a design standpoint, the better system is probably going to end up
looking up all domains because that will guaranteed a consistent security
check.
The only reason I see this provision exist, nothing to do with logic, but
s
16 matches
Mail list logo