Draft-specific Comments:
* Section 1.1
You mention a trusted third party is not required. However, is
should be allowable, and I do not see anything in this draft that
supports a trusted-third-party system. For example, the support
for X509 certificates of signing keys should be allowed.
I'm not sure what form this "support for trusted third
parties" would take. My major concern in this area isn't
really a technical/specificaiton issue, but rather regarding
the form an actual service using this specification would
take. In particular, one sort of trusted third party setup I
definitely want to see is one where service providers sign
outgoing mail and verify incoming mail. Is this what you're
asking for?
I think that we need to have the ability to support outsourced service
provision and trusted third party provision in the traditional sense of
outsourced accreditation.
The draft certainly should not repeat any of the work done in PKIX,
XKMS, SAML etc but it should allow the sender to notify recipients that
a key exists for a given DKIM signing key record.
This is a really straightforward extension:
x=x509cert|http://certs.com/cert1192873.x509
x=saml|http://saml.org/assertion2222.xml
[Jon can specify a PGP link]
The semantics of such records are well established in the corresponding
standards forums.
The business models of the CAs and the levels of authentication are
irrelevant to DKIM.
Clearly there is going to be a linkage from DKIM records to TTP
infrastructure, it would be good to specify it in the core rather than
risk incompatible extensions.
[If folk want to argue for rfc2822 style tagging I am quite happy with
x509cert=http://certs.com/cert1192873.x509 as well.]
More generally, I think the "simple" appraoch does too little
and the "nowsp" does too much. As you say, dropping all the
internal space from the body leaves the door open too far.
I don't see how this is likely to result in a vulnerability unless the
sender is complicit in the construction of the message.
What we are trying to do here is quite limited, provide accountability
for message senders for purposes of spam control and prevent the type of
eggregious impersonation messages used in phishing attacks.
We are not providing a message security transport for transactional
purposes.
Let us remember here that empirically it has proved much easier to fix
broken crypto systems than to deploy over-engineered crypto systems.
If Alice is offering an email handling product then Alice is going to
come under a certain level of pressure to make the system compliant with
DKIM. I see nowsp as being a transitional technology that is likely to
be dropped as the infrastructure is upgraded. SSL has several ciphers I
would not choose to use, so does S/MIME. There presence does not really
do much harm as they are rarely used.
We clearly cannot only provide simple today given the infrastructure in
place. I do not see that as a permanent situation.