Re: [ietf-dkim] Today's jabber #1271: Binary algorithms and algorithm spoofing during a transition.

[Douglas Otis <[e-mail]>]

On May 18, 2006, at 12:46 PM, Eric Allman wrote:

> I think it's valuable to have the base spec define a "must  
> implement" set of semantics.  Connecting that to the representation  
> will obviously differ depending on many things, not the least of  
> which being text vs. binary representations.
>
> Since -base is (now) only defining TXT, it seems to make sense for  
> that to remain the definition syntax.  [Posix tried to define  
> abstract semantics and then binding for each language.  This was a  
> disaster and after losing at least a year of time they went back to  
> using C as the definition language.]
>
> It probably does make sense clarifying that /any/ representation  
> has to include these basic values with the same semantics, but make  
> it clear that the syntax is specific to TXT records and may or may  
> not apply to others.  I tried to do that by saying that the defined  
> representation SHOULD be used for any text-based system, but  
> perhaps I didn't go far enough.


If the binary RR uses a binary representation for the algorithm, then  
within the base draft...

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


Could change to:

: a= (plain-text string or decimal positive integer
: 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 RFC3110 and
: draft-ietf-dnsext-dnssec-rsasha256.
:
: Verifiers must support (5) 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" / "rsasha256" / "5" / "tbd"
:
: Future algorithms will always be specified by number.

Or to avoid the draft dependency:

: a= (plain-text string or decimal positive integer
: representation of an 8-bit algorithm number used to
: generate the signature; REQUIRED).  When a number is used
: within the key, the same number MUST be used in the
: DKIM-Signature header field.
:
: Verifiers must support  rsa-sha-1 and rsasha256.
:
: ABNF:
:
: sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
: sig-a-tag-alg = "rsa-sha1" / "rsasha256" / 1*(DIGIT)
:
: Future algorithms will always be specified by number.

	
-Doug




>
> --On May 18, 2006 7:25:25 PM +0000 Mark Delany <MarkD+dkim@yahoo- 
> inc.com> wrote:
>
>> On Thu, May 18, 2006 at 11:55:51AM -0700, Michael Thomas allegedly
>> wrote:
>>> Mark Delany wrote:
>>>
>>> >> OLD:	TXT records are encoded as described in Section 3.6.1.
>>> >>
>>> >>
>>> >
>>> > So I've circulated the draft DKK to a couple of people to get the
>>> > roughest edges off.
>>> >
>>> > One of the big questions asked in that draft relates to the
>>> > relationship between TXT and DKK semantics. Which one is
>>> > authoritative and which one is a mirror? Or should base be
>>> > authoritative and both the TXT and DKK simply be particular
>>> > representations?
>>> >
>>> >
>>> Is there really any reason to force one to be the master of the
>>> other?
>>
>> Simply to avoid duplication of semantics. I was merely asking which
>> text is the source of truth and where should it reside. Also,
>> presumably if a DKK springs into existence, the TXT may well be
>> frozen at some point with new functionality only going into the DKK
>> RR.
>>
>>
>> Mark.
>> _______________________________________________
>> NOTE WELL: This list operates according to
>> http://mipassoc.org/dkim/ietf-list-rules.html
>>
>
>
> _______________________________________________
> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ 
> ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html