Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Tue, 09 September 2014 18:23 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 8FA511A00A8 for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 11:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level:
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 FHuGoZbxbvgO for <trans@ietfa.amsl.com>; Tue, 9 Sep 2014 11:23:30 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AD81A88A3 for <trans@ietf.org>; Tue, 9 Sep 2014 11:23:30 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:40456 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRQ4t-000CDo-AE for trans@ietf.org; Tue, 09 Sep 2014 14:23:43 -0400
Message-ID: <540F459E.6060504@bbn.com>
Date: Tue, 09 Sep 2014 14:23:26 -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> <CAFewVt5kZqw0-W7PqtFHe7yJUsR9PqVJ6C74ZShgo0qs19wLjA@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140909011451.GW5645@hezmatt.org> <CALzYgEee_=1HTBvF3MQEZeeZc9VL_rK2eRjwVjOnhZKEO+8r=w@mail.gmail.com>
In-Reply-To: <CALzYgEee_=1HTBvF3MQEZeeZc9VL_rK2eRjwVjOnhZKEO+8r=w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020607060209090202000002"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/WG7ruua41DAMQ9WmmnnZ1TbLU_c
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 18:23:34 -0000

Eran,

> I see two issues:
> * What should the precertificate contain.
> * What should be the format of the precertificate.
>
> First I'd like to point out that there already is a way to issue 
> precertificates without violating section 4.1.2.2 in 5280:
> As Matt correctly pointed out, when a Precertificate  is signed by a 
> Precertificate Signing Certificate, then the log produces a signature 
> over a TBSCertificate that _uses the final issuer's identity_, not the 
> one in the Precertificate Signing Certificate (hence the requirement 
> that the Precertificate Signing Certificate will be signed directly by 
> the certificate that will ultimately sign the end-entity certificate 
> the Precertificate represents).
Well, since certs are NOT used to sign anything, I can't agree with the 
phrase "As Matt correctly pointed out" ;-).
> That is explained in section 3.2 of RFC6962 ("Structure of the Signed 
> Certificate Timestamp") or in compliant code 
> <https://github.com/google/certificate-transparency/blob/master/java/src/org/certificatetransparency/ctlog/LogSignatureVerifier.java#L149>. 
>  We could do a better job of explaining this in RFC6962-bis (I 
> personally found it confusing when implementing the Java CT API).
6962-bis is what needs to be clear. Also, code is not generally viewed 
as a spec, for IETF purposes.
> On what precertificates should contain:
> Seems like there's a consensus that it should be all data in the final 
> certificate, except for the serial number, for which there's no agreement.
> The argument against including the serial number, raised
Count me as not part of the consensus. I still want to see an analysis 
of why selected
cert data needs to be part of the SCT.
> mostly by Stephen, is that it may be difficult for CAs who use HSMs to 
> determine/generate the serial number in advance. I don't recall any CA 
> strongly supporting this position (and, given precertificates from 
> several CAs have already hit CT Logs, that's definitely not an issue 
> for several CAs).
On this list, very few CAs seem to be participating. I seem to recall 
one CA commenting that
they had concerns about the per-cert model. I see that one CA, a 
co-author of the doc, says
it was easy to implement. When I was in Beijing last week I spoke with 
folks who deal
with cert issuance there (under CNNIC) and they were completely unaware 
of the TRANS WG.
I wonder how many other CAs outside of the CABF are tracking this activity?
> The argument for including the serial number is its necessity for 
> revoking a certificate - Somebody has mentioned alternative revocation 
> mechanisms that do not require it but have not provided any 
> references, and all current mechanisms I know of require the serial 
> number.
> We all realize the requirement for pre-generating the serial number is 
> a disruptive one for the certificate issuance process - Given the 
> authors of RFC6962 have tried hard not to introduce disruptive 
> changes, I think this is a reasonable given the necessity of the 
> serial number.
here's an off-the-cuff idea on how to have our cake and eat it too.

1. A CA submits a cert template ala CRMF.

2. A log operator generates an SCT* based on this data, and returns it.

3. The SCT* is embedded in a cert by the CA.

4. The CA submits the SCT*, plus the issued cert plus to the same log 
operator, and
a new data item is created, the SCT. It links the serial number to the 
previously-issued
SCT*. If there is a mismatch between the SCT* and the final cert, the 
Monitor will
refuse to issue an SCT.

(A Subject who submits its cert gets an SCT. The serial number is not a 
problem here.)

A TLS client that checks for the presence of an SCT acts as before, but 
with slightly
different processing to match the SCT against the received cert. This 
seems to offer
equivalent (analogous) guarantees to the client, but without a threat 
model I can't be
sure if there is a gap here.

A Monitor will examine a log to determine when an SCT* was issued and no 
SCT was issued subsequently. That is a red flag. An SCT without a 
preceding SCT* is not a problem, as this
is what would occur if a Subject (or OCPS server?) requested an SCT.

Steve