Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

Nick Sullivan <nick@cloudflare.com> Wed, 15 June 2022 15:48 UTC

Return-Path: <nick@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BBEC1594A8 for <tls@ietfa.amsl.com>; Wed, 15 Jun 2022 08:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=cloudflare.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 B1gPKe_76ztL for <tls@ietfa.amsl.com>; Wed, 15 Jun 2022 08:48:51 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 1C2F8C1594A9 for <tls@ietf.org>; Wed, 15 Jun 2022 08:48:51 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id y79so13094021iof.2 for <tls@ietf.org>; Wed, 15 Jun 2022 08:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4a7G0pUIBuGZ9IN/d+PSFFrlauMm2NUl1C2vT15vhxQ=; b=KG1xh9CYmk5QTLYV6Ov8uih4/4rMqi8yaOEI0f1jYnpArBRSlqK/6/NBF7791c/DXG PUYkMIVXaEO5ysFsFaI303G1PNUvKv/kJtPKdpJR/XLAvWj8mCGOKiOnTQ9iZ9OaSpRM rUvwE6RrvgccEZD6smqhEKzCCW0Pzq8/A8LEA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4a7G0pUIBuGZ9IN/d+PSFFrlauMm2NUl1C2vT15vhxQ=; b=r4ARtnDYfg0cdIRngGJNAAD0aptbFjLnrdLen7hKKRvCaxdiG8HOVyQ6KG7bI0RG0E y5Z3RuyDR8RR+wUVvVpaT/wxmKXQAl3Vs6SZdcDxtKk1oHw2AdeoY7CSsAp6iBVZPZct nQSIBwddXFxNp/5fST+4TUlGsoEsRl4c7AWT/Yj24ddGvgmNyw7fsc7Vtlx2rU0UaMzg xjGvLO/rs500dYwtXRJ6DD1mO/NQ6A3PyrhImj1mHMnOuo4AbPw8TJ8WckyRhVA6vkzt 3nrQdd3HE3EwWy3cYvesc9NEQy0q56teDhGkCtB6DDMjRlmrVXXdLW9HLxMVdzyNbK2I eNZA==
X-Gm-Message-State: AJIora9gazRl0UchOxp4XhnobY6+YRHh/RcfjCsoR5CCSL/MNuqu7e0i R1Y0YFmD1jW0evhHHcqPn+F67h6eF/hIY/ZWYO6ElQ==
X-Google-Smtp-Source: AGRyM1sASF5YYzvGvr9N9Zx1kkKtFY1Sfiid14ue4DpP+SPw36F92c+2ig/5kOhMbmlm46fNg/LlnTf8SZPOBiLNpEU=
X-Received: by 2002:a05:6638:218c:b0:331:a10e:7702 with SMTP id s12-20020a056638218c00b00331a10e7702mr198408jaj.147.1655308129980; Wed, 15 Jun 2022 08:48:49 -0700 (PDT)
MIME-Version: 1.0
References: <165403377923.5138.5525135448713322864@ietfa.amsl.com>
In-Reply-To: <165403377923.5138.5525135448713322864@ietfa.amsl.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Wed, 15 Jun 2022 11:48:34 -0400
Message-ID: <CAFDDyk-2uXWNwY7MOMY6pnQ8yDUJk70P_0P2=8Y+9SBw7-=C3A@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-subcerts@ietf.org, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>, Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="00000000000014fcf505e17e75f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pN7aEni8IlfPt9VJ5_Yv-2oCLqk>
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 15:48:54 -0000

Hi Roman,

Thank you for the good suggestions. Comments addressed here
https://github.com/tlswg/tls-subcerts/pull/108

Best,
Nick

On Tue, May 31, 2022 at 5:49 PM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-tls-subcerts-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ** Section 4
>      Endpoints will reject delegated
>       credentials that expire more than 7 days from the current time (as
>       described in Section 4.1) based on the default (see Section 3.
>
> For clarity, consider:
>
> NEW
> By default, unless set to an alternative value by an application profile
> (see
> Section 3), endpoints will reject delegated credentials that expire more
> than 7
> days from the current time (as described in Section 4.1.3).
>
> ** Section 7.1
>    However, they cannot create new delegated credentials.  Thus,
>    delegated credentials should not be used to send a delegation to an
>    untrusted party, ...
>
> The second sentence doesn’t seem to follow from the first.
>
> ** Appendix B
>    The following certificate has the Delegated Credentials OID.
>
> For clarity, consider:
>
> NEW
> The following is an example of a delegation certificate which satisfies the
> requirements described in Section 4.2 (i.e., uses the DelegationUsage
> extension
> and has the digitalSignature KeyUsage).
>
> ** Appendix B.  I will leave to the RFC Editor to decide if using the
> Watson
> Ladd’s personal home page (kc2kdm.com) in the certificate SAN is an
> acceptable
> example domain name.
>
> Editorial Nits
>
> ** Abstract.  Typo. s/to to/to/
>
> ** Section 4.2. Typo. s/documnt/document/
>
> ** Section 7.6.  In the spirit of inclusive language, consider if there is
> an
> alternative term to “man-in-the-middle certificate”
>
>
>
>