Re: [pkix] Private key usage period extension

mrex@sap.com (Martin Rex) Tue, 10 May 2016 17:55 UTC

Return-Path: <mrex@sap.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DD512D7BC for <pkix@ietfa.amsl.com>; Tue, 10 May 2016 10:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 VloUIsvcESnH for <pkix@ietfa.amsl.com>; Tue, 10 May 2016 10:55:18 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B949112D583 for <pkix@ietf.org>; Tue, 10 May 2016 10:55:18 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 96A56448F9; Tue, 10 May 2016 19:55:16 +0200 (CEST)
X-purgate-ID: 152705::1462902916-0000299C-1C39D8B6/0/0
X-purgate-size: 1539
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 00D8241430; Tue, 10 May 2016 19:55:15 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A09F41A4B5; Tue, 10 May 2016 19:55:15 +0200 (CEST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C7B87A@uxcn10-5.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 10 May 2016 19:55:15 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20160510175515.A09F41A4B5@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/NIYwcGN0YIsCYt9lDinC46un4vU>
Cc: Directory list <x500standard@freelists.org>, PKIX <pkix@ietf.org>
Subject: Re: [pkix] Private key usage period extension
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: mrex@sap.com
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2016 17:55:21 -0000

Peter Gutmann wrote:
> Erik Andersen <era@x500.eu> writes:
> 
>>In my mind, the validity of the private key should not spread outside the
>>validity period of the certificate.


As Russ wrote, a relying party doing signature verification deals with
_public_ key validity and with certificate validity only. So private
key validity might go ignored by many/most verifiers of digital signatures.

Renewal of certificates with same key also seems not that unusual.


> 
> It's not meant for that, in fact it's the exact opposite, it's an extremely
> useful extension for when you want to say that, for example, a signing key is
> valid for one year but the certificate used to verify its signatures is valid
> for ten years.  The lack of a capability for doing this has been plaguing
> cert-based signatures for years, leading to all manner of workaround hacks to
> deal with verifying signatures after the cert has expired.

For "online" signatures (for the purpose of online authentication),
the reference time will should be the real time of the verifier, not a
time asserted by the signer himself in the signature blob.

In contrat to that, "offline" signature verification, in particular
for archived or batch-processed material often uses the reference time
from the signature blob -- and unless that signature is countersigned
by a trusted third-party timestamping authority, a signer-asserted
signing time is pretty fluffy, and could be made to fit within a
"private key validity period".


-Martin