IETF Logo Mail Archive

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

Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> Tue, 16 April 2024 15:07 UTC

Return-Path: <zahed.sarker.ietf@gmail.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 460ACC15199D; Tue, 16 Apr 2024 08:07:02 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MNbsD9IgZIOC; Tue, 16 Apr 2024 08:07:00 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 5B01DC1E010B; Tue, 16 Apr 2024 07:59:31 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-5e4613f2b56so2930339a12.1; Tue, 16 Apr 2024 07:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713279571; x=1713884371; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=a2NFl/sqGqhoMNL4uAeS8//GonXB7reC4lMXJNC1hLc=; b=EAN2SLX10624otKF1QqBiFPcLebwp6dbbDBMgNT1X13lQzA7bhAL+AY57kTyrPjJ5W trIquin+KR7uaipSSkRdQqqhBSim7ZENv1vdj77FWoZ0u2Ywn5MGWdRStii6sXMArQ26 4/fbUxfk/4t/OGmmKabTWvN2F49LAYeNJWqenwEDLKAYAFB4tqZ4K6OsnHsoTU56/Pev CPb9bquu1vi/PyIqJ+auV/sfQz+IKCzMkRpjdvwBda8EGKdfxl3nvoCnI8st+ILD5FKw vsWL2UMPGNRItz3Fcumbq/O5IcDobjvc4WramhDV7sS2FbohR8fFg78RWo1Cn6M3Qwa1 NNMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713279571; x=1713884371; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=a2NFl/sqGqhoMNL4uAeS8//GonXB7reC4lMXJNC1hLc=; b=Voz5bgjEn/uWWgGYQOV6aJAAJZAPDP4OVB1V89wt5MqpwVGotDhJobTDgfobdRvPtt XhF0Hm9LPJpw/gdb1ovQjVbVa38gbMvrKmJga6t/C09sE8JsXdWrIH/rp366uXXIijXX j39NkXHnxq+p2hkzFRSjMl5uQo70VL0Yr+F8nqR6Fl5Iq98swOXRjyoAdFOkiPn77jqX cfPdVJG6zN6zFMmOeSbdbs0KiXLb7AALgkLEvvja154bKtH/IiLIDnkmwQW1esCMsEM9 n/UDCk3pYeAXgvQmJ9s4+4K4m4hc12sLS6qC79QVeOZYXBdw7OCxQ8QkK9tEXuUrv3hV WqIw==
X-Forwarded-Encrypted: i=1; AJvYcCX3nLtHTT4DD/N0v56XfYh6dCiiIVFve2AYg9XTYxTK+elyk/9GPHkLIscFCg7MT/kLqfdjYNaQzt8dhdDtZMn9cA1yX7D7Oiimzg07CzhpavB5tQhhDT1SdKwJVALrVzWVKV8D91gR/ftoqOv2/JdRFYM5j2URjS8VrHoVZjEEsbjnCL8bnqmHtzU=
X-Gm-Message-State: AOJu0YzrQD3mJ+OabRC8Pqqn58OL4hR3ZSDug3ej4II5TomnGQyB8jiD Mmi3KgzoRH6Y+aWcM3cvqLoy7ZqsU2Cp3S9TSh4cxcfkubQ9cvbZFvZ7ES7qgqBOc5eRkCXb/s8 8IIqG2qCjyIih+k24NVQwBac7wy/Q05Mw
X-Google-Smtp-Source: AGHT+IGE5D+HDEmE/CCsc48nvbtyuBso1fyn1ZIAZMLgghmyrPqsKodAxRlHPNT5FtTWE1YJDCvbPJmHSTb4wHTcPws=
X-Received: by 2002:a17:90b:614:b0:2a7:a36c:140e with SMTP id gb20-20020a17090b061400b002a7a36c140emr6701566pjb.21.1713279570783; Tue, 16 Apr 2024 07:59:30 -0700 (PDT)
MIME-Version: 1.0
References: <171327854630.54337.8735538356041977711@ietfa.amsl.com> <EC57EF74-F01D-4374-AF71-9F655941612D@vigilsec.com>
In-Reply-To: <EC57EF74-F01D-4374-AF71-9F655941612D@vigilsec.com>
From: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Date: Tue, 16 Apr 2024 17:59:19 +0300
Message-ID: <CAEh=tccJeMcnKReVxgn7HU30zBk_jUKqJDvSV0UhvAbGXOehaQ@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, IESG <iesg@ietf.org>, draft-ietf-lamps-rfc5019bis@ietf.org, LAMPS Chairs <lamps-chairs@ietf.org>, LAMPS <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037b5a4061637fc55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/mYezMg9Q4G6-dvB_to9gTEcIzIY>
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 15:07:02 -0000

On Tue, Apr 16, 2024 at 5:53 PM Russ Housley <housley@vigilsec.com> wrote:

> > ----------------------------------------------------------------------
> > 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.
>
yes, perhaps not..(or perhaps use some other techniques like short live
cert if this to be a big issue - a separate discussion I guess) hence it is
would be great to add the rational in the document.

>
> 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.
>
I see.

//Zahed

>
> Russ
>
>

v2.23.0 | Report a Bug | By Email