Return-Path: 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 8E3B312D885 for ; Fri, 8 Jul 2016 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 p8YjVtaIXS_S for ; Fri, 8 Jul 2016 08:35:44 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 1986E12D87F for ; Fri, 8 Jul 2016 08:35:36 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f6so6409682ith.0 for ; Fri, 08 Jul 2016 08:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J5WOZmKHN80MfmxxFAjNyTh5xcYn7riFvhAKYbdO8u8=; b=llvdlOvIBM5g9U791D8AqTOnv3X/NSAhQmD1nCTxLPOW8RDat5qvi1vR2HFvesLBRc Vr6w49np73HV3Ep6EXk3V2rENMn/qwe3drJEqwoggupsgllCCsSL/9MjkIxSFyJWe6Nf mv/CYErLOIQWYgBdszAARc3Q/H6LHtjmXk0fA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J5WOZmKHN80MfmxxFAjNyTh5xcYn7riFvhAKYbdO8u8=; b=U6g8tTJ9CBQXlO+Fje/vG+xVd/PAktsPCcHRoVQ2J3uX+cD0VX9AnIPcFfljm8C9pt Lgw9Zl2FwmbKU+InzNj6FvEOc+B+rloSnnK9yZkuAEsxG1WdfZflRva7hPAZw512CxE+ NBPVuRqtrBLc2TXE1PSgEQRVzNemh9ojLii2uSZIKvCd/bEnfnZBSzNLCthNSGU5YDt7 7rQ6Ot4YaXiTa4Ar5qXN7wDtI+WqWJM045cUwR8KrhRkkKmlWfeNKgr47Ii1f8b0cowm mD+iFKCx17tSX0tnG8uIc8ECNw/6cugl9GUZVabOqikQovd16BmUbKusD/dGnS4yoz7L h8hQ== X-Gm-Message-State: ALyK8tKgZ5rcCT+khmWgim5ngnG4T/XuqtRDZzEZF9KhCMoHlriiDYxLyBSAGXaFe3qRZhQ4+Yr+qutRFOcy2V+2 X-Received: by 10.36.61.201 with SMTP id n192mr4079334itn.92.1467992135257; Fri, 08 Jul 2016 08:35:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 08 Jul 2016 15:35:24 +0000 Message-ID: To: Watson Ladd , Eric Rescorla Content-Type: multipart/alternative; boundary=001a11444e94c1a4070537218dad Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-rescorla-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:35:48 -0000 --001a11444e94c1a4070537218dad Content-Type: text/plain; charset=UTF-8 On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote: > I don't think we can use name constraints here. Yes, they are opt-in > and clients can indicate support, but it may well be that a TLS > implementation doesn't know if its X509 validation code will support > them as it hands the certificate to a system provided validator. (I > believe there was a longstanding Chrome on Windows XP bug for a > similar reason). > What are you referring to? I think one would know well enough whether our validators support a given feature. If there's weird cases, one can always decline to advertise if unsure. If you're thinking ECDSA and Chrome/XP, I believe it only got reflected in the cipher list and not sigalgs, but that's just because we never routed that bit through, not because we didn't know if we could do ECDSA. (And by now it's irrelevant since Chrome/XP is no longer supported.) David > Sincerely, > Watson > > > > > In the next rev, we'll update the draft to make these points more > clearly. > > > > -Ekr > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11444e94c1a4070537218dad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 7,= 2016 at 7:29 PM Watson Ladd <w= atsonbladd@gmail.com> wrote:
I don't think we can use name constraints here. Yes, they are opt-in and clients can indicate support, but it may well be that a TLS
implementation doesn't know if its X509 validation code will support them as it hands the certificate to a system provided validator. (I
believe there was a longstanding Chrome on Windows XP bug for a
similar reason).

What are you referring to? I think one would know well enoug= h whether our validators support a given feature. If there's weird case= s, one can always decline to advertise if unsure.

If you're thinking ECDSA and Chrome/XP, I believe it o= nly got reflected in the cipher list and not sigalgs, but that's just b= ecause we never routed that bit through, not because we didn't know if = we could do ECDSA. (And by now it's irrelevant since Chrome/XP is no lo= nger supported.)

David
=C2=A0
Sincerely,
Watson

>
> In the next rev, we'll update the draft to make these points more = clearly.
>
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a11444e94c1a4070537218dad--