-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <[email protected] il.com>, Wei Chuang <[email protected]> writes
>I'm announcing the Internet-Draft for the "Domain Name specification for >DKIM2". >https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/02/ > >DKIM2 intends to be compatible with the existing DKIM installed base of >keys hence this part of the specification is essentially the same as >RFC6376 with an update for more modern algorithms. However to prevent >ambiguity with the parent document, this document carves out a subset meant >to be used by DKIM2 and puts it in a separate Internet-Draft. It also >provides a place to document future changes for DKIM2. Comments welcome. First I want to thank Wei for creating this document ... our discussions around DKIM2 led us to conclude that we did not want to create new keys for our new protocol but to re-use existing "DKIM1" keys. However, we feel that in the fullness of time DKIM1 will fall out of use and having the new protocol rely on some sections of 6376 (and all of 8463) would be inconvenient for future developers. Whilst stressing that the purpose of this document is not to actually change anything really significant about the way that DKIM1 keys are stored and used (in either DKIM1 or DKIM2) I think that we should take the opportunity to assess what is actually being used in practice and to deprecate parts of the design that have not turned out to be useful (or used at all ?). To that end I wonder if the people who collect DKIM keys at scale and analyse what they see (they publish data about key lengths from time to time for example) are able to inform us as to which tags are actually being seen in the wild ??? Anyway: RFC6376 lists the fields which are actually needed for things to work: v= version h= hash function k= signing algorithm p= public key material but it also provides for n= notes for humans s= service type t= flags y testing s match to i= required I rather suspect that n= is seldom encountered (sysadmins document what they are doing at complete different stack levels); s= was a Good Idea At The Time but other protocols want their own key definition schemes rather than piggybacking here; and t= is commonly seen but pointless... We don't need, IMO, to complicate verifiers by telling them that although there is a DKIM signature (t=y) it isn't one really because we are hoping they will help us in their testing (they won't, they will reject the mail !) and i= (I'll leave looking up that obscurity as an exercise for the reader) is seldom used So I would suggest moving these 3 tags to a different section, indicating that DKIM1 verifiers may take notice of s= and t= but that DKIM2 verifiers will not. - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBaHc+6GHfC/FfW545EQJGxgCfdpnvegYmNz91v0lqqkPdclLU1LgAoOLu RQXGbK/yHAm3X7abIdKXf7ty =ghLN -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
