Re: [Trans] Prior knowledge of certificate serial number

Erwann Abalea <eabalea@gmail.com> Wed, 24 September 2014 19:17 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 D39D31A00FD for <trans@ietfa.amsl.com>; Wed, 24 Sep 2014 12:17:35 -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 2Wj0V7wzAUbS for <trans@ietfa.amsl.com>; Wed, 24 Sep 2014 12:17:32 -0700 (PDT)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB3F1A0143 for <trans@ietf.org>; Wed, 24 Sep 2014 12:17:32 -0700 (PDT)
Received: by mail-vc0-f180.google.com with SMTP id hq11so7013292vcb.39 for <trans@ietf.org>; Wed, 24 Sep 2014 12:17:31 -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=InScQ6SYJUYiYXHVQybqSGgfVDvxm95dqQ+VWlGwOhs=; b=cL5HZIte8ztJ4PBIHAoVH1tFw69oWuSKkOMxxIEnAVhf5xFVAfMzAd8tEoF4grUt0J Ih4gC/poTLCpfDKbn5npSUv/RG0QNCXZrI9GpCyjnlbuZ5yfgv2CPggCxYyjmhtMVAD4 z3l7soKpCltMiH2AWEH9N5BbeERNL7FG+/werxUWe0O/55cvSqvpkAQUQ0Fj26DBvtj/ VjhiYrc6/ycpxirdlbF4R6JW/ua5TSxLo+obRJ0/XrKPFsunHsQFKrE/QgsHv9pM+m7c U329iTunSB+gY8j65dQHmQR7dP4eChFBCOPiaPX+E+iKwrK9DSsrfPt36pFKjKBk+bzL 6JXw==
MIME-Version: 1.0
X-Received: by 10.220.169.2 with SMTP id w2mr7469353vcy.33.1411586251249; Wed, 24 Sep 2014 12:17:31 -0700 (PDT)
Received: by 10.52.156.168 with HTTP; Wed, 24 Sep 2014 12:17:31 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D1408063@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <54219AF0.6040901@gmail.com> <544B0DD62A64C1448B2DA253C011414607D1408063@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Wed, 24 Sep 2014 21:17:31 +0200
Message-ID: <CA+i=0E5bkax-X2FK=2whsT3pH-k8H0DfjGLuRAci5tX=whCxmQ@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: multipart/alternative; boundary=001a11c2d150135e940503d489d1
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/OeYBuCV35kRYNw_9c2RnPtvwo50
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 19:17:36 -0000

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.