Re: Time in CMC requests

Thanks Anders,

I think that max age (and max future) is redundant as it can simply be a
local policy for the CA who decides for itself how long it will store
nonces for old requests.

I would certainly not allow the requester to set this policy in the
request as they could suggest infinite time.

I want to stay away from structure in data where none was intended as it
makes it hard to distinguish support or non support in a clean way.

I'm leaning towards a custom control attribute for request time and an
open interface for replay protection that may use this information if
its available.

/Stefan


On 2021-10-26 19:15, Anders Rundgren wrote:
> Hi Stefan,
>
> Yes, time-stamped nonces is the way to go.
>
> The only addition needed is a MAX_AGE (and MAX_FUTURE) check to keep
> the bag in shape.
> I recently did this for a similar use case:
> https://github.com/fido-web-pay/specification/blob/gh-pages/replay-cache-java.md
>
>
> Anders
>
> On 2021-10-26 18:29, Stefan Santesson wrote:
>> We have an implementation of CMC (RFC 5272) that I need to use, but I
>> got stuck on replay protection.
>>
>> CMC says that replay protection is handled by the use of nonce values.
>>
>> However, without any time information when the request was created, I
>> would have to validate against an infinitely large bag of previous
>> nonces.
>>
>> Was this an oversight in the design, or am I missing something?
>>
>> Is there any control message defined elsewhere that holds a time when
>> the CMC request was created?
>>
>>
>> My current options (as I need replay protection in this particular case)
>> is either to abuse the nonce data and use a byte encoded timestamp as
>> nonce, or to create a new control attribute with time information.
>>
>> Any suggestions?
>>
>>
>>
>