There will need to be an IANA registry of signing algorithms, and we
should actually point at that. Both key types ("rsa") and hash
algorithms ("sha-1", "sha-256") are pieces that will need to be
registered. We will need an IANA Considerations section dealing with the
registry process.
We could split the registration portion document out into a separate
document, or we could include it in the base. When MIME was first
created, descriptions of MIME media-type registrations and the registry
were all included together. It was eventually split out into separate
documents.
Tony Hansen
[EMAIL PROTECTED]
Scott Kitterman wrote:
> On 02/25/2006 16:56, Dave Crocker wrote:
>> My proposal for language to cover supported text was confounded by
>> suggesting some alternative language. Discussion since then has frequently
>> expressed agreement with my text, but even I am not sure what exact text
>> folks are agreeing with. I also think that Ned's point about the benefit
>> of citing sender-side support, versus what is actually sent, is
>> significant.
>>
>> Based on all that, here is what I think reflects groups consensus. Those
>> agreeing should say something simple, like "agree". Those disagreeing,
>> should say something simple, like, "I proposal the following alternate
>> text...".
>>
>> Here goes:
>>
>> A validator MUST support {SHA-1, SHA-256}.
>>
>> A signer MUST support {SHA-1, SHA-26}. A signer SHOULD use {SHA-256}
>> for its higher security strength. However a signer MAY use {SHA-1}, such as
>> for compatibility with an installed base, lower computational cost, or
>> easier implementation effort.
>>
>>
>> Consensus?
>>
>> d/
>
> I'm not experienced enough with IETF processes to know if the following would
> be a useful approach in an IETF context or not, but here goes anyway...
>
> In other venues that I've worked in I've run into problems before when a spec
> had to be reopened "just to fix one little thing" and then the next thing you
> know, the engineers are loose and the whole thing has been updated in an
> incompatible way. When there are aspects of a design the you KNOW are going
> to have to be periodically changed, it may be useful to break them out into a
> separate document so that the entire design doesn't get exposed every time
> you revise for the known item that will have to be updated. I'm thinking
> this may be a similar case.
>
> Might it be useful to break the exact crypto algorithm out into a separate
> (very short) RFC so that it can be revised as necessary? Something like:
>
> A validator MUST support all crypto algorithms listed as not deprecated
> in RFC ZZZZ or it's successors, initially {SHA-1, SHA-256}.
>
> A signer MUST support all crypto algorithms listed as not deprecated in
> RFC ZZZZ or it's successors, initially {SHA-1, SHA-26}. A signer SHOULD use
> the highest strength algorithm in RFC ZZZZ or its sucessors, initially
> {SHA-256} for its higher security strength. However a signer MAY use earlier,
> non-deprecated algorithhms, initially {SHA-1}, for compatibility with an
> installed base, lower computational cost, or easier implementation effort.
>
> The initial text for RFC ZZZZ would be along the lines of:
>
> For DKIM the following cryptographic algorithms are specified:
>
> Deprecated: None
>
> Required: SHA-1, SHA-256
>
> High strength: SHA-256
>
> ZZZZ then could be easily revised at the point it becomes clear what the next
> high strength hash algorithm is or if SHA-1 is determined to be broken to the
> extent it should be deprecated.
>
> None of this affects what has to be implemented now, but may make future
> transitions easier.
>
> Scott Kitterman
> _______________________________________________
> 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
