Re: [Trans] Precertificate format

Stephen Kent <> Tue, 09 September 2014 17:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C62CA1A7004 for <>; Tue, 9 Sep 2014 10:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.853
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PCLEiu4lEUxN for <>; Tue, 9 Sep 2014 10:39:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADDBD1A7003 for <>; Tue, 9 Sep 2014 10:39:16 -0700 (PDT)
Received: from ([]:37114 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XRPNr-0001qe-K1 for; Tue, 09 Sep 2014 13:39:15 -0400
Message-ID: <>
Date: Tue, 09 Sep 2014 13:39:14 -0400
From: Stephen Kent <>
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
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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 17:39:17 -0000


>> 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.