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

Alberto Leiva <ydahhrk@gmail.com> Wed, 06 March 2019 23:44 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 13DC812008A for <sidr@ietfa.amsl.com>; Wed, 6 Mar 2019 15:44:01 -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 65RkIeQV05Jt for <sidr@ietfa.amsl.com>; Wed, 6 Mar 2019 15:43:59 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 768B21310ED for <sidr@ietf.org>; Wed, 6 Mar 2019 15:43:58 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id w6so15350695wrs.4 for <sidr@ietf.org>; Wed, 06 Mar 2019 15:43:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PCTV1CWyX6jd9s+RfyoNXuS//AW6NpB3TBBhnzFkyvg=; b=U0ukNa5g+bQ8VPJ3ugJJhqS5VuC23xw8Ogf9gme7R+G3CbLdNpWa2agcd0M9dw9Yh3 Qj1u+2sCMEaHpmE6m/mjKMx8xL0BNmcIUQ4YqCmmpXxuXj9JTM3q7ni12gjJNWe1Mgkj Qd38ECjTLvLe/IYXpgQYqYdLLx1XThqOfFpYrhH9iM4PlJ45qncptznVNGMkPk0jPjkh MoLUK2V5f9bq3q9/fuybDgmH3QhgHaygbuoRmqhaIcNFyJs22A4sZq0Anb5PHhGGhQ9Q EXMpxkPj5ffwOxQ0NX4nybKwVlNny9fbGXBs4NNOL77jXH3UIXXJsseag5Jwd5xXNDkz pNBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PCTV1CWyX6jd9s+RfyoNXuS//AW6NpB3TBBhnzFkyvg=; b=ta10dvil71ZutyOMjoTpGfBKjehpm44+1Jbq0V0H3V5SHJAOjq/neMoRxkxer+/OBt zwicmQM2EpnyuJXT3nAW0gQXsNgG3flySAtYKF6IaGw0tP31qAY0iFiFhgW2PljLyan0 ZCVR++vQlmttQ/fofzQKFDBksj1y79CRE3msk6XZwoKuuozimpoKT9eJT2h2xdqDVYVP 28XltVyV+vty9iCkDgt06NZOiTHIMhMMHdI43a8yxyOHOo6XLzXPZMATuyBTKXqj73HP yqNqzGDwpX6hEj0VlxEGCHxKySv9J1/D8vy75v/58Ad2di0NxqDCTGxACOAy68GGijzQ RHQg==
X-Gm-Message-State: APjAAAUT1bQBBH7ZIKGp8jhNycPbpVyKJX8vRgZ1bVetPv+z2LFaZWl1 bfVcKWsEC23xmLiZhFSiN+GvDTP3IYN56IoMRPHIjw==
X-Google-Smtp-Source: APXvYqyyQ94t4e7ritHa+eVZTFODRWGJYYQXsZlCJLSzHBbl/fDJSy9VbblU6tH9QS0XZqiLqRAGmOSa1bIzvcojLOI=
X-Received: by 2002:adf:fc49:: with SMTP id e9mr5033250wrs.2.1551915836887; Wed, 06 Mar 2019 15:43:56 -0800 (PST)
MIME-Version: 1.0
References: <CAA0dE=VA=YAe-SOnRn7y+bcZuAUXdC6-LLfFhUD3j03WQfMzCg@mail.gmail.com> <80A72EB4-1A58-4C2A-8021-2F2AF8857DBF@vigilsec.com>
In-Reply-To: <80A72EB4-1A58-4C2A-8021-2F2AF8857DBF@vigilsec.com>
From: Alberto Leiva <ydahhrk@gmail.com>
Date: Wed, 6 Mar 2019 17:43:45 -0600
Message-ID: <CAA0dE=X3LZwsrC2J2f5OkySKOb1-mv_hSSSGQ5TvtPY26xHPkQ@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IETF SIDR <sidr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/9s-40UEQdthJFz-uzC7bIsGcIjs>
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: Wed, 06 Mar 2019 23:44:01 -0000

Thank you for the clarification.

On Tue, Mar 5, 2019 at 5:11 PM Russ Housley <housley@vigilsec.com>; wrote:
>
> 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
>