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

[Eric Allman]

Doug, I think you have assumed that we have accepted your suggestion 
that all future algorithms will be represented by number.  I, at 
least, have not.

You also seem to have missed my point about Posix.  Defining an 
abstract set of semantics and then doing a concrete profile (in this 
case, for the representation) looks great in theory, but for creating 
specs there is at least one datum that says the opposite.

Just to be clear: my proposal is that we leave -base as is.  One part 
of the DKK spec will be a mapping from the new binary form to the DKK 
form and vice versa.

eric


--On May 18, 2006 1:33:17 PM -0700 Douglas Otis 
<dotis at mail-abuse.org> wrote:

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