Re: [Trans] Precertificate format
Stephen Kent <kent@bbn.com> Tue, 09 September 2014 19:43 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 43C5C1A01F7 for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 12:43:41 -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 503z_YyMGMps for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 12:43:38 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53951A0205 for <trans@ietf.org>; Tue, 9 Sep 2014 12:43:37 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:33347 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRRK4-0004cr-W3; Tue, 09 Sep 2014 15:43:29 -0400
Message-ID: <540F585C.6050203@bbn.com>
Date: Tue, 09 Sep 2014 15:43:24 -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: "Hill, Brad" <bhill@paypal.com>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <4B184DAD-3C7A-4032-8BA6-634736BB2689@paypal.com> <540F3B42.3000708@bbn.com> <38010FE8-5B34-4721-94E5-888D3FC62C9E@paypal.com>
In-Reply-To: <38010FE8-5B34-4721-94E5-888D3FC62C9E@paypal.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Qr2cUAme0BDe2Rl20RHVu51Dw1c
Cc: "trans@ietf.org" <trans@ietf.org>
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 19:43:41 -0000
Brad, > Whatever is logged ought to be as close as is possible to the actual certificate and ought to include all meaningful information in the certificate other than a preimage-resistant hash. Absent a clear description of scope, i.e., what problem is being solved, the approach of "include everything" is understandable. But that doesn't make it the best approach. > Detecting problematic issuance isn't confined just to organizational authority. Looking at the recent history of bugs in this area, observing a flurry of issuance of certificates of the form "www.legit.com\0www.evil.com", or certificates with large "tumors" in rarely used or obsolete extensions might have been cause to investigate deeper and additionally could've provided evidence of stealthier prior exploitation of such bugs. Again, if the I-D stated what problem is being solved, and the examples you cite are part of that description, then covering everything in a cert makes more sense, but ... > We can't predict in advance what such problems will be, so the default stance should be that everything is logged, and the onus fall on those who want to exclude content to justify that action. I see your point, and if the I-D clearly stated the sort of very broad goals that you note above, I think your argument would be a good one. We already have one example of folks wanting to exclude info, in the case of redacted certs. I'm not yet convinced that the proposed mechanism is safe, but we'll see. > With regard particularly to serial numbers it's clear they are necessary as input to revocation mechanisms. yes, and my suggested alternative mechanism preserves logging of serial numbers, as a separate step for CAs (not for Subjects or others who have a cert for which an SCT is to be created as a post-issuance artifact.) But, I think the I-D needs to be clear about the threat model so that we can see why revocation is part of a remediation plan in some circumstances. The current text is way too vague on this topic, as I noted in my review prior to the Toronto meeting. 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