Ned Freed wrote: > The problem here isn't that someone could configure the use of some > random > signature algorithm and still remain compliant, but rather that > someone can > write an implementation which supports generation of neither SHA-1 nor > SHA-256 > signatures and still be compliant. As such, I suggest making support > for SHA-256 > on generation a MUST and SHA-1 a SHOULD. Both SHA-1 and SHA-256 need > to be > a MUST for verifiers. As my colleague Jim Fenton is fond of saying, I am reticent to impose restrictions on verifiers. The issue here is how much they wish to trust SHA-1, and there's no need for the IETF to dictate to them on this count, and there should be no need for us to update the document when we want to pronounce SHA-1 dead. That to me therefore rates a MAY. Just as Phil mentioned in another note, we're pretty close to a green field here. Had it been otherwise I might consider a SHOULD.
Eliot _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
