From benl@google.com Tue May 29 08:44:12 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1125421F8686 for ; Tue, 29 May 2012 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL24oe4yshTU for ; Tue, 29 May 2012 08:44:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8318C21F8681 for ; Tue, 29 May 2012 08:44:11 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8683942obb.31 for ; Tue, 29 May 2012 08:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=c29czIJIdJBEMyJ3nNL+Ca+qoiQekliDIF+vf5TqH4E=; b=WX9swv/x5PJX3hk+t7bL/xtcxgUuiU/a3ULfa5+QQIKxDyFCmLdAutJtkH11lO6n3+ TEu5uMMGsfuh5Q1QVv/dCeg04E6Z/6/o320A1ycO3BtD4ezEYsFEMoWsl98oLDtuiSOM ZWr+cOwbnLddaIBAqG2yPBq8LBW+sYenISFYzjKuY4dM5DD4D1Wt/HRarEjQp8YLUy8v vJoargBRBuZHA8jw9m4sQoq45I7yMtcA9s91FvHMeG7zxHTa6YTAfHt42uiq5jeENI6i 7BSRGDDzWCYbjmP48bu2CZztzLhu0DTsxJc7x3Gk2q4YIVkhmrI4WRyhisvObwv+P60/ YSnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=c29czIJIdJBEMyJ3nNL+Ca+qoiQekliDIF+vf5TqH4E=; b=cBV+52EIQpygsTjUeD8SCA+HKVYjKKvYMCTMyOQ6RGpnM3zqkasMeTFNA2ukOwNJ5b 9xPqzJjWI6Mb0Zru/KsXLYlKAtdJixhKLdwHt6Urim3Ef+w/v1tZibX9P/3XEDXSn18Y FB70CkrMWN9fOEOuEagv4V9X9jP3a8gQglbcDdjGh4OC3E/e8K+cQaroH07Ohb/7BgRB 7TU+Xz2DfbfSFl/w8Kae40QC6Z50y7lhcxQgaBX8eZSjLvZ9I+x74XPwHgKiUwn/VkHI QAu22BOnzWMy/c9031GDFDWT8PWFBc78ler2CRD83PFLtjJJpVBYtnUtVwR+I4ZQ3kny u3bA== Received: by 10.182.47.66 with SMTP id b2mr11742961obn.2.1338306250959; Tue, 29 May 2012 08:44:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.47.66 with SMTP id b2mr11742950obn.2.1338306250697; Tue, 29 May 2012 08:44:10 -0700 (PDT) Received: by 10.182.122.102 with HTTP; Tue, 29 May 2012 08:44:10 -0700 (PDT) Date: Tue, 29 May 2012 16:44:10 +0100 Message-ID: From: Ben Laurie To: therightkey@ietf.org, revocation@cabforum.org, certificate-transparency@googlegroups.com Content-Type: multipart/alternative; boundary=14dae93998cdac6c1904c12eb40c X-System-Of-Record: true X-Gm-Message-State: ALoCoQm7BXgpNN0bWQ89vqh+h8KDvYZ33H/JId2Of5Kh+yMdlo9jogN0cRIHyanFwS1K1F5n5/KP5kYLsXKTxpUozIR3PwvKUvdEfNLQrRt2yOZxOjsMx+pLkjp3/1XV4M65hAR2NbFZGwW0hNym8/8wMijt1lk26g== Subject: [therightkey] CT and notAfter X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:44:12 -0000 --14dae93998cdac6c1904c12eb40c Content-Type: text/plain; charset=ISO-8859-1 We have realised that, contrary to previous thinking, notAfter, at least, cannot be different between the proof request (or pre-cert as we have also called it) and the issued cert. Why? Because if it is allowed to be different then an attacker could mis-issue a certificate, which gets revoked, wait until its validity period is over so it is dropped from the CRL, and then re-issue with a new validity period and start using it. Is this a problem for CAs? It seems, also, that it would be sensible to have the same requirement for notBefore. Is that a problem? --14dae93998cdac6c1904c12eb40c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We have realised that, contrary to previous thinking, notAfter, at least, c= annot be different between the proof request (or pre-cert as we have also c= alled it) and the issued cert.

Why? Because if it is all= owed to be different then an attacker could mis-issue a certificate, which = gets revoked, wait until its validity period is over so it is dropped from = the CRL, and then re-issue with a new validity period and start using it.

Is this a problem for CAs?

It = seems, also, that it would be sensible to have the same requirement for not= Before. Is that a problem?

--14dae93998cdac6c1904c12eb40c--