Re: [Trans] Precertificate format

"Hill, Brad" <> Tue, 09 September 2014 19:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49D581A0176 for <>; Tue, 9 Sep 2014 12:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -22.501
X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KclybXZSbpQb for <>; Tue, 9 Sep 2014 12:12:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EC1F1A015F for <>; Tue, 9 Sep 2014 12:12:57 -0700 (PDT)
DomainKey-Signature: s=paypalcorp;; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:X-CFilter; b=JVLf/VAHK7SJ7O4pF19VrJCalwDWjQav6JXW3Lhby96+nv4SkrxMEUdD TkbDIm6t2BoGU+AVRmoVB+crcjZguUo7qgE2e9Hht135qJGjDB4O2bAxo ozCPLpKDoV88/YA1JdogzMwiT85iLtEV3e6aay1iya/ew1ubeJqxpracm w=;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=paypalcorp; t=1410289978; x=1441825978; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gpH3Jj7bG4taHunZ4PbZwi35I0nkysZx8js/lQ5YqMw=; b=cHGqIjo4QXi2NFUkD3QclaPzp0zFI2ymB3RG4rEvYp3w03z57Xkka0jQ BvQcZ+OG68VDzJyANyCXL2QKoC2syrU1WpQpG89d6weeB/X91WSB1mSWQ bXvBETGUcrvzqd2FXOSwML5FkOlt+eNcyh8qMWcL6VMhawChWLhByVPZ4 Y=;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="5.04,492,1406617200"; d="scan'208";a="67114374"
Received: from (HELO ([]) by with ESMTP; 09 Sep 2014 12:12:57 -0700
Received: from ([fe80::40c1:9cf7:d21e:46c]) by ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 13:12:56 -0600
From: "Hill, Brad" <>
To: Stephen Kent <>
Thread-Topic: [Trans] Precertificate format
Date: Tue, 9 Sep 2014 19:12:55 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned den1
Cc: "" <>
Subject: Re: [Trans] Precertificate format
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Sep 2014 19:12:59 -0000

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.  

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 "\", 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.

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.

With regard particularly to serial numbers it's clear they are necessary as input to revocation mechanisms.


On Sep 9, 2014, at 10:39 AM, Stephen Kent <> wrote:

> 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 mailing list