We have chosen a literal, perhaps rigid, interpretation that the key
record must fail validation if it implies lack of support for sha256,
e.g. contains "h=sha1;".
Well, gee, if they meant "every signing key must announce SHA256" it
could have said so in so many words.
In an academic sense, I require signers to appear (and hopefully
*be*) RFC compliant because it's important - like stopping at a red
light even if nobody else is around. Practically, operationally, I
feel like I'm being silly.
Stepping back a little, it's incredibly hard to write totally
unambiguous definitions of anything. Back in the 1960s and 1970s
there was a vogue to write standards in entirely mechanical terms.
The Algol 68 spec was written in a two-level grammar that almost
nobody could follow, and the ANSI PL/I standard was written as 300
pages of transformations of an abstract tree machine. "You don't have
to understand it, you just have to implement it." Well, they were
wrong. Like any 300 page program, it had bugs, which were pretty
obvious if you understood what was going on, not so much if you
didn't.
So in a situation like this, if you're reading a standard and it seems
to be suggesting that the authors want you to do something silly, it's
usually safe to asssume that they don't. They either made a mistake,
or there's another interpretation. Fortunately, for IETF standards
most of the authors are still around, so it's not hard to find them
and ask.
In this case (since I was there), I know the intention was that
different keys can announce different things, and the point of h= is
to allow signers that have been using SHA1 to deprecate it as they
shift to SHA256, perhaps rather quickly if someone finds a really bad
SHA1 crack.
Finally, remember the "as if" rule. You can do anything you want, so
long as the results are the same as if you literally implemented the
spec. If you have one signer that implements both SHA1 and SHA256,
but chooses to sign with SHA1, and another signer that only implements
SHA1, the signature and the key in the DNS could be exactly the same.
So if you are seeing something that could have been produced by
someone that implements both, you're morally obliged to assume that
they do.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops