[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Thomas
Roessler
It's probably as easy to extend either S/MIME or PGP/MIME to
make some statements about the parent message entity's
headers as it is to develop and deploy DKIM.
The problem is not how easy it would be to extend the S/MIME or PGP
spec, the problem is that any MIME based scheme depends on support in
the legacy base that simply is not there.
The primary goal of DKIM is to write a signature spec that does not
cause any recipient to receive a negative user experience in in any
circumstance whatsover.
Adding S/MIME signatures to a message causes an unacceptable user
experience in about 5% of cases. Examples include "WARNING THIS MESSAGE
WAS SIGNED" or Eudora stripping out the attachments and putting them in
a separate directory it never empties.
I did propose a mechanism for use of S.MIME at the start of MASS, Jon
Callas of PGP pointed out that they have already implemented essentially
the same mechanism and it does not work well enough in practice due to
forwarders.
Things are even worse if you attempt to extend S.MIME beyond the
original assumptions. At that point most existing MUAs start to give
unacceptable experiences.
See above, that's not by itself a reason to start with an
entirely new protocol, when one could (maybe) tweak an existing one.
I do not care about the number of protocols, it is not like we have not
given S/MIME and PGP a pretty good trial.
I would much rather look at the assets we have and seek to maximize
their use:
* PKIX - works pretty well for establishing trust relationships
* Full stack is pretty heavyweight
* XKMS - Fully specified and has support from major vendors, little
deployment
* Compact, negligible client impact
* S/MIME, PGP Encryption - Both work acceptably for end to end
* In practice applications may need document lifecycle security
or
edge encryption may be sufficient
* Both lack an adequate key discovery mechanism
* S/MIME, PGP Signature - Both are unfortunately an afterthought
* Both assume verifier has special client
* Impact is not acceptable
* Both lack a policy layer so lack of signature means little
I think that DKIM provides a useful bootstrap mechanism for
cryptographic email security. Even if you believe that only end-to-end
security is acceptable the best way to get deployment is to start with
specs that can be ubiquitously deployed without negative impact:
Phase One A:
Deploy DKIM, major email providers sign 100% of outgoing email
Phase One B:
Linkage to accreditation mechanism allows for visible indicata
presented to end recipient (via PKIX Logotype)
Phase Two A:
Client based implementations allow end to end signature
Use XKMS/XKRSS for management of private key
Phase Two B:
XKMS/XKISS Locate mechanism provides necessary encryption policy
infrastructure (can I send encrypted email to
Alice(_at_)example(_dot_)com)
Exisiting PGP & S/MIME package formats are re-used
Phase Two C:
Enterprises with complex PKI requirements make use of XKISS
validate to delagate PKI complexity to trusted service.
(e.g. Federal bridge CA).
Phase Three:
Document lifecycle encryption mechanisms introduced.