Subject: [ietf-dkim] ISSUE: SSP-02:Author Signature scope too narrow (Updates ISSUE 1519)

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Feb 2008 18:16:37 -0800

See:
https://rt.psg.com/Ticket/Display.html?id=1519

SSP-02:
2.8. Author Signature (too restrictive)

  An "Author Signature" is any Valid Signature where the identity of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) matches an
  Author Address in the message.

The structure of the draft has changed for both all and strict.  In  
reviewing the draft, the definition used in ASP-00 provides a far less  
problematic Author Signature definition.
See:
http://tools.ietf.org/html/draft-levine-asp-00

2.8. Author Signature (too simple)

  An "Author Signature" is any Valid Signature where the signing domain
  (listed in the "i=" tag if present, otherwise its default value,
  consisting of the value of the "d=" tag) matches the domain of an
  Author Address.

While the ASP definition is much better than the current SSP  
definition, other definitions can better recognize the signing domain  
as being authoritative for what messages are compliant with their  
signing policy.  The increased scope would allow greater freedom for  
domains that partition users into separate sub-domains where different  
policies are asserted.  When the From email-address domain applies a  
signature to the message, this indicates the message is compliant with  
their signing policies.  There might be a desire to limit the scope of  
this compliance to assure the scope of the signatures compliance is  
constrained by the key's g= and t= parameters such that the key being  
referenced could have been used for the Author Address as well.

2.8. Author Signature

Full scope Author Signature definition: (recommended)

  An "Author Signature" is any Valid Signature where the signing domain
  (listed in the "d=" tag) matches or is above the domain of the
  Author Address.

NON-NORMATIVE DISCUSSION: This definition permits signatures for
local-part restricted keys and sub-domain restricted keys to be
compliant with an assertion that all messages are signed.  The key
restrictions limit the domain's authority to indicate for whom
the signature was added (listed the "i=" tag).

Limited scope Author Signature definition: (conservative)

  An "Author Signature" is any Valid Signature where the signing domain
  (listed in the "d=" tag) matches or is above the domain of the
  Author Address.  The Author Address must also be contained within the
  scope of the key local-part and sub-domain range (listed in the
  key's "g=" and "t=" tags).

NON-NORMATIVE DISCUSSION: The key restrictions limit the domain's
authority to indicate for whom the signature was added (listed the
"i=" tag) as well as limit the ability of restricted keys to be
automatically considered compliant with the domain's signing
polices.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Feb 2008 11:28:21 -0000

>   key's "g=" and "t=" tags).

Yes, that is the only definition that is really correct, though the  
wording might well be improved.

    An "Author Signature" is any Valid Signature where the domain of the
    Author Address is a sub-domain of the signing domain
    (listed in the "d=" tag). Morover, the <local-part> of the Author  
Address
    must also be contained within the scope of the key local-part of any  
"g="
    tag.

Having just reread the relevant bits of RFC 4871, I cannot see what effect  
a tag "t=s" would have, since it just restricts what the domain of the  
"i=" tag may be, but that domain appears to play no part in the  
verification process. In fact, ISTM that sections 3.5 and 3.8 contradict  
each other. Perhaps someone could enlighten me on this.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Feb 2008 15:46:24 -0800

> https://rt.psg.com/Ticket/Display.html?id=1519

Also relates to issue 1399 "clarify i= vs. SSP" if I understand that 
correctly.

To briefly summarize, I understand Doug's issue to be the question of 
whether the local-part of an Author Address should be matched against 
the i= value, if a local-part is present in i=.

SSP matches the local part if present
draft-levine-asp-00 matches only the domain part
Doug is suggesting a third alternative:  to match the Author Address 
against the g= field in the key record used to verify the signature.

Doug, please verify that I understand the issue correctly before I 
invest a lot of keystrokes in responding.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 16:19:49 -0800

On Feb 13, 2008, at 3:46 PM, Jim Fenton wrote:

> To briefly summarize, I understand Doug's issue to be the question  
> of whether the local-part of an Author Address should be matched  
> against the i= value, if a local-part is present in i=.
>

Jim,

Almost.  Here is the 10,000 foot view from the two perspectives.

View 1: (recommended)

The verifier does not police how someone might make use of a DKIM key.

Restrictions on the key (g= t= parameters) only limit which identities  
can be associated with a signature.  Policy, on the other hand, is  
constrained only by DNS hierarchy.  When a domain signs a message for  
a group of users within different sub-domains, the message would be  
considered compliant with an "all" assertion when a valid signature's  
d= parameter is at or above the From email-address domain (referencing  
the policy).  The identity and header associated with a signature is  
not germane to DKIM policy.

View 2: (conservative)

The verifier should police how someone might make use of a DKIM  
restricted key.

Restrictions on the key (g= t= parameters) limit which identities can  
be associated with a signature.  In essence, the sub-domain and  
identity within the From email-address must be encompassed within the  
scope of the key's restrictions.  In the case of restricted keys, the  
key should be able to have provided a valid signature for the From  
email-address identity and domain (referencing the policy).  The  
identity and sub-domain associated with a signature is not germane to  
DKIM policy.  The signature might be on-behalf-of of some other  
identity within headers other than the From, or even in no header at  
all.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Feb 2008 16:50:53 -0800

> not germane to DKIM policy.

This seems like the rarest of situations:  Not only do you have multiple 
>From addresses in the message, which is rare to start with, but you're 
considering a case where the multiple From addresses come from different 
subdomains and optimizing for that case so that only one signature will 
work for any of them.  This seems like it's trying to redefine RFC 4871, 
where the default value of i= comes from the value of d=, and if a 
domain wants to sign for a subdomain it MUST include an i= tag with the 
name of the subdomain.  If a signature was supposed to be valid for any 
subdomain, RFC 4871 should say that.

So: -1
> identity within headers other than the From, or even in no header at all.

Ignoring the subdomain stuff (see above) I think this corresponds to 
what I said, although you're using the term "identity" where I'm using 
"local-part".  But what you want to do is check the key restriction 
against an Author Address, not the i= value, right?

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 17:24:16 -0800

On Feb 13, 2008, at 4:50 PM, Jim Fenton wrote:

>> Restrictions on the key (g= t= parameters) only limit which  
>> identities can be associated with a signature.  Policy, on the  
>> other hand, is constrained only by DNS hierarchy.  When a domain  
>> signs a message for a group of users within different sub-domains,  
>> the message would be considered compliant with an "all" assertion  
>> when a valid signature's d= parameter is at or above the From email- 
>> address domain (referencing the policy).  The identity and header  
>> associated with a signature is not germane to DKIM policy.
>
> This seems like the rarest of situations:  Not only do you have  
> multiple From addresses in the message, which is rare to start with,  
> but you're considering a case where the multiple From addresses come  
> from different subdomains and optimizing for that case so that only  
> one signature will work for any of them.

There is some confusion.  This is _not_ about multiple From headers.   
A message can be signed where there are multiple email-addresses  
within different headers that are also within the same domain. This  
situation is not rare at all.

> This seems like it's trying to redefine RFC 4871, where the default  
> value of i= comes from the value of d=, and if a domain wants to  
> sign for a subdomain it MUST include an i= tag with the name of the  
> subdomain.

When the key has not been restricted from being able to sign for the  
sub-domain, why would it matter what had been used in the i=  
parameter.  By the same token, the i= could be blank and the default  
would become the d= parameter.  Although this signature might not  
directly associate with the identity within the From header, it would  
still provide a valid signature.  Unless restricted by the key, there  
is no reason to assume the signature is any less trustworthy as a  
result.  The From identity is included within the signature's hash  
after all.

> If a signature was supposed to be valid for any subdomain, RFC 4871  
> should say that.

A signature can be valid without being associated with any specific  
identity.  Don't confuse being valid with being associating with a  
specific identity.  These are too entirely separate issues.

>> Restrictions on the key (g= t= parameters) limit which identities  
>> can be associated with a signature.  In essence, the sub-domain and  
>> identity within the From email-address must be encompassed within  
>> the scope of the key's restrictions.  In the case of restricted  
>> keys, the key should be able to have provided a valid signature for  
>> the From email-address identity and domain (referencing the  
>> policy).  The identity and sub-domain associated with a signature  
>> is not germane to DKIM policy.  The signature might be on-behalf-of  
>> of some other identity within headers other than the From, or even  
>> in no header at all.
>
> what I said, although you're using the term "identity" where I'm  
> using "local-part".

Identity may also include sub-domains and local-parts extending the  
range of the domain's signature.

>  But what you want to do is check the key restriction against an  
> Author Address, not the i= value, right?

First and foremost, the signature must be valid.  When a key is g=  
restricted, the i= parameter must conform to the g= restriction.  For  
the conservative view, this would be saying that restricted keys must  
be signing on behalf of the From header identity.  However, there are  
two separate key restrictions that come into play.  Each of these  
restrictions should be handled separately.  The t= parameter may not  
relate directly to the i= parameter.  In other words, local-parts may  
vary when the key is only restricted by the t=s parameter.

-Doug