Re: [Trans] Prior knowledge of certificate serial number

Erwann Abalea <eabalea@gmail.com> Wed, 24 September 2014 20:58 UTC

Return-Path: <eabalea@gmail.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 5437B1A19F9 for <trans@ietfa.amsl.com>; Wed, 24 Sep 2014 13:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 A7QLaULxdlS8 for <trans@ietfa.amsl.com>; Wed, 24 Sep 2014 13:58:41 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDF51A036D for <trans@ietf.org>; Wed, 24 Sep 2014 13:58:40 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hq11so7171027vcb.34 for <trans@ietf.org>; Wed, 24 Sep 2014 13:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aAFJE/qvWoL/qoXQr/UL3VsBNqQgi3qI8qjpsPHSkug=; b=doI3xpjnQ5TKwjHJjSJMyevoJHujf4cQEnNQ+u+IEXmFaktatEvNAi7UygSGZjaRc6 PFjrJAHZFxciaD+T7fbEroJNluR99moZgOBZU/jB5P1DI5fUgPFEmLXZHo/zDHqTRYev NlxjXqPKP428WC7+VpLykP908rvbGacPZQ/+SQBP6+11AEYOeE+Ks16C0aarmAOoVv3l vHiF7uAKiTQNzLMefEYudaCJHk8r4jYTu8+8eEeeBWHs1fwAnnKJkZ9kBAZJzfYLZVIF yiYfsl5dGRY8rc20ond2Id8Ee6Nul7p8wv7Z6Qug0tg93dIqL/Tq5sxEbWJRMg2riRx9 kagQ==
MIME-Version: 1.0
X-Received: by 10.220.44.80 with SMTP id z16mr7721341vce.7.1411592319945; Wed, 24 Sep 2014 13:58:39 -0700 (PDT)
Received: by 10.52.156.168 with HTTP; Wed, 24 Sep 2014 13:58:39 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D14080F3@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <54219AF0.6040901@gmail.com> <544B0DD62A64C1448B2DA253C011414607D1408063@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CA+i=0E5bkax-X2FK=2whsT3pH-k8H0DfjGLuRAci5tX=whCxmQ@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607D14080F3@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Wed, 24 Sep 2014 22:58:39 +0200
Message-ID: <CA+i=0E6jYVAJajM6GcybhPBkxecr8d5UG1Sov4_WR-7v_0j-RA@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: multipart/alternative; boundary=047d7b34313ccc51a60503d5f2a1
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7p4k1UI9L-9GslNh2Vb7SYgz0KM
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Prior knowledge of certificate serial number
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, 24 Sep 2014 20:58:51 -0000

Well, that's possible, of course. Explaining this to an auditor may be
tricky.

I wanted to make it clear that if, for example, you generate the Precert at
date D with {notBefore=D, notAfter=D+3y}, finalize the push to all the logs
on day D+1, and issue the final cert immediately after that, thus on day
D+1, you MUST NOT have the final certificate with {notBefore=D+1,
notAfter=D+1+3y}. It won't work.

2014-09-24 21:42 GMT+02:00 Rick Andrews <Rick_Andrews@symantec.com>om>:

> Erwann,
>
>
>
> Isn’t it possible that I log a Precertificate in one or more log servers
> and then can’t issue the final certificate, either because of log server
> failure or failure of my issuance system? The log server records my INTENT
> to issue a certificate, but I don’t think it COMPELS me to issue that
> certificate. I must be able to reject that order, change the date and
> serial number and start over.
>
>
>
> We worked around the issuerName+serialNumber constraint by storing
> certificates in one table, Precertificates in another.
>
>
>
> -Rick
>
>
>
> *From:* Erwann Abalea [mailto:eabalea@gmail.com]
> *Sent:* Wednesday, September 24, 2014 12:18 PM
> *To:* Rick Andrews
> *Cc:* Melinda Shore; trans@ietf.org
> *Subject:* Re: [Trans] Prior knowledge of certificate serial number
>
>
>
> Bonsoir Rick,
>
>
>
> If the dates set in the final certificate is different than the dates used
> in the Precertificate, the browser won't be able to verify the SCT. That
> means that all the Precertificates you publish for the same final
> certificate MUST be identical in every aspect.
>
>
>
> We also have an issuerName+serialNumber constraint in database, that's why
> Option 1 isn't an easy task.
>
>
>
> 2014-09-24 21:05 GMT+02:00 Rick Andrews <Rick_Andrews@symantec.com>om>:
>
> Melinda,
>
> At Symantec we know the serial number prior to issuance, because we
> generate it and put it in the TBSCertficate.
>
> The only problem we have with serial numbers is in the case where we fail
> to get enough SCTs to put in the cert. We'll retry the operation up to 48
> hours, but we always want to set the notBefore date to the day we issue the
> cert, so we don't short-change customers (believe me, there are customers
> who notice). But if we update the notBefore date and retry the logging
> operation, we have to change the serial number too. Otherwise we might log
> different certs with the same serial number in different logs, and that
> would be inconsistent. However, we use the combination of issuer name and
> serial number as a unique key for that order in our database, so changing
> serial numbers is challenging. The simpler alternative is to reject the
> order and ask the customer to start over, but that's a bad customer
> experience. We're not sure yet how we'll solve this, but we'll figure
> something out (we don't expect 6962-bis to provide a solution). And while
> we hope that this situation will occur very rarely
>  , it could happen, so we're preparing for it.
>
> -Rick
>
>
> -----Original Message-----
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore
> Sent: Tuesday, September 23, 2014 9:08 AM
> To: trans@ietf.org
> Subject: [Trans] Prior knowledge of certificate serial number
>
> One of the questions that's come up is whether or not it's reasonable to
> expect that CAs will (or can) have knowledge of a certificate's serial
> number prior to issuance - it's one of the basic questions that needs to be
> considered in the context of the precertificate discussions.
> We'd be grateful if any CAs (particularly ones with a CT implementation
> either in the works or planned) could give some feedback on that.
>
> Thanks,
>
> Melinda
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>
>
>
>
> --
> Erwann.
>



-- 
Erwann.