Ned Freed wrote:
the problem is making sure that transitions are possible.
This is why having two mechanisms is a good idea - without
two agility doesn't get tested and likely will not work
when we really need it.
A "good idea" isn't necessarily expressed as MUST.
Quite true but totally irrelevant. You're confusing the rationale for there
being a MUST implement for signers with the rationale for the specification
having two algorithms. The former is done to insure interoperability, the
latter to vet algorithm agility. These aren't completely disjoint goals, but
they're pretty close.
Violating a MUST means that things break and cause harm.
Which is exactly what will happen if there is no mandatory-to-implement signing
algorithm. That's why there needs to be at least one MUST implement, unlike the
signers SHOULD SHA-256 MAY SHA-1 you advocated.
MUST is also
not necessarily used to promote a certain way of implementing
a good idea like agility.
I'm afraid this is a strawman since the reason for there being a MUST has
almost nothing to do with insuring agility.
Instead of "edit config file and
select SHA-256" agility could be also implemented by "get and
install fresh package from where you got the last package".
Not if the implementation doesn't support SHA-256 or SHA-1 signing and there
are no packages to add such support.
I can see a SHOULD here, but no MUST. Probably it's one of
the usual MUSTard interpretation issues, and we actually mean
the same thing.
I don't think so. I think you're completely missing the point.
If verifiers MUST support SHA-256, then it's fine if signers
support only SHA-256. Why a "MUST SHA-1" for signers if they
don't want to use it ?
Another strawman. I don't have a problem with SHA-1 being a SHOULD, although a
MUST is also fine. My problem is there not being any mandatory-to-implement
signing algorithm at all.
Maybe you want a "SHOULD support two
algorithms, and at this time one of them MUST be SHA-256, the
other MAY be SHA-1". Or something else you talked about here,
whirlpool or whatever.
There's no "maybe" about it. I have been completely consistent here. Signers
and verifiers need to have at least one MUST implement in common, and it needs
to be the best algorithm choice we currently have available. And if past
history is any indication we don't have a choice in this. I've seen what
happens to specifications that reach the IESG that allow compliance without
assuring interoperability and specifications that try to go with inferior
crypto choices.
This then translates to MUST implement SHA-256 signing and verification.
As for SHA-1 the two reasons for having it are (1) We need a second algorithm
to insure agility and (2) Backwards compatibility. I would satisfied with a
SHA-1 implementation MUST for verify and SHOULD for signing, but MUST for both
is better as it vets agility more.
BTW, a conforming implementation could be a rather expensive
feature with an accredited SHA test lab and registration fee.
I doubt very very much this is a real concern for most implementors, one way or
another. And on a personal note, I have been through an accreditation process
twice and was singularly unimpressed both times.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html