IETF Logo Mail Archive

Re: [lamps] Zaheduzzaman Sarker's No Objection on draft-ietf-lamps-rfc5019bis-08: (with COMMENT)

Russ Housley <housley@vigilsec.com> Tue, 16 April 2024 14:53 UTC

Return-Path: <housley@vigilsec.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 A1914C14F69C; Tue, 16 Apr 2024 07:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vigilsec.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 bKfCBf9C132O; Tue, 16 Apr 2024 07:52:56 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 AF4EDC14EB19; Tue, 16 Apr 2024 07:52:16 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id B1C9A150905; Tue, 16 Apr 2024 10:52:15 -0400 (EDT)
Received: from smtpclient.apple (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 81EFC150900; Tue, 16 Apr 2024 10:52:15 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <171327854630.54337.8735538356041977711@ietfa.amsl.com>
Date: Tue, 16 Apr 2024 10:52:04 -0400
Cc: IESG <iesg@ietf.org>, draft-ietf-lamps-rfc5019bis@ietf.org, LAMPS Chairs <lamps-chairs@ietf.org>, LAMPS <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC57EF74-F01D-4374-AF71-9F655941612D@vigilsec.com>
References: <171327854630.54337.8735538356041977711@ietfa.amsl.com>
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vigilsec.com; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=pair-202402141609; bh=FFEjv7zRWcqpWNHbIolCQfKnO3iZJhFtAfJTEr0ZsWY=; b=u9cE2Mhg+jue/mb0+KBEBgNUo3jQ6ikEJw4PwlpL8P0lzcXlAZGtN89mNFSmkfsEnLBl5yjjfWNYBaRVPrZeCa1L1q5bTzisfhKi9yy1fCTI+vbdcYFTNctTJY8ahkaqAEgwqdgjHo09m0oYOOgxAXFjesff+qY6iqDyRroyXYX7rKb8yGmkgvN3KbXSnfPg8WYTdlOKr+b9poNNot/ZFIrKZrQ+paY5tJ9Pp60ABYlEfEmAg0EHoXsR+lA5xdvmbraMK2x5S/GNXeEMwnu8aeydBGjy+C78CS8qSLUhpv8BnhHuzt5tfdOJXMVbEIJQv/NjA6B7HoePaG9BD1SdZQ==
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/LM14O0EluVlm6zYTOMIFkXzY4V0>
Subject: Re: [lamps] Zaheduzzaman Sarker's No Objection on draft-ietf-lamps-rfc5019bis-08: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: This is the mail list for the LAMPS Working Group <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: Tue, 16 Apr 2024 14:53:00 -0000

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for working on this update.
> 
> One thing the I noticed that the profile transport uses HTTP only ( and not
> HTTPs). There might be good reasons for using it that way in certain scenarios.
> I would strongly suggest to explain the rational(s) behind the choice.
> 

Yes!  OCSP is used in validation of each certificate in a chain.  So, if a certificate status is being checked as part of the setup for a TLS session, you do not want to create another TLS session as part of the certificate status checking.

By the way, the recommendation in Section 2.2.2 that the OCSP responder's certificate contain the id-pkix-ocsp-nocheck extension is for a similar reason.  This avoids the use of OCSP to get the certificate status for the OCSP responder's certificate.

Russ

v2.23.0 | Report a Bug | By Email