Thank you for the clarification. On Tue, Mar 5, 2019 at 5:11 PM Russ Housley <[email protected]> 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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
