Subject: [pkix] Private key usage period extension

From: "Erik Andersen" <[email-masked]>
Date: Fri, 6 May 2016 10:42:26 +0200

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?

Erik

---

From: Peter Rybár <[email-masked]>
Date: Fri, 6 May 2016 11:50:53 +0200

One key pair can be included in many certificates e.g. cross-certificates.

The validity period of each cross-certificate can be different.

After the time value of notAfter field of the Private key usage period
extension of  the Private key used for signing,  any duplication of the
private key are deleted.

Peter

From: pkix [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, May 6, 2016 10:42 AM
To: Directory list; PKIX
Subject: [pkix] Private key usage period extension

Erik

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 May 2016 10:53:04 +0100

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:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 6 May 2016 12:30:24 +0200

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.

-- 
Erwann.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 May 2016 13:02:03 +0100

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.

> 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

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 6 May 2016 14:25:32 +0200

OK, it is being used. I have seen no reason so far that the private key use period starts before and/or ends after the certificates validity period.

If I get a message together with a certificate and the message is signed after the certificate validity period, but before the notAfter for the private key usage period, what do I do? Consider the certificate invalid and discard the message or do I validate the signature with the public key I am not supposed to use anymore.

It is of no help to me that there may be another certificates with the same key pair, where the certificate validity period is different. I might not know those certificates.

Regards,

Erik

Fra: Erwann Abalea [mailto:[email-masked]] 
Sendt: 06 May 2016 12:30
Til: Stephen Farrell <[email-masked]>
Cc: Erik Andersen <[email-masked]>; Directory list <[email-masked]>; PKIX <[email-masked]>
Emne: Re: [pkix] Private key usage period extension

Bonjour,

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.

 

2016-05-06 11:53 GMT+02:00 Stephen Farrell <[email-masked] <mailto:[email-masked]> >:

Hi Erik,

S.

 

-- 

Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 May 2016 14:44:27 +0200

I think so Erik,

However, to me this belongs with the fuzzy parts of X.509 that would not be designed this way, had the standard been written with the knowledge and experience we have today.
So to me this is a part of X.509 that has little or no value (and not really worth fixing).

Having said that, a private key can have a usage period that extends the certificate, which is a quite common case when certificates are renewed.

At Microsoft, at the time I worked there, we came up with a potential use case  for this extension for CA:s when re-issuing a cert based on an existing cert.
In this use-case the re-issued cert could only be re-issued if not contradicted by the private key usage period extension in the old cert, if present, So in this case the private key usage period had to extend the old cert cert and be honoured in the new cert.
This way you could for example issue a 1 year cert with a 5 year private key validity and make sure It was not renewed forever using the same key.
I think it was actually implemented in the CA but I doubt it was ever used in practice.

/Stefan

From:  <[email-masked]> on behalf of Erik Andersen <[email-masked]>
Reply-To:  <[email-masked]>
Date:  Friday 6 May 2016 at 10:42
To:  Directory list <[email-masked]>, PKIX <[email-masked]>
Subject:  [x500standard] Private key usage period extension

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.

Erik

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 May 2016 13:49:34 +0100

On 06/05/16 13:25, Erik Andersen wrote:
> OK, it is being used. I have seen no reason so far that the private
> key use period starts before and/or ends after the certificates
> validity period.
> 
> 
> 
> If I get a message together with a certificate and the message is
> signed after the certificate validity period, but before the notAfter
> for the private key usage period, what do I do? Consider the
> certificate invalid and discard the message or do I validate the
> signature with the public key I am not supposed to use anymore.

The semantics of message signature validation is not a part
of RFC5280, and as we've seen nor is any semantics for that
particular extension, so you won't find an answer here I
figure.

If X.509 tries to specify such semantics, then IMO that's
broken. So my answer to your question is: go look at whatever
it is that specifies the semantics of that message signature.

S.

> 
> 
> 
> It is of no help to me that there may be another certificates with
> the same key pair, where the certificate validity period is
> different. I might not know those certificates.
> 
> 
> 
> Regards,
> 
> 
> 
> Erik
> 
> 
> 
> Fra: Erwann Abalea [mailto:[email-masked]] Sendt: 06 May 2016
> 12:30 Til: Stephen Farrell <[email-masked]> Cc: Erik
> Andersen <[email-masked]>; Directory list <[email-masked]>;
> PKIX <[email-masked]> Emne: Re: [pkix] Private key usage period
> extension
> 
> 
> 
> Bonjour,
> 
> 
> 
> See ICAO MRTD 9303 part 12 document
> (http://www.icao.int/publications/Documents/9303_p12_cons_en.pdf).
> 
> (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.
> 
> 
> 
> 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.
> 
>> 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.
>> 
>> 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.
>> 
> _______________________________________________ pkix mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Peter Rybár <[email-masked]>
Date: Fri, 6 May 2016 15:01:05 +0200

You can see many certificates with the same key and with different validity period e.g. in Austria trusted list:

http://tlbrowser.tsl.website/tools/index.jsp 

- AT        Rundfunk und Telekom Regulierungs-GmbH

-- Trust Service Providers 

--- A-Trust Gesellschaft für Sicherheitssysteme im elektronischen Datenverkehr GmbH

--- Trust Services

---- a-sign-Premium-Sig-01 (key no. 1)

Certificate (1)

Serial number: 6164

Subject: CN=a-sign-Premium-Sig-01,OU=a-sign-Premium-Sig-01,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT

Valid not before: Thu Jan 23 00:00:00 CET 2003

      not after: Mon Jan 23 00:00:00 CET 2006

SubjectKeyIdentifier

40:D7:F3:9E:1B:87:3A:CC

Certificate (2)

Serial number: 57998

Subject: CN=a-sign-Premium-Sig-01,OU=a-sign-Premium-Sig-01,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT

Valid not before: Mon Dec 06 00:00:00 CET 2004

      not after: Mon Dec 01 00:00:00 CET 2008

SubjectKeyIdentifier

40:D7:F3:9E:1B:87:3A:CC

Certificate (3)

Serial number: 307164

Subject: CN=a-sign-Premium-Sig-01,OU=a-sign-Premium-Sig-01,O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT

Valid not before: Mon Dec 01 00:00:00 CET 2008

      not after: Sat Dec 01 00:00:00 CET 2012

SubjectKeyIdentifier

40:D7:F3:9E:1B:87:3A:CC

...

Peter

From: pkix [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, May 6, 2016 2:26 PM
To: Directory list; PKIX
Subject: Re: [pkix] Private key usage period extension

Regards,

Erik

Bonjour,

 

Hi Erik,

S.

 

-- 

Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 May 2016 15:10:23 +0200

In line;

I just posed one.
Actually I would rather see this period extend the certificate than being shorter than the certificate.

Having it longer than the certificate will not impact validation (see below). Having it shorter may cause confusion and potentially security issues.
Having a shorter private key period may create expectations that a verifier will honor this period fail validation if a signature was created outside of this period.
I doubt that there are many signature validation applications that actually would process this extension if present. Resulting in false positive validation result.

If I get a message together with a certificate and the message is signed after the certificate validity period, but before the notAfter for the private key usage period, what do I do? Consider the certificate invalid and discard the message

Yes, because you don’t have a valid certificate for this signature.

 or do I validate the signature with the public key I am not supposed to use anymore.

No. As the certificate is not valid, you stop there. No information in a certificate that is not valid is of any interest to you.

Exactly. If you don’t have a valid certificate. You fail.

Regards,

Erik

It is typical that closed community applications can make use of odd extensions in a successful manner as they are governed by extended specifications and profiles.

 

Hi Erik,

S.

 

-- 

Erwann.

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 6 May 2016 15:46:27 +0200

Hi Stefan,

Thanks for the clarification. You wrote at some time that the extension is not worth fixing. It is against my responsibility as rapporteur and editor. If it is broken it shall be fixed or deprecated.

I have one issue left. I do not like that either notBefore or notAfter can be omitted. notAfter could mean that the private key is valid until the sun burns out. If not specified, it could default the end of the validity of the cert validity period. Something similar for an omitted notBefore.

Erik

Fra: [email-masked] [mailto:[email-masked]] På vegne af Stefan Santesson
Sendt: 06 May 2016 15:10
Til: [email-masked]; PKIX <[email-masked]>
Emne: [x500standard] Re: SV: [pkix] Private key usage period extension

In line;

From: <[email-masked] <mailto:[email-masked]> > on behalf of Erik Andersen <[email-masked] <mailto:[email-masked]> >

 

I just posed one.

 

 

Regards,

Erik

 

 

Hi Erik,

S.

 

-- 

Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 May 2016 18:52:43 +0200

Hi Erik

From:  <[email-masked]> on behalf of Erik Andersen <[email-masked]>Hi Stefan,

I’m afraid I do not agree.

The default function of a certificate is that both notBefore and notAfter are undefined with regard to private key usage period.
This means that the verifier using this certificate can assume that the private key can be used at least during the validity of the certificate.

In this extension you can set the notBefore and notAfter independently.

I don’t see anything strange or broken with that. It means that the undefined time is undefined = default behaviour.

/stefan

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 May 2016 15:03:47 -0400

We had a very long discussion about this back in the day.  You can look in the mail list archive.

Really, only the owner of the private key can control when the private key is used.  This is not something involves the relying party, so it does not need to go into the certificate.

Russ

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 7 May 2016 05:09:28 +0000

>omitted from RFC 5280 (except for A.2).

It's been deprecated since RFC 2459.  At that time no-one was ever able to
give a coherent explanation for this that got much beyond "PKIX doesn't do
that sort of thing" [0].
 
>validity period of the certificate.

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.

Peter.

[0] Years later people retconned explanations for it, but none of them were 
    terribly credible.

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 7 May 2016 07:53:41 +0200

It seem like we just leave as it is. I could suggest a new note saying
something like "This Specification does not specify any semantic associated
with this extension. This has to be defined for the individual usage".

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: Peter Gutmann [mailto:[email-masked]] 
Sendt: 07 May 2016 07:09
Til: Erik Andersen <[email-masked]>; Directory list
<[email-masked]>; PKIX <[email-masked]>
Emne: RE: [pkix] Private key usage period extension

Erik Andersen <[email-masked]> writes:

>This extension was included in RFC 3280 with a heavy health warning. It 
>was omitted from RFC 5280 (except for A.2).

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.

Peter.

=

---

From: [email-masked] (Martin Rex)
Date: Tue, 10 May 2016 19:55:15 +0200 (CEST)

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

> 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