DKIM is not designed to support persistent signatures. This does not mean that we will not end up creating any under any cirscumstances.
I don't think that the x= has any effect from a legal standpoint. Courts currently regard an ASCII signature at the bottom of a message as rebuttable proof of creation. Any information in the header may be used to help prove that the message came from a particular source. Putting x= in the header does not affect that. If companies want to put disclaimers in their messages then they will do something like add a footer to state 'this is not a contract unless accompanied by a signed order, this is confidential do not read it, etc.' I think it would be useful to have a way to express some signer semantics in the signature or the key record. For example a way for a mailing list to say 'I am a mailing list', a way for an ISP or other open mail provider to say that and so on. > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell > (A message from the in-two-minds department:-) > > Michael Thomas wrote: > > Paul Hoffman wrote: > >> Note that the informative note only says what x= is not. > Leaving x= > >> in can also lead to silly states. > > > > What states might those be? > > I was also wondering about that. I guess that "x=" is a way > to make it crystal clear that this signature is (probably, > potentially) totally worthless in some court case in 5 years > time - a v. good feature (*). It would also help if someone > wanted to auto-generate new signing key-pairs at about the > latency with which their DNS stuff becomes available (but I > don't know if that info's available to the verifier via DNS - > is it?). Were we to ask verifiers to interpret "x=" as > guidance, and not as a way in which it MUST fail a signature, > then its optional inclusion may well help some layer above DKIM. > > However, on Paul's side of the argument, it is true that > many, if not most, people recognize that insisting upon X.509 > certificates having to have a notAfter date was a mistake. > So, there is a bit of prima-fasciae evidence that > signed-things-with-stupid-expiry-values > are problematic in some cases, though that analogy really > holds much better against the key record and not the > signature. To be concrete about problems-ensuing: I guess if > an MUA were DKIM-aware then "x=" > creates a dilemma for the MUA programmer in cases where the > mail isn't read until after the relevant time. I also > remember trying to shoe-horn a Kerberos thing into being > usable on an extranet - the clock skew was such a killer that > we had to open the window to ridiculous levels. > > Basically, YMMV! > > But, facts outweigh opinions: are there specific verifier > uses cases that act upon the "x=" value? > > Stephen. > > (*) <rant now="y"> If "x=" survives and becomes practically > used by verifiers then I would encourage DKIM implementers > who *really* want their signatures to be worthless at some > point in the future to agree to publish their old private > keys a little while after they are finished with using those > private keys. Giving everyone the means to repudiate old > transactions is IMO an excellent way to prevent a > lawyer/<<thing>> from pretending that you meant a signature > to be some kind of pseudo-non-repudiable thing! > </rant> > > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
