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

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
>