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

Alberto Leiva <ydahhrk@gmail.com> Tue, 05 March 2019 22:33 UTC

Return-Path: <ydahhrk@gmail.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 C46FD131083 for <sidr@ietfa.amsl.com>; Tue, 5 Mar 2019 14:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2CE_m5w9wAax for <sidr@ietfa.amsl.com>; Tue, 5 Mar 2019 14:33:53 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A19F1293B1 for <sidr@ietf.org>; Tue, 5 Mar 2019 14:33:53 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id w6so11223794wrs.4 for <sidr@ietf.org>; Tue, 05 Mar 2019 14:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=P30cUfYGCuxswKO73IHcvLyoiDDBxHUbBBuSq4AIprs=; b=k4HabUn7rf1UFn3NaPXWkFxlJdrdBSZ2Bts1vSmlhF8fg5R2Z2pcrOZUU3MlmfgLzL B8KWgkOUj4suoh6QuYxaLjr8SbeWV3iM6Rkzwtlq5P2tV1MufaEVRk2LEoXbfHqpOrWM pKM14eQp5WepeQXgTPEQV9S1dFO0DncRXabqanRcim030yp2uTgauEiEls35/4P6xpxj 42xH/qWt3OGWGQaE+bxMukxZsQEFuXUCQFJR0rQ0t7YzjIVaIoJa5C33mjph1nzmGm+f bolKwflCFXEWcO7oNueVRQqqeipjsN3rVrg4SuXCPz7fR8+cYV3zs8IebHlJFTc2DMSE mbpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P30cUfYGCuxswKO73IHcvLyoiDDBxHUbBBuSq4AIprs=; b=cR82FarkHRTtfqxeIrIfD3xNk1dxxmgYZKDp87ebmVdVBBn8nqJBUbpbHHgWskEClU AuNXw9l289bzfdUJFSCX7v9kcfIXJcOurOQv3FhTN4Qsx0RYgl6uAE6noxKizOjLiISv EAFBNK9ktFg/Qy+Bbh3mSPbmp5LWBz5Cvy6kwiweODFq2WU3Ix2s6Be/mLtiLfDmWreg AwH0L9rfxfKS9FhdyVXzCOU3c3ZyQavqPDC9hxgL4kEnMIz2/bmJA7Di0/YjIF+Rm7ff zNYzwPulxf6MA1MfffZLu+32/sfpJI7BqMF7/MFitkoRIkeNi8Vr2+wCfFZG0rpYdog7 +H0g==
X-Gm-Message-State: APjAAAVYQLCI2t6gZSlYIBD3JN2gE8nPvE5wLvbpaD6m52hsme4pxhMB Hc5Yi+uxIoffQsHAV1/A0zHCnDFuY8dB1KLMfv5fGbtC
X-Google-Smtp-Source: APXvYqyCKcyxNX0kZSDTX176YycCnlmsGmyqgJbUvyEDaA1nQMzWH6vi+0JoEdxsK9wAUN1TinJZIwrQ+0fqiRirw+c=
X-Received: by 2002:adf:fc49:: with SMTP id e9mr810255wrs.2.1551825231891; Tue, 05 Mar 2019 14:33:51 -0800 (PST)
MIME-Version: 1.0
From: Alberto Leiva <ydahhrk@gmail.com>
Date: Tue, 05 Mar 2019 16:33:41 -0600
Message-ID: <CAA0dE=VA=YAe-SOnRn7y+bcZuAUXdC6-LLfFhUD3j03WQfMzCg@mail.gmail.com>
To: sidr@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/eZFhYUYEbG-36MOCCeAXpsNl6F4>
Subject: [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 22:33:56 -0000

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