Re: [pkix] Private key usage period extension

Erwann Abalea <eabalea@gmail.com> Fri, 06 May 2016 10:30 UTC

Return-Path: <eabalea@gmail.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 1C6BA12D578 for <pkix@ietfa.amsl.com>; Fri, 6 May 2016 03:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9Jrk2LmJhW0c for <pkix@ietfa.amsl.com>; Fri, 6 May 2016 03:30:27 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F6012D09E for <pkix@ietf.org>; Fri, 6 May 2016 03:30:26 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id m64so126337921lfd.1 for <pkix@ietf.org>; Fri, 06 May 2016 03:30:26 -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; bh=r8e9Gj3yruKuVhgpAorGRqfzO3UJmN/BXrkViGdbjRo=; b=wckaW2+a8zMpKUfEw6I5dr72mg3wNZ1D6XP2IwZpHS+A0Xm6hpUU8x7G+LKs9QPhCd DvGFkCE5hv4ozpQjNKzfhsJjlGX3uXgSlCO9axbnvOPKTZ+EHbOVpv66mDPP4soMGL3i 4oClH21PbjghglnvQZKBR8HPE8XRFJ5B5Nwrs86K/nrjziNSm0nbnlSU7JGLj+4QcKrc jIbv/8yKI07fN3vy5vbpYL0y1z4zfTAQFi3VJPgih5ATNL55aeBYG9qUA2q7KsSPExh7 JcrfdlqYlDKmLmvMt9UUyz/7nmm3LTG8X7pYrmjLP+T2Qeb9rM5DYppX4VNEPgnY9Xvo Yn4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=r8e9Gj3yruKuVhgpAorGRqfzO3UJmN/BXrkViGdbjRo=; b=fxDp1iGL6xxZs2u00GCBM24T/DgkoOkqkN4YTHV4RFhy6nf8/1p9X1sqpiq1Cx/deQ dKn2tdCypWZJDDFO3YAH3fjU6r72KK+UahyQrmalWqk9qZvg8GcKwqknzPOP4r13gg3s wSuNGBTcD1L75ECmwyDnTtWsOdFt9l5pqRR83w3CaP5MyIhheqXGUvh2JMtmTTQdl0lt pyC3eMqkME5QXcAU6VubBojHrGbgpmeuBN1Il0Vd+az86Nfa6vFHg7KfDLI9O3U59Spn DGfGNZt5oPDbG/zEmv6eMIJ5TRCNY4KJANoQ4CwqaZoVjthmF6QkItGVMconmuX1Qisi M1AA==
X-Gm-Message-State: AOPr4FXeBsNkjmrSx5HkFtyo85yuNITUXsfAC6JHpr2MkXBl2gYmhUeMPc0UiuMSKmvgYb3cbEnHqmDL5wk0qQ==
MIME-Version: 1.0
X-Received: by 10.112.181.72 with SMTP id du8mr9193793lbc.137.1462530624652; Fri, 06 May 2016 03:30:24 -0700 (PDT)
Received: by 10.114.4.138 with HTTP; Fri, 6 May 2016 03:30:24 -0700 (PDT)
In-Reply-To: <572C6980.8000808@cs.tcd.ie>
References: <000901d1a773$379e1680$a6da4380$@x500.eu> <572C6980.8000808@cs.tcd.ie>
Date: Fri, 6 May 2016 12:30:24 +0200
Message-ID: <CA+i=0E6oo1hZSbyN_xYM1oB4-gKiuxCx-OotqAVz+G6Z7S6uJA@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a11c36b8a5b10fb053229f218
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/yDSp96xR9Om2c1K_MO4e2TX3zVQ>
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
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: Fri, 06 May 2016 10:30:29 -0000

Bonjour,

This extension is heavily used in electronic passports.
ICAO has set it to be mandatory for Root CA and Document Signer
certificates (subscriber certs used to verify data in passports), and
optional for MasterList signers.
See ICAO MRTD 9303 part 12 document (
http://www.icao.int/publications/Documents/9303_p12_cons_en.pdf).
ICAO did a bad job here; this extension already hurt them in the past
(preventing some Roots to issue a fresh CRL), and their "solution" was to
change the Name comparison rule for CRL checking, so that CAs that don't
have the same Name but have the countryName in common are to be considered
the same CAs, except for China. Yes, it's that bad.

This extension was already deprecated in RFC2459.


2016-05-06 11:53 GMT+02:00 Stephen Farrell <stephen.farrell@cs.tcd.ie>ie>:

>
> Hi Erik,
>
> I've a separate question: does anyone use this extension
> or should we put it on a virtual/mental list of stuff to
> be deprecated when/if someone has the energy?
>
> S.
>
> On 06/05/16 09:42, Erik Andersen wrote:
> > X.509 has a specification of the Private key usage period extension
> > (8.2.2.5). This extension is a little confusing. It has notBefore and
> > notAfter specification. However, the text says:
> >
> > The notBefore component indicates the earliest date and time at which the
> > private key could be used for signing. If the notBefore component is not
> > present, then no information is provided as to when the period of valid
> use
> > of the private key commences. The notAfter component indicates the latest
> > date and time at which the private key could be used for signing. If the
> > notAfter component is not present then no information is provided as to
> when
> > the period of valid use of the private key concludes.
> >
> > With a little ill will, this can be read as the private key validation
> > period may extend beyond the validity of the public key. Note 1 adds to
> the
> > confusing, as it says:
> >
> > NOTE 1 - The period of valid use of the private key may be different from
> > the certified validity of the public key as indicated by the certificate
> > validity period. With digital signature keys, the usage period for the
> > signing private key is typically shorter than that for the verifying
> public
> > key.
> >
> > It is the word "typical" that confuses me. It implies it could be
> different.
> >
> > This extension was included in RFC 3280 with a heavy health warning. It
> was
> > omitted from RFC 5280 (except for A.2).
> >
> > In my mind, the validity of the private key should not spread outside the
> > validity period of the certificate.
> >
> > Have I misunderstood something?
>


-- 
Erwann.