Re: [Trans] Precertificate format

Tomas Gustavsson <tomas@primekey.se> Wed, 10 September 2014 08:01 UTC

Return-Path: <tomas@primekey.se>
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 65CCD1A0679 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 01:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level:
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] 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 bYPStfn2rix0 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 01:01:09 -0700 (PDT)
Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F9B1A0677 for <trans@ietf.org>; Wed, 10 Sep 2014 01:01:09 -0700 (PDT)
Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id C255B45C00C0 for <trans@ietf.org>; Wed, 10 Sep 2014 10:01:06 +0200 (CEST)
Received: from [192.168.3.193] (gatekeeper.primekey.se [37.247.8.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id B22C545C00BD for <trans@ietf.org>; Wed, 10 Sep 2014 10:01:06 +0200 (CEST)
Message-ID: <54100542.1040509@primekey.se>
Date: Wed, 10 Sep 2014 10:01:06 +0200
From: Tomas Gustavsson <tomas@primekey.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.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> <38010FE8-5B34-4721-94E5-888D3FC62C9E@paypal.com> <540F585C.6050203@bbn.com>
In-Reply-To: <540F585C.6050203@bbn.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5acVQBv8D9R5-Ynle8dU-nxuHgY
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: Wed, 10 Sep 2014 08:01:12 -0000


On 2014-09-09 21:43, Stephen Kent wrote:
> 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.

The question of logging everything is not that clear even today. As 
there is currently drafted how to exclude private domain names in the 
PreCertificates being logged. I see possibility for either:
- Log everything by default, risking to add one item after another that 
can optionally not be logged (=can become complex)
- Define what is to be logged, risking adding new things continuously 
(=can become complex)

In any way, the PreCertificate will most likely (almost)never have 
exactly the same information as the real certificate.

> 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 mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans