,---
| a= The algorithm used to generate the signature (plain-text;
| REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";
| signers SHOULD sign using "rsa-sha256". See Section 3.3 for a
| description of algorithms.
|
| ABNF:
|
| sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
| sig-a-tag-alg = "rsa-sha1" / "rsa-sha256" / x-sig-a-tag-alg
| x-sig-a-tag-alg = hyphenated-word ; for later extension
'___
Change to:
: a= (plain-text or decimal representation of an 8-bit algorithm
: number used to generate the signature; REQUIRED). The number
: is defined in the algorithm table that supports the KEY, SIG,
: DNSKEY, RRSIG, DS, and CERT RRs. See RFC3755 and
: draft-ietf-dnsext-dnssec-rsasha256.
:
: Verifiers must support (3) RSA/SHA-1 and (tbd) RSA/SHA-256.
: ABNF:
:
: sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
: sig-a-tag-alg = "rsa-sha1" / "rsa-sha256" / "3" / "tbd"
:
: Future algorithms will always be specified by number.
When DKIM supports a binary key RR format, there will be a
requirement to confirm an unknown algorithm is supported by the
signer, when not supported by the verifier. This prevents an exploit
where a signature may proffer a new algorithm and use of a binary
key, but where the mapping of the text algorithm to a binary
algorithm representation that can not be known in advance. As such,
using a numeric designator ensures compatibility with future key
specifications while also preventing algorithm spoofing during a
transition phase, which may cause allowances to be erroneously granted.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html