Re: [Trans] Precertificate format
Stephen Kent <kent@bbn.com> Tue, 09 September 2014 17:39 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 C62CA1A7004 for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 10:39:17 -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 PCLEiu4lEUxN for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 10:39:16 -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 ADDBD1A7003 for <trans@ietf.org>; Tue, 9 Sep 2014 10:39:16 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:37114 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRPNr-0001qe-K1 for trans@ietf.org; Tue, 09 Sep 2014 13:39:15 -0400
Message-ID: <540F3B42.3000708@bbn.com>
Date: Tue, 09 Sep 2014 13:39:14 -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>
In-Reply-To: <4B184DAD-3C7A-4032-8BA6-634736BB2689@paypal.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/k6Qe3YjlPVHXyxOFFvTYBXX9ZL4
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 17:39:17 -0000
Brad, >> I suggest that the CT designers list which data items from a cert that is being >> logged need to be in the SCT request, and why each item has to be present. Maybe that >> will show us how to avoid the concern that I and others have raised. It would also >> provide us with a starting point for the format of a new data structure for the SCT >> request, and the set of data that is input to the SCT hash computation. > The serial number needs to be part of the logged proof because that is the key on which existing revocation mechanisms operate. Transparently identifying that a certificate has been issued incorrectly is of little utility unless that certificate can be revoked. I agree that the serial number is critical if one plans to revoke the cert. But , the I-D makes no mention of remediation mechanisms, an omission I noted in my review a while ago. In some cases it appears that CT plans to shame CAs into submission, in which case revocation may not be needed ;-). > The alternatives are revoking the issuing CA on any leaf mis-issuance or inventing alternate revocation mechanisms. I agree that those mechanisms would effect revocation of the offending cert, but they may be overkill, and so should be avoided if possible. > The latter may be less of an obstacle than it appears since the major implementers of CT are also in the process of inventing and deploying their own (currently) proprietary revocation systems alongside CT. I didn't know that. Since the WG does not know how these might work, we also don't know if the cert serial number is required. > Nevertheless, one would need something stable to uniquely identify the certificate for these purposes, which ends up looking a lot like a serial number however you slice it. (You can't use a cryptograhpic hash of the final cert for this, either, because that would require a preimage in the log.) I agree that something that uniquely identifies the evil cert is needed, which is why I suggested that we revisit this problem and look at each cert component to see what we need, and why. 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