[lamps] Request time in CMC
Stefan Santesson <stefan@aaa-sec.com> Wed, 27 October 2021 07:33 UTC
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
- [lamps] Request time in CMC Stefan Santesson
- Re: [lamps] Request time in CMC Brockhaus, Hendrik
- Re: [lamps] Request time in CMC Stefan Santesson
- Re: [lamps] Request time in CMC Russ Housley
- Re: [lamps] Request time in CMC Stefan Santesson