I'm wondering if people who are arguing the difference between a MUST on
the signing end versus a set of SHOULD/MAY are confusing the choice of
terms "implement" versus "use".
I think Ned is saying that we MUST implement both on the signing end,
but we SHOULD use SHA-256 and MAY use SHA-1 (dependent on performance /
security tradeoffs).
Tony
Ned Freed wrote:
>> 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
