Re: [Rats] Nonce-based freshness for CMP/EST

Carl Wallace <carl@redhoundsoftware.com> Mon, 04 March 2024 11:46 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE6C15198C for <rats@ietfa.amsl.com>; Mon, 4 Mar 2024 03:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEe4UAq1rHIR for <rats@ietfa.amsl.com>; Mon, 4 Mar 2024 03:46:36 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B34EC151553 for <rats@ietf.org>; Mon, 4 Mar 2024 03:46:36 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7882177f683so58457585a.1 for <rats@ietf.org>; Mon, 04 Mar 2024 03:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; t=1709552794; x=1710157594; darn=ietf.org; h=mime-version:in-reply-to:references:thread-topic:message-id:to:from :subject:date:user-agent:from:to:cc:subject:date:message-id:reply-to; bh=uyVFjMGGsnAwb1kl8Q/cxSGsm0mQTkUxCOXGjMVYumU=; b=j4QXeJ/l49LW6h3ahD4zam2L7OYMcmZ3BUFMCnFqokDu4Rj/RMSyZuh/1vH8Uv2Mv5 4rYRmyE7e8OiDPXVBgIpW7xsQ3wyL2CsC0ZO4lb+6iXbctnI9jUB85KAWTnAtRCBQOyz 6bn5hLhbb52e6tI0VRhhcjgJF0+om0vlNUyk8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709552794; x=1710157594; h=mime-version:in-reply-to:references:thread-topic:message-id:to:from :subject:date:user-agent:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uyVFjMGGsnAwb1kl8Q/cxSGsm0mQTkUxCOXGjMVYumU=; b=i+mOmaC31H6HYMRrVxWMKn7yr5WVhiLQOHZsa8F9PauPhtCwQC/ne/o9Rs5OrGmz+N iqdx/0zVFllSfT1Aze1eBKaK+gq6UfhkuMyMCofLTJ5z7ElYOxa+7kqI3zzE4OtxS8Ba dSx6C6RnMZKFB0ZUvPtOZUthpkNHcHGLG1PpsS+bG+TgrpUYZZGSoddxDiWrG3IhnovL 40gnIi81/Lm/K6V2QXDB7uLMIiaO9FBK95y9uHNRM9eEvJTYxQ0z/U9pWC0R7yq91yIm XOnRTPsb3Ol3l2bXnev30vKGMEm6fIxOGTSlvIeOlQypjENwjPZjiNsq/ONmY+u978M4 Ncug==
X-Forwarded-Encrypted: i=1; AJvYcCVNaZefh9umnJzYIzhJKOofYqkVrok4ZXWwYy9DvnGrULUktQMO1fSxuxZ3y/bABn4+DtVUsil/77ntYIoH
X-Gm-Message-State: AOJu0Yxiz9HtXnQJNNa4wIMP5fUEtSEbK3Z2L46v1BaJ4dg6KM8WswNB nj5+PkpJl5lAPDO8zKVBiqJBxyewQs0NP+2iY5TAQl41ZV8jWvbBUwRljCuiHyjOCMz+/D9h1HG A
X-Google-Smtp-Source: AGHT+IEGl8zkiG3r8XIZSCySEg/icw7I5sxZGjDjTkBumHVLve8Pr7BQipKFwqgDnGEAkXFR0EPXTg==
X-Received: by 2002:a05:620a:21d5:b0:788:1f98:14b8 with SMTP id h21-20020a05620a21d500b007881f9814b8mr5398088qka.39.1709552785161; Mon, 04 Mar 2024 03:46:25 -0800 (PST)
Received: from [192.168.4.77] (pool-96-255-232-167.washdc.fios.verizon.net. [96.255.232.167]) by smtp.gmail.com with ESMTPSA id i22-20020a05620a405600b00785da717d64sm4259312qko.111.2024.03.04.03.46.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2024 03:46:24 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.82.24021813
Date: Mon, 04 Mar 2024 06:46:24 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: hannes.tschofenig=40gmx.net@dmarc.ietf.org, 'rats' <rats@ietf.org>, spasm@ietf.org
Message-ID: <8CE151EC-3EA3-41C5-823F-2A5D9592C713@redhoundsoftware.com>
Thread-Topic: [Rats] Nonce-based freshness for CMP/EST
References: <023701da6d65$9e9c0340$dbd409c0$@gmx.net>
In-Reply-To: <023701da6d65$9e9c0340$dbd409c0$@gmx.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3792379584_1174599858"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/kxZBxeH0DSsE9HGJCC8VXX484hs>
Subject: Re: [Rats] Nonce-based freshness for CMP/EST
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 11:46:40 -0000

I reviewed the diff for the new draft and had a couple of questions/comments. Added LAMPS since this originates there.

 
How are non-ASCII values intended to be handled in the various EvidenceHint options? 
Given the way EvidenceHint is used in the JSON example, would it be better to just define EvidenceHint as a UTF8String instead of as a CHOICE? This would be more consistent with the statement from the attestation draft that the “format and contents of the hint are out of scope of this document.”
Should EvidenceHint be included in the NonceResponse to indicate which verifier was elected? This seems necessary given the attester may include a hint in the EvidenceStatement. 
Similarly, why does the hint need to be in the NonceRequest? The CA is the relying party. It seems to me that it will use whatever verifier it wants (so inclusion in the response makes some sense, to inform the EvidenceStatement creation, but inclusion in the request seems a bit like the tail wagging the dog).
s/a test value/a text value
The statement “indicates the time the nonce is considered valid” should probably be “indicates the time after which the nonce is considered invalid” assuming a nonce would only be valid until the expiry time if not used already.
What should occur if the verifier refuses to supply a nonce of the requested length?
 

From: RATS <rats-bounces@ietf.org> on behalf of <hannes.tschofenig=40gmx.net@dmarc.ietf.org>
Date: Sunday, March 3, 2024 at 7:23 AM
To: 'rats' <rats@ietf.org>
Subject: [Rats] Nonce-based freshness for CMP/EST

 

Hi all,

 

I have just submitted a new version of the draft that describes how to add nonce-based freshness for certificate management protocols like CMP/EST. The solution relies on the CSR attestation specification.

 

Here is the updated draft:

https://datatracker.ietf.org/doc/draft-tschofenig-lamps-nonce-cmp-est/

 

As the recent mailing list exchanges have shown, there is room for more discussion about this freshness topic. FWIW I have requested an agenda slot in the LAMPS group.

 

Ciao

Hannes

 

_______________________________________________ RATS mailing list RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats