Re: [Trans] draft-ietf-trans-rfc6962-bis-31

Paul Wouters <paul@nohats.ca> Wed, 19 June 2019 23:43 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE871200F7 for <trans@ietfa.amsl.com>; Wed, 19 Jun 2019 16:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 IX6a-Wi6TZ8r for <trans@ietfa.amsl.com>; Wed, 19 Jun 2019 16:43:48 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D991412012A for <trans@ietf.org>; Wed, 19 Jun 2019 16:43:47 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45ThNd3Lftz3Bb; Thu, 20 Jun 2019 01:43:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1560987825; bh=LeORfeX5BNTIABaJ/sBUCQTcswo4lknzN8dG6yPwwYQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=StE6O13lNmpzu2/o9XRrBJCwFuxXbSMyfiDZCfdmC8TcVY3TSjrIJrEfLkuZuxRdw g9nndzm/u/JcAH5zbdB7L6vbtYkxsDH6xKSeRdeZGRJ8uofTJeL7Td/wLAfcD902EH wu/qoXWzLjKhc/BOKRNocwNIHgRbbaHZ2xIlw0ug=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ePiunVS1mdFU; Thu, 20 Jun 2019 01:43:43 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 20 Jun 2019 01:43:43 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1F3BB393509; Wed, 19 Jun 2019 19:43:42 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1F3BB393509
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 123AA4009E7F; Wed, 19 Jun 2019 19:43:42 -0400 (EDT)
Date: Wed, 19 Jun 2019 19:43:42 -0400
From: Paul Wouters <paul@nohats.ca>
To: Rashmi Jha <rashmij=40microsoft.com@dmarc.ietf.org>
cc: "trans@ietf.org" <trans@ietf.org>
In-Reply-To: <MWHPR21MB0846D2C92633AE28A7B012EAA7E50@MWHPR21MB0846.namprd21.prod.outlook.com>
Message-ID: <alpine.LRH.2.21.1906191936520.28894@bofh.nohats.ca>
References: <MWHPR21MB0846D2C92633AE28A7B012EAA7E50@MWHPR21MB0846.namprd21.prod.outlook.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-7"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/LDZ7gHZ1pMFXc3fil4nDvkVqOYo>
Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-31
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 23:43:50 -0000

On Wed, 19 Jun 2019, Rashmi Jha wrote:

> Have you looked into the options of not requiring CT for CAs which are constrained to a brief list of domains ? I understand this was considered in the past but couldn’t find details why this was not
> accepted.

Whether or not to require CT is not part of the document. This seems
more like a question to browser vendors. The draft only states:


    In addition, if TLS clients will not accept unlogged certificates,
    then site owners will have a greater incentive to submit certificates
    to logs, possibly with the assistance of their CA, increasing the
    overall transparency of the system.

The "if" there is important. It is not a decision made in this document
or this Working Group.

The draft only lists the requirements and formats for when CT is used.

> Named constraint by default provide the assurance as to what domains they will issue. CT becomes an additional network call in in issuance of certificate which can be prevented.  

Not "assurance", but "expectation". CT is there to confirm this
expectation. Surely, you want CT logs to show captured certificates that
were signed by a CA outside of that CA's own Named constraint policy?

Additionally, if you skip accepting certificates within a named
constraint, what do you do when some CA claims ".com" as their
named constraint?

Paul