[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-allman-dkim-base-00.txt
> [mailto:owner-ietf-mailsig@xxxxxxxxxxxx] 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
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
Things are even worse if you attempt to extend S.MIME beyond the
original assumptions. At that point most existing MUAs start to give
> 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
* PKIX - works pretty well for establishing trust relationships
* Full stack is pretty heavyweight
* XKMS - Fully specified and has support from major vendors, little
* Compact, negligible client impact
* S/MIME, PGP Encryption - Both work acceptably for end to end
* In practice applications may need document lifecycle security
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@xxxxxxxxxxx)
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).
Document lifecycle encryption mechanisms introduced.