Re: Private key usage period extension

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 protected]] Sendt: 06 May 2016
> 12:30 Til: Stephen Farrell <[email protected]> Cc: Erik
> Andersen <[email protected]>; Directory list <[email protected]>;
> PKIX <[email protected]> Emne: Re: [pkix] Private key usage period
> extension
> 
> 
> 
> 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 <[email protected]
> <mailto:[email protected]> >:
> 
> 
> 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?
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________ pkix mailing list 
> [email protected] https://www.ietf.org/mailman/listinfo/pkix
>

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix