Re: [ietf-dkim] Today's jabber #1271: Binary algorithms and algorithm sp

On May 18, 2006, at 1:59 PM, 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.
The critical aspect of the algorithm representation is to ensure  
there is no opportunity for exploitation during a subsequent  
algorithm transition.  Semantics must allow a verifier a method to  
confirm that the signer has offered a key with an unknown algorithm  
that matches the DKIM signature header field with an unknown  
algorithm.  Key algorithm representation == Signature algorithm  
representation.
When the query method indicates q=x, y; there could be conflicts  
where one algorithm's representation in the key is a number, and  
where the other method's representation within the key is a  
mnemonic.  Unknown mnemonic representations can not be mapped to a  
number.
One solution could have future algorithms represented as a number to  
avoid possible conflicts between mnemonic and number representations  
of algorithms.  An exception can be made where known mnemonics can be  
mapped to known numbers.
Of course, the binary key could use a mnemonic to represent the  
algorithm.  This added overhead may reduce how well this key extends  
for other uses, or might be less compliant with other protocols where  
numeric representations for the algorithm are common.  : (

> 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.
The base draft could be explicit and use the q= dns, dnsrr with  
definitions then referencing other drafts for full dependence.  This  
would simplify future updates where when perhaps just the TXT draft  
is obsoleted there is little affect on the base draft, for example.
Not fully sharing your concern, better independence is achieved where  
a token is used as a placeholder such as 1*(query-method-designator).
query-method-designator: see rfc-xxxx and rfc-xxxx.

The TXT draft could become a common template for the binary RR and  
other future drafts.  An abstraction is not required, although it  
should not be difficult to understand.  A place holder seems cleaner  
and would help keep straight which tags are contained in the  
signature and which are in the key.
If the base-draft stays the same, then the issue of algorithm  
representation still needs to be resolved for the TXT and future  
mechanisms.
Is there to be only one query mechanism per algorithm representation?

If all algorithms have a common representation, should this be  
numeric or mnemonic?
Perhaps a=x,y; q=j,k;  where algorithm x goes with query method j,  
and y goes with k.  There are many ways this can be resolved.

> 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.
This mapping must allow for unknown algorithms.  It is not a simple  
matter unless semantics provide a consistent means to confirm what  
algorithm has been offered by the signer, or the transition period  
allows undetected removal of the non-deprecated signature  
algorithms.  A bad actor could simply invent algorithms when pointing  
to a new key, where the verifier is unable to confirm the algorithm  
within the key does not match the algorithm found in the DKIM  
signature header field.  Ensuring this confirmation is always  
possible, thwarts any attempt at a spoofing the offered algorithm.   
This spoof could be detected prior to the verifier being updated and  
seems simple to achieve.
Although splitting the draft seems cleaner, retaining the TXT record  
within the base still needs the minor detail of algorithm  
representation sorted out.  Tagging keys as deprecated should also be  
defined, but this has a lesser impact on future semantic compatibility.
-Doug





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