Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Tue, 09 September 2014 20:17 UTC

Return-Path: <kent@bbn.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7111A017D for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 13:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.832
X-Spam-Level:
X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 WZxblCNfw5Cr for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 13:17:28 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723CD1A0149 for <trans@ietf.org>; Tue, 9 Sep 2014 13:17:28 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:60422 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRRrB-000DLF-FL for trans@ietf.org; Tue, 09 Sep 2014 16:17:41 -0400
Message-ID: <540F6051.205@bbn.com>
Date: Tue, 09 Sep 2014 16:17:21 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
CC: "trans@ietf.org" <trans@ietf.org>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <4B184DAD-3C7A-4032-8BA6-634736BB2689@paypal.com> <5B08EB66-1A0F-4FAC-90BE-11949471F0BF@paypal.com>
In-Reply-To: <5B08EB66-1A0F-4FAC-90BE-11949471F0BF@paypal.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/CqN55K6EGLjI9W_KQPbXCOd3bcg
Subject: Re: [Trans] Precertificate format
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 09 Sep 2014 20:17:29 -0000

Brad,
> Stephen,
>
> Below was your original question, which I've attempted to answer in as straightforward a manner as possible, including illustrative examples from recent history.  Detecting mis-issuance of certificates through public logging of such is the stated goal of the I-D.
The I-D fails to describe what constitutes mis-issuance. there appears 
to be many examples
where Web PKI CAs issue certs that do not comply with RFC 5280 (see the 
WPKOPS WG).
Are those certs mis-issued? Or, are certs that are syntactically valid, 
maybe even
5280-compliant, but issued to the "wrong" subject mis-issued? or, ...

The I-D needs to be more precise in defining. Logging, per se, permits 
folks who monitor
logs to detect mis-issuance, but does not solve the problems caused by 
mis-issuance. If detection were sufficient, then there would be no need 
for TLS clients to reject certs w/o
SCTs (as mandated by the current I-D). I'm guessing that there is a 
notion of how the various elements of CT work together to address the 
problems that result from mis-issuance, but the
I-D fails to articulate this notion. That's a serious omission.
> The complex nature of X.509/PKIX and the surrounding technology ecosystem and the history of vulnerabilities in such demonstrates that including everything in the log except that which MUST be excluded furthers that goal.  There is not a specific threat model nor any need to articulate one.
For several years it has been common practice to require a threat model 
for new security efforts in the IETF. Why do uyou believe that TRANS 
should be an exception?
>   We desire a technology that is useful against as many threats to the broad certificate ecosystem as possible, including those yet to be formally anticipated.
The scope here is essentially the Web PKI used with TLS, primarily as 
used by in browsers;
it is not all possible uses of certs with IETF security protocols. So 
the "broad certificate ecosystem" is not universal, right?

Steve