ietf-mailsig
[Top] [All Lists]

Re: SSP - 3rd party Signers - Definition/Usage

2005-07-28 23:17:46


----- Original Message -----
From: "Earl Hood" <earl(_at_)earlhood(_dot_)com>

On July 28, 2005 at 23:34, "Hector Santos" wrote:

I thought the SSP was part of the key policy.  I naturally thought that
is
where it makes sense on a per KEY basis.

This assumes that the key is "owned" by the OA (Originating Address).

The SSP is what the OA defines, not what the signer defines.  The signer
controls the key, and the signer may not be the OA.

Ok I see.

Lets use an example of this possibility:

        hosted domains

ISP:           isp.com
customer:   customer.com

The customer is just using an MUA.  His domain is hosted by the ISP. All
mail is routed via the ISP.   The ISP offers an optional DKIM signing
service.

Who creates the key?  The ISP or the customer?

Lets assume the ISP creates its keys and allows the customer to define a OA
SSP policy record.  Lets use the recommended legend which I believe Jim
Fenton has endorsed:

   o=?  WEAK (signature optional, no third party)  (NEW - ARVEL)
   o=~  NEUTRAL (signature optional, 3rd aparty allowed)
   o=-  STRONG  (signature required, 3rd party allowed)
   o=!  EXCLUSIVE (signature required, no 3rd party)
   o=.  NEVER  (no mail expected)
   o=^  USER

The customer will see one of the above OS SSP policies

Option 1: o=?  WEAK (signature optional, no third party)

if message is signed,  the ISP must verify this message.

If the message is not signed, the ISP *MUST* not do any signing whatsoever.


Option 2:  o=~  NEUTRAL (signature optional, 3rd aparty allowed)

if the message is signed, the ISP *SHOULD* avoid additional signing just in
case the customer has purchased a new MUA with DKIM signing capabilities.

if the message is not signed, the ISP *MAY* sign and it can use either its
own ISP.COM or CUSTOMER.COM:

         DKIM-Signature: s=ispcustomer;  d=isp.com; ...
         From: user @ customer.com
or
         DKIM-Signature: s=ispcustomer;  d=customer.com; ....
         From: user @ customer.com


Option 3:  STRONG  (signature required, 3rd party allowed)

if the message is signed, the ISP *MUST* avoid additional signing just in
case the customer has purchased a new MUA with DKIM signing capabilities.

if the message is not signed, the ISP *MUST* sign and it can use either its
own ISP.COM or CUSTOMER.COM:

         DKIM-Signature: s=ispcustomer;  d=isp.com; ...
         From: user @ customer.com
or
         DKIM-Signature: s=ispcustomer;  d=customer.com; ....
         From: user @ customer.com

Option 4: o=!  EXCLUSIVE (signature required, no 3rd party)

if the message is signed, the ISP *MUST* AVOID additional signing just in
case the customer has purchased a new MUA with DKIM signing capabilities.

if the message is not signed,  I am not sure if the ISP should assume
responsibility for the signing, but if it does, it must ONLY use
CUSTOMER.COM only:

         DKIM-Signature: s=ispcustomer;  d=customer.com; ...
         From: user @ customer.com

The signer can not use its domain ISP.COM because the OA SSP policy said no
3rd party signing is desired.

Option 5:  o=.  NEVER  (no mail expected)

The ISP should reject all mail from the customer.

Option 6:  o=^  USER

I don't know enough about this option.

In all case, the verifiers needs to check all this. Otherwise what is the
point?  It has to make sense at both end of the spectrum.

I think it is worth considering supporting something like:

  <local-part>._policy._domainkey.<domain>

along with the domain level SSP, where <local-part> is the local-part
of the OA address.

This may definitely be useful for "affinity"-type domains where each
user may want to establish their own SSP from other users.  Also
possibly useful for business where some addresses may have more
restrictive SSPs (like for executives) vs other addresses.

I think this is good idea for a per user key (I think). I have to study the
USER policy more to understand it.

Overall,  would you agree that 3rd party signers and verifiers need to
respect the OA SSP?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


<Prev in Thread] Current Thread [Next in Thread>