As the veteran of many arguments about pseudorandomness and uniqueness, I
think
it's reasonable to consider a sufficiently long random string to be unique.
"high probability" actually makes it worse, because 99.99 is actually a
very high
probability but not really a security boundary. If you want
At 11:46 28/03/2017 Tuesday, Martin Thomson wrote:
>I agree with Jacob here. MUST seems appropriate, but requiring
>uniqueness absolutely imposes a constraint on server design that is so
>onerous that I would see it as impractical. (Also, the document
>doesn't really identify a scope for this
I agree with Jacob here. MUST seems appropriate, but requiring
uniqueness absolutely imposes a constraint on server design that is so
onerous that I would see it as impractical. (Also, the document
doesn't really identify a scope for this uniqueness, which would
probably be necessary if you had
In section 6.4.1. Replay-Nonce, it states: "The server should generate
the value provided in Replay-Nonce in such a way that they are unique to
each message, with high probability."
Should this not be: "The server MUST generate the value provided in
Replay-Nonce in such a way that they are unique
Forwarding on behalf of Erica Portnoy.
I agree, the uniqueness should be a MUST, but I think "high probability"
should stay so random generation of nonces is acceptable. PR:
https://github.com/ietf-wg-acme/acme/pull/289
Forwarded Message
Subject:Generating nonces
