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