Re: [Trans] Precertificate format
Stephen Kent <kent@bbn.com> Mon, 15 September 2014 19:02 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 ABACC1A00E4 for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 12:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level:
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oyx3Ztf7_KsJ for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 12:02:37 -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 A46E51A6FB1 for <trans@ietf.org>; Mon, 15 Sep 2014 11:52:23 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:33097 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XTbO9-000PNp-3y for trans@ietf.org; Mon, 15 Sep 2014 14:52:37 -0400
Message-ID: <54173564.4040704@bbn.com>
Date: Mon, 15 Sep 2014 14:52:20 -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
To: trans@ietf.org
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <4B184DAD-3C7A-4032-8BA6-634736BB2689@paypal.com> <540F3B42.3000708@bbn.com> <CABrd9SS4NgJo8mX72fB_9q4u8jQ5NQYsyk5hxPZvXxyfERvvcg@mail.gmail.com> <54107771.501@bbn.com> <CABrd9SQh7-7ogTkHbAvJfKioZrgoB2-m0noGeafrOWzcLKyi5Q@mail.gmail.com>
In-Reply-To: <CABrd9SQh7-7ogTkHbAvJfKioZrgoB2-m0noGeafrOWzcLKyi5Q@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RcKj09b5fPOC8XtBS4Ye7Qgz89M
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: Mon, 15 Sep 2014 19:02:39 -0000
Ben, > ... > I think its pretty clear what the purpose of CT is - to make it > possible to detect mis-issuance of certificates - i.e. that > certificates conform to all the requirements for issuance. And its > also clear that to do this, you need to be able to see the contents of > the certificate. This is the threat model. Or, if you really want it > phrased as a threat, the threat is that some CA might issue a > certificate that does not conform to the requirements for issuance > (which, btw, vary over time) and the mitigation is a public, > append-only, verifiable log of the contents of all issued > certificates. > > The I-D clearly states this already, I think, but if you don't like > the text, perhaps you can propose something you'd like better? Here's some suggested text that matches my model for a threat model description: > ... > >>> However, when you suggest that inclusion of some particular thing is >>> problematic, then we can, of course, refer to potential problems CT >>> might reveal and available remedies as an illustration of why that >>> thing is needed. >> I don't know what this last, rather long sentence means. Please elaborate. > What I meant was that mentioning a problem in order to explain why > some field is needed does not mean that we then have to enumerate all > problems, find a problem that justifies every field, etc. Thanks for the clarification. I disagree. If one lists every field to be covered by an SCT, and notes why the field needs to be covered, then the coverage is clearly justified. Saying that we'll cover every field because there might be a need to do so, even though we can't articulate it, can lead to unnecessary complexity. For example, right now TCPINC WG is performing this exercise for the TCP header, to justify which fields needs to be integrity-protected. I agree that an X.509 cert is a much bigger, more complex data structure, but the principle is the same. Steve
- [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Rick Andrews
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Matt Palmer
- Re: [Trans] Precertificate format Matt Palmer
- Re: [Trans] Precertificate format Eran Messeri
- Re: [Trans] Precertificate format Tomas Gustavsson
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Carl Wallace
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Hill, Brad
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Brian Smith
- Re: [Trans] Precertificate format Kyle Hamilton
- Re: [Trans] Precertificate format Watson Ladd
- Re: [Trans] Precertificate format Tomas Gustavsson
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Jeremy Rowley
- Re: [Trans] Precertificate format Erwann Abalea
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Erwann Abalea
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Rob Stradling
- Re: [Trans] Precertificate format Erwann Abalea
- [Trans] Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Melinda Shore
- Re: [Trans] Precertificate format Stephen Davidson
- Re: [Trans] Precertificate format Ben Laurie
- [Trans] Fwd: Precertificate format Erwann Abalea
- Re: [Trans] Fwd: Precertificate format Ben Laurie
- Re: [Trans] Precertificate format Stephen Kent
- Re: [Trans] Precertificate format Russ Housley
- Re: [Trans] Precertificate format Rob Stradling