From nobody Wed Oct 27 00:33:53 2021
Return-Path: <stefan@aaa-sec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 3961B3A0418
 for <spasm@ietfa.amsl.com>; Wed, 27 Oct 2021 00:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id yLqD-jTlQav3 for <spasm@ietfa.amsl.com>;
 Wed, 27 Oct 2021 00:33:47 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 40E593A03F4
 for <spasm@ietf.org>; Wed, 27 Oct 2021 00:33:45 -0700 (PDT)
Received: from s807.loopia.se (localhost [127.0.0.1])
 by s807.loopia.se (Postfix) with ESMTP id 8F2A02EB6352
 for <spasm@ietf.org>; Wed, 27 Oct 2021 09:33:35 +0200 (CEST)
Received: from s630.loopia.se (unknown [172.22.191.6])
 by s807.loopia.se (Postfix) with ESMTP id 804A62E286EB
 for <spasm@ietf.org>; Wed, 27 Oct 2021 09:33:35 +0200 (CEST)
Received: from s473.loopia.se (unknown [172.22.191.6])
 by s630.loopia.se (Postfix) with ESMTP id 7113513AC003
 for <spasm@ietf.org>; Wed, 27 Oct 2021 09:33:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s645.loopia.se ([172.22.191.6])
 by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024)
 with LMTP id chjugdSLCwSM for <spasm@ietf.org>;
 Wed, 27 Oct 2021 09:33:35 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 90.229.17.25
Received: from [10.0.1.118] (unknown [90.229.17.25])
 (Authenticated sender: mailstore2@aaa-sec.com)
 by s645.loopia.se (Postfix) with ESMTPSA id EA68C157043B
 for <spasm@ietf.org>; Wed, 27 Oct 2021 09:33:34 +0200 (CEST)
Message-ID: <99c05eec-5d98-ecf2-0e2f-5dbf6cd722ab@aaa-sec.com>
Date: Wed, 27 Oct 2021 09:33:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0)
 Gecko/20100101 Thunderbird/94.0
Content-Language: en-US
To: LAMPS WG <spasm@ietf.org>
From: Stefan Santesson <stefan@aaa-sec.com>
Organization: 3xA Security AB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/x8GxMOSy9Xwwl17atPTvXYN42wg>
Subject: [lamps] Request time in CMC
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime
 \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>,
 <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>,
 <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2021 07:33:52 -0000

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

