Subject: [pkix] rfc2560bis -- GeneralizedTime -- how strict should it be?

From: [email-masked] (Martin Rex)
Date: Sat, 13 Apr 2013 05:28:22 +0200 (CEST)

Ted Lemon wrote:
> On Apr 12, 2013, at 10:35 PM, Martin Rex <[email-masked]> wrote:
> > -  MUST specify the revocationTime "700101000000Z"
> 
> *cough*Y2k bug*cough*
> 
> :)
 
Ooops.  I believe you're correct for rfc2560bis.

it seems to rather require  "19700101000000Z"

Since the revokedTime is typically copied from CRLs, and the
Times in X.509v3 certificates and X.509v2 CRLs are concoctions
of UTCTime+GeneralizedTime, I had silently assumed, this
convention would transfer verbatim into OCSP.

For CRLs, PKIX/rfc5280 specifies:

 http://tools.ietf.org/html/rfc5280#section-5.1.2.6

   5.1.2.6. Revoked Certificates

                                  The time for revocationDate MUST
   be expressed as described in Section 5.1.2.4.

 http://tools.ietf.org/html/rfc5280#section-5.1.2.4

   5.1.2.4. This Update

   This field indicates the issue date of this CRL.  thisUpdate may be
   encoded as UTCTime or GeneralizedTime.

   CRL issuers conforming to this profile MUST encode thisUpdate as
   UTCTime for dates through the year 2049.  CRL issuers conforming to
   this profile MUST encode thisUpdate as GeneralizedTime for dates in
   the year 2050 or later.  Conforming applications MUST be able to
   process dates that are encoded in either UTCTime or GeneralizedTime.

   Where encoded as UTCTime, thisUpdate MUST be specified and
   interpreted as defined in Section 4.1.2.5.1.  Where encoded as
   GeneralizedTime, thisUpdate MUST be specified and interpreted as
   defined in Section 4.1.2.5.2.

rfc2560bis was updated to explicitly point to rfc5280 Section 4.1.2.5.2

   http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-18#section-4.2.2

   4.2.2.1 Time

   Responses can contain four times - thisUpdate, nextUpdate,
   producedAt, and revokedAt. The semantics of these fields are defined
   in section 2.4. The format for GeneralizedTime is as specified in
   Section 4.1.2.5.2 of [RFC5280].

Looking at X.690 2008/11 section 11.7  GeneralizedTime,
a value with 2 digit year is *NOT* a valid GeneralizedTime type.

Now I'm wondering about the behaviour of the installed base of OCSP.
Is it true that all OCSP responders correctly return 4-digit years
in all 4 locations (thisUpdate,nextUpdate,producedAt,revocationTime)
and is it desired that OCSP clients REJECT an OCSP responses that
contains only a 2-digit year UTCTime in any one of these 4 locations?

Personally, I'm OK with mandating 4-digit years on send (OCSP responder),
but what about the receiving OCSP client?  Should the client really enforce
4-digit years on receive (following X.690 2008/11 11.7 ?)

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 13 Apr 2013 06:31:40 +0200 (CEST)

>    Section 4.1.2.5.2 of [RFC5280].

While we're at it, is that a new inconsistency in rfc2560bis:

"revokedAt", appearing 2x in Section 2.4 and 1x in Section 4.2.2.1
presumably refers to the revocationTime element in RevokedInfo:

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

and should then be called "revocationTime" consistently throughout
the document.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 13 Apr 2013 08:51:01 +0200

Martin.

Superthanks,

That was a really important catch. This one would have been embarrassing
to publishŠ.
Corrected and republished.

/Stefan