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

[Michael Thomas]

Right. I definitely don't want to have to deal with the union of 
encodings in any
given resource record. Yuck.

       Mike

Eric Allman wrote:

> 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
>>
>>
>>
>
>
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html