RE: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

> [mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave Crocker
> 1.  signers MUST have a TXT and SHOULD have a new RR.
>
> 2.  signers using RR indicate this with q=<newRR>.
>
> 3.  verifiers that see q=<newRR> SHOULD query for that RR but 
> MAY query for the TXT.
>
> Single query, no matter what the situation.  No failures, so 
> no fallbacks.
If the signer says q=TXT,newRR then the verifier should have an open choice.

The way I would expect to see new RRs phase in is with new signature
algorithms, in particular with signature algorithms that require larger
keys.

If we have base64 encoding we need 342 bytes to encode a 2048 bit key. That
does not allow much space for packaging, headers, links to certs or any of
the other stuff we are likely to be wanting.

One area where a new RR does provide a real tactical advantage though is in
widening out the data path. If the resolution path supports new RRs then
chances are that it will support 1024 byte lookups as well.

I would be quite happy with a new RR that was simply a new tag value for a
TXT record. But if we are going to declare new RRs and we are dealling with
crypto keys it's a bonus I will take. 

I would even be willing to mandate the use of the new RR in the draft
describing use of the new algorithm(s).

I would suggest a binary structure of the form:

Algorithm : Keyblob : text flags

Where Algorithm = a 16 bit field that is defined to be the same as the
DNSSEC identifier registry. Lets keep the IANA work to a minimum. I doubt we
would ever use more than 8 bits worth. If people need to they can define a
code for 'ASN.1 tagged blob'

Keyblob = length, <binary data>
        Crypto standards already define binary formats for key parameters,
reuse this DO NOT attempt to repeat the work, all you end up doing is making
unnecessary work.

Text flags
        A text field that is used to express any additional parameters that
might be required. Text is compact and flexible. For these data sizes space
delimited tag value pairs are as efficient as anything else.

smime.p7s
Description: S/MIME cryptographic signature

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