Are there any export or other restrictions on SHA-1 or SHA-256 at this time?

Otherwise, sounds like a reasonable compromise. Late binding to pay the
price when we need to solve the problem.

- Ralph


On 2/8/06 4:13 PM, "Ted Lemon" wrote:

> I just had a conversation on the phone with Sam Hartman, which I hope will
> turn out to have been constructive. Basically, Sam agrees that it's
> unlikely that we will need to change the hash algorithm in the future, but
> won't go so far as to say that he's sure we won't.
>
> So what he asked us to do is to put an algorithm identifier on the DHCID, but
> not make any other changes (we could change to SHA-1 or SHA-256 as our
> initial algorithm, and that might mollify some folks; since it's basically a
> search and replace on the document, I think it's worth doing).
>
> The idea is that in the unlikely event that we at some future date need to
> change the hash, then AT THAT TIME we write a draft that tells us how to do
> updates in the transitional state where more than one hash might still be
> present in the DNS. For now, we just put the identifier there and don't
> change anything else.
>
> This seems like a reasonable compromise - since we're claiming that we're
> never going to need the additional complexity, hopefully this postpones the
> work to describe and implement that complexity forever; if it turns out that
> we're wrong, we have a path forward.
>
> I can go more into the reasons why we agreed on this particular approach if
> anyone's interested, but unless you are, I'll just leave it at that.
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: