Re: [sidr] How are thisUpdate and nextUpdate supposed to be formatted?

Russ Housley <housley@vigilsec.com> Tue, 05 March 2019 23:11 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0CA131119 for <sidr@ietfa.amsl.com>; Tue, 5 Mar 2019 15:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 9d20VIajKkXt for <sidr@ietfa.amsl.com>; Tue, 5 Mar 2019 15:11:54 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1BC131116 for <sidr@ietf.org>; Tue, 5 Mar 2019 15:11:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8E732300AAD for <sidr@ietf.org>; Tue, 5 Mar 2019 17:53:36 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kFQ20Jfhu1xf for <sidr@ietf.org>; Tue, 5 Mar 2019 17:53:35 -0500 (EST)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1357830041F; Tue, 5 Mar 2019 17:53:35 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAA0dE=VA=YAe-SOnRn7y+bcZuAUXdC6-LLfFhUD3j03WQfMzCg@mail.gmail.com>
Date: Tue, 5 Mar 2019 18:11:50 -0500
Cc: IETF SIDR <sidr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <80A72EB4-1A58-4C2A-8021-2F2AF8857DBF@vigilsec.com>
References: <CAA0dE=VA=YAe-SOnRn7y+bcZuAUXdC6-LLfFhUD3j03WQfMzCg@mail.gmail.com>
To: Alberto Leiva <ydahhrk@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/MRahR7yKLVysuOKCJJcerSqodbI>
Subject: Re: [sidr] How are thisUpdate and nextUpdate supposed to be formatted?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 23:12:04 -0000

RFC 5280 says:

5.1.2.4.  This Update

   This field indicates the issue date of this CRL.

So, in this case, it should contain the date that the manifest is created.

RFC 5280 supports two date formats for backward compatibility with X.509v1.

In this case, only one format is supported, GeneralizedTime, so the full 4-digit year is used.

RFC 5280 says:

5.1.2.5.  Next Update

   This field indicates the date by which the next CRL will be issued.

CRLs might be issued early, but this is a promise that a fresh one will be issued on or before the nextUpdate date.

So, in this case, it is a promise that a manifest will be issued on or before the nextUpdate date.

Russ



> On Mar 5, 2019, at 5:33 PM, Alberto Leiva <ydahhrk@gmail.com>; wrote:
> 
> Hello.
> 
> I'm having a bit of trouble implementing RFC 6486 (RPKI Manifests).
> 
> In section 4.2, 6486 defines thisUpdate and nextUpdate as GeneralizedTimes:
> 
>      Manifest ::= SEQUENCE {
>       (...)
>       thisUpdate      GeneralizedTime,
>       nextUpdate      GeneralizedTime,
>       (...)
>       }
> 
> (https://tools.ietf.org/html/rfc6486#section-4.2)
> 
> During section 4.2.1, it further states the following:
> 
>   thisUpdate:
>      This field contains the time when the manifest was created.  This
>      field has the same format constraints as specified in [RFC5280]
>      for the CRL field of the same name.
> 
> Problem: RFC 5280 (https://tools.ietf.org/html/rfc5280#section-5.1)
> defines both CRL fields as Times, not as GeneralizedTimes.
> 
>   Time ::= CHOICE {
>        utcTime        UTCTime,
>        generalTime    GeneralizedTime }
> 
>   (...)
> 
>   TBSCertList  ::=  SEQUENCE  {
>        (...)
>        thisUpdate              Time,
>        nextUpdate              Time OPTIONAL,
>        (...) }
> 
> Further, 5280 states that the usage choice is not arbitrary, but
> rather, depends on the value that's being conveyed:
> 
>   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.
> 
> What I find really strange is that 5280 has rather little to say about
> thisUpdate in particular, aside from its apparent contradiction to
> 6486. So when 6486 does little more than reference 5280... what am I
> supposed to implement?
> 
> Thanks in advance,
> Alberto
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr