Re: Time in CMC requests

On 2021-10-26 21:36, Stefan Santesson wrote:
> 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.


hi Stefan, totally agree; this is exactly what the sample code does as well.

Anders

> 
> 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?
>>>
>>>
>>>
>>