Re: [pkix] Private key usage period extension

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 06 May 2016 12:02 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 91C9D12D0CF for <pkix@ietfa.amsl.com>; Fri, 6 May 2016 05:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level:
X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 ATSwQDKtBHqe for <pkix@ietfa.amsl.com>; Fri, 6 May 2016 05:02:06 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEDD12D115 for <pkix@ietf.org>; Fri, 6 May 2016 05:02:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA1D2BE38; Fri, 6 May 2016 13:02:04 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrzDmpQBAqKe; Fri, 6 May 2016 13:02:04 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 274F1BE2F; Fri, 6 May 2016 13:02:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462536124; bh=VfXm2fL//htHuWsB8htSHdldTfnq0ahsco5/6l2+8u4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=KrYzxx1ih8cC7x8KEJ7jX2tF4MRxsAMpj8gpYo8BlPCgnXLWKp8uQOY3LGjQ9DWQg FhdxYNuDmZevyIeYPV2/pX3+v51clWZqWLcWmiC1UkMGv3uGDfEcp9qNWhN9rQtTpB NR/QKTk43Z5QUmWOM8NwPvoKnP45ubxSHSHKrRqM=
To: Erwann Abalea <eabalea@gmail.com>
References: <000901d1a773$379e1680$a6da4380$@x500.eu> <572C6980.8000808@cs.tcd.ie> <CA+i=0E6oo1hZSbyN_xYM1oB4-gKiuxCx-OotqAVz+G6Z7S6uJA@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <572C87BB.5000907@cs.tcd.ie>
Date: Fri, 6 May 2016 13:02:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CA+i=0E6oo1hZSbyN_xYM1oB4-gKiuxCx-OotqAVz+G6Z7S6uJA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020008020206030501090504"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/pCa0eGyy7FpVIgQpRW9kcAbs_7M>
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 12:02:09 -0000

Thanks both.

On 06/05/16 10:58, Denis wrote:
>
>
> It is used for certificates issued to Time-Stamping Units.

I could ask how many of those there are I guess, but we don't
need to go there.

On 06/05/16 11:30, Erwann Abalea wrote:
> 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.

Urgh.

> 
> This extension was already deprecated in RFC2459.

Not quite - 2459 says CAs MUST NOT [1] include it,
3280 says it SHOULD NOT [2] be used on the Internet
and 5280 includes it in the ASN.1 module but nothing
much else. None of 'em quite come out and say "bad
idea to even include the code" but I guess given
there's some usage, 5280 is probably still good enough
for this.

S.

[1] https://tools.ietf.org/html/rfc2459#section-4.2.1.4
[2] https://tools.ietf.org/html/rfc3280#section-4.2.1.4
[3] https://tools.ietf.org/html/rfc5280#page-5

> 
> 
> 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?
>>
> 
>