Re: [lamps] Request time in CMC

[Stefan Santesson <[e-mail]>]

Thanks Hendrik,

That is very good to know for the event that we have an opportunity to
change protocol to CMP.

But even if we do that, we still need our CMC implementation to work.

However, the presence of messageTime in CMP confirms the need of such
parameter also in CMC.

/Stefan


On 2021-10-27 10:50, Brockhaus, Hendrik wrote:
> Stefan
>
> I cannot comment on your decision using CMC. But using CMP you would have a senderNonce and recipNonce in addition to the messageTime available in the PKIHeader. This should provide all you need for replay protection, I guess.
> https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.1
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile-07#section-3.1
>
> Hendrik
>
>> Von: Spasm <[e-mail]> Im Auftrag von Stefan Santesson
>> Gesendet: Mittwoch, 27. Oktober 2021 09:34
>>
>> I posted this in PKIX but I realize that this may be an issue that could be
>> discussed/handled in this group as it is somewhat related to CMS.
>>
>> I'm working on a project where we use CMC for some simple direct interaction
>> between an RA and a CA.
>>
>> We got stuck on replay protection that is essential for us. For this purpose there
>> is a nonce value, but no time when the request message was created.
>>
>> Without time information, replay protection will potentially have to save and
>> check against all nonces for eternity, which seems highly inefficient.
>>
>>
>> Our current solution is to create a new CMC control attribute with the
>> ASN.1 structure of GeneralizedTime defined as the "messageTime"
>>
>> (The term message time is used in the CMC document even though it is not
>> included in the protocol)
>>
>>
>> Questions:
>>
>> Are we correct or wrong in our assumptions?
>>
>> If we are correct, could LAMPS provide an OID for such control attribute?
>>
>> Or has such attribute already been defined elsewhere?
>>
>> I could write a short draft if this group would agree to define such attribute. It
>> would be a very short draft.
>>
>>
>> ________________
>> Stefan Santesson
>>
>> _______________________________________________
>> Spasm mailing list
>> [e-mail]
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
>> .org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.brockha
>> us%40siemens.com%7Cd529e446258c46c49d2508d9991c2652%7C38ae3bcd95
>> 794fd4addab42e1495d55a%7C1%7C0%7C637709169030020766%7CUnknown%
>> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>> CJXVCI6Mn0%3D%7C3000&amp;sdata=Tw9wag22PzLV8jyHIdUlUoYarhwSIl80Jb
>> RNghuJwHc%3D&amp;reserved=0