Subject: [lamps] Request time in CMC

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Oct 2021 09:33:34 +0200

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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 27 Oct 2021 08:50:26 +0000

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 <[email-masked]> 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.
> 
> 
> 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
> [email-masked]
> 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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Oct 2021 13:56:12 +0200

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 27 Oct 2021 09:45:38 -0400

Stefan:

Can't the CMS signing-time attribute (Section 11.3 of RFC 5652) be used for this purpose?

Russ

> On Oct 27, 2021, at 3:33 AM, Stefan Santesson <[email-masked]> wrote:
> 
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Oct 2021 15:57:15 +0200

Russ,

You are absolutely right.... I had a distinct feeling I had missed
something obvious. Now confirmed.

No further actions required. Please ignore this question :)

/Stefan