----- Original Message -----
From: "Earl Hood" <earl(_at_)earlhood(_dot_)com>
To: "IETF MASS WG" <ietf-mailsig(_at_)imc(_dot_)org>
Sent: Friday, July 29, 2005 1:08 PM
Subject: Re: SSP - 3rd party Signers - Definition/Usage
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.
Does it matter that the existing signature is valid or not?
Right, verification was implied in each case.
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
I do not think the ISP can use CUSTOMER.COM, unless the nameserver
for customer.com contains the proper key data for the OA.
Right, but that was the initial assumption. But I think you probably made
the logic programmable now. :-)
if the customer has an OA SSP, then use the OA domain for the signature
domain (d=). Otherwise the signer should use the signer domain.
This gets into the key management policies of the ISP. If the ISP
is hosting the customer.com domain, it should probably put the key
data in customer.com DNS and not isp.com DNS. All messages it sends
out for customer.com would always use d=customer.com (and possible
an appropriate i= tag).
I think you are right. The point I was trying to make is that the final
verification has to work in BOTH cases (in regards to OA SSP 3rd party
checking) regardless of whose key was used for signing. So even if
d=ISP.COM was used, it could only be done because the OA SSP allowed for it.
If ISP does not have control over customer.com nameserver (but the
customer does), then the customer must define proper key records
to facilitate ISP doing signing (if allowed by OA SSP or hosting
agreement, see below).
Now, if the ISP does not support, or allow, the customer to define
a DKIM signing key for customer.com, then the ISP can never use
d=customer.com, and it can never sign messages with an OA domain of
customer.com unless 3rd-party signing is allowed by the OA SSP.
This sound right. It will probably all depends on whether the customer has
the capability to create the records himself.
Option 4: o=! EXCLUSIVE (signature required, no 3rd party)
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:
This will depend on the hosting arangement between the ISP and the
customer. If the ISP is allowed to act as an agent for customer (due
to (legal) agreement), then the ISP can sign the message using
d=customer.com.
So the ISP in completely hidden? Again, I am thinking how the final or
downlink verification is going to work. Is this a source for phishing? How
will the information be conveyed to the user? Can it be detected?
I guess the main extract from this is that the ISP can not be the signer as
an "Exclusive" entity unless the ISP has an (legal) agreement to do so with
the customer. All verifiers will be clueless that a 3rd party signing has
taken place on behalf of the OA. All verifiers will view this as an
exclusive, single signing mail.
Personally? Exclusive is exclusive. If the customer wants exclusive, then
that means he has has a SMTP server doing the signing. The ISP should not
be involved.
Option 5: o=. NEVER (no mail expected)
The ISP should reject all mail from the customer.
Sounds correct. Of course, such rejection may occur at the message
submission level since the customer may not even have the ability
to submit messages to the ISP MTA.
Which now brings pressure to add SMTP level instant rejection logic because
we certainly don't we to allow this to become a source of bounce attacks.
:-)
Option 6: o=^ USER
I don't know enough about this option.
Hmmm. According to the DKIM SSP draft, per user policy records can be
defined with the record:
user._policy._domainkey.<domain>
So if o=^ is specified at:
_policy._domainkey.<domain>
Then the verifier must query user._policy._domainkey.<domain> for
the SSP.
Ok, we have 2 lookups?
- _policy._domainkey.<domain> yields o=^
- user._policy._domainkey.<domain>
ok.
My comments about this:
* How "user" is determined by the verifier is not specified in the
draft. Is "user" the <local-part> of the OA address?
* It only takes one user of the domain to have a user-level SSP to
require user-level SSP records for all users. Why? In order to
support a per user SSP, o=^ has to be defined at the _domain_ level.
Therefore, once one user has an SSP, the DNS admin must define
user-level SSP for all users since the o=^ causes verifiers to
query for a user SSP.
Ahhh, I see your point. Sounds like a fall back (domain level policy) is
needed for a USER policy.
One thing that cross my mind about the tags themselves if whether they are
limited to just one character. Would it be possible to have:
o=^! -- USER, otherwise EXCLUSIVE
or example?
The per user SSP is close to my
<local-part>._policy._domainkey.<domain>
comments, but it appears that verifiers should first check for
per user SSP, and if not defined, check for domain-level SSP (due
to comment above about o=^). This potential requires to DNS lookups
by the verifier, but this may be neglible compared to the overall
cost of verifing/processing a message.
Right. At this point of the process, the toll has been paid already :-)
The DKIM SSP spec also needs to clarify how "user" is determined
by the verifier.
I agree. Are the spec authors reading any of this?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com