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:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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