Dave Crocker wrote:
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
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
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
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
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
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
