[ietf-dkim] Binary algorithms and algorithm spoofing during a transition.

[Douglas Otis <[e-mail]>]

,---
| 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