Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

Watson Ladd <watsonbladd@gmail.com> Fri, 22 May 2020 15:39 UTC

Return-Path: <watsonbladd@gmail.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 C64B63A0AF5 for <tls@ietfa.amsl.com>; Fri, 22 May 2020 08:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PSLdTjFRnhi for <tls@ietfa.amsl.com>; Fri, 22 May 2020 08:39:00 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CDF3A0AD3 for <tls@ietf.org>; Fri, 22 May 2020 08:39:00 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id a5so5092311pjh.2 for <tls@ietf.org>; Fri, 22 May 2020 08:39:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+wSNkir6vRzCxfsy9RQt+6iDh/w/k6Sss8yNey6Ahl8=; b=riAP/qrvWGvQKAYOXM6OzU2cHNtxLWnB/QwezXSroWOM7dyHVl4qMxcfXbh4fOb8MK BdlqQZc3HT/XMl6fvsSLjdue0QU7uukxT1MGlnEh0g1kRV5I1QKpLJzk42MsAka/ol7e FWqM6/04qgkQYybWxVZecjUCWdVbanhx3PT8hHODlerHN0om0VVC3DkLyx0PcwJ9o+Fi ryrRQ5obNMPPHQpTFTCHIISDbsQndZN7tzR1PfcuBpZ5VubMTaPrhma8P/A903ZXNIcd 9p6jT6u/W4ISz4sBaMryzY5y5rOsSej3EOa1Kqyl4Htsuv4IS6ecuYt43F9a4QHqvuuq 11CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+wSNkir6vRzCxfsy9RQt+6iDh/w/k6Sss8yNey6Ahl8=; b=dqzPka2X0DmDiQ3j02YKNqMEZoqeMR0r8mJwOY+U0VpQuAaCoJOw+djCB3w+Tv76AA qHxGHjo4xQ7rCzFoN8VEPXTSCGs3wDpI/AyiM2zCPmfnqSul2lXVtW69u22DgxGkBLFN F87lmJgNUPe5Zcf7oksXOesM7MAA+S6VnWVW66AEF5FWaPRiltYcD8TpyateQjkF8B2e mwC5fpggBWbr/pEgHtyzEgcFLt7TZeL8cin/LT+rgitt76mhQSJj9BhYZIHfWqMMbdte YmUYA6xjd6LYjGn+ZoHWsE9myo190SrVB3UHa1h4O4uNU9ZoDB486vbgzX2UdF4BT6DT /iVQ==
X-Gm-Message-State: AOAM533ici5XH2rMetxc5A6yFWPtUNOG+WyLIZThmivyo/hkHFRLKtvv 4sdolZb+B0AaPnfNG8efysVIhCs82jKOjzz3QqSE+FhX3fg=
X-Google-Smtp-Source: ABdhPJzBnAPw+LWPDuBxTEeJDpymikY33Ag4bKZ/hz2hf2/ukxe/8xbXrbly6354bdMIxIrmvAiErbTVsKI2XKNqW+4=
X-Received: by 2002:a17:90a:21e5:: with SMTP id q92mr4697866pjc.63.1590161938988; Fri, 22 May 2020 08:38:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoDqtCmkBZYoGT5BaMJN8wgSBFKR00VSUXB9Qu8rDT3S_g@mail.gmail.com> <47A87699-B13C-480B-9C51-2386F1C69D74@vigilsec.com> <CAErg=HFNMz+JEna8FP6agD_XRuW1u7xavGCByupMJ5A9iDvqaA@mail.gmail.com> <24269E65-2CCD-42D7-AACF-85A1D5141CA0@vigilsec.com> <CAErg=HEvG8z8AOgobMyvapkZ8rV2+QMyRTDSmicChQhP51hJ+w@mail.gmail.com>
In-Reply-To: <CAErg=HEvG8z8AOgobMyvapkZ8rV2+QMyRTDSmicChQhP51hJ+w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 22 May 2020 11:38:47 -0400
Message-ID: <CACsn0c=DdhzPyABvWNOfgqqK6RT1jMDtWKoPsCEUiH0RhOKiDg@mail.gmail.com>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>
Cc: Russ Housley <housley@vigilsec.com>, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hrXBDbkqv7ntH7oBobk7t1CpDII>
Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 22 May 2020 15:39:02 -0000

On Thu, May 21, 2020 at 11:23 AM Ryan Sleevi <ryan-ietftls@sleevi.com> wrote
<snip>
>>
>> I am aware of the "fight" about EKU chaining.  I have a view, but I did not really want to drag subcerts into that controversy.
>
>
> Sure, but unfortunately, the design of DC/subcerts is a direct result of that running code.

One of the hard requirements for our deployment was that the same
certificate be useable with DCs and without. A different EKU would be
more problematic then an extension for this purpose, and while it
might be more or less irritating for implementors depending on how
their stack works (sorry Rich -
https://boringssl-review.googlesource.com/c/boringssl/+/33666/1 might
serve as inspiration, but the client side got dropped for similar
issues). We know the extension doesn't bust things, I don't know an
EKU would, and the root program issues make me hesitate.

Anyway it sounds like no one really has a problem with an extension,
just a question.

Sincerely,
Watson Ladd